六大设计原则之迪米特法则
1987年秋天，迪米特法则由美国Northeastern University的Ian Holland提出，被UML的创始者之一Booch等人普及。后来，因为经典著作The Pragmatic Programmer而广为人知。 迪米特法则 （Law of Demeter，LoD）又称为 最少知识原则 （Least KnowledgePrinciple，LKP），是指一个对象类对于其他对象类来说，知道得越少越好。也就是说，两个类之间不要有过多的耦合关系，保持最少关联性。 迪米特法则有一句经典语录：只和朋友通信，不和陌生人说话。也就是说，有 内在关联的类要内聚，没有直接关系的类要低耦合 。 就像家里的水管装修，有洗衣机地漏、卫生间地漏、厨房地漏，但它们最终都汇到同一个污水处理系统里。在平常使用时，我们不会考虑这些水管是怎么关联流向的，只需要考虑最上层的使用即可。 设计模式中的门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子 迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。 从迪米特法则的定义和特点可知，它强调以下两点： 广义的迪米特法则在类的设计上的体现： 这里用模拟学生、老师、校长之间关系的例子来说明迪米特法则来举例： 老师需要负责具体某一个学生的学习情况，而校长会关心老师所在班级的总体成绩。 违背原则的方案： 学生类： 老师类： 校长类： 校长想知道一个班级的总分和平均分，是应该找老师要，还是跟每一个学生要再进行统计呢？显然是应该找具体的班主任老师。我们在实际开发时，容易忽略这样的真实情况 迪米特法则改造方案： 老师类 校长类： 校长类直接调用老师类的接口，并获取相应的信息。这样一来，整个功能逻辑就非常清晰了。 在运用迪米特法则时要注意以下 6 点 缺点 迪米特法则是一种面向对象系统设计风格的一种法则，尤其适合做大型复杂系统设计指导原则。但是也会造成系统的不同模块之间的通信效率降低，使系统的不同模块之间不容易协调等缺点。 同时，因为迪米特法则要求类与类之间尽量不直接通信，如果类之间需要通信就通过第三方转发的方式，这就直接导致了 系统中存在大量的中介类 ，这些类存在的唯一原因是为了传递类与类之间的相互调用关系，这就毫无疑问的增加了系统的复杂度。解决这个问题的方式是： 使用依赖倒转原则，这样就可以使调用方和被调用方之间有了一个抽象层，被调用方在遵循抽象层的前提下就可以自由的变化，此时抽象层成了调用方的朋友。
六大设计原则之迪米特法则（LOD）
设计模式的六大原则有： 把这六个原则的首字母联合起来（两个 L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。下面我们来看一下迪米特法则。 设计模式六大原则(SOLID) 只与你的直接朋友交谈，不跟“陌生人”说话 其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。 迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。 过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。 从迪米特法则的定义和特点可知，它强调以下两点： 一个中介，客户只要找中介要满足的楼盘 ，而不必跟每个楼盘发生联系。 微服务中的网关，前端都请求到网关，而不是直接请求具体的微服务。
六大设计原则之五：迪米特法则
迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的，它要求 一个对象应该对其他对象有最少的了解 ，所以迪米特法则又叫做最少知识原则（Least Knowledge Principle, LKP）。 迪米特法则的意义在于降低类之间的耦合 。由于每个对象尽量减少对其他对象的了解，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。 值得一提的是，这一法则却不仅仅局限于计算机领域，在其他领域也同样适用。比如，美国人就在航天系统的设计中采用这一法则。 那么在实践中如何做到 一个对象应该对其他对象有最少的了解 呢？如果我们把一个对象看作是一个人，那么要实现“一个人应该对其他人有最少的了解”，做到两点就足够了：1.只和直接的朋友交流；2.减少对朋友的了解。下面就详细说说如何做到这两点。 迪米特法则还有一个英文解释是： talk only to your immediate friends（只和直接的朋友交流） 。什么是朋友呢？每个对象都必然会与其他的对象有耦合关系，两个对象之间的耦合就会成为朋友关系。那么什么又是直接的朋友呢？ 出现在成员变量、方法的输入输出参数中的类就是直接的朋友 。迪米特法则要求只和直接的朋友通信。 我们举一个例子说明什么是朋友，什么是直接的朋友。很简单的例子：老师让班长清点全班同学的人数。这个例子中总共有三个类：老师 Teacher 、班长 GroupLeader 和学生 Student 。 老师类： 班长类： 学生类： 使用场景也是非常的简单： 在这个例子中，我们的 Teacher 有几个朋友？两个，一个是 GroupLeader ，因为它是 Teacher 的 command: 方法的输入参数；另一个是 Student ，因为在 Teacher 的 command: 方法体中使用了 Student 。 那么我们的 Teacher 有几个是直接的朋友？按照直接的朋友的定义“出现在成员变量、方法的输入输出参数中的类就是直接的朋友”，只有 GroupLeader 是 Teacher 的直接的朋友。 Teacher 在 command 方法中创建了 Student 的数组，和非直接的朋友 Student 发生了交流，所以，上述例子违反了迪米特法则。方法是类的一个行为，类竟然不知道自己的行为与其他的类产生了依赖关系，这是不允许的，严重违反了迪米特法则！ 为了使上述例子符合迪米特法则，我们可以做如下修改： 修改后的GroupLeader： 修改后的老师类： 修改后的使用场景： 这样修改后，每个类都只和直接的朋友交流，有效减少了类之间的耦合。 如何减少对朋友的了解？如果你的朋友是个话痨加大喇叭，那就算你不主动去问他，他也会在你面前叨叨叨，把他所有的经历都讲给你听。所以，要减少对朋友的了解，请换一个内敛一点的朋友吧～换作在一个类中，就是 尽量减少一个类对外暴露的方法 。 举一个简单的例子说明一个类暴露方法过多的情况。这个例子描述的是一个人用咖啡机煮咖啡的过程，例子中只有两个类，一个是人，一个是咖啡机。 首先是咖啡机类 CoffeeMachine ，咖啡机制作咖啡只需要三个方法：1.加咖啡豆；2.加水；3.制作咖啡： 然后就是人类 Man ，该类只有一个方法 makeCoffee ，在该方法中使用咖啡机制作咖啡： 使用场景也非常的简单： 在这个例子中， CoffeeMachine 是 Man 的直接好友，但问题是 Man 对 CoffeeMachine 了解的太多了，其实人根本不关心咖啡机具体制作咖啡的过程。所以我们可以作如下优化： 优化后的咖啡机类，只暴露一个 work 方法，把制作咖啡的三个具体的方法 addCoffeeBean 、 addWater 、 makeCoffee 设为私有: 现在 Man 对 CoffeeMachine 的了解只有一个 work 方法了，所以 Man 类应该修改为： 这样修改后，通过减少 CoffeeMachine 对外暴露的方法，减少 Man 对 CoffeeMachine 的了解，从而降低了它们之间的耦合。 在实践中，只要做到 只和直接的朋友交流 和 减少对朋友的了解 ，就能满足迪米特法则。因此我们不难想象，迪米特法则的目的，是把我们的类变成一个个“肥宅”。“肥”在于一个类对外暴露的方法可能很少，但是它内部的实现可能非常复杂（这个解释有点牵强~）。“宅”在于它只和直接的朋友交流。在现实生活中“肥宅”是个贬义词，在日本“肥宅”已经成为社会问题。但是在程序中，一个“肥宅”的类却是优秀类的典范。 迪米特法则的核心观念就是类间解耦，弱耦合。只有弱耦合了之后，类的复用才可以提高，类变更的风险才可以减低。但解耦是有限度的，除非是计算机的最小单元--二进制的0和1，否则都是存在耦合的。所以在实际项目中，需要适度地参考这个原则，避免过犹不及。
设计模式原则是什么？
设计模式原则是：1、开闭原则：对扩展开放，对修改关闭，即在程序需要进行拓展的时候，不能去修改原有的代码，只能增加新的代码。2、里氏转换原则：子类继承父类，任何基类出现的地方，一定可以用子类替代出现。3、依赖倒转原则：引用一个对象，如果这个对象有底层类型，直接引用底层类型。4、接口隔离原则：使用多个隔离的接口，比使用单个接口要好，每一个接口应该是一种角色。5、合成／聚合复用原则：新的对象应使用一些已有的对象，使之成为新对象的一部分。6、迪米特原则：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，即一个对象应对其他对象有尽可能少得了解。
设计的原则是什么?
设计的原则：在进行软件系统设计时所要遵循的一些经验准则，应用该准则的目的通常是为了避免某些经常出现的设计缺陷。目前，较为公认的设计原则包括：开放-封闭原则、依赖倒置原则、里氏替换原则、接口隔离原则等。设计，是一个汉语词语，指“把一种设想通过合理的规划、周密的计划、通过各种方式表达出来的过程”。人类通过劳动改造世界，创造文明，创造物质财富和精神财富，而最基础、最主要的创造活动是造物。设计便是造物活动进行预先的计划，可以把任何造物活动的计划技术和计划过程理解为设计。相关信息：设计界因在欧美国家理论发展历史悠久，故设计史和相关理论，常以欧美的工业设计，建筑设计为两大主流。由于设计行为一般都解释为有明确目标的，因此在近代将与设计意涵相反的创作，称为乱数、随机等等。在西方，大型的设计系统，往往以Architecture建筑来称呼。这边指的建筑并非具体的建筑学、而是一种抽象的形容。设计在当代中国已成为一种新兴发展职业。
设计的基本原则为什么？
一、亲密性
想要拆散一对情侣，往往只需给他们之间增加点距离。
这其实就是亲密性原则的核心，当两个视觉元素彼此靠近时关联性就变得更强，被一定空间分隔后，就降低了他们的联系。
当我们对信息充分理解并开始编排时，就可以利用距离来控制他们之间的结构和逻辑关系，使阅读更顺畅。
如图、我在不改变字体、字重和字号大小的的前提下，只是简单的用距离区分了一下信息，原本堆积在一起的信息，就增强了一定的逻辑，阅读也变得简单了很多。
虽然是处理文字信息之间的亲密关系，实则我们是在控制各种间距的关系。
比如、字间距、行间距、组间距，这些距离的宽窄，影响着分组情况，带来的整体感受。
合理的间距不仅仅要让画面舒适，还可以对信息进行组织。
其中每个组之间的距离比行之间的距离大，才能体现出他们之间的关系。
上图文字编排的案例、文字组之间关系清晰、一目了然。
亲密性原则总结：亲密性的目的是组织信息、判断页面中哪些有关的的元素是可以被组织到一起的，哪些无关的元素是需要分开，实现画面的秩序性和条理性。
二、对齐
文字信息随意的摆放在版面中，必然造成混乱。
将元素进行对齐，是最简单建立秩序的方式，左右对齐、顶对齐、底对齐、两端对齐，居中对称，相信你一定听过并且时常应用。
虽然这是个简单的原则，却可以建立秩序的同时、影响版面风格。
左对齐对文字信息符合人的阅读习惯、并通过每行文字的长短形成节奏感。
是一种非常舒适的文字编排方式。
右对齐的文字也同样存在节奏感，与左对齐不同的是方向改变了，与人的正常阅读方向正好相反，于是让观看者产生了一定的陌生感，方式新颖。
竖排对顶部对齐，这种古籍常见对编排方式，给人历史文化感
竖排的底部对齐、富有节奏感、但在阅读上却不太容易、用它作为画面的装饰性文字则是很好的选择。
无论是横向编排的文字或是纵向编排的文字，都可以用到两端对齐的编排方式。
两端对齐，我们在画册中常见到，表现为文字组在画面中呈现一个矩形方整的块面状，平整舒缓、有条理。
在一些海报中也可以表现为、不同对齐方式的文字组被编排在一起时呈现出整体的方整的块面状，就像下方右侧图。
居中对称，文字居中对齐编排，非常常见能体现画面经典感的编排方式。
对齐原则总结：在设计时有意识的使用对齐方式进行编排文字，使画面统一有条理，虽然并不限制你在画面中到底使用了几种对齐方式，但如果没有十足的把握，尽量不要出现多种对齐方式让画面混乱。
三、重复
不要害怕画面中出现重复的元素，因为重复不单指信息重复、还可以是字体、线条、符号、颜色、格式、空间关系等等的重复。
上方海报案例出现了产品的重复、线的重复、点的重复。
再比如一本画册很多页出现同样的结构、同样的视觉元素，观看者才意识到这是一个有联系的同一本画册。
看下以上三幅海报，是什么原因让你认为它们是一组系列海报？
重复总结：重复可以理解为一致性。
四、对比
各种对比形式的目的都是希望画面更具有吸引力。
以上的各种原则，实现了文字信息的逻辑性、秩序感，但如果让画面更具表现力和吸引力的有利手段就是让画面有对比。
我曾写过关于对比的文章《设计中常见的几种对比方式》点击文章名可以跳转、这里不再赘述。
对比总结：对比目的希望画面有吸引力，值得注意的是，在文字编排中的对比关系处理，要有明确的层级关系。
比如画面中标题文字很醒目，但其他文字却是乏味的一致，那么在观看者在看到海报时，虽然第一眼看到了标题，但若想细看却不知道该看向哪里。
合适的做法是，有对比也有过度，在最醒目与最弱的视觉元素中间穿插过度性的视觉元素。
五、小提示
1、如何体现逻辑？
字号大小对比、负空间距离对比。
2、作对比时要注意什么？字号对比不要太极端，要在最强与最弱之间建立过度。
实在需要强烈对比，可适当拉大距离，让空白做缓冲带。
3、一段文字的节奏感如何建立
非两端对齐的对齐编排方式，由于行长的不同都会产生一定的节奏感，但比较好看的节奏形式是行长之间不要长的特别长，短的特别短，负空间也是如此。
4、画面中容易忽略的是什么？负空间的规整度、画面的平衡、视觉对比太极端
设计模式六大原则
设计模式六大原则为：单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则。1、单一职责原则：不要存在多余一个导致类变更的原因，即一个类只负责一个职责。2、开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。3、里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。4、依赖倒置原则：高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象。5、接口隔离原则：客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。6、迪米特法则：也被称为最少知识原则也可以表述为一个对象应该对其他对象有最少的了解，即一个类应该对自己需要耦合或调用的类知道的最少。以上内容参考百度百科-设计模式
面向对象设计的三个原则
面向对象设计的原则是单一职责原则、开放-封闭原则、Liskov替换原则、依赖倒置原则、接口隔离原则。1、单一职责原则。2、开放-封闭原则（对扩展开放；对修改关闭）。3、Liskov替换原则（子类型必须能够完全替换其父类型（继承）；关注行为的替换（多态））。4、依赖倒置原则（依赖抽象；面向接口编程等）。5、接口隔离原则（接口尽量小；接口要稳定，职责要单一；多个小接口比一个大的通用接口要好等）。三个基本特征1、抽象与封装：抽象是把系统中需要处理的数据和在这些数据上的操作结合在一起，根据功能、性质和用途等因素抽象成不同的抽象数据类型。每个抽象数据类型既包含了数据，又包含了针对这些数据的授权操作。在面向对象的程序设计中，抽象数据类型是用“类”这种结构来实现的，每个类里都封装了相关的数据和操作。封装是指利用抽象数据类型和基于数据的操作结合在一起，数据被保护在抽象数据类型的内部，系统的其他部分只有通过包裹在数据之外被授权的操作，才能与这个抽象数据类型进行交互。2、继承：它是与传统方法不同的一个最有特色的方法。它是面向对象的程序中两个类之间的一种关系，即一个类可以从另一个类（即它的父类）继承状态和行为。继承父类的类称为子类。继承的优越性：通过使用继承，程序员可以在不同的子类中多次重新使用父类中的代码，使程序结构清晰，易于维护和修改，而子类又可以提供一些特殊的行为，这些特殊的行为在父类中是没有的。3、多态：是指一个程序中同名的方法共存的情况，调用者只需使用同一个方法名，系统会根据不同情况，调用相应的不同方法，从而实现不同的功能。多态性又被称为“一个名字，多个方法”。
面向对象七大设计原则
面向对象的五大原则?单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。单一职责原则是实现高内聚、低耦合的指导方针，是最简单却最难运用的原则，需要设计人员发现类的不同职责并将其分离。面向对象设计原则有7个，这7大设计原则包括开闭原则、里氏替换原则、依赖倒转原则、单一职责原则、接口隔离原则、组合/聚合复用原则、迪米特法则。DIP依赖倒置原则抽象不依赖于细节，细节应该依赖抽象。（面向抽象编程，C#为面向接口编程）。ISP接口隔离原则接口属于用户类。特征见下面：抽象就是忽略一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有关的方面。继承是一种联结类的层次模型，并且允许和鼓励类的重用，它提供了一种明确表述共性的方法。面向对象设计的三个原则抽象不依赖于细节，细节应该依赖抽象。（面向抽象编程，C#为面向接口编程）。ISP接口隔离原则接口属于用户类。（接口面用用户类，不用想着和自身层次、方法相关）REP重用发布等价原则重用的粒度就是发布的粒度。单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。单一职责原则是实现高内聚、低耦合的指导方针，是最简单却最难运用的原则，需要设计人员发现类的不同职责并将其分离。在运用面向对象的思想进行软件设计时，需要遵循的原则一共有7个，他们是：单一职责原则（SingleResponsibilityPrinciple）每一个类应该专注于做一件事情。面向对象设计的基本原则有哪些依赖关系不要存在环。ADP稳定依赖原则朝着稳定的方向进行依赖。SAP稳定抽象原则包的抽象程度应该和稳定程序一致。单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。单一职责原则是实现高内聚、低耦合的指导方针，是最简单却最难运用的原则，需要设计人员发现类的不同职责并将其分离。面向对象的五大原则：模块化面向对象开发方法很自然地支持了把系统分解成模块的设计原则：对象就是模块。它是把数据结构和操作这些数据的方法紧密地结合在一起所构成的模块。
