15-C#

编程思想进阶笔记：POP → OOP → AOP → DDD

本文以"用户注册"这个业务场景为主线，逐步演示四种编程思想的演进过程，帮助理解每种思想解决了什么问题、又带来了什么新的局限。

---

一、POP —— 面向过程编程

核心思想

面向过程(Procedure-Oriented Programming)是最直接的编程方式：把要做的事情按步骤一行一行写下来，从上到下顺序执行。思维方式是线性的，适合逻辑简单、不需要扩展的小程序。

示例

// 用户注册的面向过程写法
Console.WriteLine("用户注册，提交信息");
Console.WriteLine("1 参数检查");
Console.WriteLine("2 数据入库");
Console.WriteLine("3 记录日志");

问题在哪

• 所有逻辑堆在一起，代码越写越长，越来越难维护
• 需求一变，就要到处改代码，牵一发动全身
• 无法复用，同样的逻辑在不同地方重复出现
• 不能应对变化，扩展性极差

---

二、OOP —— 面向对象编程

核心思想

面向对象(Object-Oriented Programming)把程序拆分成一个个"对象"，每个对象负责自己的事情。三大特性：封装、继承、多态。

• 封装：把细节藏起来，外部只看接口
• 继承：子类复用父类代码
• 多态(面向抽象)：上层代码只依赖接口，不依赖具体实现，这是 OOP 扩展性的核心

示例演进

第一步：封装对象

// 把用户信息封装成对象
UserInfo userInfo = new UserInfo()
{
    Account = "Administrator",
    Name = "张三",
    Password = "888888"
};

第二步：面向抽象(依赖接口而非具体类)

// 定义接口
public interface IDBHelper
{
    int Save(UserInfo userInfo);
}

// MySQL 实现
public class MySQLDBHelper : IDBHelper
{
    public int Save(UserInfo userInfo)
    {
        Console.WriteLine("数据入MySQL");
        return 0;
    }
}

// SQLServer 实现
public class SqlServerDBHelper : IDBHelper
{
    public int Save(UserInfo userInfo)
    {
        Console.WriteLine("数据入SqlServer");
        return 0;
    }
}

第三步：用简单工厂解耦

public class SimpleFactory
{
    public static IDBHelper CreateDBHelper()
    {
        // 只改这一行，上层代码完全不用动
        return new MySQLDBHelper();
        // return new SqlServerDBHelper();
    }
}

// 调用方
IDBHelper dbHelper = SimpleFactory.CreateDBHelper();
dbHelper.Save(userInfo);

OOP 的价值

• 封装屏蔽了细节，上层代码不关心底层怎么实现
• 面向抽象(接口 + 多实现)让切换实现变得简单，这是 80% 设计模式的核心套路
• 依赖注入(DI)、工厂模式、策略模式……都是这个思路的延伸

OOP 的局限

OOP 的扩展性靠的是对象替换对象。但如果我不想换掉整个对象，只是想在某个方法执行前后加点通用逻辑(比如日志、权限检查、性能统计)，OOP 就显得力不从心了。

最直接的做法是修改原来的类，但这违反了开闭原则(对扩展开放，对修改关闭)。

---

三、AOP —— 面向切面编程

核心思想

面向切面(Aspect-Oriented Programming)解决的问题是：在不修改原有对象、不替换原有对象的前提下，给它额外扩展功能。

这些额外的功能通常是横跨多个业务模块的通用逻辑，比如：

• 日志记录
• 权限验证
• 性能统计
• 异常处理
• 事务管理
• 缓存

AOP 不能做业务逻辑，它只负责这些"横切关注点"。

实现方式一：静态代理

手动写一个代理类，实现同一个接口，内部持有真实对象，在调用前后插入额外逻辑。

public class DBHelperProxy : IDBHelper
{
    // 持有真实对象
    private IDBHelper _iDBHelper = new MySQLDBHelper();
    private ILogHelper _logger = new LogConsole();

    public int Save(UserInfo userInfo)
    {
        // 方法执行前
        _logger.Log("Prepare Save");

        // 调用真实方法
        int result = _iDBHelper.Save(userInfo);

        // 方法执行后
        _logger.Log("After Save");

        return result;
    }
}

// 使用时，把代理对象当作真实对象用
IDBHelper dbHelper = new DBHelperProxy();
dbHelper.Save(userInfo);

优点：简单直观，不需要任何框架支持。

缺点：每个类都要手写一个代理类，代码量大，维护成本高。

实现方式二：动态代理(.NET Core 版)

.NET Core 提供了 DispatchProxy，可以在运行时动态生成代理，不需要为每个类手写代理代码。

