3

我不知道如何在实践中避免并行层次结构。例如，考虑一个必须在不同级别上创建/保存/编辑笔记的应用程序，它是一个基于 java swing 的应用程序。

域层次结构：

AbstractNote < MonthNote
             < DayNote
             < ProductNote

只读视图层次结构（显示在 JTabPane 上，每个都有 JTable 以显示特定的注释详细信息）

AbstractNotePanel < MonthNotePanel
                  < DayNotePanel
                  < ProductNotePanel

注释编辑器层次结构（当用户单击表格行中的特定注释时显示。

AbstractNoteEditorDialog  < MonthNoteEditorDialog
                          < DayNoteEditorDialog
                          < ProductNoteEditorDialog

我读过一种避免这种情况的方法是使用访问者模式。 但这似乎不适用于我的情况。

我对上面的设计很满意，因为大多数通用代码都在抽象类中（在那里应用模板方法模式）。如果我必须创建一种新类型的笔记，例如 YearNote，那么我必须并行创建 YearNotePanel 和 YearNoteEditorDialog，这对我来说是完全可以接受的，因为由于模板，我不必编写很多代码。最重要的是，我想在我的设计中避免代码异味。请在上述情况下建议我替代设计，以便我的代码仍然是模块化的。谢谢

4

2 回答 2

1

说“首先我想在我的设计中避免代码异味”是一个值得称赞的目标，但请始终牢记设计的核心是权衡成本。

在我的应用程序中，我通常有模型类和配置。配置可以在模型中（注释、自省方法）或作为额外文件。

UI 层读取此配置，然后从中构建 UI。这意味着我的设计看起来像这样：

AbstractNote < MonthNote
             < DayNote
             < ProductNote

NotePanel
NoteEditorDialog

这通常有效，因为对话框和面板非常通用。当然，我的通用 UI 层非常复杂，因为它必须处理每个极端情况。因此，如果您仅查看文件数量或继承层次结构，这可能看起来比您的设计好得多，但我的 UI 层内部的代码比您的要复杂得多。

此外，如果我在 UI 层中添加功能/修复错误，我在其他地方破坏某些东西的可能性要高得多（因此为了使编辑DayNote更舒适而更改代码可能会破坏MonthNote）。

因此，除非您认为您有很多可以轻松避免的代码重复，或者维护成本很高，或者您只有几个模型类型（而不是 500 个），否则您的设计本身并没有错。

于 2013-08-26T13:18:42.427 回答
0

您可以在此处使用的一个重要 API 是BeanInfo API。熟悉它。在任何 java 类（bean）上，您都可以定义一个元级别的 BeanInfo 类。

一种用法是，通过这种方式您可能会制作一个新的 Swing 组件，并在 IDE 中使用 BeanInfo 提供一个表格组件属性。（在 NetBeans IDE 中，您可以将自己的组件添加到组件调色板中，并以这种方式进行操作。）这与属性编辑器一起使用（用于选择颜色/数据/..）。

于 2013-08-26T13:40:59.670 回答