File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes OO Concepts - Encapsulation, Cohesion, Coupling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "OO Concepts - Encapsulation, Cohesion, Coupling" Watch "OO Concepts - Encapsulation, Cohesion, Coupling" New topic
Author

OO Concepts - Encapsulation, Cohesion, Coupling

Nidhi Sar
Ranch Hand

Joined: Oct 19, 2009
Posts: 252

I keep on tripping-up on questions on Encapsulation, Cohesion & Coupling. These are pretty important OO concepts but pretty confusing as well. Theoretically they seem clear enough, but I make mistakes on the questions on implementation e.g. how to implement each and what is the effect of each (e.g which one leads to better re-use, which is better for higher readiblity etc)

Other than K & B chapter on OO, can someone please refer me to any other resource on these three concepts?

Thanks so much!


"A problem well stated is a problem half solved.” - Charles F. Kettering
SCJP 6, OCPJWCD
Raju Champaklal
Ranch Hand

Joined: Dec 10, 2009
Posts: 521
i know it is confusing...but which part confused you....write it here...we will try to get it clear...one question on that is sure


scjp 1.6 91%, preparing for scmad
"Time to get MAD now.. we will get even later"....by someone unknown
Nidhi Sar
Ranch Hand

Joined: Oct 19, 2009
Posts: 252

Something like this:

From K & B MasterExam :

Encapsulation makes it easier to reuse classes (Select as true or not).

I did not select it, since High Cohesion should be related to re-use, not Tight Encapsulation. The answer had it selected.

These type of questions....
Raju Champaklal
Ranch Hand

Joined: Dec 10, 2009
Posts: 521
dude high cohesion means highly focused is the class....this is vaguely related to re-use.....read the part on encapsulation in k&b...there are 2 advantages of encapsulation..one of them is re-use....because making them encapsulated means they can extended or used many times..and even if there code changes it wont break someone else's code
Phungsuk Wangdu
Ranch Hand

Joined: Nov 04, 2009
Posts: 114
hey raju nidhi is a gal not a dude please look out bro ....
well apart from that everything raju said seems ok to me.
Raju Champaklal
Ranch Hand

Joined: Dec 10, 2009
Posts: 521
i dont trust the names anymore.....
Nidhi Sar
Ranch Hand

Joined: Oct 19, 2009
Posts: 252

James Carter wrote:hey raju nidhi is a gal not a dude


Thanks, James. That's true.

Seriously, is there anyplace on JR or the web I can read-up more on these concepts? Or questions, just related to these? please, please, anyone??
Phungsuk Wangdu
Ranch Hand

Joined: Nov 04, 2009
Posts: 114
well raju it was actually you who set the example of names
Raju Champaklal
Ranch Hand

Joined: Dec 10, 2009
Posts: 521
ok ok...sorry nidhi....
Raju Champaklal
Ranch Hand

Joined: Dec 10, 2009
Posts: 521
well nidhi k&b is the best place to read them....and there are related questions in the book and the masterexam....actually when i first read them even i was confused..but after reading through the book and understading what encapsulation and polymorhism is all about i was able understand these topics....dont worry about them....you will get clear after practicing other chapters like oops and stuff

Ben Power
Ranch Hand

Joined: Dec 30, 2009
Posts: 31
Raju Champaklal wrote:you will get clear after practicing other chapters like oops and stuff


This is so true. For me, I went through the book, then went back to the beginning and everything made so much more sense. The key is, you have to do a lot of writing code while you work through the book. As you do this, things will start to come together in your head, and then declarations/OOP/etc will make a lot more sense the second time through.

I was on a time crunch for my exam, but I would have done much better had I had time to go in detail through the book 2 full times. Still, the things I did go through twice were the areas I did the best on in the exam.


SCJP 6
Nidhi Sar
Ranch Hand

Joined: Oct 19, 2009
Posts: 252

Thanks Raju, Ben for sharing your thoughts on this.

