面向对象的经典语录

 

         任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员       ____Martin Flower《重构》

 

 

接口优点：

一个对象仅能通过其接口（功能）才会被其它对象所了解。

Client（客户端程序）不必知道其使用对象的具体所属类。 

松散藕合（loosens   coupling）

提高了（对象）组合的机率，因为被包含对象可以是任何实现了一个指定接口的类。

接口缺点：

设计的复杂性略有增加 

 

接口表示“…像…”（LikeA）的关系，继承表示“…是…”（IsA）的关系，组合表示“…有…”（HasA）的关系。

 

其实有些东西或许并没有你想象的那么复杂,现实生活中接口的例子也很多,例如插座,不管是电视机,还是冰箱,微波炉的插头都是可以插上去的,因为插头的规格是统一的(也就是接口),家电只要遵循插头的规格,就可以接到插座上去

 

只要软件架构师，软件工程师等设计了软件的整个架构和（或）类设计，定义接口之后，扔给下面的人去做具体的实现就可以了...

 

比如一个方法里面有读数据库的需要，传入参数为IDataReader接口，实际调用时，可以传入SqlDataReader对象，也可以传入OracleDataReader对象，数据库由SQLserver变为Oracle，此方法不需要作任何修改

 

 

================================================

 

设计模式是“封装变化”思想的最佳阐释。无论是创建型模式、结构型模式还是行为型模式，归根结底都是寻找软件中可能存在的“变化”，然后利用抽象的方式对这些变化进行封装。

 

 

有些代码不是给客户用的，而是给开发人员用的

 

已有软件模块，特别是最重要的抽象层模块不能再修改，使变化中的软件系统有一定的稳定性和延续性

接口（interface），抽象类的应用对可变性封装：将可变性封装到一个对象里。

不允许更改的是系统的抽象层，而允许更改的是系统的实现层。

 

要依赖于抽象，不要依赖于具体。

抽象不应当依赖于细节；细节应当依赖于抽象；

要针对接口编程，不针对实现编程。

传递参数，或者在组合聚合关系中，尽量引用层次高的类。

 

使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。

过于臃肿的接口是对接口的污染。

每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。

过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。

A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。

 

组合：一荣俱荣，一损俱损，整体和部分的生命周期是一样的(人，肢体)。

聚合：部分可以是整体的一部分，也可以脱离整体而存在。(List，台式机)

 

要尽量使用组合/聚合，尽量不要使用继承。

导致错误的使用继承而不是合成/聚合的一个常见的原因是错误的把"Has-A"当作"Is-A"。

 

一个对象应当对其它对象有尽可能少的了解。不要和陌生人说话

 

好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类是不被继承的。

将尽可能多的共同代码放到抽象类中。

 

 

面向对象的三大特征：

封装：隐藏内部实现

继承：复用现有代码

多态：改写对象行为

 

 

开闭原则（Open-Closed Principle）：一个软件实体应当对扩展开放，对修改关闭

 

对修改关闭：不能对原有代码重新编译

 

 

程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。