2012-03-08 2 views
1

Я создаю интерфейс отдыха в существующем проекте. Проект имеет класс, который определяет около 4 различных типов операций. Для определения параметров запроса каждая операция принимает объект другого типа. Каждая операция возвращает объект другого типа, все из которых являются объектами, закодированными в jaxb XML, и в конечном итоге становятся связанными с OutputStream.Когда подходящее время для использования общих классов в Java

Я анализирую параметры из URL-адреса и строю объекты запроса, необходимые для различных операций. В настоящее время у меня есть абстрактный родительский класс запроса, класс QueryFactory, который переключается между типами запросов и возвращает дочерний класс запроса, специфичный для типа запроса в URL-адресе. Все дочерние классы запросов реализуют абстрактный метод «buildQueryParameters» и получают результат как тип объекта.

Насколько это хорошо? Есть ли какой-нибудь причудливый способ использования параметризованных типов или общих классов для создания объектов параметров запроса? Я считаю себя строить эти заявления переключения на всем протяжении моего кода, чтобы различать типы запросов, и я не уверен, что это лучший способ ...

Edit:

Я подклассы, потому что мой код выглядит сервлетов как это:

Query query = QueryFactory.getInstance(parameterMap, requestEnum); 
query.buildQueryParams(); 
Object queryParams = query.getQueryParams(); 

Запрос завод довольно прямо вперед:

public static Query getInstance(Map<String, String> parameterMap, RequestEnum requestEnum) { 
     switch (requestEnum) { 
      case GETSTATUS: { 
       return new GetStatusQuery(parameterMap); 
      } 
      case DESCRIBEOPS: { 
       return new DescribeOpsQuery(parameterMap); 
      } 
      case GETSTATUSBYID: { 
       return new GetStatusByIdQuery(parameterMap); 
      } 
      case GETEVENTS: { 
       return new GetEventsQuery(parameterMap); 
      } 
      default: 
       break; 
     } 
     return null; 
    } 

абстрактный класс запроса также скучный:

public abstract class Query { 

    protected Map<String, String> validatedMap; 
    private Object queryParams; 

    public SOSQuery(Map<String, String> parameterMap) { 
      this.parameterMap = parameterMap; 
     } 

     public Object getQueryParams() { 
      return this.queryParams; 
     } 

     public abstract void buildQueryParams(); 

     protected void setQueryParams(Object queryParams) { 
      this.queryParams = queryParams; 
     } 

     protected Map<String, String> getParameterMap() { 
      return this.parameterMap; 
     } 

Каждый дочерний класс реализует buildQueryParams() метод и создает определенные объекты, необходимые для каждого типа запроса/операции и возвращает их как объекты, которым маршаллер не имеет никакой обработки проблемы, поэтому я не обязательно чтобы быть более конкретными с типами возврата.

+0

Покажите нам код. –

+0

Почему у вас есть подклассы Query (дочерние классы) вообще? Вы можете просто создать некоторые константы для имен параметров и использовать их для установки и получения правильных значений в QueryFactory (который больше не является фабрикой (TM) *)/соответствующими методами. –

ответ

0

вы можете объявить public abstract class SOSQuery<T> {, а затем private T queryParams;

public T getQueryParams() { 
    return this.queryParams; 
} 

и так далее ...

для подклассов вы бы объявить

public class GetStatusQuery extends SOSquery<GetStatusParticularType> { 

это то, что вам нужно?

+0

Ну, это не будет иметь никакого реального разницы в моей текущей реализации, даже если это дает дополнительное преимущество для возврата фактического типа объекта, хотя я все равно просто получу его как объект в моем сервлете ... но я думаю это все равно стоит реализовать. Думаю, с тех пор, как я не полностью понял преимущества объявления моего собственного родового класса, я не был уверен, что и как я могу их использовать. Я предполагаю, что это касается того, насколько полезны дженерики, и я приму свой ответ :) – Bal

0

Я бы не рекомендовал самостоятельно анализировать URL-адреса. Вся привязка может быть автоматической с использованием JAXB и JAX-RS.

Пример:

Определение услуги:

@Path("/app") 
@Produces("application/xml") 
public interface TestService {  
    @POST 
    @Consumes("text/xml") 
    @Path("/addType") 
    public Policy setTypePolicy(Policy p); 

    @GET 
    @Path("/server/{server}/service") 
    public Services getTypesOnServer(@PathParam("server") String serverName); 
} 

Определить модель:

<element name="policy"> 
    <complexType> 
    <sequence> 
      <element name="name" type="string" /> 
      ... 
     </sequence> 
    </complexType> 
</element> 
Смежные вопросы