我发现很多人喜欢用这个来阐述自己的面向对象观点。所以我也来模仿一下。

我想写程序首先要熟悉业务。

首先分析一下业务流程中有多少个对象，先不关心这些对象是否真的有必要存在，简单罗列出来，方便我们总结业务流程。

首先是图书馆，放书的地方。

然后图书管理员，图书馆的老大。假设有两个服务窗口，那么就要考虑多个对象之间是怎么协调的。

或者还有保安之类的，不过应该和管理程序没有太大关系，可以忽略。

之后，有借书人，当然还有些人不借书，专门偷书的。

图书馆除了借书活动之外，也会有库存管理等问题，比如图书自然损耗，人为丢失，或者要添加新的书，或者发现某些书不够和谐，要禁止被外借之类的。

所以，站在图书馆的立场，我们会发现很多内务的细节。

如果我们站在普通借书人的立场，谁还管图书馆怎么运作，我只需要借书还书就可以了。

这就要我们学会多个角度去分析对象关系。

分析对象关系有两种方式，一个是站在不同对象去观察外界，第二个是基于流程去分析。基于流程去分析有个好处，就是过程很清晰，实现简单，比如那些基于数据表格的程序就可以用这个方法，弄懂不同状态之间的转换，进行查增删改等操作。

但是业务流程有一个不足之处，那就是业务流程是非常复杂的，你要贯穿全局去分析问题，而不能简单的针对某一个对象去分析问题，不能做到把问题局部化。

第二个，如果你基于流程，那么你写的程序往往就是有限的流程路线，用户必须按照你预先设计的路线去操作，缺少灵活度。

所以我还是觉得应该尽量去掌握基于对象去分析的方法。

回过来。对于借书人来说，只是希望图书馆就提供一个查询有什么书，借书，还书的简单界面。

而图书馆的角度，希望跟踪谁借了书，还有押金多少，怎么收费等。

图书管理员是图书馆的一个窗口，作为窗口目的是提高并行度，最大的希望就是不同窗口之间数据应该同步，不要这里借出去了，那里又借出。

还有没有涉及的对象，比如书本。在这个场景中，书本并没有什么动作，因为它主要是被操作的对象。当然，你可以增加书本的概念，比如希望他管理自己的数量，记忆谁借了它之类的，这样相当于把一个大的图书馆概念，又细分到每一本书身上。问题是，这个代价值不值得？

为什么这么说？首先图书馆有很多书，如果我要知道借了多少书出去，那么我就要枚举所有的图书，而这个接出去的，和总库存之间有很大的差距。因此我希望可以建立一个虚拟的对象，那就是图书馆借出去的书的列表，我只需要和这个对象通信，就能以最有效率的方法知道借了多少书出去。

可见：面向对象，所谓对象的存在性，和他的物理实体没有必然的关系，关键是我们需要知道什么东西，然后建立相关最高效的实现，这才是我们的目的。

这就是需求导向，没有需求的面向对象，不针对需求优化的面向对象，是没有什么意义的。难道因为书是纸做的我们就要实现是哪个厂生产的这种属性么？

对对象进行分析后，我们可以得到不同对象立场去观察的环境。通过结合需求，我们可以创造出最合理的对象。一个对象可能有多个界面，因为有多个不同的观察角度。等一个环境的对象关系搞清楚后，又需要针对每个对象内部进行细分。如此进行大概就能得到比较满意的结果。

建立对象概念之后，具体还需要有些设计技巧。

第一个是对象自身的设计。对象有两类操作，一个是查询，一个是修改。只是提供查询功能的相当于复合型数据结构（抽象数据定义？），可以认为他是没有多少对象的概念的，只需把他当作变量。只有修改操作才是对象的灵魂。

第二个是对象关系，比如组合，包含，1对1，1对多，多对多之类的。

第三个，对象的通信方式。第一种是直接调用，第二个是委托调用，还有什么推模式，拉模式之类的。

第四个，算法工具。算法是效率的根本，对象要根据算法来设计，否则低效率的面向对象关系是没有意义的。

第五个，语言的集成，要用库去实现业务，不要自己重复设计，要把业务代码改得比较配合内置的库功能，比如集成linq查询的接口之类的。

第六个，用工程思想去分步实现系统。

当然，这些都是泛泛而谈啦，也希望听听大家的意见。