二进制君

通过统一的领域模型规范数据结构，并设计简洁的标准化接口，减少接口复杂度。具体做法梳理业务核心概念，定义统一的领域模型（如“用户”“订单”的属性和行为），确保各组件对数据的理解一致。基于领域模型设计接口，避免冗余字段（如接口仅返回必要的“订单ID”“状态”，而非全量信息）。接口版本控制：当业务变化时，通过版本号（如）管理接口迭代，避免频繁修改导致的混乱。优势：组件间基于共识的模型交互，减少沟通成本和接口适配工作量。通信上，通过协调层、事件驱动减少直接依赖；

软件复杂性的本质是**“目标（需求）的不确定性”“实现（技术）的局限性”“协作（团队）的低效性”三者的叠加**。它不是某一个环节的问题，而是从需求定义到系统退役的全生命周期中，各种因素累积的结果。理解这些原因的价值在于：解决复杂性需“对症下药”——需求层面需明确边界，技术层面需控制债务，团队层面需降低沟通成本，最终实现“复杂性可控”而非“完全消除”。

可复用软件的构建本质是组织能力的重构：它需要打破部门壁垒、建立专业化分工、设计合理的激励机制，并借助技术工具实现效率跃迁。尽管初期投入较高，但复用组件的长期价值远超短期成本。正如C++标准库的优秀的复用设计不仅是技术问题，更是战略选择。企业需从“项目制思维”转向“资产化运营”，将复用能力纳入核心竞争力建设，方能在数字化浪潮中实现可持续发展。

库软件的本质是**“基础设施级的复用资产”**：其需求由依赖关系决定，其可靠性由契约和稳定性保障，其价值由易用性体现。这种定位要求库开发必须跳出“单一应用视角”，以“全局复用”为目标，通过专业化团队、严格的设计规范和长期维护，成为支撑整个技术生态的“基石”。正如Linux内核的发展逻辑——“一次做好，持续兼容”，库的价值不在于短期交付，而在于长期降低整个系统的开发与维护成本。

程度需要通过具体的指标和观察点来判断。内聚性指模块内部元素（函数、类、组件）之间的功能相关性。低内聚表现为模块职责分散、功能混杂。耦合度指模块间依赖关系的强度。高耦合表现为模块间直接依赖过多，难以独立修改或替换。通过量化指标和设计原则，可以客观评估系统的内聚和耦合问题，并针对性优化。

而不是在类内部直接创建。依赖注入（DI）是一种实现。

一、核心定义与本质差异自顶向下编程思想如同绘制一幅完整的地图，从整体轮廓逐步细化到局部细节。其本质是从系统的整体目标出发，通过逐层分解将复杂问题简化为可实现的子问题，强调先定义 “做什么”，再考虑 “如何做”。自底向上编程思想则类似于搭建积木，从基础组件开始逐步构建复杂系统。其本质是从现有资源和基础功能出发，通过组合和扩展简单组件来实现复杂功能，强调先解决 “如何做” 的细节，再整合为 “做什么” 的整体。二、设计起点与逻辑流程对比设计起点：以系统的整体目标和业务需求为起点。例如设计一个电商平台，首先明确

工厂方法模式，定义一个用于创建对象的接口（工厂方法），返回对象基类，让子类去实现该接口，从而返回具体的子类对象。结构抽象产品（Product）：定义产品的接口，是工厂方法模式创建的对象的超类型。具体产品（Concrete Product）：实现抽象产品接口的具体类。抽象工厂（Creator）：声明创建产品对象的工厂方法，是工厂方法模式的核心。具体工厂（Concrete Creator）：实现抽象工厂接口，返回具体产品的实例。工作原理。

看下builder模式的官方定义：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。Builder 模式是一种创建型设计模式，旨在通过提供一种更加灵活的方式来构建复杂对象。它允许你分步骤构建对象，同时可以灵活地配置对象的属性和参数。这个模式通常包括以下几个角色：Director（指导者）：负责组织构建过程的顺序，但不负责实际构建对象的细节。客户端通过指导者来构建最终的对象。Builder（构造者）：定义了构建对象的抽象接口，包括构建对象的每个部分的方法。

Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。

