デザインパターンによるプログラム評価(1)
システム開発に対するコンサルティングを実施していると、プログラム品質の検証を相談されることがあります。
コーディング規約等のルールは比較的整備されている企業が多く、違反を抽出するツールも製版されていたりして整備されているのですが、「良いプログラミング」が出来ているか、ということはなかなか評価が難しいところです。
プログラムが構造化、共通部品化されていて効率的に開発でき、追加・改修等の保守がやり易く、構造が分かりやすくなっているかという評価を実施する必要があります。
その際、私たちは「デザインパターン」を評価軸としました。
「デザインパターン」は、オブジェクト指向プログラミングにおいて良く利用される処理概念を集めたものです。
特に、GoF(Gang of Four:Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides)の著作("Design Patterns" Addison-Wesley 1995)に挙げられた23パターンが有名です。
FactoryパターンやIteratorパターン等のオブジェクト指向プログラミングの基礎となる概念が含まれています。
ちなみに日本語訳がSBクリエイティブ社から出ています。
「オブジェクト指向における再利用のためのデザインパターン(改訂版）」(1999)
以下、GoFの23のデザインパターンを記載します。
説明には筆者の解釈が含まれています。
「デザインパターン」
A.生成に関するパターン
(1)Abstract Factory
関連する一連のインスタンスを状況に応じて適切に生成する方法を提供する。
(2)Builder
複合化されたインスタンスの生成過程を隠蔽する。
(3)Factory Method
実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供する。
(4)Prototype
同様のインスタンスを生成するために、原型のインスタンスを複製する。
(5)Singleton
あるクラスについて、インスタンスが単一であることを保証する。
B.構造に関するパターン
(6)Adapter
元々関連性のない2つのクラスを接続するクラスを作る。
(7)Bridge
クラスなどの実装と、呼出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する。
(8)Composite
再帰的な構造を表現する。
(9)Decoraior
あるインスタンスに対し、動的に付加機能を追加する。Filterとも呼ばれる。
(10)Facade
複数のサブシステムの窓日となる共通のインタフエースを提供する。
(11)Flyweight
多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす。
(12)Proxy
共通のインタフェースをもつインスタンスを内包し、利用者からのアクセスを代理する。
C.振る舞いに関するパターン
(13)Chain of Responsibility
イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されてゆくようにする。
(14)Command
複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで操作の切替えを実現する。
(15)lnlerpreter
構文解析のために、文法規則を反映するクラス構造を作る。
(16)Iterator
複数の要素を内包するオブジェクトのすべての要素に順にアクセスする方法を提供する。反復子。
(17)Mediator
オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする。
(18)Memento
データ構造に対する一連の操作のそれぞれを記録しておき、以前の状態の復帰または操作の再現が行えるようにする。
(19)0bserver
インスタンスの変化を他のインスタンスから監視できるようにする。Listenerとも呼ばれる。
(20)State
オブジェクトの状態を変化させることで、処理内容を変えられるようにする。
(21)Stralegy
データ構造に対して適用する一連のアルゴリズムをカプセル化し、アルゴリズムの切替えを容易にする。
(22)Template Method
あるアルゴリズムの途中経過で必要な処理を抽象メソッドに委ね、その実装を変えることで処理が変えられるようにする。
(23)Visitor
データ構造を保持するクラスと、それに対して処理を行うクラスを分離する。
次回、上記デザインパターンをどのようにプログラム評価に利用したかを記述したいと思います。
