Section 0: Module Objectives or Competencies
| Course Objective or Competency | Module Objectives or Competency |
|---|---|
| The student will be able to assess and apply Object-Oriented analysis and design methods like use cases to express user requirements, UML modeling, and other OO approaches. | The student will be able to apply OO design guidelines to explain systems of objects. |
Section 1: Design Guidelines
Although OO Design differs from the process-oriented approaches that we have covered previously, basic design guidelines like coupling and cohesion are still relevant.
The following is an excerpt from Basic Object-Oriented Concepts.
Object Coupling and Object Cohesion
Engineers have known for centuries that the less any one part of a system knows about any other part of that same system, the better the overall system. Systems whose components are highly independent of each other are easier to fix and enhance than systems where there are strong interdependencies among some or all of the components. Highly independent system components are possible when there is minimal coupling among the components, and each component is highly cohesive.
Coupling is a measure of the strength of the connection between any two system components. The more any one component knows about another component, the tighter (worse) the coupling is between those two components.
The objects that make up an object-oriented system exhibit object coupling and object cohesion. Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter (worse) the coupling is between those two objects.
Cohesion is a measure of how logically related the parts of an individual component are to each other, and to the overall component. The more logically related the parts of a component are to each other the higher (better) the cohesion of that component.
The objects that make up an object-oriented system exhibit object coupling and object cohesion. Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter (worse) the coupling is between those two objects.
To construct systems from objects, we must couple (to some degree) the objects that comprise the system. This is necessary object coupling. However, if in the design of an individual object, we give that object direct knowledge of other specific objects, we are unnecessarily coupling the objects. Unnecessary object coupling reduces both the reusability of individual objects, and the reliability of the systems that contain unnecessarily coupled objects.
Object cohesion, on the other hand, is a measure of how logically related the components of the external view of an object are to each other. For example, if we are told that a date object is comprised of a month object, a day object, a year object, and the color blue, we should recognize that the color blue is not appropriate, and lowers the cohesion of the date object. We want our objects to be as cohesive as possible for two reasons. First, objects with low cohesion are more likely to be changed, and are more likely to have undesirable side effects when they are changed. Second, objects with low cohesion are seldom easily reusable.
Connascence
A related software quality metric is connascence.
- Two pieces of software share connascence when a change in one requires a corresponding change in the other.
- In other words, connascence describes a relationship between two different code segments in which a change to one code segment requires a change to the other code segment in order for the program to continue to work correctly. link
- Lower connascence is better.