(I am currently using groovy but it should apply to most OO languages so I also put the langauge-agnostic tag)
I try to program in a function style which also includes method chaining and avoiding variables. Therefore I often find myself writing code with the with method in groovy that every object has. It works likes this:
someobject
.doSomething()
.doEvenMore() //this results in an object that I need check for some condition, e.g. a String
.with { String result ->
if (result != "I AM A CORRECT RESULT")
throw new Exception("assertion failed")
else
return result //need to do this because else the closure will return null
}
.doAnotherThingOnTheResult()
//and so on
(See also https://codereview.stackexchange.com/questions/57676/better-way-to-assert-correct-return-values-in-groovy for a real life example I asked some time ago)
This is rather unconcise so I was searching for a better way to check for conditions without using to have with. I came up with an idea I would like to hear your opinions to.
That is, an method that all objects have and that can be used like this:
someobject
.doSomething()
.doEvenMore() //this results in an object that I need check for some condition, e.g. a String
.assertTrue (new Exception("custom exception")) { it == "I AM A CORRECT RESULT" }
.doAnotherThingOnTheResult()
//and so on
or for default behaviour with a default exception type
someobject
.doSomething()
.doEvenMore() //this results in an object that I need check for some condition, e.g. a String
.assertTrue { it == "I AM A CORRECT RESULT" } //results in AssertionException or sth similiar
.doAnotherThingOnTheResult()
//and so on
In groovy I can make it that every (new) created object is decorated with such a method. What do you guys think about it? Are there better ways or should I stay with the with method?
7
First, I think it is a good idea to refactor the with part into its own function. It makes IMHO the code easier to read, and it corresponds to the “Single Level of Abstraction” principle, which is one characteristic of clean code.
Second, if it is a good idea to decorate every class of your program with this additional method, depends. I would do this only if you need this function all over your whole program, in many classes. Otherwise, I would restrict it to the classes which really use the method. This helps to avoid unintentional naming collisions.
I’m on the fence whether your code should be called a fluent interface or a train wreck. Either way, method chaining should not be overused because it decreases readability. I have first hand experience from a project where I found myself writing wrapper functions to shorter some chains. Furthermore, some folks such as Robert C. Martin in “Clean Code” Chapter 3 suggest that one should strive to separate commands from queries, which your code clearly does not do. I don’t say this is an absolute truth, but you should be more careful with method chaining. After all, functional style does not say that one must chain everything but rather that one should strive to build code from functions that do not use implicit state. So, of course you should follow Doc Brown’s suggestion and refactor with into a separate function, but you should also check if you’re overusing method chaining.
For example, it may be better to assign the result of computation before invariant check to a variable, then verify the variable satisfies the check, and then continue with computation. You may even decide to wrap several commonly used sub-chains into separate functions with a descriptive name.
If it was Haskell, you could have returned Maybe.Some(yourobj) from each method and rely on compiler to halt computation as soon as Maybe.None is returned. This way, a verification method would return yourobj unchanged if it is OK, and return None otherwise. In Java there is a very similar thing called Optional, and this article explains how it can be used to solve your issue in a different way.
0