标签: nested-class

假设我有一个"应用程序"类.为了初始化,它需要在构造函数中进行某些设置.我们还假设设置的数量太多,以至于将它们放在自己的类中是很有吸引力的.

比较此方案的以下两种实现方式.

实施1:

class Application 
{
   Application(ApplicationSettings settings) 
   {
       //Do initialisation here
   }
}

class ApplicationSettings 
{
   //Settings related methods and properties here
}

实施2:

class Application 
{
   Application(Application.Settings settings) 
   {
       //Do initialisation here
   }

   class Settings 
   {
      //Settings related methods and properties here
   }
}

对我来说,第二种方法更为可取.它更具可读性,因为它强调了两个类之间的关系.当我编写代码以在任何地方实例化Application类时,第二种方法看起来更漂亮.

现在想象一下,Settings类本身又有一些类似的"相关"类,而该类反过来也是如此.只有三个这样的级别,类命名在'非嵌套'的情况下失控.然而,如果你筑巢,事物仍然保持优雅.

尽管如此,我还是读过人们在StackOverflow上说嵌套类只有在外部世界不可见时才被证明是合理的.也就是说,它们仅用于包含类的内部实现.通常引用的异议是包含类的源文件的大小膨胀,但是部分类是解决该问题的完美解决方案.

我的问题是,为什么我们对嵌套类的"公开暴露"使用持谨慎态度？还有其他反对这种用法的论据吗？

或者为什么以下不可能:

class Material
{
    class Keys
    {
        ...
    }

    Material.Keys Keys { get; set; } // Illegal
}

我没有看到任何可能的歧义.按实例访问时,返回属性.静态访问时,返回类.或者我错过了什么？

我不是要求"修复"(我知道我可以用不同的名称来命名,比如MaterialKeys等),但更多的是这个限制背后的技术原因.

可用的 嵌套类SuperView和NestedView.

class SuperView : UIImageView {

    class NestedView : UIImageView {
        var text : String = "Nested View"
    }

    var text : String = "Super View"
    var nested : NestedView?

}

我想为UIImageView设置名为"Custom Class Name"的属性,以在Storyboard场景的检查器中为"NestedView"值.但是Interface Builder找不到"NestedView"类.

将私有静态类嵌套在非静态类中会被认为是一种不好的做法吗？

public class Outer
{
    private static class Inner
    {


    }
}

这里的想法是'Outer'的所有实例都将共享对静态的访问.另一种方法可能是让Inner类是非静态的并使用它的静态实例:

public class Outer
{
    private static innerInstance = new Inner(); 

    private class Inner
    {


    }
}

效果相似.这种方法有哪些优缺点或其他考虑因素？

我必须承认,我几乎从不使用嵌套类,无论是否静态,但我对这个特定的概念感兴趣.

我正在浏览一些代码,我看到了这个:

public class A {
    public A(SomeObject obj) {
      //Do something
    }
    //Some stuff
  public static class B {
    //Some other stuff
  }
}

我想知道,因为即使内部类是public为什么它作为嵌套而不是一个单独的类？另外,我可以在这里这样做new A.B(SomeObject)吗？我觉得这会破坏静态类的目的,但我也看到了这个实现,所以想知道.

这个问题是关于Java的有趣行为:它在某些情况下为嵌套类生成了额外的(非默认的)构造函数.

这个问题也是关于奇怪的匿名类,Java用这个奇怪的构造函数生成.

请考虑以下代码:

package a;

import java.lang.reflect.Constructor;

public class TestNested {    
    class A {    
        A() {
        }   

        A(int a) {
        }
    }    

    public static void main(String[] args) {
        Class<A> aClass = A.class;
        for (Constructor c : aClass.getDeclaredConstructors()) {
            System.out.println(c);
        }

    }
}

这将打印:

a.TestNested$A(a.TestNested)
a.TestNested$A(a.TestNested,int)

好.接下来,让构造函数A(int a)私有:

    private A(int a) {
    }

再次运行程序.接收:

a.TestNested$A(a.TestNested)
private a.TestNested$A(a.TestNested,int)

这也没关系.但是现在,让我们main()以这种方式修改方法(添加类A创建的新实例):

public static void main(String[] args) {
    Class<A> aClass = A.class;
    for (Constructor c : aClass.getDeclaredConstructors()) {
        System.out.println(c); …

我有一个关于UML的问题.我有一个类,它只包含一个带有私有访问修饰符的内部类 - 无法从其他任何地方访问...通常为了呈现内部类关系,我可以使用像(here InnerOddIterator)这样的(+)关系:

(摘自http://www.uml-diagrams.org/nested-classifier.html)

我没有找到任何关于如何明确强调这个类是私有的信息.你知道这种方法是否存在吗？如果是的话,我会感激你在这里给我一些链接吗？

为了保持清晰,示例代码:

public class DataStrucure {
     // fields, methods, etc
     private class InnerOddIterator{
          // ... 
     };
}

请考虑以下代码:

template < typename T >
struct A
{
    struct B { };
};

template < typename T >
void f( typename A<T>::B ) { }

int main()
{
    A<int>::B x;
    f( x );         // fails for gcc-4.1.2
    f<int>( x );    // passes
    return 0;
}

所以这里gcc-4.1.2要求f明确指定模板参数.这符合标准吗？较新版本的GCC是否修复了此问题？如何避免int在调用时明确指定f？

更新: 这是一个解决方法.

#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>

template < typename T >
struct A
{
    typedef T argument;
    struct B { typedef A outer; };
};

template < …

我最近遇到了一个编码标准声称你永远不应该使用Java中的公共内部枚举/类.这是我第一次遇到这个惯例,并且未能找到令人满意的解释原因.

我理解为什么应该避免使用公共内部类,但是为什么你永远不会使用公共嵌套枚举？或者,为什么这是一个糟糕的惯例？

我有一个控制电路,它有多种设置,可以连接任意数量的传感器(每个都有自己的设置).这些传感器只能与控制电路一起使用.我想过使用嵌套类,如下所示:

public class ControlCircuitLib
{
    // Fields.
    private Settings controllerSettings;
    private List<Sensor> attachedSensors;

    // Properties.
    public Settings ControllerSettings
    { get { return this.controllerSettings; } }

    public List<Sensor> AttachedSensors
    { get { return this.attachedSensors; } }

    // Constructors, methods, etc.
    ...

    // Nested classes.
    public class Settings
    {
       // Fields.
       private ControlCircuitLib controllerCircuit;
       private SerialPort controllerSerialPort;
       private int activeOutputs;
       ... (many, many more settings)

       // Properties.
       public int ActiveOutputs
       { get { return this.activeOutputs; } }
       ... (the other Get properties …