/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Architectural Atrocities, part 5: Interfaces in AS3

Architectural Atrocities, part 5: Interfaces in AS3

This is the fifth post in the Architectural Atrocities series and now the time has come to scrutinize ActionScript 3.0. The item of discussion is interfaces and how they are used in the ActionScript 3.0 API:s.

Let me start with an OO-maxim:

If you prefix your interfaces with “I”, you have no idea how to use them

(ok, I made it up myself, but that doesn’t mean that it’s not true)

The ActionScript 3.0 API:s have a few interfaces, in general it’s a good thing, it shows that the Macromedia/Adobe developers actually understand something, which hasn’t been obvious in the past.

The decision to include interfaces in AS2 was probably a manager or marketing executive saying “hey, all the other languages have something called ‘interfaces’, why don’t we?”, and the developers quietly obeyed.

In AS3 it seems that the developers (the new ones, I presume, since it’s unlikely that those responsible for AS2 could even begin to design the AS3 API:s) have a general understanding of object oriented software development and what interfaces are and why they are usable.

The point of this rambling

An interface declares a type. It’s an abstract concept and not connected to any concrete implementation. This is very usable since we can tie our code to an abstract concept and don’t worry about the actual implementation. The actual implementation can later change, but we don’t need to worry since we have only programmed to the abstract concept.

A more common OO-maxim states:

Program to an interface, not an implementation

Programming to interfaces leads to low coupling, which is a good thing for reuse and maintenance. If you don’t belive me, you’re disqualified from making a comment to this post.

The problem with the AS3 API:s is that every single interface I have found is prefixed with “I”. I assume this is in order to make it blindingly obvious that it’s an interface*. Given the explanation above, can you see the problem?

The point finally

If an interface is a type, and you want to program to interfaces, your ActionScript code will be littered with types that start with “I”.

Types are types. It doesn’t matter if they are abstract or concrete, they are types, you shouldn’t distinguish between a type defined by an interface and one defined by an imlementation (a class).

Prefixing with “I” takes interfaces aside and tells us that these are special cases, not abstract types. I read code like this as “This is an IFootballPlayer”, not “this is a football player”. This is wrong, a type represents a concept, not a type name and naming conventions should make it easier for the client programmer to think in this way, not harder.

To prefix interfaces with “I” is to not understand that types declared in interfaces are the types you will use in your code. Classes are just implementation specifics. Interfaces are not a convenience for emulating multiple inheritance, and they are not just a way to guarantee that a bunch of classes have the same methods.

* This is sometimes called Hungarian notation, you usually see it in newbie programmers that haven’t started to belive in the holy type checker.

