我理解的面向对象

面向对象已经出来很长一段时间了，和面向对象有关的书也写了不少,出了不少,自己也曾读过一些大作.再加上自己的经验和感受,形成了以下的理解.

第一,面向对象的核心是类.其实"类"是中国人自己翻译的，很形象,但是从我的角度来讲,类这个词感觉很空洞,很抽象.不过对类的定义:具有相同或相识属性和行为的一组对象的集合,还是很贴切的。但是有一个不好的地方就是:在类的概念中又引如了一个新的概念,那就是对象.其实在我看来，对象这个概念,其实也是同样的重要.如果不知道什么是对象,那怎么知道它的集合是什么.所谓对象,其实很好理解就是现实世界中的事物.没当提到这, (几乎所有的书上都是这么说的).其实我觉得不太贴切.我认为,现实中的事物和作为一个组成单元的程序中的事物是两码事.这两个事物有一个是源,有一个是在源事物的基础上抽象起来的。所以对于类的概念我认为有必要做如下改动:类是抽象自现实世界中的,具有一定属性和行为的对象的集合.这样首先在概念上强调类的组成部分其实不是简单的现实世界中的对象.而是一个经过加工、处理的、满足程序要求的编程单元。在面向对象的角度我认为可以这样讲。

首先，明确了概念后，那接着来看一下，类到底是什么？由什么来组成。如果从编码的角度来讲，类中的成员无外乎字段，属性，方法（包括构造函数），事件，其他类型（接口，类，委托，枚举，结构体）。但如果从设计的角度来将，UML中把一个类分了三部分：类名，类的属性，类的方法。类名没有什么好说的了；类的属性，我认为就是“让类之所以成为该类所具有的信息的结合”。虽然有点拗口。但是的确就是这样的。说个例子：假设我们写了这样一个类：
class Person{
......
string Name;
string Address:
string SSN;
......
}.那么可以想象一下，这是我们经过抽象的，假设满足程序要求的“人”类。那么是不是只要是人都应该具有这些属性。或者说，属性体现了一个类的静态的信息。刚才的例子，三个属性（姓名、住址、SSN）保证了一个事务之所以称之为“人”所具有的信息。那么如果对这些信息进行初始化以后，那么这个人就不在是泛泛的一个概念了而是具有了“姓名”、“住址”、“身份证号”的这样一个特定的人了。所以说，属性表达的是静态的信息，它标识了一个对象区别于同“类”中其它对象所应该具有的详细信息。那么，在实际编程过程中，属性也的确是这么做的；

再来说一下一个类中的方法：方法是一个类中动态的行为，告诉我们干什么事情。这是一个大原则，也可以用于指导自己如何去抽象一个类中的方法。还是刚才那个例子：
class Person{
......
string Name;
string Address;
string SSN;
Eat();
Drink();
Sleep();
......
}.无论什么样的人（正常人），都必须有上面的三种方法。

好了，至此，我们已经对类和对象，这样独立的实体（或者叫编程单位）熟悉了。那么再从现实的角度去考虑一个问题：社会当中的任何活动是不是都是在各种对象相互合作（或者叫关系）下完成的。是的，从哲学的观点：世界中的任何事务都是和外界相联系的。证明了这样一点。那么很显然，如果用面向对象的思想如进行软件的开发和设计，就必然脱离不了这个束缚，事实证明软件开发也的确是这样的。拿三层体系结构来讲。其中的业务逻辑层，其实就是在对软件系统中各个逻辑的对象进行抽象，其实我认为抽象还是相对比较简单的。如果将抽象出来的这些功能节点（类，编程单位，都是一个意思），让他们有机的建立联系，完成这样一个功能网才是最困难的。倒过来说呢，只有把握好事物之间的联系，才能更好的去指导设计逻辑实体。相辅相成的。说个例子：消费者要买商品（一个电子商务网站的功能），那么很显然牵扯到消费者和商品这两个类，那么这是一个正向的过程，那么在建立这个联系的基础上，应该想到如果通过网站来现实交易，应该加上购物车和订单这两个类，才能真正的实现网上购物（当然有的业务逻辑不是这样，这里只是为了好说明问题）。那么推出后两个类的过程，就是反向过程。四个类都抽象出来了，业务流程也就出来了：消费者选择商品，提交到购物车，生成订单，结帐。

还要说明一点，类出来了，其实真正的业务逻辑的实现不是类，而是类的一个实例（对象）：真正购买商品的是“张三”（消费者类实例），购买的商品是三星S500数码相机（商品类实例），生成购物车B001（购物车类实例），生成订单O0001（订单类实例）。这就指导大家在编码的时候真正要做到“面向对象（实例）”。