UI设计模式的七大基本原则
新闻来源：优漫教育
日期：2021-07-29
凡事都有一定的规律可循，设计模式也不例外。广州优漫动游教育UI设计培训学校小优整理出一些设计模式，一般遵循以下七个基本原则：
一、单一责任原则。
单点职责原则表达了模块组件的功能相关性。对于软件更改来说，类的更改只有一个原因；一般而言，一个类只负责一个职责。
(1)SRP原理简单直观，但在实际编码中难以正确使用，需结合实际情况。
(2)一种责任原则可减少一门课的复杂性。一种类只负责一种责任，其逻辑肯定比多重责任的逻辑简单。
(3)改进代码的可读性和系统的可维护性。
开放和闭合原理说明软件实体(类、模块、功能等)应该是可扩展的，但不能修改。(Openforextension,closeformodification)
(4)可对现有系统进行扩充，提供新的功能，以适应新的需求，具有较强的适应性和灵活性。
(5)现有模块，特别是那些重要的抽象模块，无需修改，因此该软件具有很强的稳定性和耐久性。
程序设计中，我们经常会遇到这样的问题：一个由类a完成的函数P1，现在我们需要扩展这个函数P1。扩充函数是p，其中p包含原函数P1和新函数P2。新函式p由类A的子类B完成，当新函数P2完成时，子类B可能会导致原函数P1失败。
Richter替换原理告诉我们，当使用继承时，类B继承类A时，尽量不要修改父方法的预期行为，而只会添加新方法完成新函数P2。
Leeb替代原则的目的是：***不影响原始函数，而不影响原始方法。
遗传的含义是：父类中的所有实现方法(与抽象方法相关)实际上建立了一系列规范和契约。尽管它不要求所有的子类都必须遵守这些契约，但如果子类随意地修改这些非抽象方法，就会破坏整个继承系统。瑞克特的另类原则表明了这种意义。
定义：***模块不应依赖于底层模块，它们都是抽象的。而且，抽象不能依赖于细节，而应依赖于抽象。
举例来说，某一天产品经理需要添加一个操作数据库的新功能。不同的程序员常常负责封装数据库操作和处理业务逻辑。
可将封装的数据库操作视为底层模块，而处理业务逻辑可视为***模块。在封装数据库操作的代码编写完成之后，如果处理业务逻辑需要等待，将严重影响项目的进度。
适当的方法是为处理业务逻辑的程序员提供一个抽象界面，用来封装数据库操作，然后交给底层模块的程序员编写，这样双方就可以独立编写，而不会互相影响。
界面隔离原则ISP[建议：Android设计师需要什么实用的UI设计工具？]
界面隔离原则，它的“隔离”并不是一个准备好的翻译，它的真正目的是“隔离”界面。
界面分离原则强调，客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该基于小接口。
狄米特定律，又称未知原理，是指一个物体对其它物体了解得较少。通常，它只和直接的朋友沟通。
第一，让我们来解释什么是直接的朋友：每一个对象都和其他对象的耦合。如果两个物体之间存在耦合关系，我们可以说这两个对象是朋友耦合的方式有很多种，如依赖、关联、组合、聚合等，这些成员变量中的类、方法参数和方法的返回值称为直接友元，局部变量中的类不是直接友元。这就是说，***不能以局部变量的形式出现。
无论逻辑有多么复杂，依赖类都会尝试将逻辑封装到类中，并且把一个公共方法提供给外部，而不会泄露任何信息。
合并/聚集复用的原则是在新对象中使用一些现有对象，使之成为新对象的一部分；新对象可以通过委派这些对象来重用已有函数。
在面向对象的设计中，如果直接继承基类，封装就会被破坏，因为继承会向子类公开该基类的实现细节；如果基类的实现发生变化，子类的实现就必须更改；从基类继承的实现是静态的，而且在运行时不能更改，而且没有足够的灵活性。在实际的开发设计中，为了避免类继承，本文提出了组合/聚合复用的原则，尽可能多地使用组合/聚合。
