CSC/ECE 517 Summer 2008/wiki3 3 lc: Difference between revisions
No edit summary |
No edit summary |
||
| Line 6: | Line 6: | ||
==Basic Description== | ==Basic Description== | ||
Coupling, also known as dependence, is a measurement of the degree in which two program modules relies on each other two complete a task. When these 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, you have "low" coupling. Other terms used to describe this situation may be "loose" or "weak" 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 program. | Coupling, also known as dependence, is a measurement of the degree in which two program modules relies on each other two complete a task. When these 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, you have "low" coupling. Other terms used to describe this situation may be "loose" or "weak" 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 program. | ||
==Postive Features== | |||
===Ease of Modification=== | |||
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 reguards to the speed at which changes may be implemented and the limited testing that must be performed as a result. | |||
===Information Hiding=== | |||
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. | |||
==Negative Consequences== | |||
===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. | |||
Revision as of 23:44, 26 July 2008
Low Coupling
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.
Basic Description
Coupling, also known as dependence, is a measurement of the degree in which two program modules relies on each other two complete a task. When these 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, you have "low" coupling. Other terms used to describe this situation may be "loose" or "weak" 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 program.
Postive Features
Ease of Modification
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 reguards to the speed at which changes may be implemented and the limited testing that must be performed as a result.
Information Hiding
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.
Negative Consequences
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.