Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
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.
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:
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
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.