aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes tight versus loose coupling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "tight versus loose coupling" Watch "tight versus loose coupling" New topic
Author

tight versus loose coupling

Rachel Glenn
Ranch Hand

Joined: Oct 24, 2012
Posts: 95
UGH, another ambiguous question..this is from a mock exam

Given:

21. class Wheels {
22. private Bike bike;
23. void setBike(Bike b) { bike = b; }
24. }
25.
26. class Bike {
27. private Wheels [] wheels = new Wheels[5];
28. void setWheels(Wheels [] w) {
29. if( w.length == 2)
30. wheels = w;
31. }
32. }

Which is true?
A. Compilation fails.
B. These classes are NOT coupled.
C. These classes are loosely coupled.
D. These classes are tightly coupled.
E. These classes are abstractly coupled.



(Option D is correct because both classes have references to instances of each other.)

Why is this considered tight coupling? Internal changes to either Wheels or Bike classes do not affect the other class. What would make these considered as being loosely coupled?
Zhenyi Luo
Ranch Hand

Joined: Sep 03, 2012
Posts: 33
Rachel Glenn wrote:UGH, another ambiguous question..this is from a mock exam

Given:

21. class Wheels {
22. private Bike bike;
23. void setBike(Bike b) { bike = b; }
24. }
25.
26. class Bike {
27. private Wheels [] wheels = new Wheels[5];
28. void setWheels(Wheels [] w) {
29. if( w.length == 2)
30. wheels = w;
31. }
32. }

Which is true?
A. Compilation fails.
B. These classes are NOT coupled.
C. These classes are loosely coupled.
D. These classes are tightly coupled.
E. These classes are abstractly coupled.



(Option D is correct because both classes have references to instances of each other.)

Why is this considered tight coupling? Internal changes to either Wheels or Bike classes do not affect the other class. What would make these considered as being loosely coupled?


Internal changes to either Wheels or Bike classes will affect the other class, setBike is in Wheels class and setWheels is in Bike class.
Rachel Glenn
Ranch Hand

Joined: Oct 24, 2012
Posts: 95
Zhenyi Luo wrote:
Rachel Glenn wrote:UGH, another ambiguous question..this is from a mock exam

Given:

21. class Wheels {
22. private Bike bike;
23. void setBike(Bike b) { bike = b; }
24. }
25.
26. class Bike {
27. private Wheels [] wheels = new Wheels[5];
28. void setWheels(Wheels [] w) {
29. if( w.length == 2)
30. wheels = w;
31. }
32. }

Which is true?
A. Compilation fails.
B. These classes are NOT coupled.
C. These classes are loosely coupled.
D. These classes are tightly coupled.
E. These classes are abstractly coupled.



(Option D is correct because both classes have references to instances of each other.)

Why is this considered tight coupling? Internal changes to either Wheels or Bike classes do not affect the other class. What would make these considered as being loosely coupled?


Internal changes to either Wheels or Bike classes will affect the other class, setBike is in Wheels class and setWheels is in Bike class.


Thank you for your reply, but I am still unclear.

Lets look at the class Wheel. It has a member variable; Bike bike. But that is it. It only has a reference to this class. It doesn't call any of Bike's member functions or access any of Bikes' variables. To me, this is a simple has-a relationship. If the internal structure of Bike changes, Wheels is not affected at all. So how is this specific relationship 'tight coupling'?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: tight versus loose coupling