Comments on: A Refactoring: Explicit Modeling And Reducing Duplication

By: Augi

Augi — Thu, 30 Sep 2010 06:52:28 +0000

The first code example can be easily cleaned using null-coalescing operator:

return GuardClause1(something) ?? GuardClause2(whatever) ?? Step1(whoCares) ?? Step2(doesntMatter);

The solution you proposed in “Reducing Duplication” paragraph is actually well known as Template Method pattern: http://en.wikipedia.org/wiki/Template_method_pattern

By: derick.bailey

derick.bailey — Thu, 30 Sep 2010 03:10:26 +0000

@Michael and @Mike Murray

I’ve been reading up on monads and have put together some examples to try and learn about them, specifically with Maybe – your article was VERY helpful, Mike Murray…thank you for the link!

i can certainly see how the Maybe monad would be an option for the original code… however, I don’t think it would be the best option. i think a monad, in general, though, could create a potentially more elegant solution – just not the Maybe monad.

Assuming my understanding of monads is correct (see my monads post that i just put up), I’ll be posting what I think is a better monadic solution that still accounts for everything I want from explicit modelling, etc, in this post. :)

By: Mike Murray

Mike Murray — Wed, 29 Sep 2010 16:06:14 +0000

My first thought when looking at the code was also to perhaps utilize the Maybe Monad. I’ve been looking into that recently, and blogged about it: http://murrayon.net/2010/09/maybe-from-murray-monads.html

I will have a follow up blog post by the end of the week with a link to a different Monad library that I put together instead of the one I introduced in the above linked to blog post.

By: David Clarke

David Clarke — Wed, 29 Sep 2010 01:11:35 +0000

To me a guard clause is the Release version equivalent of an Assert. A guard clause says if one of my inputs is not valid then I cannot continue and should either return an error or throw an exception. Maybe I’m misinterpreting your example code but to me your method lacks cohesion and instead of refactoring to have actual guard clauses and higher cohesion with (apart from the guard clause returns) a single return you have instead used artifice via a func to give the appearance of a single return. Just saying.

By: derick.bailey

derick.bailey — Mon, 27 Sep 2010 15:22:20 +0000

@john – thanks! :)

i was 50/50 split on whether or not to do the one return statement change. in this simple case, it’s not really a big deal either way. i decided to go with it just to make the point, but i wouldn’t care either way if the code were really this small.

i agree on early returns, when they are from guard clauses. otherwise, i try to keep the code small enough that an early return is not really needed. :)

@michael – i’ve been reading more about monads and Maybe and i’m intrigued…

i can see some potential value here, though i’m not sure an “Empty” value is what i’m looking for. i think the idea of a monad for piping these calls together is a potentially good idea, though. i’m going to have to continue doing some reading and experimenting to really figure out this monad stuff in c#, and see if i can come up with a monad version of the solution.

thanks for the suggestion! you’ve given me something to obsess over and something new to learn, for a while :)

By: John Sonmez

John Sonmez — Mon, 27 Sep 2010 15:02:00 +0000

Excellent post!

As soon as I saw the first part of the code, I was pretty sure you were going to go the Func<> way!

The only thing I disagree with is the one return refactor. I am fan of early return. Although, I do agree with you that many returns is a problem.

Nice refactor though, I see this kind of code many times and it is not immediately obvious how to refactor it.

By: derick.bailey

derick.bailey — Mon, 27 Sep 2010 00:57:08 +0000

hmmm…. ok – i’m pretty sure i did completely miss what you were trying to suggest. i’m going to have to read up on monads in c# and see if this would be beneficial here… cause i think it might be fun, at least. :)

By: derick.bailey

derick.bailey — Mon, 27 Sep 2010 00:51:27 +0000

michael – i haven’t even heard of that, let alone tried it. :) is there a Maybe built into .NET 4? we’re still on .NET 3.5, but there seem to be plenty of articles on building a Maybe implementation.

from what i’ve ready in the last 10 minutes, it looks like Maybe is used often as a null-object pattern and/or a way to ensure that you never have null references in your code. I can certainly see the advantage of that, but in this case I don’t think a null object pattern would model the result the way i want to see it.

the core of the logic here, is “if the step fails, return the result immediately, without processing any additional steps”. by using a Maybe we would have to change our if statement in ProcessSteps to “if (result.HasValue)” which does not tell me anything other than the object having a value or not. By modeling the result with a status and checking to see if that status equals a well known Error type (an enum in this case), I know what the value means instead of only knowing whether or not there is a value and then having to implicitly understand what the presence of a value indicates.

… or did i completely misunderstand your suggestion? Feel free to share some code on how you would recommend using this (post the code on Pastie.org or another site like that, and link to it here in the comments). I’d love to understand what you’re trying to say and see when / where this would be useful.

By: Michael Chandler

Michael Chandler — Mon, 27 Sep 2010 00:03:26 +0000

Did you try using the maybe monad?