设计模式-常见设计原则篇
常见设计原则篇
都是为了高内聚低耦合原则。编程时基本都要遵守
单一职责原则
分类原则:一种人只干一种事。
人可以干的事情有很多:敲代码、唱歌、跳舞、打篮球…以人设置成一个类,里面的方法就太多太杂了。所以可以有多个类:程序员(敲代码)、音乐人(唱歌)、爱豆(跳舞)、NBA球员(打篮球)。这样类就具体化了,可以干的事情也就具体了,一旦需要用哪个方法就知道从哪个类里调用了。
开闭原则
开:提供方提供 抽象类/接口/方法 等,实现类可以决定行为。闭:调用方调用时,尽量不需要修改代码。
定义:一个软件实体,比如类、模块和函数应该对扩展开放,对修改关闭。其中,对扩展开放是针对提供方来说的,对修改关闭是针对调用方来说的。
里氏替换原则
对子类的特别定义:父类方法非抽象方法,子类不可以重载(覆盖)。但如果父类有抽象方法则子类必须实现父类的抽象方法,子类也可以编写自己的方法
里氏替换原则(Liskov Substitution Principle)是对子类型的特别定义。所有引用基类的地方必须能透明地使用其子类的对象。
白话:子类可以扩展父类的功能,但不能改变父类原有的功能。有以下四原则:(重点在一二)
子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
子类可以增加自己特有的方法。
当子类的方法重载父类的方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松。
当子类的方法实现父类的方法时(重写/重载或实现抽象方法),方法的后置条件(即方法的输出/返回值)要比父类更严格或与父类一样。
依赖倒转原则
定义:高层模块不应依赖于底层模块,它们都应该依赖抽象。抽象不应依赖于细节,细节应该依赖于抽象。
传统:没有接口而是类与类之间的对象创建。一旦需求变化,类就需要重写,这样其他类也需要修改
// 抽象层
interface DataStorage {void save(String data);
}// 高层模块
class Application {private DataStorage storage;Application(DataStorage storage) {this.storage = storage; // 依赖注入}void processData(String data) {storage.save(data);}
}// 低层模块(具体实现)
class DatabaseStorage implements DataStorage {public void save(String data) {System.out.println("Saving to database: " + data);}
}
接口隔离原则
对接口进行细分,避免接口中定义的方法,在实现类中用不上。
举例:定义一个接口,有方法:设备芯片、设备名称、设备内存。这样的接口只有电脑、手机等实现类才可以实现,而对于风扇、台灯等普通设备实现类而言确只有设备名称才是有效的方法。于是就需要把接口进行细化成两个接口。
interface SmartDevice { //智能设备才有getCpu和getMemoryString getCpu();String getType();String getMemory();
}interface NormalDevice { //普通设备只有getTypeString getType();
}//电脑就是一种电子设备,那么我们就继承此接口
class Computer implements SmartDevice {@Overridepublic String getCpu() {return "i9-12900K";}@Overridepublic String getType() {return "电脑";}@Overridepublic String getMemory() {return "32G DDR5";}
}//电风扇也算是一种电子设备
class Fan implements NormalDevice {@Overridepublic String getType() {return "风扇";}
}
合成复用原则
优先使用对象组合,而不是通过继承来达到复用的目的。
合成复用原则(Composite Reuse Principle)的核心就是委派。
情况:如果A类里写了想要的方法,为了不在B类不重复编写代码,可以在B类中设置一个方法:将A类的对象作为参数并在设置的方法里通过对象获取到A类中想要的方法。
class A {public void connectDatabase(){System.out.println("我是连接数据库操作!");}
}class B {A a;public B(A a){ //在构造时就指定好this.a = a;}public void test(){System.out.println("我是B的方法,我也需要连接数据库!");a.connectDatabase(); //也是通过对象A去执行}
}
迪米特法则
每一个软件单位对其他单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。
迪米特法则(Law of Demeter)又称最少知识原则,是对程序内部数据交互的限制。
简单来说就是,一个类/模块对其他的类/模块有越少的交互越好。当一个类发生改动,那么,与其相关的类(比如用到此类啥方法的类)需要尽可能少的受影响(比如修改了方法名、字段名等,可能其他用到这些方法或是字段的类也需要跟着修改)这样我们在维护项目的时候会更加轻松一些。
白话:在设计方法参数的时候,保证不多给方法多余的参数。例如:方法只需要一个用户的ip地址就可以执行,方法参数就不要写成需要输入用户对象,然后在方法里面通过对象再去调用其ip出来;而是在调用方法前就把用户对象的ip取出来,然后作为参数来调用方法。
举例:
正面教材
public class Main {public static void main(String[] args) throws IOException {Socket socket = new Socket("localhost", 8080);Test test = new Test();test.test(socket.getLocalAddress().getHostAddress()); //在外面解析好就行了}static class Test {public void test(String str){ //一个字符串就能搞定,就没必要丢整个对象进来System.out.println("IP地址:"+str);}}
}
反面教材
public class Main {public static void main(String[] args) throws IOException {Socket socket = new Socket("localhost", 8080); //假设我们当前的程序需要进行网络通信Test test = new Test();test.test(socket); //现在需要执行test方法来做一些事情}static class Test {/*** 比如test方法需要得到我们当前Socket连接的本地地址*/public void test(Socket socket){System.out.println("IP地址:"+socket.getLocalAddress());}}
}