プログラミングはジェンガではありません

プログラミングするときに、ジェンガプレーヤー（プレーヤーが、構築中の構造に1つの要素を交互に追加し、そのアクションが破壊につながる要素を失うゲーム）のように感じますか？ ソフトウェアシステムに変更を加えるのは簡単ですか？ 変更を加えた後、コードが突然機能しなくなることを恐れていますか？ これらの質問の1つに「はい」と答えた場合、これはコードが適切に設計されていないことの明らかな兆候であり、表示された翌日には作業が遅くなります。 翌日には理解しにくいコードを開発する必要がありましたか？ ボブ・マーティン（ボブおじさん）の多くのプレゼンテーションに参加できたのは幸運でしたし、コードの質が悪いために開発速度が大幅に低下したかどうかを聴衆に尋ねる彼のスピーチの部分が本当に好きです。 ほとんどの聴衆が手を挙げたとき、彼は尋ねた：「それでなぜあなたはそれをそのように書いたのですか？」







スクラブルをプレイしましょうか？



この記事は、Mark Nijhofによる拡張可能なソフトウェアコードの開発へのアプローチのプレゼンテーションに基づいて書かれ、著者の許可と祝福を得てAlexey Smirnovによって翻訳されました。 これは、SOLIDの原則の使用法を例とともに示しており、初心者や経験豊富な開発者の両方に役立つことを理解できます。



もっとよく見えますか？



柔軟性のないコードの問題を解決するために、それを記述するために使用するスタイルを変更する必要があります。また、今後の変更についてさらに考え、簡単に変更可能なコードだけでなく、文字通り変更が行われることを期待するコードも記述する必要があります将来的に。



明日変更するかのようにコードを書きます。 そのような柔軟なコードを書く際の大きな助けは、その後の再構築に役立つ原則を含むパターン（テンプレート）によって提供されます。 特に、これらはいわゆるSOLID原則です。 それが何であるかを理解してみましょう。 SOLIDは、将来の変更に対処するシステムの能力を大幅に向上させるコードの構造化に不可欠な5つの異なる原則を説明する頭字語です。



素晴らしいデザインとは、難しい質問に対する答えを聞いてから考えることです。もちろん、もちろんです！



著名な著書「レガシーコードを効果的に使用する」の著者であるマイケルフェザーズは、SOLIDという略語を提案した人々の1人でした。 それがどのような原理で構成されているか見てみましょう。

•S-単一責任原則（SRP）

•O-オープンクローズドプリンシプル-OCP

•L-リスコフ置換の原則-LSP

•I-インターフェイス分離の原則（ISP）

•D-依存関係反転の原理-DIP



ボブ・マーティンは、これらの原則の順序については揺るぎないものであり、SOLIDの略語を反映しておらず、SDOLIへの順序の変更を提案しています。 彼の提案に従います。



ティム・バルツからの引用





これは私のシーケンスです

ボブの提案を確認して、私はいくつかの内部プレゼンテーションを行ったと言うことができ、そのたびに説明するのが困難になりました。 SOLIDの原理は互いに密接に関連しており、SDOLIシーケンスによりナレーションが大幅に簡素化されるという事実により、私には思えます。 それでは始めましょう。



ブレードの1つが破損するまですべてを実行できるすばらしいツールに注意してください。1つの破損したブレードが他のすべてのブレードに影響を与えるため、廃棄する必要があります。 クラスを変更する理由は複数ありません。



個人的責任の原則（単一責任原則）は、SOLIDの最初の原則であり、「クラスを変更する理由は複数あるべきではない」ことを示しています 。 これまたはそのクラスまたはメソッドが何に責任を持ち、その責任範囲外にあるものを理解すると、それらを変更するのが常に簡単になります。 個人的な責任範囲があるため、システムの他の部分に影響を与える可能性のある変更を加える可能性はほとんどありません。 もちろん、システムの動作を変更できますが、コードは変更できません。これにより、再利用の可能性が大幅に高まります。 さらに、責任範囲が明確に定義されたソフトウェア設計は、他のすべてから分離してテストするのが簡単です。



OrderProcessorクラスのさまざまな責任領域を詳しく見てみましょう。 ここには、注文の処理、保管、および確認メッセージの送信に関連する3つがあります。 したがって、このクラスを変更する理由は少なくとも3つあります。



ご覧のとおり、責任範囲を3つの異なるクラスに分けました。 これで、これらのクラスを簡単に知るだけで、クラスの責任を理解することができます。再利用しても不必要ではありません。



