任何一个傻瓜都能写出计算机可以理解的程序,只有写出人类容易理解的程序才是优秀的程序员 ____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):一个软件实体应当对扩展开放,对修改关闭
对修改关闭:不能对原有代码重新编译
程序代码更是不能搞重复建设,如果同一个类中有相同的代码块,请把它提炼成类的一个独立方法,如果不同类中具有相同的代码,请把它提炼成一个新类,永远不要重复代码。