Hi, This is from K&B mock exam
HAS-A relationships are tightly coupled.--FALSE. Why ?? Could you please give a sample example why it is False.
Given Answer is : while has-a relationships can lead to tight coupling, it is by no
means always the case.
HAS-A relationship can be achieved with the Class reference and with the Interface reference. If it's with Class reference, then tightly coupled. And, if it's with Interface, the loose coupling. So, always the HAS-A relationship aren't tightly coupled. Hence it's false.
EDITED : A typo.
|BSc in Electronic Eng| |SCJP 6.0 91%| |SCWCD 5 92%|
Joined: Sep 23, 2010
Thanks Abimaran. Here they did not say anything about class or interface. So, why it should be tightly coupled (class implementation).
Harikrishna Gorrepati wrote:Thanks Abimaran. Here they did not say anything about class or interface. So, why it should be tightly coupled (class implementation).
Let's ahev an example then,
Here, with the Car reference, it's tight coupling between the TestCoupling and Car. But, with the interface Bounceable reference, it's loose coupling, because, you don't need to care whether it's a Car instance or Ball instance. That's the concept of loose coupling.
1. Highly Cohesive - Classes should have well focused purpose.
2. Loosely Coupled - Degree to which one class knows the other.
Consider following real world example for the coupling with has-a relationships.
Say we have to define a House class. Think about how you can organize it.
1. House has Windows
2. House has-a Roof
3. House has-a Radio
4. House has Walls
Can you select the irrelevant relationship from above 4 items? (but possible to define in a class)
See, item 3 is not that matching with other three. If you define a House with a Radio it will be tightly coupled. But others are very well explained the House class, then the rest becomes loosely coupled.
Now you will see that following statement is correct.
"while has-a relationships can lead to tight coupling, it is by no
means always the case"
Loose coupling is a design pattern, it simply means that individual design elements should be constructed so the amount of unnecessary information they need to know about other design elements are reduced. So, my above example suits more.