Вопросы, связанные со стилем кодирования Java - PullRequest
0 голосов
/ 14 марта 2019

Здравствуйте, мне нужны некоторые данные по следующим двум вопросам

1> Это следующий объект, который я получаю как запрос ввода

public class CreatePaymentRequestDto {
    long insuranceId; 
    int annualCalculationYear; 
    int annualCalculationTotal; 
    int annualPayment; //
    int oneTimePayment;
    int manualChangePayment;
    boolean createRefund;
}

но при передаче его в моем сервисе я хочу оставить другие поля нетронутыми, за исключением того, что поле insuranceId должно быть самим объектом страхования ... что было бы хорошим стилем кодирования вместо создания другого DTO, например ниже

public class CreatePaymentDto {
    Insurance insurance; 
    int annualCalculationYear; 
    int annualCalculationTotal; 
    int annualPayment; //
    int oneTimePayment;
    int manualChangePayment;
    boolean createRefund;
}

2> Второй вопрос касается интерфейсов для служб ..

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

Спасибо

1 Ответ

0 голосов
/ 14 марта 2019

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

Я не уверен, что полностью понял вторую часть об интерфейсах для классов обслуживания. Лично при принятии решения о создании интерфейса я использую несколько простых рекомендаций:

1: использовать интерфейсы для абстрагирования поведения или функциональности

2: это поведение меняется.

3: этот интерфейс используется в качестве контракта

Пример: рассмотрим поведение записи данных. Определим интерфейс

interface DataWriter {
 void write()
}

Теперь вы можете определить одну или несколько реализаций этого, чтобы указать несколько вариантов поведения в зависимости от требований.

Если вам никогда не понадобится несколько вариантов поведения, вам может не понадобиться интерфейс.

Если вы разрабатываете классы, которые общаются, и если над ними работают несколько разработчиков, наличие интерфейса облегчает задачу, выступая в качестве контракта на общение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...