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" <[EMAIL PROTECTED]> 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