面向对象设计原则--单一职责原则(SRP)

晚上在宿舍把WEBCAST翻出来，听了李建忠讲的关于面向对象设计的几天基本设计原则的课，半懂非懂听了下来，听完之后除了茫然还是茫然！也好，只有这样才能知道自己所知甚浅，所学甚糙！革命远未成功，吾须戒骄戒躁！
  (PS:个人觉得李建忠讲课水平一般，可能他是一个非常好的程式员，但不是一个好的讲课员，大概程式员都有这个通病，写个程序哪怕再复杂的程序都能应付自如，但让他讲课甚至是讲几句话，总让人感觉词不搭意，听过李建忠讲课的，肯定都会有这种感觉：断断续续，常为了表达一个词卡那半天，最后搜肠刮肚找出来的词仍然是词不搭意，但好在都是讲给程序员听的，大家基本都能明白他所要表达的意思)

原则一：单一职责原则(SRP)
   --- 一个类应该仅有一个引起它变化的原因(最简单，最容易理解却最不容易做到的一个设计原则)
  我想，所谓职责就是一个类所完成的主要任务和功能，单一职责应就是讲这个类只有一个目的和任务！
  也有很多人认为职责就是"变化的原因"或者是"变化的动机"，如果一个类有多于一个动机会要求改变这个类，那么这个类就不是单一职责，就是多职责了！
  这个和上面说职责就是类所需要完成的任务和功能，从本质上讲不矛盾的，从最终效果来将，类的主要任务和功能也是类需要变化的根本原因，因此从这点来讲，这2种看法是统一的！
  李建忠在他的课里讲了2个例子来论证SRP，一个就是职员类，一个是Framework类库里的文件类！
  
职员类例子：
  比如在职员类里，将工程师、销售人员、销售经理这些情况都放在职员类里考虑，其结果将会非常混乱，在这个假设下，职员类里的每个方法都要if else判断是哪种情况，从类结构上来说将会十分臃肿，并且上述三种的职员类型，不论哪一种发生需求变化，都会改变职员类！这个是大家所不愿意看到的！

将那些容易导致变化的职责分离，而不必将每一个职责都分离！
如果有一个原因导致类中其中一个职责发生变化，就应该将这个职责分离！
如果是导致类中所有职责都发生变化，则可以不分离！

SRP原则是所有设计原则中最基本的原则，坚持这个原则能够给我们带来的好处如下：
1.代码的可复用性
2.函数变短，可读性增强
3.不存在重复代码，结构精炼
4.函数功能单一，容易被替换