Utils anti-pattern & AutoMapper
These are more for my reference purposes – hopefully you’ll find them useful:
If you’re about to name a class **Util; think harder – there is a better name that discribes what that class is for:
Chriss Missal has some advice for you
Faced with the prospect of heaps of left hand side => right hand side code in your DTO of anti-corruption layer? Consider Jimmy Bogard’s Automapper
Functions with side effects are just rude!
Today I fell into a trap when using a function that had a side effect – it unexpectedly changed an input parameter; causing a later statement to fail. Debugging took an age!
For example, consider the following function:
1 | string StringReplace(string haystack, string needle) |
If this function is side-effect free, we can use it without fear like this:
1 2 3 4 5 6 | string menagerie = "cat,dog,bee,llama"; string catFreeMenagerie = StringReplace(menagerie, "cat"); string beeFreeMengerie = StringReplace(menagerie, "eric"); Assert.AreEqual(",dog,fish,llama", catFreeMenagerie); Assert.AreEqual("cat,dog,,llama", beeFreeMengerie); |
However, if StringReplace() had the side effect of also changing the passed in haystack, then the second Assert would fail, because the first StringReplace has the unexpected side effect of changing one of its arguments.
Evans in the DDD book has quite a bit to say about this; arguing that having side effect free functions goes a long way towards making a supple design
Side effect free functions also make testing & refactoring easier (less state to worry about etc)
Remember, function that changes parameters entrusted is rude, and should not be trusted!
