次に、STUPIDとSOLIDの原理を紹介します。 これらは原則であり、法律ではないことに留意してください。 ただし、それらを法律として考慮することは、コーディングを改善したい人にとっては良いことです。
STUPIDコード、真剣に？
これはあなたのプライドを傷つけるかもしれませんが、おそらくあなたはすでにたくさんのSTUPIDコードを書いているでしょう。 私も。 しかし、それはどういう意味ですか？
- シングルトン
- 強いカップリング/タイトなカップリング
- テストできない
- 時期尚早の最適化
- 非記述的な命名
- コードの複製
以下のテキストでは、各ポイントについて詳しく説明します。 これらは、一般的に言えば私の話の転写と言えます。
シングルトン
孤独なパターンはおそらく最も有名な開発パターンであり、最も過小評価されています。 ローン症候群について知っていますか？ これは、シングルトンテンプレートが現在のユースケースに最適なテンプレートであると考える場合です。 つまり、どこでも使用できます。 これは間違いなくクールではありません。
単一の要素は矛盾しており、多くの場合、誤ったパターンと見なされます。 それらを避ける必要があります。 実際、シングルトンの使用は問題ではなく、問題の症状です。 理由は2つあります。
- グローバル状態を使用するプログラムはテストが非常に困難です。
- グローバルステータスに依存するプログラムは、依存関係を隠します。
しかし、常にそれらを避けるべきですか？ あなたはしばしばシングルトンを使ってより良いものに置き換えることができるので、私はイエスと言います。 強い結合を防ぐには、静的なものをすべて避けることが非常に重要です。
強いつながり
強い連結性は、シングルトン問題の一般化です。 つまり、モジュール間の通信を減らす必要があります。 接続性は、関連するルーチンまたはモジュールの程度の尺度です。
アプリケーション内の1つのモジュールを変更するために別のモジュールを変更する必要がある場合、接続が存在します。 たとえば、インスタンスをパラメーターとして渡すのではなく、コンストラクターのクラスでオブジェクトをインスタンス化します。 これは、インスタンスをサブクラス、モックオブジェクト、またはその他のもののインスタンスに置き換えるなど、それ以上の変更を許可しないため、良くありません。
強く結合されたモジュールは再利用が難しく、テストも困難です。
テストできない
私の意見では、テストは難しくないはずです！ いやいや。 時間がないために単体テストを作成しないたびに、実際の問題はコードがそれほど効率的ではないことですが、それは別の話です。
ほとんどの場合、テストの不可能性は強い一貫性によって引き起こされます。
時期尚早の最適化
Donald Erwin Knut氏は次のように述べています。「早すぎる最適化はすべての悪の根源です。 費用だけで、ダメです。」 実際、最適化されたシステムは、単にループを作成したり、ポストインクリメントではなくプリインクリメントを使用するよりもはるかに複雑です。 判読不能なコードになってしまいます。 これが、 時期尚早な最適化がしばしばエラーと見なされる理由です。
私の友人は、アプリケーションを最適化するための2つのルールがあるとよく言います。
- これをしないでください。
- （専門家のみ！）まだこれをしないでください。
非記述的な命名
明白なはずですが、それでも言う必要があります。クラス、メソッド、属性、変数に適切な名前を付けてください。 ああ、それらをカットしないでください！ そして、はい、あなたは車のためではなく、人々のためにコードを書きます。 彼らはあなたが何を書いているのか、どうにか理解していません。 コンピューターは0と1のみを理解します。プログラミング言語は人向けです。
コードの複製
複製されたコードは非効率的であるため、繰り返さないでください。また、短くて簡単にします。 コードを1回だけ記述してください！
STUPIDコードとは何かを説明したので、あなたのコードはSTUPIDコードであると思うかもしれません。 それは（まだ）関係ありません。 落胆しないで、落ち着いて、代わりにSOLIDコードを書いてください！
救助にしっかり
ソリッドは、ロバートC.マーティン（ボブおじさん）によって発明された効率的なコードの設計原則のセットを説明する用語です。
ソリッドとは：
- 単独責任の原則
- 開放性/近接性の原理
- バーバラ・リスコフの代替原理
- インターフェース分離の原理
- 依存関係の逆転の原則
単独責任の原則
Single Responsibility Principle（SRP）は、各クラスが1つの単一の責任を持つべきであると述べています。 クラスに変更する理由は1つだけです。
必要なものをクラスに追加できるからといって、これを行う必要があるわけではありません。 責任は、アプリケーションをより良く開発するのに役立ちます。 表現するロジックがこのクラスにあるべきかどうかを自問してください。 アプリでレベルを使用すると非常に役立ちます。 大きなクラスを小さなクラスに分割し、「 神 」クラスを避けます。 最後に、簡単なコメントを書いてください。 この場合のようにコメントを書き始めた場合、ただし、いつ、またはを除いて、間違っている場合。
開放性/近接性の原理
オープン/クローズドプリンシパル（OCP）：エンティティ（クラス、モジュール、関数など）は展開のために開かれている必要がありますが、変更のために閉じられている必要があります。
デフォルトでは、すべてのインスタンス変数をプライベートにする必要があります。 getおよびsetメソッドは、本当に必要な場合にのみ記述してください。 客観的体操の 9番目のルールはこの原則に関連しているので、私はすでに前の記事でこの質問に答えました。
バーバラ・リスコフの代替原理
Liskov Substitution Principle（LSP）：基本型の任意のサブタイプを代用することが可能であるべきです。
例を見てみましょう。 長方形は、4つの直角の平らな図形です。 幅と高さがあります。
ここで、次の擬似コードを見てください。
rect = new Rectangle(); rect.width = 10; rect.height = 20; assert 10 == rect.width assert 20 == rect.height
Rectangleインスタンスで幅と高さを設定するだけで、両方のプロパティが正しいことを確認します。 これまでのところ、とても良い。
ここで、同じ長さの4つの辺を持つ長方形を正方形と呼ぶことで、定義を改善できます。 正方形は長方形であるため、Rectangleクラスを拡張するSquareクラスを作成し、上の最初の行を下に置き換えることができます。
rect = new Square();
正方形の定義によれば、幅は高さと同じです。 問題を見つけることができますか？ Squareクラスのsetメソッドの動作を定義に合わせて変更する必要があるため、最初のステートメントは機能しなくなります。 これは、Barbara Liskov Substitution Principleの違反です。
インターフェース分離の原理
インターフェイス分離の原則（ISP）：多くの特殊なインターフェイスは、1つのユニバーサルインターフェイスよりも優れています。 つまり、使用していないメソッドを実装する必要はありません。 ISPを実装すると、弱い接続性と強い接続性が得られます。
接続に関しては、接続についてもよく言及されます。 強力な接続性とは、類似の要素と関連する要素をまとめて保持することです。 連結性と連結性の組み合わせは、直交構造です。
考えは、コンポーネントの指向性を保ち、コンポーネント間の依存関係を最小限に抑えることです。
これは唯一の責任原則に似ていることに注意してください。 インターフェイスは、ニーズを満たす契約です。 さまざまなインターフェイスを実装するクラスを用意してもかまいませんが、SRPに違反しないように注意してください。
依存関係の逆転の原則
Dependency Inversion PrincipleまたはDIPには2つの主要な原則があります。
- 抽象化は詳細に依存すべきではありません。
- 詳細は抽象化に依存する必要があります。
この原則は、特定のレベルで同じレベルの抽象化を使用する方法を言い換えることができます。 インターフェイスは他のインターフェイスに依存する必要があります。 インターフェイスメソッドシグネチャに特定のクラスを追加しないでください。 ただし、クラスメソッドでインターフェイスを使用します。
依存性反転の原理は、依存性注入と一致しないことに注意してください。 依存性注入とは、あるオブジェクトが別の依存オブジェクトについて認識している場合です。 つまり、1つのオブジェクトがどのようにハマってしまうのかということです。 一方、依存性注入の原理は抽象化のレベルにあります。 さらに、依存性注入コンテナは、クラスを自動的に結合する方法です。 これは、依存関係の注入を行っているという意味ではありません。 たとえば、 Service Locatorを見てください。
また、関連性の高いクラスを操作する代わりに、インターフェイスを使用します。 これはインターフェイスプログラミングと呼ばれます 。 実装機能への依存を減らし、コードの再利用を可能にします。 また、Barbara Liskov Substitution Principleによれば、そのインターフェイスの期待に違反することなく実装を置き換えることができます。
おわりに
おそらくお気づきのように、強力な接続を避けることはここでの重要な要素です。 ここには多くのコードがあり、それを修正することに集中することから始めれば、すぐにより良いコードを書き始めるでしょう。
ここにいくつかのアドバイスがあります。 ソフトウェア開発には多くの原則があります。 これらの原則のすべてを理解していなくても、コードを書く前に常に考えてください。 時間をかけて、理解できないことを理解しようとします。
正直なところ、 SOLIDコードを書くことはそれほど難しくありません。
TL; DR
STUPIDは、Oriented Object Programmingの悪い経験を説明する頭字語です。
- シングルトン
- 強力な接続性
- テストできない
- 時期尚早の最適化
- 非記述的な命名
- コードの複製
SOLIDは、 STUPIDコードを修正するためのオブジェクト指向プログラミングと設計およびエンジニアリングの5つの基本原則の頭字語です。
- 単独責任の原則
- 開放性/近接性の原理
- バーバラ・リスコフの代替原理
- インターフェース分離の原理
- 依存関係の逆転の原理
黄金律：あなたの脳をオンにします！