http://www.chromium.org/developers/content-module/content-api

動機

• Chromeとコンテントを分離
• 境界をつくり開発者や組み込み者に明確にする

ゴール

• 組み込み用APIはsrc/content/publicにある。

デザイン

一般的にはWebKitに倣う。

• content/publicはインターフェースや構造体、そしてわずかの静的関数を含む
  • 例外はcontent/public/test。ここでは具体クラスを許す。
• 古いスタイルのChrome IPC_messages.hは許さない。.mojomファイルを許す（議論参照）。mojomがコンテント内だけで使われるなら、content/commonに置くべき。組み込み者から利用されるなら、content/public/commonに置くべき。
• それぞれのインターフェース、構造体、列挙は別々のファイルに置くべき。
• コンテントは名前空間content内にあるべき。
• コンテントが実装するインターフェースは純粋仮想であるべき。なぜなら普通１つしか実装が存在しないから。これらはコンテント外で実装されるべきでない。（コンテントはこれらを自由に実装にキャストすることができるべき）。
• 組み込み者が実装するインターフェースは、それはテストやオブザーバスタイルで実装され、多くの実装を持つものだが、デフォルト（空）の実装を持つべき。
• 列挙値は型の名前で始めるべき。例：PAGE_TRANSITION_LINKはcontent::PageTransition列挙の値。
• コンテントが実装するコードをコンテントから呼ぶときはインターフェース経由じゃなく直接呼ぶべき。content/rendererはRenderViewImplを使うべきでcontent/RenderViewじゃない。
• メンバ変数をもつインタフェースや構造体のコンストラクタとデストラクタの実装は許容できる。構造体については、メンバの初期化をする。インタフェースについては（RenderViewObserverのような）自動登録/登録解除をカバーするかもしれない。通常これらの小さなコードはヘッダに置くが、clangはそのことをチェックするので、.ccに置くことを強制される。（例外を追加すると混乱のもとなのでしたくない）
• chromeのコードがコンテントのインタフェースを実装するときは頭にChromeをつけたクラスでやるべき。（例：content::ContentBrowserClientを実装するときはChromeContentBrowserClient）。
• 組込者が必要とするAPIのみ公開すること。メソッドがコンテントのコードのみから利用される場合は、foo_impl.hに属するべきで、foo.hではない。
• 組込者とコンテントは相互にCallし合うので、APIのメソッドはそこに存在すべきである。組込者どうしのCallは存在すべきではない。
• 公開APIのすべてのクラス・構造体・列挙は組込者とコンテントによって使用されるべきである。Chrome層が構造体を使っていてコンテントがそのことを知らないい場合は、それはcontent/publicに属するべきではなくもっと高いレベルに属するべきである。
• ひとつのメソッドだけをもつデリゲートインタフェースは避ける。その場合はコールバックを使う。
• コンストな識別子をインタフェースに追加しない。組込者によってインターフェースが実装される場合、それが必要とされるか知ることはできない。コンテントによって実装される場合は、実装の詳細を公開すべきではない。
• オブザーバインタフェース（WebContentsObserver, RenderFrameObserver, RenderViewObserver)はvoidメンバのみもつべきである。そうしないとオブザーバ登録の順番が問題になる。唯一の例外はOnMessageReceivedで、この場合は１つのオブザーバクラスだけがそれに特化したIPCを扱うので順番は違いを生じさせない。

Done:2018/07/17 (火) 11:40:14