달력

082017  이전 다음

  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
 

    Aggregation은 전체와 부분의 연관 관계를 맺지만, 그러나 동일한 생명 주기를 갖지는 않는다.
    ( 'Person' 과 'Address' 의 관계 )
    ( '역사과목' 과 '학생' 의 관계 )

    Composition은 전체와 부분이 강력한 연관 관계를 맺으며, 전체와 부분이 같은 생명 주기를 갖는다.
    ( 'Car' 와 'Engine' 의 관계 )
    ( 'House' 와 'Room' 의 관계 )


    밑에 글은 출처를 까먹었음.

     

    Introduction:

    Apart from programming, a lot of my spare time sat at the computer is spent reading group, blog postings, etc from other developers. One particular posting that caught my eye recently provoked a lot of response and mixed answers to a question posed by a poster. This question was, 'What is the difference between composition and aggregation and how would I express it in my programs'?

    Reading the responses to the post, I had a mixed reaction, many of the responses reflected my understanding of the difference, others turned my understanding right around and explained composition as my understanding of aggregation.

    This short article will put forward my understanding of composition and aggregation and how I would express it in C# code.

     

     

    Composition:

    As we know, inheritance gives us an 'is-a' relationship. To make the understanding of composition easier, we can say that composition gives us a 'part-of' relationship. Composition is shown on a UML diagram as a filled diamond (see Figure 1).




    If we were going to model a car, it would make sense to say that an engine is part-of a car. Within composition, the lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed along with it. So how do we express this in C#?

    public class Engine

    {

     . . . 

    }

    public class Car

    {

        Engine e = new Engine();

        .......

    }

    As you can see in the example code above, Car manages the lifetime of Engine.

     

     

    Aggregation:

    If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example. For the past 12+ months I have been involved with the implementation of a CRM system, so I am going to use part of this as an example.

    The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond (see Figure 2). 




    So how do we express the concept of aggregation in C#? Well, it's a little different to composition. Consider the following code:

    public class Address

    {

     . . .

    }

    public class Person

    {

         private Address address;

         public Person(Address address)

         {

             this.address = address;

         }

         . . .

    }

    Person would then be used as follows:

    Address address = new Address();

    Person person = new Person(address);

    or

    Person person = new Person( new Address() );

    As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario does map quite nicely to the real world.

     

     

    Conclusion:

    As I said at the beginning of the article, this is my take on composition and aggregation. Making the decision on whether to use composition or aggregation should not be a tricky. When object modelling, it should be a matter of saying is this 'part-of' or does it 'have-a'?

      

     

     Other Explain..

     

    Aggregation vs. Composition

    Byadmin on Mar 21, 2008 | In Design ConceptsOO Concepts

     

    So many times I am asked by developers what the difference is between Aggregation and Composition. I will try and explain the difference in the following section by making use of examples and UML diagrams. Aggregation and Composition are both types of associations between objects.

    Aggregation

    Aggregation is a kind of association that specifies a whole/part relationship between the aggregate (whole) and component part. This relationship between the aggregate and component is a weak “has a” relationship as the component may survive the aggregate object. The component object may be accessed through other objects without going through the aggregate object. The aggregate object does not take part in the lifecycle of the component object, meaning the component object may outlive the aggregate object. The state of the component object still forms part of the aggregate object.

    An example of aggregation is a History-Class object contains zero or more of Student objects. The state of each Student object has an influence on the state of the History-Class object. If the History-Class object is destroyed, the Student objects may continue to exist.


     

    The UML diagram above illustrates the aggregation association line with an open diamond on the aggregate side.

     

     

    Composition

    Composition is a kind of association very similar to aggregation except where the composite object has sole responsibility for the disposition of the component parts. The relationship between the composite and the component is a strong “has a” relationship, as the composite object takes ownership of the component. This means the composite is responsible for the creation and destruction of the component parts. An object may only be part of one composite. If the composite object is destroyed, all the component parts must be destroyed, or the reference and responsibility of the component part must be handed over to another object. Composition enforces encapsulation as the component parts usually are members of the composite object.

    An example of composition is a House object contains zero or more Room objects. The state of each Room object has an influence on the House object. If the House object is destroyed, the Room objects will also be destroyed.



    The UML diagram above illustrates the composition association line with a solid diamond on the composite side.

     


신고
Posted by 아티스트 쑨 쑨~

티스토리 툴바