Design patterns 哪些体系结构样式和模式适合此系统？

考虑以下情况。有一群人在执行一项任务（例如，编辑地图）。任何人都可以看到整张地图。每个人都被认为是他们创建的某张地图的所有者。如果人员A创建了地图MA，而人员B希望更改该地图，他们可以在本地编辑该地图，然后将其更改提供给A。如果A接受更改，则新的MA将分发给整个团队。根据定义，不允许B向MA提交变更

如您所见，这是一种协作或分布式编辑，其中任务的每一部分都有一个所有者，而其他部分可能会提供更改，这些更改应该被传播

由于我对如何正确设计一个系统以及应该应用哪些规则一无所知（我们的课程也没有关于这方面的材料，这确实很奇怪，但这就是它的含义——意思是“去弄清楚你自己”），我想问一下你对这一主题的看法：

• 在软件设计中，这种系统的一般类别是什么
• 在这样的系统中应该使用哪些样式和模式

我100%确信这是以前设计过的，并且应该使用正确的实现

另外，我真诚地希望这不会作为家庭作业结束，因为a）我不是要求你为我做这件事，只是建议或意见，b）这是我可以就这个话题征求意见的唯一地方

---

p.p.S.我坚信OO分析和设计中有严格的规则，有严格的标准来衡量设计的正确性，因此我不想仅仅用零知识来编造一些随机的“设计”，而是首先知道如何正确处理问题。感谢您的理解。

这类问题的一般架构模式称为“黑板”。您可以阅读它

在拥有超过15年的编程经验之后，我强烈反对您的p.p.S.模式通常是从代码中产生的，而不是从模式中构建的代码。直观地开始做事，迭代地重构和改进，而不是试图预先计划所有事情，这样做更有效、更实用。为什么他们先教我们模式和风格？业界在50年内编写的软件还不够涵盖99%的可能设计场景和问题吗？（并不是说我想和一个15年的经验工程师争论，而是想理解。）而且，这不是像数学一样，在数学中，对如何解决某些问题有既定的规则吗？我不是负责定义你们学校如何教授编程的人。模式比您想象的更细粒度，并且作为命名和识别组件的方法比作为工具箱更有用。没有“协作编辑地图”的模式。有一些模式可以确保使用对象的单个实例，或者使对象适应接口，或者使用多种类型的输入重用算法。协作编辑地图的范围比模式要广得多：它涉及选择如何持久化地图、如何在人与人之间进行交流、如何显示地图等等，这些都是“模式”，但“样式”又如何呢？据我所知，“样式”是一个更广泛、更一般的概念？尽管如此，我还是相信对于这类事情应该有一个传统的高级架构，或者至少有一些可能的选择。当然，也许我没有正确地看待这个问题。我不知道你所说的“风格”是什么意思。你是指程序性的、面向对象的还是功能性的？所有这些都可以应用于许多类型的问题，选择一个与另一个主要取决于偏好、习惯和文化。有许多框架用于解决类似的问题。例如，要编写web应用程序，您将使用MVC web框架。要编写富客户端桌面应用程序，您需要使用GUI工具包。要将对象映射到关系数据库表，可以使用ORM。不过，该应用程序是否用于编辑地图、测验、自行车或其他内容并不真正相关。