SOLIDの原則を整理する

SOLIDとは?

SOILDはオブジェクト向けの設計原則であり,コード作成後にメンテナンスに有利で拡張しやすいシステムを作成するのに適している.
サードパーティ製プロジェクトチェスのコードまたはJava APIのコードを参照してください.

2-1. 単一責任原則（SRP）

一つの階級には一つの責任しかない.
チェスゲームでは、ボード上の「行」は「ファイル」、「列」は「Rank」と表現され、チェスゲームのUIではこの用語が用いられるが、内部論理では2次元配列に格納されているため、行はX座標、列はY座標と表現される.
次のコードは,チェスゲームにおけるチェスの位置を表すためのPositionクラスである.

public final class Position {
    private final int x;
    private final int y;

    private Position(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }

    public static Position of(int x, int y)  {
        return new Position(x, y);
    }

    public static Position copy(Position position) {
        return new Position(position.getX(), position.getY());
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Position)) return false;
        Position position = (Position) o;
        return getX() == position.getX() && getY() == position.getY();
    }

    @Override
    public int hashCode() {
        return Objects.hash(getX(), getY());
    }

    @Override
    public String toString() {
        return "Position{" +
                "x=" + x +
                ", y=" + y +
                '}';
    }
}

Positionクラスは、部品の位置を表示します.
器物の位置はprivateによって保護され、戻り値のget()のみが存在します.
外部で使用されるAPIには、オブジェクトを作成して返すof()と、コピー先のcopy()があります.さらに,オブジェクトの位置を比較するためにequals(),hashcode()およびtoString()も実現した.
オブジェクトを整理する機能は、メカニズムの位置を保存して戻す機能と、位置を作成またはコピーする機能があると見なすことができます.
つまり、物の位置責任に合った機能しか収集されていないということです.
値を取得し、値を比較する機能を提供する前に、位置を作成する必要があります.
逆に,次のコードはチェス盤の範囲に位置が合っているかどうかを調べる方法である.

boolean validPiecePosition(Position position) {
    return (0 <= position.getX() && position.getX() < MAX_NUM_OF_LINE) && (0 <= position.getY() && position.getY() < MAX_NUM_OF_LINE);
}

このメソッドがロケーションクラスに入ると、単一の責任原則に違反するとみなされる可能性があります.Positionの役割は、碁盤の情報ではなく、器物の位置を知ることです.
実際、単一の責任には一定の曖昧性がある可能性があります.どこまで作るかわからない
それでもクラスやメソッドをより小さな単位に分割し、継続的な練習を行う必要があります.これにより、より信頼性の高いオブジェクト向けのコードを生成できます.

2-2. オープン-クローズの原則(OCP)

オブジェクトは展開時に開きますが、変更時に閉じる必要があります.
設計モードでは、ポリシーモード、アダプタモード、エージェントモードなどの多くのモードがこれらの原則に従います.
JDBCは典型的なOCP応用例である.

JavaアプリケーションがDBMSと統合する必要がある場合、JDBC(Java Database Connectivity)テクノロジーが使用されます.
JavaはJDBCインタフェースを定義し、DBMS開発者がインタフェースを実装するライブラリを提供します.このため,開発者はJDBC APIに従って符号化し,DBMSと一致するライブラリを使用することができる.
他のDBMSに変更した場合、Javaコードはほとんど変化せず、JDBCライブラリのみを置き換えることができます.
「オープン-クローズド」の原則では、JDBC APIを変更せずに拡張可能な構造と見なすことができます.

2-3. リスコフ交換の原則(LSP)

オブジェクトをサブタイプのインスタンスに変換しても、プログラムの正確性を破壊することはできません.
チェスゲームの器物は王、皇后、ルーク、ピシャップ、ナイト、携帯電話6点ある.6つの器物は共通の特徴を持ち、抽象化することができる.
以下はチェスゲーム器物の継承構造である.

すべてのコンポーネントは最上位のPieceインタフェースを実現し、NullPieceを除いて、残りのコンポーネントはAbstractPiece抽象クラスを継承します.
「器物」クラスがAbstractPieceタイプまたはPieceタイプの場合、完全に正常に使用できます.
Pieceインタフェースを実装する前提はPieceのすべての抽象的な方法を実装することであるからである.
継承構造をAS-IS関係として記述すると、
「皇后は器物だ」
「服は器物」
これは継承構造が非常に自然に表現されているからだ.

2-4. インターフェース分離の原則（ISP）

汎用インタフェースというより、複数の用途でより細かいインタフェースです.
より詳細には、原則として使用しない方法に依存するべきではなく、ある機能を修正すれば、他の機能に影響を与えるべきではない.
ソリューションは簡単です.マルチキャラクタインタフェースをより具体的でより小さいインタフェースに分離するだけです.

2-5. 依存関係逆転の原則(DIP)

具体化より抽象化に頼るべきだ.
これらの原則には、次のものが含まれます.

親は子に依存できません.親クラスと子クラスは抽象に依存する必要があります.

抽象化は細部に頼ることができない.細部は抽象に頼らなければならない.

要するに抽象に頼ることだ.
特定のクラスを継承したり、特定の関数を上書きしたりすると、多くの問題が発生します.不必要な依存性が生じ,後で変更することも容易ではない.
したがって、抽象クラス、実装インタフェース、および上書き特定の関数は、特定のクラスに比べて継承されるべきではない.