Last Day to Registor as a SSWUG.ORG Beta Tester
If you would like to be one of the first to see the new SSWUG.ORG site in it’s Beta form, this is the last day to sign up as a Beta Tester. By participating you receive a free year of premium membership.
Sign up now by fully completing this survey today.
OOP – Method Coupling Levels
Today I wrap up the discussion on OO Method development principles with a short review on different levels of Method Coupling. First we talked about Method Cohesion, recommending that methods have a single purpose with little or no branching. Second, we talked about kinds of coupling allowing methods to communicate. Today we follow up with Levels of Method Coupling.
Coupling levels qualify the ability of methods to be coupled allowing for long term usage and extension. Here are some levels of coupling I have been reviewing:
- Normal coupling – methods are coupled using one or more simple scalar parameters
- Structured coupling – methods are coupled using one or more complex data types or classes
- Control coupling – using this coupling a method that passes a parameter to another function telling it what to do. Close coupling is used only in certain patterns such as factories
- Insane coupling – there are real world examples of this kind of coupling where two different methods modify each other’s data. I consider this insane because anyone who does this has to be crazy
- Data Member coupling – two member functions use data members to connect with each other. This kind of coupling has reduced visibility due to the fact that there are no exposed parameters for the methods…they just magically work using internal data
- Global-Data coupling – This kind of coupling uses global variables rather than data members. Not only is method visibility lost with this kind of coupling, but now you also have methods outside your class able to confuse the state of what is being done
Normal and Structured coupling are the prefered levels of method coupling. Structured coupling has the benefit that since both methods share the same structured object, if the object is modified over time, the signature of a called method, and the parameters of a calling method remain the same…the structured object is all that need be modified. Using interfaces for coupling provides even more future proofing of your code.
These building blocks of good method development practices provide a framework to start utilizing patterns. Patterns, in turn, become a foundation for frameworks or other more complicated patterns.
How do you grade yourself with some of these basic principles for core object oriented programming? Has this been a helpful exercise? Do you have something you would like to add to the discussion? Drop me a note at btaylor@sswug.org and let me know what you think.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
All-At-Once Operations
Written by Itzik Ben-Gan with SolidQ
SQL supports a concept called all-at-onc… (read more)