- 综合排序
- 最热优先
- 最新优先
- 来自专栏大宇笔记
iOS 工厂设计模式解耦和
如果耦合代码过多更换的时候，代码处理很复杂，如果在需求设计和预研的时候就知道了更换的模块内容，不妨自己设计封装下，更换的时候可以一键替换。 刚开始我也是那么想的，然而在项目中需求模块，和SDK大规模的耦合的时候，你就要写很多的判断，做很多的切换，如果用工厂的设计模式就能避免集成的耦合，面向对象思想，把任务更细分到更多的对象手中，责任对象更明显 1.1 工厂设计模式 在面向对象编程中, 最通常的方法是一个new操作符产生一个对象实例,new操作符就是用来构造对象实例的。但是在一些情况下, new操作符直接生成对象会带来一些问题。 引自：工厂设计模式 1.2 Demo讲解 目的：我们要造人，有时候需要只造男人，有时候又想制造女人，实现集成自由切换。 代码思路： 首先我们要造人，不管男人或者女人，都要遵守人的协议标准。
70830发布于 2019-01-15 - 来自专栏花落的技术专栏
Flutter 解耦
uncoupling使用了标记的方式，直接操作文件代码以实现代码物理方式的灵活插入与抽取，对工程没有任何侵入性，简单易用。
72830编辑于 2021-12-15 - 来自专栏知了一笑
复杂任务中，流程的解耦设计
复杂流程，得一步异步的来； 一、业务场景 在系统开发的过程中，必然存在耗时极高的动作，是基于请求响应模式无法解决的问题，通常会采用解耦的思维，并基于异步或者事件驱动的方式去调度整个流程的完整执行； 文件任务 2、异步解耦模式 异步模式的最大优点就是实现请求和响应的完全解耦，任务只需要触发一次开始动作，后续的流程就会逐步的推进直到结束；各个服务节点处理逻辑不会受到整个请求链路的耗时限制； 实现异步有多种方式 ，服务间通过消息传递的方式，依次处理库存服务、物流服务等；由于事件携带了一定的业务信息和状态，流程解耦更加彻底的同时复杂度也会更高。 四、实践总结 1、结构设计 在结构设计中围绕任务、节点、数据三个核心要素，以确保对任务的执行过程有完整的跟踪和管理，要实现对任务的节点及相关的操作，具备执行重试或者直接取消撤回的控制； 状态管理是一项很复杂的工作 4、组件案例 Spring框架本身就极具复杂度，这里单看事件模型的设计，包含三个核心角色：事件、发布、监听；与观察者设计模式在理念上相同； 事件：ApplicationEvent基础抽象类继承自JDK
1.5K10编辑于 2022-06-14 - 来自专栏Rice嵌入式
框架解耦神器 -- REventBus
对通信双方做到完全解耦。 使用RThread pool灵活切换工作线程，一定程度提供了事件处理效率 支持同步事件发布，和异步事件发布。 资源占用极小。 缺点： 当业务多的时候，需要定义很多事件类型。
42450编辑于 2023-06-01 - 来自专栏look Java
Event事件传递 解耦
Event事件传递 解耦 spring中创建bean后，我们在完成对一个bean的操作后，我们希望把运行后的bean结果同步传递给另一个bean。
23810编辑于 2023-12-07 - 来自专栏张善友的专栏
认证系统（Authentication）与权限系统（Authorization）解耦设计
在系统设计中一个常见的认知误区——权限系统（Authorization）和认证系统（Authentication）本质上是两个独立的安全边界，但常因架构耦合被混为一谈。 OAuth/生物识别 RBAC/ReBAC/ABAC策略引擎 输出结果 用户标识符（如：user_id） 权限决策（Allow/Deny） 失效场景 凭证泄露 → 冒充风险 策略错误 → 越权操作 一、解耦实践方案 架构分层设计 认证服务：仅负责生成身份令牌（如JWT中的sub字段） 权限服务：独立微服务，接收user_id+动作+资源，返回布尔值 1.2.
29710编辑于 2025-09-08 - 来自专栏Rice嵌入式
框架解耦神器 -- REventBus
对通信双方做到完全解耦。 使用RThread pool灵活切换工作线程，一定程度提供了事件处理效率 支持同步事件发布，和异步事件发布。 资源占用极小。 缺点： 当业务多的时候，需要定义很多事件类型。
38520编辑于 2023-09-02 - 来自专栏TechFlow
原创 | 详解command设计模式，解耦操作和回滚
大家好，欢迎来到周五设计模式专题，我们的主旨是介绍一些有趣好玩的设计模式。 今天我们介绍的设计模式叫做命令模式(command)，在这个模式下，我们可以实现do和undo的解耦，让使用方不用关心内部的实现细节。 _command.undo() 这样我们的UI就和command解耦了，如果我们想要实现不同的可以回滚的功能， 只需要实现不同的command创建实例就可以了。
47520发布于 2020-09-22 数据库解耦，代码复用？还是数据库复用，代码解耦？
以上称之为解耦数据库一拆分就是解耦了。但是逻辑上来说原来在一起是有道理的，现在分开就是解除耦合了吗？有没有可能他本身就是要耦合的？问题来了很多长流程的业务，被切割成多个数据库。 如果说遇到问题，要解耦，你会发现根本解不开。最底层的是包罗万象的。一动影响全局。这就是典型的双标。在企业管理中，去申请权限一般来说，给一个最小的，然后逐步放开。 但是这个公共组件做的大而全，无法解耦。上来先运算100个。最后99%都是无用功。小结个人观点：代码应该解耦，数据库不应该。因为有时候用着用着数据就要发生联系了。
22110编辑于 2025-07-24- 来自专栏coderhuo
日常工作中的设计：解耦和封装
一、问题提出 二、优化方案 本文介绍日常工作中模块间解耦，并抽象封装的一个例子。 （这里类似设计模式中的策略模式） 从团队分工协作的角度考虑： DSP只负责出H264数据流，APP层负责业务的多样性，二者都更加聚焦； 类似业务扩展不再需要DSP参与，协作链变短了，开发效率变高
1.3K30发布于 2020-08-02 - 来自专栏魔术师卡颂
使用IOC解耦React组件
IOC（控制反转）是一种编程思想，可以解耦组件，提高组件复用性。 改造后的依赖关系： 士兵 --> 武器库 <-- 武器 改造后应用（士兵）与服务提供方（武器）解耦，他们通过IOC容器（武器库）联系。 所以说，合理使用React可以充分利用IOC的思想解耦代码逻辑。 接下来我们看看专业的DI库如何与React结合： InversifyJS InversifyJS[1]是一个强大、轻量的DI库。 ? 业务逻辑的更多依赖都可以通过注入IOC容器来实现解耦。
1.1K10发布于 2021-03-15 - 来自专栏蓝天
巧用NULL模式解耦依赖
由于需求的变化，应用B需要库libM.a的能力，以便和服务M交互。为了复用和简化，通过类A间接提供，应用B不用修改代码，只需要重新编译即可获得新的能力，其它用到类A的应用也是如此。
60930发布于 2018-09-30 - 来自专栏SDNLAB
解耦重构 Internet BGP SDN
现有的互联Peering网络是依赖于BGP设计的。 并且解耦了传统Peering路由器，演进为Peering Fabric和服务器集群（提供反向Web代理）。 2.3 解耦Peering Router 演进到Peering Fabric Espresso 另一个主要的设计原则是解耦路由器，演变成Peering Fabric。 通过Espresso，Google改造/解耦了Peering/ASBR路由器，通过把大部分软件控制功能移到服务器。 ，但是开发工作量也是巨大， Google为Espresso开发了很多全新组件： { 全新层次化SDN控制器GC/LC，全新BGP协议Raven实现，全新主机IPv4/IPv6 转发表， 全新路由器解耦
2.5K41发布于 2018-10-24 - 来自专栏音视频专栏
装饰者解耦的秘诀
装饰者解耦的秘诀 组合优于继承原则是个很棒的想法，可以解决继承的地狱。 然而，几乎没有库、示例代码或者教程来教你如何在 Android 上实现这原则。 这里思考一下我们如何站在前人的肩膀上去做。 protected void onStop() { } protected void onDestroy() { } } 这里装饰器里面持有了被装饰者的实例，看样子并没有有效的解耦和 更多的例子 总结一下，这里装饰者实际上跟真正的装饰者设计模式还是有很大的区别，首先bind的时候装饰者中耦合了被装饰者，而设计模式中的装饰器只是依赖接口。所以这里的装饰者，更像是LifeCycle。 4、设计模式中的装饰者模式 装饰者模式指的是在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰者来包裹真实的对象。 4.2 装饰者模式 UML 图解 装饰者模式 例子如下 Java 设计模式之装饰者模式 image.png 可以看到，被装饰者和装饰器通过功能的抽象Compoent来解开耦合，显然这里的装饰者有很大区别
1.1K40发布于 2020-04-08 - 来自专栏明志德到的IT笔记
代码中的解耦思维
解耦思维是一种设计和思考问题的方法，旨在将复杂的系统或问题拆分为独立的组件或子问题，以降低系统的耦合度和提高可扩展性。以下是一些关于解耦思维的要点： 1. - 使用依赖注入等技术来解耦模块之间的依赖关系。 通过合理地设计和应用解耦思维，可以提高软件系统的质量和可维护性，并降低开发和维护成本。 中间层映射解耦 中间层映射是一种常见的解耦设计模式，它可以在系统中引入一个中间层来解耦不同组件之间的直接依赖关系。这种设计模式在DNS和CDN中都有应用。 1. 解耦技术的演化 解耦的技术演化是一个持续发展的过程，随着软件开发和系统设计的不断进步，出现了许多技术和方法来实现解耦。以下是一些常见的解耦技术演化： 1. 接口和抽象类：接口和抽象类是实现解耦的基础。 应用架构中的解耦 在应用架构中，解耦是一种重要的设计原则，旨在降低不同组件之间的依赖关系，提高系统的灵活性、可扩展性和可维护性。以下是应用架构中常见的解耦方法： 1.
1.4K10编辑于 2023-12-31 - 来自专栏用户10106051的专栏
编程思想里面，何谓解耦？
核心思想主要涉及到两个方面： 一、模块解耦：模块解耦指的是将系统分解为更小的、独立的模块或组件，每个模块负责一个明确定义的功能。 这其实本质就是模块解耦思想的体现。 （多module示例图） 二、时间解耦：时间解耦指的是系统中的不同部分不应该过于依赖彼此的执行顺序。 我们也知道它的三大核心特性：异步、解耦、消峰。 这里的解耦指的就是时间维度上的解耦。 生产者压根不需要知道消费者应用的存在。它尽管只要往指定通道发送消息即可。消费者应用如果想要数据，订阅就好。 综上，解耦是面向对象设计和软件架构中的重要原则之一，有助于构建更灵活、可维护和可扩展的软件系统。
1.4K10编辑于 2023-12-20 - 来自专栏产品的技术小课
产品经理 ｜ 什么是解耦？
在理解解耦之前，我们先来理解耦合度。耦合度是软件工程领域的概念，是指模块之间的依赖程度。 这里的模块可以小到一个小功能，也可以大到一个系统。 那么对应的，解耦就是解除模块之间的耦合关系。 降低模块之间的依赖程度也可以理解为解耦，模块之间有依赖关系就必然存在耦合， 0耦合是基本无可能的，那是最理想的状态。 耦合度越低，模块之间依赖的程度越低，模块的独立性、复用性和可移植性就越强。 如果把A产品的基础功能和搜索推荐功能解耦，各司其职，分开2个独立的模块，以后任何产品想接入搜索推荐功能的话，按照接入标准接入即可。 小结：如果很难降低2个模块的耦合度，那么可能是模块之间职责分工不合理、调用方式有问题、或者设计模式不合理等等。 --- end ----
4.1K10编辑于 2022-09-02 - 来自专栏深度学习和计算机视觉
孤立卡尔曼滤波（IsoKF）：理论与解耦估计器设计
本研究提出了一种新的 孤立卡尔曼滤波（Isolated Kalman Filtering, IsoKF） 方法，旨在在状态估计问题中实现 状态解耦，特别是当个体估计的动力学是解耦的，但输出之间存在稀疏耦合时 由于 IsoKF 需要解耦计算，因此采用 最大行列式补全（MDC） 近似缺失的协方差： 这一近似方法确保了估计的可行性，但可能导致轻微的估计偏差。
24400编辑于 2025-02-26 - 来自专栏CoderStar
设计模式 - 命令模式&中介者模式&组合模式~AppDelegate 解耦
本周主要给大家分享的内容是三种设计模式 (命令模式、中介者模式以及组合模式) 及其它们在AppDelegate解耦场景下的应用，特别是组合模式，沉淀出相应的轮子分享给大家。 同时给大家推荐一个学习设计模式的好网站--深入设计模式[2]，文章中涉及的部分 UML 图也来自该网站。 下面我们利用上述三种设计模式实现对AppDelegate的解耦，使其优雅。 命令模式 命令模式（Command） 是一种 行为设计模式，它可将请求转换为一个包含与请求相关的所有信息的独立对象。 对该套解耦方案进行完善，沉淀出的轮子地址为ApplicationServiceManager[4]。功能比较轻量级，欢迎大家使用。 关于AppDelegate的解耦其实还有阿里的BeeHive[5]，不过其是一个综合的组件化方案，AppDelegate的事件分发只是其一部分。
84720编辑于 2022-09-23 - 来自专栏TechBox
模块化与解耦（转）
模块化开发有哪些优点和缺点 解耦与通信 1.为什么要做模块化？ 解耦与通信 我先说说为什么要解耦吧，模块化并不是说你把工程的代码拆分成 50 个 pod 或者framework就算完事了，要实现模块之间真正的解耦才算真正的模块化，否则如果模块之间还都是互相调用代码， 那么什么是模块间的解耦呢？ *** 模块解耦的目标就是, 在基于模块设计原则上, 让模块之间没有循环依赖, 让业务模块之间解除依赖。 模块做出一些设计，添加一些注册型Api，修改JSBridge的服务为可以通过注册的方式添加逻辑，这样来实现与业务解耦，业务完全可以把与自己业务相关的代码放在自己的模块里面，然后通过你设计的Api注册到WebView 2、 我自己写的一个解耦框架 AppLord. 简单介绍一下几个概念。
7.8K40发布于 2018-06-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号