跳跃，跳跃再跳跃
万物的基础是循环，状态的出现，就是循环带来的一段时期持续的特征呈现，而如果循环具有两次或两次以上时，我们就不得不使用for或while或其它什么来实现重复代码的执行。
既然循环是万物的基础，那么为什么我们还要反过来遇到有状态呈现时用循环语句来实现呢？实际上，无论何时都有循环出现，那么循环就应该是一种默认的实现，我们不应该针对数组或是集合进行处理，反过来我们应该认为万物能够，它就是一个集合或一组数据，只是我们在识别系统的特征概念时，才采用单元片断来识别。
本质上，现在开始，彻底应该忘记单元的概念，任何最小化的识别对象都是一个集合，都是其它对象的组合体，完全的系统论化视角。
我们声明一个Class，泛型的出现，让我们不必再定此Class的List或是Collection，所以，从现在开始，我们任何情况下的操作，都是针对List，永远不再会有单元类的直接使用。
这样的好处是什么？在我的概念中，一个类定义的本质也是其它的类的List构成的，在此基础上，我们就拥有了，把一个类转移为其它类的List或是此类构造一个List成为其它的类。
世界上有男人女人，那么这里就产生了MAN，按照此研究，本质的定义是一组可以具有符合MAN成员属性方法的实现对象的都可以称之为MAN，MAN本身就是一个List，那它具有什么样的特点呢？首先，它可以成为一个Company的Member，也可以成为Human的一个Member，就此，我们的定义应该是：
public class MAN
显然，这是一个MAN，我们在程序中永远不会直接出现针对单独的一个实例化MAN的操作出现，而是会采用List<MAN>.CreateMAN来创建一个新的MAN对象，简单来说，所有创建的新对象都将会有自己的List对它进行管理。
public class WOMNAN
它具有一个比较有趣的特点，男人女人都是人，那么它们的共同就是HUMAN，现在我们不会让MAN与WOMAN去继承，为什么，因为是男人与女人组成了HUMMAN,记住是组成，组成的含义就不再使用继承。
继承的最大作用就是利用代码，如果能够达到代码利用的目的，我们是完全不需要继承的，但如果需要更大量的代码来实现就会让人很郁闷。MAN与WOMAN都有SEX属性，按传统的方式，我们可以继承HUMAN来得到SEX属性，但这里，概念要转变了，SEX不再是HUMAN的属性，MAN与WOMAN是继承于它，而是反过来，有了MAN与WOMAN后，构成了HUMAN这个概念，然后我们抽象出来的共性才具有SEX，这个SEX是抽象出来的，抽象出来的东西，不是代表着你抽象后它才出现，而是你要根据现实来抽象的，所以，我们发现了一个更有乐趣的事情，SEX应该是一个属性，它作为MAN与WOMAN都具有的属性，不应该是自HUMAN而来，女娲造人神话也告诉了我们，女娲娘娘是同时造的男人与女人，而不是造出人来后，再把他们分别加工成男人与女人。西方的神话中上帝造了一个没有女人却有男人特点的亚当，不得不让人怀疑上帝的意图：因为如果没有女人的概念的话，上帝造出来的亚当为什么具有男人的特点呢？很明显，上帝在一开始就考虑好了男人与女人的设计，至于伊甸园究竟是发生了什么就值得怀疑了，上帝如果原来就没打算制造女人，明显是不需要制造一个有男性特征的亚当的，所以制造女人应该是在制造亚当前就计划好了，否则男人与女人如何能那么容洽，刚好互补呢？于是乎，我们沿用上帝的思路来说，人，应该就是由男人与女人构成的，至于神话中先造男的再造女的，估计是因为MAN比WOMAN少两个字母比较好写的缘故。
由此，根据通常的思路，我们先想到了男人，又想到了女人，类MAN与类WOMAN就产生了，为什么不制造无性繁殖的个体呢？这是因为人与人之间要形成有效的联系与团结，必须要有能够牵引他们在一起的动力，即使是达到了最小单位上的，男与女也会有天然的吸引力，这才能保证在自然条件下生存的最大效益。男人与男人之间，或女人与女人之间，往往会发生斗争，一种无性繁殖的物种，也很容易消失在自然界中，观察一下自然界就会知道，无性系列物种往往具有极强的自我吞噬与毁灭倾向，即使是现存物种，也不可能发展壮大，更难以出现文化艺术之类的事物－至少在地球上是如此。
故而，设计最小是有男有女的两组一体的系统才能发生变化，可能至此还有人不明白，实际上可以这样理解，如果只有一个1，那么11是2，111是3，1111是4，有多少种变化就要多少个1，这会造成系统严重冗余，占用过多的资源，现在有了1与0后，大大地缩小了需要占用的信息空间，于是乎只需要10位，其中只要有1与0的区别，就可以产生一千零二十四种变化，如果只有1或只有0，那需要一千零二十四位，这个比率是非常大的。
回到性别上的讨论，SEX不代表男人与女人的性征是一样的，相反，它是我们用于区别男人与女人而提取出来的一个概念，这个概念是MAN与WOMAN的区别概念，我们应该单独提取出它为一为一个类来处理，于是产生了：
public class SEX
产生了SEX之后为了表达上的方便，很多时候我们其实中用string SEX，简化了类的表达，隐匿利用系统提供的便利，而无须再多写更多的代码，那么一个SEX定义成字段是很可怕的，因为调用方极有可能赋一个“太监”值来让系统彻底弄不清楚是怎么回事，于是，一个必要的CHECK必须出现，SPEC#与C#3.0中都提供了提供可以让我们达到这样的目的，这个异常应该是“性别”这个属性（实际上是一个类）来处理的。
采用值类型一个比较容易出问题的就是，当一个值类型扩展成一个类时，那么就可能导致大范围的修改，这是非常可怕的一件事，比如说，这里的SEX是一个string还不明显，可以说一个更加有趣的例子。
姓名，NAME，这个玩意一般是string，对于一般的NAME来说，string定义它就行了，string因为是final，就造成了如果我们后来发现string NAME实际上是不行的，我们要还具体分割出FirstName与LastName，那么怎么半，系统其它地方都是调用的NAME，直接获取全名，然而string又是不可扩展的，这就造成一个令人郁闷的事实，通常这样的问题会归纳在设计的水平上，虽然事实也是如此，但如果像这样的问题，直接调用字段就是造成不可扩展的罪恶的原因，在java中，对此一般就会统一要求getNAME或是setNANE来处理，即便是发生了变化也能处理，还好，在C#中，我们处理起来也不是很麻烦，就算用的是字段，那么重构为一个属性就行了，即把
public string NAME;
重构为：
public string NAME {get;set;};
很漂亮的平滑转变，因为属性会隐匿编译后成为get_NAME与set_NAME，在写法上隐藏了字段与方法间过渡的事实。
然而，现在我们要获取NAME中的姓，而不是全名，通常的扩展办法就是，把NAME加一个tool方法，比如GetFirst(string NAME)，来得到NAME中的姓。如果系统变化越来越多，就会造成越来越多的tool方法，混乱不堪。如何我们才能更漂亮地解决这个问题呢？
C#中提了插件方法可以用来解决这类问题，但此类问题除非没有更好的办法，否则并不应该用插件方法来解决，因为插件方法不应该插手到string这个型上来解决NAME这个限定域的问题，string涉及的范围毕竟太广了。虽然命名空间中可以由命名空间的显式指定为某个空间中的string操作，但是，除非string没有指明其它字段，否则仍然不应该在string上扩展它。
一个NAME，不仅可以代表全名，也可以得到姓，得到名，这时可以意识到NAME本身是一个LIST,我们只需要在里面加上FIRSTNAME与LASTNAME的实现就可以达到目的。
这样会不会有问题呢？想想，在现实中，有时我们会称呼，小张，小李，小王，也有可能会称呼，小晶，小红，小晶，也就是不称呼全名，那么，非全名一样可以作为该NAME在这个称呼集合中出现。
所以，这里的NAME作为一个成员时，仍然应该为一个具有List性质的NAME，而并非应该成为单独的NAME，当然，如果早期就已经处理好了FIRSTNAME与LASTNAME问题，就不必拆分NAME了。
这里其实说了半天，最后的总结是，无论它是否构成一个List，在循环化思想中，任何一个成员只能作为LIST方式出现，任意类型都必须是基于LIST的。从某种抽象角度上，我们看起来是这样:
public class MAN
{
public string List<Name>;
public string List<Sex>;
}
尽管看起来有些怪异，但目前没有够快乐的语法呈现能够实现我们不书写List它也作为List来操作的方法，至少C#不适合这种东西，它也仅仅能作为一种实现手段而已。
不多述，最后实现出来的层次应该是：
public IHuamn
{
public List<Feature> IFeature;
}
public class HumanFeatures:IFeature
{
public string Name;
public string Sex;
}
public class Man:IHuamn
{
public List<HumanFeatures> Features;
}
public class Woman:IHuamn
{
public List<HumanFeatures> Features;
}
既然循环是万物的基础，那么为什么我们还要反过来遇到有状态呈现时用循环语句来实现呢？实际上，无论何时都有循环出现，那么循环就应该是一种默认的实现，我们不应该针对数组或是集合进行处理，反过来我们应该认为万物能够，它就是一个集合或一组数据，只是我们在识别系统的特征概念时，才采用单元片断来识别。
本质上，现在开始，彻底应该忘记单元的概念，任何最小化的识别对象都是一个集合，都是其它对象的组合体，完全的系统论化视角。
我们声明一个Class，泛型的出现，让我们不必再定此Class的List或是Collection，所以，从现在开始，我们任何情况下的操作，都是针对List，永远不再会有单元类的直接使用。
这样的好处是什么？在我的概念中，一个类定义的本质也是其它的类的List构成的，在此基础上，我们就拥有了，把一个类转移为其它类的List或是此类构造一个List成为其它的类。
世界上有男人女人，那么这里就产生了MAN，按照此研究，本质的定义是一组可以具有符合MAN成员属性方法的实现对象的都可以称之为MAN，MAN本身就是一个List，那它具有什么样的特点呢？首先，它可以成为一个Company的Member，也可以成为Human的一个Member，就此，我们的定义应该是：
public class MAN
显然，这是一个MAN，我们在程序中永远不会直接出现针对单独的一个实例化MAN的操作出现，而是会采用List<MAN>.CreateMAN来创建一个新的MAN对象，简单来说，所有创建的新对象都将会有自己的List对它进行管理。
public class WOMNAN
它具有一个比较有趣的特点，男人女人都是人，那么它们的共同就是HUMAN，现在我们不会让MAN与WOMAN去继承，为什么，因为是男人与女人组成了HUMMAN,记住是组成，组成的含义就不再使用继承。
继承的最大作用就是利用代码，如果能够达到代码利用的目的，我们是完全不需要继承的，但如果需要更大量的代码来实现就会让人很郁闷。MAN与WOMAN都有SEX属性，按传统的方式，我们可以继承HUMAN来得到SEX属性，但这里，概念要转变了，SEX不再是HUMAN的属性，MAN与WOMAN是继承于它，而是反过来，有了MAN与WOMAN后，构成了HUMAN这个概念，然后我们抽象出来的共性才具有SEX，这个SEX是抽象出来的，抽象出来的东西，不是代表着你抽象后它才出现，而是你要根据现实来抽象的，所以，我们发现了一个更有乐趣的事情，SEX应该是一个属性，它作为MAN与WOMAN都具有的属性，不应该是自HUMAN而来，女娲造人神话也告诉了我们，女娲娘娘是同时造的男人与女人，而不是造出人来后，再把他们分别加工成男人与女人。西方的神话中上帝造了一个没有女人却有男人特点的亚当，不得不让人怀疑上帝的意图：因为如果没有女人的概念的话，上帝造出来的亚当为什么具有男人的特点呢？很明显，上帝在一开始就考虑好了男人与女人的设计，至于伊甸园究竟是发生了什么就值得怀疑了，上帝如果原来就没打算制造女人，明显是不需要制造一个有男性特征的亚当的，所以制造女人应该是在制造亚当前就计划好了，否则男人与女人如何能那么容洽，刚好互补呢？于是乎，我们沿用上帝的思路来说，人，应该就是由男人与女人构成的，至于神话中先造男的再造女的，估计是因为MAN比WOMAN少两个字母比较好写的缘故。
由此，根据通常的思路，我们先想到了男人，又想到了女人，类MAN与类WOMAN就产生了，为什么不制造无性繁殖的个体呢？这是因为人与人之间要形成有效的联系与团结，必须要有能够牵引他们在一起的动力，即使是达到了最小单位上的，男与女也会有天然的吸引力，这才能保证在自然条件下生存的最大效益。男人与男人之间，或女人与女人之间，往往会发生斗争，一种无性繁殖的物种，也很容易消失在自然界中，观察一下自然界就会知道，无性系列物种往往具有极强的自我吞噬与毁灭倾向，即使是现存物种，也不可能发展壮大，更难以出现文化艺术之类的事物－至少在地球上是如此。
故而，设计最小是有男有女的两组一体的系统才能发生变化，可能至此还有人不明白，实际上可以这样理解，如果只有一个1，那么11是2，111是3，1111是4，有多少种变化就要多少个1，这会造成系统严重冗余，占用过多的资源，现在有了1与0后，大大地缩小了需要占用的信息空间，于是乎只需要10位，其中只要有1与0的区别，就可以产生一千零二十四种变化，如果只有1或只有0，那需要一千零二十四位，这个比率是非常大的。
回到性别上的讨论，SEX不代表男人与女人的性征是一样的，相反，它是我们用于区别男人与女人而提取出来的一个概念，这个概念是MAN与WOMAN的区别概念，我们应该单独提取出它为一为一个类来处理，于是产生了：
public class SEX
产生了SEX之后为了表达上的方便，很多时候我们其实中用string SEX，简化了类的表达，隐匿利用系统提供的便利，而无须再多写更多的代码，那么一个SEX定义成字段是很可怕的，因为调用方极有可能赋一个“太监”值来让系统彻底弄不清楚是怎么回事，于是，一个必要的CHECK必须出现，SPEC#与C#3.0中都提供了提供可以让我们达到这样的目的，这个异常应该是“性别”这个属性（实际上是一个类）来处理的。
采用值类型一个比较容易出问题的就是，当一个值类型扩展成一个类时，那么就可能导致大范围的修改，这是非常可怕的一件事，比如说，这里的SEX是一个string还不明显，可以说一个更加有趣的例子。
姓名，NAME，这个玩意一般是string，对于一般的NAME来说，string定义它就行了，string因为是final，就造成了如果我们后来发现string NAME实际上是不行的，我们要还具体分割出FirstName与LastName，那么怎么半，系统其它地方都是调用的NAME，直接获取全名，然而string又是不可扩展的，这就造成一个令人郁闷的事实，通常这样的问题会归纳在设计的水平上，虽然事实也是如此，但如果像这样的问题，直接调用字段就是造成不可扩展的罪恶的原因，在java中，对此一般就会统一要求getNAME或是setNANE来处理，即便是发生了变化也能处理，还好，在C#中，我们处理起来也不是很麻烦，就算用的是字段，那么重构为一个属性就行了，即把
public string NAME;
重构为：
public string NAME {get;set;};
很漂亮的平滑转变，因为属性会隐匿编译后成为get_NAME与set_NAME，在写法上隐藏了字段与方法间过渡的事实。
然而，现在我们要获取NAME中的姓，而不是全名，通常的扩展办法就是，把NAME加一个tool方法，比如GetFirst(string NAME)，来得到NAME中的姓。如果系统变化越来越多，就会造成越来越多的tool方法，混乱不堪。如何我们才能更漂亮地解决这个问题呢？
C#中提了插件方法可以用来解决这类问题，但此类问题除非没有更好的办法，否则并不应该用插件方法来解决，因为插件方法不应该插手到string这个型上来解决NAME这个限定域的问题，string涉及的范围毕竟太广了。虽然命名空间中可以由命名空间的显式指定为某个空间中的string操作，但是，除非string没有指明其它字段，否则仍然不应该在string上扩展它。
一个NAME，不仅可以代表全名，也可以得到姓，得到名，这时可以意识到NAME本身是一个LIST,我们只需要在里面加上FIRSTNAME与LASTNAME的实现就可以达到目的。
这样会不会有问题呢？想想，在现实中，有时我们会称呼，小张，小李，小王，也有可能会称呼，小晶，小红，小晶，也就是不称呼全名，那么，非全名一样可以作为该NAME在这个称呼集合中出现。
所以，这里的NAME作为一个成员时，仍然应该为一个具有List性质的NAME，而并非应该成为单独的NAME，当然，如果早期就已经处理好了FIRSTNAME与LASTNAME问题，就不必拆分NAME了。
这里其实说了半天，最后的总结是，无论它是否构成一个List，在循环化思想中，任何一个成员只能作为LIST方式出现，任意类型都必须是基于LIST的。从某种抽象角度上，我们看起来是这样:
public class MAN
{
public string List<Name>;
public string List<Sex>;
}
尽管看起来有些怪异，但目前没有够快乐的语法呈现能够实现我们不书写List它也作为List来操作的方法，至少C#不适合这种东西，它也仅仅能作为一种实现手段而已。
不多述，最后实现出来的层次应该是：
public IHuamn
{
public List<Feature> IFeature;
}
public class HumanFeatures:IFeature
{
public string Name;
public string Sex;
}
public class Man:IHuamn
{
public List<HumanFeatures> Features;
}
public class Woman:IHuamn
{
public List<HumanFeatures> Features;
}
