ゆるこあプログラミング

新卒社員がプログラミングとたたかう

オブジェクト指向設計の原則 とは

以下はメモなので参考になりませんです
勉強される方はここ(http://hamasyou.com/archives/000210)とかお勧めです.

------

オブジェクト指向について考える際に
私が今悩まされているPerlに限らず,プログラミング全体で
共通の設計思想があります.

それがオブジェクト指向設計の原則です.


Perlは非常にオブジェクト指向に不向きで
この言語だけで考えてしまうと,混乱しがちです…

なので広い範囲での概念を学ぶことにします.

クラス設計に関する原則

オブジェクト指向設計の原則というと多くあるようなのですが,
まずは基本から…

  • 単一責任の原則
  • オープン・クローズドの原則
  • リスコフの置換原則
  • 依存関係逆転の原則
  • インターフェイス分離の原則

それぞれ順番に見て行きましょう.

単一責任の原則

クラスが存在する理由が複数あってはならない

たとえば,ひとつのクラスの中に全く志向の違うメソッドが存在していること.
ひとつのクラスには,ひとつの役割だけ与えていればおっけー.
会員登録クラスがあったとして,
その中に登録,編集,退会,お気に入り…そんなに盛り込むのは良くないことです.

オープン・クローズドの原則

ソフトウェアの構成要素は拡張に対して開いていて,修正に対して閉じていなければならない。

拡張性あるコードな一方で,修正した場合の影響範囲をなるべく狭く狭くする.

  • 開かれている:モジュールの拡張が容易
  • 閉じている:モジュールの中身を変更しても他のコードに影響を出さない

ベースクラスを用意して,それに最低限の動作を保証してもらうのが良いのでしょうか.

リスコフの置換原則

派生型はその基本型と置換可能でなければならない

…う…ちょっと解釈に詰まる文章ですね.
ベースクラスにあるメソッドと,あくまで形式が同一の子クラスであるべき?
ってことでしょうか.

依存関係逆転の原則

1. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである
2. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである

いい感じに分からなくなってきました.

インターフェース分離の原則

すべてのインターフェースを一つのクラスに押し込めてしまうのではなく、関連性を持ったインターフェースはグループ化し、抽象基本クラスとして分けて利用すべき

関連性のあるインターフェイスをグループ化する
ここで言ってるインターフェイスってなんだ


わからない_(┐「ε:)_