Kanban是一种流行的框架，用于实施和软件开发。它需要实时沟通的能力和完全透明的工作。工作内容在Kanban Board上直观地表示，允许团队成员随时查看每项工作的状态。Kanban在当今的敏捷和DevOps软件团队中非常重要，但Kanban的工作方法可以追溯到几十年前。在1940年代后期，丰田开始根据超市用来存放货架的相同模型优化其工程流程。让超市库存的产品刚好能满足消费者的需求，这种做法优化了超市和消费者之间的物流。

软件设计人员根据前期的需求分析，进行软件系统框架的搭建，根据用户的业务需求，开发初始的原型系统，原型系统应具备基本的业务需要，针对用户的基本业务，原型系统上都要体现出来，在搭建原型系统时，还要考虑后续原型系统功能的拓展性，为后续的软件功能更改做好准备。基本的思想是——在限定的时间内，用最经济的方法开发出一个可实际运行的系统模型，用户在运行使用整个原型的基础上，通过对其评价，提出改进意见，对原型进行修改，评价过程反复进行，使原型逐步完善，直到完全满足用户的需求为止。这有助于减少开发周期，提高开发效率。

螺旋模型中，发布的第一个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，最终得到一个更加完善的版本。成本高：由于螺旋模型的复杂性，以及迭代周期中需要进行的多个活动和任务，它往往需要更多的人力、物力和时间投入，导致整个开发过程的成本增加。灵活性和可定制性：螺旋模型允许根据项目的特点和需求进行定制，可以根据具体情况选择合适的活动和任务，并调整迭代周期的长度和数量。难以预测：由于螺旋模型的不确定性和复杂性，开发进度和成本难以准确预测。

增量模型强调将整个项目划分为多个增量或阶段，并在每个增量中逐步构建和交付系统的功能。开发和测试：在每个增量中，开发团队按照预定的优先级顺序进行功能开发和测试。集成和验证：在每个增量完成开发和测试后，将其集成到已有的系统中，并进行验证和测试以确保新功能与现有系统的兼容性和稳定性。迭代开发：在每个增量的评审和反馈后，开发团队可以根据客户的需求和反馈进行调整和修改，并继续下一个增量的开发和交付。反馈和调整：每个增量的交付和评审提供了反馈机制，使开发团队能够及时调整和改进系统，以满足客户的需求和期望。

瀑布模型是一种软件开发过程模型，它将软件开发过程划分为一系列阶段，并且每个阶段必须按照顺序完成，前一个阶段完成后才能进入下一个阶段，形如瀑布流水，最终得到软件产品。这些阶段通常包括需求分析、设计、编码、测试和维护等。在瀑布模型中，每个阶段都有明确的输入和输出，而且每个阶段的输出成为下一个阶段的输入。

软件生命周期模型是指在软件开发过程中，按照一定的阶段和活动划分，描述了软件从概念到废弃的全过程。它是一种组织和管理软件开发活动的框架，用于指导开发团队在不同阶段进行需求分析、设计、编码、测试和维护等工作。常见的软件生命周期模型包括以下几种：瀑布模型：瀑布模型是最经典的软件生命周期模型之一。它将软件开发过程划分为线性的阶段，包括需求分析、设计、编码、测试和维护等。每个阶段依次完成，前一个阶段完成后才能进入下一个阶段。原型模型：原型模型注重通过创建和演示可用的软件原型来验证需求和设计。它采用快速迭代的方式，通过

在消息驱动的架构中，组件之间的交互是通过发送和接收消息来实现的。总的来说，消息驱动和事件驱动都是有效的编程模型，用于实现组件之间的通信和协作。消息驱动更关注消息的发送和接收，适用于强调消息的内容和类型的情况；在事件驱动编程中，程序的执行顺序是由事件的发生和相应的处理决定的，而不是按照传统的顺序执行。在消息驱动的模型中，系统中的各个组件（或对象）通过发送和接收消息进行通信和协作。事件驱动编程是一种编程范式，它以事件的发生和相应的处理为核心，通过订阅和响应事件来实现程序的逻辑控制。

