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

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

说“最重要的是我想在我的设计中避免代码异味”是一个值得称赞的目标，但请始终牢记 the core of design is to weigh costs .

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

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

AbstractNote < MonthNote
             < DayNote
             < ProductNote

NotePanel
NoteEditorDialog

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

此外，如果我在 UI 层添加一个功能/修复一个错误，我在其他地方破坏某些东西的可能性要高得多(因此更改代码以使编辑 DayNote 更舒适可能会破坏MonthNote).

因此，除非您觉得您有很多可以轻松避免的代码重复，或者维护成本很高，或者您只有几种模型类型(而不是 500 种)，否则您的设计没有任何问题。