プログラマーが知らなければならないオブジェクト向け設計の6つの原則

背景
プログラム設計分野では,SOLID(単一機能,開閉原則,リッツ置換,インタフェース分離および依存反転)は,ロバート・C・マーティンが21世紀初期に導入した記憶術頭文字略語であり,オブジェクト向けプログラミングとオブジェクト向け設計の5つの基本原則を指す.
これらの原則が一緒に適用されると、プログラマーがソフトウェアのメンテナンスと拡張を容易にするシステムを開発することがより可能になります.
SOLIDに含まれる原則は,プログラマがソフトウェアソースコードのコード再構成を開始することによってソフトウェアのコード異臭清掃を行い,ソフトウェアが明瞭に読み取り可能であり,拡張可能である場合に適用できるガイドラインである.SOLIDは典型的にテスト駆動開発に応用され,敏捷開発及び適応ソフトウェア開発の基本原則の重要な構成部分である.
単一の職責

単一機能原則(Single responsibility principle)は、各クラスに単一の機能があり、この機能はこのクラスによって完全にカプセル化されるべきであることを規定している.すべてのサービスは厳密にその機能と平行であるべきである(機能は平行であり、依存していないことを意味する).

受注サービスが実装された場合、

開閉の原則

オブジェクト向けプログラミングの分野では、開閉原則は「ソフトウェアのオブジェクト(クラス、モジュール、関数など)は拡張に対して開放的であるべきであるが、修正に対しては閉鎖的である」と規定しており、これは、エンティティがソースコードを変更せずにその動作を変更できることを意味する.この特性は、製品化された環境において特に価値があり、このような環境では、ソースコードを変更するには、コード審査、ユニットテスト、および製品の使用品質を確保するためのプロセスが必要である.このような原則に従うコードは、拡張時に変更されないため、上述の手順は必要ない.

新しいニーズを変更するときは、元のコードを変更するのではなく、オブジェクト向けの特性統合、マルチステートによるビジネスロジックの変更を行います.これにより,回帰テストを行う際に時間コストを削減し,パブリケーションのリスクを低減できる.

メイエ開閉原則
バートランド・マイエは一般的に開閉原則という用語を最初に提案した人とされ、[ソースリクエスト]は1988年に発行された「オブジェクト向けソフトウェア構造」で与えられた.この考え方は,いったん完了すると,1つのクラスの実装は誤りによってのみ修正され,新しいまたは変更された特性は異なるクラスを新規に作成することによって実現されるべきであると考えられる.新しいクラスは、元のクラスのコードを継承することで再利用できます.派生するサブクラスは、元のクラスと同じインタフェースを持つことができるか、または持つことができない.
メイエの定義は継承を提唱している.具体的なインプリメンテーションは継承方式で再利用できますが、インタフェース仕様は必ずしもそうではありません.既存のインプリメンテーションは修正に対して閉じられているが、新しいインプリメンテーションは既存のインタフェースを実装する必要はない.
マルチステート開閉の原則
1990年代には,抽象化インタフェースの使用により,開閉原則が広く再定義され,この中間実装は変更され,多様な実装が作成され,多様な実装が異なる実装に置き換えられる.
メエの使用方式に比べて,多態開閉原則の定義は抽象ベースクラスの継承を提唱している.インタフェース契約は継承によって再利用できますが、再利用する必要はありません.既存のインタフェースは修正に対して閉じられており、新しい実装は、少なくとも、そのインタフェースを実装する必要がある.
リッツ置換
オブジェクト向けのプログラミングでは,Liskov Substitution principleはサブタイプの特別定義である.バーバラ・リスコフ(Barbara Liskov)が1987年の会議で「データの抽象と階層」という演説で最初に提出した.
リ氏置換の原則の内容は、「派生類(サブクラス)オブジェクトは、そのベース類(スーパークラス)オブジェクトの代わりにプログラム内で代替することができる」と記述することができる.以上の内容はリスコフの原文ではなく、ロバート・マーティン(Robert Martin)の原文の解読から訳されている.
これは,我々のサブクラスがすべてのベースクラスを置き換え,ある抽象クラスを継承したり実現したりすることを意味する.その子は親のすべての能力を持っています.子クラスと親クラスは間違いなくjavaの継承であり、郭継承インタフェース/抽象クラス/クラス実現インタフェース/抽象クラス/クラスを通じて実現される.彼はこの原則に従っているのではないでしょうか.親を継承し、親を書き換える方法で、子は親を置き換えることができますか?これではいけません.

