Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been asked to support a Java EE application. The data model was poorly-designed and will not support several necessary use cases; so I'm developing a new data model using EclipseLink (the old one was built on iBATIS). Mind you, I'm no EclipseLink guru, and still have many questions about the best ways to utilize it.

For example, the current application has different entities for different types of requests-- let's say, CakeRequest, PieRequest, DonutRequest, etc. My first thought was to create a base Request type, then extend that with PieRequest, which can have fields specific to it, such as crustType and hasCoolWhip. Certainly, EclipseLink can do that.

However, I also need the ability to list all Requests, starting with the most recent. I'm not sure what the best way to handle this would be. In order to sort requests together, I need to be able to put all request types in a single collection, which defeats the purpose of polymorphism.

It could be that there are EclipseLink features which would help me out here, features that I'm unaware of; or perhaps Java itself could provide the answer. Does anyone have any suggestions? Thanks very much!

share|improve this question
add comment

2 Answers 2

I'm not sure if this will fit your needs - please let me know if I misunderstood.

If the request date is in the Request class, why can't you have a collection of them?

ArrayList<Request> requests;

// do some stuff

// Sort code
// ...
...request.get(i).getDate()...
//...

This will not violate encapsulation in the slightest. Date should probably be part of the Request, as it is not type-specific.

share|improve this answer
add comment

Using a base subclass like Request seems like a perfectly reasonable solution. I hesitate to call out a "correct" solution, since there often isn't a single correct solution, and I know little about your specific context.

I'm not sure how putting all request types in a single collection (by using the base class as the type) defeats the purpose of polymorphism; in fact it would seem to make use of one of the key facets of polymorphism, substitutability.

PieRequest pieRequest = new PieRequest();
CakeRequest cakeRequest = new CakeRequest();
// and so on
List<Request> requests = new ArrayList<Request>;
requests.add(pieRequest);
requests.add(cakeRequest);
// and so on

for (Request request: requests) {
    doSomething(request.getDate());
    // etc.
}
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.