Re: [flexcoders] Re: interface inheretence
Hi Simon,
I definitely understand your position. In fact this was how the code used to
work. The problem we were running into is that there are a lot of different
child users types which frequently change during the execution of the
program. What's worse is more child user types keep getting added and much
of the program execution throughout the application depends on which type of
user is currently in use. We were finding that making frequent updates to
this system was becoming quite a chore, and usually introduced new bugs.
I've actually finished the conversion to the more polymorphic system, and it
seems to be working quite well. I've even found that I could utilize binding
by creating a "morphUserType" function that dispatches a propertyChange
event. This would allow me to do something like:
# selectedIndex="{(myAuthUser.userModel is IChildUserModel )? 1 : 0}"
However, this does introduce another question. Is there a good way in AS3 to
determine the exact implementation of a class? Right now, I can only check
to see if it's not an IChildUserModel which means it must then be an
IUserModel. What if down the road a third type was added? I was thinking I
might be able to do something like a switch statement without breaks to see
how far down the line it goes, but this would bring me back to the updating
problem where switch statements would have to be updated throughout the
application.
This is really just a question for my own curiosity, so anyones thoughts on
the matter will be greatly appreciated.
Thanks again!
...aaron
On 1/1/08, simonjpalmer <[EMAIL PROTECTED]> wrote:
>
> 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
> > > ,
>
> "Aaron
> > > Miller" 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 c
[flexcoders] Re: interface inheretence
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 , "Aaron > > Miller" 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 >
Re: [flexcoders] Re: interface inheretence
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 , "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
Re: [flexcoders] Re: interface inheretence
>> 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 , "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
[flexcoders] Re: interface inheretence
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, "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 >
