問題タブ [solid-principles]

Liskov Substitution Principle (LSP) がオブジェクト指向設計の基本原則であると聞いたことがあります。それは何であり、その使用例は何ですか?

Interface Segregation Principle (ISP) は、多くのクライアント固有のインターフェイスが 1 つの汎用インターフェイスよりも優れていると述べています。何でこれが大切ですか？

オープン/クローズの原則では、ソフトウェア エンティティ (クラス、モジュールなど) は拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります。これは何を意味し、なぜそれが優れたオブジェクト指向設計の重要な原則なのですか?

依存関係逆転の原則とは何ですか? なぜ重要なのですか?

私が書いているアプリケーションには、Policy クラスがあります。ポリシーには 4 つの異なるタイプがあります。各ポリシーは、ポリシー A > ポリシー B > ポリシー C > ポリシー D のように、他のポリシーに対して重み付けされます。

あるポリシーが別のポリシーよりも優れているかどうかを判断するロジックを実装する責任は誰にありますか? 私が最初に考えたのは、> および < 演算子をオーバーロードし、ポリシー タイプ自体にロジックを実装することです。

それはSRPに違反していますか？

情報-エキスパート、Tell-Do n't-Ask、およびSRPは、多くの場合、ベストプラクティスとして一緒に言及されます。しかし、私は彼らが対立していると思います。これが私が話していることです。

SRPを支持するが、Tell-Do n't-Ask＆Info-Expertに違反するコード：

Tell-Do n't-Ask＆Info-Expertを支持するが、SRPに違反するコード：

これらの慣行がどのように平和的に共存できるかについて私に記入してください。

用語の定義、

• Information Expert：操作に必要なデータを持つオブジェクトは、操作をホストする必要があります。

• 尋ねないように言う：仕事をするためにオブジェクトにデータを求めないでください。オブジェクトに作業を行うように指示します。

• 単一責任の原則：各オブジェクトには、狭く定義された責任が必要です。

「変更する理由が1つしかないクラス」について知っています。さて、それは正確には何ですか？クラスが単一の責任を負っていないことを示す匂い/兆候はありますか? それとも、本当の答えが YAGNI に隠され、クラスが最初に変更されたときにのみ単一の責任にリファクタリングすることができますか?

私は長い間データベースの設計に携わってきましたが、最近はC＃でも働いています。OOは私には理にかなっていますが、私はOOデザインの深い理論に十分な根拠があるとは感じていません。

データベースの世界では、データベースの構造を設計する方法について多くの理論があり、主な概念は正規化です。正規化は、データベースの構造を直接操作し、データベース内のエンティティの配置方法をある程度指示します。

オブジェクト指向プログラムの構造を設計する方法の背後にある同様の概念はありますか？

私が到達しようとしているのは、開発者を特定の問題の解決策の「正しい」設計に自然に導く1つ以上の基礎となる理論的原則です。

詳細はどこで確認できますか？
読むべき頼りになる作品はありますか？

アップデート：

回答してくれた皆さんに感謝します。私が読んでいることは、「オブジェクト指向デザインの大統一理論」は存在しないと言っているようですが、重要な原則がたくさんあります。それらは主にデザインパターンによって例示されています。

回答ありがとうございます:)

私はいくつかの個人的なプロジェクトで PHP5 から Python にゆっくりと移行しており、現在その経験が気に入っています。Python ルートをたどることを選択する前に、私は Ruby に目を向けました。Ruby コミュニティから私が気付いたのは、モンキー パッチが一般的であり、高く評価されていることです。ruby s/w のデバッグの試行に関する多くの恐ろしい話にも出くわしました。なぜなら、だれかが小さな仕事をするために比較的無害なライブラリを含めたのに、誰にも言わずに、頻繁に使用されるコア オブジェクトにパッチを当てたからです。

私が Python を選んだのは、(他の理由の中でも) 簡潔な構文と、Ruby ができるすべてのことを実行できるという事実のためです。Python は OO クリックを PHP よりもはるかに優れたものにしており、この理解を深めるために OO の原則についてますます読んでいます。

今晩、私はRobert Martin の SOLID の原則について読んでいます。

• 単一責任原則、
• オープン/クローズド原則、
• リスコフ置換原理、
• インターフェイス分離の原則、および
• 依存性逆転の原則

私は現在、O :ソフトウェアエンティティ (クラス、モジュール、機能など) は、拡張のためにオープンにする必要がありますが、変更のためにクローズする必要があります。

OO 設計の一貫性を確保することと、モンキー パッチ全体との間の対立について頭が混乱しています。Pythonでモンキーパッチを適用できることを理解しています。また、「pythonic」であることは、よくテストされた一般的な oop のベスト プラクティスと原則に従うことであることも理解しています。

私が知りたいのは、相反する 2 つのテーマに関するコミュニティの意見です。それらがどのように相互運用されるか、一方を他方よりも使用するのが最善の場合、モンキーパッチを行う必要があるかどうか...うまくいけば、問題の解決策を提供していただけます。

最近、OOP(Java)には9つのルールがあると聞きました。私が知っているのは、抽象化、ポリモーフィズム、継承、カプセル化の 4 つだけです。OOP に関するその他のルールはありますか?