On Tuesday 15 April 2008, Daevid Vincent wrote: > I've had at least three job interviews in the past two weeks, and each one > has asked me this rather "text book academic" question regarding the > difference between "abstract" vs. "interface". I've been coding for nearly > 20 years, and at least 10 of those have been in PHP and another 3 in J++. I > have NEVER used either of these concepts/keywords? Am I missing some > exciting tool/feature? > > All the reading I've done tonight just reinforces my thoughts that these > are, for the most part useless. Unless you're building some HUGE project > that has an API and there are teams of people that are going to extend your > framework, then what good are they? You've just answered your own question, albeit in a rather naive way. If your code doesn't have an API and clear separation of parts, then neither abstract classes nor interfaces are useful to you. If you're coding anything of respectable size, vis, more than a one-off 1000 line script or less, then you either want to have an API and clear separation of parts or I don't want to hire you, because your code is going to be an unmaintainable mess. Abstract classes and interfaces are a standardized, syntactic way to establish an API and clean separation of parts. They are not the only way to accomplish that goal by any means, but they are a commonly understood way that, if used properly, can create a very good API and very clean separation of parts. If used stupidly, of course, you'll create a system that is completely inflexible and impossible to extend. That comes down to the skill and experience of the developer and architect. If you're not writing OOP code, then neither is of any use to you as both are OOP concepts. (And you don't have to write OOP code if it doesn't make sense, but don't shun it either because often it does make sense.) In general, an interface defines a "front end" of a class, without specifying anything about its implementation. All component A needs to know about component B is that it implements interface Foo, meaning that you know, absolutely, that you can call $b->foo() and get back a string and $b->bar() and get back a database connection, because the interface says so. (If that's not the case, then B is buggy by definition.) You don't know or care how it goes about getting that database connection (creates it, loads it from a cache, creates a fake one for you, etc.), just that you can call $b->bar() and get back a database connection. A class may implement any number of interfaces. An abstract class defines a "front end" *and* the implementation behind it, modulo some bits. It is exactly the same as any other parent class, except that it defines bits of functionality that it is missing that its child classes *must* finish. That's useful if you have some number of classes that are *almost* the same, but have no "generic" form. Database abstraction systems are probably the canonical example here. Usually, you will want to use an interface (possibly with composition) over an abstract class unless you have a ton of shared code, as interfaces are more flexible in a single-inheritance system. Yes, you can get by just fine without them. You can also get by without OOP at all. However, there are some problems where OOP just makes things a lot easier, and in OOP there are places where having a formal interface just makes things a lot easier; like, say, when you're reading someone else's code and trying to make sense of what it's supposed to do and what assumptions are being made. Having that built right into the syntax can be quite useful, even in a loosely typed language like PHP. -- Larry Garfield AIM: LOLG42 larry@xxxxxxxxxxxxxxxx ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
