前端宝典十五：设计模式之前端开发5大设计原则

本文主要探讨前端开发设计原则：
单一职责原则
开闭原则
里氏替换原则
接口隔离原则
依赖倒置原则

一、单一职责原则（Single Responsibility Principle，SRP）

1、介绍：

一个类应该只有一个引起它变化的原因。这意味着一个类应该只负责一项特定的任务，避免将过多的功能集中在一个类中，提高类的内聚性和可维护性。

2、代码实例：

// 用户数据存储类，只负责用户数据的存储
class UserDataStorage {
  storeUserData(userData: any): void {
    // 存储用户数据的逻辑
    console.log(`Storing user data: ${userData}`);
  }
}

// 用户数据验证类，只负责用户数据的验证
class UserDataValidator {
  validateUserData(userData: any): boolean {
    // 验证用户数据的逻辑
    return true;
  }
}

3、实际应用场景：

在前端开发中，比如一个表单组件，可以将表单的渲染逻辑、数据验证逻辑和提交逻辑分别放在不同的类中。这样当需要修改表单的验证规则时，只需要修改验证类，而不会影响到渲染和提交逻辑。

二、开闭原则（Open/Closed Principle，OCP）

1、介绍：

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。这意味着当有新的需求时，应该通过扩展现有代码来实现，而不是修改已有的代码。

2、代码实例：

interface Shape {
  area(): number;
}

class Rectangle implements Shape {
  constructor(private width: number, private height: number) {}

  area(): number {
    return this.width * this.height;
  }
}

class Circle implements Shape {
  constructor(private radius: number) {}

  area(): number {
    return Math.PI * this.radius * this.radius;
  }
}

class AreaCalculator {
  calculateArea(shapes: Shape[]): number {
    return shapes.reduce((total, shape) => total + shape.area(), 0);
  }
}

3、实际应用场景：

在开发一个图表库时，可以定义一个抽象的图表接口，然后针对不同的图表类型实现这个接口。当需要添加新的图表类型时，只需要创建一个新的实现类，而不需要修改已有的代码。

三、里氏替换原则（Liskov Substitution Principle，LSP）

1、介绍：

子类型必须能够替换掉它们的父类型。也就是说，在任何使用父类的地方，都可以用子类来替换而不会产生任何错误或异常。

2、代码实例：

class Animal {
  move(): void {
    console.log('Animal is moving.');
  }
}

class Bird extends Animal {
  move(): void {
    console.log('Bird is flying.');
  }
}

class Dog extends Animal {
  move(): void {
    console.log('Dog is running.');
  }
}

function makeAnimalMove(animal: Animal): void {
  animal.move();
}

const bird = new Bird();
const dog = new Dog();

makeAnimalMove(bird);
makeAnimalMove(dog);

3、实际应用场景：

在开发一个游戏时，有一个角色类和各种子角色类。如果游戏中有一个函数接受角色类作为参数，那么可以传递任何子角色类的实例给这个函数，而不会影响游戏的逻辑。

四、接口隔离原则（Interface Segregation Principle，ISP）

1、介绍：

客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。这可以避免实现不必要的方法，降低类之间的耦合度。

2、代码实例：

interface Readable {
  read(): void;
}

interface Writable {
  write(data: any): void;
}

class File implements Readable, Writable {
  read(): void {
    console.log('Reading file.');
  }

  write(data: any): void {
    console.log('Writing to file.');
  }
}

class Database implements Readable {
  read(): void {
    console.log('Reading from database.');
  }
}

3、实际应用场景：

在前端开发中，如果有一个数据存储模块，可能有不同的存储方式，如本地存储和服务器存储。可以为它们分别定义不同的接口，避免在只需要本地存储功能的地方实现服务器存储的接口。

五、依赖倒置原则（Dependency Inversion Principle，DIP）

1、介绍：

高层模块不应该依赖低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。这可以降低模块之间的耦合度，提高代码的可维护性和可扩展性。

2、代码实例：

interface DataSource {
  fetchData(): any;
}

class DatabaseSource implements DataSource {
  fetchData(): any {
    return { data: 'from database' };
  }
}

class FileSource implements DataSource {
  fetchData(): any {
    return { data: 'from file' };
  }
}

class DataProcessor {
  constructor(private dataSource: DataSource) {}

  processData(): void {
    const data = this.dataSource.fetchData();
    console.log(data);
  }
}

3、实际应用场景：

在开发一个前端应用时，数据获取模块不应该直接依赖于具体的数据来源（如某个特定的 API），而是应该依赖于一个抽象的数据获取接口。这样当数据来源发生变化时，只需要修改具体的数据来源实现类，而不会影响到应用的其他部分。