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

[sjhcsdn]

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2597275-add-keyword-owner-form-inner-class

大家来帮顶这个建议
add keyword "owner" for inner class for example:
class A{
string member;
class B{
void M(){
owner.member="***";
}
}
}

类部类是其物主类的成员它天生知道物主类的所有其它成员包括私有成员这本身说明了嵌套的特殊性
为嵌套类加入物主引用 owner 就象 this,base一样自然 ，

在很多设计时嵌套类是很有用的，比如 一个类在公开的功能中使用内部类来隐藏实现
类部类对象成为其私有的存储节点，更好的表现了封装等面向对象思想（当然这有点扯远了）
还望大家助力支持 投票

[threenewbee]

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

就你举的例子，明显根本就不该用内嵌类，而是使用对象聚合。如果你非要觉得C#和Java相比有些不同是C#的错的话，你为什么强迫自己用有缺陷的C#，直接用Java就是了。

[sjhcsdn]

to 39
public class A{
string s;
public A(string s){this.s=s;}
void M(){this.s="xxx";}//this的使用不以其何种构造函数而设计时不能用
}

所以owner也一样，编译报错也好隐匿加入无参默认构造也好，都一样，反正设计时可用编译时报不报错
看设计。

[fengkeyiren]

你非要劳斯莱斯搞个宝马配置做什么呢？既然这样，你何不直接买宝马啊！非要宝马和劳斯莱斯一样，那就是这个买车的脑子有问题了

[窗户纸]

[Quote=引用 43 楼 hetengfei_ 的回复:]
一个车子类型：
一个轮子类型：（从轮子内部也有轮胎类型）
一个车灯类型：

这种类型中 的类型，用C# 的继承方法来表示， 始终都感到不妥！
一个车让它继承于轮子？ 轮子继承于轮胎又继承于轮框？［不合理吧，C# 没有多继承啊］
[/Quote]
车子为什么要继承于轮子呢？因为车里面有轮子吗，那这是使用（关联）关系（用CAO大侠的话是聚合），因为车子和轮子是风马牛不相及的两种物类，而如果说轮胎与子午线轮胎才有继承之说，可见你已经被JAVA的随意性绕进去了。

[hetengfei_]

[Quote=引用 52 楼 etudiant6666 的回复:]
车子为什么要继承于轮子呢？
[/Quote]

那你说，这种包含关系，用C#如何写？
能不能给出代码？

[IE11下面经常卡到爆]

[Quote=引用 20 楼 sugarbelle 的回复:]

lz意思是
C# code
class A { public class B { ... } }

如果 A.B r1=new A.B();
就同时new了A 和new了B? 这样B就可以用A的属性方法什么的?
[/Quote]

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

[窗户纸]

[Quote=引用 53 楼 hetengfei_ 的回复:]

那你说，这种包含关系，用C#如何写？
能不能给出代码？
[/Quote]

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

[窗户纸]

对于LZ的设想我们 也举个例子

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


 }

[hetengfei_]

[Quote=引用 55 楼 etudiant6666 的回复:]
class 车子
{
private 轮子[] _轮子集合；
public 轮子[] 轮子集合
{
get;
set;
}
}
class 轮子
{
....
}
[/Quote]

车子型类里面的轮子是对象来的。指的是某一个轮子，而不是某一款轮子，

但是我们 说某一类车时，指的是这类车要安装某一款轮子，这似乎变义了。

[qldsrx]

基本明白楼主的用意，你是希望微软在你实例化内部类时，对外部类也进行实例化处理，这样你就可以在内部类中使用新增的关键字owner来访问那个自动实例化的外部类。

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

[窗户纸]

[Quote=引用 57 楼 hetengfei_ 的回复:]

车子型类里面的轮子是对象来的。指的是某一个轮子，而不是某一款轮子，

但是我们 说某一类车时，指的是这类车要安装某一款轮子，这似乎变义了。
[/Quote]

