OOPHP Dialogue

[RopeADope]

Hi all.

 

I have some questions in reference to using OOPHP.  All of my programming thus far has been procedural and that's worked out great for me, but there's (obviously) a huge market for OOP.  I'm confused on how to apply the OOP concepts to what I'm already doing procedurally (or if OOP even applies to what I'm doing).  A lot of what I do is PHP/MySQL, so how do I apply OOP concepts to that relationship?  At what point do things become objects that should be put into a class?

 

I found this example but it seems excessive compared to writing only a  simple connection function

http://forum.ragezone.com/f427/simple-oophp-mysql-connection-679020/

[btherl]

If you find yourself writing functions with a common theme, like user_login(), user_logout(), user_get_last_login_time(), then that would make a good class.  Or if you find yourself creating a seperate file to store a bunch of related functions, that's also a good class candidate.  A class is a bunch of related stuff that more or less belongs together.  It's analogous to a library in procedural programming, with some additional framework (keeping variables and functions together, automatic initialization and freeing with constructors/destructors, inheritance, privacy) to make life easier.  You could call OO programming a "library-writing library" - a bunch of stuff useful for writing libraries.

 

I'm also a procedural programmer who started on OO because my workplace used it.

[KevinM1]

If you find yourself writing functions with a common theme, like user_login(), user_logout(), user_get_last_login_time(), then that would make a good class.  Or if you find yourself creating a seperate file to store a bunch of related functions, that's also a good class candidate.  A class is a bunch of related stuff that more or less belongs together.  It's analogous to a library in procedural programming, with some additional framework (keeping variables and functions together, automatic initialization and freeing with constructors/destructors, inheritance, privacy) to make life easier.  You could call OO programming a "library-writing library" - a bunch of stuff useful for writing libraries.

 

I'm also a procedural programmer who started on OO because my workplace used it.

 

Eh, not really.  What you're describing is using classes to create your own abstract data types, which you then use in a procedural manner.  That's what I used to do with C++ way back in the day.

 

True OOP is a lot different in that the currency of the paradigm is objects.  Objects do all of the heavy lifting - they construct each other, contain one another, pass data, or even entire objects around....

[btherl]

If "true OOP" means you have to make everything into an object, then I am not a true believer   OO is something to be used when it helps, and to be avoided when it will cause more trouble than it's worth.  I think that making everything object-centric would be a mistake, just as making everything procedural would be a mistake, given that OO is available.

[KevinM1]

If "true OOP" means you have to make everything into an object, then I am not a true believer   OO is something to be used when it helps, and to be avoided when it will cause more trouble than it's worth.  I think that making everything object-centric would be a mistake, just as making everything procedural would be a mistake, given that OO is available.

 

I hear ya.  I don't use OO for small projects simply because of the overhead.  It's just too much work for something like a small page controller.

 

RE: 'true' OOP or not, the best way to tell is by looking at the main script.  OO projects tend to have a very small main script, which is often just a front controller which parses requests and funnels them to other objects which know how to deal with them.  Rather than one hefty file with includes here and there, there's a small file for the front controller with the rest broken up unto class files, which are autoloaded when necessary.

[RopeADope]

Hmmm.  I still feel a little fuzzy on when and where to implement OOP.  From what I've gathered here, it seems like both OOP and procedural have a time and place and both can be used concurrently.  I think the trouble I'm having is finding a good example of where OOP is more appropriate than procedural.  Any ideas/code examples?

[btherl]

Let's say I'm writing a collection of RSS feed fetchers.  Usually they use the same format, but some of them have quirks.  Each has a different url, and may have different settings.  I could implement them as a single parent class called RSSFeed, with a subclass for each site.  The parent class defines a common interface and also has code for handling the most common format (or formats).  In most cases I can implement a new feed by just subclassing the parent class and changing the url only.  If a new feed has some kind of quirk, I can override whatever methods are affected.

 

There are problems with this approach - overriding the parent method may lead to code duplication, and it may be better to alter the parent methods so they support the new format.  But in general it allows me to implement a new feed like this:

 

class TheAgeFeed extends RSSFeed
{
    private $url = 'http://feeds.theage.com.au/rssheadlines/top.xml';
}

 

And that's it.  Now to use the new feed:

 

$feedObj = new TheAgeFeed();
$headlines = $feeObj->fetch();

 

Assuming fetch() is defined in the parent, and fetches and parses a standard RSS feed.

 

So that's an example where inheritance works well.

 

If you're not using the fancy features like inheritance, then the main benefit of OOP is that it helps to organize things, and allows you to make visibility rules.  It's especially important in PHP as PHP has no other mechanism (apart from resources which have to be created in C code) to declare that a variable is a specific type of thing, such as an RSS feed.  Then if you try to use the wrong type of object in the wrong place it'll tell you.  That means PHP is doing the debugging for you, by checking that your code follows the rules you set for it.

 

 

[gizmola]

Hmmm.  I still feel a little fuzzy on when and where to implement OOP.  From what I've gathered here, it seems like both OOP and procedural have a time and place and both can be used concurrently.  I think the trouble I'm having is finding a good example of where OOP is more appropriate than procedural.  Any ideas/code examples?

 

The basic mechanics of OOP take a while to learn.  Once you learn those, there remains a gap between having OOP as a tool in your toolbox and understanding how to make it work for you.  For the most part, where you really see oop is in largish projects (frameworks, complicated applications etc.).  I'm sure you've used a library of functions from someone in the past, and purely as a distribution method, oop has advantages for people who have written a library to do something.

 

But in terms of your own understanding, oop is the foundation that enables the implementation of design patterns.  There are many books on this topic, so I'd recommend that you take a look at some of those.  From what I've read in recommendations from other people there are at least a couple of good ones that tackle the topic in php code.  You can also take a look at zend framework or symfony to find examples of the implementation of design patterns.

 

One example that I think helps is the example of an object relational mapper like Doctrine or Propel or Zend_DB_Table. Reading the documenation for these, you will often see reference to a particular design pattern they are trying to implement ("table gateway pattern" or "Active record" pattern).

 

People are used to the idea of making sql queries and getting back rows of the data from a query, and then working with that.

 

With an ORM, you have to change your thinking -- you aren't working with a "row" of data, you are working with an object.

 

Since objects have behavior this leads to code like this:

 

// change name
$person = PersonTable::getOneById($personId);
$person->firstname = $_POST['firstname']; 
$person->lastname = $_POST['lastname']; 
$person->save();

 

Rather than dealing with functional routines, you're dealing with objects that have behavior.  It's a different way of thinking about problems and coding.