When does it make sense to use OOP?

[dbo]

Let me start by saying that I actually come mainly from an OOP background. I'm not a newbie, or someone trying to learn OOP for the first time. I understand its effectiveness. What I'm wrestling with right now is when it makes the most sense to use it, in web development, particularly PHP.

 

My general standpoint is that OOP provides a very logical representation of different "items" aka objects. You've got a few private members/properties that represent something, you've got some functions that allow you to operate on these things, access them etc. In addition, you're provided with a level of modularity that lets your code be reused iin subsequent projects.

 

So with that understanding, what are the benefits of using OOP if its code that really can't be reused and doesn't necessarily have any unique attributes... why should I use OOP.

 

The example I'm thinking of is this CMS I've inherited at work. A big majority of it is written procedurally, with some components having been converted to OO. The "backend" aka site administrator runs off a single index.php, it uses a get variable to determine which view to load up.

 

For example:

 

switch( $_GET['action'] )
{
   case 'settings':
      //load settings view
      break;

   case 'page':
      //load page view
      break;

    //......

    default:
       //load dashboard
       break;
}

 

 

Now this could be encapsulated and just be called like:

 

$obj->loadView($_GET['action']);

 

But what's the point in wrapping that inside of a class? Inside the class that same code is going to exist, and if I started a new project, the same idea could be used, but the class is going to have to be rewritten to accomodate the new views thus the modularity standpoint doesn't really exist.

 

So yeah, I dunno. Things that make sense to logically be represented I'm all for OOP. Admittedly, a lot of the web development I've done has not utilized a lot of OOP. I've got a few utilities that I wrap in classes so that they can be reused, but that's about it. Most of my OOP goes back to C++, VB.NET, C#, and Java days.

 

Interested on some of your insight.

[maexus]

OOP also provides a way of keeping most of the underlaying logic inside the objects, this also makes the logic structured and much easier to change. At least from my experience.

[dbo]

I think it depends on if you first have a logical object to represent. If you do then, yes I'd agree. However, if a class is just being used to wrapper a few functions I don't think it's anymore easy to maintain than a single file that has a bunch of functions.

[Acs]

I do agree with you dbo! I use classes with static functions but it's not really to use oop logic it's so that I can organize my code and make use of the __autoload function! I am still trying to really understand the power of oop. I have no problem creating a class. But I do have a problem grasping the full complexity of oop. That's mostly because I normally don't use inheritance or polymorphisms. Just plain old static function calls  

[keeB]

OOP for Re-usability is a good goal, but I have much simpler goals in mind. Maintenance. It's bound to happen, someone asks you to change a certain piece of functionality.

 

When these requests used to come it would really, really stress me out. I would think of all the the things I would have to change and all of the place it would affect, the overhead of testing such a change.. it was a NIGHTMARE.

 

Ever since I adopted my 'new way' of developing a few years ago, I actually get excited when someone asks me to change core functionality because it means my product gets expanded but, it's (generally) an isolated expansion.

 

I always develop with these core ideas in mind:

- Do not break encapsulation. Ever. Ever Ever Ever. It may sound like a good idea, it may sound OK to break this rule just once, until something changes and because you rely on some accessor in multiple places and the accessor has to change.

- Always program to an interface.

 

 

Getting on to your specific questions, though, dbo, here's my take:

        $obj->loadView($_GET['action']); 

 

The easiest benefit I can come up with is, if, say you want to have 'settings', and 'administration' shown on the same page, you could simply

 

<?php
try {
   $obj->loadHeader();
   $obj->loadView("settings");
   $obj->loadView("administration");
} except (PageDoesNotExistException $pe) {
   $obj->404();
}
?>

 

Now imagine for every variation having to update your switch statement case: 'settingsandadministration.' Which is easier to maintain/read?

 

Consider the following structure:

 

<?php

interface Page() {
   public function display();
   public function authenticate(User $user); //can this user access this page? This is implemented on each page in (potentially) it's own way. 
}

public class SettingsPage implements Page {
     public function display() {
        //echo some settings out here. Could actually use a form which is an abstract class that implements Page.
     }
}

public class AdministrationPage implements Page {
     public function display() {
        //echo some settings out here. Could actually use a form which is an abstract class that implements Page.
     }
}

public class PageFinder implements Page {
         public static function getPage($name, User $user) {
               switch ($name) {
                     case 'settings':
                         $s = new SettingsPage;
                         $s->authenticate($user); // throws exception, let parent script handle it.
                         $s->display();
                         break;
                     case 'administration':

                     default:
                           throw new PageDoesNotExistException("Page could not be loaded");
               }
         }
        
}

?>

 

Making sense?

[dbo]

Yeah your code does make sense. Although I'm not sure it's necessary or would make maintenance any easier in this particular instance... so I do appreciate the response, I'm just not sure that it convinces me to always use OOP, because I'm not sure that it is always necessary.

 

That being said, I've recently developed the base structure for a framework... that leverages MVC and OOP, so moving forward I probably will be using mainly OOP