インターフェイスが人（職種でもいいかも）
メソッドが仕事
コクラスが組織
できる仕事は人によって違う（インターフェイスとメソッドの関係）
各人ができる仕事はそれぞれ決まっている（）
ある人が同じ仕事をやる場合でも、親の組織によってやり方が違う（インターフェイスの実装）
同じ人が複数の組織にいてもよい（インターフェイスの継承・コクラスとインターフェイスの関係）
組織がどんな人材を擁しているか（どんな仕事ができるか）は公示する（IDLとかレジストリとか）
仕事に必要なインプットと、仕事の成果物の仕様も公示する（インターフェイス定義だか宣言だか）
組織や人にはIDが振られており、名前とIDを変換する仕組みがある（LID,IID,CID etc)
どの組織にも、その組織にいる人材を管理する窓口が必要（IUnknown)
ある組織にいる人材は、その組織の同僚全員の情報（誰がいて何の仕事ができるか）を聞かれたら答えられる（IUnknownを継承）
組織→人→その人の仕事 と問い合わせると仕事が発注できる（QI経由のメソッド呼び出し）
IUnknownは人材に仕事があるかの管理も行う
ある人の仕事がなくなったら解雇、仕事ができたら再度雇うのが原則（労働者に厳しいね…
組織によっては、仕事を指定するだけで発注可能な窓口を持っている（IDispatch）
組織がIDispatchを持っていれば、それを通じて組織として可能な仕事を直接問い合わせることが可能（オートメーション）
IDispatch経由で頼める仕事は、インプット・アウトプットの形式が制限される（オートメーションタイプ）
（IDispatchが？）コンパイル時に人と仕事の対応を知っておく方法と、受注時に誰の仕事か調べる方法とがある 前者は早い 後者は融通がきく（アーリーバインディングとレイトバインディング）
人経由でもIDispatch経由でも仕事を受注できるようにすることが可能（デュアルインターフェイス）
組織が別の組織を子会社化したり、子会社に仕事を下請けに出すとかもできる その場合人材窓口が混乱しないよう１つにまとめる（アグリゲーションとかデリゲートとか）
（子会社にはならないぞタイプの組織や、子会社としてじゃないと存在できない組織もいる）
発注元の敷地に常駐する住み込むタイプと、常駐しない住み込まないタイプの組織がいる？？？（たとえとしてこれでいいのだろうか・DLLとEXE）
（常駐というとプロセスとして常駐的なやつについても言うからちょっと誤解を招きそう）
住み込み型と住み込まない型とで、仕事のない人を切るか切らないか変わってくるらしい…
住み込み型は、組織の立ち上げと解散も発注元から仕事があるかで決まる
住み込まない型は、組織の立ち上げ・解散タイミングを自分（誰？）の都合で決められる
受注元は、敷地をどう使うか決められる（？）
複数のクライアントからの仕事を同時に受注できる組織と、一度に１つのクライアントからの仕事しかできない組織がいる（MTA, STA？、スレッドモデルのはなしがしたい）
アパートメントの概念を具体的に理解できてねえなこれ
基本はクライアントがサーバーに仕事を発注してアウトプットをもらう
双方向のやりとりをしたい場合はサーバーが連絡担当のひとの情報を公開してクライアントが雇い、サーバ側でなにかあったらその人にれんらくする的な…（コネクタブルオブジェクトとコネクションポイント）
連絡担当の人は連絡のための研修を受けている（コネクションポイント）
こんな人材がいるよなーというのをIDLに書くと、ヘッダとソースにしてくれるのでそれを組織が継承して実装する感じでいいんだっけ…
取引先募集のレジストリもVisual Studioが作って貼り出してくれる