Just a thought, do you really need all these subclasses? With a bit of creativity, and a little less purity, could you just roll them all into a single class with some different properties and then externalise an interface from it?
I don't know what your application is, and apologies if I am making a silly suggestion, but I do know that it is easy to get carried away with the OO paradigm and sometimes it's better to forego some architectural purity in the name of simplicity and understandability (is that a word?). --- In flexcoders@yahoogroups.com, "Aaron Miller" <[EMAIL PROTECTED]> wrote: > > Thanks for the good information! I'll go ahead and give it a shot and add in > your suggestions as well. > > When I said it "becomes" an IChildUserModel class, this was probably not the > technical OOP term. What it does is get reinstantiated as a new class and > uses the memento pattern to restore it's state. The end result is an > IChildUserModel class which starts with the same state as the previous > IUserModel class, with a few extra properties and methods tacked on. Do you > think this is an ok approach? I don't have any formal education with this, > so I'm just kind of winging it. > > Thanks for the help! > ...aaron > > On 1/1/08, simonjpalmer <[EMAIL PROTECTED]> wrote: > > > > If you are strict about only referring to methods/properties through > > IUserModel and IChildUserModel and not the concrete classes then I > > don't see that you have any problems with your implementation and > > there's nothing inherently unsafe about it. > > > > You should probably check the type at runtime e.g... > > if (user is ChildUserModel1) > > if (user is IChildUserModel1) > > > > Everything in your class hierarchy is IUserModel. That doesn't make > > it redundant it means that you never have to refer to a concrete > > class, which is generally a good practice. > > > > However you do say that something starts off as a UserModel and > > becomes a ChildUserModel. I'm not sure how you can make that happen > > because an object gets strongly typed on creation using the new > > operator, so you can't switch from a class to a sub-class - but maybe > > I have just misunderstood what you meant. > > > > btw, I think that ChildUserModel1 implicitly implements IUserModel > > through extending UserModel, so you get that through inheritance which > > means your class declarations can be cleaned up a little. If you want > > to overrride the UserModel implementations of the IUserModel methods > > in your subclass you'll have to use the override keyword. > > > > hth > > > > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "Aaron > > Miller" <amiller@> wrote: > > > > > > Hello, > > > > > > I just wanted to make sure my logic was correct so I don't waste a > > bunch of > > > time typing up all this code to find out it doesn't work. > > > > > > With the given class structure: > > > > > > # UserModel implements IUserModel > > > # ChildUserModel1 extends UserModel implements IUserModel, > > IChildUserModel > > > # ChildUserModel2 extends UserModel implements IUserModel, > > IChildUserModel > > > # ChildUserModel3 extends UserModel implements IUserModel, > > IChildUserModel > > > etc. > > > > > > If I have a class instance where the exact implementation could be > > any of > > > the above classes, and is determined at run time, would it be > > safe/correct > > > to define a variable of type IUserModel and then strong type it as > > either > > > IUserModel or IChildUserModel depending on its expected implementation? > > > > > > For instance: > > > > > > # var user:IUserModel; > > > # user = new UserModel(); > > > # trace( IUserModel(user).someUserProperty ); > > > # user = new ChildUserModel2(); > > > # trace( IChildUserModel(user).someChildUserProperty ); > > > > > > (assuming the properties are defined in the interface of course) > > > > > > Is there a safer/more correct way to accomplish this given that the > > property > > > always starts off as a UserModel and may or may not become any one > > of the > > > ChildUserModel classes who share a common interface? > > > > > > note: Any of this can be changed, I just need to be able to have a class > > > that acts as an IChildUserModel when it is one, or as a UserModel > > when it's > > > not. There is only one kind of UserModel, so I'm not sure if the > > IUserModel > > > interface is even necessary. I just wasn't sure how to define the > > variable > > > so it could be either one. > > > > > > Any input or advice will be greatly appreciated. > > > > > > > > > > > > Thanks for your time! > > > ...aaron > > > > > > > > > > > > > -- > Aaron Miller > Chief Technology Officer > Splash Labs, LLC. > [EMAIL PROTECTED] | 360-255-1145 > http://www.splashlabs.com >
