6 
class Room{
  public:
    void ColorRoom(){};
};

class House{
  public:
    Room* GetRoom(){return &m_room;}
  private:
    Room m_room;
};

1) 家がなければ部屋は存在できず、家には「部屋がある」。(composition)
2) 部屋に色を付けるもう 1 つの方法は、House にメソッドを持ち、ColorRoom in Room メソッドを呼び出すことですが、これはより委任的です。（これを避けたい）

私が見る唯一の方法は上記のものですが、プライベートメンバーへの参照を返すことはOOPを壊しているようです。これは良いデザインですか？

4

6 に答える 6

5

問題は、プライベート メンバーを明示的に公開していないことです。あなたの API は部屋を取得する方法を示しているだけであり、消費者は、House がその部屋を作成しているか、private フィールドに保持されている何かを返しているか、Web サービスから部屋を取得しているかを知りません。それはしっかりした OO です。

于 2010-01-26T18:50:49.140 に答える
4

NickLarsenの答えは好きですが、追加することが1つあります。

オブジェクトのプライベートフィールドをそのオブジェクトの外部で変更させないでください。オブジェクトを変更する必要がある場合は、Room委任を使用してください。つまり、メソッドがある場合Roomは、SetFloorColor(Color _color);House

SetRoomFloorColor(Color _color){ m_room.SetFloorColor( _color ); }
于 2010-01-26T19:01:08.913 に答える
4

Houseメンバー変数をそれ自体で作成するため、全体としてm_roomは問題ありません。インスタンス化後に消費者が何かを呼び出す必要はありません。これは、アイテムがインスタンス化された直後に使用できるというパターンに従います (部屋の設定などの特別なアクションは必要ありません)。

私はいくつかのマイナーなピッキングを持っています:

class Room
{
public:
    // virtual method to allow overriding
    virtual void ColorRoom(){};
};

class House
{
public:
    // Returning a non-const pointer in C++ is typically a bad smell.
    const Room& Room() const { return m_room; }
    // Allow for assignment and manipulating room, but breaks const-ness
    Room& Room() { return m_room; }
    // Facade method for houses with more than one room
    // You can forward parameters or come up with room-painting schemes, but you should
    // not require that a House has a Room called Room().
    virtual void ColorAllRooms()
    {
        m_room.ColorRoom();
    }
private:
    Room m_room;
};
于 2010-01-26T18:47:00.787 に答える
2

私はNickLarsenの答えが好きですが、もう1つ指摘したいのは、部屋自体は色付け（または塗装）されないということです。そのアクションは通常、ルームのメンバーではない Painter によって行われます。今では、画家は家全体に色を塗ることも、画家が 1 つの部屋だけで作業することもできます。

この場合、部屋には色のプロパティがあり、その色を変更する行為は別のオブジェクトによって外部で処理されることをお勧めします。

この考えは、Color プロパティがパブリック プロパティである必要があり、変更する部屋への参照を Painter オブジェクトに渡すことを示唆しています。

于 2010-01-26T19:11:53.570 に答える
2

操作は家ではなく部屋で行われます。家を介して部屋への不変の参照を返すことができ、それを操作できる場合は、OOP を壊していません。

于 2010-01-26T18:47:51.440 に答える
0

プライベート メンバーを公開すると、結束が低下し、結合が増加します。一般に、次のようなコードは避ける必要があります。

selection.getRecorder().getLocation().getTimeZone();

このコードは保守性が低く、デメテルの法則に違反しています。

于 2010-01-27T14:10:45.760 に答える