1.抽象类仅提供一个类型的部分实现。抽象类可以有实例变量,以及一个或多个构造方法。抽象类可以同时具有抽象方法和具体方法。一个抽象类不会有实例,这些构造方法不能被客户端调用来创建实例。一个抽象类的构造方法可以被其子类调用,从而使一个抽象类的所有子类都可以有一些共有的实现,而不同的子类可以在此基础上有其自己的实现。
抽象类和子类的这种关系实际上是模版方法模式的应用。
2.应当优先使用Java接口声明一个超类型。
3.一个新的抽象类,一定是用来继承的;具体类不是用来继承的。只要有可能,不要从具体类继承。
4.在一个以继承关系形成的等级结构中,树叶节点均应当是具体类,而树枝节点均应当是抽象类(或Java接口),这样的设计是所有的Java设计师都应当努力做到的。
5.在一个从抽象类到多个具体类的继承关系中,共同的代码应当尽量移动到抽象类里。把重复的代码从子类里面移动到超类里面,可以提高代码的复用率。
6.与代码的移动方向相反的是,数据的移动方向是从抽象类到具体类。一个对象的数据不论是否使用都会占用资源,因此数据应当尽量放到具体的类或者等级结构的低端。
7.应当针对抽象类编程,不要针对具体子类编程。
8.只要可能,尽量使用合成,而不要使用继承来达到复用的目的。
9.只要当以下Coad条件全部被满足时,才应当使用继承关系:
① 子类是超类的一个特殊种类,而不是超类的一个角色,也就是要区分Has-A 与 Is-A 两种关系的不同。Has-A 关系应当使用聚合关系描述,而只有Is-A 关系才符合继承关系。
② 永远不会出现需要将子类换成另一个类的子类的情况。如果设计师不是很肯定一个类会不会在将来变成另一个类的子类的话,就不应当将这个类设计成当前这个超类的子类。
③ 子类具有扩展超类的责任,而不是具有置换掉或注销掉超类的责任。如果子类需要大量地置换掉超类的行为,那么这个子类不应当成为这个超类的子类。
④ 只有在分类学角度上有意义时,才可以使用继承,不要从工具类继承。
Coad条件比里氏代换原则更加通俗易懂,但是不如里氏代换原则严格。
10.如果子类需要置换掉太多的超类的行为,那么一定是因为子类的行为与超类有太大的区别。这个时候,很有可能子类并不能取代超类出现在任何需要超类的地方,也就是说它们不满足里氏代换原则。
11.机会没有例外,从工具类型继承是错误的。
抽象类
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
- 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...