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实体也有一个密切的方法：

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

提供两种方法来做同样的事情是不错的做法？或者更好的是，为了清楚起见，只需从POJO中删除所有“代理”方法？

Answer 1

你应该从“POJO”中删除这些方法......如果你封装了这样的功能，它们就不是真正的POJO。其原因来自于SOA设计原则，它基本上表示您希望在应用程序的不同层之间loose coupling。

如果您熟悉Inversion of control容器，例如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并获得到期日期......它不需要处理器来执行这个简单的操作。

你可能会说：“信用卡可以从静态工厂获得处理器”。虽然如此，singletons被广泛认为是反模式，需要在您的应用程序中保持全局状态。

将业务逻辑与数据模型分开始终是一件好事，可以减少所需的耦合。松耦合使测试更容易，并且使代码更易于阅读。

Answer 2

我不认为你的情况是“两种方法”，因为实现的逻辑保留在bussinessLogic中。这类似于询问这是一个好主意java.lang.System同时具有方法getProperties()和getProperty(String)，而不仅仅是同一方法的快捷方式。

但是，总的来说，不，这不是好习惯。主要是因为：

a）如果将来做这件事的方式发生变化，你需要记住你必须触及两个实现。

b）在阅读你的代码时，其他程序员会想知道是否有两种方法，因为它们是不同的。

此外，它不适合为给定任务的特定类分配响应性，这是OOP的原则之一。

当然，所有绝对规则都可能有一个特殊情况，其中一些考虑因素（主要是表现）可能暗示违反规则。想想你是否通过这样做赢得了一些东西并大量记录下来。

快捷方式

旧问题

2 个答案: