js 五大原则
- 单一职责原则(一个程序只做好一件事,如果功能过于复杂就拆分开，每个部分保持独立)
- 开放封闭原则(对扩展开放，对修改封闭,增加需求时，扩展新代码，而非修改已有代码)
- 李氏置换原则(子类能覆盖父类,父类能出现的地方子类就能出现,js中使用较少（弱类型&继承使用较少）)
- 接口独立原则(保持接口的单一独立，避免出现“胖接口”,js中没有接口（typescript例外），使用较少)
- 依赖倒置原则<面向接口编程，依赖于抽象而不依赖具体,使用方只关注接口而不关注具体类的实现,js中使用较少（没有接口&弱类型）>
单一职责原则
- 单一职责原则定义是：
不要存在多于一个导致类变更的原因。通俗地说，即一个类只负责一项职责。
- 单一职责原则针对的问题
有一个类T负责两个不同的职责：职责P1和职责P2。当因为职责P1的需求发生改变而需要修改类T的时候，有可能会导致原本运行正常的职责P2功能发生故障。
- 单一职责原则的解决方案
遵循单一职责原则，分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1的时候，不会使职责P2发生故障风险。同理，当修改T2的时候，也不会使职责P1发生故障风险。
比如说，类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，或许是需求变更了，又或许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1和P2。这时候，如果要使程序遵循单一职责原则，就需要将类T也分解为两个类T1和T2，分别去负责P1和P2两个职责。但是在程序已经写好的情况下这样做，十分浪费时间和精力。所以，简单地修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做会有悖于单一职责原则。
适当地违背单一职责原则有时候反而能提高开发效率，因此设计原则还是要按照实际需求来选择使用的。
- 实例
比如，目前vue脚手架框架，
每个文件夹都有各自的职责，也都只负责一件事情。这就符合单一职责的。
- 单一职责原则的优点
1.降低类的复杂度，一个类只负责一个职责。这样写出来的代码逻辑肯定要比负责多项职责简单得多。
2.提高类的可读性，提高系统的可维护性。
3.降低变更引起的风险。变更是必然的，如果单一职责原则遵守得好，当修改一个功能的时候可以显著降低对其他功能的影响。
需要说明的一点是，单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。比如说单一职责原则不仅仅适用于类，还适用于方法
开闭原则
- 开闭原则定义是：
对扩展开放，对修改关闭。详细描述一下就是：添加一个新的功能时，应该在已有代码的基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。
- 开闭原则意义是：
对扩展开放是为了应对需求变化，对修改关闭是为了保证原有代码的稳定性。在识别出代码可变部分和不可变部分之后，要将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层使用。
- 实例
简单的示例：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
</head>
<body>
<div id="test"></div>
</body>
<script type="text/javascript">
//一个面向对象的JS例子，很好的支持了开闭原则
function HtmlControl(options) { //定义一个方法
var el = options.element; //el赋值为dom元素
//下面是为el元素添加参数样式
el.style.width = options.width;
el.style.height = options.height;
el.style.top = options.top;
el.style.background = options.background;
el.innerHTML=options.text;
console.log(el)
}
var option = { //为方法定义一个参数对象
element: document.getElementById('test'),
left: 50,
top: 0,
width: 100,
height: 200,
background: '#ccc',
text:'什么是开闭原则'
}
option.background = 'red'; //对参数对象进行扩展
HtmlControl(option); //调用
</script>
</html>
这是一个简单的例子，意思就是说封装一个功能，这个功能有默认参数，对外提供接口，接口参数可扩展改变，但是需要修改功能是不可以的，也就是说在功能接口内扩展修改该功能，就可以得到不同的效果。
4 . 如何做到“对扩展开放、对修改关闭”
最常用来提高代码扩展性的方法有：多态、基于接口而非实现编程、依赖注入，以及大部分设计模式（比如：装饰、策略、模板、职责链、状态等）。
最重要的是要时刻具备扩展意识、抽象意识、封装意识。写代码的时候多向前思考，可能会有哪些需求变更。不过也经常会有考虑不全的情况，只能通过不断重构来保持代码的可扩展性。
李氏置换原则
- 里氏替换原则针对的问题
有一个功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P2由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
- 里氏替换原则的解决方案
当使用继承的时候，遵循里氏替换原则。类B继承类A的时候，除了添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
继承包含这样一层含义：父类中范式已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
继承作为面向对象的三大特征(封装、继承、多态)之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象之间的耦合性。如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
- 里氏替换原则的案例
案例链接
关于里氏替换原则的例子，最有名的是【正方形不是长方形】。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但是从类的继承关系来看，由于它们不能继承鸟类会飞的功能，所以它们不能被定义成鸟类的子类。如果要强行定义为鸟类的子类，则有一些行为是需要重写鸟类的行为的，这样就违背了里氏替换原则。
这里以【几维鸟不是鸟】为例来说明里氏替换原则
public class LspTest {
public static void main(String[] args) {
Bird bird1 = new Swallow();
Bird bird2 = new BrownKiwi();
bird1.setSpeed(120);
bird2.setSpeed(120);
System.out.println("如果飞行300公里：");
try {
System.out.println("燕子将飞行" + bird1.getFlyTime(300) + "小时。"); // 燕子将飞行2.5小时。
System.out.println("几维鸟将飞行" + bird2.getFlyTime(300) + "小时。"); // 几维鸟将飞行Infinity小时。
} catch (Exception err) {
System.out.println("发生错误了！");
}
}
}
// 鸟类
class Bird {
double flySpeed;
public void setSpeed(double speed) {
flySpeed = speed;
}
public double getFlyTime(double distance) {
return (distance / flySpeed);
}
}
// 燕子类
class Swallow extends Bird {
}
// 几维鸟类
class BrownKiwi extends Bird {
public void setSpeed(double speed) {
flySpeed = 0;
}
}
这里，因为几维鸟类重写了鸟类的setSpeed方法，导致了程序发生错误，违背了里氏替换原则。正确的做法应该是取消几维鸟原来的继承关系，定义鸟类和几位鸟类的更一般的父类，比如动物类。他们都拥有奔跑的能力。几维鸟的飞行速度虽然为0，但是奔跑速度不为0，可以计算出其奔跑300千米所要花费的时间。
public class LspTest2 {
public static void main(String[] args) {
Animal bird_swallow = new Bird_Swallow();
Animal notBird_brownKiwi = new NotBird_BrownKiwi();
bird_swallow.setSpeed(120);
notBird_brownKiwi.setSpeed(120);
System.out.println("如果移动300公里：");
try {
System.out.println("燕子将花费" + bird_swallow.getFlyTime(300) + "小时。"); // 燕子将花费2.5小时。
System.out.println("几维鸟将花费" + notBird_brownKiwi.getFlyTime(300) + "小时。"); // 几维鸟将花费2.5小时。
} catch (Exception err) {
System.out.println("发生错误了！");
}
}
}
// 动物类
class Animal {
private double speed;
public void setSpeed(double speed) {
this.speed = speed;
}
public double getFlyTime(double distance) {
return (distance / speed);
}
}
// 燕子类
class Bird_Swallow extends Animal {
}
// 几维鸟类
class NotBird_BrownKiwi extends Animal {
}
- 里氏替换原则的认识
里氏替换原则的通俗理解就是：子类可以扩展父类的功能，但是不能改变父类原有的功能。也就是说，在子类继承父类的时候，除了添加新的方法完成新增功能之外，尽量不要重写父类的方法。
如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
如果程序违背了里氏替换原则，则继承的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计他们之间的关系。
它包含了以下4层含义：
1.子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。
2.子类中可以增加自己特有的方法。
3.当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更加宽松。
接口隔离原则
1.定义
用多个专门的接口，而不是使用单一的总接口
(一个类对应一个类的依赖应该建立在最小接口上
尽量细化接口，接口中的方法尽量少
注意适度原则，一定适度)
- 实例 （https://blog.csdn.net/ppwwp/article/details/107677784）
我们拿动物作为例子：动物都会吃，我们把动物的共有特性抽象为一个接口
然后我们把一些种类特有的性质抽象为一个接口，示例如下：
都会吃
public interface IAnimal {
public void eat();
}
有的会飞
public interface IFlyAnimal {
public void fly();
}
有的会游泳
public interface ISwimAnimal {
public void swim();
}
那么我们以依赖最少的原则来定义实现我们的具体的动物
Bird 会吃但是不游泳 会飞所以是实现了 IAnimal,IFlyAnimal 这两个接口
public class Bird implements IAnimal,IFlyAnimal {
@Override
public void eat() {
System.out.println("会吃");
}
@Override
public void fly() {
System.out.println("会飞");
}
}
dog会吃但是不会飞 会游泳所以是实现了 IAnimal,ISwimAnimal 这两个接口
public class Dog implements IAnimal,ISwimAnimal {
@Override
public void eat() {
System.out.println("会吃");
}
@Override
public void swim() {
System.out.println("会飞");
}
}
- 优点
- 符合我们常说的高内聚，低耦合的设计思想
- 从而使得类具有很好的可读性，可扩展性和可维护性
依赖倒转原则
- 定义
依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。（来自百度百科）
高层模块不应该依赖低层模块，两者都应该依赖其抽象
抽象不应该依赖细节
细节应该依赖抽象
- 实例 （https://www.cnblogs.com/zhengyufeng/p/11058046.html）
现有一个人类，人类有一个读书的接口，因为是读书，所以要依赖一个书类的输出书内容的方法。这就违反了依赖倒置原则，因为你此时人类是高层模块，书是低层模块，高层模块人类依赖了低层模块书类。此时如果要让人类去读报纸，原有的读书方法很难做到。
// 阅读类
class Reader{
constructor(content) {
this.content = content
}
// 获取内容的抽象方法
outPutContent(){
throw "Abstract methods require concrete implementation";
}
}
// 书类
class Book extends Reader{
constructor(content) {
super(content)
}
// 获取内容的抽象方法的实现
outPutContent(){
console.log(`书的内容是${this.content}`)
}
}
// 报纸类
class NewsPaper extends Reader{
constructor(content) {
super(content)
}
// 获取内容的抽象方法的实现
outPutContent(){
console.log(`报纸的内容是${this.content}`)
}
}
// 人类
class People{
constructor(name) {
this.name = name
}
// 读抽象方法的具体实现
reader(what){
console.log(`${this.name}读的`,what.outPutContent())
}
}
let xiaoMing = new People('小明')
let xiaoHong = new People('小红')
let anTuSheng = new Book('安徒生故事')
let wanBao = new NewsPaper('今日晚报')
xiaoMing.reader(anTuSheng);// 书的内容是安徒生故事 小明读的
xiaoMing.reader(wanBao);// 报纸的内容是今日晚报 小明读的
xiaoHong.reader(anTuSheng);// 书的内容是安徒生故事 小红读的
xiaoHong.reader(wanBao);// 报纸的内容是今日晚报 小红读的
- 优点：
避免需求变化导致过多的维护工作
采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
扫一扫
802
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
