#GROOVY METHOD MAP CODE#

To much ambiguity can be a form of code smell. Yes, It may also be the case you need to rethink some abstractions. If you have multiple args each that could be varying types and or null… well this is where dynamic languages can shine.However, if your method has more than one arg, and any of them might be null this approach falls apart pretty quick.The logic is right on the line where the method is being invoked, no need to go looking or having to reason about java method signature fallbacks etc. Date myNewDate = incomingJsonDate ? parseToDate(incomingJsonDate) : null might be better than adding the extra parseToDate signature to handle the null case if you are only invoking the method in a few places.How many args does your method accept and how much variation in the types of its args are there.

If just one or two and this is a private method - probably NBD either way - do what feels better for those specific one or two spots.

If a lot, a strictly defined method signature sure goes a long way to a predictable and stable API.

How many other pieces of code will invoke this method?.How important are the performance benefits of for your case?.So is the static typing here worth it?Īnd here we have one of those classic “it depends” scenarios. The null situation falls into the less specific signature, and the others go to the one more fitting for their specified types. The ambibuty is replaced with a specificity cascade. To be fair so could body, but at least the service class name or the method name might give a hint as to what that would be.Īdding a type can inform or contextualize the name, but don’t stop at that, naming arguments well can help a lot! 1ĭef sendAnEmail(String body, String recipients) In this method params could literally be anything 😢 1

It’s even worse if no type is specified at all, which Grails totally allows! I know the root of this is in part because Grails controllers use that for request parameters, and just passing that whole thing along to a service method can be tempting, but the type of Map and name of params gives the person working on the service method no useful information about what should be in that map. Map params as an argument to a service method is something I have frequently seen, and drives me a bit crazy now. The naming stuff could probably go without saying except that Grails sits in this spot where a lot of the people I have worked alongside in Grails projects came either from either a Java background, a Rails background, or a JavaScript background, and those camps seem to clash a bit awkardly when it comes to working in Grails together.īoolean isThisThingLegit( Thing thing, Map propertiesToCheck) Good naming is just generally good practice - this is not Groovy or Grails specific of course - but given that Java programs are often overly or painfully verbose in their naming, I have seen developers in Grails sometimes over-correct, naming things to way to vaguely. Whenever possible specify the return type of service methods and the types of arguments they expect.īoolean isThisThingLegit( Thing thing, AppUser user) Being a bit more explicit with defining the method signature can be very helpful, when used with this constitutes a sort of test that automatically runs at compile time as well. Methods here tend to be reused or are set up to be used by multiple controllers or whatever. In Grails the service layer is where a lot of your business logic is supposed to live. I don’t tend to spend much time fighting with the compiler in Groovy. Groovy lets you just def everything, or even omit types declarations altogether and that can be great at times. In Grails services specifically I have found that it is typically better to be a bit more Java like when possible. That ends up being covered mostly in the last section of this post, but found some other best practice stuff buried in a readme file I had written a while back that was also relevant, so just posting that all together, ‘cause why not. After a bug I recently introduced to production was fixed, I set out to write about what happened as a sort of post-mortem exercise.

Groovy method map