У меня есть клиентская библиотека, в которой я делаю http-удаленные вызовы для службы отдыха, а затем возвращаю List<DataResponse>
обратно клиенту, который звонит в нашу библиотеку с ответом, который я получаю от своего REST службы вместе с любыми ошибками, если есть какие-либо обернутые вокруг объекта DataResponse
.Как избежать создания длинных конструкторов
public class DataResponse {
private final String response;
private final boolean isLink;
private final TypeOfId idType;
private final long ctime;
private final long lmd;
private final String maskInfo;
// below are for error stuff
private final ErrorCode error;
private final StatusCode status;
// constructors and getters here
}
Вот мой ErrorCode
перечисление класс:
public enum ErrorCode {
// enum values
private final int code;
private final String status;
private final String description;
// constructors and getters
}
А вот мой StatusCode
перечисление класс:
public enum StatusCode {
SUCCESS, FAILURE;
}
Как вы можете увидеть в моем DataResponse
классе у меня есть много полей, так Основа на том, что у меня очень длинный конструктор, и каждый раз, когда я делаю объект DataResponse
, у меня есть большая строка с new DataResponse(.......)
. В будущем у меня может быть больше полей, но пока у меня есть только эти поля.
Есть ли какой-либо лучший способ, который я могу использовать для создания объекта DataResponse
, а затем вернуть обратно List<DataResponse>
из моей библиотеки?
Вы можете использовать шаблон строителя. – YoungHobbit
http://stackoverflow.com/a/6395981/3885376 –
Я бы не стал зависеть от строителя. У вас много полей? Звучит как работа для разложения. Проверьте [этот ответ] (http://stackoverflow.com/questions/33784390/object-oriented-design-how-important-is-encapsulation-when-therere-lots-of-da/33785266#33785266). Если вы все еще чувствуете, что впоследствии передаете слишком много данных конструктору, вы можете использовать шаблон построителя. Хотя правильное разложение обычно делает трюк. Я нахожу, что строители будут полезны для необязательных параметров (чтобы избежать конструкций телескопов, которые предоставляют значения по умолчанию, а не избегают множества параметров) –