一点体会（面向对象）
面向对象最终想解决的问题就是代码重用，应变业务经常变动(非常小的项目且业务不经常变动例外）。其实对面向对象的理解，我也不深刻，算是一知半解而以吧，要是只是说三大特性（封装,继承,多态）的话，我想大部分程序员都知道，但我觉得只会用，没什么用。主要是思想，在写代码的时候要有那种意识。
一般我们在分析的时候，都会想，这个系统有什么功能，我们应该做什么。这个“有什么功能”就是一个用例，用例就是描述一件事，比如说借书，应该先做什么，再做什么。大概是这样“借书人员应该先到图书管，出示借书证，图书管理员检验借书证，再查找借书人员所要借的书，交给借书人员”，这就是一个完整的用例。一般我们会想，先是怎么样再是怎么样。对，分析用例的时候大家都是这样，也应该是这样。这使大多数人往往很容易深陷下去，写代码的时候，也是这样想了，这样就成了面向过程的编程了。
用例确实要写（画）出来，系统分析人员可以根据用户，得到系统的一些对象，比如（借书人员，图书管理员）这些对象，他们能做什么事（行为），对象里面就包含他们的行为，然后在业务层里，比如说借书这个业务，再集合起这些对象的一些行为，就变成了业务层（应该是业务外观层）只是一些行为的集合，没有具体的实现，具体的实现都应包含在对象的行为里面。这样的话，如果是业务有变动的话，大部分情况下我只是修改一些业务外观层借书业务里面的一些对象的行为调用，当然一般的业务修改除了要改变业务层之外，对象的里面的行为也会有修改但很少影响到多个对象的关联即使是有，问题也不大，最起码这些全都是分开的，容易理解。其实看上去好像“面向模块”也是这样一回事，但用面向模块的话具体的实现（对象的行为）存放的位置会显得很乱(在我目前的公司我是这样感觉的），如果是使用面向过程，给我的感觉所有的东西都是集成在一起 了，想修改很麻烦，因为很难把握所有代码（超过一定的行数就容易出错，越多行的代码越容易出错），相反面向对象不同，因为你在写对象的时候，你不知他会在哪里用到他这个行为，所以你只要关心当前这个对象的行为是否正确就行了！比如上面提到的借书业务，使用面向过程的话，你要顾虑到的代码是整个用例，但如果使用面向对象的话，你只要考虑其中的一小部分（可能是管理员查找借书人员要借的书），这一小部分的代码绝对是比整个借书流程的代码少的！所以出错的机会也就小很多。
看了上面，我觉得写得挺乱的（文采不好，请见谅），可能您不知我在写什么感觉是东一句西一句的，其实我想表达就只是说，业务层里主要的只是对象的一些行为的集合而以;
上面纯属个人见解，也可能我的见解是错的，但起码深思过有收获，如果是错的，请您提出来，谢谢！
