Alternative to Strategy Pattern

[Mark Reyes]

Hi All,

I am trying to apply OO principles in some of the project that I am working right now.
But I am not sure if this is correct.

For some readings on the net about OO principles, I always see that 'You should encapsulate what varies'.

I try to apply it in what I am working right and its about how to draw the UI of my apps.

Say, I notice that the way UI are being drawn is what varies in my apps so I created this interface.

public interface CreateUI {
	public void drawUI();
}

and in my Concrete class I have an instance variable referring to this.

public class TransactionUI {
	protected CreateUI myUI;
	protected int iReportID;
	
	public TransactionUI(int iReport) {
		this.iReportID = iReport;
	}
	
	public void open() {
		if (iReportID == 1) {
			myUI = new AddTrans();
		}else if(iReportID ==2) {
			myUI = new DeleteTrans();
		}
		
		myUI.drawUI();
	}
}

Now, I have this class implements the transaction

public class AddTrans implements CreateUI{
	public void drawUI() {
		//create add trans UI here
	}
}

public class DeleteTrans implements CreateUI{
	public void drawUI() {
//		create delete specific ui here
	}
}

Now, I am a bit confused about the instantiation of the class. Dont you think, my hierarchy is not good? Because I need to hard code the class to be instantiated and I cannot protect this class from further change.

I am not sure, but I think what I am doing is what they call as Strategy Pattern. Though I have not done much reading about design patterns.
I think this class is still volatile to change. Could you comment on this?

[ramesh maredu]

The only issue I could see here is creating the instance of concrete class should be moved outside, I guess you can use factory pattern.