Question

Please refer to the post :
Display checkbox inside Flash List Control ? (Similar to itemrendering in Flex)

As usual, i always get somewhat confused with the significance of Interface.

So in the above link, i still don’t get what is the significance of specifying ICellRenderer

Why can’t instead of :

  public class CustomCellRenderer extends CheckBox implements ICellRenderer 

I can write

   public class CustomCellRenderer extends CheckBox  

I tried to play with above line, but it doesnot work. I MUST specify ICellRenderer.

In my opinion, Interfaces, just tell a class to follow a certain rule of using functions. How can it stop the working of the class ( if i have used all the necessary functions, but not implemented the required interface )

Thnx in advance.
Vishwas.

Answer 1

Due to checks in other code on your objects not implementing an interface can cause a failure. However this is the advantage of interfaces as well, your class doesn’t need to extend from something to implement an interface, so it can arbitrarily extend from any class but implement a particular interface that means it has some other functionality outside of the things it got from it’s inheritance chain. So Adobe (or whoever) codes something up like:

if(argumentObject is ICellRenderer)
{
   var icr:ICellRenderer = argumentObject as ICellRenderer; //cast so code completion can work
   icr.data = data; //do some stuff on the object that only an ICellRenderer can do
}

Let me know if this explanation isn’t clear, it took me a long time to come to grips with interfaces and their use, but now I’m a huge advocate.

Supporting Arguments

Insofar as inheritance itself is concerned, just for clarity the concept is that if something is just like something else but with extra properties (nouns) or actions (verbs) associated with it, you need not re-write the common parts.

To use a common example say you have a class Animal (properties such as isAlive, actions like reproduce). Now say you want to make a class for SexualAnimal and AsexualAnimal and in the reproduce method for the SexualAnimal takes an argument whereas the one for AsexualAnimal doesn’t (SexualAnimal would have an overloaded version of the reproduce method and would override the default throwing an error). Okay so that’s all well and good now say somewhere down the line we get to Birds, now we have a choice on how to handle flight, we can A add flight as a boolean somewhere in the inheritence chain or B create an interface for flight (perhaps we aren’t concerned with where in the inheritence tree an Animal is we just want to know that it can fly and therefore has certain properties like altitude and actions like takeFlight). Rather than check for every individual property that you want to possibly use on a flying thing you can just check is IFlyingThing.

Another way to see this is, as a programmer I can write up an Interface give it to another team and we can both operate based on the “contract” established in the Interface. For example say I need to access a database to do some operations, but I don’t know which database solution their going to go with long term. So I write an interface for what I need the DB to be able to fetch Y data with X argument, now I’m free to write the rest of my code under the assumption that I supply X and you give me Y, no matter what the underlying implementation my code will work.

For a more formal reference to uses of interfaces see: http://en.wikipedia.org/wiki/Design_Patterns