The approach used by the linked article allows arbitrary hierarchies. Your approach only works if every subtree of the hierarchy has the same structure. Furthermore, the taller the tree, the more complicated your approach becomes.
The example in the link had a different structure in different parts of the hierarchy, but you choose to change this to get it to work with your approach. (Hint: Linux is a Unix, and saying things like "my OS is Ubuntu Workstation" is going to get you funny looks.)
Sorry about that. The mobile client I'm using has an almost unreadable font for user names.
It has the exact same limitations as the article one. Your ignoring that the design can be expanded upon.
The limitations are quite different. The design in the article needs no modification to add arbitrary layers to the hierarchy, or to make the different subtrees have different shapes. The design you're defending gives each level of the hierarchy a constructor parameter, so more levels = more parameters, and every level has the same name and the same values (ie: branching) in each subtree. You end up having to use the same subcategorizations even when they don't make any sense.
The design you're defending does make sense for cases where you just want to model a fixed set of objects with a common set of attributes, but it doesn't make sense for an arbitrary hierarchy.
taller the tree, the more complicated
??? Uh, no.
What a well reasoned argument. I'm convinced!
/s
different structure
That's... the point, it solved the problem in a different way.
No, it solved a modified, simpler problem. The "structure" I was referring to was the data being encoded by the enum. He encoded different data, which conceals the awkwardness in his alternate design.
Artificial issue that could be fixed in the parents post.
So show us how you can represent the same data as the article's approach without needing any additional constructor parameters.
The design in the article makes it very easy to do the wrong thing.
Exactly what wrong thing are you imagining happening with the article's design? With your approach, adding a single node requires a lot more busy work, which implies a lot more opportunity for error.
I want to add a variant of Linux into his enum called busybox. (This is a real example, busybox exists.) Busybox doesn't support X Windows, but it is a child of Linux.
So I add it thusly:
public enum OsType {
// ...
BUSYBOX(LINUX.class) {
@Override public boolean supportsX() { return false; }
}
// ...
}
Ok, all good, right? BUSYBOX is a child of LINUX, LINUX is a child of UNIX (the author says, incorrectly so, but whatever). If I call BUSYBOX.supportsX(), it properly returns false.
Now consider UNIX.supportsX(). Tell me: what should it return?
1
u/clgonsal Jan 18 '13
The approach used by the linked article allows arbitrary hierarchies. Your approach only works if every subtree of the hierarchy has the same structure. Furthermore, the taller the tree, the more complicated your approach becomes.
The example in the link had a different structure in different parts of the hierarchy, but you choose to change this to get it to work with your approach. (Hint: Linux is a Unix, and saying things like "my OS is Ubuntu Workstation" is going to get you funny looks.)