设计模式,我一直把设计模式想象成兵法,精妙的兵法可以结构化的、优雅的组织代码。以一种聪明的方式去实现功能,并且具有极强的可维护性。
说设计模式应该先从软件设计的思想说起,比如开闭原则,开:对扩展开放;闭:对修改关闭。这就需要什么呢?把不变的部分抽象出来并进行封装。软件设计还有一个原则叫做面向接口编程。接口是什么,这是我第一个想谈的东西,算是我想到所有东西的起点。接口,用书里的话来说就是一个标准,定义好这个标准之后,类库和客户端程序员就可以按照这个标准来进行开发,而不必关心实现的细节。从另一个角度来说,接口也是一个基类,所有实现此接口的细节实现都可以向上转型为这个基类,并为别人所用。下面开始我的“漫谈”,重口味啊,不喜勿进。
接口---标准也。什么事标准?就拿老丈人定义的标准来说,确切的说,一个适龄待嫁女青年的父亲给自己的女婿定义了一套标准:1、有房。2、有车。3、对自己女儿好。这就是一个接口其实,因为这是一套标准,只有实现了此标准(接口)的人才能成为他的女婿。
public class SonInLaw{
public House getHouse();
public Car getCar();
public void takeCareOfGirl();
}
?这样,女婿就成为了一个接口,但是女婿不可以被实例化,不能说“他是一个女婿”,但是假如“小明”实现了女婿接口,并成为了老头的女婿,小明就可以向上转型为基类“女婿”,老头的女婿指向的就是小明了。这样有什么用呢?老头可以说,我要一个这样这样的女婿,有这这个女婿之后我可以调用女婿的这样这样的方法。
public class FatherInLaw{
public void MarryMyDaughter (SonInLaw sonInLaw){
House house = sonInLaw.getHouse();
Car car = sonInLaw.getCar();
sonInLaw.takeCareOfGirl();
……
}
}
?可以看到FatherInLaw的嫁女儿的方法(marryMyDaughter)里必须要求传入一个女婿(SonInLaw)类,因为嫁女儿必须调用女婿的获得房子,获得小汽车,照顾女孩儿三个方法。这里岳父是不关心女婿其他的,只关心他是实现了那个女婿接口,也就是说可以向上转型为女婿。这也是面向对象设计的一个原则:面向接口编程。那么小明如果实现了接口,怎么去娶老头的女儿呢?
小明类:
public class Xiaoming implements SonInLaw{
private Car car;
public Car getCar(){
return car;
}
private House house;
public House getHouse(){
return house;
}
public void tackCareOfGirl(){
System.out.println("照顾女孩");
}
}
下面是测试类:
?public class TestSon{
public static void main(String[] args){
FatherInLaw fatherInLaw = new FatherInLaw();
fatherInLaw.marryMyDaughter(new Xiaoming());
}
}
?
?小明类就是一个实现了女婿接口的类,换句非程序的话说就是一个达到了老头嫁女儿标准的人。在测试类里,有一个岳父对象被初始化,之后调用此对象的嫁女儿方法,此方法需要传入一个实现了女婿接口的类,我们把小明穿进去,老头就成功的把女儿嫁出去了。
例子就说完整了。里边利用接口,使岳父不必关心女婿的细节实现,只是定义一个接口,实现我的接口就可以了。就是OO中的面向接口编程。并且这个例子里还有一个设计模式---策略模式。
策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化----百度百科。
? ?? ? ? 这里的小明其实就是算法族中的一个,不仅可以有小明,还可以有小刚、小强、小白……只要他们实现了女婿接口,就可以传给岳父的嫁女儿方法。岳父是不关心具体的实现的(他不关心你是小强还是蟑螂),他只关心你是否实现了女婿接口。
? ? ? ? ? ?再回归文章开头说的原则:开闭原则,老头嫁女儿方法是不变的:有房有车疼女儿。女婿是可以变的--小明、小刚和小强,not at all。这里正是抽象并封装了不变的部分:嫁女儿方法。开放了扩展部分---各种女婿。
好了,今天就说道这吧。下次我准备写代理模式和适配器模式。小强们是怎样实现女婿接口的---拼爹,拼爹就是代理啊适配器啊,其实是小强他爹实现了女婿方法,小强不过是一个适配器罢了。哈哈~~
?
?
?