Timeline for C# pattern to handle "free functions" cleanly, avoiding Helper-style "utility bag" static classes
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| S May 6, 2018 at 22:45 | history | suggested | CommunityBot | CC BY-SA 4.0 | Removed obsolete paragraph |
| May 6, 2018 at 22:44 | review | Suggested edits | |||
| S May 6, 2018 at 22:45 | |||||
| Oct 12, 2017 at 9:59 | comment | added | ipavlu | @Fabio You won my upvote and my heart! :) Great analysis! | |
| Oct 11, 2017 at 23:42 | comment | added | jpmc26 | @RobertHarvey I think Fabio's point in the last paragraph is that if the method contains many branches, you may find yourself tempted to write tests on the callers that touch all the branches internal to the method (which increases your testing burden and would seem to make several tests fairly redundant). A better alternative to consider in those cases is often to transform the calling code so that the function's output is an input (and the function never needs to call the code), but this doesn't always make sense either. | |
| Oct 10, 2017 at 21:23 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 19 characters in body |
| Oct 10, 2017 at 21:14 | comment | added | Robert Harvey | I did some fairly major cleanup on your answer, mostly cosmetic. I'm not sure what your last paragraph is about; nobody worries about how they are testing code that calls the Math static class. | |
| Oct 10, 2017 at 21:10 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 83 characters in body |
| Oct 10, 2017 at 16:25 | comment | added | Frank Hileman | One thing you failed to mention: the growth of such code (helper code) in volume usually indicates the developers are failing to see opportunities for code reuse. In most similar code bases I have seen, there were many opportunities to reduce the amount of code, with a bit of work on factoring out common functionality, or eliminating superfluous complexity. | |
| Oct 8, 2017 at 18:33 | comment | added | William | Re "addition of new method" aspect (b), I agree completely. I worded that aspect poorly. More classes are certainly not a problem. (As you could see from the answer I'd proposed, more classes are a solution.) The problem is when the breakdown into more classes is done badly or incompletely, so that instead of one static class with 100 methods, you might have two static classes each with 50 methods. Even if the resulting smaller bag-classes have "better" names, they still hide the domain entities within a non-entity that would not exist if "free functions" had an explicit language construct. | |
| Oct 8, 2017 at 18:15 | comment | added | William | Re "addition of new method" aspect (a), the "general idea" of this specific kind of static class is identical to the "general idea" of a namespace. The only important domain entity in this particular context is the "free function"-like method. The underlying issue is that C# (for very good & pragmatic reasons documented by Eric Lippert himself) does not have a specific language construct for "free functions". Static classes are used to contain these entities, because C# simply requires it. | |
| Oct 8, 2017 at 17:36 | comment | added | William | Re "static class as namespace", the fact it's a common pattern doesn't mean it's not an anti-pattern. The method (which is basically a "free function" to borrow a term from C/C++) within this particular low-cohesion static class is the meaningful entity in this case. In this particular context, it seems structurally better to have a sub-namespace A with 100 single-method static classes (in 100 files) than a static class A with 100 methods in a single file. | |
| Oct 8, 2017 at 17:08 | comment | added | William | Okay, there was some confusion here. The question's first list of items is not a list of alleged problems. It's a list of common characteristics of the specific methods I'm reviewing. It's context to help answers provide more applicable solutions. I'll edit to clarify. | |
| Oct 8, 2017 at 9:48 | history | edited | Fabio | CC BY-SA 3.0 | added 64 characters in body |
| Oct 8, 2017 at 5:53 | comment | added | Fabio | @Paul, Open/Close principle can not be applied for static classes. That was my point, that SRP or OCP principles can not be applied for static classes. You can apply it for static methods. | |
| Oct 8, 2017 at 5:21 | comment | added | Paul | It’s not a SRP violation, but pretty clearly an Open/Closed Principle violation. That said, I’ve generally found the Ocp to be more trouble than it’s worth | |
| Oct 8, 2017 at 5:09 | history | answered | Fabio | CC BY-SA 3.0 |