设计模式 |
您所在的位置：网站首页 › 案台可以分为哪三大类 › 设计模式 |
|
1. 设计模式三大分类 设计模式分为三种类型，共23类。 （1）创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。 （2）结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。 （3）行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。
2. 六大原则 2.1 单一职责原则 单一职责原则是指，不要让一个类承担过多的职责。避免职责耦合在一起，避免一个职责的变化影响到其他职责。 比如在Activity中存在网络请求的逻辑，导致Activity过于臃肿，导致引起这个Activity变化的原因太多，这样就违反了单一职责原则，不利于后续的版本维护。 最后再来理解一下单一职责的定义——就一个类而言，应该仅有一个引起它变化的原因。
2. 2 开放封闭原则 在开发过程中，需求的变化如果要通过修改原有的代码来完成，那么就很可能将新的错误引入到旧的代码中。因此才有了开放封闭原则。就是说，需求改变时，我们应该尽量通过拓展的方式、即加入新代码来实现变化。 比如我们要实现一个银行业务的逻辑，如下所示： //By SEU_Calvin on 2017/03/27 public class BankProcess { public void Deposite() {//存款 } public void Withdraw(){//取款 } } public class BankStaff { private BankProcess bankpro = new BankProcess(); public void BankHandle(Client client) { switch (client.Type) { case "deposite": // 存款 bankpro.Deposite(); break; case "withdraw": // 取款 bankpro.Withdraw(); break; } } }这样直接调用BankStaff.BankHandle()方法，通过传入的参数完成对应的存取款功能。 但是这时加入了转账业务呢，就需要去修改BankProcess类，这样既违反了单一职责原则，也违反了我们的开放封闭原则，因为BankProcess职责不单一，且新需求需要修改已有的代码。因此可以使用的接口的方式进行优化： //By SEU_Calvin on 2017/03/27 public interface IBankProcess { void Process(); } public class DeposiProcess implements IBankProcess { public void Process(){ // 办理存款业务 } } public class WithDrawProcess implements IBankProcess{ public void Process(){ // 办理取款业务 } } public class TransferProcess implements IBankProcess{ public void Process(){ //办理转账业务 } } public class BankStaff { private IBankProcess bankpro = null; public void BankHandle(Client client) { switch (client.Type) { case "Deposite": // 存款 bankpro = new DeposiProcess(); break; case "WithDraw": // 取款 bankpro = new WithDrawProcess(); break; case "Transfer": // 转账 bankpro = new TransferProcess(); break; } bankpro.Process(); } }这样如果我们再添加功能，你会发现我们不需要修改原有的类，只需要添加一个功能类的子类即可。 最后再来理解一下开放封闭的定义——软件中的对象（类、模块、函数等）应该对于拓展是开放的，而对于修改是封闭的。 2.3 里氏替换原则 里氏代换原则告诉我们，只要父类出现的地方，子类就可以出现，替换为子类后不会产生任何错误和异常，当然反过来未必适应。 我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，在运行时再确定其子类类型，用子类实例来替换父类实例。如2的例子中对bankpro的实例化。就可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。因此说，里氏替换原则是开闭原则的具体实现手段之一。 最后再来理解一下里氏替换原则的定义——所有引用基类（父类）的地方必须能透明地使用其子类的对象。
2.4 依赖倒置原则 依赖倒置原则在Java中是指接口或抽象类不依赖于实现类，而实现类依赖接口或抽象类。 就是说如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。依赖倒置就是为了解决耦合。让程序依赖于抽象。 举个简单的例子： //By SEU_Calvin on 2017/03/27 public class Fute { public void run() { System.out.println("福特汽车启动"); } public void stop() { System.out.println("福特汽车停止"); } } public class Bentian { public void run() { System.out.println("本田汽车启动"); } public void stop() { System.out.println("本田汽车停止"); } } public class AtuoRunSystem { private String mType; private Bentian bentian = new Bentian(); private Fute fute = new Fute(); public AtuoRunSystem(String type) { mType = type; } public void AutoRun() { if ("bentian".equals(mType)) { bentian.run(); } else { fute.run(); } } public void AutoStop() { if ("bentian".equals(mType)) { bentian.stop(); } else { fute.stop(); } } }代码很简单，但是缺点也很明显，扩展性特别差，现在只有两种车，if-else语句还算简单，假设以后有100种车… //By SEU_Calvin on 2017/03/27 public interface Icar { void run(); void stop(); } public class Fute implements Icar { public void run() { System.out.println("福特汽车启动"); } public void stop() { System.out.println("福特汽车停止"); } } public class Bentian implements Icar { @Override public void run() { System.out.println("本田汽车启动"); } @Override public void stop() { System.out.println("本田汽车停止"); } } public class AtuoRunSystem { private Icar icar; public AtuoRunSystem(Icar icar) { this.icar = icar; } public void autoRun() { icar.run(); } public void autoStop() { icar.stop(); } }经过改造，再加入新车我们也不怕了。这种设计也充分说明了，类与类不应该直接依赖细节，因为这样会导致耦合，限制了可扩展性，而是让类与类直接依赖抽象。
2.5 迪米特原则 也称为最少知识原则，是指一个对象应该对其他对象有最少的了解。 通俗的讲，一个类对自己需要耦合的类应该知道的最少，你内部多么复杂和我没关系，我只对你提供的public方法感兴趣。这样的话，如果一个系统符合迪米特法则，那么当其中某一个类发生修改时，就会尽量少地影响其他模块，降低系统的耦合度，使类与类之间保持松散的耦合关系。 下面是老师让班长清点班级人数的例子： //By SEU_Calvin on 2017/03/27 public class Teacher { public void commond(Monitor monitor) { List lists = new ArrayList(); // 初始化同学 for (int i = 0; i < 20; i++) { lists.add(new Student()); } // 告诉班长清点人数 monitor.count(lists); } } public class Monitor { // 有清查女生的工作 public void count(List lists) { System.out.println(lists.size()); } } //调用时 Teacher teacher= new Teacher(); teacher.commond(new Monitor());我们看到Teacher类不仅与Monitor类产生了关系，还和Student类产生了关系。产生了不必要的耦合。这样Student类的变化不仅影响Monitor类，还会影响到Teacher类。程序优化修改后如下，调用方法不变： //By SEU_Calvin on 2017/03/27 public class Teacher { public void commond(Monitor monitor) { monitor.count(); } } public class Monitor { public void count() { List lists = new ArrayList(); for (int i = 0; i < 20; i++) { lists.add(new Student()); } System.out.println(lists.size()); } } //调用时 Teacher teacher= new Teacher(); teacher.commond(new Monitor());2.6 接口隔离原则 接口隔离原则的含义是：建立单一接口而不是建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。 比如说，定义了一个接口MyInterface。 public interface MyInterface{ public void method1(); public void method2(); public void method3(); }但是实现类A只想实现接口中的method1方法，而实现类B只想实现接口中的method2、method3方法。 此时只写一个接口让A、B都去实现该接口的话，会导致AB中会实现不需要的方法，这样设计接口会导致接口比较臃肿，因此我们应该要把这个接口拆分开来写。 很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。单一职责原则注重的是职责，针对的是程序中的实现和细节；而接口隔离原则注重的是对接口依赖的隔离，主要针对抽象。 最后理解一下接口隔离原则的定义：类间的依赖应该建立在最小的接口上。 |
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |