使用什么设计模式？
建模的问题是这样的：
陆军内部的层级结构，从整个国家军队开始，经过野战军、子部队，最后是个人。每个级别可能涉及到一个或多个其他类别的链接，例如General或Officer或其他类别。野战军中的各个单位需要能够相互通信，特别是为了模拟士气、凝聚力等，以及与任何敌方野战军的通信（例如，我军中的一个单位会影响敌人的士气）积极）。此外，每个单元都需要与层次结构中位于其上方和下方的单元进行通信（出于明显的目的）。
我正在考虑在每个实体的类中使用实际指针（可能是双边的）表示物理层次结构中的链接（例如每个单元中的“army*”和“unit*”或者每个军队中的全部集合），然后利用观察者设计模式来实现其他情况下的任何通信（例如我上面提到的情况）。
然而，由于不是设计模式或编程方面的专家，我不知道是否有其他更有效的方式来做到这一点。任何帮助将不胜感激。
The problem to model is this:
A hierarchy of levels within an Army, starting with the national army in whole, through field armies, subunits, and eventually the individual men. Each level may involve links to one or more other classes such as General or Officer or whatever. The units within say a field army need to be able to communicate with each other, especially for purposes of modeling morale, cohesion, etc, as well as with those of any enemy field army (e.g. a unit routing in my army affects the enemy morale positively). Furthermore, each unit needs to communicate with those above and below it in the hierarchy (for obvious purposes).
I was thinking of having the links in the physical hierarchy represented by actual pointers (possibly bilateral) in each of these entities' classes (e.g. army* in each unit and unit* or a whole collection of them in each army) and then making use of the observer design pattern to implement any communication in other cases (such as the case I mentioned above).
However, being no expert in design patterns or programming for that matter I do not know whether there is any other more efficient manner to do this. Any help would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有一种模型/设计模式用于在不同实体之间通信事件，这些实体在通信发生之前可能不知道彼此的存在。该模式称为“发布/订阅”。
每个实体将其想要发布的事件发送给代理，并告诉代理它会对哪些类型的事件感兴趣。代理负责确保订阅实体了解他们感兴趣的已发布事件。
这类似于观察者模式，但在观察者模式中，每个感兴趣的实体单独订阅它想要接收事件的每个实体。我认为这可能会导致大量开销，因为这需要每个人都关心事物的创建和销毁。
不管怎样，一篇关于发布/订阅的不错的维基百科文章。
我会为各个军队使用 复合 模式（基本上意味着某种形式的树） 。也可能是上下关系或兄弟姐妹关系的观察者。但是 Observer 需要太多的注册和注销操作才能在一般情况下工作。
There is a model/design pattern for communicating events between disparate entities that may not know of eachothers existence before the communication happens. The pattern is called 'Publish/Subscribe'.
Each entity sends events it wants to publish to a broker and tells the broker about what kinds of events it would be interested in. The broker handles making sure the subscribing entities learn of events they find interesting that are published.
This is like the Observer pattern, but in the Observer pattern each interested entity subscribes individually to each entity it wants events from. I think this could result in a lot of overhead because that requires everybody to care about creation and destruction of things.
Anyway, there is a nice Wikipedia article on Publish/Subscribe.
I would use the Composite pattern (which basically means a tree of some form) for the individual armies. And possibly Observer for relationships up and down the hierarchy or with siblings. But Observer requires too much registering and unregistering for it to be workable in the general case.
听起来像是“有图案的小男孩”综合症。你正在寻找一种模式，而不是思考你的问题。
层次结构的自然数据结构是树。我会从那开始。
如果要求树中的每个单元都必须与所有其他单元通信，我会说观察者不适合您。每个单位都必须向所有其他单位注册。每次触发事件时，您都会收到 N 方的消息风暴。
调解员可能会更好。单元将事件发送给调解器，允许消费者注册他们对接收特定类型消息的兴趣。生产者和消费者只了解中介者，而不了解对方。松耦合是你的朋友。
Sounds like "Small Boy With A Pattern" syndrome. You're looking for a pattern instead of thinking about your problem.
The natural data structure for a hierarchy is a tree. I'd start with that.
If the requirement is that every unit in the tree must communicate with all others, I'd say that Observer is not for you. Every unit would have to be register with all the others. You'll have an N-squared firestorm of messages every time an event was fired.
Mediator might be better. Units would send events to the mediator, allowing consumers to register their interest in receiving a particular kind of message. Producers and consumers only know about the mediator, not each other. Loose coupling is your friend.
对于结构建模，这看起来像是 Composite 模式的经典应用。然后您可以使用 Visitor 或 解释器，用于对子单元上的操作进行建模。
For modeling the structure, this looks like classic application of the Composite pattern. Then you can use Visitor or Interpreter for modeling the operations on sub-units.