Java类层次结构，如何实现整个可选变量

我想知道是否有任何“干净”的方式来实现整个类层次结构中的可选变量，而不必简单地将它留空和空检查所有的时间。假设我有以下抽象父类：Java类层次结构，如何实现整个可选变量

public abstract class Item { 

public String name; 

public Item(String name){ 
    this.name = name; 
} 

public String getName(){ 
    return name; 
}

非常简单。现在我有另外一个抽象类来扩展它，并扩展了这个类，每个抽象类都带有一些额外的变量/方法。 Item还有一个存根类，用于扩展它（只是调用super（））的构造函数，如果Item可以具体化，可能不需要，但这取决于解决方案。

现在，让我们假设这些具体类中的任何一个都可能包含MyObject的一个实例。大量的项目将被创建。 Item层次结构中的任何类的一些实例将拥有它，有些不会。程序在编译时无法说明。我无法真正将分层结构拆分为两个单独但几乎相同的树，一个是MyObject，另一个是没有。这会导致很多代码重复。使用包含MyObject的另一个具体类对具体实现进行子类化将意味着过度的类型检查，这会变得很难看，特别是如果层次结构增长的话。将接口/抽象类放到更远的位置并不是一种选择，因为它会将MyObject放在所有东西中。无论解决方案如何，所有这些都必须具有通用的接口/抽象类。

我可能会挑剔，应该只是在层次结构顶部实现MyObject，并且检查它，或者使用一个简单的布尔方法告诉我它是否存在，但它仍然感觉有点草率，我会如果可能的话寻找更好的解决方案。

来源

2013-07-05 user1017413

没有干净的方式。通常这意味着你的类层次有点怪异，应该重构... – Thihara

我试过了，但我找不到合理的方法来重构它以分离两者。 MyObject的存在增加了一个额外的功能，但没有改变每个项目中的任何其他字段/方法。除此之外的类将遍历Items集合并确定哪些具有MyObject，它们将基于该附加功能将它们分开（至少就用户看到的而言，并非字面上在代码中）。把它想象成有和没有A/C的各种汽车的列表，但是如果A/C存在，我们需要知道它是什么类型，它是如何工作的等等。一个简单的标志不会。 – user1017413

您是否考虑从层次结构中删除可选部分并使用合成将它们放置在需要的位置？ – Thihara

你对问题的描述让我想起了Decorator模式的动机 - 一种过度膨胀的类层次结构，带有某种想要的“多重继承”和“超级类的组合”。看看互联网上的Decorator的描述，并且看看Reader/Writer标准Java类是如何实现的。

来源

2013-10-16 16:00:25

Java类层次结构，如何实现整个可选变量

回答

相关问题