wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Coupling and Cohesion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Coupling and Cohesion" Watch "Coupling and Cohesion" New topic
Author

Coupling and Cohesion

Matloob Hussain
Ranch Hand

Joined: May 13, 2011
Posts: 37

Hi,

In SCJP Sun Certified Programmer for Java 6 Study Guide by Katherine Sierra and Bert Bates (K&B):
Coupling refers to the degree to which one class uses members of another class


So it means, more than one classes are involved in coupling.

In SCJP Sun Certified Programmer for Java 6 Study Guide by Katherine Sierra and Bert Bates (K&B):
Loose coupling is the desirable state of having classes that are well encapsulated, minimize references to each other and limit the breadth of API usage.


So it means encapsulation plays a major role in loose coupling, It must be well encapsulated( protected instance vaiables using private modifier)

Upto here, I think, I might be right. But I do not undstand the two other requirements for loose coupling.
The first one is "minimize references to each other"
The second one is "limit the breadth of API usage"

Could you please explains these ones.....

Thanks


Matloob


Matloob
OCPJP 1.6
OCPWCD in progress.....
Tomski Simon
Greenhorn

Joined: May 30, 2011
Posts: 7
I found quite easy explanation (written by Mario Peshev) of each term:

Loose coupling: your classes must be independent from each other. Otherwise
your class could 'break' because of another 6,7... 10 classes that are
strongly related to it. With better coupling your class doesn't need many
other classes and your application is bit stronger.

High Cohesion - that's the entity of a class or method. You shouldn't
develop a method that acts like a whole big application (for example, all of
your program in a method). When an exception comes out, it's harder to find
the problem and look over thousands of lines code. When you keep strong
cohesion, your methods act like 1 simple organism and it's easier to look
over them.

Strong cohesion: System.out.println(message);
Simple operation, gets the information and send it to the console.

Bad cohesion: a method that executes connecting to Internet, downloading
information, putting it into a database, changing details, exporting,
printing, uploading back to Internet. All of this activities in a method.
How many errors could occur here? ;)

Encapsulation, in my opinion, is strongly related to data abstraction. They
both form a mechanism like a Black Box (airplanes` black boxes) or a clock -
you just see the display, but you don't have an idea what's hidden inside
and how it works. And you don't care. All data and operations are collected
in your class. Good practise is hiding the details: all fields private and
usage of getters and setters to gain access to your fields. That's how you
can implement complex logic in your getters/setters, you can restrict access
(read-only, write-only or both, or none). Finally, you show users only the
information that he/she needs. Remember the example with the clock- you
don't mind if the mechanism gets replaced, if you see this display, working
the same way.
Make private fields, public/protected getters and setters; private methods
for internal algorithms that are no interest for the user; public methods
that user can use. If you update your app and change your logic, it should
be invisible for the user- he just have to use the same algorithm and a set
of operations.


Source: http://java.ittoolbox.com/groups/technical-functional/java-l/tight-encapsulation-loose-coupling-and-high-cohesion-in-classes-1089364
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Coupling and Cohesion