5 Replies Latest reply on Sep 11, 2008 5:32 PM by Newsgroup_User

    Reusing functions in ActionScript Classes

    ericbelair Level 1
      I have an MXML Component which I am using as a Base Class for other components that share similar functionality. The Extended Classes use some of the same functions. Those functions perform no logic in the Base Class, but are called by Event Listeners in the Base Class. Right now, I have those functions setup as protected functions, and I am overriding them in the Extended Classes, but I'm thinking this isn't the best way to do this. Should I use an Interface???

      Any suggestions would be greatly appreciated...

      Thank you.
        • 1. Reusing functions in ActionScript Classes
          Ansury Level 3
          Looks like it might be a good case for an abstract class/functions. Unfortunately, AS3 doesn't have such a concept. :P

          An interface seems like a good option here. The most concrete advantage it gets you is that you won't forget to override one (or all) of those functions -- assuming they always should contain logic. (Assuming you don't forget to implement the interface, heh. That's why I'd like abstract here better. But at least FB will autogenerate your method stubs for you.)

          When you override methods it's typically because you want your class behavior to change from some default behavior, but you don't have any. Doing what you're doing doesn't seem like a terrible sin in AS3 since there's no abstract functions available to delegate implementation of those functions. Actually, if leaving those functions "empty" IS acceptable behavior, that makes overriding look better than an interface. (Why force outside code to agree to a contract if compliance is optional?) So I'd say here it depends on whether behavior must be implemented, or if it's optional.
          • 2. Re: Reusing functions in ActionScript Classes
            Level 7

            "Ansury" <webforumsuser@macromedia.com> wrote in message
            news:gac30t$lh6$1@forums.macromedia.com...
            > Looks like it might be a good case for an abstract class/functions.
            > Unfortunately, AS3 doesn't have such a concept. :P

            There's a lot about abstract classes in the book Actionscript 3 Design
            Patterns. Here's another take on that
            http://nodename.com/blog/2005/09/19/abstract-classes


            • 3. Re: Reusing functions in ActionScript Classes
              ericbelair Level 1
              quote:

              Originally posted by: Ansury
              An interface seems like a good option here. The most concrete advantage it gets you is that you won't forget to override one (or all) of those functions -- assuming they always should contain logic. (Assuming you don't forget to implement the interface, heh. That's why I'd like abstract here better. But at least FB will autogenerate your method stubs for you.)

              When you override methods it's typically because you want your class behavior to change from some default behavior, but you don't have any. Doing what you're doing doesn't seem like a terrible sin in AS3 since there's no abstract functions available to delegate implementation of those functions. Actually, if leaving those functions "empty" IS acceptable behavior, that makes overriding look better than an interface. (Why force outside code to agree to a contract if compliance is optional?) So I'd say here it depends on whether behavior must be implemented, or if it's optional.


              Thanks for replying (I feel like this forum has been dead lately!). Exactly my point. I tried an interface, but with an interface, you still have declare the functions in the base class. The overrides are actually NOT required in the extensions. THis seems to be working just fine, so I'm gonna keep it - less code to maintain....
              • 4. Re: Reusing functions in ActionScript Classes
                Ansury Level 3
                Yes, I was referring to having your inheriting classes implement the interface (still a pain in the rear), but like I said you have to remember to add the interface to each class anyway... It's probably not worth worrying about it at this stage of AS's life.

                Regarding abstract classes in current AS, that's interesting. But I usually avoid fancy hacks that are likely to confuse new people looking at or maintaining my code. Maybe it's not the coolest strategy but many people do appreciate it when you omit that fancy fancy automagic tricky code and go with something much easier to understand or maintain from the outsider's perspective.

                Also I'm not sure what that method gets you over simply throwing an exception in a function that must be implemented by an extending class. I guess this: "We can make a real abstract class that implements none, some, or all of an interface’s methods". (Although really you can still do that with the common exception throwing method.) I suppose this is useful if you're making lots of complex hierarchies and leveraging polymorphism alot and so on, but that type of design tends to get trickier than it's worth in practice.

                And if this gave you a compile time error that might be cooler, but it looks like it's still just generating a run-time error. Anyway, enough rambling on.

                Cool trick, but I'll wait until Adobe decides to support abstract natively and it becomes common knowledge - maybe with Flex 4 and Flash 10?
                • 5. Re: Reusing functions in ActionScript Classes
                  Level 7

                  "Ansury" <webforumsuser@macromedia.com> wrote in message
                  news:gacbks$1b0$1@forums.macromedia.com...
                  > Yes, I was referring to having your inheriting classes implement the
                  > interface
                  > (still a pain in the rear), but like I said you have to remember to add
                  > the
                  > interface to each class anyway... It's probably not worth worrying about
                  > it at
                  > this stage of AS's life.
                  >
                  > Regarding abstract classes in current AS, that's interesting. But I
                  > usually
                  > avoid fancy hacks that are likely to confuse new people looking at or
                  > maintaining my code. Maybe it's not the coolest strategy but many people
                  > do
                  > appreciate it when you omit that fancy fancy automagic tricky code and go
                  > with
                  > something much easier to understand or maintain from the outsider's
                  > perspective.
                  >
                  > Also I'm not sure what that method gets you over simply throwing an
                  > exception
                  > in a function that must be implemented by an extending class. I guess
                  > this:
                  > "We can make a real abstract class that implements none, some, or all of
                  > an
                  > interface?s methods". (Although really you can still do that with the
                  > common
                  > exception throwing method.) I suppose this is useful if you're making
                  > lots of
                  > complex hierarchies and leveraging polymorphism alot and so on, but that
                  > type
                  > of design tends to get trickier than it's worth in practice.
                  >
                  > And if this gave you a compile time error that might be cooler, but it
                  > looks
                  > like it's still just generating a run-time error. Anyway, enough rambling
                  > on.
                  >
                  > Cool trick, but I'll wait until Adobe decides to support abstract natively
                  > and
                  > it becomes common knowledge - maybe with Flex 4 and Flash 10?

                  Probably too soon after As3 and ECMA parted ways