Erich Gammaいわく

artima developerに連載されている、Erich Gammaインタビュー。気になったところをメモしておきます。
（Web積読解消の一環）
How to Use Design Patterns

• 問題を解決するためにパターンを使うべき。パターンをやたらに使って、設計を複雑にしてはだめ。要求される柔軟性や再利用性を実現するためにパターンを導入すればよい。
• 成熟した設計では、核となる抽象概念(JUnitの場合はTestCase)の周りをパターンで実現される設計ポイントが囲う形になる。
• パターンは、必然のものとして浮かび上がってくる("pattern destiny")。

Erich Gamma on Flexibility and Reuse

• 何年か前、フレームワークを追求し始めたときは、ハイレベルな、ドメインに特化したフレームワークを構築してカスタマイズすれば再利用の涅槃に逝けると思ってた。でもいまはちょっと現実が見えて、それが難しいってことがわかった。
• 将来必要になる柔軟性を予測して実装するのは悪。GoF本には「再利用を最大限を行うためのキーは、新しい要求や、既存の要求に対する変更を前もって知ること、それらが然るべく進化できるようにシステムを設計することである。（GoF本の「概論 1.6デザインパターンで設計問題を解く の 「変更に対する設計」という節の冒頭）」と書いたけど、10年たって大人になって、宗旨替えした。
• リファクタリングするときか、新しい要求を実装するときにパターンを実装する。予想される要求ではなく、実際の顧客が要求するものを実装する。

Design Principles from Design Patterns

• 実装でなくインターフェイスに対してプログラムする
  • インターフェイスを変えるとクライアントを壊すことになるから、基本的に変えてはいけない。
  • 抽象クラスなら新しいメソッドのデフォルト実装を提供できるから、インターフェイス（Javaの）よりメリットがある場合もある。（この辺よくわからず）
  • インターフェイスを変更しないために、EclipseではI*2インターフェイス（IMarkerResolution2, IWorkBenchPart2など）を使っている。IMarkerResolutionやIWorkBenchPartにメソッドを追加したいとき、サブインターフェイスとして作る。新しいメソッドを使うクラスがinstanceofを使ってこのメソッドが使えるかチェックしなければならないというデメリットもあるが。
  • インターフェイス名やメソッド名を眺めれば、そのドメインのボキャブラリがわかる、という価値もインターフェイスにはある。
  • publicなAPIとpublishedなAPIは違う(by Martin Fowler。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AccessModifier)。publishedなAPIは外部に公開されるインターフェイス。Eclipse3.1では、publishedなAPIを特定のパッケージにまとめる機能をサポートしている。
  • 100人のチームで開発するのであれば、コンポーネントごとにチームを分ける。チームの責任は、コンポーネントを作ってAPIをpublishすること。コンポーネント間の依存はAPI(publishedな)で定義する。いったんAPIをpublishしたら、それを安定させておく責任がチームにはある。
• コンポジションと継承
  • サブクラスは親クラスのコンテキストに前提を設けやすいので、両者の結合度が高くなる。
  • コンポジションが継承を使わないというのは誤解。Listenerなんかがよい例で、小さなインターフェイスを継承している。
  • コンポジションを使うと柔軟性が上がることを、"black box reuse"と呼んでいる。コンテナに小さなオブジェクトをplug-inすることで振る舞いを変えられる。Strategyパターンを見よ。継承を使うとこうはいかない。実行時に振る舞いを変えることもできない。

まだまだ、つづきがあるんですよねぇ。