Question about Encapsulation

[Rahul Ba]

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.


let's say now I can no in this way

Painter
---------------------------------
setPaintStyle(PaintStyle pt);

Please check whether I did use encapsulation properly?

here is the code

  
public class Painter extends PaintStyle{

	String  name;
	PaintStyle pt = null;
	
	public void setPainterStyle(PaintStyle pt){
	this.pt = pt;	
	}
}

 public abstract class  PaintStyle {

	PaintStyle pt = null;
	
	public PaintStyle getPaintStyle(){
		return pt;
	}
	
	public void paint(){
	}
}

 public class PaintBlue extends PaintStyle{


	public void paint() {
		System.out.println("We are painting Blue color.");
	}

}   

public class PaintBlack extends PaintStyle{

	public void paint() {
		System.out.println("We are painting Black color.");
	}

}

and at a Last My main class is

public class TestPainter {
	public static void main(String[] args) {
	
		Painter pnt = new Painter();
		PaintStyle paintBlue = new PaintBlack();
		pnt.setPainterStyle(paintBlue);
		paintBlue.paint();

	}
}

[Campbell Ritchie]

Afraid I don't think so.

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 class

public class PaintStyle
{
   private String styleName;

   public PaintStyle(String styleName)
   {
       this.styleName = styleName;
   }
}

. . .

   . . . new PaintStyle("Impressionist");

You 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]

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

[Rahul Ba]

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.


let's say now I can no in this way

Painter
---------------------------------
setPaintStyle(PaintStyle pt);

Please check whether I did use encapsulation properly?

here is the code

  
public class Painter{

	String  name;
	PaintStyle pt = null;
	
	public void setPainterStyle(PaintStyle pt){
	this.pt = pt;	
	}
}

 public abstract class  PaintStyle {

	PaintStyle pt = null;
	
	public PaintStyle getPaintStyle(){
		return pt;
	}
	
	public void paint(){
	}
}

 public class PaintBlue extends PaintStyle{


	public void paint() {
		System.out.println("We are painting Blue color.");
	}

}   

public class PaintBlack extends PaintStyle{

	public void paint() {
		System.out.println("We are painting Black color.");
	}

}

and at a Last My main class is

public class TestPainter {
	public static void main(String[] args) {
	
		Painter pnt = new Painter();
		PaintStyle paintBlue = new PaintBlack();
		pnt.setPainterStyle(paintBlue);
		paintBlue.paint();

	}
}

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

[Campbell Ritchie]

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:

public void paint()
{
   pt.paint();
}

[Rahul Ba]

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]

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

new Painter(null)