On Wednesday 16 April 2008, Daevid Vincent wrote: > > -----Original Message----- > > From: Larry Garfield [mailto:larry@xxxxxxxxxxxxxxxx] > > > > 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. > > That is soooo not true. My last company had nearly 15 developers and we > never used either of these concepts in the six years the company existed. > We had perhaps 50+ classes and some had upwards of 5-KLOC each. We had > three databases with almost 300 tables. We had an external XML API that > hooked into these classes with 'set', 'get', 'add', 'delete' and all the > commands you would expect. And we weren't doing simple stuff either. This > was an extremely complex appliance that was HEAVILY PHP/Ruby driven > (http://www.lockdownnetworks.com). > > I'm not trying to start a war here, I just really don't see how any PHP > project other than the very fringe examples such as a DB abstraction > project or huge PEAR project has any _real_ need for this. Sure, it's all > text-book and "proper" perhaps, but to me it just seems like bloat and if > you intend to extend a given class, you STILL have to read the source code > and examine the abstract class or interface anyways to know what you have > to implement in your derived class (right?) > > 90% of the LAMP projects amount to some website/service, some user > registration, some blogs or threaded discussion, some database entries. > They're really not all that complex in the big picture. > > I can sort of see the use for these if you were designing an operating > system or a device driver or something HUGE. But come on -- a website is > really not that big (code wise). It may have thousands of pages, but > they're built from a relatively small amount of dynamic PHP pages. > > In any event, thanks for your detailed reply Larry. I get the concepts. I > just don't see the general-use-case need in PHP's OOP world. Maybe sometime > the light-switch will flip on for me and I'll realize I've been skating > uphill all these years... > > Daevid. > > P.S. you should look at my resume before you decide not to hire me ;-p > http://resume.daevid.com Please take note of what I said. I did not say "if you're coding anything of respectable size without interfaces and abstract classes, I don't want to hire you." I said "If you're coding anything of respectable size clean separation of parts and an API between them, I don't want to hire you." Interfaces, abstract classes, and the rest of OOP are *A* way of defining an API and separation of parts. It is not the only way. OOP is a tool, and sometimes it's the right tool and sometimes it's not. Yes, it's overkill for many small projects, but that doesn't make it never-useful. I'm a Drupal developer. Our codebase is huge, and our contrib codebase is over a million lines of code, I think. There's maybe 4 classes total in all of that, all of them very recently added. :-) And yet the system itself is extremely modular with clear APIs. It's the "modular and clear APIs" part that makes it good, not the number of classes it has (or doesn't have). Besides, interfaces and abstract classes only came to PHP in PHP 5. :-) Now, that said, a 5000-line class? Unless 4500 lines of that is comments, I have to question if you're understanding OO design properly. :-) -- 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