- Nidhi
Raju Champaklal
Ranch Hand

Joined: Dec 10, 2009
Posts: 521
your always welcome
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

I have that problem as well.

I can answer correctly questions about high Cohesion (a class with a very specific reason of existence), but i fail to differentiate between loose coupling and encapsulation. IMHO loose coupling ~ encapsulation. Or in other words, loose encapsulation is sure to have the effect of tight coupling. That means that loose coupling results in tight encapsulation. However, could we have tight encapsulation AND tight coupling at the same time?

Lets say, that we have a class JBEncapsulated which is a normal POJO bean. One of the methods return an InputStream (getIs() ). Lets say that the next version changes JBEncapsulated.getIs() to throw an Exception instead of returning null in case it cant open the InputStream.
This will break lose coupling, while maintaining tight encapsulation, thus we will have tight encapsulation (good) and tight coupling (bad) at the same time.

Could we say that "Loose coupling" ISA "Tight Encapsulation"?? (meaning Loose coupling is smth more (subclass) than Tight Encapsulation)?
or that Tight Encapsulation is a prerequisite for Loose coupling?

Do you agree with the above logic?


OCPJP 6.0
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

Achilleas Achix wrote:Or in other words, loose encapsulation is sure to have the effect of tight coupling.

Loose encapsulation allows tight coupling. But think of the extreme case: you could have a poorly encapsulated class that nothing else refers to - no coupling at all.

Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Matthew Brown wrote:
Achilleas Achix wrote:Or in other words, loose encapsulation is sure to have the effect of tight coupling.

Loose encapsulation allows tight coupling. But think of the extreme case: you could have a poorly encapsulated class that nothing else refers to - no coupling at all.



You mean, no one uses that class?
Loose encapsulation means communication is done via public members. And this *means* tight coupling.

Am i wrong? please share your thoughts.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

In my opinion:

- coupling is about how a class is used
- encapsulation is about how a class allows itself to be used

Not quite the same thing. If you make all the member variables of a class public, then you've got poor encapsulation. You don't actually have poor coupling, though, until another class actually makes use of those member variables. So poor encapsulation allows tight coupling, but it's not the same thing.
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Matthew Brown wrote:In my opinion:

- coupling is about how a class is used
- encapsulation is about how a class allows itself to be used

Not quite the same thing. If you make all the member variables of a class public, then you've got poor encapsulation. You don't actually have poor coupling, though, until another class actually makes use of those member variables. So poor encapsulation allows tight coupling, but it's not the same thing.


Alright, but when we have a solo class which is never used by no one (no other class), then i guess this is a corner case, where coupling cant be neither tight nor loose because it simply does not exist.
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

I think its official : Loose coupling *NEEDS* tight encapsulation :

http://www.moleksyuk.com/2011/01/scjp-16-sun-certified-java-programmer.html

2.3 Coupling
· Coupling refers to the degree to which one class knows about or uses members of another class
· 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
· Tight coupling is the undesirable state of having classes that break the rules of loose coupling
Mala Gupta
Author
Ranch Hand

Joined: Sep 27, 2002
Posts: 251
    
    9
Achilleas Achix wrote:I think its official : Loose coupling *NEEDS* tight encapsulation :

http://www.moleksyuk.com/2011/01/scjp-16-sun-certified-java-programmer.html
· Loose coupling is the desirable state of having classes that are well encapsulated,


The link that you referred to isn't an official document by Sun/ Oracle and hence it cannot be termed as official.

I agree with Matthew Brown that
- coupling is about how a class is used
- encapsulation is about how a class allows itself to be used

Here's an example to prove this. The following is a well encapsulated class which does not defines any public instance variables:



The following isn't a well encapsulated class which defines public instance variable(s):


The following is an example of a class (LooseCoupling) loosely coupled to class LooseEncapsulation:



