Does pure composition differ in OOP concepts?

Question

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

1) A room cannot exist without a house; there is a room in the house. (Composition)
2) Another way to color a room is to have a method in the House that will refer to the ColorRoom in Room method, but then it's more like delegation. (I want to avoid this)

The only way I see is above, but it seems like returning the link to a private member violates OOP. Is this a good design?

Answer 1

In general, you are good, because House itself creates the member variable m_room - the user does not need to call something after creating the instance. This follows that the element can be used immediately after creating the instance (it does not require special actions, such as setting up a room or something else).

I have some minor nit collections:

 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; }; 

Answer 2

The fact is that you obviously do not open your private member. Your API simply shows a method to get a room, and the consumer does not know if House creates this room by returning something in a private field or receiving a room from a web service. This is solid OO.

Answer 3

I like NickLarsen, but I need to add:

Do not allow the private field of an object to be modified outside this object. If you must change the delegation of the use of the Room object. That is, if Room has a SetFloorColor(Color _color); method SetFloorColor(Color _color); then you must place a call in House

 SetRoomFloorColor(Color _color){ m_room.SetFloorColor( _color ); } 

Answer 4

The operation takes place in a room, not in a house. If you can return an invariable link to a room through a house that can then work, you do not violate OOP.

Answer 5

Although I like to answer NickLarsen, I would like to point out one more thing: the rooms do not paint (or paint) themselves. This action is usually performed by an artist who obviously does not enter the room. Now the artist could paint the whole house, or the artist could work only in one room.

I would assume in this case that the room has a color property, and the act of changing this color is handled by an external object by another object.

This idea assumes that the Color property should be publicly available and that you will pass a link to the room that will be changed to the Painter object.

Answer 6

Providing private members eliminates cohesion and enhances communication. As a rule, you should prohibit this code:

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

This code is less maintainable and violates the Law of Demeter .