我想知道扩展在第一时刻制作的类是否是一个好习惯，而不需要扩展它，只是为了添加一些你将在应用程序中使用的信息。时刻。
例如，我使用Swing Java API为我正在开发的应用程序创建GUI。构建它时，我有必要创建一个JTable，根据用户的操作，该模型将在运行时更改几次。所以，我有三种不同的模型可以根据情况应用于JTable。也就是说，在我的应用程序中，我意识到如果我可以扩展JTable并创建另一个在内部具有Enum（或任何其他类型）的类可以提供我在JTable上哪个模型处于活动状态对我来说会容易得多。在我检查它的确切时刻。所以，我的问题是：例如，扩展JTable是一个好习惯，只是添加具有可能对应用程序中的访问有用的信息的字段？对我来说，直接在JTable中保存这些信息并在我访问JTable时访问它会容易得多。
这是一个好习惯吗？可怕的做法？你有什么看法？谢谢！
答案 0 :(得分：4)
假设有一个M-V-C或模型 - 视图 - 控制程序结构，或者与此相近的东西，
...创建一个JTable，该模型将在运行时更改几次，具体取决于用户的操作。所以，我有三种不同的模型可以根据情况应用于JTable。
这里的关键是：实际上有什么变化？ JTable或其TableModel？如果是TableModel，我会避免对JTable进行子类化。
那就是说，在我的应用程序中，我意识到如果我可以扩展JTable并创建另一个在内部具有Enum（或任何其他类型）的类可以为我提供哪个模型是活动的，这对我来说会容易得多。在我检查它的确切时刻在JTable上。
这似乎使View与Model混淆。 TableModel信息应该是程序模型的一部分，如果它发生了变化，那么你可以让模型通知侦听器这个变化。
所以，我的问题是：例如，扩展JTable是一个好习惯，只是添加具有可能对应用程序访问有用的信息的字段？对我来说，直接在JTable中保存这些信息并在我访问JTable时访问它会容易得多。
在这种情况下，我不会将JTable子类化，而是进行重大的状态更改，并且它们的通知是主程序模型的一部分，而不是它的视图（正如您尝试的那样）。
答案 1 :(得分：1)
是的，以这种方式扩展类是很好的java。
如果一个课程不打算延长，则应宣布为最终课程。
答案 2 :(得分：1)
这取决于您的应用程序业务要求和架构策略，但这是具有Decorator模式的常见设计模式。