すべての開発者が知っておくべきオブジェクト指向プログラミングの 10 の原則

SOLID 原則について聞いたことがない開発者によく会います (私たちは ここでそれらについて詳しく話しました。 — 翻訳）またはオブジェクト指向プログラミング (OOP) について説明するか、聞いたことはありますが、実際には使用しません。 この記事では、開発者の日常業務に役立つ OOP 原則の利点について説明します。 それらの中にはよく知られているものもあれば、あまり知られていないものもあるため、この記事は初心者と経験豊富なプログラマーの両方に役立ちます。

リマインダー： すべての Habr 読者対象 - Habr プロモーション コードを使用してスキルボックス コースに登録すると 10 ルーブルの割引。

スキルボックスは次のことを推奨します。 教育オンラインコース 「Java開発者」.

DRY (繰り返さないでください)

非常にシンプルな原則であり、その本質はその名前から明らかです。「同じことを繰り返さない」。 プログラマーにとって、これは重複コードを避ける必要があることと、作業で抽象化を使用する機会を意味します。

コード内に XNUMX つの繰り返しセクションがある場合は、それらを XNUMX つのメソッドに結合する必要があります。 ハードコードされた値が複数回使用される場合は、それをパブリック定数に変換する価値があります。

これは、コードを簡素化し、保守を容易にするために必要であり、これが OOP の主な目的です。 同じコードは OrderId と SSN の両方で検証に合格しないため、ユニオンも過度に使用しないでください。

変更のカプセル化

ほとんどの企業のソフトウェア製品は常に進化しています。 これは、コードに変更を加える必要があり、サポートする必要があることを意味します。 カプセル化を使用すると作業が楽になります。 これにより、既存のコード ベースをより効率的にテストおよび保守できるようになります。 ここに一例を示します.

Javaで書くと、 デフォルトでプライベートメソッドと変数を割り当てる.

開閉原理

この原則は、次の文を読むと簡単に思い出すことができます。「ソフトウェア エンティティ (クラス、モジュール、関数など) は拡張に対してオープンであるべきですが、変更に対してはクローズされている必要があります。」 実際には、これは、ソース コードを変更せずに動作を変更できることを意味します。

この原則は、ソース コードの変更でコードの改訂、単体テスト、その他の手順が必要になる場合に重要です。 オープン/クローズの原則に従うコードは拡張されても変更されないため、問題ははるかに少なくなります。

この原則に違反するコードの例を次に示します。

その中の何かを変更する必要がある場合は、目的のフラグメントと関連するコードのすべてのセクションを変更する必要があるため、かなりの時間がかかります。

ちなみに、SOLIDの原則の一つに開放性と閉鎖性があります。

単一責任の原則 (SRP)

SOLID セットのもう XNUMX つの原則。 それは、「階級の変化を引き起こす原因はただ一つである」と述べています。 このクラスでは問題が XNUMX つだけ解決されます。 いくつかの方法がある場合がありますが、それぞれは一般的な問題を解決するためにのみ使用されます。 すべてのメソッドとプロパティはこれのみを提供する必要があります。

この原則の価値は、個々のソフトウェア コンポーネントとコードの間の結合を緩めることです。 クラスに複数の機能を追加すると、XNUMX つの関数間に関係が生じます。 したがって、それらのうちの XNUMX つを変更すると、最初のものに接続されている XNUMX つ目のものが台無しになる可能性が高くなります。 これは、すべての問題を事前に特定するためにテスト サイクルを増やすことを意味します。

依存性逆転の原則 (DIP)

上記は、AppManager が EventLogWriter に依存し、AppManager と密接に連携するコード例です。 プッシュ、SMS、電子メールなど、別の方法で通知を表示する必要がある場合は、AppManager クラスを変更する必要があります。

この問題は DIP を使用して解決できます。 したがって、AppManager の代わりに、フレームワークを使用して入力される EventLogWriter をリクエストします。

DIP を使用すると、依存関係モジュールを変更することで、個々のモジュールを他のモジュールに簡単に置き換えることができます。 これにより、他のモジュールに影響を与えることなく XNUMX つのモジュールを変更できます。

継承ではなく合成

コードを再利用するには主に継承と合成の XNUMX つの方法があり、どちらにも独自の長所と短所があります。 通常は XNUMX 番目の方が柔軟性が高いため、優先されます。

コンポジションを使用すると、クラスのプロパティを設定することによって、実行時にクラスの動作を変更できます。 インターフェイスを実装する場合、ポリモーフィズムが使用され、より柔軟な実装が可能になります。

Joshua Bloch 著の『Effective Java』でも、継承ではなく合成を選択するようアドバイスしています。

バーバラ・リスコフの置換原理 (LSP)

SOLID ツールキットのもう XNUMX つの原則。 サブタイプはスーパータイプの代わりに使用できる必要があると規定されています。 つまり、スーパークラスで動作するメソッドと関数は、そのサブクラスでも問題なく動作できる必要があります。

LSP は、単一責任原則と共有責任原則の両方に関連付けられています。 クラスがサブクラスよりも多くの機能を提供する場合、後者は一部の機能をサポートしなくなり、この原則に違反します。

以下は LSP と矛盾するコードです。

area(Rectangle r) メソッドは、Rectangle の面積を計算します。 ここでは Square は Rectangle ではないため、Square を実行するとプログラムがクラッシュします。 LSP の原則によれば、基本クラスへの参照を使用する関数は、追加の命令なしで派生クラスのオブジェクトを使用できる必要があります。

この原則はサブタイプの具体的な定義であり、「データの抽象化と階層」と題された 1987 年の会議の基調講演で Barbara Liskov によって提案されたため、その名前が付けられました。

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

もう一つの堅固な原則。 それによると、使用されないインターフェイスは実装すべきではありません。 この原則に従うことで、システムの柔軟性が維持され、動作ロジックに変更が加えられた場合のリファクタリングに適した状態を保つことができます。

ほとんどの場合、この状況は、インターフェイスに一度に複数の機能が含まれており、クライアントがそのうちの XNUMX つだけを必要とする場合に発生します。

インターフェイスを書くのは難しい作業なので、作業が完了した後に何も壊さずに変更するのは困難です。

Java の ISP 原則の利点は、すべてのメソッドを最初に実装する必要があり、その後でのみクラスで使用できることです。 したがって、この原理によりメソッドの数を減らすことができます。

実装ではなくインターフェイスのプログラミング

ここのすべては名前から明らかです。 この原則を適用すると、インターフェイスの新しい実装で動作する柔軟なコードが作成されます。

変数、戻り値の型、またはメソッドの引数の型にはインターフェイス型を使用する必要があります。 例としては、サブクラスではなくスーパークラスを使用することが挙げられます。

I.e：

リスト番号 = getNumbers();

ではなく：

ArrayList の数値 = getNumbers();

ここでは、上で説明した内容の実際的な実装を示します。

委任の原則

一般的な例は、Java の equals() メソッドと hashCode() メソッドです。 XNUMX つのオブジェクトを比較する必要がある場合、このアクションはクライアントのクラスではなく、対応するクラスに委任されます。

この原則の利点は、コードの重複がなく、動作の変更が比較的簡単であることです。 これはイベントの委任にも適用されます。

これらすべての原則により、凝集性が高く、結合性が低い、より柔軟で美しく信頼性の高いコードを作成できます。 もちろん理論は良いのですが、開発者が得た知識を実際に活用するには実践が必要です。 OOP の原則をマスターしたら、次のステップは、一般的なソフトウェア開発の問題を解決するための設計パターンを学ぶことかもしれません。

スキルボックスは次のことを推奨します。

• 実践コース 「モバイルデベロッパーPRO」.
• オンラインコースの申し込み 「Pythonで学ぶデータアナリスト」.
• XNUMX年間の実践コース 「私はプロのウェブ開発者です」.

出所： habr.com