面向对象编程的理解

   学java很多年了，工作中也用了2年，始终对这三大机制似懂非懂，这次抛砖引玉，希望看看大家的意见。
   从工程的角度说，为了避免软件危机,程序员需要相互协作。从效率的角度上说，需要代码复用。从设计的角度上来说，
需要高内聚低耦合。从扩展的角度来说，需要考虑设计模式。

继承
      为什么要采用面向对象技术？这道题目的答案是：主要原因是软件重用和便于维护。软件重用，对应面向对象中的继承机制。
      继承，让代码可以复用。
封装
      假如有这样一个程序，从功能上划分为10个模块。假设每个模块用一个代码块实现，需要用到10个代码块，假设每个代码块需要使用50个变量。那么，为了完成这样一个程序功能的实现，需要维护500个变量。函数机制的出现，局部变量和函数参数的使用，大大减少了需要维护变量的数量。同时，因为局部变量不可见，不可调用，提升了代码的安全性——别的程序员不能够通过修改局部变量，改变函数整体的逻辑。从代码块，升级到函数，大大提升了程序员的协作能力。函数对局部变量进行了封装，使局部变量不可见，不可用。一个类对其内部属性的控制，更加方便，更加强大。减少了全局变量的使用。
      封装，便于变量的维护和使用。提高程序的安全性。
多态
       实现多态，有二种方式，覆盖，重载。
       覆盖，是指子类重新定义父类的虚函数的做法。
       重载，是指允许存在多个同名函数，而这些函数的参数表不同（或许参数个数不同，或许参数类型不同，或许两者都不同）。封装可以隐藏实现细节，使得代码模块化；继承可以扩展已存在的代码模块（类）；它们的目的都是为了——代码重用。而多态则是为了实现另一个目的——接口重用！多态的作用，就是为了类在继承和派生的时候，保证使用“家谱”中任一类的实例的某一属性时的正确调用。
怎样做到高内聚低耦合
      目的，提高代码的复用性。也就是说，如果不考虑代码的复用性，可以不考虑高内聚，低耦合的说法。
      那么怎样实现高内聚低耦合呢：一，把复杂的系统“化整为零，各个击破”。功能上分解开了，一个模块实现一个独立的功能，自然就不耦合在一起了。这在软件设计上，称之为 单一职责原则SRP(Single Responsibility Principle)。
二，依赖于接口，而不是依赖于类。依赖倒转。原本是高层依赖低层的情况，将底层抽象出接口，通过这个抽象接口操作，反而变成了低层模块要向上依赖这个抽象接口。这就是依赖倒转。
三，模块间尽量做到单向依赖。
设计模式
      帮助我们将应用组织成容易了解，容易维护，具有弹性的架构，建立可维护的OO系统，要诀在于随时想到系统以后可能需要的变化以及应付变化的原则。设计模式多用于复杂系统，方法设计，负责业务逻辑，增加代码可维护性方面。模式是前人智慧的结晶，重用这种智慧是非常有益的。
      通常，实现模式有助于去除重复、简化逻辑、澄清意图、提高灵活性。尽量地学习更多的模式，而不要认为模式太复杂而不使用模式。但是，有些模式确实使代码更复杂。出现这种情况，就应该返回做进一步的重构（发现问题再处理，而不是凭空担心）。
      应用设计模式的最好方式就是：重构为模式（Refactoring to Patterns）。也就是说，不是不加变通地套用模式，而是通过重构渐进地引入设计模式，这样才可能避免过度设计。重构使我们的注意力集中在去除重复、简化代码、澄清意图，从而使我们更明智地使用模式。
      在哪里应用设计模式的一个重要指标就是：看哪里有变化点。设计模式建立在对系统变化点的基础上进行，哪里有变化点，哪里应用设计模式。设计模式应该以演化的方式来获得，系统的变化点往往经过不断演化才能准确定位。应用设计模式的时候，要先找到哪里会发生（需求的）变化，然后在那里寻找合适的模式并运用。在不会发生任何变化的地方，是不需要使用设计模式的。
      设计模式的危险就是：为了使用模式而使用模式，把任何需求都看作模式的拼凑，一开始就使用模式来设计。正如学习武功而痴迷于招式，同样会走火入魔。模式不是目的，目的是更好地设计。只有明智地使用模式，才能为我们带来模式的乐趣。有很多场景，可以用多态完成的，完全没有必要去使用工厂方法模式。而有些场景，使用多态并不能够胜任，必须使用工厂方法模式。
