Tight Coupling

[Aniket Patil]

Given a class House, which are true(Choose all that apply)
A. House has-a Roof would be tight coupling
B. A turnOnStero() method would not be cohesive
C House is-a Dwelling would be good encapsulation.
D House has-a Door would be low coupling
E A getAddress() method would NOT be cohesive

The correct answer is B,D. How is D correct, does has-a relationship not enforce tight coupling?

[Dinuka Arsakularatne]

it would be tight coupling only if HOUSE accesses public variable of the DOOR method. but here it just means that house has a reference of door in it.

Dinuka Arseculeratne

[Aniket Patil]

If so, how is "has-a Roof" supposed to be tight coupling? House only has a reference of Roof, no variable is being accessed.

[Dinuka Arsakularatne]

i think you have not read the question right. the question says choose the true statements. hence house has a roof is tight coupling is false. it is low coupling. that is why it is not one of the answers. you have misread the question.

[Aniket Patil]

A misread indeed, thanks!

[Matt Russell]

I had a question about this, so I thought I'd resurrect this thread, hope that's OK.

Why is it that option D ("House has-a Door would be considered low coupling") is true?

The explanation given for this question by K&B is that, "A is incorrect because a house will almost certainly have a Door, so this is not considered tight coupling". I don't understand this. K&B elsewhere say that "coupling refers to the degree to which one class knows about or use members of another class", and that "loose coupling describes a situation in which classes know only about each other's APIs". I'm not sure, then, how that fits in with the explanation.

Further, just knowing that "House has-a Door" tells us very little about how a House uses its Door -- it's entirely possible that House fiddles with Door's public doorKnob field rather than using get/setDoorKnob...or not, we don't know.

More generally, does anybody else find these object-oriented definitions questions really hard, or is it just me? I never know how to answer them correctly, and I'm normally not totally convinced even when I've seen the actual answer. They seem to rely on definitions of concepts like coupling and cohesion that are particular to the SCJP. However, the SCJP definitions are not universal amongst programmers, and what's more problematic, aspects of what they mean are not documented anywhere. For example, another MasterExam question's explanation stated that "coupling is not used to evaluate classes within the same inheritance tree". From the definition given in K&B, there's no reason to believe that would be the case, and I've seen people elsewhere actually refer to subclassing as an example of tight coupling.

[Burkhard Hassel]

Hi ranchers,

Matt wrote:

More generally, does anybody else find these object-oriented definitions questions really hard, or is it just me?

I don't find them hard, but this one is again an example of a really silly, bad and totally ambigous question, that cannot be properly answered at all.
Where is this question from?



A) House has-a Roof would be tight coupling

This has nothing to do with tight or loose coupling at all.
To say if the coupling is loose or tight you'd had to know, what the methods are, and how House and Roof interact.
Since you don't know, A) maybe false.
But there surely can be scenarios, where House and Roof are tightly coupled (that would be a bad design then).


B) A turnOnStereo() method would not be cohesive

If in a class MediaControlling, the method would be cohesive.
If in a class House, it would not be cohesive.
In a class RadioStar, you couldn't tell, depends if the class describes a stellar object or a radio from the Star company.

So again you can't be sure. I think there must be some context missing.
Where is this question from?


C) House is-a Dwelling would be good encapsulation.
No matter of encapsulation at all. Neither good nor bad.


D) House Has-A Door would be low coupling.
Same nonsense as with roof

E) A getAddress() method would NOT be cohesive

If an Adress class provided, then this method should be in this class, not in the house class.
If there's is no class Adress, perhaps make one.

If the House class (how can I know???) just has a String field named "adress", the method would be cohesive.
If the House had a field of type Adress, it also may be cohesive if it returened that Adress object.

If class House doesn't have any instance variable named "adress" the method would not be cohesive.
So again, you cannot decide.

Perhaps the designer of the question wanted to test if we just say:
"has nothing to do with cohesion, is a matter of encapsulation".
But even then you cannot decide, because you don't even know if there is an adress field and whether it's private.



