Talk:Composite
JaninaVoigt (Talk | contribs) (New page: In lectures today, Wal briefly brought up the question about where the addChild(), removeChild() and getChildren() methods should go. The Composite pattern tells us to put them in the Comp...) |
|||
| Line 1: | Line 1: | ||
In lectures today, Wal briefly brought up the question about where the addChild(), removeChild() and getChildren() methods should go. The Composite pattern tells us to put them in the Component class but this forces us to use no-op overrides in the leaf component. I think that this is probably not such a great idea. It seems to me that clients should know that they can only add other components to a composite. If they just add it to a component, how are they supposed to know if the method actually added the new component or not? Sure, we could return a boolean or throw an exception but that would require us to keep the method contract very general; i.e. we would have to say that the method may or may not add the component. This smells fishy to me. Instead, I would much rather that the client had some way of checking if they had a composite before adding child components to it. Therefore, I would move these methods down into the composite component. What does everyone else think? -- [[User:JaninaVoigt|Janina Voigt]] | In lectures today, Wal briefly brought up the question about where the addChild(), removeChild() and getChildren() methods should go. The Composite pattern tells us to put them in the Component class but this forces us to use no-op overrides in the leaf component. I think that this is probably not such a great idea. It seems to me that clients should know that they can only add other components to a composite. If they just add it to a component, how are they supposed to know if the method actually added the new component or not? Sure, we could return a boolean or throw an exception but that would require us to keep the method contract very general; i.e. we would have to say that the method may or may not add the component. This smells fishy to me. Instead, I would much rather that the client had some way of checking if they had a composite before adding child components to it. Therefore, I would move these methods down into the composite component. What does everyone else think? -- [[User:JaninaVoigt|Janina Voigt]] | ||
| + | |||
| + | What about something like hasChildren() or isLeaf()? Although that leads us (back) to [[Beware type switches]]. Maybe there just is no ideal solution? --[[User:TobiW|TobiW]] | ||
Latest revision as of 04:15, 3 August 2009
In lectures today, Wal briefly brought up the question about where the addChild(), removeChild() and getChildren() methods should go. The Composite pattern tells us to put them in the Component class but this forces us to use no-op overrides in the leaf component. I think that this is probably not such a great idea. It seems to me that clients should know that they can only add other components to a composite. If they just add it to a component, how are they supposed to know if the method actually added the new component or not? Sure, we could return a boolean or throw an exception but that would require us to keep the method contract very general; i.e. we would have to say that the method may or may not add the component. This smells fishy to me. Instead, I would much rather that the client had some way of checking if they had a composite before adding child components to it. Therefore, I would move these methods down into the composite component. What does everyone else think? -- Janina Voigt
What about something like hasChildren() or isLeaf()? Although that leads us (back) to Beware type switches. Maybe there just is no ideal solution? --TobiW
