Win a copy of Practice Tests for OCP Java 17 Certification Exam (1Z0-829) this week in the OCPJP forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

Encapsulation, coupling and cohesion

 
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

What will be the correct answer?



 
Ranch Hand
Posts: 144
Oracle Fedora Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe the answer is Tight Coupling as well. Look specifically at this following

This code is dependent on the class having a default constructor and the setColor method being public or even existing. If the Car's constructor changes or someone decides that you can no longer change the Car color (setColor is made private), you are forced to update this code of the Driver class. To limit coupling you should do the following


Edit: It is bad forum practice to post multiple threads about the same topic. You should have post this as a reply to your other thread.
 
Greenhorn
Posts: 7
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To achieve loosely coupling you need to make both classes independent from each other (as much as possible). Mike's example is a good one. I would even create some Vehicle interface that would be passed to the Driver constructor instead of Car type. In such case we can pass not only a Car object but any object that implements such interface.
 
Matloob Hussain
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

if we change to:



How do we set the value of instance variable (private String color from Car class) in Driver class ?



 
Tomski Simon
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can set Car colour in the main method and once when your Car object is ready you can pass it to the Driver constructor.
 
Matloob Hussain
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I changed the code. Is this right?


and if it is right then could you please explain how the Driver class is independant from class Car.

As I know, Car has private instance method, It only can access via setter/getter methods and to invoke these methods we have to create instance of Car class then how does it becomes independant.

Thanks....

Matloob
 
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Guys,
OO-application-design-patterns are quite "subjective"...However, lets try and analyse the scenario...before I continue I have a question to ask; why did you guys say it is tight coupling? IMHO there is NO tight coupling here because the ONLY visible members of the Car class is its API, oweing to the fact that it is 'well-encapsulated'.
The problem that I see here is low cohesion REMEMBER that cohesion is the degree to which a class has a single WELL-FOCUSED purpose. That said, the drivers constructor is setting the color of the Car and the Drivers class getting the colour, a drivers job is to drive, NOT to get NOR to set colors of the vehicles they drive...

@Matloob the modification you did to your code is good, the ONLY thing that IMHO is NOT 'coherent' is the getColor() method, if you need the color of the Car, you can retrieve that information right there in the main method (car.getColor()). Lets modify the applications;




You can observe that as the above applications stand, both classes now have well-focused-purposes, their design is high cohesion.

P.S. The main method can perfectly fit into a neutral class.

Regards

Ikpefua



 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matloob Hussain wrote:As I know, Car has private instance method



Lets assume that the above is a 'typo-error' but let me correct you just-in-case;

-Car has public instance methods AND a private instance variable.
 
Matloob Hussain
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Thanks Ikpefua for correcting the typo-error. I am trying to learn how to achieve loose coupling from tight coupling.

Mike wrote:
If the Car's constructor changes or someone decides that you can no longer change the Car color (setColor is made private), you are forced to update this code of the Driver class.



After updating new code, if we made any changes in Car class. Does it not force to update the code of Driver class?

Matloob
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matloob Hussain wrote:After updating new code, if we made any changes in Car class. Does it not force to update the code of Driver class?


If I understand what you mean...The answer is NO. It does NOT force any updating in the Drivers class.
However it is IMPORTANT to note that whatever changes you make to the Car class MUST adhere to OO principles.

regards

Ikpefua.
 
Matloob Hussain
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am still confused. Might be, I am thinking in wrong way.

If Car's constructor make some changes in Car class like , setColor() method change to private and add new constructor then the class Driver has to be changed becuase if we try to access privae method, it give compile error.



 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Matloob... If you make a getter or setter method private that means your class is BADLY encapsulated, in Object Orientation, good encapsulation means PRIVATE instance variables AND PUBLIC getter and setter methods, the ONLY thing you can do to the method is modify the implementation that is the codes INSIDE the curly brackets. I hope you understand better now.
 
Matloob Hussain
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks... Ikpefua.
But Mike wrote:

"the Car's constructor changes or someone decides that you can no longer change the Car color (setColor is made private), you are forced to update this code of the Driver class"

My code was:


and new suggested code to achieve the loose coupling:



Could you please explain the new changes. I am trying to learn how to achieve loose coupling state from tight coupling state. If you could explain in your way or do you know any other explaination with examples. It really helps me.

My task is if someone gives me code which is in tight coupling state and ask me to do some changes in code to achieve loose coupling state which rules should I follow.

Thanks once again...


Matloob


 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Matloob, there is NO problem of loose coupling nor tight coupling here, the problem with this class is low COHESION, I said it before. It is BAD design (low cohesion) for the constructor of a driver to set the color of the car:

In this code the constructor of the driver is 'setting' the color of the Car, it is (LOW-COHESION).
There is NO tight-coupling here.

Now this is tight coupling:

The tight coupling will ONLY be possible if the instance variable color in Car's class is marked with a 'public' access modifier (POOR-ENCAPSULATION).

-cohesion... classes should have a well-focused purpose...do you understand this?
-coupling... the degree to which classes know of themselves
-loose coupling... you should ONLY have access to public getter and setter methods
-tight coupling... you HAVE access to public getter, setter AND instance variables

Lets do some poor-encapsulation and tight-coupling.

-Poor encapsulation

You can observe that the instance variable has a 'public' access modifier (Poor encapsulation)
Good encapsulation -'private' instance variable AND 'public' getter and setter methods-.

-Tight coupling

In Object Orientation, loose coupling means that you should ONLY have access to the classes A.P.I and when I say A.P.I, I mean the public getter and setter methods.

Do you have futher doubts? if yes let me know the SPECIFIC part of the code where you are confused, try and search for codes that have similar problems, bring them here and lets analyze them together.

regards

Ikpefua
 
Matloob Hussain
Ranch Hand
Posts: 37
MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In SCJP Sun Certified Programmer for Java 6 Study Guide by Katherine Sierra and Bert Bates (K&B):
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.


So it means to acheive loose coupling state , It must be well encapsulated( protected instance vaiables using private modifier)

Upto here, I think, I might be right. But I do not undstand the two other requirements for loose coupling.
The first one is "minimize references to each other"
The second one is "limit the breadth of API usage"

I studied the following explaination written by Steve:
https://coderanch.com/t/417221/java/java/Loose-Coupling

As I understand: Please correct me if I am wrong or if I am missing something.

Encapsulation:

1-Only one class is involved in encapsulation.
2-If instance variables are private and getter and setter are public then it is "well ecncapsulated".
3-If instance variables, getter and setter are public then it is "poor encapsulated".


Coupling:

1- More than one classes are involved in coupling.
2- These classes must be well encapsulated.
3- If classes A.P.I are accessed by using the reference of interface (which makes independent) then it means, It has loose coupling.
4- If classes A.P.I are accessed by using the reference of concrete class (which makes dependent) then it means, It has tight coupling.


So to acheive loose coupling state, it need following steps:
1- make it well encapsulated
2- implements interface
3- use the interface reference to access classes A.P.I
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matloob wrote:"minimize references to each other", "limit the breadth of API usage"



Matloob these expressions are subjective to loose coupling, as you may already know.
"minimize references to each other" what part of this statement dont you understand? minimize?, references?, to each other?.
"limit the breadth of API usage" what part of this statement dont you understand?, limit? breadth? API usage?

I am inviting you to read over and over again, sometimes this helps us understand things better.

Regards

Ikpefua.
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matloob Hussain wrote:
As I understand: Please correct me if I am wrong or if I am missing something.

Encapsulation:

1-Only one class is involved in encapsulation.
2-If instance variables are private and getter and setter are public then it is "well ecncapsulated".
3-If instance variables, getter and setter are public then it is "poor encapsulated".


Coupling:

1- More than one classes are involved in coupling.
2- These classes must be well encapsulated.
3- If classes A.P.I are accessed by using the reference of interface (which makes independent) then it means, It has loose coupling.
4- If classes A.P.I are accessed by using the reference of concrete class (which makes dependent) then it means, It has tight coupling.


So to acheive loose coupling state, it need following steps:
1- make it well encapsulated
2- implements interface
3- use the interface reference to access classes A.P.I



Your understanding seems pretty solid, but I want to point out a couple things.

First about your item 3 for Encapsulation: the accessibility of getter and setter methods doesn't really affect encapsulation.
It is the accessibility of the instance variables. A class could be designed with no getter and setter methods (because, the
designer thinks, they aren't needed), but if the state of its variables can be changed directly, then its encapsulation is poor.

Consider this:



See that by giving the color variable default access, I have made the Car object unable to be aware that I have changed its color from red to blue.

Second, your item 2 under coupling. I think you understand this, but I just want to make sure. It makes it seem as if coupling
can only occur when classes are well encapsulated, and of course this is not the case. We can couple two classes that are poorly
encapsulated, and often the poor encapsulation is what is at the root of tight coupling.
 
reply
    Bookmark Topic Watch Topic
  • New Topic