Лучшая практика Java или существуют шаблоны проектирования для хранения данных, которые не имеют прямой связи с этим классом - PullRequest
0 голосов
/ 08 ноября 2018

Я просто хочу передать значение вместе с объектом, но это значение не полностью связано с этим объектом. Допустим, есть объект вызова запроса данных

public class RequestData
{
  private int requestId;
  private String status;
 .......
}

Я хочу передать, должен ли этот запрос сохранять только или печатать только или сохранять и печатать аналогичным образом, есть несколько действий. Когда я передаю эти данные запроса другому классу для проверки этого requestData, я хочу определить, идет ли он от сохранения или печати или сохранения и печати вызова. Для этого, в принципе, я могу добавить атрибут к этому классу RequestData. Но согласно моему изучению в ООП, мы должны сохранять атрибуты, связанные непосредственно с этими объектами, как атрибуты этого объекта.

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

Ответы [ 4 ]

0 голосов
/ 09 ноября 2018

В идеале вы запрашиваете класс данных должен иметь состояние requestAction , которое должно указывать, какое действие он должен выполнить. В вашем случае это может быть сохранение, печать, и т. Д.

В будущем, если будет введено больше действий, вам не нужно изменять ваш код ( Принцип открытого закрытия ) Вы можете перечислить значения, которые может принимать requestAction.

public class RequestData
{
  private int requestId;
  private String status;
  private String requestAction ;
 .......
}
0 голосов
/ 08 ноября 2018

Да, вы правы! Добавление несвязанного атрибута в ваш класс затруднит повторное использование класса в другой среде, для которой не требуется этот несвязанный атрибут.

Типичным решением является создание другого класса, который использует старый класс:

class SecondRequestData {
    private RequestData origin;
    private bool isSave;
    private bool isPrint;
}
0 голосов
/ 08 ноября 2018

Определите атрибут типа запроса - и он определяет, является ли его print или save . Определите этот атрибут как enum . Таким образом, если требуется другой тип, например «запрос» или «обновление», вы можете добавить новое значение в класс enum. Это также документация кода и функциональности.

Вот как может выглядеть код:

enum RequestType { SAVE, PRINT }

class RequestData {
    private int requestId;
    private String status;
    private RequestType requestType;
    .......
    // Get/set methods for request type
    public RequestType getRequestType()
        return this.requestType;
    }
}

class UtilityClass {
    static boolean validateRequestData(RequestData req) {
        switch (req.getRequestType()) {
            case SAVE: // do save related validation
            case PRINT: // do print related validation
            default: throw new IllegalArgumentException("Illegal request type");
        }
        ...
    }

    // private boolean ... detailed validate methods called from switch-case.
}

public class RunMyApp {
    public static void main(String [] args) {
        ...
        // Invoke the request data validation
        RequestData rd1 = new RequestData();
        rd1.setRequestType(RequestType.PRINT);
        if (UtilityClass.validateRequestData(rd1) {
            ...
    }
}
0 голосов
/ 08 ноября 2018

Проще говоря, добавьте все свойства, связанные с запросом, в класс RequestData (мне кажется, тип запроса является свойством запроса). Что касается валидации, если валидность запроса зависит от места его валидации (где обрабатывается запрос), то оставьте его снаружи, если валидность запроса основана только на данных внутри объекта RequestData, тогда поместите метод validate внутри этого класса

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