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]

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

[maskedMan]

Aaaaah, werry clever! :) That makes sense. I think this more clearly illustrates Abstract Factory for me than any of the literature I've read on the topic.

[acolyte]

was it the thingy you was looking for ?? did it helped you .

Discussion about design pattern theory in the Best Practice area in my Opinion would be a nice Sticky thread - dont you think .

So we could collect a library covering all patterns with flash/flex examples

[MichaelxxOA]

If you end up needing an interface just refactor your code. Simple code right now will make things easier when refactoring later.

[maskedMan]

Sorry it has taken so long to get back to you, Acolyte! Work is busy. :)

Hmmm... So, the "Factorys" itself is a sprite, but the IFactory objects it requests instances of are not. I suppose if the IFactory objects were in charge of changing some graphical elements in the Factorys object it could work. The problem is that while you're able to get IFactory objects just fine, you can't add them to the display list because they aren't considered by the machine to be display objects. That's what I'm really getting at... a way to instantiate any number of different subclasses of MovieClip/Sprite without referring to classnames, or even superclassname, but instead by using a common interface and then add them to the display list.

[creynders]

Just declare a getter for the instance as a MovieClip in the interface definition.
//interface
function get mc() : MovieClip
//implementation
public function get mc() : MovieClip{
return this as MovieClip
}

[maskedMan]

I did eventually try something like that, and it worked for a time. Problem was that it still didn't know its own base class if you used things like getChildAt(x) to retrieve it... so I took a little bit from Acolyte's example and created a recasting utility that basically accepts any object and returns it cast as its classname. Absolutely useless in most cases, but absolutely awesome if you are trying to stick an interface into a display list, or retrieve from said display list and immediately invoke a function or assign a variable. :)

I then took it a step further and added the recasting utility to a second utility that creates new instances of objects you pass to it. It has as function for making just default instances, a different function that accepts objects implementing an IClonable interface that allows the object that is to be coppied to be responsible for setting all of its relevant data in its clone before the clone is returned by the utility. It's a primitive, but in all the cases I need it effective way of duplicating display objects. :)

[acolyte]

I did eventually try something like that, and it worked for a time. Problem was that it still didn't know its own base class if you used things like getChildAt(x) to retrieve it... so I took a little bit from Acolyte's example and created a recasting utility that basically accepts any object and returns it cast as its classname. Absolutely useless in most cases, but absolutely awesome if you are trying to stick an interface into a display list, or retrieve from said display list and immediately invoke a function or assign a variable. :)

I then took it a step further and added the recasting utility to a second utility that creates new instances of objects you pass to it. It has as function for making just default instances, a different function that accepts objects implementing an IClonable interface that allows the object that is to be coppied to be responsible for setting all of its relevant data in its clone before the clone is returned by the utility. It's a primitive, but in all the cases I need it effective way of duplicating display objects. :)

Wow that sound nice maskedman i like to organize my mediator like this what is most of the time a subclass of my view if you dont care i would love to see wht you found out about this topic
so it would be cool if you could upload a example maybee ?

What is a good rehearsal maybee for realy getting a crasp what
factory is doing infact i would recommend checking out steven sacks awesome gaiaflashframework what is one of a big factory .

http://www.gaiaflashframework.com/

If you follow the framework flow you will recognize that it is the factory what is abstracting away complexity what if you know what is all about with this strange word "consultancy" :| could be worth something if you are forced to work with nasty stinky sphagetticoders.

bw

m@

[NickZA]

Programming to interfaces forces you to think about your classes in terms of the services they provide... which in truth, is all that matters.

I find it prudent to structure objects first around what they provide (methods). Their internal structure is a function of these provisions.

In other words, don't build something in earnest until you know what it's for.

(P.S. This does not mean you cannot change your interfaces as you go, but by a certain point they will have solidified as you realise your requirements through coding... cf. the XP way: the "true" design emerges as you work.)