给C#的建议：让嵌套类有owner关键字

Question

本帖最后由 caozhy 于 2012-02-18 07:07:07 编辑

Answer 1

不同意 星星多的那位朋友的 看法，说实话你没仔细看，我也不想和你辨加owner的好处是很明显的，嵌套类的 本来就是 特殊的class A{} calss B{}
class A{class B{}}这两行是有差别的，定义在类内部的类 是它的一个成员“天生”知道这个类的其它成员包括私有成员
而非嵌套类就不能够知道 你明白吗？ 加owner和加 this, base一样 自然 你懂不懂？？！！

Answer 2

class A{class B{}}嵌套类只在特殊的设计时会用到
当你 A.B b=new A.B() 时，A类并没有实例，所以也不存在owner

Answer 3

A.B b=new A.B();这和有没有owner有什么关系
owner就象base 只在子类里面使用访问父类一样 只在嵌套类里使用以访问物主类class A{
  string m;
  class B{
    void M(){
       owner.m="hello world";
    }
  }
}嵌套类的物主总是确定的，并且唯一，没有必要写成这样class A{
  string m;
  class B{
    void M(){
      A a=new A();
      a.m="hello world";
    }
  }
}
orclass A{
  string m;
  class B{
    A a=new A();
    void M(){
      a.m="hello world";
    }
  }
}

Answer 4

你没回答9楼的那个问题，假如直接new A.B() 时，owner该等于什么，null？

Answer 5

你总觉得别人看不懂你的话。实话说，这种所谓的内嵌类用处不大，毫无意义。纯粹是Java语言的糟粕。而且你用来说明它如何有用的这套完全是建立在你根本就不理解内嵌类和对象聚合使用的场合的情况下的。坦率地说，C#一开始是抄的Java（SUN不让微软卖VJ++，微软自己单干）。你以为C#的设计者连Java有什么都不懂，还不如你明白么？再说，这根本就不是什么新特性。就你举的例子，明显根本就不该用内嵌类，而是使用对象聚合。如果你非要觉得C#和Java相比有些不同是C#的错的话，你为什么强迫自己用有缺陷的C#，直接用Java就是了。

Answer 6

12楼，你会不会写C#程序，还不明白？ 
new A.B(); 这时会考虑owner? 就象 net A();你会考虑this,base??真是不知所云14楼，水平 实在有限，看来泡csdn 的确没前途
什么聚合不聚合的，完全 不知道你在说什么...嵌套类 使用的场合是好象不多，作用不大，但不代表 完全 和其它类没有区别，没有适用场合.定义嵌套类不是用来new A.B();的 一般来说是物主类自己使用的
不让外部看到，物主类可以用内部类来管理自己的代码和功能，总之 有了内部类之后 会让
物主类代码写得更愉快，功能管理更舒适，怎么使用 都可以，随便举个例子来说，比如你自定义一个集合类class MyList{
  public void Add(object o){}
  public void Remove(object o){}
  ...
  Node root,next;  
  class Node{
   public Node next;
   public object data;
  }
  ...
}定义内部类把不必要呈现的内部实现都隐藏了..

Answer 7

你还没明白我在说什么
class A
{
    public class B
    {
        public B()
        {
            var b = base.ToString();
            var t = this.ToString();
            var o = owner.ToString();
        }
    }
}
就这样如果new A.B()的时候，base和this的使用都没问题，可owner是什么。你不能让嵌套类都定义成private的把

Answer 8

18楼，我的确没明白你意思 owner是一个内部类可见的默认物主类实例（唯一且存在）
new A.B()的时候从B实例内部看是可以访问A实例的即owner

Answer 9

lz意思是
class A { public class B { ... } }
如果 A.B r1=new A.B();
就同时new了A 和new了B? 这样B就可以用A的属性方法什么的?

Answer 10

唯一能保证这个的就是把A设计成static的，可如果是static的了，那就没必要用owner关键字了，直接访问就行了

Answer 11

你们跟lz的分歧在于，他没有搞清楚Java嵌套类和C#定义在类里面的类的区别。两者没有可比性。Java那个需要依附外部的实例，C#的是独立存在的。所以Owner根本不存在，更不要说什么owner关键字了。

Answer 12

唯一的意思是 指针对 内部类，其物主类是唯一确定的。反过来不行，物主类可以有n个内部类实例。但内部类无必要也应该有n个物主类实例
内部类是帮助物主类的一个中间工具，比如分类功能，隐藏实现，有时很有用，见前面我举的MyList示意

Answer 13

class A{
   class B{}
}对于java来说, B的实例是依附于A的实例存在的  A a = new A(); A.B = new a.B();//貌似是这么写
所以自然就有存在"owner"但对于c#来说,class B等同于java中的static class B
B与A只存在一个命名空间包含的关系

Answer 14

