wordpress是单线程,百度关键词优化的方法,wordpress建站事项,企业策划书范文案例转#xff1a;http://www.ibm.com/developerworks/cn/java/j-lo-beyondpattern/刘 旭进, 软件开发工程师, IBM 中国软件开发中心简介#xff1a; 可复用面向对象软件的基础 -- 设计模式#xff0c;以其可复用的设计初衷、精巧的逻辑思维被广大面向对象程序设计所追捧。但不少…转http://www.ibm.com/developerworks/cn/java/j-lo-beyondpattern/ 刘 旭进, 软件开发工程师, IBM 中国软件开发中心 简介 可复用面向对象软件的基础 -- 设计模式以其可复用的设计初衷、精巧的逻辑思维被广大面向对象程序设计所追捧。但不少程序设计者却经常将思考的问题转换为遇到了什么场景就要用什么模式。这种八股文式的思维在某种程度上严重影响了程序设计的艺术性并固化了程序设计者的思想违背了设计模式的初衷。在本文中作者总结了设计模式背后的核心思想并提出了几个关键的设计原则例如面向接口、封装变化、依赖倒置原则、只和朋友交谈等。程序设计者只需在程序设计时遵循这些原则便会发现原来已经在使用某些设计模式了。 引题 GOF 的设计模式推出以后受到程序员的热烈追捧很多程序员不亦乐乎的埋头苦读甚至背诵其 23 个设计模式并以熟悉设计模式而自豪。然而在实际的程序设计中很多程序员并未能把设计模式应用到自己的场景中。原因有很多设计模式太多以至于常常被混淆设计模式应用场景太局限或者程序员自己意识不到应用的场景。综合各种原因根本原因只有一个程序员并不能透彻理解熟练应用设计模式的核心思想。笔者认为设计模式并不是条条框框设计模式也不是简单的 23 种。设计模式体现的一种思想是尽可能的复用而实现可复用的手段无外乎笔者总结的几个设计原则而已。 彻底的忘掉 GOF 的设计模式吧程序设计应该是一门艺术而不是备受束缚的那些模式。 回页首 原则一封装变化 该原则的核心思想是在程序设计中找出应用中可能需要变化之处把它们独立出来以便以后可以轻易的改动或者扩充而不影响不需要变化的部分。事实上如果您回过头去重新阅读设计模式的书籍您会发现封装变化几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让系统中的某部分改变不会影响其它部分。 我们举一个简单的例子我们建立一个 Car 的基类有两个继承类 Benz 和 BMW, 具体参见下图 1 图 1. Car 的第一个实现 相信大部分人都会这么设计但是这个设计有什么问题呢我们看待问题需要以发展的眼光假如科技发展了所有的 Car 都可以飞了怎么办有人说很简单给 Car 加一个 protected 的 fly() 方法这样 Benz 和 BMW 就都可以飞了继承真伟大好那么如果我需要建立另外一个 Car 的子类玩具车Toycar, 我们知道玩具车可以 run, 但不能 fly 的。怎么办还是好办我们可以重载玩具车的 fly 方法让他们什么都不干。那好又一个子类来了模型车ModelCar。模型车不能 run不能 fly好办继续重载他们的这些方法。见下图 2 图 2. Car 的第二个实现 如果我们有更多的 Car 的子类呢有没有觉得有点繁琐是的我们需要重载太多的方法了。 继承并不能帮我们解决问题 可不可以使用接口我们可以把 fly 从超类中取出来分别作为接口Flyable这样一来只有 Benz 和 BMW 才实现 Flyable 接口ToyCar 和 modelCar 并不实现该接口。Run 也作类似处理。见下图 3 图 3. Car 的第三个实现 大家可以看到这其实是一个很笨的办法除去 description() 方法我们使用继承需要重载 3 个方法可是我们使用接口实现则需要额外定义两个接口类和个方法。接口方法里面并不能有实现代码而 ToyCar 的 fly 行为和 Benz 的飞行行为也可能不尽相同那么这就意味着我们需要实现越来越多的 fly() 方法。 接口也不行 怎么办想一想我们的前面提到的设计原则把变化的和不变化的分离开来以便我们以后可以轻易的改动和扩充而不影响其它不需要变化的部分。我们变化的部分是什么是否可以飞行是否可以 run以何种方式飞行何种方式 run BenzBMW 和 ToyCar 的飞行行为和 run 行为各不相同。我们可以把这些不同的 fly 和 run 抽象出来。见如下图 4 图 4. Car 的第四个实现 看到这也许您应该大概明白接下来应该怎么办了。是的很简单我们可以给 Car 类加入飞行行为和 run 行为的实例变量。而在初始化 Car 的子类时传入的具体行为进行初始化这样每个子类就自然拥有了相应的行为。 代码参见如下 清单 1. Car 的实现类
public abstract class Car
{ protected RunBehavior runBehavior; protected FlyBehaviro flyBehavior; public abstract description (); protected performFly() { flyBehavior.fly(); } protected performRun() { runBehavior.run(); }
} public class Benz extends Car
{ public String description() { System.out.println(“I am Benz!”); } public Benz() { this.runBehavior new HighSpeedRunBehavior(); this.flyBehavior new HighFlyingBehavior(); }
}上述代码中我们实现了 Benz如果我们要实现 ToyCar一个不能飞但可以跑。尝试一下看看多简单。 清单 . ToyCar 的实现类
public class ToyCar extends Car
{ public String description() { System.out.println(“I am Toy car!”); } public Benz() { this.runBehavior new LowSpeedRunBehavior(); this.flyBehavior new NoFlyingBehavior(); }
}总结 策略模式定义 定义了算法族并分别封装起来让他们之间可以相互替换此模式让算法的变化独立于使用算法的客户。 回过头来看看我们前面所作的工作第一个我要告诉您的是恭喜您学会了策略模式上面我们的设计的核心实现就是使用了策略模式。继承和接口不能解决一切问题尽量的利用组合将为您的设计带来低耦合。尽可能的针对接口或者抽象类而不是实现去编程试想如果我们定义的 Car 类组合具体的行为类也就是实现那么它就被绑死了我们不可能以后再改变它的行为。但这样我们可以在运行时动态的改变 Car 子类的具体行为。这也是我们成功的关键。最重要的把变化的和不变化的分离出来封装变化的部分以应对随时改变。 回页首 原则二只和朋友交谈 继续我们的话题假设我们有一家汽车公司可以生产 Benz、BMW、ToyCar 和 ModelCar姑且这么认为吧虽然这不太符合常理那么该如何设计我们的实现呢很简单参见下面代码 清单 3. CarCompany 类
public class CarCompany
{public CarCompany () { } public Car produce(String type) { Car car null; if(“Benz”.equals(type)) { car new Benz(); } else if(“BMW”.equals(type)) { car new BMW(); } else if(“ToyCar”.equals(type)) { car new ToyCar(); } else if(“ModelCar”.equals(type)) { car new ModelCar(); } else { } car.assembly(); // 组装car.sprayPainting(); // 喷漆car.proof(); // 校对return car; }
} 老问题上面的代码有问题么但从业务逻辑上讲当然没问题。可是还是要用变化的眼光看问题上面的代码维护起来成本很高。上面的代码要求我们无论是 Benz、BMW、ToyCar 还是 ModelCar 都不能在将来发生变化。否则我们这段代码就有维护的成本和风险。 有没有更有效的办法想想我们第一个设计原则把变化的部分提出去变化的部分是什么显然生成 car 的那一段。我们把它提出去参见下面代码 清单 4. CarFactory 和 CarCompany 另一种实现
public class CarFactory
{ public CarFactory () { } public Car createCar(String type) { Car car null; if(“Benz”.equals(type)) { car new Benz(); } else if(“BMW”.equals(type)) { car new BMW(); } else if(“ToyCar”.equals(type)) { car new ToyCar(); } else if(“ModelCar”.equals(type)) { car new ModelCar(); } else { } return car; }
} public class CarCompany
{ CarFactory carFactory; public CarCompany (CarFactory carFactory) { this.carFactory carFactory; } public Car produce(String type) { Car car null; Car carFactory.createCar(type); car.assembly(); // 组装car.sprayPainting(); // 喷漆car.proof(); // 校对return car; }
}很显然我们的 CarCompany 现在只依赖 CarFactory 一个类了。有人说这么做有什么用我们只不过把问题转移到另外一个对象 CarFactory 了问题依然存在。但是别忘了我们的 CarCompany 可能不止一个 produce() 方法。它可能还有 sale(), repair() 方法。这样我们相当于是把几个问题缩小为一个问题了。 总结 这个例子虽然很简单但是却告诉我们一条最重要的设计原则一个类应该尽可能少的与其它类产生联系尽可能的保持类之间的耦合度保持类的最少知识量。恭喜您您学会了简单工厂模式。外观模式也是对本原则的典型应用。具体请参见设计模式相关书籍。 回页首 原则三依赖倒置原则DIP 在您的设计里面一定要减少对具体类的依赖尽量依赖抽象不要依赖具体类。这就是依赖倒置原则。 听起来有点像面向接口不针对实现编程。的确很类似但是这里强调的是抽象。具体说来就是不要让高层组件依赖低层组件而且不管高层低层组件都应该依赖抽象。高层组件最多是依赖低层组件的抽象。低层的抽象和实现也只依赖于高层的抽象。 所谓高层组件是由其它低层组件定义其行为的类。高层组件是包含重要的业务模型和策略选择低层模块则是不同业务和策略实现。 也许您不是很理解这段话的含义。不要紧继续我们上面的例子。假设随着汽车公司规模越来越大业务规模拓展到了亚洲和欧洲。我们希望可以针对亚洲人和欧洲人生产出不同的同一品牌的的汽车。比如同一品牌 BMW 亚洲是左驾驶座当然除了一些特殊地区欧洲是右驾驶座。看看下面的实现。 清单 5. DependencyCarCompany 实现
public class DependencyCarCompany
{ public CarCompany () { } public Car produce(String style, String type) { Car car null; if(“Asia”.equals(style)) { if(“Benz”.equals(type)) { car new AsiaBenz(); } else if(“BMW”.equals(type)) { car new AsiaBMW(); } else if(“ToyCar”.equals(type)) { car new AsiaToyCar(); } else if(“ModelCar”.equals(type)) { car new AsiaModelCar(); } else { } } else if(“Europe”.equals(style)) { if(“Benz”.equals(type)) { car new EuropeBenz(); } else if(“BMW”.equals(type)) { car new EuropeBMW(); } else if(“ToyCar”.equals(type)) { car new EuropeToyCar(); } else if(“ModelCar”.equals(type)) { car new EuropeModelCar(); } else { } car.assembly(); // 组装car.sprayPainting(); // 喷漆car.proof(); // 校对return car; } }
}够简单吧总结它们对象之间依赖的情况如图 5 所示 图 5. CarCompany 的第一个实现 我们发现 CarComany 依赖的具体类有 8 个如果任何一个类发生改变CarCompany 都需要改变。这至少不符合我们的原则二只和朋友交谈。应用我原则一把变化的部分提出来。我们可以定义两个 CarCompany 的子类AsiaCarCompany 和 EuropeCarCompany 用来生产不同样式的同一品牌的汽车。在这两个子类里面需要做的就是生成不同品牌和样式的汽车然后再调用超类的三个方法。这样的话我们可以把生成汽车的方法提出来。 清单 6. CarCompany 另一种实现
public abstract class CarCompany
{ public Car produce(String type) { Car car createCar(type); car.assembly(); // 组装car.sprayPainting(); // 喷漆car.proof(); // 校对return car; } protected abstract Car createCar(String type);
} public class AsiaCarCompany
{ protected Car createCar(Sting type) { Car car null; if(“Benz”.equals(type)) { car new AsiaBenz(); } else if(“BMW”.equals(type)) { car new AsiaBMW(); } else if(“ToyCar”.equals(type)) { car new AsiaToyCar(); } else if(“ModelCar”.equals(type)) { car new AsiaModelCar(); } else { } return car; }
} public class EuropeCarCompany
{ protected Car createCar(Sting type) { Car car null; if(“Benz”.equals(type)) { car new EuropeBenz(); } else if(“BMW”.equals(type)) { car new EuropeBMW(); } else if(“ToyCar”.equals(type)) { car new EuropeToyCar(); } else if(“ModelCar”.equals(type)) { car new EuropeModelCar(); } else { } return car; }
}DependencyCarCompany 的问题在于它依赖于每一个具体的 Car 类型。然而在应用第二种方法后CarCompany 现在只依赖 Car 类型的抽象不再依赖具体类型而是把这些依赖转移到子类中。我们可以画一个对象依赖图 6 图 6. CarCompany 的第二个实现 从这个图中我们可以看出 我们的高层组件也就是 CarCompany 已经由原来的 8 个低层对象依赖变化为只依赖一个低层对象的抽象 Car。这就是依赖抽象。对比上面两个图您会发现以前所绘制的依赖是自上而下而现在则是倒置过来。高层和低层组件都依赖于抽象的 Car。这就是依赖的倒置。总结 工厂方法模式定义 定义一个创建对象的接口但由子类决定要实例化哪个类。工厂方法让类的实例化推迟到的子类。 恭喜您您学会了工厂方法模式。上面的例子实际上是工厂方法的一个典型应用。一些辅助原则可以帮助您更好的运用 DIP 任何变量都不应该持有一个指向具体类的引用。任何类都不应该从具体类派生而是派生一个抽象类。任何方法都不应该覆盖它的任何基类中已经实现了的方法。 回页首 原则四类应该对扩展开放对修改关闭 继续刚才的例子随着汽车公司业务越来越大为了满足不同客户的不同需求对于任一品牌的汽车我们将有不同型号的配置。我们的配置包括气囊Balloon、天窗SkyLight以及自动加热座椅HeatedSeats等。每款汽车的价格为汽车自身价值加上配件的价格。设计如下图 7 图 7. 第一个实现 Oh, My God! 这是什么类爆炸好可怕的一件事。可以想象出来这样的设计将来的维护成本又多高。假如我想增加新的配件怎么办假如我想增加新的品牌又怎么办 其实我们可以用实例变量和继承来重构上面的设计。见下图 8 图 8. 第二个实现 我们在超类 Car 里面 cost() 方法计算各种配件的价格然后在子类里面覆盖 cost() 方法但是会调用超类 cost 方法得到配件价格和然后再加上子类汽车的基本价格。 清单 7. Car 的另一种实现
public abstract class Car
{protected Balloon balloon;protected SkyLight skyLight;protected HeatedSeat heatedSeat;protected int cost(){int res 0;if(hasBalloon){res 25000;}if(hasSkyLight){res 20000;}if(hasHeatedSeat){res 10000;}}void setBalloon(Balloon balloon);boolean hasBalloon();….….
}public Benz extends Car
{public Benz(Balloon blloon){this.setBalloon(balloon);}public int cost(){int res 1000000;res super.cost();}
}怎么样看起来好像天衣无缝的解决了我们的问题。然而有下面几个问题需要考虑 如果配件的价格发生改变怎么办如果出现新的配件怎么办如果某些配件在某种品牌汽车上不能应用怎么办比如您在玩具车上装 ABS自动刹车系统显然是没有意义的。如果我想给我的车安装 4 个气囊而不是一个两个怎么办为什么看起来完美的设计会有这么多解决不了的问题 因为它违背我们的设计原则类应该对扩展开放对修改关闭。我们的目标是允许类容易扩展。在不修改现有代码的基础上就可以搭配新的行为。这样设计才可以接受新的功能来应对改变的需求。 该原则最典型的应用就是装饰模式。让我们以装饰模式的思想重构我们上面的实现。 首先用户需要一辆汽车。那我们就构造一辆裸车并计算价格。用户希望是 BMW, 那我们就把它封装为 BMW并计算价格。用户希望带有气囊那我们就给我们的 BMW 装饰上气囊并加上气囊的价格 25000。用户希望有天窗那我们就给我们的 BMW 装饰上天窗并加上气囊的价格 20000。用户希望有加热椅那我们就给我们的 BMW 装饰上加热椅并加上的价格 10000。用户希望带有双重气囊那我们就给我们的 BMW 再装饰上气囊并加上气囊的价格 25000。见图 9 图 9. 装饰过程 参见我们的实现代码。 清单 8. Car 的另一种实现
public abstract class Car
{ protected abstract int cost();
} public class Benz extends Car
{ public int cost() { return 100000; } } public abstract class CarDecorator extends Car
{ protected abstract int cost();
} public class Balloon extends CarDecorator
{ public Car car; public Balloon(Car car) { this.car car; } public int cost() { return car.cost() 25000; }
} public class SkyLight extends CarDecorator
{ public Car car; public SkyLight (Car car) { this.car car; } public int cost() { return car.cost() 20000; }
} public class HeatedSeat extends CarDecorator
{ public Car car; public HeatedSeat (Car car) { this.car car; } public int cost() { return car.cost(0 10000; }
}下面看看我们的测试类。 清单 9. Car 装饰者的测试类
public class CarWithDecorator {public static void mian(String[] args){Car car new BMW();car new Balloon(car);car new SkyLight(car);car new HeatedSeat(car);car new Balloon(car);System.out.println(car.cost());}...}怎么样回过头想一想我们前面提出的那四个问题是用这种设计方式是不是可以很好地解决呢 总结 恭喜您您学会了装饰模式。现实世界中装饰模式也即我们面向扩展开放面向修改关闭的应用很多。最常见的就是 Java I/O。见下图 10 图 10. Java I/O 应用开放封闭原则有时候会带来小类过多的情况这是这个原则所带来的潜在问题。所以在实际应用中也要注意设计上的考虑。而不要一味的遵循。 回页首 结篇 设计原则不是统一的不同人对有不同的设计原则有不同的见解设计原则也不限于上面所陈述的几点。然后设计原则大的方向是统一的那就是让代码尽可能的应对变化尽可能的可复用。设计模式不是万能的没有设计模式也不是不能的。然而在程序设计过程中遵循一些最基本的设计原则则是一个优秀的程序员所必需的良好的设计原则的应用可以让您设计的程序从容应对可能的改变可以让您的代码变得优雅而富有艺术性。 参考资料 学习 参考 设计模式概述了解设计模式基本内容。 查看教程“Java 设计模式 101”了解设计模式基本词汇以及简单使用设计模式。 查看教程“Java 设计模式 201超越四人组”了解设计模式深层次的应用。 查看系列文章“从 Java 类库看设计模式”了解 JDK 在设计模式中的应用。 技术书店浏览关于这些和其他技术主题的图书。developerWorks Java 技术专区数百篇关于 Java 编程各个方面的文章。讨论 加入 My developerWorks 中文社区。关于作者 刘旭进IBM 中国开发中心软件工程师对开源软件、REST、Web Service、Open Search 有浓厚兴趣和深入研究。目前在 Lotus Connections Fils Team 从事 REST Service 开发相关的工作。 转载于:https://www.cnblogs.com/persist/p/3181240.html
