Question on coupling

[Ruben Soto]

This is from MasterExam B, Question 44:

Question 44
Given a class House, which are true? (Choose all that apply.)
Correct Answer
B: A turnOnStereo() method would NOT be considered cohesive.
D: House has-a Door would be considered low coupling.

My question is answer D. How does House has-a Door represent low coupling? Whether coupling is low or not depends on factors which are not disclosed, such as: Is the Door class well encapsulated? The Door class could be badly encapsulated and allow House to use implementation details which might break the House class if the Door class changes in the future.

Is this a mistake, or is there any logic to it?

Thanks in advance,

Ruben

[Balu Sadhasivam]

I guess Door is interface in the question. Did they mention it ?

[Ruben Soto]

Balu Sadhasivam wrote:

I guess Door is interface in the question. Did they mention it ?

Hi Balu,

That's a good point, but they don't mention Door being an interface. Also, naming an interface as Door would be bad practice (the guideline for interfaces is to name them as adjectives denoting what the objects implementing the interface will be able to do.)

Thanks though.

[Robert O'Leary]

Ruben Soto wrote:

My question is answer D. How does House has-a Door represent low coupling? Whether coupling is low or not depends on factors which are not disclosed, such as: Is the Door class well encapsulated? The Door class could be badly encapsulated and allow House to use implementation details which might break the House class if the Door class changes in the future.

Is this a mistake, or is there any logic to it?

Thanks in advance,

Ruben

Ruben, I think these type of questions are bit vague TBH and can be argued about, which makes them slightly meaningless IMO. But my take on it to answer these Qs is that has-a relationships usually represents composition. In OO design we favour composition over inheritance as objects that are composed of other objects are less "connected". It is good OO design. If you have a reference to an object, you can only using the object's public API (provided its a well-encapsulated object - so this is the assumption)...which would be low coupling (even the terminology isnt consistent - loose coupling surely!)

[Ruben Soto]

Robert O'Leary wrote:
Ruben, I think these type of questions are bit vague TBH and can be argued about, which makes them slightly meaningless IMO. But my take on it to answer these Qs is that has-a relationships usually represents composition. In OO design we favour composition over inheritance as objects that are composed of other objects are less "connected". It is good OO design. If you have a reference to an object, you can only using the object's public API (provided its a well-encapsulated object - so this is the assumption)...which would be low coupling (even the terminology isnt consistent - loose coupling surely!)

Robert, I understand that composition is favored over inheritance (when composition is more appropriate.) But using composition simply doesn't assure low coupling. When you have a reference to an object, you may use any public members defined in the object, and if the object is poorly encapsulated, that can lead to tight coupling. So I still don't understand why that answer is correct. To me it is very illogical. Hopefully the real exam doesn't have any of these, because if it does I'm going to have some problems.

[Robert O'Leary]

Ruben Soto wrote:
Robert, I understand that composition is favored over inheritance (when composition is more appropriate.) But using composition simply doesn't assure low coupling. When you have a reference to an object, you may use any public members defined in the object, and if the object is poorly encapsulated, that can lead to tight coupling. So I still don't understand why that answer is correct. To me it is very illogical. Hopefully the real exam doesn't have any of these, because if it does I'm going to have some problems.

Yes composition doesnt assure low coupling, but it suggest good OO design is being used. And if good OO design is being used, youd like to think the object is encapsulated well. For an exam question you shouldnt have to make assumptions and I think it is an area is badly covered. I always stop at these OO questions and think WHAT are they trying to say here. For me there definition of encapsulation is wrong too, encapsulation and information hiding are two separate concepts IMO. I suppose recognising the exam is flawed is important, you just need to try to see what they're thinking, however illogical it seems to you!

That was Im amazed that people get 98% or so in the exam, when topics like this are sketchy

[Ryan Beckett]

Like you said, composition doesn't assure low coupling. Its easy to see the question is misleading because it doesn't mention anything about a public interface. How can you ask something like that w/o providing all the details? I mean, were coders?!?! We dig deeper and deeper.

I think HAS-A promotes low coupling in comparison to IS-A in the context of inheritance. Implementation inheritance vs. interface inheritance. You have to watch your subclass overrides for possible scenarios that will break the code with IS-A whereas you don't have to worry about that using composition with interfaces. IS-A is perfectly fine if you don't make derived classes dependent on the super class.

That's the only time I've ever heard composition directly promoting low coupling. I DO however think composition promotes good OO design, because it allows classes to be specialized and more likely to be reusable, maintainable, and extendable.

[Ruben Soto]

Thanks for your answers. I understand what you mean, and at least I am glad to know I'm not the only one who thinks that this type of question is misleading (although I am more convinced that the answer is just plain wrong, since composition can never ensure on its own loose coupling.)

Composition and inheritance are almost the same regarding coupling (if you ignore the protected access modifier.) But I agree they are different OO tools, and sometimes composition is more indicated than inheritance (and the other way around.)