40 Responses to “Architectural Atrocities, part 5: Interfaces in AS3”

  1. Iconara » Using Dependency Injection to simplify parallel development in Flex and Apollo Says:

    [...] as is the convention in the ActionScript API:s I have written about that in an article called Interfaces in AS3, the gist of which is “If you prefix your interfaces with ‘I’, you have no idea [...]

  2. DannyT Says:

    Have never thought about it this way and I’m somewhat convinced by your argument. Although sometimes I do see the need for it when the interface is less of a type and more an implementation of reusable common functionality: IBindable for example, just a little help for looking up in the intellisense list.

    Good argument though always interested in peoples ideas on improving readability and cohesiveness on code :)

  3. Iconara » Architectural Atrocities, part 9: Cairngorm’s Model Locator pattern Says:

    [...] also have a pet peeve: interface names prefixed with “I”. I’ve written about this before so I won’t go in to the details. It suffices to say that if you prefix your interfaces with [...]

  4. Mims H. Wright Says:

    Is this really that big of a deal? I totally agree with the readability part of it, and I do program to interfaces, but the I doesn’t really throw me off in practice. Anyway, it seems like it would be a bigger crime to start creating interfaces that don’t conform to the standard set by the API.

    Have you done one on implicit getters / setters? ugh!

  5. Mims H. Wright Says:

    Let me be more specific about getters and setters. I think it’s similar to what you’re saying about how interfaces should be indistinguishable from classes since they’re both types.

    Part of the idea of using an explicit get/set method (e.g. with Java) is that you’re using the exact same syntax for getting a value as you would for performing any other methods. foo.getValue() and foo.setAnotherValue(bar) and foo.reset() all use the same syntax. The result of the method is the only thing you care about. This allows us to take publicly declared properties out of the picture.

    It also reinforces the idea that some process could be happening behind the scenes (and not that this is just a pointer to a private field).

    With implicit getters and setters, I’m now stuck using () sometimes and not others. Not to mention marking my private variables with an underscore or dollar sign. Ugh.

  6. Theo Says:


    (first of all sorry for taking so long to approve your comments, I’ve had a flood of spam lately so I’ve had a hard time keeping up)

    Re: not such a big deal

    Try prefixing all your classes with “C” and see what happens. Would that change how you write your code or design your applications? Can you truthfully say that it wouldn’t change anything?

    Re: implicit getters and setters

    I’m not sure about this one. I used to agree more or less with your view, especially about the hidden side-effects and that, but I’ve come to change my mind.

    I’ve written a bit about getters and setters here: http://blog.iconara.net/2007/03/11/mxmlc-wtf-5/ but I’ve somewhat changed my mind since.

    The basic idea in OO (and bear with me now, this is basics and I’m not patronising you, I will get to the point, I just have to build up to it first) is to have objects with internal state and a public interface of actions that that object can perform, i.e. encapsulation. This breaks down when noobs start writing a getX/setX pair for each of their (private) instance variables, and unfortunately it seems like it’s only the minority that don’t do that nowadays. So, given the state of encapsulation in the majority of code examples out there I agree with you, because in that world properties (a.k.a. implicit getters and setters) hide the problem even more. It becomes even harder to spot setters that have side-effects, and sometimes you don’t even know if it’s a property or a public instance variable.

    However, if you dream away and just presuppose that things are as they should, that the public interfaces of types don’t do everything they can to break encapsulation, but instead enforce it, then properties aren’t so bad. In that world you know that if you mess with an object it will react, because setting a property is not the same as setting an instance variable, there will be a side-effect, just as there will be for a method call. The only thing that differs is the syntax, you’ve got one syntax for requesting actions to be performed and one for sending data.

    I mean, really, the getX/setX convention in Java is more or less exactly the same thing as properties, it’s just a different syntax. If you don’t expect instance variables to be public then a property is just shorthand for setX/getX.

    Properties in ActionScript isn’t all good though, one huge problem is with the compiler which doesn’t let you have different access levels for the getter and setter. In theory you can have a public getter and a protected setter, but in practice it never works, the compiler gets confused and complains about ambiguity (see the post I refer to above). This more or less forces you to either break your encapsulation by making both public, or write one getter and one setX method, making the code confusing and ugly.

    It may be that I have been lured into liking properties more and more from writing Flex applications. Bindings in Flex is implemented through the compiler re-writing properties to add some side-effects, and couldn’t be implemented as elegantly without them. It could be done with the getX/setX convention in Java, and I’m sure there are examples of that, but it would be different, and not at all as elegant (because, for example, you would in all likelyhood have binding syntax that looked like properties, but getX/setX in the implementation).

    This became a post in itself, I realise now… so to round it all off let me say that I’m completely with you on how much it sucks to have to mark all instance variables with an underscore.

  7. return undefined; » Simple monkey patch to fix ToolTipManager.toolTipClass Says:

    [...] would also like to go on record that I hate the *Impl naming convention. Despite what Theo says, I like my interfaces with I’s. *Impl just seems kludgy and redundant, and it reminds me of [...]

  8. John Nesbitt Says:

    Do you also dislike the convention of ending your interface names with “able”? I tend to view an interface more as a contract, rather than a representation of a type; after all, an interface cannot dictate which properties to make publicly accessible. Interfaces take care of the verbs in OOP, but not the nouns. I could certainly see your argument if all abstract classes started with an “A”, but I differ from you in that I do see an interface as a special case. I’m not saying I couldn’t be persuaded to your way of thinking, just that I’m not there yet :)

  9. Theo Says:


    No, I don’t dislike the convention of using “able” for types, I think it’s good. My point is that the name of a type should describe it. Something serializable should be called “Serializable” if it is something serializable or “Command” if it is a command, not “ISerializable” or “ICommand”, because it is not a “i-serializable” or a “i-command”.

    When it comes to abstract classes there are two variants: those that provide a basic implementation of an interface, and those that both define the interface and provide a basic implementation of it. In ActionScript and Flex an example of the first type is UIComponent (which is an abstract implementation of IUIComponent) and an example of the second is DisplayObject. In my view something like UIComponent should be called AbstractUIComponent, but something like DisplayObject should be called exactly that (however, legitimate examples of the second variant is quite rare, the first variant is almost always the right way to solve a problem). I will not say more about the second variant, and the rest of this discussion is only about the first.

    Why do I think that the “Abstract” prefix is a good idea when “I” for interfaces is not? The reason is that you should always type your objects as the most abstract type possible, which means that for objects that are instances of a class descendant from an abstract class the interface type that that abstract class implements is the most abstract type, never the abstract class type. Prefixing the names of abstract classes with “Abstract” both makes it obvious that the class is abstract (which is hard in languages lacking the abstract keyword), and sets the type apart, making it obvious that it is a special type of type, one that you should think twice about when you use it. This is the same argument that most people use when arguing for prefixing interfaces with “I”, but here I think it is valid. Interface types should not be set apart, because they are not special, abstract types are, because they are only convenience classes and should never be seen (except, obviously, when they are used as parent classes).

    I hope that the different meanings of the word “abstract” weren’t too confusing in that last paragraph, it really would have benefited from a diagram. A type can be more or less abstract (meaning, more or less, that it is more or less general), but a class can also be an “abstract class” (which just means that the class provides an abstract, as in not-finished, implementation of something).

    You also mention that interfaces “cannot dictate which properties to make publicly accessible”, this isn’t strictly true, in ActionScript and C#, the two languages that I know of that have implicit getters and setters (a.k.a. properties), interfaces can define properties. However, that doesn’t mean that it is necessarily a good idea. It all depends on how you use the feature. It’s always a bad idea to break encapsulation, and defining interfaces that dictate how an implementing class should define its inner workings (e.g. instance variables and such) is not a desirable feature.

    I’m not sure if this discussion persuades you further, but I hope that it does. Thanks for your comment.

  10. John Nesbitt Says:

    Thanks for the thoughtful reply. I do understand your Abstract… vs. I… rationale. I hadn’t ever thought about it that way. I always considered both of them special types, due to viewing them from the subclass’/implementor’s perspective. Looking at them from the outside-in, from the perspective of the class that actually does the instantiation and method calls, the differences between an Abstract class and an Interface type becomes clear. Sorry,that was all horribly articulated, but basically to say that I get your point. Thanks, also, for the info on the implicit getters and setters; I’ve gone all this time without taking advantage of that functionality for my Interfaces. Very handy! Anyway, I’ll lose the I on my interfaces in my next AS3 project and see how if it changes the way I structure anything.

  11. Theo Says:

    Good to hear that I’ve managed to convert someone.

    I wanted to add that there is also one practical argument for not prefixing your interfaces: if you want to refactor and replace a class with a number of classes, perhaps a whole hierarchy of classes, one way is to extract an interface from the first class and let all the new classes implement that interface (another way is of course to let the new classes inherit from the original class, but mindless subclassing will come back and bite you).

    If the interface has the same name as the class, no code that previously used the class needs to change. If you insist on prefixing your interfaces with “I”, all the code that just use the class need to change. It doesn’t have to change much, just an “I” needs to be added, but it has to be done.

    Let’s illustrate this with an example: say you have a class called Service. So far your application has only needed one kind of Service, but now the requirements have changed and you need to introduce a number of new service types. From the perspective of the code that uses the service it doesn’t matter what kind of service it is as long as it works the way it does now. You extract an interface from the Service class, rename the class to something else and make it implement the new Service interface. Then you create the other service classes, making them all implement the Service interface. The last thing you need to change is the code that instantiates the service, making sure that it instantiates the right kind of service in the right circumstances (this part could probably benefit from being refactored into a factory). If the new interface has the same name as the old class you’re done. If not, you have a couple of fun hours wading through the rest of the code searching and replacing.

  12. Joe The Plummer Says:

    Do you have much experience in other programming languages? Namely C/C++, C#, Java? We prefix interfaces with I not because we don’t understand them, but to help along users of our code. I can understand if it a solo project, otherwise I think you’re mistaken. Interfaces ARE meant to force users to implement required methods, as well as assuring they are defined for explicit conversions. Not multiply inheritance, although they do solve some cases if used cleverly. Anyway, back to this gibberish about -not helping readability/usability/bug prevention with coding conventions-. What do you think is the purpose of abstraction, access permissions (private, protected, public), properties (accessors, getters/setters), constants (const correctness)? This kind of stuff is part of the standard in many languages. Required by the most professional programmers in the world. Those are ALL designed to help prevent misuse of code, and prevent bugs. Not to mention encapsulation, and abstraction play a part in this goal. With encapsulation outside users of the class should not be aware of the internal workings of the class, take it for what it is, this way the core can change without dependencies breaking.

    Anyway, use I for interface if you distribute your code. You’re just kidding yourself if you don’t. You don’t have to use C for class, because class is the default nowadays (used to be S for struct back in the day).

  13. Joe The Plummer Says:

    I mean’t “with data abstraction outside users” but whatever. I won’t make a dent in how you’ve laid this in your mind. If you’re proposing “Abstract” prefix but not interface, you’re hopeless. Yes, no abstract keyword exists in C++, but neither does interface. How about..

    I for Interface C for Class S for Struct A for Abstract

    There you go, lol. Joking. You know a good IDE solves all these naming convention problems. Such as Visual Studio, and yet Microsoft’s XNA prefixes I for interfaces.

  14. Joe The Plummer Says:

    For the record.. I only agree with what you’ve said (besides the abstract part, that just goes against your argument). Only because if we had proper IDE’s then we wouldn’t need these descriptors. I think I’ll drop the I from my interfaces for my next project. It’s too bad Camera and Sprite are reserved words in AS3 though >.< (ICamera isn’t :P)

  15. Joe The Plummer Says:

    Proper IDE’s and proper languages (C# forces abstract declaration, so it’s easily viewable, not to mention VS debugging is easier).

  16. Theo Says:


    What do you think is the purpose of abstraction, access permissions [...]

    Do you prefix your public methods with “p”? If not, why not?

  17. ideasculptor Says:

    This one is really simple to demonstrate by example. If I am coding to interfaces (as contracts) rather than concrete implementations, the ‘I’ is simply nonsensical. If I’m using dependency injection, it is even more so, since my code will have absolutely no knowledge of the specific instance type. If I have a service class which requires access to a DAO for users and a DAO for orders, and the particular instance of each DAO will be injected into my service class, using the ‘I’ makes no sense. My service depends upon a UserDao and an OrderDao. It doesn’t depend upon an IUserDao and an IOrderDao. Meanwhile, assuming that each DAO has basic CRUD operations via some kind of ORM framework, odds are very good that I have an abstract CrudDao implementation that both dao objects inherit from in order to gain access to basic CRUD functionality via inheritance. So I’ve got AbstractCrudDao in my class hierarchy. Note, the inclusion of ‘Abstract’ in the class name is not an identifier – it is a description. If you really want descriptive interface names, then call your interfaces UserDaoInterface, etc. The ‘I’ serves much the same purpose, but it is a very artificial construct which actually takes away from the intent of an interface – to genericize a contract.

    a HibernateUserDao extends AbstractHibernateCrudDao and implement UserDao and will be referred to as a UserDao absolutely everywhere in my code except for where the dependency injection is configured to instantiate a concrete instance.

    With IoC, the contract becomes the first class type which all of your other code interacts with, so singling it out as ‘special’ via the ‘I’ prefix is pretty much exactly the opposite of intent. If anything, the ‘Hibernate’ and ‘AbstractHibernate’ are the equivalent of the ‘I’ prefix on an interface, but are much more appropriate, marking particular implementations that are mostly beneath the radar of a developer that is merely using the api, since that dev will only interact with the contract. The dev that maintains the API must know about the concrete implementations, but the maintaining dev necessarily must know the details of the api internals, so it makes sense for that dev to utilize what are, effectively, private prefixes in order to label classes.

    Going down one layer and looking at the domain model itself makes this even more apparent. Let’s say that for testing’s sake, my domain model is implemented as a set of interfaces with a concrete implementation that is probably (in java, anyway) annotated with information about the storage mapping of the class in question. So I can have a Car which has a Wheel and a Tire, and all of my business logic will interact with Car, Wheel, and Tire objects, or I can have an ICar, and IWheel, and an ITire and have those names scattered throughout my codebase. Since the fact that my app uses a HibernateDao is completely irrelevant to every other layer in my app courtesy of dependency injection, the fact that I am currently passing around hibernate-specific versions of the domain objects which were acquired via that same DAO is also irrelevant. I only care that it adheres to the Car, Wheel, or Tire contract.

    So far as I can tell, the only people who still argue that interfaces need prefixes because they are not first-class types are those who either do not yet understand how programming to interfaces is absolutely vital to de-coupling code, or don’t yet understand just how well a framework like Spring can truly isolate each layer of an app from every other so that absolutely no knowledge of the implementation details of one layer is ever visible to any other layer. My application layers never know ANYTHING other than the interfaces that describe the layers they interact with. If I have a cross-cutting concern which demands knowledge of implementation details, then I’ll implement it as an AOP aspect that is injected between layers by the framework without the knowledge of any other involved layer, and again, only the IoC framework will need to know the specifics of the aspect’s implementation, which must necessarily match the implementation details of the layers with which it interacts.

  18. Theo Says:


    I very much agree that the fundamental problem seems to be that those who think prefixing interfaces with “I” have probably misunderstood their use. Perhaps a related problem is that most programmers have yet to grasp dependency injection too? They live in a world where you create new instances of classes willy-nilly, and in that context it feels wrong (to them) to let interfaces be first-class participants. When you move to dependency injection you notice that most of the things you interact with are actually interface types, and the “I” sticks out like a sore thumb.

    Thank you for taking your time, your examples are great and show the issue from a more concrete perspective.

  19. Nick Says:

    Theo et al,

    Some good points made by both sides here.

    I think what this really boils down to is, “How much of the system is the human is able to see at once?” — i.e. it reflects our inability (vs. a machine’s) to grasp the code as a whole, as the gestalt, and “instantaneously”. Can you immediately say for sure, when looking at an external reference to an interface in some stranger’s code, that is indeed an interface? For that matter, if we were able to grasp the complexities of a system in such a broad and imediate way, the (descriptive) naming of variables would be unnecessary as well (let alone all the other implications of human beings being this omniscient).

    I think it’s a bit inappropriate to say that more experienced and capable programmers than you or I utilise the I-prefix because they do not fully grasp the logic structures of what they are implementing. I know you were indicating less experienced developers… but there exists this implication, nonetheless.

    Ultimately though, you are challenging the status quo and I respect that. That said, I still lean toward the side of programmers who are doing it to document their code for others, as most projects these days are not one-man jobs… Even if some are at the outset, they are not later on. Why bother changing your tactic for those smaller projects where you don’t need the prefix, and then changing back again when you’re working on a team? Better to keep life simple and adopt the standard which exists for good reason.

    Kind Regards, Nick

  20. Theo Says:

    Can you immediately say for sure, when looking at an external reference to an interface in some stranger’s code, that is indeed an interface?

    No, and my point is that there is no reason that you should.

    Better to keep life simple and adopt the standard which exists for good reason.

    No, and my point is that there is no good reason.

  21. Nick Says:

    Well, I guess I must have missed your point then as others have clearly missed yours, and you’ve missed others.

    Some think documenting code clearly (in fact more than clearly) is necessary for an approachable codebase, whilst others do not.

    And while I appreciate the concept of self-documenting code, I don’t think this can fall into that category.

  22. Nick Says:

    Ah… See Bill Trwobridge’s post (3rd down):


    THIS is what I was thinking would be the best solution to this problem, and here Bill has formulated the idea nicely. I maintain that developers must be able to see what “type of types” (to use your words) they are working with, immediately and explicitly… but that it shouldn’t interfere with the type’s literal name.

  23. Theo Says:

    Can you immediately say for sure, when looking at an external reference to an interface in some stranger’s code, that is indeed an interface?

    This question assumes that there is a difference between a type declared by an interface and a type declared by a class — but that is not the case. It makes no difference what declared a type.

    About Bill Trowbridge’s comment: if I understand him correctly he proposes to drop the “I” prefix in favour of showing some icon next to the type in the IDE. His suggestion makes sense, absolutely. He wrote that over four years ago and nowadays most IDEs do what he suggests. However, the “I” prefix tradition still lives on.

  24. Steve Says:

    When I was developing MS COM apps back in the day, we didn’t use “I” to denote just any interface. We used it to denote an interface that extended IUnknown. These interfaces provided special features necessary for MS’s COM such as the QueryInterface function and a UUID that uniquely identified the interface in the system. I’ve created large-ish COM components whose implementation consisted of non-COM interfaces, and for those we did not use the “I” prefix. So, we didn’t use “I” to distinguish between our classes and our interfaces we used it to distinguish between regular C++ interfaces and COM compatible interfaces.

    I’ve also done some eclipse development and many of the platform interfaces are prefixed with “I” also. But again, this prefix isn’t on all interfaces, just those that are interfaces that correspond to a plugin’s extension point. As someone consuming these platform APIs it is very necessary for me to be able to quickly look at a package’s contents and determine which of the interfaces (with the I icon in the IDE) are participating in the plugin’s public API.

    So while I agree that using “I” to distinguish between classes and interfaces is silly, using it in other circumstances can make sense – specifically where you have a component framework of some sort that can treat certain interfaces in a special manner.

  25. tylermac Says:

    Nick said:

    Better to keep life simple and adopt the standard which exists for good reason.

    So I would recommend instead of an I prefix on interfaces, adding a impl postfix on Classes. This way, it will be the classes that look out of place in your code.

    Just a thought.

  26. Kingfish Says:

    I program in java mostly and have recently started looking at AS3. I have used Interfaces for years and my standard which I guess is the java standard is to call interfaces I at the end. This way there names are easier to find. Basically FootballPlayerI for the football player interface instead of IFootballPlayer which becomes unreadable in my opinion as stated above.

  27. Kingfish Says:

    Also on another comment, in most cases you are going to have multiple uses of a interface so let say you have a interface called EnemyI. Then you will probably have tons of classes called such as Pion, Boss, Assasin, etc and it could also have other interfaces. Totally bad idea to call it PionImpl because that would completely defeat the point. The interface is what you are trying to identify in the name not the classes that implement it. Build APIs to tell you this.

  28. Theo Says:

    @Kingfish sticking the “I” at the end or the beginning doesn’t really matter, you still just arbitrarily separate interfaces from other types. The point is that interface types aren’t special.

  29. maciek Says:

    While I agree with your point in general, I think there are two arguments in favor of the ‘I’ prefix:

    1. This is what the AS3 APIs do. There’s something to be said for following a set of code conventions in your project (see, e.g., the section in McConnell’s ‘Code Complete’), and naming conventions that clash with those of the standard library are going to stick out. It’s true that the AS3 APIs do lots of things that are far from exemplary, but in deference to the cohesiveness of your project code base, I think you have less leeway in ignoring core library naming conventions than its other design choices.

    2. It helps identify when developers on your project are writing APIs in terms of concrete types. Of course, you could argue that “don’t write APIs in terms of concrete types” is a more useful “convention” than “prefix interfaces with ‘I’”, but realistically, the latter is probably easier to enforce.

  30. Theo Says:
    1. I don’t find this argument very convincing. Don’t follow bad conventions.

      If we had listened to that argument we would still call our methods things like memcmp, strlen or tmpnam. Just look at the PHP standard library. Stick with the good things and your code will blend in just fine.

    2. If you want to make it blindingly obvious when developers write APIs in terms of concrete types have them prefix all classes with C.

  31. maciek Says:
    1. I don’t think the words “conventions” and “PHP standard library” belong in the same sentence, so I’ll ignore that example. I essentially meant that there is some cognitive load associated with using an API that has a mix of IInterfaces and regular Interfaces. Conversely, I suppose you could argue that you’re reducing the cognitive load by purging the ridiculous IPrefix wherever possible. I guess it’s a matter of taste.

    2. Touché.

    For what it’s worth, I was firmly in favor of IPrefixes; I’m now on the fence.

    Also, while slightly off-topic, your posts (especially on presentation models) in the Mate forums have helped me immensely in understanding sane, maintainable, and testable UI architecture. Thank you.

  32. Theo Says:

    Haha, no the PHP libraries have a thousand conventions. But my point was rather that many of the PHP functions are named after the C convention of removing the vowels and leaving off parts of the end. There are other parts that don’t follow that convention, and I’m not sure if that’s a good or a bad thing =)

  33. Stan V Says:

    Your whole premise is that interfaces aren’t special.

    An interface is a type of potentially hundreds of different implementations (versus one), but which you can’t instantiate on its own. It can’t be extended, but implemented, which only has public members, and those members can only be methods, but not properties.

    That’s the very definition of “special”. An interface is a type. It’s a special type. You come with horribly long-winded twists on supporting your idea, but you fail to recognize the merits of the opposing view.

    You want consistent naming? Then use the rules of the platform you use. Otherwise your code will be, ironically, the one with the special names.

    There are so many tough issues in software engineering, but naming things is by far the most discussed one. Maybe since everyone knows just enough to feel competent to discuss it.

  34. Theo Says:

    A class’s type has only one implementation, that too is the very definition of “special”. I can come up with many other sentences that describe classes and interfaces as special in relation to each other, but that has very little to do with the argument here.

    Interfaces don’t define special types, they just define types. Classes do to. There’s nothing different between the type defined by a class and the type defined by an interface. Both define what actions objects of that type can perform. In fact, hadn’t the term interface become so overloaded (blame Java for that) I would say that both classes and interfaces (as in the language construct) define interfaces, it’s just that in the case of a class, that interface is tied to an implementation.

    Re: “An interface is a type of potentially hundreds of different implementations (versus one)”

    This is just wrong. The type of a class has also potentially endless implementations. Any subclass is also of the type of its superclass. Interfaces don’t have to have an implementation but they are pretty useless without one so in practice that distinction is moot.

    Naming things is important, and clearly the ActionScript community hasn’t discussed the issue thoroughly. That the most common argument for prefixing interfaces with “I” is that everybody else does it should be proof enough for that.

  35. FredV Says:

    Yes, you can use factories and dependency injection so the users of an object never instantiate one directly, have the implementation chosen for them and never care about which. This is a good design principle, but it cannot be applied universally. But what about objects that implement multiple interfaces for different kind of users of the object, or even more, what about objects that expose properties/methods not defined in an interface. Sometimes a dependency injection approach doesn’t work.

    Anyway it’s funny to see how the discussion diverged on the question if interfaces should be prefixed with an I or not, universally. Sorry people, there’s no golden rule here :)

  36. Theo Says:

    I don’t see the problem in your description. If an object should be used typed as different interfaces in different places, the factory or dependency injection container will know this and instantiate the object once, but return it for different requests. This is not an uncommon use case that dependency injection containers solve, and you can easily implement it in a factory.

    If the object exposes properties or methods not defined in the interface that the factory returns it as, you’re simply doing something wrong. If that is the case that particular interface isn’t what the factory method should return, since the client code can’t use it through that interface.

  37. john Says:

    “If you prefix your interfaces with “I”, you have no idea how to use them”

    Thats a tad strident. If your intention is to persuade it’s also counterproductive.

  38. Sean Thayne Says:

    I like your argument. The one thing I can think of that would be a good counterpoint is name collisions.

    Using RobotLegs for example. There is a api/impl for most of the pieces of the framework. The api/impl is also a big Java practice.

    A example name collision would be IEventMap and EventMap.

    EventMap implements IEventMap

    Sure you could use the full namespace.

    EventMap implements org.robotlegs.v2.extensions.eventMap.api.IEventMap

    But that would be a real pain in the butt, even with solid IDE help.

    Another option is using a different wordage for the default implementation. Similar to how Java’s Seam framework does. Like

    EventMapImpl implements EventMap

    That seems really wrong thou. As names should be descriptive. Yes it’s a Implementation of EventMap. But when creating code using this naming convention.

    var eventMap:EventMap = new EventMapImpl()

    Are you creating a implementation of EventMap or are you creating a EventMap?

    Also when you have a multiple interfaces being supported by a class. Would you still use the Impl? or not?

    If not you have half your classes ending with Impl and the other not. And you have some that are easily conforming there names to the Interfaces. Like EventMap and EventMapImpl. But when your using a second class interface. The naming wouldn’t make sense.

    var sortable:ISortable = new EventMapImpl()

    In programming I have always like to live by the rule. Especially when right re-usable code. If you can use the same rule everywhere, then don’t use the rule anywhere.

    Using I is something you can do 100% without adding exceptions.

    Add Impl isn’t 100%.

    What if my class name is Implementation. Would I then call the interface Implementation and the default implementation class ImplementationImpl?

    That’s weird right?

    IImplementation is better.

    ImplementationInterface is also better.

    If there was never default implementations. I would go your route and delete the I. But for simplicity and consistency, for now, I will stick with the I-Prefix.

    Loved your article thou!

  39. Theo Says:

    Naming is hard, and I agree that EventMapImpl is ugly. However, if there is an interface, there is likely the possibility of multiple implementations, and you should strive to name each one so that it’s easy to get what makes that particular implementation different from the others — in other words, give the class a descriptive name. What kind of event map is it, what makes it different from other event maps?

    EventMap implements IEventMap doesn’t tell me anything. MyMagicalEventMap implements EventMap tells me much more.

  40. Oalyeksyeyev Says:

    Yohoho, 4 years of discussions :)

    Just the noobie thoughts….

    Well, as for me, the noobi, if I name interface starting with ‘I’ I will be sure my neighbors will not try to cast it to other class.

    And if I see injection of IFootball player, I think that this day I will not punish someone for injecting implementation.

    When you work in heavens with only superior coders you may think FootballPlayer is ok, but in real life, the price of simple rules that limit coders from writing tash code and lets em to understand the existing code is very high.

    Thanks for great post. I am going to read all you have :)

    Ps, soorry for my English

Leave a Reply