Javaでは、 堅固な原則 ソフトウェア構造の設計に適用されるオブジェクト指向のアプローチです。それはによって概念化されます ロバート・C・マーティン （ボブおじさんとしても知られています）。これら 5 つの原則はオブジェクト指向プログラミングの世界を変え、ソフトウェアの書き方も変えました。また、ソフトウェアがモジュール化されており、理解、デバッグ、リファクタリングが容易であることも保証されます。このセクションでは、次のことについて説明します。 Java の SOLID 原則 適切な例とともに 。
SOLID という言葉の頭字語:
Javaのaのascii
- 単一責任原則 (SRP)
- オープンクローズ原則 (OCP)
- リスコフ置換原理 (LSP)
- インターフェース分離原則 (ISP)
- 依存関係逆転の原則 (DIP)
原理を一つずつ詳しく説明しましょう。
単一責任の原則
単一責任原則では次のように述べられています。 すべての Java クラスは単一の機能を実行する必要があります 。単一クラスに複数の機能を実装するとコードがマッシュアップされるため、変更が必要な場合はクラス全体に影響を与える可能性があります。コードが正確であり、コードの保守が容易です。例を通して単一責任の原則を理解しましょう。
仮定する、 学生 は 3 つのメソッドを持つクラスです。 printDetails()、calculatePercentage()、 そして addStudent()。 したがって、Student クラスには、学生の詳細を出力し、パーセンテージを計算し、データベースを作成するという 3 つの役割があります。単一責任の原則を使用すると、これらの機能を 3 つの別個のクラスに分離して、原則の目的を達成できます。
Student.java
public class Student { public void printDetails(); { //functionality of the method } pubic void calculatePercentage(); { //functionality of the method } public void addStudent(); { //functionality of the method } } 上記のコード スニペットは、単一責任の原則に違反しています。原則の目的を達成するには、単一の機能のみを実行する別のクラスを実装する必要があります。
Student.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } パーセンテージ.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } したがって、機能を 3 つの別個のクラスに分離することで、単一責任原則の目標を達成しました。
オープンクローズの原理
アプリケーションまたはモジュールは、メソッド、関数、変数などを実体化します。オープンクローズ原則では、新しい要件に従って、 モジュールは拡張のためにオープンされている必要がありますが、変更のためにクローズされている必要があります。 この拡張機能を使用すると、モジュールに新しい機能を実装できます。例を通して原理を理解しましょう。
仮定する、 車両情報 はクラスであり、メソッドがあります 車両番号() 車両番号を返します。
VehicleInfo.java
このxdはどういう意味ですか
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Truck という名前の別のサブクラスを追加する場合は、オープンクローズ原則に違反する if ステートメントをもう 1 つ追加するだけです。サブクラスを追加し、原則の目的を達成するには、 車両番号() 以下に示すような方法です。
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber() { //functionality } } public class Car extends VehicleInfo { public double vehicleNumber() { return this.getValue(); } public class Car extends Truck { public double vehicleNumber() { return this.getValue(); } 同様に、車両クラスから拡張する別のサブクラスを作成することで、さらに車両を追加できます。このアプローチは既存のアプリケーションには影響しません。
リスコフ置換原理
リスコフ置換原則 (LSP) は、によって導入されました。 バーバラ・リスコフ 。これは次のような方法で継承に適用されます。 派生クラスはその基本クラスを完全に置き換え可能でなければなりません 。言い換えれば、クラス A がクラス B のサブタイプである場合、プログラムの動作を中断することなく B を A に置き換えることができるはずです。
これは、オープン/クローズの原則を拡張し、スーパークラスとそのサブタイプの動作にも焦点を当てています。特別な理由がない限り、プロパティを保持するようにクラスを設計する必要があります。例を通して原理を理解しましょう。
Student.java
public class Student { private double height; private double weight; public void setHeight(double h) { height = h; } public void setWeight(double w) { weight= w; } ... } public class StudentBMI extends Student { public void setHeight(double h) { super.setHeight(h); super.setWeight(w); } public void setWeight(double h) { super.setHeight(h); super.setWeight(w); } } StudentBMI クラスには身長と体重が同じでなければならないという追加の制約があるため、上記のクラスはリスコフ置換原則に違反しています。したがって、Student クラス (基本クラス) を StudentBMI クラス (派生クラス) で置き換えることはできません。
したがって、Student クラスを StudentBMI クラスに置き換えると、予期しない動作が発生する可能性があります。
インターフェース分離原理
この原理は、大きなインターフェースが小さなインターフェースに分割されることを示しています。実装クラスは必要なメソッドのみを使用するためです。クライアントが使いたくない方法の使用を強制すべきではありません。
インターフェイス分離原則の目標は、単一責任原則と似ています。例を通して原理を理解しましょう。
複数行のコメントPowerShell
次の名前のインターフェイスを作成したとします。 変換 3つの方法がある intToDouble()、intToChar()、 そして charToString() 。
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } 上記のインターフェースには 3 つのメソッドがあります。 intToChar() メソッドのみを使用したい場合は、単一のメソッドを実装するという選択肢はありません。この問題を解決するために、原理によりインターフェースを 3 つの別々のインターフェースに分割することができます。
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } これで、必要なメソッドのみを使用できるようになります。整数を double に変換し、文字を string に変換したいとします。その場合、次のメソッドのみを使用します。 intToDouble() そして charToString()。
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } 依存関係逆転の原則
この原則では、具体的な実装ではなく抽象化 (抽象クラスと抽象インターフェイス) を使用する必要があると述べています。高レベルのモジュールは低レベルのモジュールに依存すべきではありませんが、両方とも抽象化に依存する必要があります。なぜなら、抽象化は詳細に依存するのではなく、詳細は抽象化に依存するからです。ソフトウェアを切り離します。例を通して原理を理解しましょう。
public class WindowsMachine { //functionality } Windows でキーボードとマウスを使用できない場合には、この機能を使用する価値があります。この問題を解決するには、クラスのコンストラクターを作成し、キーボードとモニターのインスタンスを追加します。インスタンスを追加すると、クラスは次のようになります。
public class WindowsMachine { public final keyboard; public final monitor; public WindowsMachine() { monitor = new monitor(); //instance of monitor class keyboard = new keyboard(); //instance of keyboard class } } これで、キーボードとマウスを使用して Windows マシンで作業できるようになりました。しかし、私たちはまだ問題に直面しています。 new キーワードを使用して 3 つのクラスを緊密に結合したためです。クラスの Windows マシンをテストするのは困難です。
コードを疎結合にするために、Keyboard インターフェイスとこのキーワードを使用して WindowsMachine をキーボードから切り離します。
キーボード.java
SQL複数テーブル選択
public interface Keyboard { //functionality } WindowsMachine.java
public class WindowsMachine { private final Keyboard keyboard; private final Monitor monitor; public WindowsMachine(Keyboard keyboard, Monitor monitor) { this.keyboard = keyboard; this.monitor = monitor; } } 上記のコードでは、依存関係の注入を使用して WindowsMachine クラスにキーボードの依存関係を追加しました。したがって、クラスを分離しました。
なぜSOLID原則を使用する必要があるのでしょうか?
- 依存関係が軽減されるため、他のコード ブロックに影響を与えることなくコード ブロックを変更できます。
- 設計をより簡単に、理解しやすくすることを目的とした原則。
- この原則を使用すると、システムは保守可能、テスト可能、拡張可能、および再利用可能になります。
- ソフトウェアの不適切な設計を回避します。
次回ソフトウェアを設計するときは、これら 5 つの原則を念頭に置いてください。これらの原則を適用すると、コードはより明確になり、テストしやすく、使いやすくなります。