> Thanks a lot for all the replies. Most helpful. It's a funny > situation. I'm using a deserialised XML file to dictate the > content and layout of each page. A page might contain 1. A > heading, 2. A TextField 3. A link or it might contain 1.A > heading 2. A thumbnailMenu or various other permutations. > I have written a class for each item that implements an IItem > interface, and they all have certain identical methods > (setPosition(), setScheme(), close() etc), but they also have > unique props that need to be set (The label of the header, > the label / path of a link etc.) Also to comlicate things, if > the item is a menu, I need to attach an eventListener. > > I like the idea of using classes to encapsulate the > parameters, but where would these be created? I guess it > would make sense to do it at deserialisation, but then that > gives two places that will be subject to change and that is a > bad thing. I could do it in a separate method in the factory > I suppose.
This sounds like what I'm doing at the moment. What I did was instead of using an interface, to make all my elements inherit the same base Element class, then when running a createElement function, I simply defined it as returning an instance of Element. It sounds to me like you're giving in to a common problem of letting the OO cart pull the design horse - you're trying to force a function to be strongly typed when by design it's creating elements of different types. Danny _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
