Question

软件实体（类，模块，函数等）应该是可以扩展的，但是关闭以进行修改

我正在设计一个域名，并在我的域名实体中包含相当多的行为。我正在使用域事件并将依赖注入到方法中，因此请确保我的实体不会与外部影响耦合。但是，对我而言，如果客户端稍后需要更多功能，我将不得不违反OCP并破解这些域实体以添加功能。一个行为丰富的领域实体如何与开放封闭原则协调一致？

Answer 1

在设计类时要牢记开放闭合原则（OCP）是有用的，但是让类“立即关闭以进行修改”并不总是实际或可取的。我认为单一责任原则（SRP）在实践中更有用 - 只要一个类只做一件事，如果对这一件事的要求发生变化就可以修改它。

此外，随着时间的推移，SRP会导致OCP;如果你发现自己经常更改一个类，你最终会重构它，以便更改部分被隔离在一个单独的类中，从而使原始类更加封闭。

Answer 2

答案很简单：工厂方法和界面+组合。

打开扩展意味着您使用新的子类添加新功能。

要启用您必须使用工厂来创建域对象。我通常使用我的存储库作为工厂。

如果您使用接口而不是混凝土进行编码，则可以轻松添加新功能：

IUSER
IManager：IUser（添加一些管理员功能）
ISupervisor：IUser（添加主管功能）

功能本身可以是使用合成包含的小类：

public class ManagerSupervisor : User, IManager, ISupervior
(
    public ManagerSupervisor()
    {
        // used to work with the supervisor features.
        // without breaking Law Of Demeter
        _supervisor = new SuperVisorFeatures(this);

    }
)

Answer 3

如果没有一些具体的例子，这是一个难以解释的问题。我建议你阅读Robert Martin的书“敏捷软件开发，原理，模式和实践”。本书也是开放式原则的来源。

具有丰富行为的域对象与开放关闭原则不冲突。如果他们没有行为，则无法创建合理的扩展。应用开放原则的关键是预测未来的变化并创建新的界面来履行角色并让他们承担单一责任。

我将讲述在实际代码中应用开放原则的故事。希望它有所帮助。

我有一个Sender类，它在开始时发送消息：

package com.thinkinginobjects;

public class MessageSender {

private Transport transport;

public void send(Message message) {
    byte[] bytes = message.toBytes();
    transport.sendBytes(bytes);
}
}

有一天，我被要求以10批次发送消息。一个简单的解决方案是：

package com.thinkinginobjects;

公共类MessageSenderWithBatch {

private static final int BATCH_SIZE = 10;

private Transport transport;

private List<Message> buffer = new ArrayList<Message>();

public void send(Message message) {
    buffer.add(message);
    if (buffer.size() == BATCH_SIZE) {
        for (Message each : buffer) {
            byte[] bytes = each.toBytes();
            transport.sendBytes(bytes);
        }
                    buffer.clear();
    }
}
}

但是我的经验告诉我这可能不是故事的结尾。我预计人们将需要不同的批处理方式。因此我创建了一个批处理策略并让我的发件人使用它。 请注意，我在这里应用了开放式原则。如果我将来有新的批处理策略，我的代码是开放的（通过添加新的BatchStrategy），但接近修改（通过不修改任何现有代码）。然而正如Robert Martin在他的书中所说，当代码对某些类型的更改开放时，它也接近其他类型的更改。如果有人想在将来发送后通知某个组件，我的代码将无法进行此类更改。

package com.thinkinginobjects;

public class MessageSenderWithStrategy {

private Transport transport;

private BatchStrategy strategy;

public void send(Message message) {
    strategy.newMessage(message);
    List<Message> messages = strategy.getMessagesToSend();

    for (Message each : messages) {
        byte[] bytes = each.toBytes();
        transport.sendBytes(bytes);
    }
    strategy.sent();
}
}

package com.thinkinginobjects;

public class FixSizeBatchStrategy implements BatchStrategy {

private static final int BATCH_SIZE = 0;
private List<Message> buffer = new ArrayList<Message>();

@Override
public void newMessage(Message message) {
    buffer.add(message);    
}

@Override
public List<Message> getMessagesToSend() {
    if (buffer.size() == BATCH_SIZE) {
        return buffer;
    } else {
        return Collections.emptyList();
    }
}

@Override
public void sent() {
    buffer.clear(); 
}

}

Jus完成这个故事，几天后我收到一个要求，每5秒发送一次批量信息。我的猜测是正确的，我可以通过添加扩展而不是修改我的代码来满足要求：

package com.thinkinginobjects;

public class FixIntervalBatchStrategy implements BatchStrategy {

private static final long INTERVAL = 5000;

private List<Message> buffer = new ArrayList<Message>();

private volatile boolean readyToSend;

public FixIntervalBatchStrategy() {
    ScheduledExecutorService executorService = Executors.newScheduledThreadPool(1);
    executorService.scheduleAtFixedRate(new Runnable() {

        @Override
        public void run() {
            readyToSend = true;

        }
    }, 0, INTERVAL, TimeUnit.MILLISECONDS);
}

@Override
public void newMessage(Message message) {
    buffer.add(message);
}

@Override
public List<Message> getMessagesToSend() {
    if (readyToSend) {
        return buffer;
    } else {
        return Collections.emptyList();
    }
}

@Override
public void sent() {
    readyToSend = false;
    buffer.clear();
}
}

免责声明：代码示例属于www.thinkingInObjects.com

Answer 4

您在使用域事件模式的正确轨道上。

你不必破解你的课程。您只需附加其他条件事件处理程序。

域事件 - 事件处理程序关系可以是一对多，并且处理程序可以根据域事件参数的具体类型触发。

Answer 5

简单的答案是确保：

它可以执行任务，因此如果您发现问题，它可以不要求您稍后修改它。虽然开放/封闭原则不包括错误只会改变。
它鼓励更换，即它实现了合理的界面。该组件应该换成另一个而不是修改。
使其可配置，任何可以更改的硬编码参数都应该可配置。
将代码更改为外部化，使用控制反转来导出可能需要更改的任何功能。

在重型起重组件中实施开/关原则通常要容易得多，但在应用程序流控制和业务逻辑通常需要最大变化的应用程序部分应用相同的原则要困难得多。通过配置运行工作流程是理想的选择。

领域驱动设计很难与良好的编程设计原则相协调，DDD的关键部分是保持低级概念远离业务领域的语言和理由，并使业务模型保持在高级别用户和企业使用的语言，即“无所不在的语言”，以防止商业模式的软件/技术污染。

如何拥有一个遵循开放封闭原则的行为丰富的域实体？

5 个答案:

您在使用域事件模式的正确轨道上。