the ideal way of programming is to program to interfaces

[worthyashes]

Hi,

I've recently been doing some reading and have read about the ideal way of programming is to program to interfaces. Now this all sounds well and good, but I have to admit that I'm finding it quite hard. Even with good planning in advance I won't know all of the methods I'm going to use in my classes and I'm finding that as well as adding the methods to the class I'm amending the interface too. This all seems a bit backward to me so my quesiton is - am I getting the wrong end of the stick here or am I just not spending enough time planning to work out exactly what I need to achieve and therefore all of the required public methods for each class?

Cheers,

tim

[newblack]

imho, interfaces are only worthwhile when you're needing to generalize something that may be implemented radically different from one type to another. if you're just writing out interfaces for data types that you end up simply subclassing, it become superfluous- the implementor's type wholly describes that API.

[worthyashes]

Hi newblack,

I think I agree with you here. The only time I've used interfaces before has been to abstract a type where you may have a few different types of concrete versions of the classes that implement it, but you are using them in the same classes of your app, for example a MenuButton and a ImageButton could implement IMenuItem and then both be used in the Menu class.

Where I'm working at the moment they seem really keen on programing to interfaces though and whilst I understand that this exposes the API (if you don't have IDE that has code hints) in as much as you can read the Interface to see the public methods, and also that this could be a way of creating code where one developer may be working on one bit and another on a related part and they need to know their classes will be able to work together - so you could use and interface to create a 'contract' for the classes to adhere to.

But as a way of programing it feels a bit too prescriptive, I'd rather have good communication with the team as the development process goes on to talk about any tweaks or changes to the API as you go.

Anyway, cheers for your opinion - I think I agree with it.

[maskedMan]

I know where you're coming from with this. I think that newblack has the right idea, judging from my experience.

Note however that you can "Program to Interfaces" without using the implements keyword. You could instead simply use an abstract class (in as much as a class can be abstract in AS3), and always type your interchangable objects as the abstract class. This way you always have a consistent interface as long as you aren't adding new public methods to the subclasses that the superclass protests against executing because it doesn't know of them.

For the most part, it seems to be just a difference of style. I think the only time I've found it truly helpful to implement Interface is when for example you desperately need to subclass something that does not already have a certain set of public functions and you need to ensure that those functions are available to your set of subclasses, whether they're implemented beyond empty curly braces in any particular subclass or not.

[worthyashes]

Arrrgh! Now you're raising the Inheritance / composition row too!!!!



I agree with you though - it's a style question rather than a right or wrong one......however as a freelancer you need to bend your style to the people you're working with, and lots of time you learn techniques that you've never tried or thought of so it's interesting to consider the different styles and see what 'works' best for you.

Thanks for the really intersting replies!

[Assertnfailure]

Yeah....it can be a little presumptuous to assume you wouldnt need an interface for something though. I've had projects where I polymorphed to abstract classes, and then found myself later needing to switch everything to an interface. Depending on the type of interactions you're looking for, it may or may not make sense.

For example, if you need to be able to add the object to the display list, then obviously an interface won't give you any advantages.

Edit: Oh yeah, forgot another huge plus for interfaces...
Interfaces are lighter weight than abstract classes, which comes in real handy when you need to abstract the document classes of external swf modules.

[maskedMan]

Perhaps I'm overlooking something glaringly obvious, but I've just encountered an instance where I find IInterface style programming useful but it is currently extremely cumbersome. Here's what I mean:

I have several subclasses of MovieClip that need to share an interface, but who also need to retain all the normal functionality of MovieClip. But IInterface style programming doesn't allow me to do this...

var interface:IInterface = new InterfacedMovieClip();
  this.addChild(interface);
  interface.x = 100;
  interface.y = 100;
  interface.play();

Because this.addChild doesn't recognize my IInterface as a valid display object. Now I could solve that by casting IInterface as MovieClip like this...

var interface:IInterface = new InterfacedMovieClip();
  this.addChild(MovieClip(interface));
  interface.x = 100;
  interface.y = 100;
  interface.play();

But then I still can't call .x, .y, or .play() on interface unless I declare those items specifically in the interface like so...

public interface IInterface{
    function get x():Number;
    function set x(value:Number):void;
    function get y():Number ;
    function set y(value:Number):void; 
    function play():void;    

    //other IInterface functions below...
  }

This is very irritating. Do you really have to explicitly declare in your interface all the movieclip functionality required to make your interface do movieclip-like things? Moreover, can you somehow make your interface compatible with the displayObject such that you can just simply add IInterfaces to the display list without casting as a MovieClip, or some other display object first?

[acolyte]

Yo Masked Man ,

well i am relay not shure if i know what you mean but i think you mean Factory aka Virtual Constructor / where you are launching constructor via IFactory ?!?!?

i compiled an example

From Wiki :

The Factory Method pattern offers a solution. It encapsulates the knowledge of which Document subclass to create and moves this knowledge out of the framework.

http://en.wikipedia.org/wiki/Factory_method_pattern

http://en.wikipedia.org/wiki/Builder_pattern

sofar i only used interfaces like for example :
If i have a webservice building up on reflection (as/php) i am using my
interface for implementing the public function Methods reflecting to the php classes

Well its not necessary but its much more organized codestyle in my opinion i can send my Command.as Interface to my backendGuy and he knows exactly what methods to implement on the phpside and how many parameters the Methodes require.

interface Command {
    function get_folders(nr,nr0,nr1) : Void;

    function get_content(nr) : Void;

    function updateUser(arr,id) : Void;
}

[maskedMan]

Hi Acolyte,

The fla doesn't compile. It looks like you left out a "Factorys" class. But I think I get what you're going for here. I'm not sure it would solve my problem though, since the objects returned aren't DisplayObjects, nor do they implement any kind of DisplayObject interface that would let you use addChild to add them to the display list.

[acolyte]

Originally Posted by maskedMan

Hi Acolyte,

The fla doesn't compile............

here is the factorys sorry :

package {


    import flash.display.Sprite;

    import mat3d.dp.factory.*;

    public class Factorys extends Sprite {

        public function Factorys() {

           

            var factory : IFactory = new ChildFactory();

            var newFactory : IFactory = factory.newInstance();

            trace(newFactory.className);

           

            factory = new AnotherChildFactory();

            newFactory = factory.newInstance();

            trace(factory.className);
        }
    }
}

ahh and yes thats why Factorys extends Sprite