explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Naming Conventions, Interfaces, Abstract Classes, Impl in as3

7 Comments

[update]

I think I have settle on the following formats (of course this is subject to change):

public interface iFoo { ... } //interfaces
public class mFoo { ... } //implementations a.k.a. base classes
public class aFoo { ... } //abstract classes w/ function override enforcement via errors

[original]

I am currently on my 4th complete rewrite of the as3isolib.v2. It’s not that the previous drafts were not worthy, but rather through experimentation over time, the code has become quite cluttered and unmanageable. So rather than trying to clean up the existing code, it seems like a time to do a rewrite while things are relatively fresh on my mind.

One thing I have been struggling with in v2 is maintaining an easy-to-use APIs while not sacrificing performance. I spent 6+ months performance tweaking draft #3. There is a lot of function inlining, base class implementations, scratch objects, etc. This makes for blazing fast performance, squeezing everything possible out of the flash player, but it also makes maintaining an easy-to-use API very challenging.

Case in point: Interfaces vs Abstracts. While there is no officially supported Abstract class in as3, there are a few hacks here an there. Why would you choose an abstract implementation over an interface implementation? First I should discuss the performance implications of calling a function rather than accessing a simple instance variable. Interfaces mandate that defined APIs are done so either by true function calls or getters/setters.

package
{
public interface IFooBar
{
     function foo():void;
     function get bar():Object;
     function set bar( value:Object ):void;
}
}

you cannot however define an interface variable.

package
{
public interface IFooBar
{
     var myVar:Object; //does not compile.
}
}

But back to performance implementations.  Over at Jackson Dunstan’s blog (http://bit.ly/mXLmEX), he has done some performance testing of function calls over variable access.

Obviously we can’t get out of NOT calling functions, but when performance is key, Jackson shows that variable access is much more performant.  In as3isolib.v2, performance is a big deal.  So the alternative is to impose some sort of pseudo-abstract class implementation.  This would basically look like:

package
{
public class IFooBarImpl
{
     public function foo():void {}
     public function get bar():Object { return null; }
     public function set bar( value:Object ):void {}

     public var myVar:Object;
}
}

So the upside of this is a) we get both the functions demanded by the interface and the variable accesses provided by the implementation.  The downside is that in order to utilize this, it needs to be subclassed.  The other thing to note is the naming convention.  I think because this is a special case, it requires a special naming convention to denote a) the interface-ishness and b) the abstractness.  I’d suggest something like:

IClassImpl

The prefix “I” conforms to Adobe’s coding conventions for interfaces, you still get the intended purpose immediately following the prefix and the “Impl” suffix denotes that this is an actual implementation rather than a true interface.

So I will now present why I am seriously considering this for the as3isoilb.v2.  The v2 engine’s render process is something that gets called once every frame via Pushbutton Engine’s IAnimatedObject.  There are several core classes that get accessed on every render pass, including a collection of game objects that are looped through.  This means in the render pass’s loop, we are accessing simple values like x, y, z, and isInvalidated THOUSANDS of times.  So while in a normal situation where under the hood a getX() is getting called may be fine, for performance-intensive code, those performance hits for function calls add up considerable.  We are talking on the scope of 5-10 FPS lost per render pass and 10-20 ms per frame added.  This increases proportionately to the total number of entities rendered.  Having access to simple vars keeps the access penalty low, thus allowing more objects to be crunched.

Thoughts?  I’d love to hear them.

Advertisements

7 thoughts on “Naming Conventions, Interfaces, Abstract Classes, Impl in as3

  1. I think Impl suffix is not appropriate. Clients of API don’t care what ‘interface’ represent – as Interface or as AbstractClass. So I think prefix ‘I’ is enough.

  2. As a user of an instance of this object I shouldn’t care if it is an interface or an implementation, I should only care what it’s contract is, so why use ‘I’ or ‘Impl’ ; if I want information about it’s implementation I will look at the source code. Don’t blindly assume Adobe’s coding standards were written by some OO guru, they were probably written by someone who was given the job to do it in day.

    • While I agree in part with your comment about paradigms set forth by some guy at Adobe, the “I” prefix for interfaces I believe is a common language-agnostic naming convention.

      As for the “Impl” suffix, I have only seen that in some core singleton-ish classes in the MX framework, which fits your comment.

  3. As an intermediate programmer (at best) who used as3isolib for a school project last Spring, this looks sound. I’m no expert, though.

    If this improves performance then I’m all for it. It may be worthwhile to use this approach for all places you would use an interface in the code (not just the ones where you need a variable), as it would be more consistent.

  4. I think your ‘abstract’ class is a perfect solution for this, and I see no problem with it. I’d leave out the I in IFooBarImpl simply because it’s not an interface. I wound up having to use this exact method myself a while back in IsoKit; I had used interfaces but they were slower, so I just created a BaseIsoRenderer class that stored all the absolute essential functions that were required and used that to replace the interface. Just my 2 cents. Keep up the good work on this! I’m about to enter rewrite number 4 myself for IsoKit. 😉

  5. I just always use the suffix “Base” in those sorts of classes. I do this because, while they start totally Abstract, I have found it useful to shove logic in those classes down the road. Therefore, they are more Base classes to me, which happen to contain Abstract functions and stub. Just my 2 cents.

  6. Thanks for the feedback guys. Something I hadn’t thought of was the concept that a recipient class (that would extend this) isn’t going to care about wether it’s an Interface or Abstract class. So it really sounds like you folks aren’t opposed to the implementation aspect of it (which was what I was worried about) but rather you disagree on the naming convention only.

    @David
    My only gripe with prepending the actual implementation class with Base+ is that it looks fugly. I DO want the name to imply some special meaning in it being an interface / abstract class. I think Hitsuke might have nailed it when they said the I+ prefix is enough? I dunno…. that is appealing to me. I do know what you mean, you start with a abstract class and then it just grows and grows. I am hoping to avoid that in part by having the abstract methods actually throw “need override” errors of some sort.

    @LunarRaid
    If I were to choose from a prefix of I+ only vs. a suffix of +Impl only, I’d choose the prefix simply from a IDE filtering perspective. I like having all my Interfaces and in this case Abstract classes in one place. OCD…. Now that doesn’t exclude the possibility of having an Abstract+ prefix. That would really eliminate any chance of confusion.

    From what I gather though is that having both the prefix and suffix I+ name +Impl is redundant. I will think on this more. Thanks all for the feedback.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s