之前无论是作为开发还是测试,习惯性的觉得,别人提供了什么功能,就用什么样的功能,这样做天经地义。然而,在自己的架构设计过程中,如果有了这样额思维,很容易让自己的程序设计陷入困境。
打个装修的比喻,我们一定是有设计师设计相关方案(具体的风格),然后分解成对应的家具,然后再购买材料,打造对应的家具。如果我们将这一过程倒过来,先有什么材料,然后看这些材料能打造出什么家具,再把家具组合起来,那么最后的装修效果一定会非常差。
图1 正确的设计方式
图2 自底向上的设计结果,一定是最后的整合有问题
所以优秀的设计一定是从整体到局部设计出来的。从局部构造整体,不可能得到优秀的设计。
了解清楚某个功能模块(或者整个功能)具体要干什么事情,我们才能够知道具体要如何做设计。而不是找一个设计方案,能够实现主要功能就行了,其他功能再次基础上修修补补。
再举一个简单的例子:比如说我们要喝水(表面功能/基础目标),那么我们就需要找相关盛水的容器(设计实现)。我们找到了以下容器(可能的实现方案):
图三 各种盛水容器的实现
三种容器都能喝水,但具体要使用哪个呢?如果随便选一个酒杯,但具体实现(或者未来可能的功能)要求能够带到户外去,总不能给酒杯再加个盖子吧;同理,如果我们要品酒,却选了个保温杯的实现,到时候直接设计推倒重来了。所以,要有合适的设计,一定要对产品本身的需求(以及未来可能的需求)做详细的分析和了解,然后确定设计方案。
在学习“面向对象”的语言时,我们首先被教会“封装、继承、多态”。从此,感觉有点关系的都要进行继承,觉得这样能节省好多代码。然后我们的代码中便出现了继承的乱用
正常情况下,这样做没有问题,但问题的起源在于,我们的需求是不断的修改和添加的,如果使用了继承,在超类中的方法改动,会影响到子类,并可能引起引起子类之间出现冗余代码。
举个汽车的例子吧,一辆汽车开行(drive)是一样的,但车标(logo)是不一样的,所以用继承
public abstract class Car { /**
* 驾驶汽车
*/
public void drive(){
System.out.print("drive");
} /**
* 每辆车的车标是不一样的,所以抽象
*/
public abstract void logo() ;
}
class BMW extends Car{
@Override
public void logo() {
System.out.print("宝马");
}
}
class Benz extends Car{
@Override
public void logo() {
System.out.print("奔驰");
}
}
class Tesla extends Car{
@Override
public void logo() {
System.out.print("特斯拉");
}
}
一切看起来解决的很完美。突然加了一个需求,要求有个充电(change)需求,这时候,只有特斯拉(tesla)才有充电方法。但如果使用继承,在父类添加change方法的同时,就需要在BMW和Benz实现无用的change方法,对于子类的影响非常大。但如果使用组合,使用ChangeBehavior,问题就得到了有效解决,
public interface ChargeBehavior {
void charge() ;
}
public abstract class Car {
protected ChargeBehavior chargeBehavior ; /**
* 驾驶汽车
*/
public void drive(){
System.out.print("drive");
} /**
* 每辆车的车标是不一样的,所以抽象
*/
public abstract void logo() ; /**
* 充电
*/
public void change(){ /**
* 不用关心具体充电方式,委托ChargeBehavior子类实现
*/
if (chargeBehavior!=null) {
chargeBehavior.charge();
}
}
}
class Benz extends Car{
@Override
public void logo() {
System.out.print("奔驰");
}
}
class BMW extends Car{
@Override
public void logo() {
System.out.print("宝马");
}
}
class Tesla extends Car{
@Override
public void logo() {
System.out.print("特斯拉");
} public Tesla() { super();
chargeBehavior = new TeslaChargeBehavior() ;
}
}
class TeslaChargeBehavior implements ChargeBehavior{
@Override
public void charge() {
System.out.print("charge");
}
}
通过将充电的行为委托给changeBehavior接口,子类如果不需要的话,就可以做到无感知接入。
这样的代码有三个优势
1、代码不需要子类中重复实现 2、子类不想要的东西,可以无感知实现 3、子类运行的行为,可以委托给behavior实现,子类本省本身无需任何改动
在刚刚接触面向对象的时候,封装,对我们来说就是类,实例化后就是对象。最基本功能是对于数据进行隐藏,对于行为进行开放(如JavaBean)。慢慢用多了以后渐渐发现,其实我们可以封装跟多东西,比如某些实现的细节(私有方法方法),实例化规则(构造器)等。
1,对于变化本身进行封装
由于我们的代码是分层和分模块的,但我们的需求又是经常要变化的,我们希望修改新功能,对于除了模块本身外,调用方是无感知的。所以,我们的类(或者说是模块吧)变封装了变化本身。对于调用方来说,只需要知道不会变的功能名(方法名)就够了,而不需要了解可能变化的内容。
图四 变化本身进行封装
2,从共性和可变性到抽象类
在一类实现中,我们其实可以分析发现,代码的实现上是有一些共性的,比如说处理的流程(如何调用一些方法的顺序),也有一些完全一致的操作(比如上文提到的car都可以drive,实现一致的方法)。但也有一些可变性:如必须存在(共性),但实现不一致的操作(如上文car里面的logo方法,必须有,但不一致)。这时候,我们就可以对这些实现进行一些简单的抽象,成为抽象类。抽象类就是将共性变为以实现的方法,而将可变性变为抽象方法,让子类予以实现。
图五,共性和抽象类
代码看多了,写多了,便会发现,看起来舒服的代码,在可维护性,可读性,可扩展性上相对来说都比较高。代码界也有“颜值即战斗力”这一说法,颇有一番玄学的味道。但分析具体的原因,其实可以发现,优秀的编码设计,在其抽象,封装,都有其合理之处,其整体的架构设计上,亦有其独到之处。