如今做那个网站致富,建设工程业绩补录 网站,新网站如何做seo优化,wordpress评论删除站点1.单一职责原则
单一职责原则(Single responsibility principle)#xff0c;即一个类应该只负责一项职责。如类A负责两个不同职责#xff1a;职责1#xff0c;职责2。当职责1需求变更而改变A时#xff0c;可能造成职责2执行错误#xff0c;所以需要将类A的粒度分解为A1、…1.单一职责原则
单一职责原则(Single responsibility principle)即一个类应该只负责一项职责。如类A负责两个不同职责职责1职责2。当职责1需求变更而改变A时可能造成职责2执行错误所以需要将类A的粒度分解为A1、A2。所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。
单一职责原则注意事项和细节
降低类的复杂度一个类只负责一项职责。提高类的可读性可维护性降低变更引起的风险通常情况下我们应当遵守单一职责原则只有逻辑足够简单才可以在代码级违反单一职责原则只有类中方法数量足够少可以在方法级别保持单一职责原则 2.接口隔离原则 接口隔离原则Interface Segregation Principle, ISP是面向对象设计的五大原则之一由Robert C. Martin在《Agile Software Development, Principles, Patterns, and Practices》一书中提出。这一原则强调了在设计软件时应当尽量保持接口的小而专一以避免客户端依赖它不需要的方法。
具体来说接口隔离原则提倡以下几点 模块化设计每个接口应该专注于提供一组相关功能而不是试图满足所有客户端的需要。这样可以确保接口的高内聚性每个接口都只负责一个功能模块。 客户端定制接口为不同的客户端或用途定义不同的接口而不是强迫它们去依赖并实现那些它们实际上并不使用的接口方法。这样可以减少不必要的耦合提高系统的灵活性和可维护性。 避免胖接口胖接口是指包含了大量方法的接口这往往意味着使用该接口的类需要实现很多它实际上并不关心的方法。ISP建议将这样的大接口拆分为更小、更具体的接口使得每个类仅需实现它真正需要的方法。
遵循接口隔离原则的好处包括
提高代码的可读性和可维护性。减少代码间的耦合度易于修改和扩展。提升系统的灵活性便于单元测试。促进设计的清晰和职责的单一。
下面我将以Java语言为例简单展示如何应用接口隔离原则。
假设我们有一个系统需要处理不同类型的动物一开始可能会设计一个包含多种行为的胖接口
// 胖接口示例
interface Animal {void eat();void fly();void swim();
}
然后有一个Duck类实现了这个接口
class Duck implements Animal {Overridepublic void eat() {System.out.println(Duck is eating.);}Overridepublic void fly() {System.out.println(Duck is flying.);}Overridepublic void swim() {System.out.println(Duck is swimming.);}
}
但问题在于并非所有动物都能飞和游泳比如鸟可能不能游泳鱼不能飞。这导致了不必要的方法实现如对于一个只能游泳的鱼来说实现fly()方法是没有意义的。
按照接口隔离原则改进我们可以将接口拆分为更具体的几个
interface Eater {void eat();
}interface Flyer {void fly();
}interface Swimmer {void swim();
}
现在每个类只实现它需要的接口
class Duck implements Eater, Flyer, Swimmer {// 实现相应的方法...
}class Fish implements Eater, Swimmer {// 实现相应的方法无需实现fly()
}
这样Fish类就不需要实现fly()方法因为它不符合鱼的行为特征这便是接口隔离原则的应用实例它让我们的设计更加合理和灵活。
3.依赖倒转原则
面向过程的开发上层调用下层上层依赖于下层当下层剧烈变动时上层也要跟着变动这就会导致模块的复用性降低而且大大提高了开发的成本。
面向对象的开发很好的解决了这个问题一般情况下抽象的变化概率很小让用户程序依赖于抽象实现的细节也依赖于抽象。即使实现细节不断变动只要抽象不变客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。 4.里氏替换原则
在软件中子类型子类必须能够替换其基类型父类并且在软件中使用基类型的地方都能够使用子类型而不引发任何错误或导致程序的行为异常。这意味着子类应当能够保持父类的行为约定不会破坏或违背父类的预期用途。
具体来说里氏替换原则强调以下几个关键点 行为一致性子类应当能够替换父类且不会影响到程序的正确性。即使用父类的地方可以用子类替代而不会引起任何错误或意外行为。 合约不变子类应当遵守父类定义的接口契约即方法的前置条件和后置条件不能比父类更严格。例如如果父类的一个方法承诺在某种输入下一定会返回一个正数那么子类的相同方法也必须满足这一承诺。 增加功能但不改变原有行为子类可以添加新的方法或属性但不得去除或修改父类已有的方法除非是通过重写使行为更为一般化但仍需满足上述的合约不变原则。
遵循里氏替换原则的好处包括
增强代码的稳定性确保现有代码在新子类加入时仍能正常工作。提高代码的可预测性开发者可以依赖基类的行为而不用担心子类的具体实现细节。促进良好的设计鼓励设计者在设计类的继承结构时更加谨慎考虑接口和实现的一致性。
违反里氏替换原则可能导致的问题
子类的行为与父类不一致可能在运行时引发错误。系统变得更加脆弱难以维护和扩展因为子类的修改可能会影响到依赖父类的其他部分。 基类 Shape.java public abstract class Shape {public abstract double area();
} 子类 Rectangle.java public class Rectangle extends Shape {private double width;private double height;public Rectangle(double width, double height) {this.width width;this.height height;}Overridepublic double area() {return width * height;}
} 使用这些类的 Main.java public class Main {public static void main(String[] args) {Shape shape new Rectangle(10, 5); // 这里展示了里氏替换原则的应用System.out.println(Area: shape.area()); // 输出矩形的面积}
} 在这个Java示例中Rectangle类继承了抽象类Shape并实现了area()方法。在Main类中我们创建了一个Rectangle对象并将其向上转型为Shape类型的引用。这证明了子类对象可以替换父类对象同时程序逻辑保持正确体现了里氏替换原则的精神。通过将Rectangle实例赋给Shape类型的变量我们展示了子类对父类的透明替换能力而无需修改使用Shape的现有代码。父类可以不是抽象类吗
父类不一定是抽象类。里氏替换原则并没有规定父类必须是抽象类。它可以是一个具体的类只要子类遵循其规则即可。实际上里氏替换原则适用于所有类型的继承关系不论是抽象类还是具体类作为基类。
这里有一个非抽象父类的例子
父类 Vehicle.java public class Vehicle {public void start() {System.out.println(Vehicle started.);}
} 子类 Car.java public class Car extends Vehicle {Overridepublic void start() {System.out.println(Car started with ignition.);}
} 在这个例子中Vehicle是一个具体类它有一个start()方法。Car类继承了Vehicle类并重写了start()方法提供了更具体的实现。只要Car类中的start()方法不违反Vehicle类中该方法的预期行为比如没有改变车辆启动的基本含义或引入不可接受的行为变更即车开起来细化一下可以是汽车公交车卡车开起来但都比车这个范围更小更细化这就遵循了里氏替换原则。即使Vehicle类不是抽象的我们依然可以将Car实例安全地用在任何期待Vehicle类型的地方。
5.开闭原则
开闭原则(Open Closed Principle)一个软件实体如类模块和函数应该对扩展开放(对提供方)对修改关闭(对使用方)。也就是当软件需要变化时尽量通过扩展软件实体的行为来实现变化而不是通过修改已有的代码来实现变化。用抽象构建框架用实现扩展细节。
开始 Display直接修改成BarChart
Display用于显示各种图表。BarChart一种特定类型的图表表示条形图。
重构此设计以符合开闭原则。开闭原则要求软件实体模块、类或方法应该对扩展开放对修改关闭。这意味着我们应该能够轻松添加新功能如新的图表类型而不必更改现有的代码。
重构后的类结构图
Display负责显示图表。AbstractChart一个新的抽象类定义了显示图表的方法。BarChart继承自AbstractChart表示条形图。LineChart同样继承自AbstractChart表示折线图。 // 抽象类定义了显示图表的方法
abstract class AbstractChart {abstract void display();
}// 条形图类
class BarChart extends AbstractChart {Overridevoid display() {System.out.println(Displaying bar chart);}
}// 折线图类
class LineChart extends AbstractChart {Overridevoid display() {System.out.println(Displaying line chart);}
}// 显示器类负责显示图表
class Display {void display(AbstractChart chart) {chart.display();} 现在如果需要添加新的图表类型例如饼状图只需创建一个新的类如PieChart让它继承自AbstractChart并实现display()方法。然后在Display类中您不需要更改任何现有代码就可以处理新的图表类型。这就是开闭原则的一个简单应用。
6.迪米特法则
迪米特法则也被称为最少知识原则Least Knowledge Principle, LKP是一种面向对象设计中的指导思想它的核心理念非常直白“不要和陌生人说话”。这句话听起来像是一句社交建议但在编程世界里它帮助我们构建低耦合、高内聚的软件系统。
想象一下在一个公司里员工们专注于自己的工作他们通常只会直接和紧密相关的同事沟通比如他们的直接上司、团队成员或是直接对接的其他部门同事。他们不会也不应该去干涉或者直接联系公司里每一个不认识的人。这样做的好处是每个人的工作职责清晰减少了不必要的干扰提高了工作效率。
在编程中迪米特法则应用这个思路要求一个对象应该尽量减少与其他对象的直接交互特别是避免和那些它不直接依赖的对象交流。具体来说一个对象应该只和它的直接朋友通信
直接的朋友包括对象本身、对象的成员变量属性、传递给对象的方法参数以及由该方法创建或返回的对象。
遵循迪米特法则我们可以这样做
限制访问范围尽量使用private或protected修饰符限制类成员的访问权限只暴露必要的接口给外部。减少依赖通过接口而非具体类编程减少类之间的直接耦合。使用中介者当需要跨多个层级访问数据时可以引入一个中介对象来协调避免高层级的对象直接操作低层级的对象。 7.合成复用原则
合成复用原则(Composite Reuse Principle)就是是尽量使用合成/聚合的方式而不是使用继承。合成复用原则则更像是使用标准化的建筑模块来组装房屋。每个模块比如卧室模块、厨房模块、浴室模块都是独立设计和制造的。当你需要建造一座新房子时不是从零开始或者修改旧设计而是选择需要的模块进行组合。这样即使未来想升级卧室设计或者替换浴室设施只需替换相应的模块即可不影响整体房屋结构的稳定性和其他部分的正常使用。
放到编程领域这意味着我们应当尽量使用对象组合即将对象作为其他对象的属性或通过集合管理来实现新功能而不是通过继承来扩展类。这样做能够使得系统更加灵活易于维护和扩展因为修改或添加功能时不必触及或改动现有的类结构只需调整或增加新的组件对象即可保证了各个部分的独立性和复用性。就像是高效又灵活的建筑工地随时可以根据需求调整设计方案而不会造成大规模的返工。
