Kent Beck氏(リンク)が、ソフトウェア設計における継承のアプリケーションを説明するためにFirst One, Then Many(リンク)を書いた。継承とは、現時点において十分なものから最終的に必要とされるものまで、システムのアーキテクチャを進化させるための技術だ。例を挙げると、今のところ、1つのトランザクションを処理すればよいシステムが、最終的には多くのトランザクションを処理しなければならなくなる。
一般的に、エクストリームプログラミングコミュニティ (参考記事リンク)は、必要に応じて進化するシンプルな設計とアーキテクチャを好む。以下のような例がある。
- Never Add Functionality Early(リンク) (早く機能を追加するな)
- YAGNI(リンク) (それは必要ないだろう)
- The Simplest Thing That Could Possibly Work(リンク) (どうにかして動くもっともシンプルなもの)
Kent氏の例(リンク)で、顧客はどのくらいのトランザクションを扱うのかまだ分かっていない。どのタイプのAPIとインフラが複数トランザクションを処理するのに適切であるか開発者が適当に推測しても、この推測はおそらく最適ではない。チームや顧客は、まだ必要ではない機能を開発するために支払いをする。さらに、チームや顧客は、推測に基づいて作成された設計を受け入れるか、その設計を修正するのにコードを書き直すことで、将来また支払わなければならないだろう。Kent氏は、リスクがあることも指摘している。将来の開発者は、APIに基づき、コードがすでに複数トランザクションを処理する能力があると間違って仮定するかもしれない。
Kent氏(リンク)は、今、最小限の設計をして、それを進化させるために継承と呼ぶプロセスを使うことを好む。彼の記事では、ある特定のタイプの継承の実装方法を説明している。すなわち、それは1対多の継承であり、1つのトランザクションを扱うコードから、複数のトランザクションを扱うコードに安全に変えるものだ。
あなたは、最初に複数トランザクションシステムを設計し、構築するだろうか? なぜそうするのか? または、なぜそうしないのか? コメントを残して、考えを共有しよう。
原文はこちらです：http://www.infoq.com/news/2009/02/Succession-Agile-Architecture