23 Design Patterns-Understanding the differences between dependencies, associations, aggregations, and combinations _ design Patterns

When learning object-oriented Design object relationships, the distinction between dependencies, associations, aggregations, and combinations of these four relationships is easy to confuse. In particular, the latter three, only in the semantic difference, the so-called semantics refers to the context of the environment, specific scenarios and so on. They are basically the same in the programming language, but basically the same doesn't mean exactly the same, which is already mentioned in my previous post, "class relationships in design patterns," and here's a detailed discussion of how to accurately embody dependencies, associations, aggregations, and combinations in Java.

First look at a book. Definitions of these four relationships: dependent (Dependency) relationships are joins between classes and classes. A dependency represents a class that relies on the definition of another class. For example, a person can buy a car and a house, and the People class relies on the definition of the cars class and the home class, because the man class refers to both the vehicle and houses. Unlike associations, the person class does not have the car and house type properties, and the instance of the car and house is passed to the Buy () method in parametric fashion. In general, a dependency is embodied in the Java language as a local variable, a formal parameter of a method, or a call to a static method. An association (association) relationship is a join between a class and a class, which enables a class to know the properties and methods of another class. The association can be bidirectional or one-way.  In the Java language, association relationships are typically implemented using member variables. The aggregation (Aggregation) relationship is a kind of association relation, and it is a strong association relation. Aggregation is the relationship between the whole and the individual. For example, the relationship between automobile and engine, tyre, and other parts is the whole and individual relationship. As with association relationships, aggregation relationships are also implemented through instance variables.  However, the two classes involved in the association relationship are at the same level, while in the aggregation relationship, two classes are at the unequal level, one represents the whole and the other represents the part. The combination (composition) relationship is a kind of relation, which is stronger than the relationship of aggregation. It requires that an object representing the whole in a common aggregation relationship is responsible for representing the life cycle of a part of the object, and that the composite relationship cannot be shared. The objects representing the whole need to be responsible for maintaining part of the object and surviving, and in some cases the objects responsible for the representative part are annihilated. An object representing a whole can pass an object representing a part to another object, which is responsible for the life cycle of the object. In other words, the object representing a part can only be grouped with one object at a time, and the latter is solely responsible for the lifecycle. Part is the same as the life cycle of the whole.

--Excerpt from Java object-oriented programming, Author: Sun Weichen

The coupling degree of the above relationship is enhanced in turn (the concept of coupling degree will be discussed later, which can be understood for the time being that when a class changes, the degree of influence on other classes is smaller, the less the coupling degree is, the stronger the coupling degree is). By definition we already know that dependency is actually a relatively weak association, aggregation is a relatively strong association, and the combination is a stronger association, so the general to distinguish between, in fact, the four kinds of relationship, are related.

        dependency is a good distinction, it is the weakest coupling, in Java as a local variable, the formal parameters of the method, or the call to static methods, As in the following example: The driver class relies on the car class, and the driver three methods demonstrate the three different forms of dependency relationships. [java]  View Plain Copy class car {       public static void  run () {           system.out.println ("car in the Run");        }  }      class driver {        //dependency relationship using formal parameters        public void drive1 (car car) {           car.run ();       }        //dependency relationships using local variables        public void  Drive2 () {           car car = new car ();            car.run ();        }       //dependency relationships using static variables         public void drive3 () {           car.run ();       }  }  

        Association relationships are typically implemented in Java using member variables, sometimes in the form of method parameters. Still using the example of driver and car, the method parameter form can be used to represent dependencies, or to indicate association relationships, after all, we cannot express semantics too accurately in the program. In this case, the member variable is used to express this meaning: The car is my own car, I "own" the car. Use method parameter expression: The car is not mine, I am just a driver, I will drive a car, I use this car.
[java]  View Plain copy class driver {       //use a member variable form to implement the association         Car mycar;       public void drive () {           mycar.run ();       }        ...       //using method Parameter form to implement association         public void drive (car car) {            car.run ();       }  }  

The aggregation relation is a kind of strong association relation, in Java generally uses the member variable form to realize. There is a whole and part relationship between objects.       For example, in the example [Java] View plain copy class Driver {//The aggregation relationship is implemented using the form of a member variable car mycar;       public void Drive () {Mycar.run (); }   }

If the code above is given the following semantics: The car is a private vehicle and is part of the driver's property. The same code represents the aggregation relationship. Aggregation relationships generally use setter methods to assign values to member variables.

If given the following semantics: The car is the driver's necessary property, to be a driver must first have a car, if the car is gone, the driver does not want to live. And if the driver does not do the driver, the car will be smashed, no one else to use. That means a combination of relationships.    In general, in order to represent a combinatorial relationship, a construction method is often used to achieve the purpose of initialization, such as in the example above, plus a construction method with the car as a parameter [Java] view plain copy public Driver the "." "{Mycar." }

        So, association, aggregation, combination can only match semantics, combined up and down wisdom can be judged, and only give a piece of code to let us Judge is association, aggregation, or combination of relations, is impossible to judge.