快捷方式答案

【问题标题】：Shortcut methods快捷方式
【发布时间】：2011-08-12 21:09:35
【问题描述】：

我最初的问题是非常不正确的，我有类（不是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 中删除所有“代理”方法？

【问题讨论】：

标签： java frameworks

【解决方案1】：

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

如果您熟悉Inversion of control 容器，例如Google_Guice 或Spring Framework-- 这种分离是必需的。例如，假设您有一个CreditCard POJO 和一个CreditCardProcessor 服务，以及一个实际上不收取 CC 费用的DebugCreditCardProcess 服务（用于测试）。

@Inject
private CardProcessor processor;

...

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

在我的示例中，我依靠 IoC 容器为我提供CardProcessor。这是调试的，还是真正的……我真的不在乎，CreditCard 对象也不在乎。提供的一个由您的应用程序配置决定。

如果您在处理器和信用卡之间有耦合，我可以说card.process()，您将始终必须在卡构造函数中传递processor。 CreditCards 可以用于除处理之外的其他事情。也许您只是想从数据库中加载一个CreditCard 并获取到期日期......它不需要处理器来执行这个简单的操作。

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

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

【讨论】：

谢谢，这正是我担心的事情。我将删除所有快捷方式并重构代码，以摆脱将 buisnessLogic 对象传递给 POJO（或在我的情况下为假 POJO）。
IIRC，松耦合意味着您应该将对象作为接口的实例而不是类传递，以便可以轻松更改实现。还是我错了？

【解决方案2】：

我不认为您的案例是“两种方法”，因为实现的逻辑保存在 bussinessLogic 中。这类似于问java.lang.System 是否有一个好主意getProperties() 和一个getProperty(String)，不仅仅是一个不同的方法只是同一个方法的快捷方式。

但是，一般来说，不，这不是好的做法。主要是因为：

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

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

此外，它也不太适合为给定任务分配特定类的职责，这是 OOP 的原则之一。

当然，所有绝对规则都可能有一种特殊情况，即某些考虑（主要是性能）可能会建议违反规则。想想你这样做是否会赢得一些东西，并大量记录下来。

【讨论】：