局部函数和 SOLID 原则 C#答案

【问题标题】：Local functions and SOLID principles C#局部函数和 SOLID 原则 C#
【发布时间】：2018-11-11 03:41:27
【问题描述】：

我知道从 C# 7.0 开始我们可以创建本地函数，但这与 SOLID 原则有什么关系以实现良好的设计模型？

我的意思是，这不是违反单一职责原则，在另一个函数中添加一个函数吗？

我们可以将这个简单的任务委托给另一个方法或另一个新类来计算吗？对于允许我从 SomeClass 继承来修改它的 Open-Closed 原则现在更加复杂，我现在需要重写整个基本函数而不是我的代码的一部分？

可能我们只需要重新编写方法的某些部分而不是更改其上的整个功能。

【问题讨论】：

请在此处阅读：en.wikipedia.org/wiki/Nested_function 这个概念并不新鲜，甚至对于 C# 7.0 来说也不是特别的。我在 1990 年左右与 Pascal 一起使用了这个概念。
对于初学者，SOLID 适用于类，而不适用于这些类中的方法。方法是否通过单个语句、充满代码的页面或通过调用本地函数来完成其工作对类的设计和接口并不重要。显然，做“很多事情”的“大”方法可能是维护问题的迹象，但无论您是否在 SOLID 教堂祈祷都是如此，并且本地功能不会立即产生维护问题。他们可能成为新方法或新类的候选者，或者他们可能不会。
作为一个对立点，考虑一个你总是将每个本地函数拆分为自己的方法的世界，并且可能将它们重新打包到新的类中，而不管你为什么这样做.现在你有一个完全不同的问题：你负责保持这些东西可用并为客户工作。当然，您可以选择将它们设为私有或以其他方式隐藏以避免这种负担——但这正是您使用本地函数实现的，不是吗？

【解决方案1】：

有时您不需要使用仅在一种方法中使用的另一种方法来污染您的基本上下文，但是您需要将其作为匿名方法在您的代码中执行某些操作，我建议您查看@987654321 @

【讨论】：

【解决方案2】：

我们能够创建局部函数，但这与 SOLID 原则有什么关系以实现良好的设计模型？

本地函数通过提高代码的可读性和可维护性来帮助您创建良好的代码。不过，这与 SOLID 并没有真正的关系。

在另一个函数中添加一个函数不会破坏单一职责吗？

怎么会？ The Single Responsibility Principle 声明“每个模块或类都应该对软件提供的单个功能部分负责，并且该职责应该完全由类封装”。您在类中组织代码的方式不会改变责任级别或实现的封装。

【讨论】：

【解决方案3】：

我在一定程度上同意你的看法。这里的答案是否支持所谓的上帝（小g）方法我个人觉得，就像你所做的那样，这些方法应该是精确的。

也就是说，本地函数实际上可以支持 SOLID。一个例子是能够轻松地连接来自事件的回调，赋予方法单一职责，关闭范围，并最大限度地减少错误。这可以通过本地代表来完成，但它不是那么干净或直接。

递归局部函数也符合 SOLID。在很多情况下，您必须编写两个方法来完成一个操作，因为它是一种递归方法，现在您可以将所有逻辑放在一个地方。有时，根据传递的数据和类型，局部函数实际上会因为它们借用作用域变量而表现得更好。

这只是两个简单的示例，可能不需要辩论或大量代码来说明本地函数如何更好地与 SOLID 内联，但还有更多。

本地函数也很容易污染您的代码，使方法难以管理/阅读，并背离 SOLID 原则。就像任何其他 C# 组件一样，我们有责任选择何时以及为何使用本地函数和 SOLID 以及其他开发实践/指南。我不同意让方法变得更长、更复杂，或者仅仅为了确定方法的范围而要做不止一项工作。

【讨论】：