Одиночный класс с несколькими значениями параметров конструктора или многими классами?

У меня есть класс Response, который содержит HTTP-ответ с кодом состояния HTTP, например, 200 или 404, и несколько других вещей, таких как имя вида и объект домена. Но давайте сосредоточимся на коде состояния. Я мог бы использовать один класс и передать статус в качестве параметра:Одиночный класс с несколькими значениями параметров конструктора или многими классами?

public class Response { 
    private int status; 
    public Response(int status) { 
    this.status = status; 
    } 
} 

// in a handler method: 

return new Response(HttpStatus.OK);

Другой путь будет создать новый класс для каждого кода состояния (41 кодов состояния в HTTP 1.1). Как это:

public class Ok extends Response { 
    public Ok() { 
    super(HttpStatus.OK); 
    } 
} 

// in a handler method: 
return new Ok(); 


public class Created extends Response { 
    public Created() { 
    super(HttpStatus.CREATED); 
    } 
} 

// in a handler method: 
return new Created();

В действительности будет, как правило, больше параметров, как имя вида и объект домена, как этот new Response(HttpStatus.OK, "customer", customer) соответствующего new Ok("customer", customer).

источник

2010-07-13 deamon

Имеет ли каждый код состояния разную уникальную обработку, или все они выполняют одну и ту же вещь, кроме # их разных? Если классы не приносят ничего нового в таблицу, не используйте их. –

Статус отправляется клиенту, но для серверной части они очень похожи, с небольшим исключением для кодов ошибок, которые обрабатываются немного иначе, чем базовый API сервлета, но это не входит в компетенцию класса (es), показанных выше. – deamon

@David - Это будет хороший ответ, а не комментарий. – Alohci

Спросите себя - вы нужны разные «типы» для каждого кода состояния? Это может быть полезно, если, например, вы хотите использовать определенный тип, скажите OK как параметр для некоторого метода. Если нет, я не вижу преимуществ второго подхода. Пойдите для первого.

источник

2010-07-13 20:11:27 samitgaur

моя рекомендация 1) если нет никакого поведения, связанного с каждым кодом состояния, тогда нет необходимости в новых абстракциях. 2) использовать перечисления для констант вместо int

источник

2010-07-13 20:07:38

Вы правы, переписчики лучше. Интересно, следует ли мне разрешать другие коды статуса, чем те, которые определены HTTP 1.1. – deamon

определяют перечисления, которые ближе к вашему бизнес-домену, чем этот протокол. Если вы считаете, что они специфичны для протокола и все еще должны иметь их, то u не должен определять новые константы enum и рассматривать их так же, как HTTP OK и т. Д. –

Я бы сохранил конструктор просто. Что-то вроде:

public Response(int status) 
public Response(int status, String reasonPhrase) 
public Response(int status, Map<String,String> headers) 
public Response(int status, String reasonPhrase, Map<String,String> headers)

Или, возможно, опустить последнюю 2 и обеспечить setHeader(String, String)

источник

2010-07-13 20:08:59

«Чистый» способ - иметь тип для каждого отдельного значения, но на практике это может быть излишним.

Вообще говоря, считают ли:

Существует любую уникальная обработка (которая поддается классы)
ли может быть иерархия между объектами (например, статусами представляющим успеха и статусы, представляющие ошибки).

По моему опыту, если в домене есть иерархии, они часто попадают в код. Вы можете сохранить будущий рефакторинг, планируя это. Например, в статусах ошибок могут также появляться такие вещи, как сведения об ошибках.

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

Кроме того, при получении данных из фиксированного домена перечисление может быть лучше, чем прямой int.

источник

2010-07-13 20:11:48 Uri

Одиночный класс с несколькими значениями параметров конструктора или многими классами?

ответ

Смежные вопросы