13c Low Coupling

3,973 views
3,758 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,973
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
74
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

13c Low Coupling

  1. 1. TK2023 Object-Oriented Software Engineering CHAPTER 13c GRASP Patterns: Low Coupling
  2. 2. GRASP PATTERNS: LOW COUPLING <ul><li>Problem </li></ul><ul><li>How to support low dependency, low change impact, and increased reuse? </li></ul>
  3. 3. <ul><li>Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. These elements include classes, subsystems, systems and so on. </li></ul><ul><li>A class with high coupling relies on many other classes. Highly coupled classes suffer the following problems: </li></ul><ul><ul><li>Forced local changes because of changes in related classes </li></ul></ul><ul><ul><li>Harder to understand in isolation </li></ul></ul><ul><ul><li>Harder to reuse because its use requires the additional presence of its dependants. </li></ul></ul>
  4. 4. <ul><li>Solution </li></ul><ul><li>Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives. </li></ul>
  5. 5. EXAMPLE OF APPLICATION <ul><li>This example shows how two patterns may suggest different solutions. </li></ul><ul><li>In the POS application, when the Cashier enters a payment, a Payment object needs to be created and associated with the current Sale. </li></ul><ul><ul><ul><li>Who should be responsible for creating a Payment instance and associate it with Sale? </li></ul></ul></ul>
  6. 6. <ul><li>In the real-world domain, </li></ul><ul><ul><ul><li>a Register “records” a Payment </li></ul></ul></ul><ul><li>According to the Creator pattern, Register is a candidate class for that responsibility. </li></ul>DESIGN A : Register p : Payment : Sale 1. makePayment( ) 1.1. Payment( ) 1.2. addPayment( p ) {new}
  7. 7. <ul><li>Since the Payment object will eventually be linked to the Sale object, why not assign the responsibility to Sale? </li></ul>DESIGN B Note that applying the Information Expert pattern also results in this design. : Register : Payment : Sale 1. makePayment( ) 1.1. makePayment( ) 1.1.1. Payment( ) {new}
  8. 8. <ul><li>Which design supports low coupling? </li></ul>DESIGN A Register Payment Sale DESIGN B Register Payment Sale
  9. 9. <ul><li>Based only on the “coupling” factor, we prefer Design B as it maintains overall lower coupling. </li></ul><ul><li>We need to remember that when evaluating different designs, we should not just consider one factor (e.g. degree of coupling) in isolation. We need to consider other principles as well such as Information Expert and High Cohesion . </li></ul>
  10. 10. DISCUSSION <ul><li>Low Coupling is an evaluative principle that is applied while evaluating design decisions. </li></ul><ul><li>Common forms of coupling from TypeX to TypeY include: </li></ul><ul><ul><li>TypeX has an attribute that refers to a TypeY object. </li></ul></ul><ul><ul><ul><ul><li>class Car { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>private Person owner; </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul><ul><ul><li>A TypeX object calls on services of a TypeY object. </li></ul></ul><ul><ul><ul><ul><li>class Application { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>public void start() { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>(new Game ()).initialize(); </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul>
  11. 11. DISCUSSION <ul><ul><li>TypeX has a method that references a TypeY object. For example, as a parameter or local variable or the object returned from a message sent to a TypeY object. </li></ul></ul><ul><ul><ul><ul><li>class Game { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul><ul><ul><ul><ul><li>public void addPlayer( Person p) { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul><ul><ul><li>TypeX is a direct or indirect subclass of TypeY. </li></ul></ul><ul><ul><ul><ul><li>class MyApplet extends JApplet { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul>
  12. 12. DISCUSSION <ul><ul><li>TypeY is an interface, and TypeX implements that interface. </li></ul></ul><ul><ul><ul><ul><li>class Game extends JApplet implements ActionListener { </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul><ul><ul><ul><ul><li>} </li></ul></ul></ul></ul>
  13. 13. <ul><li>Low coupling supports the design of classes that are more independent, which reduces the impact of change. </li></ul><ul><li>Inheritance is a strong form of coupling. Any decision to create an inheritance relationship between two classes should be considered carefully. </li></ul><ul><li>Is no coupling between classes a good thing? </li></ul><ul><ul><li>An object-oriented system is a system of collaborating objects. Some moderate degree of coupling between classes is normal and necessary . </li></ul></ul>
  14. 14. CONTRAINDICATIONS <ul><li>High coupling to stable elements and to pervasive elements is seldom a problem. For example, a Java application can safely couple itself to the Java libraries because they are stable and widespread. </li></ul>
  15. 15. BENEFITS <ul><li>Low Coupling has the following benefits. Lowly coupled classes are </li></ul><ul><ul><li>less affected by changes in other components </li></ul></ul><ul><ul><li>simple to understand in isolation </li></ul></ul><ul><ul><li>convenient to reuse </li></ul></ul>

×