私は最近OOPに入ろうとしていますが、SOLIDの原則とデザインパターンに問題があります。なぜ人々がそれらを使用するのかがわかり、私もそれらを使用したいのですが、仕様に合わせてクラスを開発することに頭を悩ませることはできません。そのようなことを理解するのに役立つものがあれば、本当にありがたいです。
17369 次
1 に答える
123
私は大学でデザインパターンの周りに2週間を費やしたクラスを受講し、GangofFourの本を読んでも無駄になりました。各パターンが何に役立つのか、そしてそれらをどのように使用して私の問題に合わせるのかを理解することは、オブジェクト指向プログラミングの経験があまりない開発者にとって非常に困難でした。
私にとって本当にクリックした本は、Head FirstDesignPatternsでした。まず、問題、開発者が検討したさまざまなアプローチ、そしてそれを修正するためにデザインパターンを使用することになった経緯を示します。それは非常に単純な言語を使用し、本を非常に魅力的に保ちます。
デザインパターンは最終的にソリューションを説明する方法になりますが、クラスをソリューションに適合させる必要はありません。それらは、さまざまな問題に対する優れた解決策を提案するガイドとして考えてください。
SOLIDについて話しましょう：
- 単一責任。クラスには1つの責任しかありません。つまり、たとえば、Personクラスは、個人自体に関するドメインの問題のみを考慮し、データベースでの永続性については考慮しない必要があります。そのためには、たとえばPersonDAOを使用することをお勧めします。Personクラスは、その責任を可能な限り短くしたいと思うかもしれません。クラスがあまりにも多くの外部依存関係（つまり、他のクラス）を使用している場合、それはクラスがあまりにも多くの責任を持っていることの症状です。この問題は、開発者がオブジェクトを使用して現実の世界をモデル化しようとし、それをやりすぎた場合によく発生します。ゆるく結合されたアプリケーションは、ナビゲートするのが非常に簡単ではなく、実際の動作を正確にモデル化していないことがよくあります。
- オープンクローズ。クラスは拡張可能である必要がありますが、変更することはできません。つまり、クラスに新しいフィールドを追加することは問題ありませんが、既存のものを変更することは問題ありません。プログラムの他のコンポーネントは、上記のフィールドに依存する場合があります。
- リスコフの置換。サブクラスの犬とサブクラスの猫が渡された場合、動物タイプのオブジェクトを期待するクラスが機能するはずです。つまり、cat型のサブクラスは吠えることができないため、Animalにはたとえば樹皮と呼ばれるメソッドを含めるべきではありません。Animalクラスを使用するクラスも、Dogクラスに属するメソッドに依存するべきではありません。「この動物が犬の場合、（動物を犬にキャストする）吠える。動物が猫の場合、（動物を猫にキャストする）ニャー」のようなことはしないでください。
- インターフェイス分離の原則。インターフェースはできるだけ小さくしてください。学生でもある教師は、IStudentAndTeacherと呼ばれる単一の大きなインターフェイスではなく、IStudentインターフェイスとITeacherインターフェイスの両方を実装する必要があります。
- 依存性逆転の原則。オブジェクトは依存関係をインスタンス化するべきではありませんが、オブジェクトに渡す必要があります。たとえば、内部にEngineオブジェクトがあるCarは、engine = new DieselEngine（）を実行するべきではなく、コンストラクターでエンジンを渡す必要があります。このように、車のクラスはDieselEngineクラスに結合されません。
于 2012-12-03T21:39:04.867 に答える