CSC/ECE 517 Summer 2008/wiki3 3 lc: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 32: Line 32:
==Benefits of Low Coupling==
==Benefits of Low Coupling==


===Reduced Coding===
===Reduced Code===
[[Image:highcoupling.jpg|thumb|right|150px|Figure 2: High Coupling]]
[[Image:highcoupling.jpg|thumb|right|150px|Figure 2: High Coupling]]
[[Image:lowcoupling.jpg|thumb|right|150px|Figure 3: Low Coupling]]
[[Image:lowcoupling.jpg|thumb|right|150px|Figure 3: Low Coupling]]
Line 39: Line 39:
===Reduced YoYo Affect===
===Reduced YoYo Affect===


===Easier Testing===
===Better Testing===


By lowering coupling a module may be tested without including a multitude of other classes or modules.  By making testing easier programmers are more likely to thoroughly test code and less bugs will reside in the final version of the code.
By lowering coupling a module may be tested without including a multitude of other classes or modules.  By making testing easier programmers are more likely to thoroughly test code and less bugs will reside in the final version of the code.


===Higher Encapsulation===
===Better Encapsulation===
Anytime you can hide the design details of your program so that other modules and services may utilize a standard rarely changing interface your program will be less likely to break other modules as a result of design detail modifications.
Anytime you can hide the design details of your program so that other modules and services may utilize a standard rarely changing interface your program will be less likely to break other modules as a result of design detail modifications.



Revision as of 02:01, 1 August 2008

Low Coupling

This document seeks to explain low coupling including when it should be used, when it should not be used, and how exactly you may make use of this technique in your own programs.

Problem Description

We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.

Coupling

Figure 1: Dependency

Coupling, also known as dependence, is a measurement of the degree in which two program modules rely on each other to complete a task.

Recognizing dependencies:

  • A member function of class A uses an object from class B.
  • When making CRC cards the "collaborators" column denotes classes which depend on one another.
  • As seen to the right in UML diagrams a dashed line with an open arrow points to a dependent class.

When two modules have a very stable interface between one another, one which does not require or even concern itself with the internal structure of the other module and you have "low" coupling between those modules. Other terms used to describe this situation may be "loose" or "weak" coupling.

Recognizing low coupling:

  • The number of connections between classes is low and seems more like a tree structure than spaghetti code.
  • Interfaces between two classes are well defined and usually only communicate through messages (independent modules)
  • Changes to individual classes do not require modification to their dependent classes
  • The number of dependent classes program wide are low

Types of Couping

  • Pathological/Content Coupling was discussed earlier and occurs when a function of class A actually uses or modifies objects/data from class B.
  • Global Coupling can be recognized by the use of global data variables to communicate between two classes. ie Keeping a count of the number of objects initialized using a global count variable.
  • Control Coupling uses a control flag to send instructions between two classes, similar to the way semaphore files were used to exchange data between multiple sessions of the same MS-DOS application.
  • Data-Structure Coupling occurs when a predifined amount of data must be passed between modules, much of this data may not be used but must be present to satisfy the requirements for the message to be successfully transmitted or passed.
  • No Data Coupling occurs when two modules do not transfer data or interact in any way. They are said to be two independent modules.

Benefits of Low Coupling

Reduced Code

Figure 2: High Coupling
Figure 3: Low Coupling

When a module is modified in a well-structured system, one which makes use of low couping, very few subsequent modules must be modified as a result. While this has obvious benefits in regards to the speed at which changes may be implemented and the limited testing that must be performed as a result.

Reduced YoYo Affect

Better Testing

By lowering coupling a module may be tested without including a multitude of other classes or modules. By making testing easier programmers are more likely to thoroughly test code and less bugs will reside in the final version of the code.

Better Encapsulation

Anytime you can hide the design details of your program so that other modules and services may utilize a standard rarely changing interface your program will be less likely to break other modules as a result of design detail modifications.

This is essential to coding a well-structured system which may grow and change to the users requests or external requirements beyond the programmers control. In the every changing workplace as soon as a program has been coding and fully tested, it seems that modifications are needed or often required.

Consequences of Low Coupling

Reduced Performance

One of the unavoidable consequences of low coupling is reduced performance in most situations. Usually however reduced performance is highly tolerable when compared to the increased programming efficiency and future modification.

References

Modular Programming

Information Hiding

Loose Coupling

Tools

Semmle Code Querying Tool (works with Eclipse)