Reputation: 1600
I am new to design patterns and I have the following need: I have a set of events represented by DTO objects like: LateEventDTO, RescheduleEventDTO,etc. Each of these DTO objects have their own set of properties. Right now, I have an abstract class called EventDTO and all different types of DTO objects like LateEventDTO,RescheduleEventDTO,etc extend the EventDTO.
I will be passing one of these DTO objects to my ui layer (jsp page) which checks what type of DTO object it is. Like this:
if(event instance of Late){
//handle late event and display it's content
}
else if(event instance of Reschedule){
//handle reschedule event and display it's content
}
And so on and so forth.
What i want is to make the presentation layer oblivious to the different type of eventDTO objects. All it needs to do is get a generic object and display it's contents. It shouldn't check for it's type explicitly like i showed above.
What would be the best design pattern for this scenario?
Upvotes: 2
Views: 1230
Reputation: 5101
Make coherent classes, not DTOs
That will fix this misapplication of abstract class
polymorphism.
Extending abstract class
is the strategy pattern (see @Crazy Ninja comment). abstract class
instead of interface
does not make it less so.
The point of extending an abstract class is so each instance can be handled the same. If you have to figure out what type each instance is, then why bother?
If the below does not meet your design needs, you still need to make coherent classes - classes that do something, not just contain fields/properties.
P.S. this may not be valid Java syntax.
Your code should look more like this:
public abstract EventBase {
// declare common properties here.
public virtual void Handle () {
// code to handle the properties.
// maybe there is some behavior for the base properties.
}
// Depending on how you're going to display contents, you
// may want to override toString()
public override string toString() {
// format the DTO thingies as needed.
}
}
public class RescheduleEvent extends Eventbase {
// define RescheduleEvent unique properties here
public override string toString(){
string whoAMI = base.toString();
whoAMI = whoAMI + .....
return whoAMI;
}
public override void Handle() {
base.Handle():
// do stuff
}
}
// client code.
myRescheduleEvent.Handle();
myWhateverEvent.Handle();
// or
foreach( Eventbase anEvent in eventList) {
anEvent.Handle();
DisplaySomething(anEvent.toString());
}
Upvotes: 3
Reputation: 23029
Well if you have one page and you want to show different classes with different properties, you have to specify which property should show in which place in the JSP page.
One way would be to have object the JSP page understands where you have some "always show" variables and then some kind of list of "other" properties you want to show.
The question is - how to map these DTOs into this new objects? The constructor is an answer (and yes, some manual work is needed as well).
public class JspUndestandableClass(){
public JspUndestandableClass(LateEventDTO lateEventDTO){
....
}
public JspUndestandableClass(RescheduleEventDTO rescheduleEventDTO){
....
}
}
Then you can simply create these objects in your controller and pass it to JSP page.
PS : Design patterns show good way to solve some problems, but they do not save you itself (ie using them in wrong use-cases) and they do not cover every situation.
Upvotes: -1