見た目ほど痛くない。 そうではありません。 低レベルモジュールは低レベルに依存するべきではなく、両方とも抽象化に依存するべきです。 抽象化は詳細に依存すべきではありません。 実装の詳細は抽象化に依存する必要があります。



依存関係反転の原則は、5番目の最終的なSOLID原則であり、 「高レベルモジュールは低レベルモジュールに依存するべきではありませんが、これらのレベルは両方とも抽象化に 依存する必要があります」抽象化 。 」 Brrr 簡単に言えば、これは、コード内の特定の実装に依存するものはなく、インターフェイスまたは抽象クラスへの依存のみが許可されることを意味します。

この原則に従うべき理由は、コードに影響を与えることなく、ある実装を別の実装に簡単に置き換えることができるためです。 はい、正確に。 あなたのコードは絶対に気にするべきではありません。



この例では、OrderProcessorクラスがRepositoryとMailSenderの実装の詳細に依存していることに気付くかもしれません。 通知の送信の実装を変更し、これに別のクラス、たとえばSmsSenderを使用する必要がある場合はどうなりますか？ 悪いニュースは、OrderProcessorクラスにはメッセージの送信方法に関する知識があるため、その実装を変更する必要があるということです。



現在、OrderProcessorは実装メソッドに依存せず、IRepositoryおよびIMailSenderインターフェイスのみに依存しています。 したがって、通知の送信方法を変更する必要がある場合は、IMailSenderインターフェイスの新しい実装を作成し、OrderProcessorに提供するだけです。 OrderProcessor自体は以前と同じように機能し続け、その実装は変更されず、動作のロジックのみを考慮し続けます。



美容師にとって、彼女は失われますが、修正を可能にするためにマスカラや口紅を与えることができます。



Open-Closed Principleはリストの2番目（Open Closed Principle）で、 「ソフトウェアエンティティは拡張のために開かれている必要がありますが、変更のために閉じられている必要があります 。 」 これは、クラスを物理的に変更せずに、クラスの外部動作と外部依存関係を変更できることを意味します。 既に定義されているインターフェイスのフレームワーク内で作業し、コードの一部に特定の変更を加え、他の部分は変更しない場合に、この動作が必要になります。



既にお気づきかもしれませんが、このクラスは依存関係反転の原理を使用した結果であり、オープンクローズド原理にも準拠しています。 これは、依存関係の反転を使用して開封の原理を達成できることを意味しますか？ もちろん、しかしこれはクラスを拡張可能にする唯一の方法からはほど遠いです。



前のスライドでは、OrderProcessorクラスの宣言にIOrderProcessorインターフェイスを追加しました。これにより、このクラスの代替実装を作成できました。 次に、DecoratedOrderProcessor Decoratorクラスを作成しました。これにより、元のクラスに追加の動作が追加され、変更する必要がなくなりました。 同様のアプローチを使用して、この動作をその場で（実行時に）追加することもできます。 このアプローチを示すもう1つの良い例は、 FubuMVCで実行される設計です 。



ごみ収集車は、下からではなく上から開く限り、ごみ容器の色を気にしません。



3番目のSOLID原則はLiskov Substitution Principleであり、 「基本クラスへの参照またはポインターを使用する関数は、実装の詳細を知らなくてもオブジェクトまたはその派生物を使用できる必要があります 。 」 つまり、コードで特定のクラスまたはインターフェイスを使用する場合、内部実装を変更せずに、派生クラスまたはこのインターフェイスの代替実装を使用できる必要があります。 この原則は、変更がコードに与える影響を最小限に抑えます。





PriorityOrderクラスがLiskov Substitution Principleに違反していることに注意してください。 Orderクラスのインスタンスを使用するコードが注文状態（IsValid関数）の有効性をチェックする場合、ブール値の形式で結果を取得することを期待しますが、PriorityOrderクラスのインスタンスを使用する場合、注文が無効である場合に発生する可能性のある例外を追加で処理する必要があります状態。 これらのクラスを操作するには、開発者は、自分が処理しているタイプ（OrderまたはPriorityOrder）を正確に知る必要があります。 そして、これはもちろんレスコウの代替原則に違反します。



この例では、Bob Martinを使用します。 SquareクラスはHeight定義の完全に異なる実装を提供するため、表面積がWidthとHeightの積として計算されることを期待するすべてのRectangleクライアント、不快な驚きを得るでしょう。



医師によっては、あなたを治すのに何が役立つかだけを伝えてください。ただし、医師によっては、一生彼に伝える必要があるかもしれません。 クライアントは、使用しないインターフェイスに依存しないでください。



