重修计划模式-计划原则
计划原则
计划原则是软件编码时所遵循的规则，旨在帮助开辟者创建出既满足功能需求又易于维护、可扩展且雅观的计划，明白计划原则可以提升代码质量、淘汰错误以及促进团队协作，但对计划原则的明白要灵活，不要拿原则认真理，生搬硬套会适得其反。
SOLID原则：
- S：单一职责原则（Single Responsibility Principle, SRP）
A class or module should have a single responsibility.
一个类大概模块只负责完成一个职责。
这有助于降低体系的复杂性，提高代码的可读性和可维护性。当需求变更时，只需要修改负责该职责的类或模块即可。
- O：开闭原则（Open-Closed Principle, OCP）
software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification.
软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭。
意味着软件应该通过添加新的代码来扩展，而不是通过修改现有的代码来实现，有助于保持体系的稳定性和可维护性。
- L：里式替换原则（Liskov Substitution Principle, LSP）
Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.
子类对象可以或许替换程序中父类对象出现的任何地方，并且包管原来程序的逻辑行为不变及正确性不被破坏。
里式替换和多态有点类似，但它们关注的角度不一样：多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法，是一种代码实现的思路。而里式替换是一种计划原则，是用来引导继承关系中子类该如何计划的，子类的计划要包管在替换父类的时间，不改变原有程序的逻辑以及不破坏原有程序的正确性。
- I：接口隔离原则（Interface Segregation Principle, ISP）
Clients should not be forced to depend upon interfaces that they do not use.
客户端不应该被逼迫依赖它不需要的接口。此中的“客户端”，可以明白为接口的调用者大概使用者。
一个类对另一个类的依赖应该建立在最小的接口上。有助于淘汰接口的污染和不必要的依赖，提高体系的灵活性和可维护性。
- D：依赖倒置原则（Dependency Inversion Principle, DIP）
High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.
高层模块不要依赖低层模块，两者都应该依赖其抽象。
抽象不应该依赖细节。
细节应该依赖抽象。
有助于淘汰模块间的耦合度，提高体系的灵活性和可维护性。
在 Java 中的表现是：
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
- 接口或抽象类不依赖于实现类；
- 实现类依赖接口或抽象类。
举例，不符合依赖导致原则的类依赖关系：
符合后：
迪米特法则（Law of Demeter, LoD）
Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
每个模块只应该了解那些与它关系密切的模块的有限知识。大概说，每个模块只和自己的朋侪“说话”，反面陌生人“说话”。
迪米特法则也叫最小知识原则：The Least Knowledge Principle。
不应有直接依赖关系的类之间，不要有依赖。有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则渴望淘汰类之间的耦合，让类越独立越好，缩小功能改动导致的代码改动范围，有助于代码“高内聚，低耦合”。
- 高内聚：相近的功能应该放到同一个类中。
- 低耦合：类与类之间的依赖关系简单清晰，纵然两个类有依赖关系，一个类的代码改动也不会大概很少导致依赖类的代码改动
KISS原则
Keep It Simple and Stupid.
尽量保持简单。
强调计划应该保持简单，避免过度复杂。简单的计划更轻易明白、维护和扩展。
YAGNI 原则
You Ain’t Gonna Need It.
你不会需要它。
在软件开辟中，不要去计划当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度计划。
DRY原则
Don’t Repeat Yourself.
不要重复你自己。
重复包括以下几种情况：
- 代码实现重复：两个方法中大部门代码相同，只有小部门差别。
看是否能抽出通用方法，但也要留意“单一职责原则”和“接口隔离原则”。
- 功能语义重复：两个方法的实现不同，但方法名语义相同。
- 实行重复：代码实行时，某一代码块实行冗余。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
