Question

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

域层次结构：

AbstractNote < MonthNote
             < DayNote
             < ProductNote

只读View Hierarchy（在JTabPane上显示每个都有JTable以显示特定的注释细节）

AbstractNotePanel < MonthNotePanel
                  < DayNotePanel
                  < ProductNotePanel

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

AbstractNoteEditorDialog  < MonthNoteEditorDialog
                          < DayNoteEditorDialog
                          < ProductNoteEditorDialog

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

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

Answer 1

说＆＃34;最重要的是我想在设计中避免代码味道＆＃34;这是一个值得称道的目标，但请始终牢记the core of design is to weigh costs。

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

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

AbstractNote < MonthNote
             < DayNote
             < ProductNote

NotePanel
NoteEditorDialog

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

此外，如果我添加一个功能/修复UI层中的错误，我可能会在其他地方破坏某些内容（因此更改代码以使编辑DayNote更加舒适可能会中断{{1 }}）。

因此，除非你觉得你有很多代码重复，你可以轻易避免或维护成本很高，或者你只有一些模型类型（而不是500），你的设计没有任何问题。< / p>

Answer 2

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

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

并行继承层次结构真的是代码味道吗？

2 个答案: