帮助解决设计问题（扩展通用接口）
我是学生项目的一部分，我们要使用 Java EE 为一家公司开发产品。作为该项目的“首席架构师”，我负责构建一个良好的设计，该设计应该能够灵活地进行进一步的扩展。
背景信息：我们将开发一个带有拖放 GUI 的网站，可以将数据源与数据操作连接起来以对特定数据执行操作。 GUI 应该是通用的并且可以与即将推出的产品集成。这意味着我们无法编写表示层中的实现。相反，我们将使用一个接口来定义各种产品可以进行的数据操作类型。然而，每个产品还可能进行产品特定的数据操作（从而使用更多方法扩展接口）。
我对上述场景的问题是，我不知道如何将这些“产品特定数据操作”传递给 GUI，并说，除了通用接口之外，我们还拥有这些数据操作操作......
现在我与公司中一些经验丰富的程序员进行了讨论，他们告诉我，这个问题有一个通用的解决方案 - 更具体地说，称为“观察者模式”。他们在白板上画了类似 [1] 的内容，并解释说可以“注册”到第三方 (getApplicationContext)，而第三方又可以传达我们的产品特定接口。他们解释说，这是摆脱那些令人讨厌的循环依赖关系的常见问题。
我现在已经了解了观察者模式及其工作原理，但我仍然不明白应该如何解决设计问题。有人可以尝试解释在我的特定场景中结果会如何吗？我对理解它如何与“主体”和“观察者”一起工作没有任何真正的问题。
这是设计的 UML 图，我们在其中使用特定产品的参考。这是我们不希望发生的事情，也是我们希望避免的事情。
（也许我全错了...）
很抱歉，但我无法将图片更改为正确的图片，因为我是新用户...以下是更新的 UML 图的链接：
I am part of a studentproject and we are to develop a product for a company using Java EE. As "lead architect" in the project I am responsible for composing a good design which should be flexible for further extensions.
Background info: We are to develop a website with a drag and drop GUI with possibilites to connect data sources with data manipulations to perform on that specific data. The GUI should be generic and possible to integrate with upcoming products. This means that we cannot code to an implementation in the presentation layer. Instead we will use an interface to define what kind of data manipulations that are possible for all kinds of products. However, each product might also sport product specific data manipulations (thus extending the interface with more methods).
The problem I have with the scenario above is that I dont see how we could pass on these "product specific data manipulations" to the GUI and say that, in addition to the generic interface, we also possess these data manipulation actions...
Now I had a discussion with some of the more experienced programmers from the company and they told me that there is a common solution to this problem - more specifically known as the "Observer pattern". They draw something like [1] on the whiteboard and explained that it would be possible to "register" to a third party (getApplicationContext) that in turn could convey our product specific interface. This is a common problem to get rid of those nasty circular dependencies, they explained.
I have now had a look on the observer pattern and how it works and I still dont really get how I am supposed to solve the design problem. Could someone possibly try to explain how it would turn out in my specific scenario? I have no real problem understanding how it works with "subjects" and "observers".
Here is an UML diagram of the design where we are using a reference of the specific product. This is what is undesirable and something we would like to get around.
(maybe I got this all wrong...)
I am sorry but I cant change the picture to the correct one as I am a new user... Here is a link to an updated UML diagram:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来您正在寻找的是 模型视图控制器 设计模式。 观察者模式只是此设计模式的一部分。 上有关于使用 Java EE 中的 Java Servlet 和 JavaServer Pages 执行此操作的简短说明维基百科文章。
It seems what you are looking for is the Model View Controller design pattern. The Observer pattern is just a part of this design pattern. There is a short description for doing this with Java Servlets and JavaServer Pages from Java EE on the wikipedia article.