Functional Programming - kitlau's blog

JUL

如何使用 Optional 模式解决 C# 中的烦人的空引用问题

Optional模式通过封装可选值避免显式null传递，结合编译期类型检查和链式调用机制，可系统性规避null reference异常风险，其核心优势体现在：1）函数式编程范式强制处理缺失值，如GroupBy操作时通过Map/Reduce自动传递空值状态，无需冗余的null判断逻辑；2）代码结构显式暴露可空性，如Person类的Author属性声明为Option类型而非Person?，在编译阶段即约束调用方必须处理空值场景；3）通过嵌套的Map/Reduce方法构建安全链式调用，在作者姓名长度计算等复杂场景中避免多层null检查的代码膨胀。相较于C# Nullable特性，Optional模式通过类型系统将空值处理逻辑从运行时提前到编译期，但代价是引入函数式编程的学习成本和代码复杂度提升，适合对安全性要求高且团队熟悉函数式思维的中大型项目，而Nullable特性则更适合需要快速迭代的简单业务场景。--Qwen3

JUL

如何使用 CSharp 表达式树？

这篇博客深入探讨了CSharp表达式树的核心概念与实践应用，通过代码示例与结构化图示揭示了如何将代码逻辑转化为可操作的数据结构。文章从基础概念出发，解析了表达式树如何通过树形结构表示运算逻辑并转化为可执行代码，特别展示了`1+2*3`等表达式如何通过优先级拆解为嵌套子树。通过对比`Func<T>`与`Expression<TDelegate>`的本质差异，揭示了编译器如何将lambda表达式转化为可动态解析的抽象语法树，并演示了如何通过`Compile()`方法将表达式树转化为可执行委托。重点在于通过手动构建表达式树解决代码维护难题，以动态属性访问为例说明如何避免硬编码字符串导致的维护困境，通过`ParameterExpression`与`MemberExpression`的组合构建出可动态解析的表达式逻辑。文章指出这种动态构建方式虽然能灵活应对变化需求，但可能牺牲代码可读性，建议开发者在实际应用中权衡利弊。最后抛出思考：当面对动态查询需求时，如何在表达式树构建与传统代码结构之间找到最优解？是否还有其他技术方案能在保持灵活性的同时提升代码可维护性？这些问题或许会启发读者重新审视代码设计中的动态性与静态性的平衡点。--Qwen3

C# Functional Programming lambda expressions expression trees Dynamic Code Generation Property Access