class LooseCoupling can be loosely coupled to either LooseEncapsulation or TightEncapsulation! The latter (classes - LooseEncapsulation or TightEncapsulation) do not make a difference on a class being loosely coupled or tightly coupled to another class.

cheers
Mala


Author of Manning's OCA Java SE 7 Programmer I Certification Guide and OCP Java SE 7 Programmer II Certification Guide
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Mala Gupta wrote:



You just presented (above) a classic case of TIGHT coupling. Class (so-called) LooseCoupling knows about LooseEncapsulation's internals, *BESIDES* LooseEncapsulation interface to the outside world.

"Loose coupling" ISA (something more than) "Tight encapsulation".

So, even if the above code read like:


We would have tight encapsulation, but just because inter-references to each other are not minimized (why have LooseCoupling do the job of LooseEncapsulation?), we do not have loose coupling.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Hello All,
I want to make use of this opportunity to talk about a technical question I got in the real exams which is SIMILAR to the following:

In a software company a programmer is called to make certain adjustments to an application with the aim of adapting to the new printers that had just been recently acquired, after making the adjustments, users of the application had problems with using this application, what do you think is the problem?

-Encapsulation
-Cohesion
-Loose Coupling
-Polymorphism
-None Of The Above
-Tight Coupling

I will appreciate if any one help with a detailed explanation of what you think is the correct answer thanks.

I personally chose encapsulation because I suppose that the programmer 'tampered' with the API (public getter/ setter methods), which in turn affected the implementation of the users of the application. What do you guys think?.


OCPJP 6.
In Your Pursuit Towards Certification, NEVER Give Up.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

This is an educated guess - I'm not quite sure what they're looking for...

My first instinct is to go for "tight coupling", because it sounds like the implementation of the printing interface is affecting the application, suggesting that the rest of the application is more dependent than it should be. If things were loosely coupled, then you wouldn't expect new printers to affect you unless you were trying to print.

However, these things do overlap. I could also make a case for "cohesion". If the components had good cohesion, all printing would be handled by a printing component that would do nothing else. So changes to that component really shouldn't affect anything else. In fact, I'm now tending towards this answer.

And, of course, both these can be affected by encapsulation, but I think we're assuming too much if we say that's the cause.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Hello Matthew,
thanks for your brilliant suggestions, they make a lot of sense. Now taking a close or second look at the question one would suggest that a company's application complies with all the recommendations of API according to SUN, meaning that its API (well encapsulated) was implemented by users who suddenly had problems with using this program after adjustments have been made.
The FUNDAMENTAL purpose of encapsulation is to prevent DIRECT access to class fields and avoid destroying users implementations, I sincerely think that the public interface were 'tampered' with by the programmer, hence destroying the users implementations.
I have my doubts about cohesion because it refers to good design -classes should have a SPECIFIC purpose- (A class house can have an address but NOT an accounts department NOR inventory). My question is should cohesion (Design) really be the reason why users suddenly could NOT use a newly adjusted application anymore?.

At the moment I will stay with encapsulation, without completely DISCARDING your suggestions.


Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 543
    
    4

I would also say tight coupling actually. Tight coupling and encapsulation goes hand in hand, but a lack of encapsulation doesn't necessarily mean that your service and client classes are tightly coupled. It doesn't necessarily mean something will go wrong. On the other hand, if there is tight coupling between the service and client classes, it is definitely error-prone if a different client class is provided.

So loose encapsulation enables tight coupling, but it is the tight coupling that actually causes the problem, so that is the direct cause.


Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Dieter Quickfend wrote: but a lack of encapsulation doesn't necessarily mean that your service and client classes are tightly coupled.


Can you bring one example of having poor encapsulation *AND* loose coupling at the same time?

A little more studying led me to believe :

Loose coupling = Encapsulation + Use of Interfaces instead of Classes wherever inter object dependencies are taking place.

