タグ付けされた質問 「solid」

私はより良く、よりクリーンなコードを書くために、SOLIDの原則について学んでいます。この点で、LSPは適切に把握するのが少し難しいことがわかっています。 私の疑問は、サブタイプSに余分なメソッドがあり、タイプTになかった場合、これは常にLSPの違反になるのでしょうか？はいの場合、どのようにextend私のクラスを行うのですか？ たとえば、Birdタイプがあるとしましょう。そして、そのサブタイプはEagleおよびHumming Birdです。現在、両方のサブタイプには、としていくつかの共通の動作がありBirdます。しかし、Eagle（一般的なBirdタイプには存在しない）優れた略奪行動もあるので、それを使用したい。したがって、今はこれを行うことができません： Bird bird = new Eagle(); それで、Eagleそれらの追加の振る舞いを与えることはLSPを壊していますか？ はいの場合、それはLSP違反を引き起こすため、クラスを拡張できないことを意味しますか？ class Eagle extends Bird { //we are extending Bird since Eagle has some extra behavior also } クラスの拡張は、Open / Closed原則に従って許可する必要がありますか？ よろしくお願いします！はっきりとわかるように、LSPは私を他のものと同じように混乱させています。 編集：このSOの回答を参照してください。この場合Carも、のような追加の動作がある場合ChangeGear、LSPに違反します。では、LSPに違反せずにクラスを拡張するにはどうすればよいでしょうか。

8 solid  liskov-substitution  open-closed-principle 

この質問は数日間私を悩ませてきました、そしてそれはいくつかの実践が互いに矛盾しているように感じます。 例 反復1 public class FooDao : IFooDao { private IFooConnection fooConnection; private IBarConnection barConnection; public FooDao(IFooConnection fooConnection, IBarConnection barConnection) { this.fooConnection = fooConnection; this.barConnection = barConnection; } public Foo GetFoo(int id) { Foo foo = fooConection.get(id); Bar bar = barConnection.get(foo); foo.bar = bar; return foo; } } これをテストするとき、IFooConnectionとIBarConnectionを偽造し、FooDaoをインスタンス化するときに依存性注入（DI）を使用します。 機能を変更せずに実装を変更できます。 …

8 c#  unit-testing  api-design  dependency-injection  solid 

私たちが知っているように、SRPはすべてのクラスが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されなければならないことを述べています。 しかし、セッターとゲッターは別の責任を果たします -それらは抽象クラスのプロパティ（データ）アクセスを行います。 場合セッターとゲッターは、抽象クラスのプロパティへのアクセスを行う、その後、彼らは別の責任を果たす行います。 だから私がこのようなものを持っているなら、 class Config { private location; public function write(array $data) { .... } public function read($key) { ... } public function exists($key) { ... } public function delete($key) { ... } // Below comes property abstraction // Here I doubt - I CANNOT USE this class …

8 solid  single-responsibility