- 综合排序
- 最热优先
- 最新优先
- 来自专栏技术知识总结
Java的先行发生原则
先行发生原则（Happens-Before）是Java内存模型定义的一个等效判断原则。 依赖这个原则，我们可以通过几条简单规则判断数据是否存在竞争，线程是否安全，而不需要陷入Java内存模型苦涩难懂的定义之中。---“先行发生”原则指的是什么。 下面是Java内存模型下一些“天然的”先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。 Java 语言无须任何同步手段保障就能成立的先行发生规则有且只有上面这些。---“时间上的先后顺序”与“先行发生”之间有什么不同？一个操作“时间上的先发生”不代表这个操作会是 “先行发生”。 时间先后顺序与先行发生原则之间基本没有因果关系，所以我们衡量并发安全问题的时候不要受时间顺序的干扰，一切必须以先行发生原则为准。
44630编辑于 2023-06-05 - 来自专栏Java成长之路
先行发生原则(happens-before)介绍
“先行发生”（happens-before）的原则。 一、什么是先行发生原则 现在就来看看“先行发生”原则指的是什么。 6. ，根据程序次序规则，“int i=1”的操作先行发生于“int j=2”，但是“int j=2”的代码完全可能先被处理器执行，这并不影响先行发生原则的正确性，因为我们在这条线程之中没有办法感知到这点。 上面两个例子综合起来证明了一个结论：时间先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。
3.1K20发布于 2018-09-29 - 来自专栏云霄雨霁
Java虚拟机--先行发生原则
先行发生”原则。 先行发生是Java内存模型中定义的两项操作数之间的偏序关系，如果说操作A先行发生于操作B，就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等 线程启动规则 ：Thread对象的start方法先行发生于此线程的每个动作； 线程终止规则 ：线程中的所有操作都先行发生于对此线程的终止检测； 线程中断规则 ：对线程的interrupt()方法的调用先行发生于被中断线程的代码检测到中断时间的发生 ； 对象终结规则 ：一个对象的初始化完成先行发生于它的finalize方法的开始； 传递性 ：如果操作A先行发生于操作B，操作B先行发生于操作C，那么，操作A也就先行发生于操作C。 依次分析一下先行发生原则中的各个原则：由于两个方法分别在不同的线程中被调用，程序次序原则不适用；没有同步块，自然不会发生lock和unlock操作，管程锁定原则不适用；value变量没有被volatile
61060发布于 2018-05-22 - 来自专栏JavaEdge
Happens-beofre 先行发生原则（JVM 规范）
)原则 这个原则非常重要，它是判断数据是否存在竞争，线程是否安全的主要依赖。 先行发生原则 指的是JMM中定义的两项操作之间的依序关系 happens- before关系 主要用于强调两个有冲突的动作之间的顺序，以及定义数据争用的发生时机 如果说操作A先行发生于操作B，就是在说发生 线程中断规则(Thread Interruption Rule) 对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted() A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论 一个操作”时间上的先发生“不代表这个操作会是”先行发生“，那如果一个操作”先行发生“是否就能推导出这个操作必定是”时间上的先发生 也是不成立的，一个典型的例子就是指令重排序 所以时间上的先后顺序与先行发生原则之间基本没有什么关系，所以衡量并发安全问题一切必须以先行发生原则为准。
60310发布于 2021-02-22 - 来自专栏韩曙亮的移动开发专栏
【Java 并发编程】指令重排序规范 ( happens-before 先行发生原则 )
文章目录 一、指令重排序规范 二、happens-before 先行发生原则 一、指令重排序规范 ---- 指令重排指的是 , 线程中如果两行代码 没有逻辑上的上下关系 , 可以对代码进行 重新排序 ; 规范 : 先行发生原则 ; 二、happens-before 先行发生原则 ---- happens-before 先行发生原则 : A happens-before B , A 先于 B 发生 , 使用 指令重排 ; happens-before 先行发生原则 适用场景 : 在以下场景中 , 不进行指令重排 , 这些先后顺序 , 绝对不能被打乱 , 否则会出现严重线程安全问题 ; 程序次序原则 检测到 中断时 事件的发生 ; 必须先发生中断 , 然后才能被检测到 ; 不能还没发生中断 , 就可以检测到中断发生 ; 对象终结 : 对象的创建 先于 对象的终结 , 创建就是调用构造函数 , 终结就是调用 finalize 方法 ; 只要符合上述规则 , 不需要进行同步 , 就可以成立 ; 通过 " happens-before 先行发生原则 " 可以判定两个线程的操作 , 是否有发生冲突的可能 ;
45410编辑于 2023-03-29 - 来自专栏无原型不设计
什么是“移动先行”原则，如何践行？
2010年的全球移动通信大会上，谷歌时任首席执行官Eric Schmidt 提出：产品设计应遵循 “移动先行” 的原则。 该原则具体指什么？遵循该原则的依据有哪些？为什么它在产品设计中如此重要？ 一、什么是“移动先行” 原则？ 为了更好地理解该原则，首先要了解两个概念： 1. 响应式网页设计（RWD） 一种网页设计方法。 因为“移动先行”原则，就是“逐步增强” 策略的一个具体表现形式。 “移动先行”，顾名思义，即在设计多终端产品时，首先设计限制较多的移动端版本，再一步步向高级终端迈进。 ? 二、为什么在产品设计中，“移动先行”的原则如此重要？ 除了以上提到的“逐步增强”的设计策略的可操作性更强外，“移动先行”原则其实还具有强大的现实基础：移动端需求的爆炸式增长。 移动端需求的爆炸式增长，要求设计师在进行产品设计时，重视产品的移动端版本，遵从 “移动先行” 的设计原则。 三、如何在产品设计中践行移动先行原则？
1.7K40发布于 2018-03-16 - 来自专栏烟草的香味
6大设计原则之开闭原则
开闭原则的好处 开闭原则是一个最基本的原则,另外五个原则都是开闭原则的具体形态,是指导设计的工具和方法,而开闭原则才是精神领袖. 开闭原则有利于进行单元测试 开闭原则可以提高复用性 开闭原则可以提高可维护性 面向对象开发的要求 开闭原则的使用 1.抽象约束 通过接口或抽象类约束扩展,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的 不能有两个不同的变化出现在同一个接口或抽象类中.封装变化,找出预计的变化或不稳定的点,为这些变化点创建稳定的接口,准确的讲是封装可能发生的变化.23个设计模式都是从各个不同的角度对变化进行封装的. - --- 开闭原则也只是一个原则,实现拥抱变化的方法很多,并不局限于这6大设计原则,但是遵循着6大设计原则基本上可以应对大多数变化. 项目规章非常重要 预知变化,在实践过程中,一旦发现有发生变化的可能,或者变化曾经发生过,就需要考虑现有的架构是否可以轻松的实现这一变化.
1.4K50发布于 2019-07-25 - 来自专栏全栈程序员必看
设计模式之6大原则(6)开闭原则
开闭原则（OCP） 是 面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之中的一个，其他非常多的设计原则都是实现开闭原则的一种手段。 开闭原则中“开”，是指对于组件功能的扩展是开放的，是同意对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的改动是封闭的，即不应该改动原有的代码。 遵循开闭原则设计出的模块具有两个主要特征： （1） 对于扩展是开放的（Open for extension）。这意味着模块的行为是能够扩展的。 模块的二进制可运行版本号，不管是可链接的库、DLL或者.EXE文件，都无需修改。 实现开闭原则的关键就在于“抽象”。 在20世纪90年代，开闭原则被广泛的又一次定义因为抽象化接口的使用，在这中间实现能够被改变，多种实现能够被创建，而且多态化的替换不同的实现。相比梅耶的使用方式，多态开闭原则的定义倡导对抽象基类的继承。
61221编辑于 2022-07-09 - 来自专栏互联网大杂烩
6大设计原则
打算用一句话概括每一个设计原则 单一职责原则 一个类只负责一项职责，有且仅有一个原因引起类的变更。 里氏替换原则 所有引用基类的地方必须能透明地使用其子类对象。 只要父类能出现的地方子类就可以出现。 依赖倒置原则 高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不依赖细节，细节应该依赖抽象。 也就是面向接口编程。 接口隔离原则 类间依赖应该建立在最小接口上。 接口尽量细化，接口的方法尽量少。 迪米特法则（最少知识法则） 一个对象对其他对象了解越少越好，也就是一个类应该对自己需要耦合或调用的类知道得最少。 开闭原则 一个软件实体如类，模块和函数，应该对扩展开放，对修改关闭。
39330发布于 2018-08-22 - 来自专栏烟草的香味
6大设计原则之接口隔离原则
接口隔离原则的定义 什么是接口. 接口隔离原则的实现 比如现在有一个人,他身兼数职,是一个老师,要教书,是一个学生,要学习,类图如下: ? 如果有一天,他不在教书了,或者又有了新的职业,那我们还要修改调用该类的代码,更好的做法是将臃肿的接口变更为几个独立的接口 ? 接口的规范约束 接口要尽量小,这是接口隔离原则的核心定义,但是"小"是有限度的,首先就是不能违背单一职责原则. . ---- 接口隔离原则就是对接口的定义,同时也是对类的定义,接口和类尽量使用原子接口或原子类来组装.
87310发布于 2019-07-25 - 来自专栏烟草的香味
6大设计原则之里氏替换原则
变量和方法被修改时,需要考虑子类的修改,有时更会带来非常糟糕的结果--大段代码需要重构 里氏替换原则的定义 如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1 都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型. 里氏替换原则的规范(继承的规范) 1.子类必须完全实现父类的方法 例如有一个打枪的游戏,类图如下 ? 其 Soldier 代码如下 ? ,将声音、形状都委托给 AbstractGun 处理,然后两个基类下的子类自由延展,互不影响 注意: 如果子类不能完整的实现弗雷的方法,或者弗雷的某些方法在子类中已经发生"畸变",则建议断开父子继承关系 ,而子类返回Map类型就违背了里氏替换原则 采用里氏替换原则的好处 增强程序的健壮性,版本升级是也可以保持非常好的兼容性.即使增加子类,原有的子类还可以继续运行.在实际项目中,每个子类对应不同的业务含义
80320发布于 2019-07-25 - 来自专栏烟草的香味
6大设计原则之依赖倒置原则
依赖倒置原则的定义 依赖倒置原则的原始定义如下: High level modules should not depend upon low level modules. 依赖倒置原则在Java语言中表现为: 模块间的依赖通过抽象产生,实现类之间不发生直接依赖,其依赖关系是通过接口或抽象类产生的 接口或抽象类不依赖于实现类 实现类依赖接口或抽象类 依赖倒置原则的好处 采用依赖倒置原则可以减少类间的耦合性 任何类都不应该从具体类派生 尽量不要覆写基类的方法 结合里氏替换原则(父类出现的地方,子类就可以出现),例如,接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现 ,实现类精确的实现业务逻辑同时在适当的时候对父类进行细化 ---- 依赖倒置原则是6个设计原则中最难以实现的原则,他是实现开闭原则的重要途经,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭.在项目中 ,只要记住是"面向接口编程"就基本抓住了依赖倒置原则的核心
69030发布于 2019-07-25 - 来自专栏烟草的香味
6大设计原则之单一职责原则
单一职责原则 如果有一个用户管理类,类图如下 ? 我想,任谁也能看的出这个接口设计的有问题,用户的属性和用户的行为没有分开,应该把用户的信息抽取成一个业务对象,把用户的行为抽取成一个业务对象,按照这个思路对类图进行修正,如下图所示 ? 其实,在实际使用中我们更倾向于使用两个不同的接口: 一个IUserBO,一个IUserBiz 单一职责原则定义 应该有且仅有一个原因引起类的变更 单一职责原则的好处: 类的复杂性降低,实现什么职责都有清晰明确的定义 可读性提高,复杂性降低了,可读性当然就提高了 可维护性提高,可读性提高了,当然更容易维护了 变更引起的风险降低.变更是必不可少的,如果接口的单一职责做的好,一个接口修改只对相应的实现类有影响,对其他类无影响 ,这对系统的扩展性、维护性都有非常大的帮助 ---- 单一职责原则适用于接口、类,同样也适用于方法. ---- 单一职责原则是非常优秀的,但是在实际使用中受很多因素的制约 建议,接口一定要做到单一职责,
43830发布于 2019-07-25 - 来自专栏代码世界
6大设计原则总结
6大设计原则总结 一、单一职责原则 单一职责原则：英文名称是Single Responsiblity Principle，简称是SRP。定义：应该有且仅有一个原因引起类的变更。 （如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。） 如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。 依赖倒置原则在Java语言中的表现就是： 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的； 接口或抽象类不依赖于实现类； 实现类依赖接口或抽象类。 一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。
97290发布于 2018-04-12 - 来自专栏国产程序员
面向对象的7种设计原则(6)-迪米特原则
迪米特原则 迪米特原则（Law of Demeter）又叫最少知道原则（Least Knowledge Principle），可以简单说成：talk only to your immediate friends 模式与意义 迪米特法则，如果两个类不必彼此直接通向，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个累哦的某一个方法的话，可以通过第三者转发这个调用。 面向对象的设计原则和面向对象的三大特性本就不是矛盾的。迪米特法则其根本思想，是强调了类之间的松耦合。 类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成搏击，也就是说，信息的隐藏促进了软件的复用。 优点 减少对象之间的耦合性 ? 摘自大话设计模式: ? ? ? 注意 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。 在类的结构设计上，尽量降低类成员的访问权限。 在类的设计上，优先考虑将一个类设置成不变类。
70540发布于 2020-08-17 - 来自专栏DevOps持续集成
DevOps推动业务成功的6点原则
当正式投入生产且Dev在进行代码工作时，Ops应该在那里以确保期望的结果并解决在通用框架下出现的任何工作流故障。 ? 但是，除了他们的协作和努力的有效性之外，这是开发量身定制的应用程序的目标。 1协作 开发和运营团队在各自的小隔间里为公司的共同利益编写应用程序已经不是一天了。这种智能过程具有超越开发公司范围的能力。它涵盖了参与应用程序开发，质量保证和接收组织的每个人。 2自动化 DevOps高度依赖于工具的自动化。不是一个，两个或三个而是一个完整的工具链，不仅可以实现自动化，而且可以将不同的团队和参与此过程的其他人员联系起来。 6持续监控 没有办法确保逐步的DevOps流程，它的本质是要求跨开发框架的各个要素相互对话。那么如何处理失败呢？您找到它们并立即对其进行修复，这就是持续监视的目的。 原文链接： https://www.veritis.com/blog/devops-capabilities-a-6-point-principle-that-drives-business-success
43320发布于 2021-04-22 - 来自专栏sylan215 的软件测试技术学习
优先进行测试的 6 条原则
有一次洗完之后，我看到蓬蓬乱乱的，就想着给梳顺了再吹，谁知道这梳子一下去怎么也梳不动，稍微使劲又拽着头发痛，我就犯嘀咕了，这不是刚洗完的头发应该丝滑般顺柔的么？ 要么接受现在的方案，毕竟进度已经推进的差不多了，要么推翻现在的方案，毕竟目前的结果并不是用户需要的。 如果是有如果的话，优先确认需求合理性是不是能发现这个问题？ 这个例子稍微有点极端，因为过程中的漏洞太多了，但是不排除实际没有这样的事情发生。 为了更准确的说明，我就再讲个故事好了。 我大概总结了这么几条原则，仅供参考： 1、优先完成用户实际场景的测试，其他再按需各种测； 2、优先保证需求的合理性，再验证实现的正确性； 3、优先验证实现方案的合理性，再验证实现的正确性； 4、优先测试容易出现问题的地方 看之前的反馈和问题单），再做常规测试； 5、优先功能验证，再做 UI 验证； 6、尽早联调、尽早联调、尽早联调； 以上，我通过三个小故事说明了优先级在做事（测试）过程中的重要性，同时提供了几个优先测试的原则
50440发布于 2020-03-13 - 来自专栏全栈程序员必看
Python6大设计原则
（如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。） ； 如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。 依赖倒置原则在Java语言中的表现就是： 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的； 接口或抽象类不依赖于实现类； 实现类依赖接口或抽象类。 一个软件产品只要在生命周期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。 一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。
55730编辑于 2022-07-21 - 来自专栏小樱的经验随笔
设计模式六大原则（6）：开闭原则
也就是说，只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；如果前面 5项原则遵守的不好，则说明开闭原则遵守的不好。 而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。 在上图中，设计1、设计2属于良好的设计，他们对六项原则的遵守程度都在合理的范围内；设计3、设计4设计虽然有些不足，但也基本可以接受；设计5则严重不足，对各项原则都没有很好的遵守；而设计6则遵守过渡了，设计 5和设计6都是迫切需要重构的设计。
1.1K70发布于 2018-04-08 - 来自专栏小鑫同学编程历险记
【程序设计】6大设计原则之接口隔离原则
这样的接口定义是不利于扩展的，也将对后期的维护带来困扰，我们将通过示例来演示符合接口隔离原则带来的好处。 概念： 接口隔离原则的定义: 客户端不应该被迫依赖于它不适用的方法 接口隔离原则的要求: 将臃肿庞大的接口拆分成更小的和更加具体的接口,保证客户端只得到自己需要的方法 案例： 需求： 设计HomePage 功能支持点击事件：可以跳转到EditPage页面 功能支持双击事件：可以双击后退出程序 设计EditPage页面 功能支持双击事件：可以双击后选择文本 功能支持长按事件：可以长按后选择全部文本 违反原则实现 符合原则实现： 将要原来的接口进行细粒度拆分： 拆分后的接口可以由需要页面有选择的进行自由组合来实现 interface OnClickListener { onClick(): void; } 按照合理的设计进行符合接口隔离原则的拆分对实现代码高内聚，低耦合将变得尤为重要。
41420编辑于 2022-12-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号