Greg Beaver wrote: > Greg Donald wrote: >> with it, but I will go grab a PEAR module if it fits my needs. Code >> re-use may be the only redeeming quality of OO programming, and >> honestly I can re-use your code from a non-OO include file just as >> easily. > > yep, unless the function names happen to conflict with ones you've > already written. Then, you run into the > oh-crap-I-should-have-planned-to-use-other-code-oh-well-I-guess-I'll-rename-everything-and-waste-hours > problem. Class names occasionally conflict, but this tends to be a much > smaller and simpler search-and-replace. Changing a function name in all my files is a one-line global search and replace. That assumes you write good code to start with, of course. > I would challenge anyone advocating functions: how many of you have had > to modify your function-based program to do a similar thing and been > forced to rewrite? Even with well-designed functions, you end up with > this problem - code modification is impossible. This is why I hardly > ever use static methods or functions. Notice - I do use these things, > but you have to know when it is appropriate to do so. Classes aren't a magic bullet -- You'll still need to write more code. It's even quite likely that you'll need to go back and change code in the original class to accommodate some weird thing in the new code / requirements. Then you need to re-test everything everywhere that relies on that class. A little forethought in your functions (or classes, for that matter) can often avoid this. I often have functions with code to handle situations my client hasn't realized they are going to need some day. Sometimes I even tell them about it, so they'll know that we're prepared. :-) > functions and static methods should be used for code that you can > guarantee you *don't* want to change - ever (well, at least almost > never). Anything that you may need to extend or modify functionality > must be implemented with something more flexible, or you're going to get > screwed at some point. Static methods should be used for any functions > that are re-distributable so that others can plug them in without risk > of name conflicts. Invariably, the other guy who wrote the class I want to use (in C++ now) decided to make something static/private that I actually don't *WANT* to be static/private to make my code work. Not fun. > If you're writing the code for Yahoo like Rasmus, you're going to write > the fastest code imaginable, and you will also be working on the C code > to do things. Since most Readers of this forum aren't writing code for Yahoo... > If you're writing the code for podunk.com, or even for a mid-level > traffic site, it is extremely unlikely that you will notice even the > slightest difference between OO and non-OO code. The biggest hogs in > php programming are: au contraire, my dear friend. I have often ripped out a bunch of OO crap and replaced it with functional programming and had SIGNIFICANT performance increases. All that class junk has to get loaded and parsed, and inexpereienced OO programmers invariably have three times as much code as they need, to no benefit. > 1) unnecessary images and animated crap/unnecessary javascript > 2) terrible database usage > 3) too much complexity in the design > > It doesn't matter whether you are using OO or functions - if your > application has too many lines of code per task, it won't be fast. As far as I'm concerned, classes almost always have too many lines of code per task. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
