Методы быстрого доступа

Question

Мой оригинальный вопрос был совершенно неверным, у меня есть классы (не POJO ), которые имеют ярлыки для классов бизнес-логики, чтобы дать потребителю моего API возможность использовать его следующим образом:

Connector connector = new ConnectorImpl();
Entity entity = new Entity(connector);
entity.createProperty("propertyName", propertyValue);
entity.close;

Вместо:

Connector connector = new ConnectorImpl();
Entity entity = new Entity();
connector.createEntityProperty(entity, "propertyName", propertyValue);
connector.closeEntity(entity);

Является ли хорошей практикой создание таких быстрых методов?

Старый вопрос

На данный момент я разрабатываю небольшойи имеют довольно хорошее разделение бизнес-логики на разные классы (коннекторы, токены аутентификации и т. д.), но одна вещь все еще беспокоит меня.У меня есть методы, которые манипулируют с POJO, как это:

public class BuisnessLogicImpl implements BusinessLogic{
    public void closeEntity(Entity entity) {
        // Business Logic
    }
}

И сущности POJO, у которых также есть метод close:

public class Entity {
    public void close(){
        businessLogic.closeEntity(this);    
    }
}

Это хорошая практика, чтобы предоставить два способато же самое?Или лучше просто удалить все "прокси" методы из POJO для ясности?

Answer 1

Вы должны удалить методы из "POJO" ... Они на самом деле не POJO, если вы инкапсулируете такую ​​функциональность.Причина этого кроется в принципах проектирования SOA , которые в основном говорят о том, что вы хотите слабую связь между различными уровнями вашего приложения.

Если вы знакомы с Инверсиями контейнеров управления , например Google_Guice или Spring Framework - это разделение является обязательным.Например, предположим, что у вас есть CreditCard POJO и CreditCardProcessor сервис, а также DebugCreditCardProcess сервис, который фактически не взимает с CC деньги (для тестирования).

@Inject
private CardProcessor processor;

...

CreditCard card = new CreditCard(...params...);
processor.process(card);

В моемНапример, я полагаюсь на контейнер IoC, чтобы предоставить мне CardProcessor.Является ли это отладкой или настоящей ... Мне все равно, и объект CreditCard тоже не имеет значения.То, что предоставляется, зависит от конфигурации вашего приложения.

Если бы у вас была связь между процессором и кредитной картой, где я мог бы сказать card.process(), вам всегда нужно было бы передать processor в конструкторе карт.CreditCards может использоваться для других целей, кроме обработки, однако.Возможно, вы просто хотите загрузить CreditCard из базы данных и получить дату истечения срока действия ... Для этой простой операции не нужен процессор.

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

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

Answer 2

Я не рассматриваю ваш случай как "два метода", потому что логика реализации сохраняется в bussinessLogic.Было бы все равно, что спросить, если это хорошая идея, java.lang.System имеет как метод getProperties(), так и getProperty(String), более чем другой метод является просто ярлыком для того же метода.

Но,в общем, нет, это не очень хорошая практика.Главным образом потому, что:

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

b) при чтении вашего кода, другие программистыИнтересно, есть ли два метода, потому что они разные.

Кроме того, он не очень хорошо подходит для назначения ответственности определенному классу для данной задачи, что является одним из принципов ООП.

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