对于车子来说，他只需要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";
  
      }

  
    }

 }

这样的构造，保留了更广泛的适应性，也不乏灵活性。

[effun]

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

[ViewStates]

我觉得LZ最开始的出发点就是从已有的JAVA思想看起的，认为嵌套类就应该是“父子”关系，子类应该可以通过一个关键字找到父类（不是继承关系的父子类），从你的角度看的确正确。
但是为什么你不换个角度，从C#这边看来这种嵌套类根本就不存在其“父子”性，如果想确定“父子”性完全可以通过设计来实现而不是考语法本身来提供这种若有若无的对象关系。

如果你这样想，那么你考虑过JAVA应该增加些类似委托的概念呢？

语言各有所长，没必要都把一个语言框定在某个其他语言的规定下。

[hetengfei_]

认真想想，楼主也没有错。
从现实角度来出发，也有很多这种情况。

比如：
一个车子类型：
一个轮子类型：（从轮子内部也有轮胎类型）
一个车灯类型：

这种类型中 的类型，用C# 的继承方法来表示， 始终都感到不妥！
一个车让它继承于轮子？ 轮子继承于轮胎又继承于轮框？［不合理吧，C# 没有多继承啊］
好你说用接口来现实？
想到就不知多复杂！
这不算C# 的一个缺点，那算什么？
或许C# 的设计目的就不是搞这个， 又 或许C# 的设计没有考虚到这个呢，谁又肯定？
总之不得不说:
这是一个缺点。

[sjhcsdn]

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

[hetengfei_]

如果用接口：
类型之多，管理之一易啊！

[hetengfei_]

类型之多，管理之不易啊！[错改对 ]

[qq13833254607]

[Quote=引用 40 楼 sjhcsdn 的回复:]

to 39
public class A{
string s;
public A(string s){this.s=s;}
void M(){this.s="xxx";}//this的使用不以其何种构造函数而设计时不能用
}

所以owner也一样，编译报错也好隐匿加入无参默认构造也好，都一样，反正设计时可用编译时报不报错
看设计。
[/Quote]

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

[hetengfei_]

其实：
语言都是不部分人想出来的东东！ 有不完美，正常。

不管： 从现实，还是从虚拟出发，
现实的语言，都是有这个那个不足。他们的表示方法，不尽然让人们一目了然，学习难度，操作难度大！ 都是缺点。

对于，表示方法，完全可以自已定一种新型的表示方法。自已的规则自已定。 然后将这种表示方法分离语言，成为一个代码管理生成器。只要在生成器上布局，就可以得到自已要的[规则]与[表示方法]。
敢说：
你们谁有去做？
又谁能做到？
没有吧，
这就注定了我们是一个使用者，没有创告能力，即然大家都说这个不好那个不好，为什么不见大家开发出新的工具？ 新的逻辑？

其实 楼主也是一个有远见的人。 但，不见得每个人都有同样的看法，所以总是［枪打出头鸟］！
不过，也不要见怪，众观历史，就是这个样啊，当然，只有[出头鸟] 才能代表新东西，代表新生代。--这行有扁义，建义大家别看!

[sugarbelle]

[Quote=引用 48 楼 hetengfei_ 的回复:]
个人都有同样的看法，所以总是［枪打出头鸟］！
不过，也不要见怪，众观历史，就是这个样啊，当然，只有[出头鸟] 才能代表新东西，代表新生代。--这行有扁义，建义大家别看!
[/Quote]
鸟为什么要出头?
1.可能因为林子不是鸟们种的.老鸟们喜欢呆在这林子里.它不喜欢.觉得自卑.
2.它想飞向一个新地方.老鸟们也没阻止啊.只是把它可能路过的陷阱告诉它了.它若想去还可以去的.
这只鸟为什么觉得［枪打出头鸟］?
1.它觉得它出头了.发现了新大陆.
2.它有被害妄想.觉得大家都在害它.