东东东尼君

设计模式(Design Patterns) 是软件工程中用于解决特定设计问题的经典方案，也是面向对象设计能力的重要体现。然而，很多开发者在学习设计模式时，往往停留在「记住二十三种模式」的层面，却很难理解为什么需要某种模式、它解决了什么问题，以及在现代 .NET 项目中应该如何使用。为了更系统地掌握设计模式，我选择学习Dmitri Nesteruk的在线课程Design Patterns in C# and .NET。该课程并非简单介绍GoF(Gang of Four)的 23 种设计模式，而是从设计原则出发，结合大量 C# 示例，深入讲解各种模式的设计思想、适用场景、优缺点以及不同模式之间的联系，并讨论现代 C# 语言特性对传统设计模式的影响。

本篇文章将作为我的课程学习笔记，也是对整个课程内容的一次系统梳理。文章不会局限于对每个模式的定义进行罗列，而是围绕以下几个问题展开：

• 为什么会出现这个设计模式？
• 它解决了什么设计问题？
• 它的核心思想是什么？
• 在 C#/.NET 中通常如何实现？
• 它有哪些优点、缺点以及适用场景？
• 与其他设计模式之间有什么联系与区别？

希望通过这篇文章，不仅能够完整记录自己的学习过程，也能够帮助读者从设计思想而非模式名称的角度理解设计模式，在实际项目中真正做到根据问题选择设计，而不是为了使用模式而使用模式。

MongoDB 是当前最流行的 NoSQL 数据库之一，它采用文档模型存储数据，通过灵活的数据结构、高性能的索引机制以及完善的分布式能力，广泛应用于互联网应用、大数据处理和实时业务场景。但想真正理解 MongoDB，仅仅掌握 CRUD 操作和查询语法是不够的。MongoDB 背后涉及许多数据库核心概念：文档模型设计、BSON存储、索引原理、WiredTiger存储引擎、MVCC并发控制、副本集以及分片架构等。本文将结合《MongoDB权威指南》，从使用实践逐步深入底层原理，探索 MongoDB 的设计思想以及它如何解决现代应用中的数据存储和扩展问题。

在工业自动化领域，无论是 PLC、HMI、变频器、伺服驱动器、仪器仪表，还是机器视觉设备，你经常会看到Modbus的身影。例如：PLC与上位机通信、PLC与上位机通信、PLC与IO模块通信等等。几乎所有的工业设备都会支持Modbus。在初次接触Modbus后，产生了很多疑问：

• 什么是Modbus？
• RTU和TCP有什么区别？
• 主站和从站是什么意思？

本文将采用问题驱动的方式，带你一步步理解Modbus。

在现代工业化设备中，串口通信大量存在。例如：PLC通信、伺服驱动器、扫码枪、光源控制器、温控器等等。虽然现在Ethernet、TCP/IP越来越普及，但串口因为成本低、稳定、硬件简单等原因，仍然是工业现场最常见的通信方式之一。很多开发者初次接触串口通信，会觉得非常简单：

1
2
3
4
5
6
7
8

SerialPort serialPort = new();

serialPort.PortName = "COM3";
serialPort.BaudRate = 9600;

serialPort.Open();

serialPort.Write("Hello");

但是在实际工业项目中，很快会遇到为什么收到的数据经常不完整？为什么一次Read读不到完整协议？如何设计一个可扩展通信系统？真正困难的不是打开串口，而是：

如何设计一个可靠的串口通信系统。

shadowsocks-windows是一个经典的C#网络代理客户端项目，它将SOCKS5代理、TCP/UDP Relay、加密通信、系统代理管理以及Windows桌面应用结合在一起。本文通过问题驱动的方式阅读源码，深入分析其架构设计、网络通信模型以及C#工程实践，探索一个成熟的开源项目是如何实现高性能、稳定的网络代理能力。

在工业软件、设备控制系统、网络诊断工具开发中，经常需要获取当前计算机的网络状态，例如：

• 当前有哪些网卡？
• 网卡是否连接？
• IP地址是多少？
• MAC地址是多少？
• 网络连接速度是多少？
• DNS、网关、DHCP信息是什么？

.NET提供了一个非常方便的命名空间System.Net.NetworkInformation，其中核心类：