So either the question has not been cited completely or it is eligible for the garbage collector.

My opinion.

Bu.

[Matt Russell]

Originally posted by Burkhard Hassel:
I don't find them hard, but this one is again an example of a really silly, bad and totally ambigous question, that cannot be properly answered at all.
Where is this question from?

This question is from the second MasterExam that comes with K&B. I just hope the ones on the real SCJP exam are better!

[Burkhard Hassel]

Matt wrote:

I just hope the ones on the real SCJP exam are better!

So do I. Thank you for your response, I'll have a look at it.

Really a question for today...




Yours,
Bu.
[ October 31, 2006: Message edited by: Burkhard Hassel ]

[Bert Bates]

Dang! I'm traveling, I just wrote a big, long response, and it got lost - sorry. So, a short response will have to do

For many of the SCJP objectives (OO concepts, I/O, regex, collections, date, currency, to name a few), the Sun exam creation team wanted to test for a very basic level of understanding. In retrospect I think we could have done a better job on the OO questions, but I do think that the question in question is fairly representative of what you'll find on the real exam. I have, however taken note that the explanation in the book should be beefed up for the next printing!

Thanks,

Bert

[Matt Russell]

Originally posted by Bert Bates:
I do think that the question in question is fairly representative of what you'll find on the real exam.

Darn. I don't suppose there's any chance you could go over, even briefly, to explain a little the answer to this question? It would be generous of you if you could.

I think the general problem with these sorts of questions is that different people have different understandings of OO concepts -- polymorphism, encapsulation, coupling etc. I've spent time Googling them, and there's variation of opinion on what they mean. Of course, it's quite acceptable to say, "here's Sun's definition", and have people learn that for the exam. However, at least in my opinion, the definitions in (your otherwise very excellent) book do not pin it down enough to enable people to answer all the questions without thinking for some options "well, that option could be true or false".

I'll be put out of my misery on Thursday, so I'll get back to revising

[Bert Bates]

Hey Matt,

Well I have to admit that a year later, looking at this question now, I'm none too thrilled with it

So I'm not too sure I can help much, but I'll take a stab - again, a caveat is that I'm also not so sure that the OO concepts questions on the real exam are that defensible, so the whole darned discussion is on shaky ground, in other words it's all a little lame to begin with so I don't want to get embroiled here

Given a class House, which are true(Choose all that apply)
A. House has-a Roof would be tight coupling
B. A turnOnStero() method would not be cohesive
C House is-a Dwelling would be good encapsulation.
D House has-a Door would be low coupling
E A getAddress() method would NOT be cohesive

Answer:

B and D are correct.
A is incorrect because a House almost certainly will have a Roof (note: on the CD it says Door, which is an errata), so this is not considered tight coupling. C describes inheritance not encapsulation. E is incorrect because getAddress() would probably represent good cohesion.

Hmmm... (and remember all of the following is really exam-centric, I would want to have to defend any of it in front of the OO community )

Tight coupling is generally a bad thing - it means that classes know more about each other than they need to or should. It's fairly defensible to say that a House class would reasonably "have-a" Roof object, so this wouldn't be considered tight coupling - House does know about Roof because it "has" a roof, but it seems natural - so A is incorrect. As far as B is concerned, a House might have a Stereo, but it would make more sense for the Stereo to have Stereo-related methods - for the House to have such a Stereo-related method would really make for a vague, non-cohesive class. When a class has a single, well defined focus, it is considered cohesive. C is a "distractor" to make sure you aren't confusing encapsulation with inheritance. I guess D is related to A - the idea being that the existence of a "reasonable has-a" doesn't create tight coupling - reasonable of course being subjective. On the real exam we tried to make up "reasonable" real-world examples.

Finally E - i suppose this one's debatable too - the admittedly subjective argument is that in the real world it's reasonable that a House object would have an address property, and that having an address property wouldn't hurt the House classes cohesiveness.

hth,

Bert

[Matt Russell]

