OO Concepts - Encapsulation, Cohesion, Coupling

[Nidhi Sar]

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!

[Raju Champaklal]

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

[Nidhi Sar]

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]

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]

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]

i dont trust the names anymore.....

[Nidhi Sar]

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]

well raju it was actually you who set the example of names

[Raju Champaklal]

ok ok...sorry nidhi....

[Raju Champaklal]

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]

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.

[Nidhi Sar]

Thanks Raju, Ben for sharing your thoughts on this.

- Nidhi

[Raju Champaklal]

your always welcome

[Achilleas Achix]

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?

[Matthew Brown]

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]

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]

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]

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]

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]

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:

class TightEncapsulation {
	private String name;
	public String getName() {
		return name;
	}
	public void setName (String val) {
		name = val;
	}
}

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

class LooseEncapsulation {
	public String name;
}

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

class LooseCoupling {
	public void getName (LooseEncapsulation val) {
		return val.name;
	}
	
	// rest of the code that does not uses 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

[Achilleas Achix]

Mala Gupta wrote:

class LooseCoupling {
	public void getName (LooseEncapsulation val) {
		return val.name;
	}
	
	// rest of the code that does not uses class LooseEncapsulation
}

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:

class LooseCoupling {
	public void getName (LooseEncapsulation val) {
		return val.getName();
	}
	
	// rest of the code that does not uses class LooseEncapsulation
}

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]

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?.

[Matthew Brown]

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]

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]

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.

[Achilleas Achix]

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]

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]

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]

@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]

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]

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]

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]

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.

public class MyClass{
public int myVariable1;
public Object myVariable2;

public void setMyVariable1(int myVariable1){
    this.myVariable1 = myVariable1;
}
public int getMyVariable1(){
    return myVariable1;
}
public void setMyVariable2(Object myVariable2){
    return myVariable2;
}
public Object getMyVariable2(){
    return myVariable2;
}
}

public class UserClass{
@Inject
public MyClass firstObj;

public String concatenate(){
    return ""+firstObj.getMyVariable1()+firstObj.getMyVariable2();

}

You catch my drift

[dennis deems]

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]

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]

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]

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]

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]

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.

public class MyClass{
public int myVariable1;
public Object myVariable2;

public void setMyVariable1(int myVariable1){
    this.myVariable1 = myVariable1;
}
public int getMyVariable1(){
    return myVariable1;
}
public void setMyVariable2(Object myVariable2){
    return myVariable2;
}
public Object getMyVariable2(){
    return myVariable2;
}
}

public class UserClass{
@Inject
public MyClass firstObj;

public String concatenate(){
    return ""+firstObj.getMyVariable1()+firstObj.getMyVariable2();

}

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]

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.