Classes referring to one another, even in a completely encapsulated manner *defeats* loose coupling.
Poor encapsulation is surely a guarantee for tight coupling.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Achilleas Achix wrote:
Poor encapsulation is surely a guarantee for tight coupling.


Ikpefua wrote:

Hello Achilleas, If the above statement AS-IT-STANDS is correct -(I think so)-, it means my theory that encapsulation is the problem is also correct or MOST appropriate.
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Ikpefua Jacob-Obinyan wrote:
Achilleas Achix wrote:
Poor encapsulation is surely a guarantee for tight coupling.


Ikpefua wrote:

Hello Achilleas, If the above statement AS-IT-STANDS is correct -(I think so)-, it means my theory that encapsulation is the problem is also correct or MOST appropriate.


If you notice the wording, it says :
-Encapsulation
-Cohesion
-Loose Coupling
-Polymorphism
-None Of The Above
-Tight Coupling


Cohesion, by itself is neither bad or wrong. High Cohesion, OTOH is *good*, and low Cohesion is *bad*.
Encapsulation, by itself is neither bad or wrong. Strong encapsulation, OTOH is *good*, and poor encapsulation is *bad*.
Tight Coupling, *IS* bad without any other assumptions. + it fits the description of the problem.

If .e.g. Poor encapsulation was in the list, then maybe it would have to be the 1st choice, but asis, i think Tight Coupling fits best.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

@Achilleas, @Dieter, @Matthew your analysis have helped a lot to understanding how to answer such a technical question. It is true that its tight coupling (Credit also goes to Matthew, that was his VERY first suggestion) because it DIRECTLY means poor encapsulation, which tends to destroy users implementation, hence they have problems with using the application (as mentioned in the question). You guys would agree with me that its easy to get such a question wrong at a first glance. @Matthew 'First Instincts' are powerful Thanks guys.
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Ikpefua Jacob-Obinyan wrote: It is true that its tight coupling because it DIRECTLY means poor encapsulation,


That is not true. You can have strong encapsulation *and* tight coupling.
Think of it as, Loose coupling is the best design practice. The ideal. In order to get there, at least we should first implement strong encapsulation.
Beginning with poor encapsulation we condemn our app to be eternally tightly coupled.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

Not necessarily. Imagine a class with only private fields and getter and setter methods. Encapsulation will be strong, and coupling will be loose.

Now, if we make all the fields public, but all the other classes in our program still only use the getters and setters, encapsulation will be bad, but coupling will still be loose.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Guys don't you think encapsulation is at the 'HEAD'of it all? I think the aim of encapsulation is to achieve loose coupling.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 543
    
    4

Achilleas Achix wrote:
Dieter Quickfend wrote: but a lack of encapsulation doesn't necessarily mean that your service and client classes are tightly coupled.


Can you bring one example of having poor encapsulation *AND* loose coupling at the same time?

A little more studying led me to believe :

Loose coupling = Encapsulation + Use of Interfaces instead of Classes wherever inter object dependencies are taking place.

Classes referring to one another, even in a completely encapsulated manner *defeats* loose coupling.
Poor encapsulation is surely a guarantee for tight coupling.




You catch my drift
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Ikpefua Jacob-Obinyan wrote:Hello All,
I want to make use of this opportunity to talk about a technical question I got in the real exams which is SIMILAR to the following:

In a software company a programmer is called to make certain adjustments to an application with the aim of adapting to the new printers that had just been recently acquired, after making the adjustments, users of the application had problems with using this application, what do you think is the problem?

-Encapsulation
-Cohesion
-Loose Coupling
-Polymorphism
-None Of The Above
-Tight Coupling

I will appreciate if any one help with a detailed explanation of what you think is the correct answer thanks.

I personally chose encapsulation because I suppose that the programmer 'tampered' with the API (public getter/ setter methods), which in turn affected the implementation of the users of the application. What do you guys think?.