/**
 * @author yuanxindong
 * @date: 2020/7/29 13:17
 */
public class demo extends DemoDad {
    @Override
    public String getName(){
        return  "son";
    }

    public static void main(String[] args) {
        Demo demo = new Demo();
        System.out.println(demo.getName());
        DemoDad demoDad = new Demo();
        System.out.println(demoDad.getName());
    }
}

/**
 * @author yuanxindong
 * @date: 2020/7/29 13:18
 */
public class demoDad {
   public String getName(){
        return  "dad";
    }
}

以上のdemoにより,この場合は親を子で置き換えることはできず,歴史的置換の原則に従わない.
依存逆転
オブジェクト向けプログラミングの分野において、依存反転原則(Dependency inversion principle,DIP)とは、特定のデカップリング(従来の依存関係は高レベルに作成され、具体的なポリシー設定は低レベルのモジュールに適用される)形式を指し、高レベルのモジュールは低レベルのモジュールの実装の詳細に依存せず、依存関係は逆転(反転)される.これにより、低階層モジュールは、高階層モジュールの需要抽象に依存する.
この原則の規定:
高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両方とも抽象インタフェースに依存すべきである.抽象インタフェースは、特定の実装に依存するべきではありません.具体的な実装は抽象インタフェースに依存しなければならない.この原則は一部の人のオブジェクト向け設計に対する認識方式を逆転させた.高レベルオブジェクトと低レベルオブジェクトが同じ抽象インタフェースに依存する必要がある場合
インタフェース分離
インタフェース分離の原則(英語:interface-segregation principles、略称:ISP)は、クライアント(client)がそれにとって役に立たない方法や機能を強制的に使用すべきではないことを示しています.[1]インターフェース分離の原則(ISP)は、非常に膨大で肥大化したインターフェースを分割し、より小さく、より具体的なインターフェースとなり、お客様が興味を持っている方法を知る必要があります.このような縮小されたインタフェースは、ロールインタフェース(role interfaces)とも呼ばれる.
インタフェース分離の原則(ISP)の目的は,システムが結合を解除し,再構築,変更,再配置を容易にすることである.インタフェース分離の原則は,GRASP(オブジェクト向け設計)における高集約性と同様に,SOLID(オブジェクト向け設計)における5つのオブジェクト向け設計(OOD)の原則の1つである.インタフェース分離の原則(英語:interface-segregation principles、略称:ISP)は、クライアント(client)がそれにとって役に立たない方法や機能を強制的に使用すべきではないことを示しています.インタフェース分離の原則(ISP)は、非常に膨大で肥大化したインタフェースを分割して、より小さく、より具体的なインタフェースになります.これにより、お客様は興味のある方法を知る必要があります.このような縮小されたインタフェースは、ロールインタフェース(role interfaces)とも呼ばれる.
インタフェース分離の原則(ISP)の目的は,システムが結合を解除し,再構築,変更,再配置を容易にすることである.インタフェース分離の原則は,GRASP(オブジェクト向け設計)における高集約性と同様に,SOLID(オブジェクト向け設計)における5つのオブジェクト向け設計(OOD)の原則の1つである.
ディミットの原則

ディミット法則(Law of Demeter)はまた最小知識原則(Least Knowledge Principle略LKP)と呼ばれ、1つのクラスは他のクラスについて知っていることが少ないほど良い.つまり、1つのオブジェクトは他のオブジェクトに対してできるだけ少ない理解を持って、友达と通信して、知らない人と話をしないべきだ.英語:LoD.

ディミット法則はクラス間の直接的なつながりを望んでいない.本当に連絡が必要なら、その友元類を通じて伝えてほしい.したがって、ディミット法則を適用すると、システムに大量の仲介クラスが存在し、これらのクラスが存在するのは完全にクラス間の相互呼び出し関係を伝達するためである可能性がある--これはある程度システムの複雑さを増加させる.3.広義のディミット法則の類の設計上の体現:

クラスを不変クラスに設定することを優先します.

クラスへのアクセスを最小限に抑えます.

Serializableを慎重に使用します.

は、メンバーのアクセス権を最小限に抑えます.

リファレンス
https://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1) https://zh.wikipedia.org/wiki/%E5%8D%95%E4%B8%80%E5%8A%9F%E8%83%BD%E5%8E%9F%E5%88%99