Composition/Aggregation law of demeter
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 9 of 9

Thread: Composition/Aggregation law of demeter

  1. #1
    Join Date
    Mar 2010
    Posts
    3

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

    }

  2. #2
    Join Date
    Dec 2009
    Posts
    109

    Re: Composition/Aggregation law of demeter

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

  3. #3
    Join Date
    Oct 2008
    Location
    Singapore
    Posts
    195

    Re: Composition/Aggregation law of demeter

    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.

  4. #4
    Join Date
    Mar 2010
    Posts
    3

    Re: Composition/Aggregation law of demeter

    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?

  5. #5
    Join Date
    Oct 2008
    Location
    Singapore
    Posts
    195

    Re: Composition/Aggregation law of demeter

    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.

  6. #6
    Join Date
    Oct 2008
    Location
    Singapore
    Posts
    195

    Re: Composition/Aggregation law of demeter

    Quote Originally Posted by DiiJAY View Post
    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.

  7. #7
    Join Date
    Mar 2010
    Posts
    3

    Re: Composition/Aggregation law of demeter

    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.

  8. #8
    Join Date
    Oct 2008
    Location
    Singapore
    Posts
    195

    Re: Composition/Aggregation law of demeter

    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.

  9. #9
    Join Date
    Apr 2007
    Location
    Florida
    Posts
    403

    Re: Composition/Aggregation law of demeter

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center