我在其中一个答案中找到了以下示例：Java内部类和静态嵌套类
public class Container {
public class Item{
Object data;
public Container getContainer(){
return Container.this;
}
public Item(Object data) {
super();
this.data = data;
}
}
public static Item create(Object data){
// does not compile since no instance of Container is available
return new Item(data);
}
public Item createSubItem(Object data){
// compiles, since 'this' Container is available
return new Item(data);
}
}
我想知道我们为什么要这样做：即为了获得容器的实例，我们为什么要创建内部类的实例？这种方法有什么用？它是哪种设计模式？上面的方法已经在一个维护项目中使用了，我仍然不知道它有什么用？
此构造的主要目的是管理data。内部类分发对"容器"的引用只是一个不重要的实现细节。
像你这样的抽象和删节的例子的问题是：你只是把"如何"从代码的作者转移到了读者身上。但是，"为什么"已经完全不复存在了。
因此，您可以用FileSystem替换Container，用File替换Item，用文件的一些更内部的状态替换data。然后你可以看到：
- 一个文件系统可以有一个或多个文件
- 一个文件正好在一个文件系统中
- 文件的生存期不能超过文件系统的生存期
File和Filesystem之间的实现是紧密耦合的——每一个都可能调用另一个——甚至是private方法
最后一点是IMO最重要的一点：您可以向真实用户提供纤薄安全的publicAPI，而File和Filesystem可以使用彼此危险的private方法。在文件系统的情况下，您不希望授予任何其他访问这些危险方法的权限。
这些特征在某些问题中是常见的，因此它们被使用。
我想知道我们为什么要这样做：即为了获得容器的实例，我们为什么要创建内部类的实例？
事实并非如此。
事实上，不能创建内部类Item的实例，除非您已经有外部类Container的实例，您可以在该实例上调用createSubItem方法。创建内部类实例不会创建外部类的新实例。相反，它是在现有实例的上下文中创建的。。。调用内部类构造函数时"可用"的构造函数。
有问题的方法被定义为static，因此它只能访问类的静态成员，并且由于Item类没有声明为静态内部类，因此不能从静态函数访问它。
我不确定这个特定的设计模式或为什么需要它，但这可以工作：
public static Item create(Object data) {
Container c = new Container();
return c.new Item(data);
}
我们使用这种设计的地方之一只是为了拥有额外的Comparator类。