View Full Version : when to OOP?

11-28-2007, 03:51 AM
I'm pondering whether the conversion of my existing webapp to OOP will be beneficial or not and I'm having a hard time grasping the advantage of OOP other than readability. It seems there are many performance disadvantages associated with it, some quite significant.

OOP is definitely more "logical" coding and readability

$mazda = new car('black'); $mazda->go();
rather than
$mazda = makeCar('black'); go($mazda);

my webapp for example needs to have a function (or a class) that generates various <div> containers with varying attributes like height and width in px or em, different css style classes and different contents. the function will have built in presets so will be used like genDivDialog('styleA',$titlebartext, $contentText).

many different dialogs may need to be produced in the same script with different styles and different contents.

I would definitely like to make divDlg class if warranted so that the parameter assignment wasnt vague as it is with a function.

$noteDlg = new divDLg();
$noteDlg->style = 'styleA';
$noteDlg->title= $titlebartext;
$noteDlg->contents = $contentText;

the latter is much more wordy but easier to read, but i dont know if i need that despite the fact that it may be reused many times, what would a class let me do more effectively in a stateless scripting language like PHP?


11-28-2007, 05:05 AM
Even in a comparison of C vs C++, which is comparable to what you are trying to determine, runtime speed is sacrificed at the expense of better readability and reduced coding time in C++, which has OOP abilities. C on the other, while often faster, is often harder to implement things in (C lacks a built-in variable-length string type/class, whereas C++ has a string class). The idea behind C++ is to make your code as efficient as possible while making your code time as efficient as possible at the same time.

I guess I am trying to say that sometimes it makes more sense to use OOP than to create a bunch of functions that require type-checking for a certain data type, etc. OOP simplifies things for you since members (functions and variables) must be of your class.

The only problem with OOP is a speed sacrifice sometimes. In C++, the sacrificed speed is often negligible, but in PHP, I'm unsure about the speed impact. In both C++ and PHP, it comes down to how much you use an object. If you use it often, as you mentioned near the end of your post, it is a matter of how you access things. If you call a bunch of functions, then the function code must be loaded into memory and executed, while keeping everything else intact. You could use class members in place of functions, in which case the speed won't be as bad because you would be directly accessing the members of the class. Functions are usually necessary, no matter what. The trick is to determine when to allow access to members and when to use functions.

11-28-2007, 06:00 AM
I guess i'd need some examples of when it would be advisable and ill-advised to use OOP in php. Since i dont have vast experience in OOP, i dont see where the fine line is. As far as type checking...maybe i'm wrong, but PHP should have a lot fewer issues with that since it takes care of doing conversions and you dont need to worry about pointer types or sizes of double/floating point/int numbers, there sould be much less casting and conversion that in C...

my father is a C/C++/VB programmer of 30 years and how he explains the advantages of OOP boils down to making generic interfaces to functional modules which can easily be reused by different developers in a large(r) development team where everyone works on different parts of the code that needs to work together....and essentially have the need to use the classes as "black boxes" with known inputs, outputs, and properties, but not necessarily the internals.


11-28-2007, 05:38 PM
PHP can't be easily compared to anything to get a good idea of how to use it.

In my experience, whenever I redid something in OO style, it became many times more useful. It's not just readability, it also affects how easy it is to maintain and extend.

The generic part is something you decide. My solution involves several basic/generic classes that do something (a basic template class, a basic form class, a basic sortable table class). They are all available through the include path along with an autoload setup, meaning I never have to include files. This also improves my ability to make changes without breaking code.

For every new website I make, I save a lot of time with these. And whenever I need one of the classes to behave differently, I just create a new class local to the website, inherit the existing base and override one or more methods.

Now, the difficulty lies in where to draw the line between OO and procedural. PHP is not ready currently to be used completely OO. You have to look at what you need, and see if it will be reused often or may need to be extended.

The speed impact is not as big as one would think. It's only important once you get a large amount of pageviews.

Once PHP6 comes out with 'built-in' caching, these concerns will rapidly diminish as PHP will no longer have to recompile everything per page visit.