Composition/Aggregation law of demeter

Hi,

I have question regarding architecture when dealing with composition/aggregation hierarchy. The three classes below "House", "Room" and "Door" describes a simple nested architecture used for this question. This architecture means that when I use a House object and want to refer to a door nested in a Room I will brake the "Law of demeter" rule that states that I should only use direct connection like House.ToString() not indirect connection like House.Room.Door.ToString(), is this okay or bad practise, is there any better way of organising the architecture?



Would it be better to do helper functions for the door in the Room Class, and not expose a Door object public, like:

DoorOpen();

DoorClose();



If this arhitecture is prefered, what should be done with the events inside the Door class, should they also be defined once again in the Room class and be "chained" back thru it's parent classes some way ?





Any thoughts, tips and ideas would be helpful.




public class House
{

public House()
{
Room = new Room();
}

public Room Room { get; private set; }

}


public class Room
{

public Room()
{
Door = new Door();
}

public Door Door { get; private set; }

}


public class Door
{

public event EventHandler<EventArgs> OnOpen;
public event EventHandler<EventArgs> OnClose;
private bool _isOpen;

public Door()
{
}

public void Open()
{
_isOpen = true;
OnOpen(this, new EventArgs());
}

public void Close()
{
_isOpen = false;
OnClose(this, new EventArgs());
}

}

May I ask what is it that you are creating here? It sounds VERY interesting!

You should include only those domain objects that have behavior. From your example, it looks like Room class does not have a behavior of its own. See, whether you can eliminate it.

Also, if Room object needs to access the string representation of Door to do something, see whether it can delegate that 'something' to Door object instead. The golden rule of OOPS is the object who has the information (data) defines the behavior based on that data.

Hi,

Dragster93: I'm not creating anything of this, it's just an example.

rohshall: In this simple example I have only included the implemenatation of the classes I founded needed to explain the situation. In a normal case, both Room and Door would have more member data and methods, that are bound to a "Room" and a "Door".

"The golden rule of OOPS is the object who has the information (data) defines the behavior based on that data. " Does this mean that if I have more releveant data for a door in the "Door" class I should leave it as it is and use House.Room.Door.ToString() as an example ?


More suggestions about this?

I suggest you don't worry about data first.
Just elaborate your problem statement about what exactly you want to be done.
Then encapsulate 'behavior' into logical classes. The data is just a state needed by the objects to implement that behavior. You can think of each object as a FSM with its data as its 'state'.

The problem I see is if you finalize the class design based on 'common sense', then it may turn out to be unnecessarily complex.

Quote:

---

Originally Posted by DiiJAY

Does this mean that if I have more releveant data for a door in the "Door" class I should leave it as it is and use House.Room.Door.ToString() as an example ?

---

To elaborate on this particular example, I suspect your program logic is in House object and all the rest are more or less wrapper over a struct like data aggregate. Program should work by objects passing messages to each other without knowing internals of others. Here, House seems to know a lot about Room object (that it has Doors) which is bad.

But I See two obvious path to deal with composition aggregation. This is just an example in normal cases Motherboard and Cpu would have more methods and properties.

either you do:
Computer.Motherboard.Cpu.Temperature();


or you make Motherboard and Cpu private in the Computer class and not visible outside a computer. This means that Computer make wrappers for methods/properties/events and deal with the "client" (calling object) interaction with Motherboard and Cpu, like:

Computer.GetCpuTemperate();



The first example seams to break, Law of demeter.
The second exmaple seems to make coupling between Computer, Motherboard and Cpu stricter/harder, but this is maybe not an design issue.

You have brought up a good point. It's an interesting example.

Is the client object a UI or a domain object?
If it is a domain object, how it is using the temperature value?

It's difficult to give any suggestion without knowing details of your requirements.
And as you said, maybe what you are doing is right for this application.

Reposting the original code from the original post.. I was going crazy trying to read it without code tags...

Code:

---

public class House
{

    public House()
    {
        Room = new Room();
    }

    public Room Room { get; private set; }

}


public class Room
{

    public Room()
    {
        Door = new Door();
    }

    public Door Door { get; private set; }

}


public class Door
{

    public event EventHandler<EventArgs> OnOpen;
    public event EventHandler<EventArgs> OnClose;
    private bool _isOpen;

    public Door()
    {
    }

    public void Open()
    {
        _isOpen = true;
        OnOpen(this, new EventArgs());
    }

    public void Close()
    {
        _isOpen = false;
        OnClose(this, new EventArgs());
    }

}

---