我们初学面向对象的时候，书里面往往会用小猫、小狗、鸭子、汽车等举例子，说是可以把这些看成是一个对象，然后再弄出来一些属性、方法、事件等进行说明。 然后呢我们学会了这些，要在一个小的项目里面应用一下，比如网上购物网站的时候，我们按照这个思路来设计，我们会把商品看成是一个对象，把购物车、订单看成是一个对象，把客户、管理员看成是一个对象，然后寻找他们之间的各种关系，于是抽象、接口、实体类等等被一一设计出来。 这似乎没有什么问题，大家是不是也是这么做的呢？如果是这么做的话，那么大家有没有发现这里面有点小问题吗？
我还是先说一下我的做法吧，还是上面的网上购物网站的例子，我会这么做： 网上购物，要先有一个产品信息的列表页面（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部分是由美工出的）。
我研究表单，于是弄出来了一个表单控件，经过不断地完善、修改升级，现在已经基本可以应对很多种情况了。 当然，您可以说我举的例子太简单，没有复杂的业务逻辑而言，如果遇到了复杂的业务逻辑，我的方法就不适用了。 这个我承认，但是我也相信另一句话：由简入难。 先把简单的做好了，然后再去处理复杂的情况。
语文发在了博客园里，http://www.cnblogs.com/jyk/archive/2009/01/06/1369949.html 这里还有各位高手的精彩讨论！
我还是先说一下我的做法吧，还是上面的网上购物网站的例子，我会这么做： 网上购物，要先有一个产品信息的列表页面（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部分是由美工出的）。
我研究表单，于是弄出来了一个表单控件，经过不断地完善、修改升级，现在已经基本可以应对很多种情况了。 当然，您可以说我举的例子太简单，没有复杂的业务逻辑而言，如果遇到了复杂的业务逻辑，我的方法就不适用了。 这个我承认，但是我也相信另一句话：由简入难。 先把简单的做好了，然后再去处理复杂的情况。
语文发在了博客园里，http://www.cnblogs.com/jyk/archive/2009/01/06/1369949.html 这里还有各位高手的精彩讨论！
解决方案 »
- 请大家帮忙看看
- c#编辑器
- 滾動條怎么設置變成平面的?
- updatePanel局部刷新问题
- 自己的网站总被发垃圾广告，有什么好的方法阻止吗？？
- 类似于这样的代码，visual studio .net中是否可用鼠标拖放的方式自动生成一部分？
- 急~~ 如何用DataGrid显示2张表的部分内容？
- 在线等待: 刚装上vs.net,运行创建一个项目,都报错"Automation 服务器创建对象出错",怎么回事啊!
- 有关 asp.net 开发网站的问题，请高手指点
- 我的vs工具箱里面已有treeview控件，为什么把它象别的控件一样移到窗体实现所见即所得？，
- 50分求 一正则表达⑩ 只要正确答案
- Profile.Save问题
http://conan77.vicp.net
其实有好多系统已经做得很好了，比如SAP,Siebel,可以做到不写代码就可以作出一套系统出来,
系统设计确实学问很大很深, Have a long way to go.
从现在看 AOP 面向切面的编程 要在OO之上；
我觉得 只要能解决问题 也就是客户需求 用什么都可以 而有的人被OO束缚 认为OO是唯一，OO、设计模式是主流这个没错
但也是用来解决问题的，为了方便开发 扩展 维护的。
所以我认为解决问题最主要 思想可以变通，完全可以用Class 担当别的角色。
高手都在研究 framework 设计模式 那里研究什么oo啊
http://topic.csdn.net/u/20090108/16/2c0e2593-1348-4a4e-8a5d-9949c0cd0338.html
http://topic.csdn.net/u/20070525/17/9CCAA2F5-82AD-458B-90B1-3F9768304D75.html