Encapsulating the business logic with a POJO façade - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 252

public Date getDeliveryTime();
public RestaurantDetail getRestaurantDetail();
public double getTotal();
…
}
public class PendingOrder implements PendingOrderDetail {
…
public .. updateDeliveryInfo(..) {…}
}
The JSP page that displays the PendingOrder would use the PendingOrderDetail
rather than PendingOrder .
Read-only interfaces are mostly straightforward to implement. One problem
with using interfaces in JDK 1.4 and earlier is that because the return types are dif-
ferent, a getter that returns a view interface must have a different name than the
getter that returns the real object. For example, PendingOrderDetail defines
getRestaurantDetail() , which PendingOrder must implement as follows:
class PendingOrder implements PendingOrderDetail {
public RestaurantDetail getRestaurantDetail() {
return getRestaurant();
}
public Restaurant getRestaurant() {
…
}
…
It is tedious to write these methods and they clutter the code. Fortunately, Java 5
eliminates the need to write these extra methods by supporting covariant return
types. A subclass can define an overloaded method whose return type is a subtype
of the return type specified in the inherited method. This means, for example,
that the following code is legal:
interface PendingOrderView { RestaurantView getRestaurant(); }
class PendingOrder implements PendingOrderDetail {
public Restaurant getRestaurant() { … };
…
Getters that return collections do not have this problem in JDK 1.4 because collec-
tions are untyped. The presentation tier can cast each element to the view inter-
face. For example, the presentation tier can cast each element of the List
returned by PendingOrderDetail.getLineItems() to a PendingOrderLineItem-
Detail . A Java 5 application can use typed collections with wildcards to enable a
subclass to override a method with a different return type.