面向对象设计（OOD）是面向对象编程（OOP）必不可少的一个环节，只有好的设计，才能保障程序的质量。面向对象设计的主要任务就是类的设计，不少面向对象（OO）的先驱和前辈已经提出了很多关于类的设计原则，用于指导OOP，其中就包括类设计的五项基本原则。
近年来，IT行业的环境相较以往显得有些严峻，因此一直以来，我都怀有一个愿望，希望能够创建一个分享面试经验的网站。由于个人有些懒惰，也较为喜欢玩乐，导致计划迟迟未能实现。然而，随着年底的临近，考虑到当前环境下许多开发者可能面临裁员等问题，我决定加速建设这个面试经验分享网站，以便为大家提供学习的平台，共同面对职场的挑战。
身为程序员我们每天都与代码打交道，而编程思想则是程序员在编写程序时所遵循的一种思维方式和方法论。它涵盖了程序员在面对问题时的思考方式、解决问题的方法以及编写代码的技巧和规范，下面简单说一下
SOLID原则是一组五个基本的面向对象设计原则，它们旨在帮助开发人员创建更加健壮、可维护、可扩展的软件系统。这些原则对于面向对象编程的重要性不言而喻，因为它们提供了一些指导和规则，有助于构建高质量的软件。
OCP（Open-Closed Principle），开放封闭原则：软件实体应该扩展开放、修改封闭。 实现：合理划分构件，一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里；一种可变性不应当与另一个可变性混合在一起。 DIP(Dependency Inversion Principle)，依赖倒置原则：摆脱面向过程编程思想中高层模块依赖于低层实现，抽象依赖于具体细节。OOP中要做到的是，高层模块不依赖于低层模块实现，二者都依赖于抽象；抽象不依赖于具体实现细节，细节依赖于抽象。 实现：应该通过抽象耦合的方式，使具体类最大可能的仅与其抽象类（接口）发生耦合；程序在需要引用一个对象时,应当尽可能的使用抽象类型作为变量的静态类型,这就是针对接口编程的含义。 LSP(Liskov Substitution Principle)，Liskov替换原则：继承思想的基础, 即子类能替代父类使用。“只有当衍生类可以替换掉基类，软件单位的功能不会受到影响时，基类才真正被复用，而衍生类也才能够在基类的基础上增加新的行为。” ISP（Interface Insolation Principle），接口隔离原则：客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上，不要引入无关因素，避免接口污染。 实现：一个类对另外一个类的依赖性应当是建立在最小的接口上的。使用多个专门的接口比使用单一的总接口要好。 SRP(Single Resposibility Principle)，单一职责原则：就一个类而言，接口职责单一，应该仅有一个引起它变化的原因。 如果一个类的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会抑止这个类完成其他职责的能力。 CARP（Composite/Aggregate Reuse Principle），合成/聚合复用原则：设计模式告诉我们对象委托优于类继承，从UML的角度讲，就是关联关系优于继承关系。尽量使用合成/聚合、尽量不使用继承。 实现：在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，以整合其功能。 LoD(Law Of Demeter or Principle of Least Knowledge)，迪米特原则或最少知识原则：就是说一个对象应当对其他对象尽可能少的了解，依赖越少越好。即只直接与朋友通信，或者通过朋友与陌生人通信。 朋友的定义（或关系）： （1）当前对象本身。 （2）以参量的形式传入到当前对象方法中的对象。 （3）当前对象的实例变量直接引用的对象。 （4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。 （5）当前对象所创建的对象。 实现： （1）在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。 （2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。 （3）在类的设计上，只要有可能，一个类应当设计成不变类。 （4）在对其它对象的引用上，一个类对其它对象的引用应该降到最低。 （5）尽量限制局部变量的有效范围.
所谓封装（Encapsulation），也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。封装是面向对象的特征之一，是对象和类概念的主要特性。简单的说，一个类就是一个封装了数据以及操作这些数据的代码的逻辑实体。在一个对象内部，某些代码或某些数据可以是私有的，不能被外界访问。通过这种方式，对象对内部数据提供了不同级别的保护，以防止程序中无关的部分意外的改变或错误的使用了对象的私有部分。
一个类只做它该做的事情。 是指一个类的功能要单一， 一个类只负责一个职责。 一个类只做它该做的事情(高内聚)。 在面向对象中， 如果只让一个类完成它该做的事， 而不涉及与它无关的领域就是践行了高内聚的原则。
在GoF(Gang of Four)的书籍《Design Patterns - Elements of Reusable Object-Oriented Software(设计模式-可复用面向对象软件的基础)》中是这样定义设计模式的：Christopher Alexander说过：“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动” [AIS+77，第10页]。尽管Alexander所指的是城市和建筑模式，但他的思想也同样适用于面向对象设计模式，只是在面向对象的解决方案里， 我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。一般而言，设计模式有四个基本要素：
作为开发人员，或多或少都会熟悉或了解一些设计模式，如单例模式、工厂模式、观察者模式等等。但并非都能理解这些设计模式背后的本质，从而可能会导致对模式单纯的套用或滥用的情况出现。不要为了模式而模式，要明白使用模式的目的，要正确理解模式背后的设计原理，要理解背后的基本设计原则。
作者：Mattia Cinelli翻译：朱启轩校对：欧阳锦 本文约3500字，建议阅读15分钟本文通过一些Python示例代码介绍了可以提高代码可靠性的SOLID编码准则。 标签：数据结构，编程，数据科学 SOLID原则是由Robert C. Martin提出的以首字母缩写命名的编码准则，它代表了五种不同的编码习惯。 如果您遵循这些原则，您就可以通过完善代码的结构和逻辑来提高代码的可靠度。 Photo by ThisisEngineering RAEng on Unsplash 以下是SOLID的五大原则
参考 模式分析，模式难点，模式解决问题，优点，缺点，模式应用场景，模式代码（基于dart)
当谈论软件设计，有一系列重要的原则和规范，它们像指南针一样指引着开发人员的方向，确保他们构建出高质量、可维护和可扩展的软件系统。这些原则不仅仅是代码编写的指导，更是一种思维方式，一种哲学，它们帮助我们在面对不断变化的需求和复杂性时保持清晰的思路。
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。需要注意以下几点：
设计原则是指导软件设计的一般性规则或准则。它们可以帮助开发者编写出结构良好、可维护、可重用、可扩展的代码。以下是一些被广泛接受和应用的设计原则：
60条面向对象设计原则 你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。 —–Arthur J.Riel (1)所有数据都应该隐藏在所在的类的内部。 (2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。 (3)尽量减少类的协议中的消息。 (4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 (5)不要把实现细
一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。（Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.），即又定义有且仅有一个原因使类变更。
在软件开发中，前人对软件系统的设计和开发总结了一些原则和模式， 不管用什么语言做开发，都将对我们系统设计和开发提供指导意义。本文主要将总结这些常见的原则和具体阐述意义。
有言曰，“无规矩不成方圆”，有“规”才能画“圆”，那设计模式要遵循的六大原则要画一个什么的“圆”呢？
构造函数（Constructor）是一种特殊类型的方法，它在创建类的实例（对象）时被调用，用于初始化对象的状态。构造函数的名称必须与包含它的类的名称相同，并且没有返回类型。
原文：www.cnblogs.com/pengdai/p/9151800.html
最近没事再次翻开《敏捷软件开发:原则、模式与实践》看，发现以前似懂非懂的东西突然就看懂了，get到了讲的重点。
设计模式都是为了让代码迎合其中一个或多个设计原则而出现的，所以面向对象的设计原则可以说是设计模式的基础思想。
我们在应用程序开发中，一般要求尽量两做到可维护性和可复用性。 应用程序的复用可以提高应用程序的开发效率和质量，节约开发成本，恰当的复用还可以改善系统的可维护性。而在面向对象的设计里面，可维护性复用都是以面向对象设计原则为基础的，这些设计原则首先都是复用的原则。遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。 面向对象设计原则和设计模式也是对系统进行合理重构的指导方针。
和其它编程语言相比，Python 在尽可能不增加新的语法和语义的情况下加入了类机制。
二十三个经典的设计模式已经过完了 ，这里再把一些基本原则过一下，以便平时开发中可以更好的体会。
这篇是第三部分的总结，基本上就是回看了之前的4篇笔记并且重新翻翻书梳理了一下，内容基本都是从前面的章节复制来的，长度较长，难度可能也比较大。
你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。 (1)所有数据都应该隐藏在所在的类的内部。p13 (2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15 (3)尽量减少类的协议中的消息。p16 (4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16 (5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17 如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 (6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17 (7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 p18 (8)类应该只表示一个关键抽象。p19 包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 . (9)把相关的数据和行为集中放置。p19 设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 (10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19 朝着稳定的方向进行依赖. (11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23 (12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。p30 (13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30 规划一个接口而不是实现一个接口。 (14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30 (15)对包含太多互不沟通的行为的类多加小心。p31 这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 (16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。p33 (17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36 (18)从你的设计中去除不需要的类。p38 一般来说，我们会把这个类降级成一个属性。 (19)去除系统外的类。p39 系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。 (20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40 (21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。p43 (22)尽量减少类的协作者的数量。p52 一个类用到的其他类的数目应当尽量少。 (23)尽量减少类和协作者之间传递的消息的数量。p55 (24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。p55 (25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55 (26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。p55 (27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57 (28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57 当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。 (29)让系统功能在窄而深的继承体系中垂直分布。p58 (30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60 (31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60 (32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。p60 (33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。p60 (34)类必须知道它包含什么，但是不能知道谁包含它。p61 (35)共享字面范围(也就是被同一个类
1.面向对象思想的核心思想是对象、封装、可重用性和可扩展性。面向对象是建立在面向过程之上的更高层次的抽象。
什么是类？ 我理解类是现实世界的描述，是对业务的抽象，类设计的好不好多半取决于你抽象的巧不巧。
下文摘自http://www.csdn.net/article/2015-09-06/2825621 GoF（四人帮），传说中的四位大神们，他们联手搞出了一套设计模式，堪称 OOD（面向对象设计）的经典之作！震惊了整个软件开发领域。但这四个老家伙非常怪异，总是喜欢显摆一些高深的理论，甚至有时候不说人话，十分让人费解。 除了最经典的六大设计原则以外，还有一些其他的设计原则也非常重要。我将尽可能地解释这些晦涩的理论，希望看完之后，会让您对这些设计原则稍微加深一些理解。若有不正确的地方，恳请大家指正！ 六
所谓单一职责原则就是一个类仅有一个引起它变化的原因。这里变化的原因就是所说的“职责”。如果一个类有多个引起它变化的原因，那么也就意味着这个类有多个职责，再进一步说，就是把多个职责耦合在一起了。
2.隐藏方法：如果想在派生类中定义一个和基类中重名的方法，但是实现过程不一样，这中操作叫隐藏方法。
俗话说得好：“设计模式，常读常新~”。的确，每读一遍设计模式都会有些新的体会和收获。马三不才，才读了两遍设计模式（还有一遍是在学校学的），属于菜鸟级别的。这次准备把阅读设计模式的想法记录下来，并且把设计模式应用在Unity游戏开发上，做些小案例。
> 这是SOLID的一篇翻译文章，作者是[serhiirubets](https://hackernoon.com/u/serhiirubets)。
这两种写法并没有任何区别，都是标记T是模板类型参数，可以是任何类型，包括用户自定义类型或是语言的基本类型。虽然而这在用于模板类型参数申明时的作用完全相同，但是仍建议使用typename，因为typename的字面意义即表示类型名称，更加符合其语义。而class则多用于类的申明，而非模板类型参数。当然，如果原有项目中均使用class，那么请与原有项目风格保持一致。
1. 单一职责原则（Single Responsibility Principle - SRP）
C++中，并不是所有的成员函数都能被子类继承，有三类成员函数不能被子类继承，分别是：构造函数（包括拷贝构造）、析构函数、赋值运算符重载函数。
LSP是继承关系设计基本原则，也是使OCP成为可能的主要原则之一。正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展，对于LSP的违反常常会导致以明显违反OCP的方式使用运行时类型辨别(RTTI),这种方式常常是使用一个显式的if语句或才if/else链去确定一个对象的类型
动态绑定是将一个过程调用与相应代码链接起来的行为。是指与给定的过程调用相关联的代码，只有在运行期才可知的一种绑定，它是多态实现的具体形式。
👉腾小云导读 本文作者在腾讯多年，主要从事的是腾讯云CDN、EdgeOne产品的后台研发工作。作者在云计算领域遇到了不少代码设计和程序设计的问题，他对于如何把项目中的代码标准化、提高开发维护的效率，做了总结梳理。本篇为各位分享作者总结的代码设计、架构设计原则和工作思维。欢迎阅读～ 👉目录 1 万物皆可抽象 1.1 遵循DRY原则 1.2 SOLID 原则 1.3 应用设计模式 2 高可用设计 2.1 设计高可用的系统架构 2.2 日志和监控，包含服务级和业
面向对象设计的目标之一在于支持可维持性复用，一方面需要实现设计方案或者源代码的复用，另一方面要确保系统能够易于扩展和修改，具有较好的灵活性。
大部分面向对象开发工作中都应用了以下部分或者全部的基本类别的类： 1、具体类（concrete class） 2、抽象类(abstract class) 3、接口类(interface class) 4、节点类(node class) 5、支持类(support class) 6、域类(domain class) 7、应用类(utility class) 8、集合和容器类(collection and container class) 这些类并不是特定的语言结构，而是用于实现逻辑类的技术。
了解设计模式的朋友们，想必都听说过“六大设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则，也就是说，设计模式是站在设计原则的基础之上的。所以在学习设计模式之前，很有必要对这些设计原则先做一下了解。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
