9

I know that starting from C# 7.0 we are able to create local functions, but how is this related with the SOLID principles to achieve a good design model?

I mean, doesn't this break the Single Responsibility Principle, adding a function inside another function?

We can delegate that simple task to be computed either in another method or in another new class? and for the Open-Closed principle which allows me to inherit from SomeClass to modify it is now more complex, I now need to rewrite the entire base function instead of just one part of my code?

Probably we just need to re write some part of the method instead of changing the whole functionality on it.

Liam
  • 27,717
  • 28
  • 128
  • 190
Diego Osornio
  • 835
  • 1
  • 10
  • 20
  • Please read about it here: https://en.wikipedia.org/wiki/Nested_function The concept is not new, not even particular to C# 7.0. I used the concept around 1990 with Pascal. – PepitoSh Jun 01 '18 at 04:38
  • 6
    For starters, SOLID applies to *classes*, not to methods inside those classes. Whether a method does its job through a single statement, a page full of code or by calling local functions is not material to the design and interface of the class. Obviously, "big" methods that do "lots of stuff" are a possible sign of a maintenance problem, but that's true whether you pray at the church of SOLID or not, and local functions do not immediately make a maintenance problem. They *may* make candidates for new methods or new classes, or they may not. – Jeroen Mostert Jun 01 '18 at 14:06
  • 2
    For a counterpoint, consider a world where you'd always split off every local function to its own method instead, and perhaps repackage those into new classes, regardless of your motivation for why you'd do this. Now you have an entirely different problem: you're responsible for keeping those things available and working to clients. You could, of course, choose to make them private or hidden in some other way to avoid this burden -- but then this is exactly what you achieve with local functions, no? – Jeroen Mostert Jun 01 '18 at 14:24

3 Answers3

9

I agree with you to an extent. Whether the answers here support so called god (little g) methods or not I personally feel, just as you do, that methods should be precise in what they do.

That said, local functions can in fact support SOLID. One example is the ability to easily wire up call backs from events giving the method single responsibility, close the scope, and minimize error. This can be done with local delegates but it isn't as clean or straight forward.

Recursive local functions are also in line with SOLID. There are many situations where you have to write two methods to complete one operation because it's a recursive method and now you can put that logic all in one place. There are even times, depending on the data and types being passed around, that local functions will actually perform better due to the fact they are borrowing scoped variables.

This is only two quick examples that probably don't require a debate or lots of code to illustrate how local functions can be better and inline with SOLID but there are more.

Local functions can also easily polute your code and make methods hard to manage / read and tear away from SOLID principles. Just like any other C# component we have a responsibility to pick and choose when and why we use local functions and SOLID as well as other development practices / guidelines should be considered when we do. I don't agree with making methods longer, more complex, or having more than one job to do just for the sake of scoping methods to it.

Michael Puckett II
  • 6,586
  • 5
  • 26
  • 46
6

we are able to create local functions, but how is this related with the SOLID principles to achieve a good design model?

Local functions help you create good code by making it more readable and maintainable. That's not really related to SOLID, though.

does not the Single Responsibility is broken adding a function inside another function?

How so? The Single Responsibility Principle states that "every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class". How you organize the code inside the class doesn't change the level of responsibility or encapsulation implemented.

Konamiman
  • 49,681
  • 17
  • 108
  • 138
2

Sometimes you do not need to pollute your base context with another method which it will use just in one method, But you need that as an anonymous method to do something in your code, I recommend you to take a look on this

Mohammad Nikravesh
  • 947
  • 1
  • 8
  • 27