本地功能和SOLID原则C#

Die*_*nio 4 .net c# solid-principles c#-7.0

我知道从C#7.0开始我们可以创建本地函数,但是如何通过SOLID原则来实现一个好的设计模型呢?

我的意思是,这不会破坏单一责任原则,在另一个功能中添加一个功能吗?

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

可能我们只需要重新编写方法的某些部分而不是改变它的整个功能.

Kon*_*man 6

我们能够创建局部函数,但这与实现良好设计模型的 SOLID 原则有何关系?

本地函数可以帮助您创建良好的代码,使其更具可读性和可维护性。不过,这与 SOLID 并没有真正的关系。

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

为何如此?单一职责原则指出“每个模块或类都应该对软件提供的功能的单个部分负责,并且该职责应该完全由类封装”。如何组织类内的代码不会改变责任级别或实现的封装。


Mic*_* II 6

我在某种程度上同意你的意见.这里的答案是否支持所谓的上帝(小g)方法,我个人觉得,就像你一样,这些方法应该准确无误.

也就是说,本地功能实际上可以支持SOLID.一个例子是能够轻松连接来自事件的回调,使方法具有单一责任,关闭范围并最小化错误.这可以通过当地代表来完成,但不是那么干净或直截了当.

递归本地函数也符合SOLID.在许多情况下,您必须编写两个方法来完成一个操作,因为它是一个递归方法,现在您可以将所有逻辑放在一个位置.有些时候,根据传递的数据和类型,本地函数实际上会更好地执行,因为它们是借用范围变量.

这只是两个快速的例子,可能不需要辩论或许多代码来说明本地函数如何更好并且与SOLID内联,但还有更多.

本地函数还可以轻松地对代码进行轮询,并使方法难以管理/读取和拆除SOLID原则.就像任何其他C#组件一样,我们有责任选择何时以及为什么我们使用本地功能和SOLID以及其他开发实践/指南应该在我们这样做时考虑.我不同意让方法更长,更复杂,或只是为了确定方法而做一个以上的工作.