NYCPHP Meetup

[Dan Cech]

bpang at bpang.com wrote:
> I've been "trying" to cross over, or at least start writing OO code, for a
> long time, but I never can seem to fully catch on.
> I am pretty sure I could identify many instances where my code would
> benefit from OO, and I've been told that my procedural code is written in
> OO format, just without the use of objects.
> 
> This may be near impossible to answer, but, what would you say is the key
> to "grasp the concepts behind OO" and to put it to use?

Hmm, it is definitely tough to pin down, and I would be no means claim 
to be an expert on OO design.  I guess the turning point for me was the 
idea that rather than working with data you are working with objects 
which give the data structure and turn it into information.

For example, say you have a bunch of news postings to go on the front 
page of your website.  The standard (procedural) approach for php would 
be to view them as a set of rows in a table, and you would write a loop 
to go through them and for each row put each piece of data into its 
place in the output.

In an OO approach you would create a class to deal with the table as a 
whole, and take care of creating/deleting/retrieving news items, and 
another class for the individual items, so that in your application you 
can just ask your news system to display the news, and each piece of 
code is contained within its object.  If you want to change the way news 
is displayed, or add a new attribute, you can just make the changes to 
the news_item class and the rest of your code should work just fine.

Basically you can modularize the code into bite-sized pieces, rather 
than having it all strung together into one procedural blob.  The other 
advantage comes when you decide you want to be able to have reviews as 
well as news, so you create a basic class with all the functions common 
to both reviews and news items, then a class which inherits from the 
base for news items and one for reviews.  By using the OO approach you 
can effectively reuse your code, rather than the procedural approach 
which would have required you to copy and paste the news code and then 
modify it to try and work with reviews.

Mambo (<http://www.mamboserver.com>) is a damn good example of this kind 
of approach to coding, every type of object in the system has its own 
class, all of which inherit from a base class with the core functionality.

Personally I'm striving toward this kind of reusability and modularity 
in my own coding, though it is much easier in theory than in practice!

> I suppose if I forced myself to use it, I would probably figure it out,
> and I always feel a little "learning-disabled" for not having picked it up
> yet, even after some tutorials, etc, but then Felix comes along and makes
> me feel better about it...
> 
> Felix said:
> "For most simple web based stuff you will almost never need to code
> objects yourself."

Felix is right, there are tons of useful bits and pieces of OO code out 
there, just ready to be taken and incorporated into your application 
(one of my favourites is ADOdb), so theoretically you could code a 
'crossover' app by stitching together existing OO objects with your own 
(procedural) code.

Dan

>>I think it is more than possible, though personally I prefer PHP to
>>Java, and for anything web-related I would almost certainly use PHP
>>rather than Java, purely because it is so flexible and easy to use.  As
>>for crossing over into OO, just take things one step at a time, once you
>>grasp the concepts behind OO you will see plenty of situations where you
>>could use OO design methods.  For example there are countless situations
>>where you can encapsulate functionality into a generic object, then use
>>inheritance to specialise that object for your particular needs.
> 
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>