深入理解Java面向对象设计的六大原则

单一职责原则（SRP）

什么是单一职责原则

单一职责原则（SRP）指的是一个类应该只有一个引起变化的原因。通俗地讲，一个类应该只关注一个职责。如果一个类承担了过多的职责，那么在需求变化时，该类面临的变化可能会很复杂，从而影响代码的维护和扩展。

为什么要遵循单一职责原则

可读性：每一个类只负责一项职责，使得类的职责更加明确，代码更加可读。
可维护性：当类只有一个职责时，任何对应职责的变化都只会影响这个类，降低了维护成本。
可复用性：职责单一的类更容易被复用。
降低耦合：类与类之间的依赖关系减少，使得系统更加模块化。

代码示例

不遵循单一职责原则的代码：


public class Employee {private String name;private int age;public String getName() {return name;}public void setName(String name) {this.name = name;}public int getAge() {return age;}public void setAge(int age) {this.age = age;}public void calculateSalary() {// 计算工资的代码}public void saveToDatabase() {// 保存到数据库的代码}}

遵循单一职责原则的代码：


public class Employee {private String name;private int age;public String getName() {return name;}public void setName(String name) {this.name = name;}public int getAge() {return age;}public void setAge(int age) {this.age = age;}}public class EmployeeSalaryCalculator {public void calculateSalary(Employee employee) {// 计算工资的代码}}public class EmployeeRepository {public void save(Employee employee) {// 保存到数据库的代码}}

总结

单一职责原则是设计一个易于维护和扩展的系统的重要基础。尽管在实际应用中可能会有一些妥协，但我们应尽量使每个类的职责单一。

开放封闭原则（OCP）

什么是开放封闭原则

开放封闭原则（OCP）是指一个软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。通俗地讲，当需求变化时，我们应通过扩展已有的代码，而不是修改已有的代码来实现变化。

为什么要遵循开放封闭原则

稳定性：对已有代码的修改可能引入新的bug，遵循OCP能提高系统的稳定性。
扩展性：通过扩展而非修改已有代码，使得系统更具扩展性，更容易适应新的需求。
可维护性：减少了对已有代码的修改，使得代码变得更加可维护。

代码示例

不遵循开放封闭原则的代码：


public class Shape {public void draw(String shapeType) {if (shapeType.equals("Circle")) {drawCircle();} else if (shapeType.equals("Rectangle")) {drawRectangle();}}private void drawCircle() {// 画圆的代码}private void drawRectangle() {// 画矩形的代码}}

遵循开放封闭原则的代码：


public interface Shape {void draw();}public class Circle implements Shape {@Overridepublic void draw() {// 画圆的代码}}public class Rectangle implements Shape {@Overridepublic void draw() {// 画矩形的代码}}public class DrawingService {private List<Shape> shapes;public DrawingService(List<Shape> shapes) {this.shapes = shapes;}public void drawShapes() {for (Shape shape : shapes) {shape.draw();}}}

总结

遵循开放封闭原则不仅提高了代码的可维护性和稳定性，同时也增加了系统的扩展能力。在实际开发中，我们应尽量遵循该原则，从而设计出更灵活、可扩展的系统。

里氏替换原则（LSP）

什么是里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）是指在使用基类的地方可以透明地使用其子类，而不会导致程序错误。换句话说，子类对象应该能够替换其父类对象并且程序的行为不变。

为什么要遵循里氏替换原则

多态性：LSP是多态性的基础，通过子类替换父类，能够使得系统具备更好的灵活性和扩展性。
协作性：LSP保证了子类能够完全适应父类所定义的协作接口，使得系统能够更好地协作。
维护性：遵循LSP能够降低系统中的耦合度，使得代码更加容易维护。

代码示例

不遵循里氏替换原则的代码：


public class Bird {public void fly() {System.out.println("Bird is flying");}}public class Ostrich extends Bird {@Overridepublic void fly() {throw new UnsupportedOperationException("Ostrich cannot fly");}}

遵循里氏替换原则的代码：


public abstract class Bird {// Bird 公共行为}public interface Flyable {void fly();}public class Sparrow extends Bird implements Flyable {@Overridepublic void fly() {System.out.println("Sparrow is flying");}}public class Ostrich extends Bird {// Ostrich 特有行为}

总结

里氏替换原则是保证多态性的重要原则。遵循LSP能够使系统具备更好的扩展性和灵活性，同时也能够提高代码的可维护性和稳定性。

依赖倒置原则（DIP）

什么是依赖倒置原则

依赖倒置原则（Dependency Inversion Principle，DIP）指的是高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。

为什么要遵循依赖倒置原则

可扩展性：通过依赖于抽象，高层模块和低层模块的耦合度降低，从而增强了系统的可扩展性。
可维护性：修改低层模块的实现时，不会影响高层模块，使得系统更加易于维护。
模块重用性：增加系统各个模块的重用性，使得不同的模块可以组合使用。

代码示例

不遵循依赖倒置原则的代码：


public class Light {public void turnOn() {System.out.println("Light is on");}public void turnOff() {System.out.println("Light is off");}}public class Switch {private Light light;public Switch(Light light) {this.light = light;}public void operate(String command) {if (command.equals("ON")) {light.turnOn();} else if (command.equals("OFF")) {light.turnOff();}}}

遵循依赖倒置原则的代码：


public interface Switchable {void turnOn();void turnOff();}public class Light implements Switchable {@Overridepublic void turnOn() {System.out.println("Light is on");}@Overridepublic void turnOff() {System.out.println("Light is off");}}public class Switch {private Switchable device;public Switch(Switchable device) {this.device = device;}public void operate(String command) {if (command.equals("ON")) {device.turnOn();} else if (command.equals("OFF")) {device.turnOff();}}}

总结

依赖倒置原则是设计松耦合、高内聚系统的关键。通过依赖于抽象，我们能够使系统更加灵活和可维护。

接口隔离原则（ISP）

什么是接口隔离原则

接口隔离原则（Interface Segregation Principle，ISP）指的是客户端不应该依赖于它不需要的接口。换句话说，一个接口应该只提供客户端所需要的方法，避免将多个职责耦合在一起。

为什么要遵循接口隔离原则

提高耦合度：将接口分成多个小接口，使得客户端仅依赖于它需要的接口，降低了代码的耦合度。
提高可读性：更小的接口职责更加明确，提高了代码的可读性。
方便维护：修改某个接口时，不会影响到不需要该接口的客户端，从而提高了代码的维护性。

代码示例

不遵循接口隔离原则的代码：


public interface Worker {void work();void eat();}public class Developer implements Worker {@Overridepublic void work() {System.out.println("Developer is working");}@Overridepublic void eat() {System.out.println("Developer is eating");}}public class Robot implements Worker {@Overridepublic void work() {System.out.println("Robot is working");}@Overridepublic void eat() {throw new UnsupportedOperationException("Robot cannot eat");}}

遵循接口隔离原则的代码：


public interface Workable {void work();}public interface Eatable {void eat();}public class Developer implements Workable, Eatable {@Overridepublic void work() {System.out.println("Developer is working");}@Overridepublic void eat() {System.out.println("Developer is eating");}}public class Robot implements Workable {@Overridepublic void work() {System.out.println("Robot is working");}}

总结

接口隔离原则通过将大接口分割为小接口，使得客户端只依赖于它需要的接口，从而提高了代码的可读性和可维护性。

迪米特法则（LoD）

什么是迪米特法则

迪米特法则（Law of Demeter，LoD），又称最少知识原则（Principle of Least Knowledge，PLK），指的是一个对象应该对其他对象有尽可能少的了解。换句话说，一个对象应尽量少地与其他对象进行交互，避免过度耦合。

为什么要遵循迪米特法则

降低耦合：减少对象之间的过度依赖，降低系统的耦合度。
提高模块化：每个对象只关注自己的职责，提高了系统的模块化程度。
方便维护：减少了对象之间不必要的依赖关系，使得系统更易于维护和扩展。

代码示例

不遵循迪米特法则的代码：


public class Engine {public void start() {System.out.println("Engine started");}}public class Car {private Engine engine;public Car() {engine = new Engine();}public Engine getEngine() {return engine;}}public class Driver {public void drive(Car car) {car.getEngine().start();}}

遵循迪米特法则的代码：


public class Engine {public void start() {System.out.println("Engine started");}}public class Car {private Engine engine;public Car() {engine = new Engine();}public void start() {engine.start();}}public class Driver {public void drive(Car car) {car.start();}}