做网站如何收益,广州中小学智慧阅读门户网站,建设168网站,数据型网站文章目录 高内聚低耦合设计原则开闭原则单一职责原则里氏代换原则依赖倒置原则迪米特原则接口隔离原则 高内聚低耦合
提高代码的可读性、可维护性和可扩展性#xff0c;降低开发和维护的成本#xff0c;并减少系统的风险
内聚#xff1a; 内聚表示一个模块内部各个元素之间… 文章目录 高内聚低耦合设计原则开闭原则单一职责原则里氏代换原则依赖倒置原则迪米特原则接口隔离原则 高内聚低耦合
提高代码的可读性、可维护性和可扩展性降低开发和维护的成本并减少系统的风险
内聚 内聚表示一个模块内部各个元素之间相互关联的程度。 高内聚意味着模块内部的功能紧密相关所有部分都共同完成一个特定的任务或功能。 低内聚则意味着模块内部包含多种不相关的功能。 耦合 耦合表示不同模块之间相互依赖的程度。 高耦合意味着模块之间相互依赖紧密一个模块的变化会影响到其他模块。 低耦合则意味着模块之间相对独立一个模块的变化对其他模块的影响较小。 举个例子 汽车是由许多不同的部件组成的比如发动机、轮胎、刹车等等。 在高内聚低耦合的设计中每个部件都应该专注于自己的功能同时尽可能减少与其他部件之间的依赖关系。 高内聚意味着每个部件都应该有一个清晰的责任和功能。发动机的责任是提供动力而刹车系统的责任是提供制动。这样设计的好处是每个部件都可以独立工作而不需要过多依赖其他部件的内部细节。 低耦合意味着部件之间的相互依赖应该尽可能减少。刹车系统不需要知道发动机如何工作它只需要知道何时需要制动。这样设计的好处是如果需要更改或替换一个部件不会对其他部件产生太大影响因为它们之间的依赖关系很少。 高内聚意味着一个类或模块的内部元素包括变量、方法和属性应该紧密相关并且共同服务于一个明确且集中的目的。
低耦合模块或类之间的依赖关系应该尽可能少 内紧高内聚程序内的模块或类应该紧密相关形成一个高效的功能单元。外松低耦合程序之间的模块或类应该尽可能不关联各自实现各自的功能。 设计原则
在进行软件系统设计时所要遵循的一些经验准则应用该准则的目的通常是为了避免某些经常出现的设计缺陷提高软件系统的可维护性和可复用性增加软件的可扩展性和灵活性
包括单一职责原则开放封闭原则里氏替换原则依赖倒置原则迪米特原则接口隔离原则
开闭原则
Open-Closed Principle, OCP
定义类模块函数等应该是可以拓展的但是不可修改 对扩展开放对修改关闭。 我们需要使用抽象实现接口和抽象类达到这样的效果。
因为抽象灵活性好适应性广只要抽象的合理可以基本保持软件架构的稳定。
而软件中易变的细节可以从抽象派生来的实现类来进行扩展当软件需要发生变化时只需要根据需求重新派生一个实现类来扩展就可以了。
举个例子
//AbstractSkin.java
public abstract class AbstractSkin {//显示皮肤public abstract void display();
}//DefaultSkin.java
public class DefaultSkin extends AbstractSkin{Overridepublic void display() {System.out.println(默认皮肤);}
}//WhiteSkin.java
public class WhiteSkin extends AbstractSkin{Overridepublic void display() {System.out.println(白色皮肤);}
}//SougouInput.java
public class SougouInput {private AbstractSkin skin;public AbstractSkin getSkin() {return skin;}//通过setSkin方法设置不同的皮肤实现public void setSkin(AbstractSkin skin) {this.skin skin;}public void display() {skin.display();}
}//Client.java
public class Client {public static void main(String[] args) {//1.创建输入法对象SougouInput input new SougouInput();//2.创建皮肤对象DefaultSkin skin new DefaultSkin();//WhiteSkin skin new WhiteSkin();//3.将皮肤设置到输入法中input.setSkin(skin);//4.显示皮肤input.display();}
}
SougouInput 类通过其 setSkin 方法允许添加不同类型的皮肤如 DefaultSkin 或 WhiteSkin这体现了对扩展的开放性。
由于 SougouInput 类依赖于 AbstractSkin 抽象类而不是具体的皮肤实现类因此添加新的皮肤类型只需要创建新的子类并实现 AbstractSkin 的 display 方法而不需要修改 SougouInput 类的代码。这体现了对修改的封闭性。
皮肤的类不用修改再创建新皮肤让他继承AbstractSkin抽象类在客户端类代码进行修改即可。
作用
提高软件的可维护性增强软件的扩展性减少代码的耦合度
单一职责原则
Single Responsibility PrincipleSRP
定义一个类或模块、函数等应该只有一个引起它变化的原因。换句话说一个类应该只负责一个功能领域中的相关职责或者变化的原因应该只有一个。
下面是不符合单一职责原则的例子
public class TelPhone {public void Dial(String phone_number){System.out.println(给phone_number打电话);}public void HangUp(String phone_number) {System.out.println(挂断 phone_number 打电话);}public void SendMessage(String message) {System.out.println(发送 message);}public void ReceiveMessage(String message) {System.out.println(接收 message);}
}可能发生的变化 内部的变化如果 TelPhone 类中的任何一个方法发生改变都需要修改TeIPhone、由于它负责了多个职责所以一个职责的变化可能会导致其他无关职责的代码也需要被修改或重新测试。 外部的变化如果TeIPhone要添加新的的方法需要修改TeIPhone类
为了符合单一职责原则我们可以做出如下修改
但中间的依然不符合存在一个以上引起类变化的原因所以我们可以考虑最右边的一个类中只有一个方法 但这样比较极端会导致类的数量大幅增加使得管理和维护代码变得复杂。
因此我们通常要在单一职责原则和实际应用之间找到一个平衡点。
实现方式
给每个方法都提炼成一个接口抽象成一种能力然后分别写类去实现接口最终在TelPhone中只进行调用。
package com.feng.test01;interface Dialer {void Dial(String phoneNumber);
}interface Hanger {void HangUp();
}interface Sender {void SendMessage(String text);
}interface Receiver {void ReciveMessage(String text);
}class DialerImpl implements Dialer {public void Dial(String phoneNumber) {System.out.println(给 phoneNumber 打电话);}
}class HangerImpl implements Hanger {public void HangUp() {System.out.println(挂断电话);}
}class SenderImpl implements Sender {public void SendMessage(String text) {System.out.println(发送 text);}
}class ReceiverImpl implements Receiver {public void ReciveMessage(String text) {System.out.println(接收 text);}
}class TelPhone {private Dialer dialer;private Hanger hanger;private Sender sender;private Receiver receiver;public TelPhone(Dialer dialer, Hanger hanger, Sender sender, Receiver receiver) {this.dialer dialer;this.hanger hanger;this.sender sender;this.receiver receiver;}public void Dial(String phoneNumber) {dialer.Dial(phoneNumber);}public void HangUp() {hanger.HangUp();}public void SendMessage(String text) {sender.SendMessage(text);}public void ReciveMessage(String text) {receiver.ReciveMessage(text);}
}public class Main {public static void main(String[] args) {// 创建接口实现类实例Dialer dialer new DialerImpl();Hanger hanger new HangerImpl();Sender sender new SenderImpl();Receiver receiver new ReceiverImpl();// 创建 TelPhone 对象并使用其接口TelPhone telphone new TelPhone(dialer, hanger, sender, receiver);// 电话呼叫操作telphone.Dial(123456789);telphone.HangUp();// 消息操作telphone.SendMessage(Hello, World!);telphone.ReciveMessage(Hi there!);}
}好处
提高代码的可读性提高系统的可维护性。降低类的复杂性一个模块只负责一个职责提高系统的可扩展性和可维护性。降低变更引起的风险。变更是不然的如果单一职责做得好当修改一个功能的时候可以显著的降低对另一个功能的影响。
里氏代换原则
Liskov Substitution PrincipleLSP
里氏代换原则任何基类可以出现的地方子类一定可以出现。
通俗理解子类可以扩展父类的功能但不能改变父类原有的功能。
要点
功能保持子类应当能够替代基类并且子类对象应能代替基类对象使用而不会导致程序运行出现问题。
行为一致子类可以扩展基类的功能但不能改变基类的功能。即子类的行为应该与基类保持一致
要求
子类可以实现父类的抽象方法但不要去覆盖重写父类的非抽象方法子类可以增加自己特有的方法当子类的方法重写父类的方法时方法的前置条件即方法的输入/入参要比父类方法的输入参数更宽松当子类的方法实现父类的方法时重写或实现抽象方法方法的后置条件即方法的输出/返回值要比父类更严格或与父类一样
package com.feng.test05;public abstract class Coder {public void coding() {System.out.println(我会敲代码);}
}class JavaCoder extends Coder {public void play() {System.out.println(喜欢玩XXXX);}//重写了父类的非抽象方法public void coding() {System.out.println(我只会敲JAVA代码);}
}里氏代换原则指出如果程序中的对象使用的是基类父类的话那么无论是使用基类对象还是其子类对象程序的行为都是一致的。
用 JavaCoder 替代 Coder 时本来会敲很多代码但现在只会敲JAVA了。
所以尽量不要去重写父类非抽象方法不要改变父类原有的功能。
可以这样修改
保留父类方法的行为并且扩展子类方法的功能 public void coding() {super.coding(); // 调用父类的coding方法System.out.println(我会敲JAVA代码);}或者再写一个javaCoding方法写JavaCoder和Coder的抽象父类People把coding这一行为定义在People中放弃JavaCoder和Coder的继承关系
好处
开放性是实现开放封闭原则的的具体手段之一提高代码的可复用性
依赖倒置原则
Dependence Inversion PrincipleDIP
定义高层模块不应该依赖低层模块两者都应该依赖抽象。抽象不应该依赖细节细节应该依赖抽象。
旨在通过依赖于抽象而不是具体实现来降低系统的耦合度提高系统的可维护性和可扩展性。
下面是一个违背依赖倒置原则的例子
package com.feng.test04;class FuelCar{public void run(){System.out.println(开的是燃油车);}
}class Driver{public void drive(FuelCar car) {car.run();}
}public class Client {public static void main(String[] args) {FuelCar fuelCar new FuelCar();Driver xiaowang new Driver();xiaowang.drive(fuelCar);}
}Driver 类直接依赖于 FuelCar 类而没有使用抽象违反了依赖倒置原则。
如果我们想要支持其他类型的车辆比如电动车或者公交车就需要修改 Driver 类这样会增加代码的耦合度和维护成本。
高层模块Driver不应该直接依赖于低层模块FuelCar而是应该依赖于抽象。在这个例子中Driver 类应该依赖于一个抽象的 ICar 接口而不是具体的 FuelCar 类。
我们可以引入一个接口来表示所有类型的车并让FuelCar实现这个接口。然后Driver的drive方法可以接受任何实现了ICar接口的对象作为参数。
package com.feng.test04after;interface ICar {void run();
}class FuelICar implements ICar {Overridepublic void run() {System.out.println(开的是燃油车);}
}class ElectricICar implements ICar {Overridepublic void run() {System.out.println(开的是电车);}
}class Driver {public void drive(ICar car) {car.run();}
}public class Client {public static void main(String[] args) {ICar su7 new ElectricICar();ICar benz new FuelICar();Driver driver new Driver();driver.drive(su7);driver.drive(benz);}
}作用
提高代码的可维护性降低代码的耦合度提高系统的可扩展性
迪米特原则
Law of DemeterLoD
也称为最少知识原则一个对象应该对其他对象有最少的了解。
定义如果两个软件实体无须直接通信那么就不应当发生直接的相互调用可以通过第三方转发该调用 一个对象应该对其他对象知之甚少只与“朋友”通信而不与“陌生人”直接通信。 租房者-中介-房东要做软件的公司-软件公司-软件工程师 这里的“朋友”指的是当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等
这些对象同当前对象存在关联、依赖、聚合或组合关系可以直接访问这些对象的方法。
下面是一个
import java.util.ArrayList;
import java.util.List;class Product {private String name;private double price;public Product(String name, double price) {this.name name;this.price price;}public String getName() {return name;}public double getPrice() {return price;}
}// 购物车类
class ShoppingCart {private ListProduct products;public ShoppingCart() {this.products new ArrayList();}// 添加商品到购物车public void addProduct(Product product) {products.add(product);}// 打印购物车中的商品信息public void printCart() {for (Product product : products) {System.out.println(商品 product.getName() 价格 product.getPrice());}}
}public class Test {public static void main(String[] args) {Product product1 new Product(banana, 2);Product product2 new Product(apple, 5);ShoppingCart cart new ShoppingCart();cart.addProduct(product1);cart.addProduct(product2);cart.printCart();}
}ShoppingCart 类对 Product 类的了解仅限于 getName 和 getPrice 方法这是符合迪米特原则的。ShoppingCart 不需要知道 Product 类的内部实现细节也不需要与其他任何与 Product 类相关的“陌生人”对象进行交互。
好处
降低耦合性提高模块独立性增强系统的可维护性
接口隔离原则
Interface Segregation PrincipleISP
定义一个类对另一个类的依赖应该建立在最小的接口上。
建立单一接口不要建立庞大臃肿的接口尽量细化接口接口中的方法尽量少。
也就是说我们要为各个类建立专用的接口而不要试图建立一个很庞大的接口件所有依赖它的类通用。
下面是一个不符合接口隔离原则的例子
package com.feng.test03;interface Device {String getCpu();String getType();String getMemory();
}
class computer implements Device{Overridepublic String getCpu() {return i7;}Overridepublic String getType() {return 笔记本电脑;}Overridepublic String getMemory() {return 16GB;}
}class fan implements Device{Overridepublic String getCpu() {return null; //不需要的方法}Overridepublic String getType() {return 电风扇;}Overridepublic String getMemory() {return null; //不需要的方法}
}虽然定义了一个Device接口但是由于此接口的粒度不够细化类依赖于不需要的方法。虽然比较契合电脑这种设备但是不适合风扇要对其进行更细粒度的划分。
接口的粒度描述了接口所提供功能的大小和复杂度
下面是一个符合接口隔离原则粒度更细的代码
// 通用设备接口
interface GenericDevice { String getType();
} // 电脑设备接口
interface ComputerDevice extends GenericDevice { String getCpu(); String getMemory();
} // 风扇设备接口
interface FanDevice extends GenericDevice {void adjustSpeed(int speed);
} 注意
接口尽量小但是要有限度。对接口进行细化可以提高程序设计的灵活性但是如果过小则会造成接口数量过多使设计复杂化。所以接口的大小一定要适度。为依赖接口的类定制服务只暴露给调用的类需要的方法不需要的方法则隐藏起来只有专注地为一个模块提供定制服务才能建立最小的依赖关系。提高内聚减少对外交互。接口方法尽量少用public修饰。接口是对外的承诺承诺越少对系统的开发越有利变更风险也会越少。
作用
降低耦合性提高灵活性增强可维护性 开闭原则抽象架构扩展实现单一职责一个类和方法只做一件事里氏替换 多态子类可扩展父类依赖倒置细节依赖抽象下层依赖上层接口隔离建立单一接口迪米特原则最少知道降低耦合 参考 14.设计模式-设计原则(依赖倒转原则概述和案例)【设计模式】六大原则详解六大设计原则超详细介绍面向对象设计原则 如有错误烦请指正。
感谢您的阅读
