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

オブジェクトが物理的に存在するかどうかに関係なく、さまざまな方法でモデリングすることができます。多くの場合、一般化または合成を任意に使用できます。ただし、「一般化よりも構成を優先する」というGoFの原則により、構成を使用するようにガイドされます。したがって、たとえばラインをモデル化する場合、Point（一般化）を拡張する代わりに、タイプPoint（構成）の2つのメンバーPointAおよびPointBを含むクラスを作成します。これは、オブジェクトが通常ははるかに複雑であるにもかかわらず、モデル化するための構成または継承を任意に選択できる方法の単純化された例にすぎません。 これが正しい選択であることをどのように知ることができますか？少なくとも、それが間違っている場合に実行すべき大量のリファクタリングが存在する可能性があるため、問題になりますか？

9 object-oriented  inheritance  composition  class-design 

この質問では、Decoratorパターンを使用して、大きなクラスのオブジェクトにほとんど機能を追加しないようにしています。 古典的なDecoratorパターンに従って、次のクラス構造を検討してください： たとえば、これがゲーム内で発生するとします。のインスタンスは、「ラッピング」しているConcreteCharacterDecorator機能に小さな機能を追加するためConcreteCharacterのものです。 たとえば、キャラクターが敵に与えるダメージを表す値をmethodA()返しますint。ConcreteCharacterDecorator単純にこの値に追加されます。したがって、必要なのはコードをに追加することだけmethodA()です。の機能はmethodB()変わりません。 ConcreteCharacterDecorator このようになります： class ConcreteCharacterDecorator extends AbstractCharacterDecorator{ ConcreteCharacter character; public ConcreteCharacterDecorator(ConcreteCharacter character){ this.character = character; } public int methodA(){ return 10 + character.methodA(); } public int methodB(){ character.methodB(); // simply delegate to the wrapped object. } } これは、2つのメソッドを含む小さなクラスでは問題ありません。 しかし、AbstractCharacter15のメソッドを定義するとどうなるでしょうか。 ConcreteCharacterDecorator少しの機能を追加することだけを目的としていますが、すべてを実装する必要があります。 少し機能を追加する1つのメソッドと、単純に内部オブジェクトに委譲する別の14のメソッドを含むクラスになります。 次のようになります。 class ConcreteCharacterDecorator extends AbstractCharacterDecorator{ ConcreteCharacter …

8 design-patterns  clean-code  composition