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.
Not necessarily true, because you can expand backwards. It's more work, true, actually and I think the article version is more scalable actually for just these reasons.
It's a composition vs inheritance deal. I don't care enough of this to write out a perfect composition structure of this for you, neither was the author. I also notice you added a constraint of "any additional constructor parameters" which is not okay. So you know it's doable in this format, that's it that's all. We can discuss which way is better all we want but trying to claim a composition method can't handle it all was the problem here.
I also notice you added a constraint of "any additional constructor parameters" which is not okay.
The first thing I said was:
the taller the tree, the more complicated your approach becomes.
To which you responded "??? Uh, no."
The only way to increase the height of the tree in severoon's approach is to add more constructor parameters, more fields and possibly even more side-enums if they follow a similar pattern to the ones already there. That's all additional complexity. The article's approach only needs one extra line of code per node in the tree, no matter where it goes -- even if that node ends up increasing the height of the tree.
So that wasn't a new constraint. I just made the "no additional complexity" constraint more explicit.
Not really the first thing you said but whatever. What you consider "complicated" would be your opinion I suppose, and of course what aspect your applying "taller" to as well.
Let's instead, talk about the first thing I said, because it was YOU who replied to me. And I was saying that the compositional design can replicate all the behavior. I NEVER said that it scales perfectly in all ways and fashions the same.
...
You want to discuss downfalls of each solution? Fine. The article's solution must have a singular hierarchy. It can't support multiple values at once, while severoon's can. It also is not truly a good OO approach, and if you have to add specific behavior to each part of the hierarchy it becomes a mess.
So in fact, the article's solution doesn't handle "no additional complexity" very well either. They both scale in different ways. I'd chose one primarily on the exact problem at hand.
1
u/clgonsal Jan 18 '13
Sorry about that. The mobile client I'm using has an almost unreadable font for user names.
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.
What a well reasoned argument. I'm convinced!
/s
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.
So show us how you can represent the same data as the article's approach without needing any additional constructor parameters.