http://javaboutique.internet.com/tutorials/coupcoh/
by Samudra Gupta
Object-oriented programming has two main objectives: to build highly cohesive classes and to maintain loose coupling between those classes. High-cohesion means well-structured classes and loose coupling means more flexible, extensible software. Applying object-oriented metrics to your design and code can help you determine whether you've achieved these goals.
What is Cohesion?
In OO methodology, classes contain certain data and exhibit certain behaviours. This concept may seem fairly obvious, but in practice, creating well-defined and cohesive classes can be tricky. Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. Though lack of cohesion may never have an impact on the overall functionality of a particular class—or of the application itself—the application software will eventually become unmanageable as more and more behaviours become scattered and end up in wrong places.
Thus, one of the main goals of OO design is to come up with classes that are highly cohesive. Luckily, there's a metric to help youverify that you've designed a cohesive class.
The LCOM Metric: Lack of Cohesion in Methods
The Lack of Cohesion in Methods metric is available in the following three formats:
LCOM1: Take each pair of methods in the class and determine the set of fields they each access. If they have disjointed sets of field accesses, the count P increases by one. If they share at least one field access, Q increases by one. After considering each pair of methods:
RESULT = (P > Q) ? (P - Q) : 0
A low value indicates high coupling between methods. This also indicates potentially high reusability and good class design. Chidamber and Kemerer provided the definition of this metric in 1993.
LCOM2: This is an improved version of LCOM1. Say you define the following items in a class:
m: number of methods in a class
a: number of attributes in a class.
mA: number of methods that access the attribute a.
sum(mA): sum of all mA over all the attributes in the class.
LCOM2 = 1- sum(mA)/(m*a)
If the number of methods or variables in a class is zero (0), LCOM2 is undefined as displayed as zero (0).
LCOM3: This is another improvement on LCOM1 and LCOM2 and is proposed by Henderson-Sellers. It is defined as follows:
LCOM3 = (m - sum(mA)/a) / (m-1)
where m, a, mA, sum(mA) are as defined in LCOM2.
The following points should be noted about LCOM3:
The LCOM3 value varies between 0 and 2. LCOM3>1 indicates lack of cohesion and is considered a kind of alarm.
If there is only one method in a class, LCOM 3 is undefined and also if there are no attributes in a class LCOM3 is also undefined and displayed as zero (0).
Each of these different measures of LCOM has a unique way to calculate the value of LCOM.
An extreme lack of cohesion such as LCOM3>1 indicates that the particular class should be split into two or more classes.
If all the member attributes of a class are only accessed outside of the class and never accessed within the class, LCOM3 will show a high-value.
A slightly high value of LCOM means that you can improve the design by either splitting the classes or re-arranging certain methods within a set of classes.
A Concrete Example
Listing 1 defines an Order class to which you can apply the LCOM metrics. Figure 1 displays a high-level UML model of an imaginary Order Processing system.
Figure 1: This shows a UML class diagram for an Order Processing Sytem.
Note: The example UML diagram and the source code below is just an example and present a very much rough code sample. Please do not try to reuse this class for any real project.
To apply the LCOM3 metric to the Order class, define the metric variables as follows:
m(number of methods in the class) = 4
a(number of attributes in the class)=5
m[prod] = number of methods accessing the attribute prod = 3
m[orderNumber] = number of methods accessing the attribute orderNumber= 2
m[totalAmount] = number of methods accessing the attribute totalAmount = 4
m[deliveryType] = number of methods accessing the attribute deliveryType = 2
m[underPromotion] =number of methods accessing the attribute underPromotion=3
Therefore:
LCOM3 = ( m - sum(mA)/a ) / (m - 1)
= ( 4 - 14/5 ) / (4-1)
= 0.73
Remember to also count the constructor as a method of the class in this calculation.
The LCOM analysis on the Order class revealed that it had a reasonably high level of non-cohesiveness. Although, it is not "alarming" (as values >1 would be alarming according to LCOM3), you would be wise to improve its design.
A little inspection of all the methods in the class will immediately reveal that the method checkIfProductExists() is not a good fit for this class. The Order class must encapsulate the behaviours that an Order will need to exhibit. Basically, assume that when an instance of Order is created, the product within it is a valid and existing product. The responsibility of assigning a valid product to the Order object is better placed as part of the OrderManager class.
After removing the checkIfProductExists() method from the Order class, recalculate the value of LCOM3:
m(number of methods in the class) = 3
a(number of attributes in the class)=5
Therefore:
LCOM3 = ( m - sum(mA)/a ) / (m - 1)
= ( 3 - 13/5 ) / (3-1) ***Note: sum(mA) is now reduced by one.
= .20
This class is now more cohesive, with an LCOM value of 0.20—compared to the previous value of 0.73. That simple change made a world of difference in peace of mind.
Measuring Coupling
Coupling is a word that's usually used in a derogatory manner in design review meetings. Even so, it's not possible to design a functional OO application without coupling. Whenever one object interacts with another object, that is a coupling. In reality, what you need to try to minimise is coupling factors. Strong coupling means that one object is strongly coupled with the implementation details of another object. Strong coupling is discouraged because it results in less flexible, less scalable application software. However, coupling can be used so that it enables objects to talk to each other while also preserving the scalability and flexibility.
Though this seems like a difficult task, OO metrics can help you to measure the right level of coupling.
Coupling Between Objects (CBO): CBO is defined as the number of non-inherited classes associated with the target class. It is counted as the number of types that are used in attributes, parameters, return types, throws clauses, etc. Primitive types and system types (e.g. java.lang.*) are not counted.
Data Abstraction Coupling (DAC): DAC is defined as the total number of referred types in attribute declarations. Primitive types, system types, and types inherited from the super classes are not counted.
Method Invocation Coupling (MIC): MIC is defined as the relative number of classes that receive messages from a particular class.
MIC = nMIC / (N -1 )
Where N = total number of classes defined within the project.
nMIC = total number of classes that receive a message from the target class.
Demeter's Law
Ian Hollaand first proposed the Law of Demeter. The class form of Demeter's Law has two versions: a strict version and a minimization version. The strict form of the law states that every supplier class of a method must be a preferred supplier. The minimization form is more permissive than the first version and requires only minimizing the number of acquaintance classes of each method.
Definition 1 (Client): Method M is a client of method f attached to class C, if inside M message f is sent to an object of class C, or to C. If f is specialized in one or more subclasses, then M is only a client of f attached to the highest class in the hierarchy. Method M is a client of some method attached to C.In Listing 1, the constructor of the Order class is a client to the Product class because it calls the getPrice() method of the Product class.
Definition 2 (Supplier): If M is a client of class C then C is a supplier to M. In other words, a supplier class to a method is a class whose methods are called in the method. In Listing 1, the Product class is a supplier class to the client class Order.
Definition 3 (Acquaintance Class): A class C1 is an acquaintance class of method M attached to class C2, if C1 is a supplier to M and C1 is not one of the following:
The same as C2;
A class used in the declaration of an argument of M
A class used in the declaration of an instance variable of C2
In Listing 1, Product is an acquaintance class of the Order class, because Product is declared as an instance variable of the Order class and also passed as an argument to the constructor.
Definition 4 (Preferred-supplier class): Class B is called a preferred-supplier to method M (attached to class C) if B is a supplier to M and one of the following conditions holds:
B is used in the declaration of an instance variable of C
B is used in the declaration of an argument of M, including C and its superclasses
B is a preferred acquaintance class of M.
In Figure 1, the OrderLine, Order class is a preferred supplier class to the OrderManager class as they are used as instance variables inside the OrderManager class.
A Concrete Example
In the imaginary Order Processing example, imagine you've got the following form of code in the OrderManager class.
Class OrderManager {
Private Order order;
public void getOrderByCustomer() {
int productPrice = order.prod.price
}
You can see that the Product class becomes a supplier to the OrderManager class. This is not allowed according to the strict form of Demeter law because Product is not a preferred supplier to the OrderManager class.
Try the following:
Class OrderManager {
Private Order order;
public void getOrderByCustomer() {
int productPrice = order.getProductPrice();
}
Note that the above code makes the assumption that OrderManager will deal with only one Order at one time and also that one Order can have only one Product.
In the modified code, the client OrderManager class does not need to know how the object model is between Order and Product. Also, you never used or initialised the Product class within the OrderManager class. Having to reference to the Product class indirectly to get the price is a violation of Demeter Law.
Figure 2 presents a corrected UML diagram with all the changes that have been made so far.
Figure 2: The corrected UML diagram.
What It All Adds Up To
All these coupling metrics really serve the same function: to reduce dependencies between several classes. The less dependency, the better the chance of a more flexible solution. But in OO programming, coupling is unavoidable. Therefore, the goal is to reduce unnecessary dependencies and make necessary dependencies coherent. In this article's example, the OrderManager class is still coupled to the OrderLine and Order classes, but its unnecessary coupling with the Product class has been eliminated.
Make no mistake, these metrics are vital to measuring the quality of an application.
No comments:
Post a Comment