一些导致重构的原因
1、通过显示地指定一个类来创建对象：
            在创建对象时制定类名将使你受特定实现的约束，而不是特定接口的约束。这回使得未来的变化更加复杂。
      应该间接地创建对象。
      设计模式：Abstract Factory，Factory Method，Prototype；
2、对特殊操作的依赖：
            当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。
      为了避免把请求代码写死，可以在编译时刻或运行时刻方便地改变响应请求的方法。
      设计模式：Chain Of Resposibility，Command；
3、对硬件和软件平台的依赖：
            外部的操作系统接口和应用程序接口（API）在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至很难跟上本地平台的更新。
      实际系统时，限制其平台的相关性就很重要。
      设计模式：Abstract Factory，Bridge；
4、对对象表示或实现的依赖：
            知道对象怎样表示、保存、定位或者实现的客户在对象发生变化时可能也需要变化。
      对客户隐藏这些信息能阻止连锁变化。
      设计模式：Abstract Factory，Bridge，Memento，Proxy；
5、算法依赖：
            算法在开发和复用时常常被扩展、优化和替换。依赖于某个特定算法的对象在算法发生变化时不得不变化。
      因此，有可能发生变化的算法应该被孤立起来。
      设计模式：Builder，Iterator，Strategy，Template Method，Visitor；
6、高耦合：
            高耦合的类很难独立地被复用，因为它们是相互依赖的。高耦合产生单块的系统，要改变或删除一个类，必须理解和改变其他许多类。这样的系统是很难理解、维护、移植的米集体。
            低耦合提高一个类被复用的可能，并提高系统的扩展性。设计模式使用抽象耦合和分层技术来提高系统的低耦合性。
      设计模式：Abstract Factory，Command，Facade，Mediator，Observer，Chain Of Responsiblity；
7、通过生成子类来扩充功能：
            通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销（初始化、终止处理等）。定义子类还需要对父类有深入的了解。如，重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，也不得不引入许多新的子类。
            一般的对象组合技术和委托技术，是继承之外，组合对象行为的一种灵活方法。新功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类方式加到应用中。另一方面，过多的使用对象组合会使设计难于理解。许多设计模式的设计中，可以定义一个子类，且将它的实例和已存在的实例进行组合来引入定制的功能。
      设计模式：Bridge，Chain Of Responsiblity，Composite，Decorator，Observer，Strategy；
8、不能方便地对类进行修改：
            有时，不得不改变一个难以修改的类。也许需要源码而又没有，或者可能对类的任何改变会要求修改许多已存在的其他子类。
      设计模式提供这种请况下对类进行修改的方法。
      设计模式：Adapter，Decorator，Visitor。
理解别人设计的意图
      读别人的代码，是个公认的难题，需要花费很多时间。
      顺着别人的思路实现代码，需要花费更多的时间。对于一个程序员来说，可能在听完一个需求的功能后，这个功能的实现思路，就已经出现在脑海中了。但是顺着别人的思路写代码，则麻烦的多。必须要考虑，前面的作者是怎样想的，猜测接下来他会如何进行处理。而且不可避免的一个问题是，对于一块代码很难进行全面的把控。有一个玩笑这样说，在你写代码的那一个月，上帝和你知道你写了什么。一个月之后，只有上帝知道你写了什么。事实上，一个月后，自己稍微浏览一下自己的代码，就会想起当时的思路是什么。
      别人的代码，永远是别人领域。不论是重构，还是二次开发，一定要仔细考虑清楚，讨论明白，才能慎重的动手工作。