接口主要用于多态！提高程序的灵活性！易扩展
对呀，我举的例子也是这个意思呀。
显卡从芯片上分为两种，GeForce和雷。
从生产厂家上分，那就更多了，这些都可以看做是多态呀。
显卡的多种形态，但是只要显卡是PCI-E的，那么就可以随意更换，对吧。
你买电脑的时候，有很多的显卡可供选择，256M的、512M的ddr2的 ddr3的，非常灵活呀。也很容易扩展，显存256M的不够，那就换成512M。
当然这个不想内存那么容易和省钱。呵呵。
对了，内存，内存也是实现了同一个接口呀——DDR2。
看不懂没关系，慢慢看嘛。我也是用了好几年的时间才弄懂了一点。
同意4楼的说法，接口的意义在于多态。
TerryLee的这篇
抽象工厂模式（Abstract Factory）虽然是讲模式的
但是看过了，可能会更深的理解接口与多态的概念。
abstract 的方法不能写实现的代码，但是 override的方法就可以写点代码了。
抽象类里面可以有 abstract的方法，也可以有override的方法。
谢谢提示，看来还是没有弄清楚这些概念。这里还是单独说接口吧，抽象类以后再说，呵呵。
抽象函数在父类里面定义，可以写点实现代码，也可以不写实现的代码。
-------------------------------------------------------------
可以写什么实现代码？可以举个例子吗？
http://www.cnblogs.com/gaozhongfa/archive/2008/07/22/1248782.html
这篇文章指出：
在方法或属性声明中使用 abstract 修饰符以指示方法或属性不包含实现。
比较是一只想做的，但是基本没有什么可比性。
1、工作范围不同。
aspnetpager 只工作在UI层，就是说只负责绘制页面，触发一个事件，事件的处理都不管。在这方面我承认，现在还是比不上的。
另外aspnetpager还可以对xml分页，还支持ajax，这些都是我的分页控件目前所没有的。
2、我的分页控件的特点，aspnetpager基本都不具备。
我的分页控件可以灵活的更换分页算法的，可是aspnetpager本身是不带分页算法的。怎么比较呢？
3、总体比较。
aspnetpager更灵活，适用范围更广，但是使用起来有点麻烦，还得另外处理如何提取数据等问题。
QuickPager使用很方便，设置好属性后就万事大吉了，当然有些时候还需要写一个视图。有很多的分页算法可供选择，也可以自己编写分页算法。
对于暂时不支持的数据库，也可以像aspnetpager那样只工作在UI层。
4、总结，aspnetpager拥有的功能，我可以学习过来，但是好像QuickPager有的功能，aspnetpager并不太想学习，呵呵。也许是觉得没有必要吧。
ps:打算在加一总方式，就是可以支持aspnetpager用的存储过程，设置存储过程的名称，就可以使用aspnetpager用的存储过程了。呵呵。
回头能不能弄个和aspnetpager的比较呢？很期待
”系统中相对稳定部分“，这个相对稳定部分我想应该指的是方法定义，而不是方法实现，方法实现绝对不可能稳定，试想，有谁写类方法时可以保证它的代码一定不会变呢。但在设计类之前，一般要将方法返回类型、参数等信息定好，这些才是相对稳定的。
至于楼主说的”系统中相对稳定的抽象出来封装成function“， 我感觉好象有一些不妥， 相对稳定用在function是什么意思，还用了封装，封装一般指的是对实现代码的封装，实现代码是不可能相对稳定了，只有方法定义才能称为相对稳定。
实际上，这就是如何处理程序中”做什么“和”怎么做“的问题。
对于”做什么“，实际上就相当于接口中定义的方法（或抽象类中的抽象方法）。注意，不是类中的方法。这是强制的，要求类必须实现这些方法。 因此，接口实际上就是解决“做什么”的问题。而且接口也是多态的核心。多态的核心思想就是只关心方法做什么，而怎么做，完全是由多态后面的实际对象去完成的。也就是说，使用多态只需要面对接口（当然，也可以是类，但一般使用接口来实现多态）。不过方法做什么，用户只面对的是接口中固定的方法，也就是说，方法是一个，可以有多种行文。
关于”怎么做“，当然就是类中的方法实现了。这个就不多说了。
关于面向对象接口、类、抽象类的概念使用代码可能更高地理解他。这种东西通过概念是很难准确理解的。 就象英语语法，没有必要专门去研究，只要多听、多写，多练，总会有明白的一天的。
任何的概念都可能会使初学者理解成别的意思。只要多编写程序才是真正理解它的唯一方法。
举例嘛，无所谓了。个人的理解是不一样的，所处的待遇也是不一样的。
可能我在的公司比较小，领导好像没有专职秘书，只有前台。
>> 封装保证了代码模块化，提高了软件的复用和功能分离
这个是没有什么分歧的，只是我感觉，有些人直接接触面向对象，不知道面向过程，所以我觉得应该给面向过程留一点东东，否则的话，会感觉得面向过程一无是处，一点优点都没有。我只是这个意思。
>>提供稳定的对外接口
这个接口应该是广义上的，不仅仅包括interface，还有应该有 function等。
是凡外部可以访问的都可以称作为是一个“接口”。
这一句是没有问题的，内部可以比那话，但是对外一定要稳定。
>>因此，系统中相对稳定部分常被抽象成接口。
这一句就费解了，要看看上下文：封装要保证的。封装可不仅仅是interface呀，更常用的是function等。
我觉得应该说成，把系统中相对稳定的抽象出来封装成function，相对不稳定的抽象出来，做成稳定的接口。
“稳定”是指interface本身的“定义”来说的，interface的实现就是千变万化得了，交给继承了接口的类去实现。
这个我觉得应该说的详细一点，如果说清楚了，就不用麻烦您来做更多的解释了吧。
3. 封装保证了代码模块化，提高了软件的复用和功能分离
还有这一点，模块化并不是哪种软件设计思想的专利。因为类也可以叫做一个模块，甚至一个子系统都可以叫做一个模块。 将类的封装特性说成是将代码模块化，并没有什么不妥，类也的确是一个模块。 再说，面向对象实际上只是面向过程的升级，在类的内部，就是面向过程和面向对象的混合体。因为在类的内部可以有方法、类全局变量、inner class等。
现在软件设计思想的发展也相当于生物的进化，在进化的过程中也会留下进化链中其他生物的影子。
2、提供稳定的对外接口。因此，系统中相对稳定部分常被抽象成接口。
第二点说的没错，因此后面的是根据“提供稳定的对外接口”引出的，也就是说，一个接口一般会有很多个类实现它（如果只有一个类实现一个接口，那么接口就没有任何意义了），既然是很多类实现它，那么这个接口中的方法就必须是稳定的，如果接口中的方法不稳定，就是说接口中的方法总变的话，那将会影响很多实现它的类。 所以这本书的作者说“将系统中相对稳定部分常被抽象成接口”是没错的，
不过将接口说成是相对稳定的，感觉是有点别扭。实际上，说白了，接口就是所有实现它的类的交集而已。 也就是说，只有很多类拥有同名、同参数的方法，这些方法才可以被抽象出来，形成接口，因此，我个人认为，接口就是类的抽象，而类是对象的抽象。
你最后那个例子举的不贴切，public可以说成普通员工，但private只能是领导的小秘了，别人都不能去叫领导的小秘，只属于领导的
本来想换成现出来的那个皮皮，但是，换完了，图片看不全了，又忘记原来的是什么了，所以就随便换了一个。
分页在 b/s + 数据库 的项目里面至少要占到50%吧，网站项目里面占得比例就更大了，所以处理好分页，可以大大提高工作效率。
沙发:)
才几天没见,皮皮都换了????
支持一下,一会儿花点时间来研究下:)
买好书还舍不得钱呀。好书且用得上的，我是不会吝啬的。
最近来的一点体会:如果你试着写一个类,而这个类的参数不是值递的简单基础类型,比如是某个类的对象,然后在你这个类的方法里面去调用传递的参数的对象的方法或属性,这样就能体会OO了?为什么呢?因为传进来的参数如果你是按接口或者基类传的,那么你只要传递符合接口或基类要求的对象就可以,而不用考虑它具体是哪个类型.
常困惑于实体对象和业务对象,如果业务对象只是简单的一堆方法,其实这和面向过程没有区别,只不过是以类来组织,以前可能是以模块来组织,这不是OO.
看了很多评论，发现大部分都是在IT公司做开发的，而且是做那种企业管理系统之类的，所以觉得层次分明是很重要的（这些都很正确，因为我也做过开发）。虽然做的系统需要都是ASP.NET的B/S，但是大系统基本上都是在局域网运行的，所以速度是不重要的，关键是逻辑。但是在Internet上的网站，就不得不考虑速度了，10人访问、100人访问、1000人访问、10000人访问呢？
这个与采用什么方式设计没关系似乎.个人从事ERP作业,主要服务提供钢铁,交通,电力,冶金,制造等领域解决方案.博主问题中有很多东西在基础数据部分就可以解决的.看似复杂,理顺了也就没什么了.更复杂的可能大家很少见过.
问一个比较菜 的问题
如何把一个
TreeView 赋给另一个TreeView，
就是TreeView 如何相互赋值？
（一） 预定一种食物
1、客户甲定了一份牛肉萝卜包子，服务员记录后选择采购员。
要先选择有卖包子陷的资格的人，然后找能够卖牛肉和萝卜的人，如果找不到既能买萝卜又能买牛人的人，那么就得找两个人。然后还要看“承重”能力，比如要买50斤萝卜，某人只有40斤的采购能力，那么也是不能选的。还有负责的地区，还要考虑时间上不能冲突。
我觉得这个真的是设计过度了，管的太细了，按照你的说法的话，采购员必须要设置他可以买的原材料的资格，还要设置承重能力，但是一点加入这些功能的话会系统变得很难维护，因为这些数据变动的很厉害的，举个例子“承重”能力，某人只能买40斤东西，ok他买了一辆自行车，承重能力提高了，那你是不是要到系统里改一下用户的承重能力啊，不改的话，这个用户还不能去做采购大于40斤东西，用户业务跑不了，要是用户一只手摔伤了只能拿一般东西呢，实际使用过程用户对这块的数据设置会很烦的，业务有很多东西是随意的，不要试图去管理，一方面自己工作量变大，二方面客户工作量也变大了。
（二）
1、客户甲定了一份牛肉萝卜包子和一份三鲜馅饺子，服务员记录后选择采购员。
这回要找既有买包子陷资格的人，同时还有买饺子馅资格的人，找不到的话，只能派两个人去；然后是具体的食物，牛肉、萝卜、鸡蛋、虾仁等。同上。
这个我感觉超出你做的快餐系统的职责了，这块东西拉出来单做一个采购系统，对于你的快餐系统只需要关心一下原材料的库存即可，库存不足直接报警，采购部门看到以后自行处理。
做系统也包含一个帮助客户分析和梳理业务的过程，你不能跟着客户走，他说什么你做什么，你要站在系统的角度去审视人家的业务，给客户提出一些合理的业务调整意见，让这个系统运转更有效率，这样才能做出一个双方都很满意的项目。
对于这个项目的分析我支持10楼的意见，一个项目还要看为谁服务：
老板，记账员，经理，客户
至于员工该怎么做出不同类型的包子也好，饺子也好等等，这只是员工的一个技能，总起来就一个菜单（有新的技能加到菜）。
@BlackCat
至少也得用上10年呀，客户已经有了8年多的资料了。
这个项目可以做成一个小型的ERP系统了。下面我简单说一下：
1.人员模块:其实就是HR模块。
--------------------------------------------------
营业员、采购员的自然信息、学历信息、劳务合同等的记录。
--------------------------------------------------
这就是HR模块的人员基本信息管理。（我认为这里还少了很多需求，比如员工的工资，奖金，还应该有一个日历，显示员工的出勤状况，等等需求都是典型ERP产品的HR模块实现的）
--------------------------------------------------
采购员的采购能力、级别、能够采购的原料的管理。
根据客户预定的主食，选择适合采购员进行采购，同时生成采购员的日程表，以便更好的管理。
--------------------------------------------------
这个地方的需求，我认为最好不要设计到人员模块里，这个应该设计一个采购模块，能力，级别都应该是采购组角色具备的特点。
客户预定主食：其实就是采购订单。
采购日程等等这些都是典型ERP产品采购模块所具备的。
2.客户管理
--------------------------------------------------
客户采用会员制，可以订餐。要记录客户的基本信息，客户的预定信息（保留历史记录）。客户还可暂停预定、退订。
--------------------------------------------------
这个地方，我认为有一些不妥之处。首先客户基本信息跟客户的预定信息就不应该设计到一起。客户基本信息其实就是ERP的基础数据中的客户信息，记录所有客户的基本信息，会员什么的，也就是客户所具备的角色管理。预定，退订，都是属于ERP系统中的销售模块所具备的特点。所以这里我认为客户管理与销售订单应该分开来设计。
3、主食的制作工序的记录
-----------------------------------------------------
每一道工序都要记录一些信息，以便计算成本等（这里有点牵强，没有想到更好的表现方式）。
-----------------------------------------------------
这个地方明显是ERP产品中的生产模块，工序什么的都是典型的ERP生产模块的词汇。当然你这里又说到了成本2字，其实应该是ERP产品的成本模块，不光生产有成本，人员的工资，采购的花费，包括打车的钱都叫成本，所以你这里说的是有一些牵强。
4、财务管理
----------------------------------------------------
简单的计个账就可以了。
----------------------------------------------------
天那，简单计个帐就行了，我真不敢想象，财务模块在ERP系统中是非常重要的，你帐记错了，本来亏本，你记个盈利，那能行吗？包括一些发票的打印，费用的计算，工商，税务，要查你，怎么查啊？不看你帐怎么记的啊？包括你自己想要看一下这一年来花了多少钱，赚了多少钱，都要在这里实现啊！！从头到脚来说财务都非常重要，怎么能跟“简单”这个词放在一起呢？
5、提醒管理
-----------------------------------------------------
根据客户的预定信息进行提醒，比如今天中午有哪些客户预订了哪些食物。
-----------------------------------------------------
这个在销售订单里能看的清清楚楚。
以上只是我简单的看了看，又简单的写了写，时间原因，我还要工作三，所以暂时只能写这些，这个东东难度是非常大的，并且非常复杂的，其实还有好多我都没有写出来，看了上面的文字，您觉得您设计的这个产品的生命周期能有多长时间呢？？？如果能用到1年，我感觉就非常不错了。。。。。
用面向过程做出来的项目乱，用OO做也不见得好到哪里去，用不用OO关键在于你对OO的理解程度，我们项目用OO也差不多3年了，也不敢说对OO理解有多深，很多东西还是要参入一些面向过程的东西，OO是把双刃剑，用得好，项目会写的很优雅，用的不好，项目比面向过程的还难维护。
顺便问一句，lz的项目完全实现了你下面说的业务了吗？实现的话，你们可以直接卖产品，还是比较复杂的。我觉得做项目的话没有必要实现客户所有的业务，把握住核心业务就行了，什么是核心业务，就是客户用来赚钱而且这块人工成本比较高的业务，不管你的系统做得多好，你总有处理不了的业务，你就得好好规划那些系统管，那些系统不管，而不是一股脑都做出来。
@斯克迪亚
这里只是一种“比喻”，确实很牵强，容易误导人，我只是把实际的业务需求转换成了这个形式，在做包子的过程中确实不需要这么细致，但是真实的客户不是做包子的，真实的业务需求要记录的东东还要多很多。用A4纸打出来，就是厚厚的一个资料袋。
@辰、 Vincent
感谢提出自己的想法、思路，谢谢！
UI部分的确认过程应该跟随backlog.并且在短时间内就确认实现.不要给客户太多的时间在一个page的UI上.你给他思考的时间越多,他的想法就越多,最终导致在某个UI上浪费大量的时间.
一旦你可以在短时间内实现UI,他的思维将围绕你所给出的UI上面,并且由于你已经实现了这部分的功能,他对UI部分的需求可能就不会要求太高,甚至直接接受你的提议进入下一个Iteration.因为他的头脑中将会被"这个部分功能已经实现,该做下一步了"的想法占领了.
以上应该是对那些不成熟的客户,他们一般自己对需求都不甚了解,一味的去挖掘客户的需求是得不偿失的.
首要任务是完成项目,不是完成完美的项目.
至于前期开发时间,我认为首先确认故事.逐步完成backlog,同时跟随backlog完成相关Domain部分的代码.UI部分也随之确认,此时的UI部分可以用html等能够呈现大致效果即可.当UI部分确认后即可跟相关的Domain结合,然后发布给客户验收.依次类推,Iteration下去直到完成.
以上是我的想法,无论对错与否愿与各位探讨.
可以订购的商品一定是在基础设置部分就已经设置好了的.同时在维护个工序的资料.
这个时候商品与工序应该就是个多对多的关系.
在设定商品的同时就把工序也关联上.
关联之后,选定一个商品自然就会得到这个商品所要用到的工序,这个时候有关工序的成本不就是也计算出来了吗.
上面是项目管理，接下来是架构设计
由于我的理解是信息系统，因此和oo没太大关系，oo主要体现在架构设计，例如采用各种的design pattern去提高程序的灵活性和健壮性。
大部分设计还是在数据表的处理上，这个如果采用了.net,也没有什么oo了。
很复杂的项目
我当时做的一个零售业的项目基本上1个月的拼才出来。怎么设计和团队的积累有关。
如果一个大型项目，最快也要半年才能稳定实施。
第一阶段：
时间：3天；
内容：如果现在我接这个项目，首先和客户谈需求，采用extreme programe方式，参考以往的项目经历，在3天时间开发一个最简单的原型，.net，winform技术，没有任何框架可言，直接界面调用持久层完成数据处理。
第二阶段：
时间：1个月；
内容：在原型系统基础上，用1个月时间和客户商谈具体需求，数据表的设计，签订合同，修改原型系统。
第三阶段：
时间：1~2个月：
内容：开始采用Iteration模型，直接抛弃原型系统，原班开发人员作为核心人员开始大型开发，加入各种的框架（持久层、工作流、权限、各种UI），1~2个月时间开发完毕，客户第一次验收。
第四阶段：
时间：1个月；
内容：听取客户的建议，开始修改UI，提高系统易用性，这个时候关注整个系统的安全性、用户操作是否会导致出错、UI是否方便等。如果需求发生变更，小范围的允许修改，大变动的放在项目上线后，或者放弃（如果再大规模修改，要么加钱 要么加时间）
第五阶段：
时间：1个月；
内容：系统上线测试，与原有系统开始平行运行，输入真实数据，检查错误。