That's very helpful to know how to approach the actual exam questions, thanks for taking the time.

[Burkhard Hassel]

Hi Bert,

thanks for your posting. I don't think I will get totally happy with the question...
But to start, I'd like to cite from your book, page 148:

We're going to admit it up front. The Sun exam's definitions for cohesion and coupling are somewhat subjective, so what we discuss in this chapter is from the perspective of the exam, and by no means The One True Word on these two OO design principles.

We shouldn't forget that!

A
you wrote about A (House has-a Roof would be tight coupling):

Tight coupling is generally a bad thing - it means that classes know more about each other than they need to or should. It's fairly defensible to say that a House class would reasonably "have-a" Roof object, so this wouldn't be considered tight coupling - House does know about Roof because it "has" a roof, but it seems natural - so A is incorrect.

ok, it is not a matter of tight coupling and A is false.
But what when you said: "House has-a Roof would be loose coupling"?
Would A be true then? Well, see D.
Anyway, loose is not the question, and in any cases A is an uncorrect answer.


B
A turnOnStereo() method would not be cohesive

Sorry about my first posting, I didn't get that the method should be in class House.
Not cohesive, should be in a radio class, now I got it.


C
C) House is-a Dwelling would be good encapsulation.
Now I'm slowly starting to understand how these questions are alike. They always state good or bad (encapsulation/encapsulation/cohesion).
But the stress is on the noun, not on the adjective.
And as is-a has nothing to do with encapsulation in the first place, C is false, OK.



D
D House has-a Door would be low coupling

Hmmm. Seems my thesis about the stress on the nouns was a bit to early...
D is the opposite of A. Just with Door instead of Roof. And low coupling should be correct.
You wrote:

I guess D is related to A - the idea being that the existence of a "reasonable has-a" doesn't create tight coupling - reasonable of course being subjective. On the real exam we tried to make up "reasonable" real-world examples.

I'm not convinced here. For the same reasons, Matt wrote in his first posting in this thread.
Matt wrote:

K&B elsewhere say that "coupling refers to the degree to which one class knows about or use members of another class", and that "loose coupling describes a situation in which classes know only about each other's APIs". I'm not sure, then, how that fits in with the explanation.

Further, just knowing that "House has-a Door" tells us very little about how a House uses its Door -- it's entirely possible that House fiddles with Door's public doorKnob field rather than using get/setDoorKnob...or not, we don't know.

I said I am not convinced. But perhaps persuaded to accept it. I thought in the first place, both are false as we cannot tell if House and Door / Roof are tight or loose coupled.
Extreme example of tight coupling (bad!):

class House {
private Door door = new Door();
public boolean enter(){
boolean open = door.isOpen();
if (! open)
door.open([B]"$/&&%"[/B]);
open=door.isOpen();
door.close();
return open;
}

}
 
class Door {
private boolean open=false;
private final String pass="$/&&%";
public boolean isOpen() {
return open;
}
public void open(String pass){
if (pass.equals(this.pass)){
if (isOpen()){
throw new RuntimeException(
"already open");
}else{
this.open = true;
}
}else throw new SecurityException("Burglar!");  :-o	  
}
public void close(){
this.open=false;
}
}

But surely you might say: "It's not the House having the Door that makes the coupling tight, but that criminal enter() method". If so, you are right, having something alone may be regarded as loose coupling. If loose is the "default value" of coupling and you do not violate it by method code.
Or in short: Having alone should be regarded as loose coupling.


E
E A getAddress() method would NOT be cohesive
you wrote

Finally E - i suppose this one's debatable too - the admittedly subjective argument is that in the real world it's reasonable that a House object would have an address property, and that having an address property wouldn't hurt the House classes cohesiveness.

When thinking about it, you are right, and I was wrong. When the getAdress method invokes the - perhaps - toString method of the adress object it is still cohesive.






Finally(*), my idea of garbage collecting the whole question was also a bit too early. At least it made me think about all this stuff again!


Yours,
Bu.


(*) finally() runs always... w/wo Biodiesel