LOW COUPLING – HIGH COHESION LOW COUPLING Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support: Lower dependency between the classes, Change in one class having lower impact on other classes, Higher reuse potential. Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies upon other elements. An element with Low Coupling is not dependent upon too many other elements. But how many is too many? High coupling is not really the problem; it is high coupling to potentially unstable (likely to be changed) objects. Problems with high coupling Forced local changes because of changes in related classes Harder to understand in isolation Harder to reuse because it requires other classes Assign responsibility so coupling remains low This reduces the impact of change NextGen example If we need to create a Payment instance and associate it with Sale, who should do it? Since Register records a payment, the Creator pattern suggests it On the other hand, Sale could create Payment and that would not increase the coupling In practice, level of coupling alone is not sufficient Forms of Coupling X has an attribute of type Y A type X object calls on services in Y X has a method that references an instance of Y X is a direct or indirect subclass of Y Y is an interface that X implements HIGH COHESION High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and averse to change.