1 Reply Latest reply on Sep 6, 2010 2:05 PM by walterln

    Migrating Legacy APIs to use Generics

      I am migrating a DB facade type API to use generics.
      This class can execute queries and has a API of the form

      public List query(Query myQuery);

      Obviously I'd much prefer to return a type safe list e.g.

      public <T extends BusinessEntity List<T> query(Query<T> myQuery);

      So the Query class has a concept of a Type which has relevant so API's it is used in knows what type it is returning.
      My first question is, I feel a bit parameterising the Query class. The only reason why it is parameterised is so that when it is used in API's such as above.
      It has not other purpose. Have I gone off on a tangent here?

      Also, in some cases when the Applicaion is creating Query objects, it's obvious what to set the generic parameter to and it's very easy.
      But for other cases it's not or it's not as important that it is set.

      This could mean the design ends up where sometimes Query is parameterised and sometimes it is not. This sounds very messy.

      I would appreciate your opinions :-) Are my better off just not parameterising the Query class?

      I would then have an API such as:

      public List<? extends BusinessEntity> query(Query query);

      Maybe that's a better way to go? Any rule of thumb here?

      Note: before anyone says it JPA is not possible :-)