As written, the question is garbage. Where is the "Insufficient Data" option? Without more information, I don't see how any answer could possibly be more than just a guess.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Hello Guys, tight or loose coupling is a CONSEQUENCE of encapsulation.
Now lets take a CLOSE look at the code sample that Dieter has just posted the problem here is poor encapsulation, INDEPENDENTLY of the way you access a class's fields, if those fields are public, they are simply PUBLIC.

Accessing those fields via public methods does NOT mean that the fields cannot be DIRECTLY accessed.

So from the VERY beginning the design pattern should be good encapsulation:

-Keep instance variables protected -loose coupling- (with restricted access modifiers)
-Make public accessor methods, and force calling codes to use those methods
rather than DIRECTLY accessing the instance variables.

Does the above explanation make sense?
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Dennis Deems wrote:
As written, the question is "garbage".


Ikpefua wrote:

Hello Dennis,
I will appreciate it better if your expressions are polite, secondly lets say yes the question is "garbage", have you bothered to make an opinion on the tough debate going on here about Encapsulation Vs Tight coupling? go ahead and please tell us something.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Ikpefua Jacob-Obinyan wrote:
Hello Dennis,
I will appreciate it better if your expressions are polite, secondly lets say yes the question is "garbage"


Hello Ikpefua,
I mean no impoliteness to any posters here. I am very glad to have the company of others who are also working to learn this material. I am glad for the posts that ask the same questions I have had, and glad for the posts that ask what has not occurred to me. Almost every post has helped me learn something.

My wallet is about to be made lighter by $300US; I am not laying my money down for the privilege of attempting to guess at what the test authors could possibly have meant. I have the right to expect an examination that is worth the money I pay, that is unambiguous and does not rely on speculation.

Ikpefua Jacob-Obinyan wrote:
have you bothered to make an opinion on the tough debate going on here about Encapsulation Vs Tight coupling? go ahead and please tell us something.

I am in agreement with those who have written to the effect that encapsulation characterizes an individual entity, and coupling characterizes relationships between entities.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Dennis, your opinions are very welcome and your suggestions too. I simply preferred for example the word "ambigous" to "garbage". For courtesy reasons politeness is always welcome and I appreciate your contribution (even if it were two lines). I got a question RELATIVELY close to the one I posted here. My main purpose of placing the question "garbage or not" is that I wanted us to CONTINUE the debate and try to resolve once and for all, the confusion about encapsulation, tight coupling and cohesion, and I am sorry that the "two lines you posted" (I wont say garbage NOR ambiguos) does NOT give me any solid explanation. Thank you.
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

Dieter Quickfend wrote:
Achilleas Achix wrote:
Dieter Quickfend wrote: but a lack of encapsulation doesn't necessarily mean that your service and client classes are tightly coupled.


Can you bring one example of having poor encapsulation *AND* loose coupling at the same time?

A little more studying led me to believe :

Loose coupling = Encapsulation + Use of Interfaces instead of Classes wherever inter object dependencies are taking place.

Classes referring to one another, even in a completely encapsulated manner *defeats* loose coupling.
Poor encapsulation is surely a guarantee for tight coupling.




You catch my drift


In this example loose coupling is accidental. In fact, although loose coupling seems to have been implemented here, tight coupling actually is allowed (not to say endorsed) via poor encapsulation.
If the writer of the user class is the same with the writer of the utility class then ok. Otherwise boom!
So if guarranteed loose coupling comes into play, then your example is bad.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 543
    
    4

You're the one who asked for an example of both at the same time, perhaps it's convoluted, but I'm not planning on writing a novel.

More importantly, (and that was the purpose) it shows that bad encapsulation does not necessarily mean tight coupling. If you've got public variables that nobody uses, you've got bad encapsulation and loose coupling.

So in most cases, bad encapsulation enables tight coupling, but not in all cases, it is not a given.

And it is tight coupling that directly represents the problem here, so the solution should definitely be tight coupling.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OO Concepts - Encapsulation, Cohesion, Coupling