• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Cohesion and coupling

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the basic criteria to decide if the two classes are loosely/tightly coupled ??

Same is the question for cohesion . I read K&B , but could not draw out a good conclusion .
 
Ranch Hand
Posts: 42
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When two classes are tightly coupled, the classes can access each others properties directly. To make them loosely coupled, we have to restrict direct access to a class's properties and must make use of getter/setter methods.
If the class' instance variables are made private and if they can be accessed only through getter/setter methods, it is an indicator of loose coupling with the other classes.
 
Greenhorn
Posts: 7
Android Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Classes and their methods should have a single and well-focused objetive. Imagine this scenario:

In this example, we can say that Document is not cohesive. The Document class should have all the info related to a document, but not things that are not specifically related to a document, like printing. Its much a better idea to have a public void print(Document d) in class Printer, since a printer is made to print things, and a document is not made to be printed (although it can be printed).

Maybe not best explanation ever, but I hope you get the point.
 
Ranch Hand
Posts: 451
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For coupling issue:
Case 1: if you have loosely coupled code like this:

Case 2 : if you have a tightly coupled code like this:


Case 1: This pseudo code demonstrates accessing a private instance variable via setta and getta.


Case 2: This pseudo code demonstrate accessing a public instance variable directly.


In case 1, a StudentRecord object is loosely coupled to Person object.
In case 2, a studentRecord object is tightly coupled to Person object as it manipulate a person object by p.Name!

If you are working for a big unversity system, you may have to deal with distributed computing system where subtasks can be done in parrell by multiple users. The above StudentRecord application has to be enhanced so that the tasks can be performed in parrell. Suppose you and Mr. Johnson are the university database administrators. You perform the add student tasks and Mr.Johnson performs the update student name task concurrently.

Here is the possible execution sequence for case 2:
1. You want to add student called Mary Smith to the database while Mr.Johson wants to update Mary Smith into Jane Smith. After you add Mary Smith, you want to print her name out. After Mr. Johnson updates Mary's name to Jane, he will print her name out.
2. In this scenario, you and Mr.Johnson perform tasks concurrently.
2.1 You add Mary Smith , studentName is set to "Mary Smith" by using p.Name
2.2 Mr.Johnson updates Mary into Jane.
2.3 You print out the studentName, and you will get "Mary Smith". (No! Mary is renamed into Jane now!)

In this case, you know this person's name is Mary , but you don't know Mr.Johnson updates her name.

Conclusion: A change in an object cause bad effect on your system. That is the disadvantage of tightly coupling.

Here is the possible execution sequence for case 1:
1.1 You add Mary Smith.
1.2 Mr.Johnson updates Mary into Jane.
1.3 You print out her name using p.getName(). Yes! You will get "Jane Smith".

In this case, you don't need to know this person's name is as long as you use p.getName() and you don't need to care Mr.Johnson has already updated her name.

Conclusion: A change in an object does not affect your system. That is the advantage of loosely coupling.
 
Helen Ma
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One more thing I want to add about the StudentRecord example is that I have an assumption that the database is synchronized for concurrent access. No two DB admins can access them at the same time.

This may not be a good example. But I want to demonstrate about the degree of coupling. The degree of coupling ranges from tighly couple to loosely couple. There are some software metrics to calculate the degree of coupling. Software metric is not in the exam , and it is another expert's topic.

In the example, I just want to demonstrate the simple aspects about tighly coupling and loosely coupling. This is not a perfect example.

If you, as one of the DB admin, use a piece of application code to access student's record by using p.Name and save the name in a variable for your further development, your application code must be tightly coupled to the student record. Chances are good that the student's name will be updated and your application code is still using the old name.

One the other hand, if you, use a piece of applcation code that accesses student's record by using p.getName() , your application code's degree of coupling to the student record is decreased. Your application code does not care what p's name is. Your application code access the student record through its API only, not directly access its data.

When a piece of code is developed, it should know other objects' encapsulated data as little as possible. Sometimes, a well encapsulated code supports loose coupling even though encapsulation and loose coupling are two different unrelated OO principles.

Again, this is not a perfect example. But the major issue you will be tested is loosely coupling will have less bad effect on your code, according to KB's practice exam.


 
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Object-oriented programming has two main objectives: to build highly cohesive classes and to maintain loose coupling between those classes.

"Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. Though lack of cohesion may never have an impact on the overall functionality of a particular class or of the application itself the application software will eventually become unmanageable."

"Whenever one object interacts with another object, that is a coupling.Strong coupling means that one object is strongly coupled with the implementation details of another object. Strong coupling is discouraged because it results in less flexible, less scalable application software. However, coupling can be used so that it enables objects to talk to each other while also preserving the scalability and flexibility."
 
Shiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic