Question about Encapsulation

I have a question about Encapsulation. I know the concept of the encapsulation as..

Anytime we have behavior in an application that you think is likely to change you want to move that behavior away from parts of the application that won't change
frequently.In other way we try to encapsulate it.

Now lets see example of it

I have a class Painter having a method paint()

Painter
--------------------------
paint()

but, paint() implemention may be varied depending upon object. Hence I want to encapsulate it.

What you are doing is creating two fields with the same name (one in PaintStyle, one in Painter), so you can get confusion between the field in the suprclass and the field in the subclass.

Does Painter really extend PaintStyle: can you say a Painter "IS-A" PaintStyle? If no, then you shouldn't write "extends PaintStyle".
You have a field in the PaintStyle class of PaintStyle type; that doesn't look right. you should have some sort of other detail, eg String styleName in the PaintStyle classYou can put the names and styles into a Map, if you know how Maps work.

Then you want a PaintStyle field in the Painter class.

I haven't got the time to give a more complete answer at the moment.

Rahul Ba

Ranch Hand

Posts: 212

posted 9 years ago

Thanks Campbell. I agree on whatever you said, but does it implies encapsulation?

Rahul Ba

Ranch Hand

Posts: 212

posted 9 years ago

Hi all,

I have a question about Encapsulation. I know the concept of the encapsulation as..

Anytime we have behavior in an application that you think is likely to change you want to move that behavior away from parts of the application that won't change
frequently.In other way we try to encapsulate it.

Now lets see example of it

I have a class Painter having a method paint()

Painter
--------------------------
paint()

but, paint() implemention may be varied depending upon object. Hence I want to encapsulate it.

Now I have updated painter class, which was previously extending PaintStyle class.

Campbell Ritchie

Marshal

Posts: 57446

175

posted 9 years ago

Better, but still incomplete. I would suggest you set up your pt in a constructor, otherwise you are risking problems with null references.
I would suggest you have a paint() method in the PaintStyle class (maybe abstract) and use polymorphism.

Add a paint() method to the Painter class, like this:

Rahul Ba

Ranch Hand

Posts: 212

posted 9 years ago

I would suggest you set up your pt in a constructor, otherwise you are risking problems with null references.

Hi, you said this statement....I am hearing this first statement and very enthu. to know how will it risk to null references?

Campbell Ritchie

Marshal

Posts: 57446

175

posted 9 years ago

If you have an object of the Painter class, until the setPaintStyle method is called, the pt reference points to null. If you attempt to use it, you will have no information available, and may suffer an Exception.
If you set up pt in a constructor, it will only be null if somebody writes