1. 项目概述当设计模式遇上C#语法糖最近在重构一个遗留的上位机数据采集系统时我遇到了一个典型的“接口不兼容”难题。系统里有一个老旧的第三方硬件驱动库它的数据上报接口是一堆基于事件回调的、参数复杂的委托方法。而我的新业务模块期望的是一个干净、统一的IDataProvider接口里面只有StartAsync、StopAsync和GetDataStream这几个方法。直接去改驱动库不现实那是闭源的。在业务代码里到处写适配逻辑那会让核心逻辑充满“胶水代码”难以维护。这正是适配器模式的经典战场。但仅仅套用教科书上的类适配器或对象适配器在C#这个现代语言里总觉得不够优雅和“地道”。直到我将它与C#的另一项利器——扩展方法结合起来才真正找到了一个既符合面向对象设计原则又极具C#特色的优雅解决方案。这不仅仅是把一个接口转换成另一个接口更是关于如何让老旧代码、第三方库甚至是不符合我们设计预期的类型能够无缝、优雅地融入我们精心设计的系统架构中。对于从事C#上位机开发、物联网中间件或是任何需要集成多源组件的场景这种组合拳的价值不言而喻。2. 核心设计思路模式与语法的化学反应2.1 适配器模式的再认识不仅仅是包装在深入代码之前我们先抛开那些刻板的UML图从实际问题理解适配器模式。它的核心目的是解决接口不兼容问题充当两个不匹配接口之间的“转换头”。在C#中这通常有两种实现方式类适配器通过继承让适配器类同时继承被适配者Adaptee并实现目标接口ITarget。这种方式耦合度高且C#不支持多类继承因此通常只在适配器需要同时表现出“是一个”被适配者和“是一个”目标接口时才考虑实际使用较少。对象适配器通过组合这是更常用、更灵活的方式。适配器类内部持有一个被适配者对象的引用并实现目标接口。所有对目标接口的调用都被委托或转换给内部这个被适配者对象。在我们的数据采集案例中对象适配器是自然的选择。我可以创建一个LegacyDriverAdapter类它实现IDataProvider并在构造函数中传入那个老旧的驱动对象实例。然而传统的对象适配器模式会引入一个新的、明确的“适配器类”。这意味着使用者必须知道这个类的存在并显式地实例化它。当系统中需要适配的类型很多或者被适配的类型本身还需要在其他上下文中以原始形态使用时管理这些适配器类会带来额外的复杂度。2.2 扩展方法的赋能无缝的集成体验C#的扩展方法允许我们向现有类型“添加”新方法而无需修改原始类型的代码或创建新的派生类型。这为适配器模式带来了革命性的变化消除“新类型”的认知负担我们不再需要告诉使用者“请使用XXXAdapter类”。相反我们可以让适配逻辑看起来就像是原有类型原生支持的功能。使用者可以对被适配的对象直接调用目标接口的方法语法上无比自然。非侵入式适配我们完全不需要触碰第三方库或遗留代码。扩展方法在一个独立的静态类中定义实现了关注点分离。按需使用通过using指令引入扩展方法所在的命名空间适配功能才可用。这提供了优秀的模块化和可管理性。两者的结合思路我们不再创建一个实现了ITarget的独立适配器类。而是创建一个静态类在其中为Adaptee类型定义一个扩展方法例如AsIDataProvider()。这个方法内部才真正包含那个适配器逻辑可能会返回一个实现了ITarget的内部类实例。对于调用方来说它只是在一个已有的对象上调用了一个便捷的方法然后就得到了一个兼容的接口实例。// 传统方式需要知道并实例化适配器 var legacyDriver new LegacyDriver(); var dataProvider new LegacyDriverAdapter(legacyDriver); // 扩展方法方式更直观更像原生操作 var legacyDriver new LegacyDriver(); var dataProvider legacyDriver.AsIDataProvider(); // 看适配就像一次转换这种结合将适配这一设计行为从“架构层”部分地降维到了“工具层”使其更轻量、更易于使用和传播。注意扩展方法本质上是静态方法的语法糖它无法访问类型的私有或受保护成员。因此如果适配逻辑需要访问被适配对象的内部状态而该状态又是私有的那么传统的对象适配器通过组合持有引用仍是必须的。扩展方法更适合于基于公共API进行逻辑组合和转换的场景。3. 实战解析从老旧驱动到现代接口让我们用一个更具体的模拟案例来贯穿整个实现过程。假设我们有一个用于模拟GameViewer Virtual Display Adapter或Generic Bluetooth Adapter的旧版驱动库它提供的数据通知机制非常原始。3.1 场景搭建不兼容的双方首先定义“老旧”的被适配者。它可能来自一个第三方Hardware.LegacyNuGet包。// 假设这是无法修改的第三方库代码 namespace Hardware.Legacy { // 一个过时的、基于事件的设备驱动 public class LegacyDeviceDriver { public string DeviceId { get; private set; } // 复杂的事件签名使用自定义的、笨重的参数类型 public event EventHandlerLegacyDataEventArgs? DataReceived; // 启动方法参数是配置字符串没有异步支持 public void StartPolling(string config) { Console.WriteLine($[LegacyDriver {DeviceId}] 开始轮询配置: {config}); // 模拟后台线程收到数据并触发事件 Task.Run(async () { while (true) { await Task.Delay(1000); // 模拟1秒间隔 var args new LegacyDataEventArgs { RawHexString A1B2C3D4, Timestamp DateTime.Now, StatusCode 0x00 }; DataReceived?.Invoke(this, args); } }); } public void StopPolling() { Console.WriteLine($[LegacyDriver {DeviceId}] 停止轮询); } } // 老旧的事件参数数据格式不友好 public class LegacyDataEventArgs : EventArgs { public string? RawHexString { get; set; } // 原始16进制字符串 public DateTime Timestamp { get; set; } public byte StatusCode { get; set; } } }然后是我们系统内部定义的、清爽的现代目标接口。// 我们系统定义的统一数据提供者接口 namespace DataAcquisition.Core { public interface IDataProvider { string ProviderId { get; } Task StartAsync(CancellationToken cancellationToken default); Task StopAsync(); IAsyncEnumerableDataPacket GetDataStreamAsync(CancellationToken cancellationToken default); } public class DataPacket { public byte[] Data { get; init; } Array.Emptybyte(); public DateTimeOffset UtcTimestamp { get; init; } public bool IsValid { get; init; } } }矛盾显而易见LegacyDeviceDriver使用同步的StartPolling和基于事件的DataReceived数据是string类型的16进制而IDataProvider要求异步的StartAsync/StopAsync和基于IAsyncEnumerable的流式数据数据是byte[]。3.2 实现组合拳扩展方法包装适配器逻辑我们不直接创建LegacyDriverAdapter类。而是创建一个静态类为LegacyDeviceDriver提供扩展方法。using System.Runtime.CompilerServices; using Hardware.Legacy; using DataAcquisition.Core; namespace DataAcquisition.Adapters { // 静态类用于存放扩展方法 public static class LegacyDriverExtensions { // 核心扩展方法将LegacyDeviceDriver“转换”为IDataProvider public static IDataProvider AsDataProvider(this LegacyDeviceDriver legacyDriver, string? customId null) { if (legacyDriver null) throw new ArgumentNullException(nameof(legacyDriver)); // 返回一个内部私有类实例它实现了IDataProvider return new LegacyDriverDataProvider(legacyDriver, customId); } // 内部私有适配器类对外不可见。这是实际干活的对象适配器。 private class LegacyDriverDataProvider : IDataProvider { private readonly LegacyDeviceDriver _driver; private readonly string _providerId; private CancellationTokenSource? _streamCts; private Task? _pollingTask; private readonly ChannelDataPacket _dataChannel; public string ProviderId _providerId; internal LegacyDriverDataProvider(LegacyDeviceDriver driver, string? customId) { _driver driver; _providerId customId ?? $Adapter_{driver.DeviceId}; // 使用Channel作为生产者和消费者之间的缓冲区处理事件到异步流的转换 _dataChannel Channel.CreateUnboundedDataPacket(new UnboundedChannelOptions { SingleWriter true, // 事件处理器是唯一的写入者 SingleReader false // 可以有多个读取者虽然我们通常只暴露一个流 }); // 订阅老旧驱动的事件并将其转换为写入Channel的操作 _driver.DataReceived OnLegacyDataReceived; } private void OnLegacyDataReceived(object? sender, LegacyDataEventArgs e) { // 将16进制字符串转换为byte[] byte[] data ConvertHexStringToByteArray(e.RawHexString); var packet new DataPacket { Data data, UtcTimestamp new DateTimeOffset(e.Timestamp, TimeSpan.Zero), IsValid e.StatusCode 0x00 }; // 尝试将数据写入Channel。如果Channel已关闭比如StopAsync被调用则忽略。 _dataChannel.Writer.TryWrite(packet); } private static byte[] ConvertHexStringToByteArray(string? hexString) { if (string.IsNullOrEmpty(hexString) || hexString.Length % 2 ! 0) return Array.Emptybyte(); byte[] data new byte[hexString.Length / 2]; for (int i 0; i data.Length; i) { data[i] Convert.ToByte(hexString.Substring(i * 2, 2), 16); } return data; } public async Task StartAsync(CancellationToken cancellationToken default) { // 将老驱动的同步StartPolling包装成Task await Task.Run(() _driver.StartPolling(DefaultConfig), cancellationToken); _streamCts new CancellationTokenSource(); } public Task StopAsync() { _driver.StopPolling(); _streamCts?.Cancel(); // 通知数据流停止 _dataChannel.Writer.Complete(); // 关闭Channel结束IAsyncEnumerable return Task.CompletedTask; } public async IAsyncEnumerableDataPacket GetDataStreamAsync( [EnumeratorCancellation] CancellationToken cancellationToken default) { // 将Channel.Reader.ReadAllAsync()与外部传入的取消令牌链接 var linkedCts CancellationTokenSource.CreateLinkedTokenSource( cancellationToken, _streamCts?.Token ?? CancellationToken.None ); await foreach (var packet in _dataChannel.Reader.ReadAllAsync(linkedCts.Token)) { yield return packet; } } } } }关键点解析扩展方法AsDataProvider这是对外的唯一入口。它接收一个LegacyDeviceDriver实例返回一个IDataProvider。调用者无需关心内部类LegacyDriverDataProvider的存在。内部私有类真正的适配器逻辑封装在这个私有类中。它持有驱动引用处理事件订阅、数据格式转换16进制转byte[]并利用System.Threading.Channels库将事件驱动的模型转换为IAsyncEnumerable拉模型。这是对象适配器模式的精髓。异步流转换这是解决“事件”到“异步流”不兼容的核心。Channel在这里充当了缓冲区和解耦器。事件处理器快速将数据写入Channel而GetDataStreamAsync方法则从Channel中异步读取并yield return。这避免了在事件处理器中执行复杂逻辑也使得数据消费可以按需进行。3.3 使用方式对比using Hardware.Legacy; using DataAcquisition.Core; using DataAcquisition.Adapters; // 引入扩展方法命名空间 class Program { static async Task Main(string[] args) { // 1. 传统的对象适配器方式如果我们暴露了那个类 // var legacyDriver new LegacyDeviceDriver { DeviceId COM1 }; // IDataProvider provider new LegacyDriverAdapter(legacyDriver); // 需要知道LegacyDriverAdapter // 2. 使用扩展方法方式更优雅 var legacyDriver new LegacyDeviceDriver { DeviceId COM1 }; IDataProvider provider legacyDriver.AsDataProvider(); // 直接在原对象上操作直观 Console.WriteLine($Provider ID: {provider.ProviderId}); await provider.StartAsync(); // 使用异步流消费数据 await foreach (var packet in provider.GetDataStreamAsync().WithCancellation(CancellationToken.None).Take(5)) { Console.WriteLine($收到数据: {BitConverter.ToString(packet.Data)}, 时间: {packet.UtcTimestamp:HH:mm:ss}, 有效: {packet.IsValid}); } await provider.StopAsync(); } }可以看到使用方代码非常干净。它只与LegacyDeviceDriver和IDataProvider这两个它本来就该知道的类型打交道。适配的魔法隐藏在了一个简单的AsDataProvider()调用背后。4. 深入探讨模式组合的优势与边界4.1 为何这种组合是“C#特色”的优雅方案符合开放-封闭原则我们对第三方库封闭的进行了扩展开放的而没有修改它。系统对新的适配方式通过扩展方法是开放的对修改旧代码是封闭的。提升可发现性和可用性在IDE中当您键入一个LegacyDeviceDriver实例变量后输入.AsDataProvider()方法会智能提示出现。这极大地降低了使用适配器的门槛就像在使用一个原生功能。简化依赖注入在ASP.NET Core或其它DI容器中注册服务变得灵活。你可以注册LegacyDeviceDriver为单例然后在需要IDataProvider的地方既可以在工厂方法中调用AsDataProvider()也可以注册一个委托转换。应对多重适配一个类型可能需要适配成多种接口。例如同一个LegacyDeviceDriver可能既需要作为IDataProvider也需要作为ILogSource。我们可以轻松地提供AsDataProvider()和AsLogSource()两个扩展方法彼此独立清晰明了。4.2 性能与资源考量对象创建每次调用AsDataProvider()都会创建一个新的内部适配器类实例。如果被适配对象是重量级且单例的而适配器是无状态的或状态很轻可以考虑在扩展方法内部实现简单的缓存返回同一个适配器实例。但要注意线程安全。事件泄漏内部适配器订阅了老旧驱动的事件。必须确保适配器的生命周期得到妥善管理。如果适配器实例被长期持有而驱动对象已不再需要会导致内存泄漏。在上面的实现中适配器持有驱动的引用驱动也通过事件持有适配器的引用形成了循环引用虽然一方是弱事件但EventHandler是强引用。更好的做法是让适配器实现IDisposable在Dispose中取消事件订阅或者使用弱事件模式。Channel缓冲区使用无界Channel(CreateUnbounded)在数据生产快于消费时可能导致内存增长。根据场景可以选择有界Channel(CreateBounded)并制定丢弃或等待策略。4.3 与其它C#特性的结合泛型适配器如果有一系列类似的老旧驱动它们有共同的接口我们可以创建泛型扩展方法。public static IDataProvider AsDataProviderT(this T legacyDevice, FuncT, DataPacket converter) where T : ILegacyDevice { return new GenericDeviceAdapterT(legacyDevice, converter); }源生成器对于大量、模式固定的适配场景可以探索使用C#源生成器在编译时自动生成适配器类和扩展方法进一步提升开发效率。5. 常见问题与避坑指南在实际项目中应用这种模式我踩过一些坑也总结了一些技巧。5.1 问题一扩展方法“污染”智能感知当你为一些广泛使用的基类型如object、IEnumerable添加扩展方法时它会在所有地方出现可能造成干扰。解决方案将扩展方法放在语义明确、作用域清晰的命名空间中。使用者通过using指令按需引入避免全局污染。例如using MyProject.Adapters.LegacyHardware;。5.2 问题二适配器中的异常处理老旧驱动的事件处理器OnLegacyDataReceived如果抛出异常会直接导致驱动内部的事件调用链崩溃可能使整个驱动进入不稳定状态。解决方案在适配器的事件处理方法内部必须使用try-catch进行严密的异常处理并将错误信息通过更安全的方式如日志、一个专门的错误通道传递出去绝不能任由异常上抛。private void OnLegacyDataReceived(object? sender, LegacyDataEventArgs e) { try { // ... 转换和写入逻辑 } catch (Exception ex) { _logger.LogError(ex, “处理遗留驱动数据时出错”); // 可以选择将错误信息作为一个特殊的DataPacket写入Channel _dataChannel.Writer.TryWrite(new DataPacket { IsValid false, /* 携带错误信息 */ }); } }5.3 问题三异步流与取消令牌的联动在GetDataStreamAsync中我们链接了外部令牌和内部_streamCts的令牌。但如果StopAsync在流枚举结束前被调用_streamCts被取消链接令牌也会取消导致ReadAllAsync抛出OperationCanceledException这个异常会传播给正在消费流的调用者这可能不是调用者期望的调用者可能只关心自己传入的令牌。解决方案更精细地处理取消。可以在适配器内部捕获由_streamCts取消引发的异常并将其转换为流的自然结束例如在写入端调用Complete后读取端会正常结束或者提供一个自定义的、不含取消异常的结果。public async IAsyncEnumerableDataPacket GetDataStreamAsync([EnumeratorCancellation] CancellationToken cancellationToken default) { var linkedCts CancellationTokenSource.CreateLinkedTokenSource(cancellationToken); // 不链接内部_cts而是通过检查Channel.Completion来处理停止 try { await foreach (var packet in _dataChannel.Reader.ReadAllAsync(linkedCts.Token)) { yield return packet; } } finally { linkedCts.Dispose(); } // 当StopAsync()调用_dataChannel.Writer.Complete()后循环会自然退出。 }5.4 问题四处理遗留驱动的线程安全问题许多老旧驱动并非线程安全它们的事件可能在任意线程上触发。而我们的适配器方法如写入Channel可能需要考虑线程安全。解决方案ChannelWriter.TryWrite本身是线程安全的适合多生产者场景。如果适配器内部有更复杂的共享状态需要使用锁lock或并发集合。确保对_driver的访问如果需要也是线程安全的或者通过将工作派发到特定的同步上下文如UI线程来处理。5.5 调试技巧由于扩展方法和内部类调试堆栈看起来会深一层。为了清晰定位问题为内部适配器类起一个易于识别的名字。在扩展方法入口处可以添加简单的日志或调试断言。使用条件编译符号在调试版本中为适配器添加更详细的跟踪日志。6. 模式演进在复杂系统中的架构应用当系统中有大量需要适配的组件时简单的扩展方法可能不足以管理复杂度。此时可以引入一个轻量的适配器注册表或工厂。public static class DataProviderAdapterFactory { private static readonly ConcurrentDictionaryType, Funcobject, IDataProvider _adapterFactories new(); static DataProviderAdapterFactory() { // 可以手动注册也可以通过反射发现所有带有特定Attribute的适配器 RegisterLegacyDeviceDriver(driver driver.AsDataProvider()); // RegisterAnotherLegacyDevice(device device.AsAnotherProvider()); } public static void RegisterT(FuncT, IDataProvider factory) where T : class { _adapterFactories[typeof(T)] obj factory((T)obj); } public static IDataProvider? Adapt(object adaptee) { if (_adapterFactories.TryGetValue(adaptee.GetType(), out var factory)) { return factory(adaptee); } // 或者尝试查找基类或接口的适配器 foreach (var kvp in _adapterFactories) { if (kvp.Key.IsInstanceOfType(adaptee)) { return kvp.Value(adaptee); } } return null; } } // 使用工厂 var provider DataProviderAdapterFactory.Adapt(legacyDriver); if (provider ! null) { // 使用provider }这种方式将适配逻辑集中管理更适合大型、插件化的系统。而扩展方法则作为构建这些适配逻辑的底层、原子化的工具。两者可以结合使用扩展方法提供类型安全的适配转换工厂提供统一的适配入口和生命周期管理。在我经历的上位机项目重构中正是先通过扩展方法为各种异构设备串口、蓝牙、OPC UA服务器、虚拟适配器提供了统一的IDataProvider适配再通过一个中心化的适配器管理器来协调它们的启动、停止和数据路由最终将原本混乱的“蜘蛛网”架构梳理成了一个清晰、可扩展的管道-过滤器架构。适配器模式与扩展方法的结合在其中扮演了至关重要的“连接器”角色让老旧代码不再是负担而是可以平稳融入新体系的积木。
1. 项目概述当设计模式遇上C#语法糖最近在重构一个遗留的上位机数据采集系统时我遇到了一个典型的“接口不兼容”难题。系统里有一个老旧的第三方硬件驱动库它的数据上报接口是一堆基于事件回调的、参数复杂的委托方法。而我的新业务模块期望的是一个干净、统一的IDataProvider接口里面只有StartAsync、StopAsync和GetDataStream这几个方法。直接去改驱动库不现实那是闭源的。在业务代码里到处写适配逻辑那会让核心逻辑充满“胶水代码”难以维护。这正是适配器模式的经典战场。但仅仅套用教科书上的类适配器或对象适配器在C#这个现代语言里总觉得不够优雅和“地道”。直到我将它与C#的另一项利器——扩展方法结合起来才真正找到了一个既符合面向对象设计原则又极具C#特色的优雅解决方案。这不仅仅是把一个接口转换成另一个接口更是关于如何让老旧代码、第三方库甚至是不符合我们设计预期的类型能够无缝、优雅地融入我们精心设计的系统架构中。对于从事C#上位机开发、物联网中间件或是任何需要集成多源组件的场景这种组合拳的价值不言而喻。2. 核心设计思路模式与语法的化学反应2.1 适配器模式的再认识不仅仅是包装在深入代码之前我们先抛开那些刻板的UML图从实际问题理解适配器模式。它的核心目的是解决接口不兼容问题充当两个不匹配接口之间的“转换头”。在C#中这通常有两种实现方式类适配器通过继承让适配器类同时继承被适配者Adaptee并实现目标接口ITarget。这种方式耦合度高且C#不支持多类继承因此通常只在适配器需要同时表现出“是一个”被适配者和“是一个”目标接口时才考虑实际使用较少。对象适配器通过组合这是更常用、更灵活的方式。适配器类内部持有一个被适配者对象的引用并实现目标接口。所有对目标接口的调用都被委托或转换给内部这个被适配者对象。在我们的数据采集案例中对象适配器是自然的选择。我可以创建一个LegacyDriverAdapter类它实现IDataProvider并在构造函数中传入那个老旧的驱动对象实例。然而传统的对象适配器模式会引入一个新的、明确的“适配器类”。这意味着使用者必须知道这个类的存在并显式地实例化它。当系统中需要适配的类型很多或者被适配的类型本身还需要在其他上下文中以原始形态使用时管理这些适配器类会带来额外的复杂度。2.2 扩展方法的赋能无缝的集成体验C#的扩展方法允许我们向现有类型“添加”新方法而无需修改原始类型的代码或创建新的派生类型。这为适配器模式带来了革命性的变化消除“新类型”的认知负担我们不再需要告诉使用者“请使用XXXAdapter类”。相反我们可以让适配逻辑看起来就像是原有类型原生支持的功能。使用者可以对被适配的对象直接调用目标接口的方法语法上无比自然。非侵入式适配我们完全不需要触碰第三方库或遗留代码。扩展方法在一个独立的静态类中定义实现了关注点分离。按需使用通过using指令引入扩展方法所在的命名空间适配功能才可用。这提供了优秀的模块化和可管理性。两者的结合思路我们不再创建一个实现了ITarget的独立适配器类。而是创建一个静态类在其中为Adaptee类型定义一个扩展方法例如AsIDataProvider()。这个方法内部才真正包含那个适配器逻辑可能会返回一个实现了ITarget的内部类实例。对于调用方来说它只是在一个已有的对象上调用了一个便捷的方法然后就得到了一个兼容的接口实例。// 传统方式需要知道并实例化适配器 var legacyDriver new LegacyDriver(); var dataProvider new LegacyDriverAdapter(legacyDriver); // 扩展方法方式更直观更像原生操作 var legacyDriver new LegacyDriver(); var dataProvider legacyDriver.AsIDataProvider(); // 看适配就像一次转换这种结合将适配这一设计行为从“架构层”部分地降维到了“工具层”使其更轻量、更易于使用和传播。注意扩展方法本质上是静态方法的语法糖它无法访问类型的私有或受保护成员。因此如果适配逻辑需要访问被适配对象的内部状态而该状态又是私有的那么传统的对象适配器通过组合持有引用仍是必须的。扩展方法更适合于基于公共API进行逻辑组合和转换的场景。3. 实战解析从老旧驱动到现代接口让我们用一个更具体的模拟案例来贯穿整个实现过程。假设我们有一个用于模拟GameViewer Virtual Display Adapter或Generic Bluetooth Adapter的旧版驱动库它提供的数据通知机制非常原始。3.1 场景搭建不兼容的双方首先定义“老旧”的被适配者。它可能来自一个第三方Hardware.LegacyNuGet包。// 假设这是无法修改的第三方库代码 namespace Hardware.Legacy { // 一个过时的、基于事件的设备驱动 public class LegacyDeviceDriver { public string DeviceId { get; private set; } // 复杂的事件签名使用自定义的、笨重的参数类型 public event EventHandlerLegacyDataEventArgs? DataReceived; // 启动方法参数是配置字符串没有异步支持 public void StartPolling(string config) { Console.WriteLine($[LegacyDriver {DeviceId}] 开始轮询配置: {config}); // 模拟后台线程收到数据并触发事件 Task.Run(async () { while (true) { await Task.Delay(1000); // 模拟1秒间隔 var args new LegacyDataEventArgs { RawHexString A1B2C3D4, Timestamp DateTime.Now, StatusCode 0x00 }; DataReceived?.Invoke(this, args); } }); } public void StopPolling() { Console.WriteLine($[LegacyDriver {DeviceId}] 停止轮询); } } // 老旧的事件参数数据格式不友好 public class LegacyDataEventArgs : EventArgs { public string? RawHexString { get; set; } // 原始16进制字符串 public DateTime Timestamp { get; set; } public byte StatusCode { get; set; } } }然后是我们系统内部定义的、清爽的现代目标接口。// 我们系统定义的统一数据提供者接口 namespace DataAcquisition.Core { public interface IDataProvider { string ProviderId { get; } Task StartAsync(CancellationToken cancellationToken default); Task StopAsync(); IAsyncEnumerableDataPacket GetDataStreamAsync(CancellationToken cancellationToken default); } public class DataPacket { public byte[] Data { get; init; } Array.Emptybyte(); public DateTimeOffset UtcTimestamp { get; init; } public bool IsValid { get; init; } } }矛盾显而易见LegacyDeviceDriver使用同步的StartPolling和基于事件的DataReceived数据是string类型的16进制而IDataProvider要求异步的StartAsync/StopAsync和基于IAsyncEnumerable的流式数据数据是byte[]。3.2 实现组合拳扩展方法包装适配器逻辑我们不直接创建LegacyDriverAdapter类。而是创建一个静态类为LegacyDeviceDriver提供扩展方法。using System.Runtime.CompilerServices; using Hardware.Legacy; using DataAcquisition.Core; namespace DataAcquisition.Adapters { // 静态类用于存放扩展方法 public static class LegacyDriverExtensions { // 核心扩展方法将LegacyDeviceDriver“转换”为IDataProvider public static IDataProvider AsDataProvider(this LegacyDeviceDriver legacyDriver, string? customId null) { if (legacyDriver null) throw new ArgumentNullException(nameof(legacyDriver)); // 返回一个内部私有类实例它实现了IDataProvider return new LegacyDriverDataProvider(legacyDriver, customId); } // 内部私有适配器类对外不可见。这是实际干活的对象适配器。 private class LegacyDriverDataProvider : IDataProvider { private readonly LegacyDeviceDriver _driver; private readonly string _providerId; private CancellationTokenSource? _streamCts; private Task? _pollingTask; private readonly ChannelDataPacket _dataChannel; public string ProviderId _providerId; internal LegacyDriverDataProvider(LegacyDeviceDriver driver, string? customId) { _driver driver; _providerId customId ?? $Adapter_{driver.DeviceId}; // 使用Channel作为生产者和消费者之间的缓冲区处理事件到异步流的转换 _dataChannel Channel.CreateUnboundedDataPacket(new UnboundedChannelOptions { SingleWriter true, // 事件处理器是唯一的写入者 SingleReader false // 可以有多个读取者虽然我们通常只暴露一个流 }); // 订阅老旧驱动的事件并将其转换为写入Channel的操作 _driver.DataReceived OnLegacyDataReceived; } private void OnLegacyDataReceived(object? sender, LegacyDataEventArgs e) { // 将16进制字符串转换为byte[] byte[] data ConvertHexStringToByteArray(e.RawHexString); var packet new DataPacket { Data data, UtcTimestamp new DateTimeOffset(e.Timestamp, TimeSpan.Zero), IsValid e.StatusCode 0x00 }; // 尝试将数据写入Channel。如果Channel已关闭比如StopAsync被调用则忽略。 _dataChannel.Writer.TryWrite(packet); } private static byte[] ConvertHexStringToByteArray(string? hexString) { if (string.IsNullOrEmpty(hexString) || hexString.Length % 2 ! 0) return Array.Emptybyte(); byte[] data new byte[hexString.Length / 2]; for (int i 0; i data.Length; i) { data[i] Convert.ToByte(hexString.Substring(i * 2, 2), 16); } return data; } public async Task StartAsync(CancellationToken cancellationToken default) { // 将老驱动的同步StartPolling包装成Task await Task.Run(() _driver.StartPolling(DefaultConfig), cancellationToken); _streamCts new CancellationTokenSource(); } public Task StopAsync() { _driver.StopPolling(); _streamCts?.Cancel(); // 通知数据流停止 _dataChannel.Writer.Complete(); // 关闭Channel结束IAsyncEnumerable return Task.CompletedTask; } public async IAsyncEnumerableDataPacket GetDataStreamAsync( [EnumeratorCancellation] CancellationToken cancellationToken default) { // 将Channel.Reader.ReadAllAsync()与外部传入的取消令牌链接 var linkedCts CancellationTokenSource.CreateLinkedTokenSource( cancellationToken, _streamCts?.Token ?? CancellationToken.None ); await foreach (var packet in _dataChannel.Reader.ReadAllAsync(linkedCts.Token)) { yield return packet; } } } } }关键点解析扩展方法AsDataProvider这是对外的唯一入口。它接收一个LegacyDeviceDriver实例返回一个IDataProvider。调用者无需关心内部类LegacyDriverDataProvider的存在。内部私有类真正的适配器逻辑封装在这个私有类中。它持有驱动引用处理事件订阅、数据格式转换16进制转byte[]并利用System.Threading.Channels库将事件驱动的模型转换为IAsyncEnumerable拉模型。这是对象适配器模式的精髓。异步流转换这是解决“事件”到“异步流”不兼容的核心。Channel在这里充当了缓冲区和解耦器。事件处理器快速将数据写入Channel而GetDataStreamAsync方法则从Channel中异步读取并yield return。这避免了在事件处理器中执行复杂逻辑也使得数据消费可以按需进行。3.3 使用方式对比using Hardware.Legacy; using DataAcquisition.Core; using DataAcquisition.Adapters; // 引入扩展方法命名空间 class Program { static async Task Main(string[] args) { // 1. 传统的对象适配器方式如果我们暴露了那个类 // var legacyDriver new LegacyDeviceDriver { DeviceId COM1 }; // IDataProvider provider new LegacyDriverAdapter(legacyDriver); // 需要知道LegacyDriverAdapter // 2. 使用扩展方法方式更优雅 var legacyDriver new LegacyDeviceDriver { DeviceId COM1 }; IDataProvider provider legacyDriver.AsDataProvider(); // 直接在原对象上操作直观 Console.WriteLine($Provider ID: {provider.ProviderId}); await provider.StartAsync(); // 使用异步流消费数据 await foreach (var packet in provider.GetDataStreamAsync().WithCancellation(CancellationToken.None).Take(5)) { Console.WriteLine($收到数据: {BitConverter.ToString(packet.Data)}, 时间: {packet.UtcTimestamp:HH:mm:ss}, 有效: {packet.IsValid}); } await provider.StopAsync(); } }可以看到使用方代码非常干净。它只与LegacyDeviceDriver和IDataProvider这两个它本来就该知道的类型打交道。适配的魔法隐藏在了一个简单的AsDataProvider()调用背后。4. 深入探讨模式组合的优势与边界4.1 为何这种组合是“C#特色”的优雅方案符合开放-封闭原则我们对第三方库封闭的进行了扩展开放的而没有修改它。系统对新的适配方式通过扩展方法是开放的对修改旧代码是封闭的。提升可发现性和可用性在IDE中当您键入一个LegacyDeviceDriver实例变量后输入.AsDataProvider()方法会智能提示出现。这极大地降低了使用适配器的门槛就像在使用一个原生功能。简化依赖注入在ASP.NET Core或其它DI容器中注册服务变得灵活。你可以注册LegacyDeviceDriver为单例然后在需要IDataProvider的地方既可以在工厂方法中调用AsDataProvider()也可以注册一个委托转换。应对多重适配一个类型可能需要适配成多种接口。例如同一个LegacyDeviceDriver可能既需要作为IDataProvider也需要作为ILogSource。我们可以轻松地提供AsDataProvider()和AsLogSource()两个扩展方法彼此独立清晰明了。4.2 性能与资源考量对象创建每次调用AsDataProvider()都会创建一个新的内部适配器类实例。如果被适配对象是重量级且单例的而适配器是无状态的或状态很轻可以考虑在扩展方法内部实现简单的缓存返回同一个适配器实例。但要注意线程安全。事件泄漏内部适配器订阅了老旧驱动的事件。必须确保适配器的生命周期得到妥善管理。如果适配器实例被长期持有而驱动对象已不再需要会导致内存泄漏。在上面的实现中适配器持有驱动的引用驱动也通过事件持有适配器的引用形成了循环引用虽然一方是弱事件但EventHandler是强引用。更好的做法是让适配器实现IDisposable在Dispose中取消事件订阅或者使用弱事件模式。Channel缓冲区使用无界Channel(CreateUnbounded)在数据生产快于消费时可能导致内存增长。根据场景可以选择有界Channel(CreateBounded)并制定丢弃或等待策略。4.3 与其它C#特性的结合泛型适配器如果有一系列类似的老旧驱动它们有共同的接口我们可以创建泛型扩展方法。public static IDataProvider AsDataProviderT(this T legacyDevice, FuncT, DataPacket converter) where T : ILegacyDevice { return new GenericDeviceAdapterT(legacyDevice, converter); }源生成器对于大量、模式固定的适配场景可以探索使用C#源生成器在编译时自动生成适配器类和扩展方法进一步提升开发效率。5. 常见问题与避坑指南在实际项目中应用这种模式我踩过一些坑也总结了一些技巧。5.1 问题一扩展方法“污染”智能感知当你为一些广泛使用的基类型如object、IEnumerable添加扩展方法时它会在所有地方出现可能造成干扰。解决方案将扩展方法放在语义明确、作用域清晰的命名空间中。使用者通过using指令按需引入避免全局污染。例如using MyProject.Adapters.LegacyHardware;。5.2 问题二适配器中的异常处理老旧驱动的事件处理器OnLegacyDataReceived如果抛出异常会直接导致驱动内部的事件调用链崩溃可能使整个驱动进入不稳定状态。解决方案在适配器的事件处理方法内部必须使用try-catch进行严密的异常处理并将错误信息通过更安全的方式如日志、一个专门的错误通道传递出去绝不能任由异常上抛。private void OnLegacyDataReceived(object? sender, LegacyDataEventArgs e) { try { // ... 转换和写入逻辑 } catch (Exception ex) { _logger.LogError(ex, “处理遗留驱动数据时出错”); // 可以选择将错误信息作为一个特殊的DataPacket写入Channel _dataChannel.Writer.TryWrite(new DataPacket { IsValid false, /* 携带错误信息 */ }); } }5.3 问题三异步流与取消令牌的联动在GetDataStreamAsync中我们链接了外部令牌和内部_streamCts的令牌。但如果StopAsync在流枚举结束前被调用_streamCts被取消链接令牌也会取消导致ReadAllAsync抛出OperationCanceledException这个异常会传播给正在消费流的调用者这可能不是调用者期望的调用者可能只关心自己传入的令牌。解决方案更精细地处理取消。可以在适配器内部捕获由_streamCts取消引发的异常并将其转换为流的自然结束例如在写入端调用Complete后读取端会正常结束或者提供一个自定义的、不含取消异常的结果。public async IAsyncEnumerableDataPacket GetDataStreamAsync([EnumeratorCancellation] CancellationToken cancellationToken default) { var linkedCts CancellationTokenSource.CreateLinkedTokenSource(cancellationToken); // 不链接内部_cts而是通过检查Channel.Completion来处理停止 try { await foreach (var packet in _dataChannel.Reader.ReadAllAsync(linkedCts.Token)) { yield return packet; } } finally { linkedCts.Dispose(); } // 当StopAsync()调用_dataChannel.Writer.Complete()后循环会自然退出。 }5.4 问题四处理遗留驱动的线程安全问题许多老旧驱动并非线程安全它们的事件可能在任意线程上触发。而我们的适配器方法如写入Channel可能需要考虑线程安全。解决方案ChannelWriter.TryWrite本身是线程安全的适合多生产者场景。如果适配器内部有更复杂的共享状态需要使用锁lock或并发集合。确保对_driver的访问如果需要也是线程安全的或者通过将工作派发到特定的同步上下文如UI线程来处理。5.5 调试技巧由于扩展方法和内部类调试堆栈看起来会深一层。为了清晰定位问题为内部适配器类起一个易于识别的名字。在扩展方法入口处可以添加简单的日志或调试断言。使用条件编译符号在调试版本中为适配器添加更详细的跟踪日志。6. 模式演进在复杂系统中的架构应用当系统中有大量需要适配的组件时简单的扩展方法可能不足以管理复杂度。此时可以引入一个轻量的适配器注册表或工厂。public static class DataProviderAdapterFactory { private static readonly ConcurrentDictionaryType, Funcobject, IDataProvider _adapterFactories new(); static DataProviderAdapterFactory() { // 可以手动注册也可以通过反射发现所有带有特定Attribute的适配器 RegisterLegacyDeviceDriver(driver driver.AsDataProvider()); // RegisterAnotherLegacyDevice(device device.AsAnotherProvider()); } public static void RegisterT(FuncT, IDataProvider factory) where T : class { _adapterFactories[typeof(T)] obj factory((T)obj); } public static IDataProvider? Adapt(object adaptee) { if (_adapterFactories.TryGetValue(adaptee.GetType(), out var factory)) { return factory(adaptee); } // 或者尝试查找基类或接口的适配器 foreach (var kvp in _adapterFactories) { if (kvp.Key.IsInstanceOfType(adaptee)) { return kvp.Value(adaptee); } } return null; } } // 使用工厂 var provider DataProviderAdapterFactory.Adapt(legacyDriver); if (provider ! null) { // 使用provider }这种方式将适配逻辑集中管理更适合大型、插件化的系统。而扩展方法则作为构建这些适配逻辑的底层、原子化的工具。两者可以结合使用扩展方法提供类型安全的适配转换工厂提供统一的适配入口和生命周期管理。在我经历的上位机项目重构中正是先通过扩展方法为各种异构设备串口、蓝牙、OPC UA服务器、虚拟适配器提供了统一的IDataProvider适配再通过一个中心化的适配器管理器来协调它们的启动、停止和数据路由最终将原本混乱的“蜘蛛网”架构梳理成了一个清晰、可扩展的管道-过滤器架构。适配器模式与扩展方法的结合在其中扮演了至关重要的“连接器”角色让老旧代码不再是负担而是可以平稳融入新体系的积木。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