首先Singleton的构造是protected的，因为Singleton本身只是个帮助类，并没有单独实例化的需要，但是子类需要实例化，所以需要protected子类才可以访问。在这里基类的析构函数可以不需要 virtual ，因为子类在应用中只会用 Derived 类型，保证了析构时和构造时的类型一致。该模式的思想是，通过模板类的静态成员变量来确保一个类只有一个实例，并且可以通过静态函数来获取该实例。奇异递归模板是指父类是个模板类，模板类型是子类类型，即父类通过模板参数可以知道子类的类型。

CRTP 的基本思想是将派生类作为模板参数传递给基类，使得基类可以通过继承关系获取派生类的类型信息，并以此来实现一些静态多态的特性。但是在 CRTP 中，模板类的参数已经确定了其派生类的类型，因此在编译期间就已经确定了转换的正确性。来进行运行时类型检查，以确保转换的正确性。因为在普通的继承中，一个基类指针指向的对象可能是派生类的对象，也可能是其他类的对象，我们需要在运行时进行类型检查，以确保转换的正确性。然而，CRTP 也有一些限制，如需要在派生类中显式地调用基类的函数，对继承关系有一定的限制等。

在使用 Pimpl 模式时，我们只需要在头文件中包含一个指向实现类的指针，而不需要包含实现类的定义。这种方式的实现原理是，由于头文件中只包含了实现类的前向声明，因此编译器在编译头文件时并不需要知道实现类的具体定义。Pimpl是C++中一种设计模式，全称为Pointer to Implementation，它可以用于隐藏类的实现细节，从而实现封装和减少编译依赖的效果。这样一来，外部代码只需要包含“接口”类的头文件，而不需要访问实现的详细信息，从而实现了信息隐藏的效果。这种方式的实现背后涉及到了一些编译原理。

该模式为客户端提供一个高级接口，隐藏了系统内部子系统的复杂性，使得客户端只需与门面对象交互，而无需了解底层子系统的实现细节。门面（Facade）：提供了一个简化的接口，将客户端的请求委派给底层的一个或多个子系统，通过门面对象可以访问底层子系统的功能。抽象主题（Subject）：定义了被代理对象和代理对象之间的公共接口，这样在任何使用被代理对象的地方都可以使用代理对象替代。在代理模式中，代理对象充当了被访问对象的替身，客户端通过代理对象间接地访问和操作被代理的对象，而不需要直接访问被代理对象。

而实际上，考虑到代码可测性，一个重要的概念就是，依赖是可以被替换的，而单例模式就是难以替换，因此将依赖封装到context里去，就是一种实现技巧。它在不同的领域中具有不同的含义和用法，但都起到了关键的作用，提供了必要的背景和条件，以便进行适当的决策和操作。在 gRPC 的 C++ 中，ServerContext 类提供了许多有用的信息和功能，可以在服务器端访问和控制 RPC 请求。这是一个非常简单的示例，实际上，在实际开发中，上下文(Context)可能包含更多的属性和方法，以支持特定的场景和需求。

考虑到鸭子子类越来越多，大白鸭，小黄鸭，火箭鸭，丑小鸭…试想如果将计算个人所得税的方法硬编码在用户类中，当新的税法颁布的时候，就要重写用户类的相关代码, 而如果使用策略模式，只需要遵循接口实现一个新的所得税算法类就行了，用户类里包含一个指向策略基类的指针或者引用，只要确保该成员变量指向新的类的对象就行了。这里的算法和行为的含义都是指某件事的做法，也就是策略 Strategy 的含义，而不局限于计算机科学中的具体算法。鸭子和策略采用 Has-A 的关系，即包含的关系，让指向策略基类的指针作为鸭子基类的成员。

虽然单例可能仍然具有有效的用例，比如管理对共享资源的访问或提供集中化配置，但重要的是要考虑上述的缺点，并探索替代的设计模式，比如依赖注入、工厂模式，或者使用能够简化对象创建和生命周期管理的框架。如果希望引入新的功能或行为，就需要修改原有的单例类，可能导致代码的复杂性增加。代码库中的任何部分都可以访问和修改单例实例，可能导致潜在的依赖和耦合问题。依赖注入：单例可能会阻碍依赖注入，因为它们创建自己的实例而不依赖于外部传入的依赖项。的一种，它限制了一个类的实例化只能为一个实例，并提供对该实例的。

幂等性是开发当中很常见也很重要的一个需求。尤其是金融、支付等行业对其要求更加严格，既要有好的性能也要有严格的幂等性。除了对其概念的掌握，理解自身业务需求更是实现幂等功能的要点，必须处理好每一个结点细节，一旦某个地方没有设计完善，最后的结果可能仍旧达不到要求。下一讲介绍全局ID的生成办法。

概念组合模式，就是将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。组合模式（Composite）将小对象组合成树形结构，使用户操作组合对象如同操作一个单个对象。组合模式定义了“部分-整体”的层次结构，基本对象可以被组合成更大的对象，而且这种操作是可重复的，不断重复下去就可以得到一个非常大的组合对象，但这些组合对象与基本对象拥有相同的接口，因而组合是透明的，用法完全一致。我们这样来简单的理解组合模式，组合模式就是把一些现有的对象或者元素，经过组合

