Когда подходящее время использовать универсальные классы в Java - PullRequest
Новая
       26

Когда подходящее время использовать универсальные классы в Java

1 голос
/ 09 марта 2012

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

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

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

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 () и создает конкретные объекты, необходимые для каждого отдельного типа запроса / операции, и возвращает их в виде объектов, с которыми маршаллер не сталкивается с проблемами, поэтому мне не нужно больше конкретный с типами возврата.

Ответы [ 2 ]

0 голосов
/ 09 марта 2012

Я бы не советовал разбирать 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>
0 голосов
/ 09 марта 2012

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

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

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

для подклассов, которые вы объявите 

public class GetStatusQuery extends SOSquery<GetStatusParticularType> {

это то, что тебе нужно?

...