1. Not what first comes to mind
Coupling
Not what first comes to mind
Want to talk about cohesion as well?
Copyright © 2014 by Curt Hill

2. Copyright © 2014 by Curt Hill
Coupling
Coupling, in Computer Science and Software Engineering, describes the dependency of one thing upon another
The things in question are usually functions and objects
May also refer to interdependency
Low coupling means an item is not very dependent on another
High coupling means that we cannot use the one without the other
Copyright © 2014 by Curt Hill

3. Copyright © 2014 by Curt Hill
Terminology
Low coupling is sometimes referred to as weak or loose
Generally desirable for functions and objects
Indicates well designed modules
High coupling
AKA tight or strong
Inhibits reuse in other programs
Copyright © 2014 by Curt Hill

4. Copyright © 2014 by Curt Hill
Informal Example
The coupling of a customer and clerk in a store is low
Communicate through common language
Either person is interchangeable with another
Family relationships are usually high
Parents/siblings/spouse are tightly coupled
No interchangeability
Copyright © 2014 by Curt Hill

5. Copyright © 2014 by Curt Hill
Types of Coupling 1
Content (high)
A module relies on the internal workings of another
Common (high to medium high)
Two modules use common global variables
Changing the globals requires a change in the modules
External (medium)
Two modules share a common data format or protocol
Copyright © 2014 by Curt Hill

6. Copyright © 2014 by Curt Hill
Types of Coupling 2
Control (medium)
One module controls the execution of another
Often a parameter that alters the type of processing
Stamp or data structure
Two modules use a common data structure, but not the same portions of it
Changing the data structure may mandate changes in one without the other
Copyright © 2014 by Curt Hill

7. Copyright © 2014 by Curt Hill
Types of Coupling 3
Data (low)
Data is shared, but the data is simple, such as in parameters
Often a parameter that alters the type of processing
None
Two modules share nothing
Copyright © 2014 by Curt Hill

8. Copyright © 2014 by Curt Hill
Coupling Issues
Highly coupled systems become harder to maintain
A change in one module forces changes in others
A ripple effect occurs as change ripples through the system
Copyright © 2014 by Curt Hill

9. Copyright © 2014 by Curt Hill
Some Examples
GUI programs are typically Common coupled
Event handlers rely on the fact that certain edit boxes or labels are available
Cutting the event handler out of one program and putting it into another is never done
Math library functions
Those programs that use them are Data coupled to them
They are not coupled to each other
Copyright © 2014 by Curt Hill

10. Copyright © 2014 by Curt Hill
The Date class example
The methods are stamp or common coupled with one another
getDay is stamp coupled with getMonth
ToString is common coupled with getDay
Changing the form of the month, day and year mandates changes in every method
Since the class is a unit this is not a problem
Copyright © 2014 by Curt Hill

11. Copyright © 2014 by Curt Hill
Date again
Suppose that the correct function were missing and not called
Then the date class would be dependent on its client to supply good data
This would shift the checking to the client
This would increase the coupling between the client and the class
Copyright © 2014 by Curt Hill

12. High Coupling is Not Evil
Very often we have a program that has a central data structure or many data structures
Nearly every method/function uses one or more of these
We do not need to pass every data structure to every function
Just use it as global data
This is not bad but it prevents reuse of the function
Copyright © 2014 by Curt Hill

13. Copyright © 2014 by Curt Hill
The Other Coupling
Multiple CPU systems also use this term
Two CPUs that have a common memory is termed tightly coupled
Two CPUs that are connected by some other type of high speed communications is loosely coupled
Current multicore CPUs are tightly coupled, while the CPU to GPU coupling is loose
Copyright © 2014 by Curt Hill

14. Copyright © 2014 by Curt Hill
Conclusion
When designing classes we generally want the lowest possible coupling
This allows us to reuse the class
This allows us to rewrite the class without breaking other things
Many programs have one-shot classes
They are designed for this particular application
Little chance of reusability
Copyright © 2014 by Curt Hill