- 综合排序
- 最热优先
- 最新优先
- 来自专栏Java技术栈
Java架构师必须知道的 6 大设计原则
开发原则 面向对象的基本原则(solid)是五个，但是在经常被提到的除了这五个之外还有 迪米特法则和合成复用原则等， 所以在常见的文章中有表示写六大或七大原则的； 除此之外我还将给出一些其它相关书籍和互联网上出现的原则 原则分析 1）如果说开闭原则是面向对象设计的目标，依赖倒转原则是到达面向设计"开闭"原则的手段。如果要达到最好的"开闭"原则，就要尽量的遵守依赖倒转原则。可以说依赖倒转原则是对“抽象化”的最好规范！ 我个人感觉，依赖倒转原则也是里氏代换原则的补充。你理解了里氏代换原则，再来理解依赖倒转原则应该是很容易的。 2）依赖倒转原则的常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中。 依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键。 3）此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范。违反这一原则，就无法实现"开-闭"原则，首先我们要明白合成和聚合的概念： 注意：聚合和组合的区别是什么？
1.3K30发布于 2018-07-30 - 来自专栏技术一号位指南(小诚信驿站)
【技术一号位指南🧭】谈谈我眼中的架构师思考原则
然而我们还得在碎片化的时间中保持自己的成长速度，这里面如果只是靠简单的碎片化知识，容易导致我们思维不够体系化，学习到的知识比较碎片化，所以我们需要形成系统学习的习惯、天思考-周思考-月思考的不断沉淀知识 1.6、管理结果-调研思考对于日常管理，需要有足够的输入和思考才可以进行结果输出，不然很容易被带偏和误导造成失误。 1.8、管理时间-提高效率如何管理时间1.9、管理视角-全局视野无论是作为工程师、架构师、团队Leader、高管、CXO，一定要基于当前的工作可以向上看、向下感的全局视野看待问题。 视角的思考-如何活成自己讨厌的人1.10、管理成长-四心齐备成长这个事情已经变成了终身成长，那么在我们整个生命不同阶段的过程中如何保持自己一直成长呢？我思考以后发现需要有三心准备。 如何管理项目、管理团队、管理不确定性1.12、管理本质-抽象破圈设计模式、架构模式不外乎涉及到高内聚/低耦合，抽象/平台/扩展设计，SOLID原则；采用简单的方案解决技术问题，不炫技，直到问题变复杂，不做过度设计
1.4K31编辑于 2023-05-26 - 来自专栏全栈程序员必看
设计模式之6大原则(6)开闭原则
开闭原则（OCP） 是 面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之中的一个，其他非常多的设计原则都是实现开闭原则的一种手段。 开闭原则中“开”，是指对于组件功能的扩展是开放的，是同意对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的改动是封闭的，即不应该改动原有的代码。 实现开闭原则的关键就在于“抽象”。把系统的全部可能的行为抽象成一个抽象底层，这个抽象底层规定出全部的详细实现必须提供的方法的特征。 这就要求我们在设计的时候，要很清楚地了解用户需求，推断需求中包括的可能的变化，从而明白在什么情况下使用开闭原则。 在20世纪90年代，开闭原则被广泛的又一次定义因为抽象化接口的使用，在这中间实现能够被改变，多种实现能够被创建，而且多态化的替换不同的实现。相比梅耶的使用方式，多态开闭原则的定义倡导对抽象基类的继承。
67421编辑于 2022-07-09 - 来自专栏烟草的香味
6大设计原则之开闭原则
开闭原则的定义 开闭原则的定义: 一个软件实体,如类、模块和函数应该对扩展开放,对修改关闭.即一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化. 开闭原则的好处 开闭原则是一个最基本的原则,另外五个原则都是开闭原则的具体形态,是指导设计的工具和方法,而开闭原则才是精神领袖. 开闭原则有利于进行单元测试 开闭原则可以提高复用性 开闭原则可以提高可维护性 面向对象开发的要求 开闭原则的使用 1.抽象约束 通过接口或抽象类约束扩展,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的 不能有两个不同的变化出现在同一个接口或抽象类中.封装变化,找出预计的变化或不稳定的点,为这些变化点创建稳定的接口,准确的讲是封装可能发生的变化.23个设计模式都是从各个不同的角度对变化进行封装的. ---- 开闭原则也只是一个原则 ,实现拥抱变化的方法很多,并不局限于这6大设计原则,但是遵循着6大设计原则基本上可以应对大多数变化.
1.5K50发布于 2019-07-25 - 来自专栏Linyb极客之路
优秀架构师必须了解的6大方面30条设计原则
架构师负责对工程师设计的架构进行修复、完策划和改进。我们的架构团队是指导员和把关人，而非独裁者。 在短期内，由一位架构师来制定架构的确既快捷又实惠。 但是，从长远来看，我们会组建一个团队，让他们自己不断思考、改善架构，并从他们的错误中来提升自己。 当我们专注于团队时，他们自然会随着时间的推移而变得更好。架构团队的首要任务是：尽可能保证架构容易执行。 原则6：了解用户并相应地平衡资源。大多数产品都有数千个最终用户，大致需要20个开发人员和100个 DevOps 人员。 原则23：最好的产品应当不需要用户手册，用户应该一看就会用。 原则24：当你无法在两个选项之间做出决定时，请不要通过配置选项的方式来呈现问题。这会给用户和架构师带来麻烦。 总结 作为一个架构师，我们应该像园丁一样思考、塑造、策划和去除杂草而不是定义和构建。虽然在短期内，由一位架构师来制定架构的确既快捷又实惠。但是，从长远来看，团队的力量才是最强的。
1.6K20编辑于 2022-01-07 - 来自专栏正则
架构师之路 - SOLID设计原则
SRP 单一职责原则 OCP 开闭原则 LSP 里氏替换原则 ISP 接口隔离原则 DIP 依赖反转原则 在架构之路上和代码设计上，我们一定要明白上面的几个原则，在这几个原则的指导下，才能设计出优良的架构 SRP 单一职责原则 SRP是五大原则里最容易被误解的一个，很多程序员根据SRP这个名字想当然的认为这个原则就是指：每个模块都应该只做一件事。 所以这个类违背了 单一职责原则 原则。 这个原则是软件设计，系统架构中非常重要的原则。 当学习完设计原则后，我发现依赖反转原则，其实是其他几个原则的综合，接口的设计保证了单一职责原则，依赖反转的部分实现也满足了开闭原则,通过抽象进行约束很大程度上也是一种里氏替换原则,接口的设计又实现各个接口的隔离
43810发布于 2021-09-04 - 来自专栏互联网大杂烩
6大设计原则
打算用一句话概括每一个设计原则 单一职责原则 一个类只负责一项职责，有且仅有一个原因引起类的变更。 里氏替换原则 所有引用基类的地方必须能透明地使用其子类对象。 依赖倒置原则 高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不依赖细节，细节应该依赖抽象。 也就是面向接口编程。 接口隔离原则 类间依赖应该建立在最小接口上。 开闭原则 一个软件实体如类，模块和函数，应该对扩展开放，对修改关闭。
44430发布于 2018-08-22 - 来自专栏烟草的香味
6大设计原则之里氏替换原则
降低代码的灵活性.子类必须拥有父类的属性和方法,让子类自由的世界中多了些约束 增强了耦合性.当父类的常量、变量和方法被修改时,需要考虑子类的修改,有时更会带来非常糟糕的结果--大段代码需要重构 里氏替换原则的定义 里氏替换原则的规范(继承的规范) 1.子类必须完全实现父类的方法 例如有一个打枪的游戏,类图如下 ? 其 Soldier 代码如下 ? 而是重载,因为输入参数不同 父类的参数范围小,当调用子类 doSomething方法时,若参数为HashMap调用父类方法,若为Map调用子类方法 要是反过来,子类的 参数比父类范围下,就违背了里氏替换原则 4.覆写或实现父类的方法是输出结果可以被缩小 这个也不难理解,也就是说父类方法返回的是Map时,子类可以返回HashMap 但是反过来,父类返回的是HashMap,而子类返回Map类型就违背了里氏替换原则 采用里氏替换原则的好处 增强程序的健壮性,版本升级是也可以保持非常好的兼容性.即使增加子类,原有的子类还可以继续运行.在实际项目中,每个子类对应不同的业务含义,使用父类作为参数,传递不同的子类完成不同的业务逻辑
87320发布于 2019-07-25 - 来自专栏烟草的香味
6大设计原则之接口隔离原则
接口隔离原则的定义 什么是接口. 接口隔离原则的实现 比如现在有一个人,他身兼数职,是一个老师,要教书,是一个学生,要学习,类图如下: ? 接口的规范约束 接口要尽量小,这是接口隔离原则的核心定义,但是"小"是有限度的,首先就是不能违背单一职责原则. . ---- 接口隔离原则就是对接口的定义,同时也是对类的定义,接口和类尽量使用原子接口或原子类来组装.
92010发布于 2019-07-25 - 来自专栏烟草的香味
6大设计原则之依赖倒置原则
依赖倒置原则的定义 依赖倒置原则的原始定义如下: High level modules should not depend upon low level modules. 依赖倒置原则在Java语言中表现为: 模块间的依赖通过抽象产生,实现类之间不发生直接依赖,其依赖关系是通过接口或抽象类产生的 接口或抽象类不依赖于实现类 实现类依赖接口或抽象类 依赖倒置原则的好处 采用依赖倒置原则可以减少类间的耦合性 任何类都不应该从具体类派生 尽量不要覆写基类的方法 结合里氏替换原则(父类出现的地方,子类就可以出现),例如,接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现 ,实现类精确的实现业务逻辑同时在适当的时候对父类进行细化 ---- 依赖倒置原则是6个设计原则中最难以实现的原则,他是实现开闭原则的重要途经,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭.在项目中 ,只要记住是"面向接口编程"就基本抓住了依赖倒置原则的核心
76130发布于 2019-07-25 - 来自专栏编程之禅
架构师内功心法之设计原则
一.架构师内功心法之设计原则 1.为什么要学习软件架构设计原则 1.1.课程目标 通过对节课内容的学习，了解设计原则的重要性。 掌握七大设计原则的具体内容。 Principle 单一职责原则 第4章 Interface Segregation Principle 接口隔离原则 第5章 Law of Demeter 迪米特法则 第6章 Liskov Substitution 所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。 开闭原则，是面向对象设计中最基础的设计原则。 我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更 的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。 总结 接口隔离原则和单一职责原则区别？ 总结 多用聚合组合代替继承原则 1.4.设计原则总结 学习设计原则，学习设计模式的基础。
69530发布于 2020-08-12 - 来自专栏大数据架构师成长之路
数据架构师成长思考总结
建立中心 当我们接手一个业务需求、面对一项挑战的时候，应当先思考这个需求的核心目标是干嘛的。 （价值的维度） 一个团队接手某项业务或需求，其背后都会有思考：我们是期望借着这个业务打造一个平台，提升整体行业的表现；还是突击这个业务方向，占领局部的商业蓝海······ 接到一个需求时一定要思考更大层面这事的价值 整体思想是 MECE（Mutually Exclusive Collectively Exhaustive）原则，即相互独立，完全穷尽不重叠、不遗漏的分类。 指的是找出事情发生的内在逻辑，思考的时候可以逻辑顺序作为参考。 我们在思考、做事、成长时应当随时使用，对于梳理复杂问题、进行决策支撑都有很大好处。
94940发布于 2020-07-08 - 来自专栏芋道源码1024
架构师应该遵守的编程原则
KISS（Keep It Simple Stupid） KISS原则是英语 Keep It Simple, Stupid 的首字母缩略字，是一种归纳过的经验原则。 KISS 原则是指在设计当中应当注重简约的原则。 说明这个原则最好的实例，是约翰逊向一群设计喷射引擎飞机工程师提供了一些工具，他们所设计的机具，必须可由一名普通机械师只用这些工具修理。 另外相类似的概念也可作 KISS原则的起源。 最少意外原则：程序代码应尽可能的不要让阅读者感到意外。也就是说应该遵循编码规范和常见习惯，按照公认的习惯方式进行组织和命名，不符常规的编程动作应该尽可能的避免。 如何把Kiss原则应用到工作中？
50720编辑于 2022-08-29 - 来自专栏烟草的香味
6大设计原则之单一职责原则
单一职责原则 如果有一个用户管理类,类图如下 ? 其实,在实际使用中我们更倾向于使用两个不同的接口: 一个IUserBO,一个IUserBiz 单一职责原则定义 应该有且仅有一个原因引起类的变更 单一职责原则的好处: 类的复杂性降低,实现什么职责都有清晰明确的定义 可读性提高了,当然更容易维护了 变更引起的风险降低.变更是必不可少的,如果接口的单一职责做的好,一个接口修改只对相应的实现类有影响,对其他类无影响,这对系统的扩展性、维护性都有非常大的帮助 ---- 单一职责原则适用于接口 、类,同样也适用于方法. ---- 单一职责原则是非常优秀的,但是在实际使用中受很多因素的制约 建议,接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化
49130发布于 2019-07-25 - 来自专栏代码世界
6大设计原则总结
6大设计原则总结 一、单一职责原则 单一职责原则：英文名称是Single Responsiblity Principle，简称是SRP。定义：应该有且仅有一个原因引起类的变更。 那才是完全解耦，在实际的项目中，需要适度地考虑这个原则，别为了套用原则而做项目。 原则只是供参考，如果违背了这个原则，项目也未必会失败，这就需要大家在采用原则时反复度量，不遵循是不对的，严格执行就是“过犹不及”。 一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。 其次，开闭原则是最基础的一个原则，前面介绍的原则都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖。
1K90发布于 2018-04-12 - 来自专栏开源社
Apache架构师的30条设计原则！
| 作者：Srinath | 编辑：Corrie | 来源：ImportSource Srinath 通过不懈的努力最终总结出了30条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门 Srinath 认为架构师应该扮演的角色是一个引导者，讨论发起者，花草修建者，而不是定义者和构建者。 Srinath 为了解决团队内部的架构纷争和抉择，制定了以下30条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。 原则5：时刻要想投入产出比（ROI）。就是划得来不。 原则6：了解你的用户，然后基于此来平衡你需要做哪些事情。不要花了几个月时间做了一个devops用户界面，最后你发现那些人只喜欢命令行。 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。 *部分图片来源于网络 ? ?
42610发布于 2019-08-15 - 来自专栏漫谈测试
测试架构师领导力的原则
测试架构师的领导力是建立在把握和执行的某些原则上---信任，认知，安全，清晰度等要素，如下图。 既然如此，架构师需要不同的视角来容纳他们。对某种解决方案的特定模型抽象出关键点，这是支撑该架构的主要技能。三、通过关系带来安全称为成功的测试架构师通常取决于你建立战略伙伴的能力。 尽管你能够作为架构师影响产品的认知，但你往往不是产品认知的拥有者。作为架构师，你要对产品的商业认知有彻底的了解。你最终负责将其转换为技术现实。 四、要身体力行，以身作则对于任何给定的项目，你期望团队的成员遵循某些原则，如果你期望团队透明，你的做法该对团队透明。透明化。见什么人说什么话。保持开放、诚实的胸襟。做事正直。 最棒的架构师有一些在其架构知识范围内的技能，所以有些时候“身体力行”在技术上本质也是如此。遵循这种原则，你就会从另一方面看待问题。
30110编辑于 2024-08-17 - 来自专栏全栈程序员必看
Python6大设计原则
内容总览 六大设计原则都有哪些 一、单一职责原则 二、里氏替换原则 三、依赖倒置原则 四、接口隔离原则 五、迪米特法则 六、开放封闭原则 内容详解 一、单一职责原则 单一职责原则：英文名称是Single 那才是完全解耦，在实际的项目中，需要适度地考虑这个原则，别为了套用原则而做项目。 原则只是供参考，如果违背了这个原则，项目也未必会失败，这就需要大家在采用原则时反复度量，不遵循是不对的，严格执行就是“过犹不及”。 一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。 其次，开闭原则是最基础的一个原则，前面介绍的原则都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖。
61930编辑于 2022-07-21 - 来自专栏小樱的经验随笔
设计模式六大原则（6）：开闭原则
开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。 在仔细思考以及仔细阅读很多设计模式的文章后，终于对开闭原则有了一点认识。其实，我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则。 也就是说，只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；如果前面 在上图中，设计1、设计2属于良好的设计，他们对六项原则的遵守程度都在合理的范围内；设计3、设计4设计虽然有些不足，但也基本可以接受；设计5则严重不足，对各项原则都没有很好的遵守；而设计6则遵守过渡了，设计 5和设计6都是迫切需要重构的设计。
1.1K70发布于 2018-04-08 - 来自专栏java思维导图
架构师必须掌握的 10 条设计原则
01 遵循单一职责原则 函数是程序员的工具中最重要的抽象形式。它们能更多地被重复使用，你需要编写的代码就越少，代码也因此变得更可靠。较小的函数遵循单一职责原则更有可能被重复使用。 点击这里查看 6 大设计原则。 06 对模块应用良好的原则 寻找机会将软件项目分解成更小的模块（例如库和应用程序），以促进模块级别的重用。 对于模块，应该遵循的一些关键原则是： 1.尽可能减少依赖 2.每个项目应该有一个明确的职责 3.不要重复自身 你应该努力使你的项目保持小巧和明确。 08 将测试作为设计和开发的一部分 我不是测试驱动开发的坚定分子，但开始编码时先编写测试代码会使得代码十分自然地遵循许多指导原则。这也有助于尽早发现错误。 你还知道别的设计原则吗？欢迎留言！
48430发布于 2018-10-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号