Home Tutorials Forums Articles Blogs Movies Library Employment Press
Old 12-25-2008, 02:38 PM   #1
rawmantick
Pipty rupees only!
 
rawmantick's Avatar
 
Join Date: Jul 2007
Location: Germany
Posts: 1,730
Default Programming to interfaces

I have more a trouble of thinking how to make it "regular" rather than how to make it work.

As you, it's recommended among almost all the experianced developers to program to interfaces.

Let's just look at an example. I have two interfaces: IView and IItemRenderer. IItemRenderer is an interface for single data object visualization. IView is like some some of container for item renderers, and it has methods like:
addItemRenderer(rend:IItemRenderer)
removeItemRenderer(rend:IItemRenderer).

Everything looks good for now... We just implement those interface with exact classes and things go well.

My trouble starts when I have to deal with item renderers as not just instances of IItemRenderer, but as for example instances of IEventDispatcher. Say I just want to hang some event listener to freshly added renderer.

So what do I do? Pass an exact renderer as an argument to view's addRenderer(). Argument's exact type is some display object. But in fact, I should deal with it as with IItemRenderer. How is that? I cast the argument to some type, for example Sprite. Eh... This is the problem. Since IMO casting is a very bad thing in this case.

So, what are the ways to go:

1. Just cast it implying on the fact, that it is an IEventDispatcher.

2. Let the IItemRenderer extend IEventDispatcher of IUIComponent (well in a Flex case). Ehh... I think extending interfaces is a bad thing. Interface is like some atomic thing keeping one single functionality set. Yes, this one solves thew problem... but what if I need more interfaces to be mixed in? AS3 does not support multi-inheritance. Moreover sdometimes there is no interface to one or another flash class, take a look at Sprite for example. It doesn't have someth like ISprite.

3. The solution I use, but still not sure if this one is a regular one. I make some AbstractItemRenderer class, that extends UIComponent (or Sprite) and implements IItemRenderer and IUIComponent and IEventDispatcher. After that I change interface IView so for now it deals with that abstract class, not with the pure interface. This method looks the most handy to me. But is it still a programming to interfaces??? I'm not sure...

What do you guys think of it? Which one is right, and which one is wrong? Which way do you prefer, and why

I'd appreciate any discussion of those, who have the same trouble making their head boilng sometimes...

Sorry for my english
__________________
Bang!
rawmantick is offline   Reply With Quote
Old 12-25-2008, 09:43 PM   #2
newblack
dondeEstanMisPantalones?
 
newblack's Avatar
 
Join Date: Nov 2005
Location: New York Proper
Posts: 1,355
Send a message via AIM to newblack
Default

your english is fine!

i've handled that problem in the exact ways that you have. i'm NEVER happy with the first solution. the 2nd is a more appropriate solution. i don't have the same issue you do with it- i have no problem extending interfaces.

ultimately my thought is that when you run into this problem, you're trying too hard to type to an interface. an interface should elegantly describe an imposed structure so that its use is completely extracted from the caller. when you get into nit-picking over whether you're treating it as an IView here or an IEventDispatcher there, you're holding structure is over-stepping its bounds in trying to simply use that interface's offering of a set, simple, extracted API. so it's ultimately not a problem with your interface or your implementation of it, but rather your use of it, i think.

i think that if you can handle your needs via inheritance, then you don't need an interface. if you need an interface to abstract an API, and if you run into the problem you're describing, you might be expecting too much from that interface.
__________________
i am gibreel farishta
general relativity
jellytanks alpha redux
newblack is offline   Reply With Quote
Old 12-26-2008, 07:10 AM   #3
rawmantick
Pipty rupees only!
 
rawmantick's Avatar
 
Join Date: Jul 2007
Location: Germany
Posts: 1,730
Default

Thanks newblack. The more I think of it the more I realize what you've said. I want to much from interfaces. Yeah, it's awesome, if you have built your system on only interfaces. But sometimes it's almost impossible. So system built on abstract classes that implement required interfaces is a good thing either. So probably I'm still on 3'd one.
__________________
Bang!
rawmantick is offline   Reply With Quote
Old 12-29-2008, 03:40 PM   #4
yell0wdart
jordanrift.com
 
Join Date: Sep 2007
Location: Phoenix, AZ
Posts: 366
Default

I think a lot of people get hung up on "programming to interfaces" because that's the verbage that a lot of books use. In fact, a lot of books I've read use that terminology when they're meaning "programming to abstractions" (abstraction meaning an interface OR an abstract class). There's a fantastic book I read on Agile development and OO principles that puts a very practical spin on your problem (never mind the fact that it's a C# book, the OO principles outlined still apply).

If you create an abstract class that implements the needed interfaces, then you're essentially getting the same benefit that you'd get from "programming to an interface". My thought on the issue is not to get so hung up on that term "interface" and focus more on abstractions. Using an abstract class allows you to leverage inheritance to apply the OO principle of Dependency Inversion.

I think the approach you're taking with #3 is just fine. Probably the same approach I'd take, if dealing with the same issue.
__________________

bad developer

Jordan Rift

Last edited by yell0wdart; 12-29-2008 at 04:01 PM. Reason: Adding link
yell0wdart is offline   Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Programmer-Oriented Programming MichaelxxOA Best Practices 43 02-22-2008 08:54 AM
Senior Flash programmer in Quebec City Bettye Projects and Positions 1 01-30-2008 07:00 PM
Help In Math Programming! zellwwf ActionScript 2.0 1 04-01-2007 09:09 PM
Interfaces: Overwriting methods. Covenent ActionScript 2.0 0 05-20-2004 09:32 PM


All times are GMT. The time now is 12:25 AM.

///
Follow actionscriptorg on Twitter

 


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Ad Management plugin by RedTyger
Copyright 2000-2013 ActionScript.org. All Rights Reserved.
Your use of this site is subject to our Privacy Policy and Terms of Use.