>>
You should probably check the type at runtime e.g...
if (user is ChildUserModel1)
if (user is IChildUserModel1)
>>
i think this is a solid approach in some cases.

interestingly enough union types are suggested for ecma 4
[dummy syntax example]
var myVar:(ISomeInterface,IOtherInterface);
[end]

in which case checking the type is part and parcel of how it has to be done
On Jan 1, 2008 12:01 PM, 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
> >
>
>  
>



-- 
j:pn
\\no comment

Reply via email to