在这种情况下如何应用oo设计模式?

时间:2013-12-10 09:36:52

标签: java oop uml design-patterns

情况:假设我们正在使用Java API设计Windows 9的UI。我们需要构建3个类mainBuildInWindowApplicationWindow

main - 渲染系统用户界面的窗口(即开始按钮和壁纸页面)

BuildInWindow - 用于渲染内置应用程序(例如IE)的窗口

ApplicationWindow - 从第三方渲染应用程序的窗口(例如eclipse)

所有这些都必须实现3个Java API接口,WindowFocusListenerWindowListenerWindowStateListener,并且方法为onExit()onCrushing()

当系统/内置应用/第三方应用正常关闭时,

onExit()执行

onCrushing()捕获任何系统/应用程序压缩并将系统状态发送回服务器

这是原始设计:

http://i.stack.imgur.com/JAJiY.png

我对如何以OO方式设计它有一些想法,但我不确定这是否是正确的方法。这是我的想法:

  1. 使用方法abstract classonExit()创建onCrushing()。由于onExit()的代码不同于3个类,因此它应该是abstract method& onCrushing()对所有类都是一样的,所以它将是一个具体的方法
  2. tHE MAIN WINdow应使用singleton设计,以确保用户只创建一个main实例。
  3. 使用facade设计可以节省将3个接口实现为三个类的麻烦
  4. 我的问题是我对门面设计并不十分了解,所以我不确定它是否适用于这种情况。此外,我不确定onExit()对于3个类是否会有所不同,onCrushing()将执行相同的功能。

    我尽力清楚地解释这个问题......如果你不明白免费评论。非常感谢你!

1 个答案:

答案 0 :(得分:0)

我在与您的问题相关的评论中留下了一些问题,但这里有一些指导:

  1. 您不应该在BuildInwindowApplicationWindow的基础上创建一个抽象类,如果它们不是#onExit#onCrushing分享任何实施。在有共同实现的地方,抽象类最有用。包含这些方法的界面就足够了。也就是说,您的两个窗口可能共享其他功能,如果是这样,它可以通过公共超类共享(如果它依赖于子类实现细节,则为抽象)。您可能会发现Template Method模式对于管理整个窗口机制非常有用,并且可以针对不同的窗口类型进行特定定制。您还可以发现Factory Method实例创建方法(对于您的窗口类)将有助于将对象创建和设置与创建机制分开。

  2. 单个共享实例似乎是明智的,单身就可以达到此目的(只要您能够处理终止等)。或者,您的应用程序可能只启动一个Main实例 - 您甚至可以通过包访问隐藏构造函数,以确保不会创建其他实例。

  3. 外观模式只是用于简化复杂的界面。它主要通过在单个(较粗糙)接口下将协作实例的调用一起滚动来实现。通常不会隐藏类支持的接口。实际上,发布类扩展的接口对API用户来说很重要。为了“方便”,您可以将三个接口转换为单个接口,但我认为这是不必要的。如果你确定了一个共同的超类,那么就会“扩展”这三个接口(如果所有的子类都支持它们)。它还可以实现这些接口的一些默认实现(同样,监视访问修饰符以确保可以覆盖您想要的那些而其他接口可能是最终的)。

  4. 修改指南

    您只需要识别类和关系: 我建议你抓一些纸并画画。你已经拥有了你的名词和动词(你可以用名词和动词识别来识别它们的类和方法)。

    那么,为什么不绘制一个包含所有信息(ABCMain等)的简单图表,并绘制它们之间的关系。这是你的起点。在弄清Main如何链接到窗口类时(考虑到有两种类型),您可能会有些困惑。只需在上面写一个注释,然后继续澄清图片的其余部分。

    接下来,优化您的图表以开始将常用功能移动到一个位置(抽象)。您知道这与您的接口和您建议的方法有关,但您可能需要决定哪些(如果有)具有任何常用功能。然后决定接口是否满足您的需求(方法是常见的但实现是不同的),或者实现本身是否相同,因此父超类可能是有用的(这解决了抽象[谁负责什么],封装[个别实现在适当的级别]和多态[哪些类支持常用方法])。请注意,即使你选择了一个超类,你也应该通过一个接口来支持它(它可以更容易地引入兄弟或替换类 - 想想维护)。

    接下来,处理您发现的问题。您的草案设计是否澄清了其中任何一个?例如,您的Main需要了解其窗口,但是 - 它们是什么类型的?那么,你的任何改进是否更清楚了呢?

    是否存在任何模式?为此你需要已经对设计模式有一种感觉,我担心这样买并吸收GoF Design Patterns book。当你走的时候,它会让你很好地发现模式。我还建议你阅读这本特定的书,然后再接受其他任何一本书,因为它与技术无关(而且其他一些书籍也是根据技术特定的解决方法进行的)。也许研究我指出的两种模式,看看它们是否符合你的要求。

    总的来说,你的想法似乎正朝着正确的方向发展。