Java 在这种情况下，我如何应用oo设计模式？

情境：假设我们正在使用JavaAPI设计Windows9的UI。我们需要建立3个类

main

，

BuildInWindow

和

ApplicationWindow

main

-用于呈现系统用户界面的窗口（即启动按钮和壁纸页面）

BuildInWindow

-用于在应用程序（如IE）中呈现buildt的窗口

ApplicationWindow

-用于呈现来自第三方（例如eclipse）的应用程序的窗口

它们都必须实现3个Java API接口，

WindowFocusListener

、

WindowListener

和

WindowsStateListener

，并且具有方法

onExit（）

和

OnCrash（）

onExit（）

在系统/内置应用程序/第三方应用程序正常关闭时执行

oncrash（）

捕获任何系统/应用程序崩溃并将系统状态发送回服务器

这是原始设计：

我对如何以面向对象的方式设计它有一些想法，但我不确定这是否正确。以下是我的想法：

使用方法

onExit（）

和

oncrash（）

创建一个

抽象类。由于
onExit（）
的代码在3个类中有所不同，因此它应该是一个
抽象方法
，
oncrash（）
对于所有类都是相同的，因此它应该是一个具体的方法

MAIN

窗口应使用

singleton

设计，以确保用户只创建一个

MAIN

实例

使用

facade

设计可以避免为三个类实现三个接口的麻烦

我的问题是我不太了解立面设计，所以我不确定它是否可以应用于这种情况。另外，我也不确定3个类的

onExit（）

是否会不同，而

oncrash（）

是否会执行相同的功能

---

我尽力把问题解释清楚…如果你不懂，可以自由评论。多谢各位

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

如果

BuildInwindow

和

ApplicationWindow

都必须有方法

#onExit

和

#oncrashing

，则不应基于这两个方法创建抽象类。抽象类在有公共实现的地方最有用。包含这些方法的接口就足够了。这就是说，您的两个窗口可能共享其他功能，如果是这样，则可以通过一个公共超类（抽象，如果它依赖于子类实现细节）共享。您可能会发现该模式对于管理整个窗口机制以及针对不同窗口类型的特定裁剪非常有用。您还可能发现实例创建方法（对于窗口类）将有助于将对象创建和设置与创建机制分离

一个单独的共享实例似乎是明智的，而一个单独的实例可以达到这个目的（只要您能够处理终止等）。或者，您的应用程序可能只启动一个

Main

实例，您甚至可以通过包访问隐藏构造函数，以确保不创建其他构造函数

facade模式只是用来简化复杂的接口。它主要通过将对协作实例的调用滚动到单个（更粗糙的）接口下来实现这一点。这样做通常不会隐藏类支持哪些接口。事实上，发布类扩展的接口对API用户很重要。为了“方便”，您可以将三个接口合并为一个接口，但我认为这是不必要的。如果您确定使用一个公共超类，那么这将“扩展”三个接口（如果所有子类都支持它们）。它还可以实现这些接口的一些默认实现（同样，请注意访问修饰符，以确保您想要的那些接口可以被覆盖，而其他接口可能是最终的）

编辑：指南

您只需确定类和关系： 我建议你拿些纸来画画。你已经有了你的名词和动词（你也可以用名词和动词来识别它们上面的类和方法）

那么，为什么不画一个包含所有信息的简单图表（

a

，

B

，

C

，

Main

，等等）并画出它们之间的关系呢。这是你的出发点。在计算如何链接到窗口类时，您可能会有一些困惑（假设有两种）。只需在上面写个便条，然后继续澄清图片的其余部分

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

接下来，处理您发现的问题。您的设计草案是否澄清了其中任何一个问题？例如，您的

Main

需要了解其窗口，但它们是什么类型的？因此，您的任何改进是否使这一点更清楚

有没有什么图案可以展示自己呢？为此，你需要对设计图案有一种感觉，我想还是买吧