To paraphrase Bill Clinton's famous bit of reasoning, it comes down to how one defines "is". In traditional OOP, we're accustomed to equating class inheritance with the logical "is a kind of" relationship. However, that's not always necessary or at least not the whole story. As of late, I've been seeing a philosophical push in the Java world toward designing and coding to interfaces (quite prominent in what's coming out of Google now). In Java, we have 2 ways of looking at types inheritance: classes and interfaces. Sometimes multiple inheritance in interfaces and single inheritance in classes is presented as Java's solution to the diamond problem. But we can think of it in other ways too: interfaces represent the real logical contract that in some ways model "real world" (SortedSet extends Set) and classes and their hierarchies may or may not mirror those relationships, but really don't have to (adapter pattern). For example, in GWT, there is a very strong emphasis on small behavior-descriptive interfaces, such as HasText (getText, setText). API that deal with "things that hold text" then generally talk about HasText objects, rather than TextBoxBase or whatever. And indeed, when looking at the widget class hierarchy, you'll notice that they don't always parallel the behavior interface hierarchy.
So back to the original example. I made Person a Pair<String, Pair<String, Long>> kind of on purpose to demonstrate that the use of tuples to describe the underlying object graph and internal arrangement of properties within that graph is kind of irrelevant (is an internal implementation detail), even if it happens to be visible to the outside world. I suppose it would have been more clear to also describe a set of interfaces, such as HasAge (getAge) and HasName(getFirst, getLast) and apply them to Person. As I noted in another post, I'm not discounting Lombok. It can and does reduce boilerplate -- much the same boilerplate as the structured typing approach. The difference (benefit perhaps) here is that everything is expressed within the confines of "standard" Java language spec. It may look a little unusual, but there is some thought behind using inheritance this way (see above) and everything about it can be understood from looking at the source code. When using Lombok, the source code will be insufficient to understanding what will happen at runtime. I think both approaches have their respective merits and drawbacks. Alexey ________________________________ From: Reinier Zwitserloot <[email protected]> To: [email protected] Sent: Fri, February 18, 2011 10:56:34 PM Subject: Re: [The Java Posse] using structured typing to reduce Java boilerplate My own project, but: Why the heck jump through all those hoops? Download lombok and you can just do this: @Data public class Person { private final String first, last; private final int age; } And toString, getters, constructor, equals/hashCode are all taken care of. More to the point: A person is NOT a Pair<String, Pair<String, Integer>>. Or at least, that's not a practical way of looking at it. Why isn't it a Pair<Integer, Pair<String, String>>? Pair doesn't say a whole lot, and it doesn't add anything particularly useful for general processing. i.e. a List<String> doesn't say a whole lot either, but at least that way you can feed your list into code that can do stuff to lists, and that code doesn't need to care about what kind of list this is. The amonut of generic methods that work on pairs is rather limited, so why do it (Other than saving yourself some boilerplate, for which I'm going to stick with: Project Lombok is a much nicer solution for that problem). -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
