Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Tuesday, February 19, 2013

Simple Generic Cast Method for Rice

Overview

As things are now, if one wants to cast a Document or BusinessObject to access a method, one has to do something like:


This is a pretty ugly way to handle casting. It's also difficult to read. The added parenthesis make it difficult to determine what type the method is being executed on.

Using generics, it's possible to add a method to the BusinessObjectBase.java in KRAD which will make casting much nicer.

Here's what I did

I added a new cast() method to the BusinessObjectBase.java


The result is a new class that looks like:


Now I can cast objects like this:


The result is a much cleaner cast that is easier to read. At least, it is to me. I'll leave it up to you whether you think it is easier or not. I know what you're thinking. "This should be in Object!!" Agreed. It should be.




3 comments:

  1. Meh, I dunno. Agreed, I think it's pretty kewl. But I'm not seeing how much is bought with it, honestly. As I read the article I was holding out for you, honest, I think generics can create some pretty good solutions -- and cast is definitely one that can be annoying.

    But when I placed both lines of code on top of each other in a text editor I see they have the exact same number of brackets as each other; namely: 6. The only difference is that you've replaced 2 parentheses with 2 chevrons and you've re-ordered the wording such that instead of saying "make an AccountingDocument from this document and then call getSourceAccountingLine" you are now saying "take this take document and turn it into an AccountingDocument and call getSourceAccountLine".

    Not only are they virtually identical but the new technique involves slightly more characters of typing; namely: 4 more.

    Additionally, we now have additional underlying source-code we have to worry about (the generic casting method) -- granted, not a very big concern but it is one nonetheless.

    Finally, it "breaks the mold" (for, seemingly, a very low return if any); millions of java developers around the world know immediately at a glance what the first technique is doing; but the second technique, while also quite clear in general, will leave many of them wondering if some other magic is being hidden inside the cast()-method -- enticing them to go look, breaking OO and stealing time from them.

    Aside from the extra 4 characters (which are 'cast' and are largely mitigated by auto-suggest), if this approach had been used by the industry since it's inception I'm sure it would work just fine. My only criticism isn't it doesn't buy enough to be worth it at this point in time since the first approach is so engrained in us.

    Just my $0.02. I really liked reading about it and I think it's always good to look for creative solutions to problems even if the solution is criticized. My criticism is likely to encounter yet more criticism. Haha. :D

    ReplyDelete
    Replies
    1. Wow. That was a well thought out and verbose response. I thank you for it. I have to disagree though. The biggest reason for the change is that this way is more readable. Someone else has already responded that they thought the opposite which is that it's not more readable. Personally, I think it is comparable to a static_cast in C++ except the brackets are in back instead of in front. If you think about it though, that's exactly what it looks like.

      True, it may be more characters, but I think that's a particularly bad way to look at readability of code. Compare the two methods:
      public int a(int o1, int o2) {
      return o1 + o2;
      }

      public int add(int o1, int o2) {
      return o1 + o2;
      }

      One of these methods is

      add(1, 2);

      the other is

      a(1, 2);

      Which is more readable in the end? Which one cost you 2 characters? For the sake of 2 characters, you earned yourself some readability. I think that's the case here. I'll set another example. The article uses only one cast for simplicity. Let's try 2 casts:

      SourceAccountingLine sourceLine = ((AccountingDocument) ((TransferOfFundsForm) form).getDocument()).getSourceAccountingLine();

      Compare that to:

      SourceAccountingLine sourceLine = form.<TransferOfFundsForm>cast().getDocument().<AccountingDocument>cast().getSourceAccountingLine();

      Which is more readable now? Should we add 3?

      Delete
  2. Well you are certainly entitled to your own (wrong) opinion.

    I'm KIDDING! :D

    I should point out that while one of my concerns is certainly readability, number of characters isn't a primary concern but only one I mentioned to explain my thought process as I was thinking about your proposal -- I agree wholeheartedly with your argument that slightly more verbosity can add to readability.

    My main argument was really this (fixed for typos and re-worded to better incorporate an idea I'd mentioned earlier but wasn't clearly integrated into the original sentence):

    "if this approach had been used by the industry since it's inception I'm sure it would work just fine. My only criticism is that it doesn't buy enough to be worth it at this point in time since the first approach is so engrained in us as to NOT break OO whereas the second approach does (encapsulation) -- and it's easily argued that the readability of either of them is really just a personal-preference; the preference of one over the other is really just a factor of which one a particular developer has been exposed to the most"

    Hopefully that makes my point more clearly.

    In any case, you have way more time on the books than I -- so I defer to you now and honestly say I hope someday to see this in real Kuali code and have that "AHA!"-moment, as in: "By the gods, he's right, this *IS* easier to read!"

    :D

    ReplyDelete