// 真实代理：拦截所有方法调用
public class MyRealProxy<T> : DispatchProxy
{
    public T _Instance = default;

    protected override object? Invoke(MethodInfo? targetMethod, object?[]? args)
    {
        // 方法执行前的通用逻辑
        Console.WriteLine("方法执行前可以加入的逻辑");

        // 调用真实方法
        var result = targetMethod?.Invoke(_Instance, args);

        // 方法执行后的通用逻辑
        Console.WriteLine("方法执行后可以加入的逻辑");

        return result;
    }
}

// 透明代理：负责创建代理对象
public static class TransparentProxy
{
    public static T Create<T>(T instance)
    {
        dynamic proxy = DispatchProxy.Create<T, MyRealProxy<T>>()!;
        proxy._Instance = instance;
        return proxy;
    }
}

// 使用
IDBHelper dbHelper = new MySQLDBHelper();
dbHelper = TransparentProxy.Create<IDBHelper>(dbHelper);
dbHelper.Save(userInfo); // 自动触发前置/后置逻辑

注：.NET Framework 时代用的是 RealProxy(基于 .NET Remoting)，.NET Core 之后已移除，统一用 DispatchProxy。

动态代理的进阶用法

在 Invoke 方法里，可以通过反射读取方法上的自定义特性(Attribute)，实现更细粒度的控制：

// 比如：只有标了 [Log] 特性的方法才记录日志
if (targetMethod.IsDefined(typeof(LogAttribute), true))
{
    // 记录日志
}

AOP 的价值

• 业务代码只关注业务逻辑，通用逻辑统一在切面里处理
• 代码复用，一处修改，全局生效
• 方便团队协作，业务开发和基础设施开发分离

实际框架中的 AOP

在实际项目中，AOP 通常通过以下方式实现：

方式	代表框架
动态代理	Castle DynamicProxy、AspectCore
IL 编织	PostSharp
中间件管道	ASP.NET Core Middleware
过滤器	ASP.NET Core Filter(ActionFilter、ExceptionFilter 等)

---

四、DDD —— 领域驱动设计

核心思想

领域驱动设计(Domain-Driven Design)不是一种编程语法，而是一种软件架构方法论，适用于复杂业务系统的设计。

它的核心理念是：软件的核心复杂性来自业务领域本身，代码结构应该反映业务模型。

关键概念

限界上下文(Bounded Context)

把一个大系统按业务边界拆分成多个子域，每个子域有自己独立的模型和语言。比如"订单系统"和"库存系统"是两个不同的限界上下文，它们对"商品"的理解可能不同。

聚合根(Aggregate Root)

一组相关对象的入口，外部只能通过聚合根来操作内部对象，保证数据一致性。

实体(Entity)

有唯一标识的对象，即使属性相同，只要 ID 不同就是不同的实体。比如两个同名用户，是两个不同的实体。

值对象(Value Object)

没有唯一标识，只靠属性值来区分。比如"地址"，两个地址只要内容相同就认为是同一个。

领域服务(Domain Service)

不属于任何实体的业务逻辑，放在领域服务里。

仓储(Repository)

负责聚合根的持久化，隔离领域层和数据访问层。

DDD 与 OOP/AOP 的关系

DDD 是更高层次的架构思想，它告诉你如何组织代码结构；OOP 是实现手段，DDD 的各种概念(实体、值对象、聚合根)都用 OOP 来实现；AOP 则负责处理横切关注点，在 DDD 架构中同样适用。

适用场景

DDD 适合业务逻辑复杂、团队规模较大的项目。对于简单的 CRUD 应用，引入 DDD 反而会增加不必要的复杂度。

---

五、四种思想的对比总结

维度	POP	OOP	AOP	DDD
关注点	执行步骤	对象和职责	横切关注点	业务领域模型
扩展方式	修改代码	替换对象(接口+多实现)	切面拦截	领域模型演进
适用规模	小脚本	中小型项目	通用功能增强	复杂业务系统
核心原则	无	开闭原则、依赖倒置	不破坏封装	领域模型驱动

---

六、一个贯穿全文的演进脉络

以"用户注册"为例，四种思想的演进是这样的：

POP：把注册步骤写成一段顺序代码
  ↓ 问题：难以维护，无法复用
OOP：把用户、数据库操作封装成对象，用接口解耦
  ↓ 问题：想加日志，只能修改对象或替换对象
AOP：用代理模式在方法前后插入日志，不动原有代码
  ↓ 问题：系统越来越大，业务边界模糊
DDD：按业务领域划分边界，用领域模型驱动设计

每一步都是在解决上一步遗留的问题，没有哪种思想是万能的，关键是在合适的场景用合适的工具。