写真-nesa -Unsplash
頭字語
SOLID-オブジェクト指向プログラミングの最初の5つの原則を示します。
- (SRP). / — . , - , « Unix» KISS.
- / (OCP). — . (Bertrand Meyer) — Eiffel.
- (LSP). , . , . (Barbara Liskov) — Clu.
- (ISP). (Robert Martin), , : « , ». .
- (DIP). , — . ( ).
これに従い、SOLIDの原則が真になるようにクラスと関数を構造化すると、信頼性が高く、理解しやすく、保守が容易なコードが得られる可能性があります。ちなみに、ここには各原則がどのように機能するかを説明するための例があります。
SOLIDを持ってきたのは誰ですか
ご想像のとおり、原則の大部分を担当したのはボブおじさんでした。彼は2000年の設計原則と設計パターンでそれらを包括的に説明し、頭字語SOLID自体は後にエンジニアのMichaelFeathersによって提案されました。興味があれば、マイケルは、レガシーシステムを「復活」させ、途中で夢中にならないようにする方法についてアドバイスする本を持っています。
写真-オスカーユルドゥズ- Unsplash
のSOLID使命を維持し、時間を超える拡張が容易なアプリケーションを開発できるようにすることです。しかし、この一連のガイドラインはしばしば批判されます。
何が批判されているのか
これらの原則は「あいまいすぎる」と呼ばれることもあり、実際に使用するのは困難です。プログラマー兼ライターのJoelSpolskyは、StackOverflow Podcastの1つで、SOLIDの方法論はあまりにもユートピア的であり、実際には、ダニのために冗長なコードに時間を費やすことを開発者に強いていると述べています。
彼は、考えられるすべてのシナリオを考慮に入れて、単純にプログラムし、欠点を徐々に修正し、架空の「セキュリティシステム」に依存しないように、事前に試す必要はないと考えています。 Spolskyは原則の重要性を否定しませんが、それらを過度と呼びます。意見
がありますSOLIDコードは一貫性が低く、テストは簡単ですが、理解するのは非常に困難です（批判では「理解できない」という言葉が使用されます）。プログラマーは、システムのセットアップを支援するよりも気が散って混乱するような、多くの詳細なインターフェースと小さなクラスを作成する必要があります。この声明は、コードの単純さに焦点を当てることで他の開発者がそれをサポートするのに十分であると信じている多くの人々によって共有されています。
写真-ケビンCanlas - Unsplash
ハッカーニューストピックス話しますまた、アーキテクチャ、テクノロジースタック、およびプロジェクトの依存関係の管理の選択ははるかに重要であり、その記述の基礎となる基本的な原則ではありません。ここでも、統合システム設計から始めることの不必要な複雑さを指摘し、YAGNIの原則または「あなたはそれを必要としない」を指摘しています。ある程度、これは古典的なKISSアプローチの別のリミックスです。
SOLIDを擁護する多くの声明があることを認めなければなりません。したがって、HNの居住者の1人は、これらの原則に従うことで、抽象化レベルで問題が発生した場合に条件付きライブラリをすばやく置き換えることができると述べています。新しい実装に対してテストが実行されていることを確認するだけで十分です。それだけで、最大は、古いバージョンのクラスの依存関係を追加でチェックし、必要に応じて、テストに合格するように変更されたものを使用することです。そうすれば、コードに「不必要な複雑さ」がなくなり、後でそれを処理する人は、他の誰かの開発を拒否するといういわゆる症候群に直面することはありません。
SOLIDの原則はガイドラインのみであり、厳密なルールではないことを覚えておくことが重要です。そして、彼らに固執する方が良い場合と、いつ撤退するかは常にあります。
1cloud.ru:
— HTTP-
,
UTF-8
: