原型模式非常简单，用一句话既可概括：以一个已存在的对象作为原型，快速克隆产生出新的对象。一些对象的构造逻辑包含复杂的过程，比如I/O操作、网络通信、第三方交互等，通过原型模式可以跳过这些过程，高效的克隆出目标对象。

依赖注入（DI）与控制反转（IoC）可能是一些开发小伙伴耳熟但又不能详的两个词，经常看到它们的名字，但又不理解。这两个词来源于英文直译，看似高深莫测，其实非常简单，并且在一些开发场景中扮演着不可或缺的角色，比如单元测试离不开依赖注入，IoC容器是插件框架的最佳拍档等，本文尝试以最简单的方式阐述这两种思想在开发中的应用。

这篇文章源于工作中的一个项目，2021年，我负责汇川工业机器人应用软件的基础架构重构，当时单元测试是重构工作的核心环节之一，从无法进行单元测试到最终60%以上的行覆盖率，过程中自己也有非常多的收获，于是将其整理成文，希望对计划开展和正在开展单元测试的同学有所帮助。

测试驱动开发（TDD：Test Driven Development）是敏捷开发中的一项核心实践，推崇通过测试来驱动整个开发的进行。TDD有别于传统“先编码，后测试”的开发过程，而是要求在编写业务代码之前，先编写测试用例。TDD的概念大致在上世纪90年代随着极限编程（XP：Extreme Programming）提出，但在敏捷开发已大行其道的今天，TDD仍未普及，对其也是褒贬不一，存在一定争议。本文主要根据实际项目中的痛点，围绕广义ATDD的思想，探讨如何通过测试前置解决项目中存在的问题。

类图以可视化的方式呈现了软件中的基本单元以及它们之间的关系。在软件架构设计过程中，它可以帮助架构师快速构思项目框架而无需关注代码细节；在软件开发过程中，它又可以精确描述类中的所有元素细节。因此对于开发人员，了解了面向对象就必须掌握UML类图。

单例模式是一种高频使用的设计模式，它保证对象只有一个。比如有一台打印机，我们需要为控制打印机写一个类，如果这个类能被随意new()，甲new出来一个，乙new出来一个，甲还没打印完，乙又开始打印，那就乱了套。所以打印对象必须唯一，只有一个对象与打印机通讯，当甲乙丙丁同时打印时，在同一个对象中实现排队逻辑。单例模式就像美国总统，美国总统只能存在一个，如果有多个，估计全世界人民都会比较高兴。

观察者模式定义了对象之间一对多的依赖关系，当一个对象发生变化时，多个依赖它的对象都会收到通知。观察者模式也是一种通信范式，不光存在于软件开发中，在日常生活中也非常常见，比如拍卖会上的竞拍者观察拍卖师的报价后制定自己的出价策略，粉丝在微博上关注自己喜欢的明星后收到明星的动态推送等。因为观察者模式在开发中使用的非常频繁，大部分开发语言和框架均原生支持观察者模式，比如C#中的事件、QT中的信号槽等。

之前的两篇文章基于C++演示了gRPC的服务端、客户端以及Protobuf应用与代码示例，本文将基于C#演示gRPC的服务端与客户端。

工厂模式的核心目的是将对象的创建与使用分离，我们习惯于在构造函数中进行一系列对象的初始化甚至逻辑处理，如果仔细推敲，会发现其实并不符合常理。如果把汽车的发动机当作一个对象，我们向发动机传入设计图纸，然后发动机自己把自己生产了出来。是的，发动机自己生产了自己，是不是感觉有些怪异？其实现实生活中的场景更符合逻辑，把图纸送到发动机生产工厂，由工厂完成发动机的生产制造。在软件开发中，大多数简单对象，并不需要使用工厂，但当一个对象的构造过程相对复杂、易变时，就需要考虑使用工厂将对象的创建过程解耦了。

在上一篇文章《gRPC基础：C++服务端与客户端代码示例》中以从0到1的入门视角，详细介绍了gRPC的编译安装、编写proto文件、以及根据proto文件生成服务端与客户端的代码示例。但还遗留了一个非常重要的场景未讨论，它就是观察者模式，因此本文专门分析和演示如何通过gRPC实现很多高级编程语言都具备的观察者模式。