您把哪些东东看成了对象？
2009-01-06 07:31 金色海洋（jyk） 阅读(3136) 评论(66) 编辑 收藏 举报
我们初学面向对象的时候，书里面往往会用小猫、小狗、鸭子、汽车等举例子，说是可以把这些看成是一个对象，然后再弄出来一些属性、方法、事件等进行说明。
然后呢我们学会了这些，要在一个小的项目里面应用一下，比如网上购物网站的时候，我们按照这个思路来设计，我们会把商品看成是一个对象，把购物车、订单看成是一个对象，把客户、管理员看成是一个对象，然后寻找他们之间的各种关系，于是抽象、接口、实体类等等被一一设计出来。
这似乎没有什么问题，大家是不是也是这么做的呢？如果是这么做的话，那么大家有没有发现这里面有点小问题吗？
我还是先说一下我的做法吧，还是上面的网上购物网站的例子，我会这么做：
网上购物，要先有一个产品信息的列表页面（A 产品列表），点击一个产品后会显示该产品的详细介绍（B 详细介绍），如果满意的话，客户会把这个产品放在购物车里面（A 购物车列表），选好了产品之后客户会填写一个订单（C 表单），添加订货人、收货地址等，提交之后就会看到一个订单的列表（A 订单列表）。
对于管理员来说也会看到一个产品的列表（A 产品列表），如果管理员想要增加新的产品的话可以单击“添加”按钮，打开一个表单（D 表单）来添加信息。管理员也可以看到客户的信息列表（A 客户列表），然后可以查看客户的详细信息（B 详细介绍）。当然管理员还可以查询产品、删除产品、客户信息等。
请大家看看括号里的A、B、C、D，没错，一个网站对于我来说就是由列表、表单、详细介绍等部分组成的，也就是说我把这些都看成了对象，而且好像还是“抽象基类”，列表可以“变化”成前台的列表和后台的列表，然后呢又可以“变化”成产品列表、客户信息列表、订单列表等等。
这里用了“变化”而没有使用“继承”，是因为表面上看（或者是面向对象的习惯上来看）是派生了各种列表，但是实际上我的做法并不是继承的哪种形式。所以这里的抽象基类也用引号引了起来。
两种做法都说了一下，先看看我前面提的那个小问题吧。
对于第一种做法来说，我们在做一个网上购物网站的时候要建立商品类、订单类、购物车类等，这个项目做完了之后我们做下一个项目的时候，假设我们下一个项目是CRM，那么我们就要建立另一套实体类，当我们再做OA的时候，又是完全不同的一套实体类。
即使是同一个项目，商品类和订单类也不尽相同，但是又很类似。类的属性是不同的，但是代码里面，除了属性名称变化了一下，其他的代码是不是一样的呢？
我的方式，就是把列表、表单、详细介绍等看成了对象，也可以说是把数据库本身看成了对象， 以达到以不变应万变的目的，不管是什么样的网站（静态的除外），都是离不开列表、详细介绍、表单等功能。我研究的对象就是这些。
既然现实世界里的小猫、小狗、鸭子、汽车、书等等都可以看成是对象，那么数据库为什么不可以呢？以前有人讨论book.Save是否够OO，而我的想法是 “数据库.Save”，不对，应该是“表.Save”，就是
表.Name = "产品"
表.Save()
当然这么做就会有一个很大的局限：必须使用数据库！
其实这种做法只是针对那种需要使用数据库来保存信息的项目，如果您的数据是保存在内存、XML、Txt等里的话，那么很显然这种方法就不适用了。
虽然有局限，但是对于我个人来说，这个使用范围也是相当的大了，这个也够我研究好几年的了。
我想做一个架构，这个架构的使用范围就是：使用数据库保存数据。
这里的数据库指的是SQL Server这类可以使用SQL的关系型数据库。
这样做的好处是很大的，不管是什么样的网站（动态网站），都可以看成是由列表、详细介绍、表单、查询等部分组成的，那么如果能把这些基础“部件”研究好了，让他们的适用范围更广，功能更强大的话，那么网站的实现代码就会很少。也很方便。
我研究列表，也就是说如何把数据从数据库里面弄出来，放在页面里面，还要能够很方便的和没工作的HTML结合起来，于是“餐盘原理”就出来了。餐盘原理的目的就是解决在网站里面用列表形式显示数据的问题。这个做好了，无论是产品的列表还是购物车的列表还是订单的列表，对于我来说都是没有区别的，唯一的区别就是，数据存放的位置不同而已。
列表的另一个主要部分就是我的分页控件，也就是QuickPager。我以前做网站的时候，这个QuickPager占据了网站的50%以上，只要给它的属性赋好了值，那么也就相当于完成了一个表单页面（当然HTML部分是由美工出的）。
我研究表单，于是弄出来了一个表单控件，经过不断地完善、修改升级，现在已经基本可以应对很多种情况了。
当然，您可以说我举的例子太简单，没有复杂的业务逻辑而言，如果遇到了复杂的业务逻辑，我的方法就不适用了。
这个我承认，但是我也相信另一句话：由简入难。
先把简单的做好了，然后再去处理复杂的情况。