文章目录前言状态模式UML类图使用场合代码实现总结前言在实际开发中，我们经常会遇到这种情况；一个对象有多种状态，在每一个状态下，都会有不同的行为。那么在代码中我们经常是这样实现的。enum State { state1, state2, state3};void Action(State actionState){ if (actionState == state1) { // DoSomething } else

责任链（Chain of Responsibility）模式的定义：为了避免请求发送者（sender）与多个请求处理者（receiver）耦合在一起（解耦），将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。分类上属于行为型模式。注意：责任链模式也叫职责链模式。在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，所以责任链将请求的发送者和请求的处理者解耦了。

双重检查锁定（也称为“双重检查锁定优化”）是一种用于减少获取锁的开销的软件设计模式。它通过在获取锁之前测试锁定条件（即“锁提示”）来实现。只有在锁定条件检查表明需要锁定时才会进行锁定操作。即假设A、B两个线程同时运行与A、B点，B的release操作对线程A可见。同时p = new Singleton()的读写操作不会被重排到B点之后。

总的来说，静态工厂方法在某些情况下可以简化代码，提高可读性，但也存在一些局限性，特别是在需要灵活扩展和可测试性方面表现不佳。在实际应用中，需要根据具体的场景和需求来选择是否使用静态工厂方法。前面我们介绍了简单工厂模式，在创建对象前，我们需要先创建工厂，然后再通过工厂去创建产品。静态工厂方法还可以直接集成到类中，简称self create。

简单工厂模式是一种创建型模式，用于根据客户端的需求创建对象实例，所谓的需求反映到编程语言里就是传入的参数。工厂类（Simple Factory）：这是整个模式的核心。它负责根据客户端的请求来创建并返回相应的对象实例。产品抽象类（Product Interface）：定义了被创建产品的接口具体产品类（Concrete Products）：实现了产品接口的具体类，由工厂类根据客户需要创建并返回给客户端。

C++规定，non-local static 对象的初始化发生在main函数执行之前，也即main函数之前的单线程启动阶段，所以不存在线程安全问题。但C++没有规定多个non-local static 对象的初始化顺序，尤其是来自多个编译单元的non-local static对象，他们的初始化顺序是随机的。C++11规定，在一个线程开始local static 对象的初始化后到完成初始化前，其他线程执行到这个local static对象的初始化语句就会等待，直到该local static 对象初始化完成。

在委托模式中，一个类（委托对象）将一些需要执行的操作委托给另一个类（委托方法），从而形成一种类似于回调函数的机制。委托模式的核心思想是将复杂的功能分解到不同的对象中去实现，降低单个对象的复杂度，从而提高系统的可维护性和可扩展性。委托模式在实际中有着广泛的应用，在事件驱动编程、GUI 编程、多线程编程等领域都有着重要的作用。对于需要动态确定对象行为，或者对象结构发生变化时需要灵活地修改代码的情况下，委托模式是一种非常有用的技术手段。委托模式有一个非常形象的比喻，那就是事件机制中的事件和事件处理器。

在GOF的《设计模式:可复用面向对象软件的基础》一书中对观察者模式是这样说的：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化，关注它的对象就会得到通知；这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者。观察者模式以消息发布-订阅来代入会更加容易理解。最常见的一个例子就是： 对同一组数据进行统计分析时候， 我们希望能够提供多种形式的表示 （例如以表格进

什么是命令模式？在GOF的《设计模式:可复用面向对象软件的基础》一书中对命令模式是这样说的：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。在OOP中，一切都是对象，将请求封装成对象，符合OOP的设计思想，当将客户的单个请求封装成对象以后，我们就可以对这个请求存储更多的信息，使请求拥有更多的能力；命令模式同样能够把请求发送者和接收者解耦，使得命令发送者不用去关心请求将以何种方式被处理。UML类图Command：声明执行操作的接口；C

先贴出它们各自的UML图。桥接模式如下：策略如下：在桥接中,Abstraction通过聚合方式引用Implementor.在策略中，Context也通过聚合引用Strategy.桥接(Bridge)模式是结构型模式的一种，而策略(strategy)模式则属于行为模式。从他们的结构图可知，在这两种模式中，都存在一个对象使用聚合的方式引用另一个对象的抽象接口的情况，而且该抽象接口的实现可以有多种并且可以替换。可以说两者在表象上都是调用者与被调用者之间的解耦，以及抽象接口与实现的分离。那么两者的

**作用：**将抽象部份与它的实现部份分离，使它们都可以独立地变化。将抽象(Abstraction)与实现(Implementation)分离，使得二者可以独立地变化。桥接模式号称设计模式中最难理解的模式之一，关键就是这个抽象和实现的分离非常让人奇怪，大部分人刚看到这个定义的时候都会认为实现就是继承自抽象，那怎么可能将他们分离呢。《大话设计模式》中就Bridge模式的解释：手机品牌和软件是两个概念，不同的软件可以在不同的手机上，不同的手机可以有相同的软件，两者都具有很大的变动性。如果我们单独以手机品

合成复用原则的核心是 “少用继承，多用组合继承是 “白箱复用”（子类可见父类内部），组合是 “黑箱复用”（仅通过接口使用）。在设计时，应优先考虑通过组合将不同功能模块化，让系统更灵活、更易维护。简单说：当你想 “这个类应该有某个功能” 时，先考虑 “能不能把这个功能做成对象，让类持有它”，而不是 “让类继承一个有这个功能的父类”。

这个实现的问题很明显：当需要新增一种图形（如三角形）时，必须修改ShapeCalculator类的calculateArea方法，添加新的判断分支，这就违反了 “对修改关闭” 的原则。具体来说，一个软件实体（如类、模块、函数等）应当允许在不修改其源代码的前提下，通过扩展的方式来新增功能。，通过定义抽象的接口或基类，让具体实现类去继承和扩展，而高层模块只依赖于抽象，不依赖具体实现。开闭原则是一种结果，一种指导思想，并非手段，想实现开闭原则，还得借助抽象来实现。实现开闭原则的关键是。

概念迪米特定律最初是作为设计面向对象系统的风格规则而制定的。“只和你的直系朋友说话”是座右铭。风格规则是由伊恩·霍兰德（Ian Holland）于1987年秋天在东北大学发现的。迪米特法则的一个更一般的表述是：每个单位应该只对其他单位有有限的了解：只有与当前单位“密切相关”的单位。 或者：每个单位应该只与它的朋友交谈;不要和陌生人说话。原话：Each unit should have only limited knowledge about other units: only units “clos