有一个接口/类的公共静态内部类的优点是什么？
在浏览我的项目的第三方库的一些资源时，我注意到了下面的代码模式：
public interface MyInterface { public static class MyClass1 implements MyInterface { ... } public static class MyClass2 implements MyInterface { ... } public static class MyClass3 implements MyInterface { ... } } 或者这个：
public class MyBaseClass { public static class MyClass1 extends MyBaseClass { ... } public static class MyClass2 extends MyBaseClass { ... } public static class MyClass3 extends MyBaseClass { ... } }
真实的例子：
- SwingX：
org.jdesktop.swingx.decorator.HighlightPredicate（ Source ） - 物质：
org.pushingpixels.substance.api.renderers.SubstanceDefaultTableCellRenderer（ Source ）
拥有这样的代码结构有什么好处？
我的第一个想法是“聚合”，但同样的事情可以使用普通的旧包来实现。 所以，何时/为什么使用公共内部类而不是包？
我认为这是聚合的原因，也许他们也不值得创build一个顶级的课程。 我有时候会这样做，如果有些东西要小创build一个包（将它们与其他人分开），但是相应的类只应该在顶级类的上下文中使用。 在我看来，这是一个devise决定。
装饰者模式可能是一个很好的例子，他们可以应用在顶层的类，但也许是如此简单，他们不值得也是顶级的。 通过使用它们作为内部类，您可以很容易地显示所有权。
乍看之下，这不是那么明显。 你直接看到依赖的类/接口。
此外，可以访问类的私有字段，这可能是有用的，并且比私有包的范围更细。
我能想到的一个用途是提供现成的接口实现，公开提供给任何人，但仍然在概念上与母接口相关联。
这只有在接口简单（因此内部实现类很小），并不是太多，而且大多数接口客户端真正需要它们时才有意义。 否则，他们会弄乱源文件，使其更难理解。
就类和它们的内部类而言 （不适用于接口），一个区别是内部类可能使用外部类的私有成员，如果它们是“兄弟”（分开的顶级类）。
例：
public class MyBaseClass { private static String staticField = "outer"; public static class MyClass1 extends MyBaseClass { public MyClass1() { MyBaseClass.staticField = "inner1"; } } }
如果将MyClass移出外部类，这将不起作用。
这样做可以节省一些额外的源代码文件，并可以给这个类一个很好的层次名称，即org.foo.bar.XY.Default而不是org.foo.bar.DefaultXY
内部接口必须是静态的才能被访问。 接口不与类的实例相关联，但与类本身相关联，因此可以像使用Foo.Bar一样访问它。
我认为公共静态内部类的原因是“基础”类的附加工具或实用工具。
当我多年前问老师时，他回答说，这样你就可以为同一个对象揭示一个完全不同的界面。 假设你有
public class MyBaseClass { public static class MyClass1 { public int myClassMethod1() {...} public int myClassMethod2() {...} } ... public void myBaseMethod1() {...} public void myBaseMethod2() {...} }
由于MyClass1实例可以访问MyClass1的内部， MyBaseClass即使两个类中定义的方法完全不同，您也可以根据需要公开与MyClass1的实例相同的内部行为或作为MyClass1的实例。
我从来不需要使用它，但真的很有趣。
