实现子系统通信设计模式
我正在寻找一种适合以下内容的设计模式:
我有以下系统结构:
MainApplication
SubSystem1
SubSystem2
SubSystem3
MainApplication 初始化每个子系统,
SubSystem1 s1;
SubSystem2 s2;
SubSystem3 s3;
public MainApplication()
{
s1 = new SubSystem1();
s2 = new SubSystem2();
s3 = new SubSystem3();
}
并且每个子系统应该能够相互通信。
在每个子系统中,如何调用另一个子系统的方法?例如,在 s1
中,
public SubSystem1()
{
s2.Method1();
s3.Method2();
}
外观设计模式在这里可行吗?如果是的话,将如何实施?如果不是,这种情况应该使用哪种设计模式?
I am looking for an appropriate design pattern for the following:
I have the following system structure:
MainApplication
SubSystem1
SubSystem2
SubSystem3
Where the MainApplication initializes each subsystem,
SubSystem1 s1;
SubSystem2 s2;
SubSystem3 s3;
public MainApplication()
{
s1 = new SubSystem1();
s2 = new SubSystem2();
s3 = new SubSystem3();
}
and each subsystem should be able to communicate with one another.
Within each subsystem how can I call a method from another subsystem? For example in s1
public SubSystem1()
{
s2.Method1();
s3.Method2();
}
Would a Facade Design Pattern work here? If so, how would it be implemented? If not which design pattern should be used for this scenario?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这很大程度上取决于子系统之间的通信类型。
如果它是抽象的,即子系统实际上不必相互了解,则基于发布-订阅的消息传递机制可能是合适的。请参阅 https://en.wikipedia.org/wiki/Publish/subscribe 了解简介,但我认为这个概念应该相当简单。
另一方面,如果子系统确实必须以具体的方式相互了解,那么为什么它们首先是子系统呢?进行这种划分表明确实存在关注点分离,因此找到一个抽象接口应该不那么难。如果是,也许您应该重新考虑您的子系统职责。
This pretty much depends on the kind of communication between the subsystems.
If it is abstract, i.e. the subsystems do not actually have to know about each other, a publish-subscribe based messaging mechanism may be appropriate. See https://en.wikipedia.org/wiki/Publish/subscribe for an introduction, but i think the concept should be fairly straight-forward.
If, on the other hand, the subsystems really have to know each other in a concrete way, why are they subsystems in the first place? Making this kind of partitioning indicates that there is indeed a separation of concerns, so finding an abstract interface should not be that hard. If it is, maybe you should reconsider your subsystem responsibilities.
我从来不记得设计模式的名字。为什么不能让每个子系统都知道其他子系统呢?
如果您希望更加适应未来变化,请在
接口
中描述每个子系统的接口,并确保 SetSubsystemX 采用该接口,而不是具体的类。编辑:界面示例。
假设您的第一个子系统知道如何发送电子邮件,第二个子系统知道如何打印文件。您应该声明两个接口:
然后您可以定义两个子系统对象:
如果您最终需要 3 个以上的子系统,您应该有一个全局子系统注册表,但现在还不用担心。
I never could remember design pattern names. Why can't you let each subsystem know the other subsystems?
If you want to be more future-change-resilient, describe each subsystem's interface in an
interface
, and make sure SetSubsystemX takes that interface, and not the concrete class.EDIT: An example of an interface.
Let's say your first subsystem knows how to send an email, and the second subsystem knows how to print a file. You should declare two interfaces:
Then you can define your two Subsystem objects:
If you ever going to end up needing more than the 3 subsystems, you should have a global subsystem registry, but don't worry about it just yet.