I was developing an API which required specific abstract base classes to be developed in order to provide a default implementation for derived concrete classes, and, as you may know ActionScript 3.0 doesn’t support Abstract Classes (classes which can not be instantiated) so I had to develop my own solution that I thought I would share.

Abstract classes in general are classes which can not be instantiated directly, but rather would be used as a base class in which sub classes would provide a specific implementation. For example, a “Mammal” could be considered an abstract class as there are no concrete examples of a generic “Mammal” per say, but there are instances of it’s decedents; People, Dogs, Cats etc., which would more than likely also be abstract types themselves, however, eventually in the inheritance chain there would be concrete classes which would override the methods defined in the base class. The base class would provide a default implementation for it’s decedents but would also require that derived classes override methods which it can not provide a default implementation.

In ActionScript 3.0 you can not use the private access modifier in a constructor definition and ActionScript does not provide an actual abstract keyword, therefore you can not create a true abstract class.

So how do you create a “pseudo abstract class” in ActionScript 3? My solution is very simple:

In the above example all I am doing is creating an inner class: Private, which is only accessible from within the defined class Abstract. This enforces that only an object of type Private can be passed as an argument to the constructor.

Now were on to something. As you can clearly see from the example above, only a sub class of Abstract has access to an instance of Private via the protected static function getAccess(). Therefore only a sub class can instantiate an instance of Abstract, and why would it ever need to if it is a sub class? The sub class would then call super in the constructor and pass the instance of Private via getAccess(); as follows:

This is a pretty elegant solution in my book. Yes, it is obviously not an abstract class in the true sense of the word but it does the trick if you want to enforce that a class is never directly instantiated.

I would suggest restricting all Abstract classes access to internal if possible in order to help further avoid potential misuse by limiting access to package level classes only.

01.04.08 - I have since implemented a utility class for enforcing Abstract types which I recommend using over the implementation in this example. The AbstractEnforcer and examples can be found here

Someone recently asked me why should they use the “this” keyword? My response was that you can use a reference to “this” as an easy way to disambiguate instance members from method parameters, local variables and so forth. In certain cases such as dynamic classes, the use of the “this” keyword is required.

After giving a little more thought as to why I originally began utilizing references to “this”, I quickly realized that it began back when AS2 first came out. At the time, I was a Flash engineer who specialized in Object Oriented design in Flash / ActionScript. There were a lot of Flash developers who would use references to _root as a way of dealing with scoping issues specific to Flash. This was definitely a bad idea as application requirements would demand scalability and if ever anything needed to change things would begin to break throughout the application. I began advocating the use of the “this” keyword to my team as a way of enforcing best practices and standards within our organization, but most of all, to eliminate convoluted scope references which would lead to applications failing to scale as needed.

When I moved over to the Flex world during the Flex 1.5 days, I would see the same kinds convoluted references to _root… so again, I quickly began enforcing the use of the “this” keyword to other team members.

So why do I still use the this keyword you might ask? Is there any real benefit? Not really. In reality the “this” keyword is the exact same construct as the “this” pointer in C++, as it is implied by the compiler if not explicitly specified. “this” simply points to the calling object’s pointer variable underneath the covers so to speak.

In the following, both examples are quite literally identical as far as the compiler is concerned:

However, in certain situations using a reference to “this” is required, such as dynamic classes as I had mentioned earlier.

The actual AS3 definition of the “this” keyword as defined by Adobe is:

“A reference to a method’s containing object. When a script executes, the "this" keyword references the object that contains the script. Inside a method body, the "this" keyword references the class instance that contains the called method.”

This is exactly my point. If ever you see a reference to this, you automatically know that the object being referenced is a property or method of the class instance in which you are working. You don’t have to figure anything out.

So it is a matter of personal preference. Again, I mainly use references to this out of habit, but also as a quick way to disambiguate instance properties from method parameters and so forth. Some people prefer to name all instance properties with an under score, and parameters without an underscore, and vise-versa. I personally don’t. Using references to this works for me and it may also work for you, or it might not.

So again, it is a matter of personal preference, and in the end it is simply a matter of whatever works best for you.

I have modified my AMFPHPRemoteGateway API to only support ActionScript implementations.

The AMFPHPRemoteGateway class is now to be considered a base class, not necessarily a pseudo-abstract class, but rather a base class in which sub-classes can build on to implement specific remote method invocation. You can still use AMFPHPRemoteGateway directly as well for general purposes.
Sub classes of AMFPHPRemoteGateway should now implement mx.rpc.IResponder and pass a reference of themselves to the new addResponder(); method.

I have also added a generic DAO interface which implementors can utilize to perform typical create, read, update and delete (CRUD) operations on a persisted object. The new interface, IDAO, provides a default contract which can be implemented by AMFPHPRemoteGateway sub-classes for specific remote DAO invocation.

I suggest that users create individual sub-classes of AMFPHPRemoteGateway for each domain object in which to perform CRUD operations on.

You can view the docs as well as download the swc. There is also a project folder in the download which contains a basic usage example.

I have just completed development of Golf Digest’s 2007 Hotlist, which was developed entirely in Adobe Flex 2 and Cairngorm 2.0.

The 2007 Hot List is a good example of organizations beginning to utilize the power of Flex to improve the user experience, and for us Flex developers this is exactly what we have been working to achieve.

http://www.golfdigest.com/flash/hotlist/