デザインパターン

August 05, 2020

Page content

デザインパターンとは

過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したもの 1994 年に出版されたものであり多くのパターンは古く現代のプログラミングとマッチしないとも言われている。

23 種類のパターンがある。

iterator とは何かが集まっているときに一つ一つを順番に指し示していき全体をスキャンしていく処理を一般化したもの

aggregate インターフェース数え上げを行うものの集合体

具体的なクラスだけで実装しようとするとクラス間の結合が強くなってしまい再利用性が薄れるため抽象クラスやインターフェースを使うということを頭に入れておく。

２つのパターン

委譲とはあるメソッドの実際の処理を他のインスタンスに任せてしまうこと

既存のクラスを使って機能を実装したい時に使える既存のクラスに一皮被せて必要とするクラスを作るバグが発生した際は adapter 役のクラスを調べるだけでいいのでチェックが楽になる

スーパークラスで処理の枠組みを定めサブクラスで具体的な内容を実装するパターンのこと

スーパークラス型の変数にサブクラスのどのインスタンスを代入しても、正しく動作するようにするという原則を The Liskov Substitution Princple(LSP)と言う。

インスタンスの作り方をスーパークラスで定める

具体的なクラス名、肉付けはサブクラスで行う

Product class 製品は何はともあれ使える

Factory class 製品を創り登録する具体的な製品を知らないが創るための method と product についてのみ知っている

IDCard class product の subclass owner 情報を持つ、使う具体的な処理を実装、owner 情報を返せる

IDCardFactory class factory の subclass create_product と register_product の具体的な実装 owners list を持ち、返せる

この構造のおかげで具体的な product のクラス名から Factory class は解放される

まさにその名の通り、抽象化されたクラスを指す言葉。抽象化とは、例えば、人間／犬／猫を抽象化する場合には「動物」となるような、共通した項目(簡潔な項目)に置き換えることである。

人間クラス／犬クラス／猫クラスが存在する場合、これらは動物クラスを継承して作ることができる、と考えると分かりやすい。

つまり、人間クラス／犬クラス／猫クラスを構成するのに必要な最低限の実装が動物クラスには含まれており、これを継承(extends)して内部のメソッドをオーバーライドすることで動物としての共通した機能を持たせつつ、種族によって独自の機能を持った人間クラス／犬クラス／猫クラスを作れるのである。

インターフェースについて説明する為にはカプセル化という考え方を知っておく必要がある。

カプセル化とは「クラス内部の複雑な実装を見なくても、手続きさえ知っていれば外部からクラスを扱えるようにしよう」という考え方のこと。

インターフェースはカプセル化の為に用意されたものである。何故かというと、インターフェースさえ見ればクラス内部の実装を見なくてもクラスを扱うことができるからだ。

インターフェース内部に記述されたメソッドは、インターフェースを使用しているクラス内部でオーバーライドして実装されることが約束されている。もし、実装されていなかった場合はコンパイルエラーとなる。