Interface Segregation Principleは4番目のSOLID原則であり、次のように聞こえます。 「クライアントは、使用しないインターフェイスに依存すべきではありません 。 」 これは、あるオブジェクトの使用方法が異なる場合、顧客を異なる責任分野と混同しないようにする必要があるため、異なるゾーンの可視性を分離するために異なるインターフェイスが必要であることを意味します。 コードの変更による影響を最小限に抑えると言って、繰り返したくありません。



顧客が買い物かごに商品を追加し、内容を表示し、自分自身と配送方法に関する情報を入力し、注文を完了する直前に、注文を確認するための要約データを受け取ることができるシンプルなオンラインストアを想像してください。 したがって、注文を使用するには3つの異なる方法がありますが、これらの使用方法のすべてがOrderクラスが提供できるすべての情報を必要とするわけではありません。



例として、チェックアウトプロセスのさまざまなステップに個別のインターフェイスを作成したことがわかります。 Orderクラスは同じように見えますが、異なるクライアントは、タスクを完了するために必要なクラスの機能にのみアクセスできます。 つまり、Orderクラスの見方が異なります。 このアプローチにより、各ステップでオブジェクトのさまざまな表現を作成および使用でき、この場所で必要なインターフェイスのみを実装できます。



プログラマーの魔法の帽子



コントロールコンテナの反転なしで依存関係の反転を行うことは困難です。 問題は、メソッド実装レベルでの特定の実装へのすべての依存関係が、より高いレベルのコードに移行することです。 まさにこの場合、Inversion of Controlコンテナが役立ちます。



このコードを見てください。 ご覧のように、特定の実装への依存関係はこのレベルでまだ生きています、brrr ...



見た目が良く、もっといいとさえ言うでしょう。 この例では、共通インターフェイスを持ち、すべてのコントロールコンテナの反転をサポートするCommon Service Locatorの使用方法を示します。 制御コンテナの正しい反転により、要求されたクラスが持っている依存関係を自動的に解決し、新しく作成されたクラスに埋め込むことができます。 言い換えれば、私が通常手動で行うことを自動的に行います。



構成の詳細は、プロジェクトで使用するコントロールコンテナーの反転に依存します。 たとえば、 StructureMapを使用します。 彼は悪くない すべての有効な依存関係が定義されているコード内の1つの場所で構成されます。これは、さまざまな実装について知っているコード内の唯一の場所です。 多くのコンテナはXMLを使用した設定をサポートしていますが、タイプセーフの喪失とリファクタリングのサポートにつながるため、私はコンテナの使用に反対しています。



テスト駆動開発/ TDDおよびビヘイビア駆動開発/ BDDまたはテスト駆動設計は、適切な設計を設計することを強制する手法です。 コードを書く前にテストを書くことは、設計にもっと注意を払い、実装しようとしていることに集中するのに役立ちます。その結果、テストの開発で「失われた」時間は、結果として得られる最高の設計に見事に報います。 テスト済みのコードは、将来変更するのも簡単になります。 コードをテストしない理由はありません。 テストは多くの分野で使用されていますが、プログラムを開発するときにテストを使用してみませんか？



繰り返してはいけません。 前述したように、コード内で同様の機能を数回繰り返している場合、変更するときに何かを変更するのを忘れる危険があります。 そして、これはシステムコードの複製だけでなく、テストにも当てはまります。 複製はコードを脆弱にします。 繰り返さないでください！ さて、再び、私はそれをやった...



必要ありません 必要条件から指示された場合にのみ、写真を追加します



あなたはそれを必要としません（あなたはそれを必要としません）。 これは非常に頻繁に起こります。 あなたはシステムのある部分に取り組み、「ああ！ 確かに重宝するものを思いつきました。 今日追加するのが最も簡単な方法だからです。これはまさに私が現在取り組んでいるシステムの一部だからです。」 当然、このまさに必要な瞬間に近づくと、本当に必要なものをよりよく理解できるようになります。 そしてもちろん、これは以前に書いたものとはほど遠いことを理解するでしょう。 したがって、時間を節約する代わりに、作業のやり直しに余分な時間を費やすことになります。 将来のために書かれたコードにも欠陥が含まれている可能性があることを忘れないでください。それは付随する必要があります。 適切に設計されたシステムに機能を追加するのは簡単なので、変更を期待してください！



必死のマニアを伴う男のように、常にコードを書く

自分に正直になって、すぐに高品質のコードを書き始めてください。



アレクセイ・スミルノフは、 21csmのセルゲイ・スレプチェンコと、記事の不正確さの翻訳と修正を支援/支援してくれたすべての人に感謝します。