纯粹的构图是否破坏了OOP概念?

Fra*_* Q. 6 oop composition

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

class House{
  public:
    Room* GetRoom(){return &m_room;}
  private:
    Room m_room;
};
Run Code Online (Sandbox Code Playgroud)

1)房间不能没有房子,房子"有"房间.(组成)
2)色彩空间的另一种方法是在House中有一个方法,它可以在Room方法中调用ColorRoom但是这更像是委托.(我想避免这种情况)

我看到的唯一方法是上面的那个,但看起来像返回对私有成员的引用正在破坏OOP.这是一个很好的设计吗?

Jay*_*Jay 5

问题是你没有明确地暴露你的私人成员.您的API只显示获取房间的方法,而消费者不知道House是否正在创建该房间,返回私人字段中保存的内容,或者从Web服务获取房间.这是坚实的OO.

  • 这非常重要,但请注意,允许外部力量修改对象状态而不进行验证通常是不好的设计. (2认同)

Tra*_*kel 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;
};
Run Code Online (Sandbox Code Playgroud)