class A
{
    public string Name;
    public A(string name)
    {
        Name = name;
    }    public class B
    {
        public string GetOwnerName()
        {
            return owner.Name;
        }
    ｝
｝A a1 = new A("1");
A a2 = new A("2");
A.B b = new A.B();
b.GetOwnerName() = 什么？

Answer 15

5星还真有耐心。。内部类，我一般都是在只有外部类自己使用的情况下，并且没有必要多搞一个文件才用。没有具体看lz的论调。最近在搞andorid开发，也对java的内部类有所了解。没有认为有何特别之处

Answer 16

LZ要做的事情和abstract类，或者继承 属于一个鸟意思

Answer 17

试了一下原来java是这样new的
A a = new A();
A.B b = a.new B();即使是java也没有owner关键字

Answer 18

没学过Java，不明白LZ为什么提这个要求的。按LZ所描述的那些东西来看，似乎C#都已经能实现了，没必要非要搞成个嵌套类来实现。不同语言有自己不同的特色，在某种语言里很好用的东西不一定就能简单推广到其它语言里。C++里指针满天飞，谁敢说不用？可C#里哪有？

Answer 19

class A{ 
 string member;
 B CreateB(){return new B(this);}
 class B{ 
  A owner;
  protected B(A a){this.owner = a;}
  void M(){ 
  owner.member="***"; 
  } 
 }
}

Answer 20

坦白说：
  没有用过类中类.
从实用性来说：
  是乎 只有静态类才有这个必要。（但c# 用程序集代取了！）
  当然，我写js 也有这么干，那是因为怕跟同事们的变量冲突！类名冲突！从楼主的描述看，
  楼主这种写法，似乎给C# 加上 一些复杂的东西。

Answer 21

楼主的意思是，有了owner关键字，就像base关键字可以访问父类成员一样，owner可以访问它的外部类，就好像你声明了一个内部类，那么内部类“自动有了”外部类的成员，有点像继承那样，不同之处在于内部类可以访问外部类的private成员，这是内部类天生就具有的功能。

Answer 22

我在一种情况下使用过“类中类”， 就像CAO大侠所说的，只是一种代码组织工具而已，确实是两个不同的类，感觉C#的概念更清晰些，JAVA的嵌套类容易让人脑袋中的对象概念变成一堆酱紫.  class A
  {
     string _T;
     private A(string t)
     {
       _T=t;
     }
      //....
     Class ListA:List<A>
     {
       public ListA( list<string> x)
       {
        // ...
         //可批量创建A对象，并形成一个集合，但不允许单个创建A对象
       }
     }
  }

Answer 23

如果遇到自定义物主类的情况：
class A{
  string s;
  class B{
    //支持自定义物主类的情况吗？如果自定义物主类怎么处理？
     A a1,a2,a3;
    //or
    A[] aas;
    public B(){
      a1=new A();a2=new A();a3=new A();
      aas=new A[3];//
    }
    void M(){
      owner.s="nb";
      this.a1.s=owner.s;
      this.a2.s=owner.s;
      this.a3.s="sb";
      this.aas[0].s="xx";      ...
    }
  }
}这也没什么，owner可以做成为一个系统提供的默认设计时可访问的实例关键字 就象this,或base
但上面的M 内也可以设计为让a1,a2,a3,aas[x]不可见s成员只能由owner才可见 a1,a2,a3,aas[x]这些和外部实例相同 权限，这些可以考虑owner 和 this,base 实在太象了 这样就，都代表一个 设计时默认实例他的好处是 this.后面可见本类成员，base.后面可见父类成员（外部不可见protected而base.可见，但不可见
private成员）owner.后可见物主类的所有成员当我们定义一个类的时候 this即存在 因为唯一且确定，base也存在因为默认继承object，
base的作用是当父类成员和本类成员有岐义时可以区分，base也是唯一确定的，如果多继承base关键字就不能确定。
owner也是唯一确定的，

Answer 24

lz还没醒悟过来，C#里owner根本是不存在的要不你先回答我26楼的问题
b.GetOwnerName() = 什么？

Answer 25

to 39
public class A{
  string s;
  public A(string s){this.s=s;}
  void M(){this.s="xxx";}//this的使用不以其何种构造函数而设计时不能用
}所以owner也一样，编译报错也好隐匿加入无参默认构造也好，都一样，反正设计时可用编译时报不报错
看设计。

Answer 26

我在碰到类似情况的时候也想到过如果有这样的owner该多方便，但是仔细想想这根本是风马牛不相及的事。因为A和B的关系只存在于定义上，而不是实例的上下级，因此并不保证B的每一个实例都有与之对应的A，因此提供这样的owner关键字实际是没有意义的。当然，你可以自己来实现这种需求，比如可以在B的构造函数里把A的实例传进来作为owner。

Answer 27

我觉得LZ最开始的出发点就是从已有的JAVA思想看起的，认为嵌套类就应该是“父子”关系，子类应该可以通过一个关键字找到父类（不是继承关系的父子类），从你的角度看的确正确。
但是为什么你不换个角度，从C#这边看来这种嵌套类根本就不存在其“父子”性，如果想确定“父子”性完全可以通过设计来实现而不是考语法本身来提供这种若有若无的对象关系。如果你这样想，那么你考虑过JAVA应该增加些类似委托的概念呢？语言各有所长，没必要都把一个语言框定在某个其他语言的规定下。

Answer 28

认真想想，楼主也没有错。
  从现实角度来出发，也有很多这种情况。比如：
   一个车子类型：
   一个轮子类型：（从轮子内部也有轮胎类型）
   一个车灯类型：
   
这种类型中 的类型，用C# 的继承方法来表示， 始终都感到不妥！
   一个车让它继承于轮子？ 轮子继承于轮胎又继承于轮框？［不合理吧，C# 没有多继承啊］
好你说用接口来现实？
   想到就不知多复杂！
这不算C# 的一个缺点，那算什么？ 
   或许C# 的设计目的就不是搞这个，  又 或许C# 的设计没有考虚到这个呢，谁又肯定？
总之不得不说: 
   这是一个缺点。

Answer 29

class 汽车｛车门 a1,a2;发动机 b1;｝
class 车门｛｝
class 发动机｛｝
...
这是通常的聚合好处是 各部分可独立 继承
...
通过内部类
class 汽车｛车门 a1,a2;发动机 b1;
class 车门｛｝
class 发动机｛｝
｝
...
让外部不可见汽车的内部结构定义（类型定义）
而继承只能针对 汽车，这样做也是可以的
灵活其实并没损失，反而封装性更好，让
代码更逻辑性更好，更容易管理，

Answer 30

你的意思还是要默认生成一个A的隐藏实例，这个A的隐藏实例只能由B.owner来访问，甚至连A自己都没法访问这个实例，有什么意思，B自己new一个A出来不完全一样么

Answer 31

 车子为什么要继承于轮子呢？因为车里面有轮子吗，那这是使用（关联）关系（用CAO大侠的话是聚合），因为车子和轮子是风马牛不相及的两种物类，而如果说轮胎与子午线轮胎才有继承之说，可见你已经被JAVA的随意性绕进去了。

Answer 32

如果是这样那问题真的大了，LS说感觉很可笑，所谓的内嵌类真的没什么用
去看看UML吧

Answer 33

class 车子
{
  private 轮子[] _轮子集合；
  public 轮子[] 轮子集合
  {
    get;
    set;
  }
}
 class 轮子
  {
    ....
  }

Answer 34

对于LZ的设想我们 也举个例子class 车子
{
  private 前大灯[] _前大灯集合；
  public 前大灯[] 前大灯集合
  {
  get;
  set;
  }
  class 轮子
  {
   owner.前大灯=....  // 这样会是什么情况？ 轮胎上安了个前大灯？实际是汽车的前大灯，滥用下去不一锅绛紫才怪。
  }
 }

Answer 35

基本明白楼主的用意，你是希望微软在你实例化内部类时，对外部类也进行实例化处理，这样你就可以在内部类中使用新增的关键字owner来访问那个自动实例化的外部类。基于上述设想，有几个问题不能解决：
一、如果要自动实例化外部类，那么必须外部类有一个无参数的构造函数，但是C#设计成了当你提供了一个有参数的构造函数时，无参数的构造函数将自动屏蔽，只有不提供任何构造函数的情况下，才会自动创建无参数的构造函数。
二、如果每个内部类的实例都有一个默认的外部类实例，那资源的浪费将不可想象，内部类如果用在List列表或者数组里，将可能创建很多个这样的实例，而每个实例都有一个owner实例，这意味着实例体积无形中变大了，很不合理。别告诉我不同的内部类实例共享一个外部类实例，那就没必要用owner关键字了，直接将外部类声明为静态的就足够。
三、C#发展到现在了，编程习惯和兼容性问题必须考虑，你的大胆设想破坏了这些，而且不止C#，整个.NET语言是互通的，任何基于.NET的语言，都是最终编译为IL语言，所以任何改动必须要考虑兼容性。

Answer 36

对于车子来说，他只需要4个轮子，符合条件的各个品牌的轮子都行，而具体使用了那种轮子，是在对象实例化时定义的，这也是LZ的问题所在，青龙白虎已经说到实处了。在扩展一下：
 使用owner在很多实例化情况下会造成歧义，如：
1.  实例化类种类时，外部类未实例化，里面的意义就很混乱，因此使用owner就不能允许“public” 类种类
2. 外部类的所有对象都会被自动实例化，这样就要求类中类只能有一个特定的无参构造函数，实际上LZ的需求，使用C#的类中类很容易处理：
 class A
 {
   private string _T;
   private B _Tb;   public A()
   {
     _Tb=new B(this);
   }
    class B
    {
      private A _Owner;       public B(A a)
       {
          _Owner=a;
       } 
      public void DoSometing()
      {
        _Owner._T="hello";
  
      }  
    } }
这样的构造，保留了更广泛的适应性，也不乏灵活性。