本文将系统介绍如何使用这些API构建一个网络信息采集工具。

在软件开发过程中，代码并不是写完提交之后就结束了。一个项目真正的生命周期，往往伴随着持续的修改、扩展和维护。需求会不断变化，新的功能会不断加入，原本简单的模块可能逐渐变得复杂。如果代码经过良好的设计和整理，随着时间推移，系统会慢慢演变成难以理解、难以修改，甚至无人敢触碰“遗留代码”。

正如软件工程领域常说的一句话：

代码的第一读者是人，第二读者才是机器。

计算机只关心代码是否能够正确运行，而开发人员需要面对代码背后的意图、结构以及未来变化的可能性。一段能够运行的代码，并不一定是一段优秀的代码。

由Robert C. Martin(人称Uncle Bob)编写的《代码整洁之道》正是围绕这一问题展开讨论。本书从变量命名、函数设计、类的职责划分，到错误处理、测试、架构设计等多个方面，系统总结了如何编写更加清晰、可维护的软件代码。

书中提出：

“Clean code always looks like it was written by someone who cares.”

优秀的代码不仅仅是满足需求，更体现了开发者对软件质量的关注。在实际开发中，我们经常会遇到这样的代码：

• 一个几百行甚至上千行的函数
• 一个承担几十种职责的巨大类
• 大量重复逻辑散落在项目各处
• 修改一个小需求，却需要影响多个模块
• 新成员接手项目，需要花费大量时间理解代码

这些问题并不是某一天突然出现的，而是在一次次“先实现功能，以后再优化”的过程中逐渐累积形成的。《代码整洁之道》提供了一套思考方式：

• 如何通过命名让代码表达真实意图
• 如何设计短小、专注的函数
• 如何让类保持单一职责
• 如何降低模块之间的耦合
• 如何通过测试保护代码质量
• 如何让软件具备持续演进的能力

学习整洁代码，并不是为了追求代码形式上的“漂亮”，而是为了降低软件长期维护的成本，让系统能够面对未来的不确定变化。在本文中，我将结合书中的核心思想，并结合实际工程开发中的案例，对《代码整洁之道》进行深入学习和总结，希望能够探索：

什么样的代码才是真正适合长期维护的软件代码？

在 GitHub 闲逛时，我偶然发现了NETworkManager这个开源项目。作为一款网络管理和故障排查工具，它已经积累了超过 8.5k Star，足以说明社区对它的认可。更让我感兴趣的是，这个项目采用 C# + WPF 进行开发，与我当前正在深入学习和实践的技术栈高度契合。因此，我产生了一个想法：通过深入分析 NETworkManager 的源码，探索一个成熟的 WPF 桌面应用是如何进行架构设计、模块划分以及工程实践的。接下来，我将以 NETworkManager 为切入点，逐步拆解它在 WPF UI 设计、MVVM 架构、依赖注入、配置管理、网络通信、异步编程以及工程化实践 等方面的实现，希望能够从优秀的开源项目中学习桌面应用开发的最佳实践。

日志是软件工程中最基础也是最重要的能力之一。无论是Web服务、AI应用、数据处理任务、自动化脚本、后台Worker，都离不开日志。Python标准库提供了logging。它功能强大，但实际工程使用中经常会遇到一些问题：

• 配置复杂
• 格式设置繁琐
• 文件滚动需要额外配置
• 多模块项目初始化麻烦

例如标准logging：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import logging

logger = logging.getLogger(__name__)

logger.setLevel(logging.INFO)

handler = logging.FileHandler('app.log')

formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')

handler.setFormatter(formatter)

logger.addHandler(handler)

logger.info("Application started")

简单记录一条日志到文件，需要很多代码。这也是为什么可以尝试用Loguru。

论文：You Only Look Once: Unified, Real-Time Object Detection

作者：Joseph Redmon, Santosh Divvala, Ross Girshick, Ali Farhadi

论文地址：https://arxiv.org/pdf/1506.02640

Python诞生于1991年，经过30多年发展，已经成为：

• AI领域首选语言
• 数据科学事实标准
• Web开发重要生态
• 自动化脚本核心语言

但Python工程化一直存在一个问题：

代码开发体验优秀，但项目管理体验长期落后。

特别是在依赖管理方面。