Page 2 of 2

Posted: Tue Jun 05, 2007 3:34 pm
by superdezign
Maybe I've been using abstracts incorrectly, but I use them mostly to define one of two things:
  1. Member variables that need to be shared among classes (and functions if there are any)
  2. Functions dealing with the setting, getting, and finding of necessary member variables that are shared among classes
Interfaces, however, I've only used just to be able to ensure that the methods are defined before trying to use them with instanceof.


The more and more I hear, the less and less I know, so I've gotta be sure that I'm at least in the correct mindset. ^_^

Posted: Tue Jun 05, 2007 4:11 pm
by Christopher
timvw wrote:Last year i've been in a situation with teams that actually 'consume services' from each other, and in that situation i've really started to appreciate the advantages of programming against an interface instead of a concrete implementation :)
Exactly. When you need to enforce an interface then using interfaces is they way to go. However, you can also do "programming against an interface" without the run-time error checking provided by an interface definition.

Posted: Wed Jun 06, 2007 12:39 am
by timvw
TheMoose wrote: But with the method you added, you cannot create separate drinks because your Drink class is a single instantiation with concrete methods of its own.
Imagine the situation where you have beer in a bottle and beer in a can... Using abstract classes you would implement them as following:

Code: Select all

class BeerInBottle()
{
 function Open() { ... }
}

class BeerInCan()
{
 function Open() { ... }
}
And for Wine in bottle you would want to re-use the Open method of BeerInBottle (because they both open bottles).. If you want to reuse the method for opening you have to declare Wine as an inheritor from Beer

Code: Select all

class Wine : Beer 
{
 / /only way to reuse the functionality to open bottles....
}
With the interface approach you could do it as:

Code: Select all

class BottleOpener : IOpener
{
 function Open() { .... }
}

class CanOpener : IOpener
{
 function Open() { ... }
}

beerInCan = new Beer(new CanOpener());
beerInBottle = new Beer(new BottleOpener());
winInBottle = new Wine(new BottleOpener());

Posted: Fri Jun 15, 2007 1:36 pm
by BDKR
arborint wrote: I have only found one or two cases where either interfaces or abstracts actually solved a problem better than not using them.
I've not yet run into a lot myself, but in those cases, it's a fantastic tool. It's too bad that the recent time where there is use is in PHP4 so all I can do is state that the class should be extended and thought of as an interface. Let's see if other developers are keen on reading comments. :)
arborint wrote: I see programmers create an interface reflexively without ever having a problem enforcing an interface. Call them a Premature De-optimization.
:rofl: :rofl: :rofl: :rofl: