You are viewing a single comment's thread from:
RE: Extension Methods - The devious evils lurking in your code
@woz.software To be perfectly clear, our code base is not functional except in places where I use a lot of LINQ to solve problems in a more functional way but not purely functional. The main problem is each extension method developed can have some number of parameters and acts on a domain object from our datalayer and can call n number of methods doing the same in a really unit-test-unfriendly way and also the cyclomatic complexity of each method is far too high for my liking, I have been trying to break it into much smaller functions that do one thing and one thing only well but there's a lot going on in the smalltalk code that I've been porting to C# in each method and it's not very clear cut either.
Yep see where you are coming from. If you are full on OO code then that should be followed. agreed
For testing, the thing I have found when people get full on OO, that functions and dependencies grow to much and so to test something you need to build up complex test objects or driving mocking frameworks.
That is what pushed me away from OO, I like small self contained functions that I can test in a few lines, then plug them together.
I am currently porting old VB to C#, for my sins. Years back when I started this (Its that big) I tried to follow the logic in the VB. No I just try and extract what is really going on, then clean room it. Not follow the original design.
Get a lot cleaner code then
And yep, seen enough extension method abuse in my time lol
"That is what pushed me away from OO, I like small self contained functions that I can test in a few lines, then plug them together." <=== Totally my goal
That's the thing with dependencies, they tend to grow. We have monolithic 'functions' in the smalltalk side of things that are incredibly complex but they can be simplified quite a bit after hours of going down the rabbit hole of code.
Smalltalk bills itself as the original OO language but the smalltalk code I've looked at is way to big. There are smalltalk methods that easily get to be 50-100 lines or more and each method calls a similar sized chunk of code.
Personally I think a single method should be able to be seen and understood with no details hidden and with very few dependencies(classes or other structures) and should be at most 20 lines of code. I think if a single method is longer than that then you probably aren't breaking it into small enough pieces.
I had similar a while back. A 3500 line VB6 function that I got down to 300 lines of tiny functions :)
Btw I read your "Functional programming for the OO developer" series.
Good posts, got me to think more about a more functional approach to writing code.
Glad to hear it helped. You might find this a good talk. Found the other day, eye opening on how the parsers are put together. Great talk, funny guy and so well put across :)
YouTube - Write A Compiler in 24 hours