How much OO is too much?

[digitman]

Until now, I use proecedural functions to divide all my code into functions. Sure, i had a few classes such as database class, form validation, etc which I would reuse again and again, but for the code used in 1 script only, i used procedural functions to divide the code.

E.g if there was a script used to add users to the database: its processing would be like this:

<?php
if (isset($_POST['submit']))
{
 validate();
 addUser();
 sendActivationEmail();
 displayConfirmation();
} else {
 showForm();
}
 die;
?>

But now I want to change the way I code and use classes even for normal/ single scripts. For example, instead of the previous processing method, i want to use something like:

<?php
$userAdder=&new UserAdder;
if (! $userAdder->isSubmitted())
{
 $userAdder->validate();
 $userAdder->add();
 $userAdder->sendConfirmationEmail();
 $userAdder->displayConfirmation;
 
} else {
 $userAdder->showForm();
}
die;

?>

I know there is no technical advantage of doing this.. but I want to do it simply because I enjoy OO coding more than procedural.

Do any of you guys also make your scripts this way? Are their any potential disadvantages of this method?

[bonefry]

Actually, that code in OOP goes something like this:

    $myUser = new User();
    $myUser->addOnInsertListener($mailer);
    
    if ($form->isSubmitted() && $form->isValid()) {
        $myUser->populate($form->getMap());
        $myUser->insert();
        $requestDispatcher->forward('showUser', $myUser->ID);
    } 

[digitman]

but you got my point dude

[jabird]

I've been learning PHP for some time now. I've never taken a single OOP tutorial though. But for some odd reason, it is comming extremely natural to me. This begin in mid-coding of my CMS. But when I get done with a stable version, I'm going to rewrite ALOT of it to OOP... I should have thought of it a long time ago. but now everytime I want to change a menu... I have to change it EVERYWHERE... that gets complicated...

So in version 2.0.0 it will go from the big huge bulky code to:
$jbcms->showMenu();

I think it'd be a great idea for you too...

[digitman]

which CMS is that?

[jabird]

JabirdCMS

My CMS.... It's by no means pretty... and its mostly procederal (sp?).

[gregor002]

I know there is no technical advantage of doing this.. but I want to do it simply because I enjoy OO coding more than procedural.

Totally with you on this one ... sure, I may not be able to reuse it but it's a lot cleaner and I enjoy (*shiver*) doing it.

[ethanp]

I feel that even though long time PHP gurus advocate against using OOP to group functions, it still helps out in your code. It is kind of like each object represents an idea or concept.

Although it doesn't match up with the purpose of OOP, it does make programming much easier. I've done it myself in the next version of a CMS that I'm writting now.

[Ezku]

I feel that even though long time PHP gurus advocate against using OOP to group functions, it still helps out in your code. It is kind of like each object represents an idea or concept.

Well, one could certainly argue that it's not OOP if you use objects only to group functions. Sure, it can help, but it's not "object oriented" by the least. :)

[arborint]

The code posted in the first post of this thread is not OO code. There is no difference between the first code and the second except the second code will be slower. If you just want to use classes to namespace you might as well just prefix your fuction names with "userAdder_" and make a real library out of it. Nothing wrong with that except the fact that even in procedural coding you would not create a library that: validates the request, writes to a database, sends email, and displays HTML. Bundling poorly structured code in a class does not magically apply structure.

[DougBTX]

Here's another way to divide the responsibilities.

I've used three classes: a User, a Request and a Notifier.

The User class is an ActiveRecord which is used to save data to a database. It will only let itself be saved to the database when it is valid, it validates itself when you try and save it and returns false if it cannot be saved. The constructor takes an associative array which correspond to fields in the database*.

Here, this array comes from the Request class. The Request class holds the keys to the $_GET and $_POST data, removing magic quotes and other helpful things.

The Notifier is responsible for sending emails, and uses an associative array to fill in the email templates.

$user = new User($request->get_params());
if ($user->save()) {
  $notifier->deliver_signup_for($user->get_params());
  $this->redirect_to('show', $user->get_id());
} else {
  $this->render($user->get_params());
} 

That code would end up in a fourth Controller class, which would be able to handle redirects, and pass on render calls to the View layer. The User class keeps a note of any validation problems it has when you try and save it, or ask if it is valid ($user->is_valid()). This data can be read by the View to render error messages and warnings about form validity.

Regads,
Douglas

* Because it is just an array, the data can come from anywhere. It is simplest if it can come directly from the Request, but you might like to do other processing on the data first, for example by setting default values for some fields if they were not in the Request originally.

[DougBTX]

JabirdCMS

My CMS.... It's by no means pretty... and its mostly procederal (sp?).

I've got some ideas for a PHP style mix of procedural and OO code which could turn into a framework. If they work well with the app I'm working on at the moment, I might try the "extract the framework" dance

Douglas

[digitman]

even in procedural coding you would not create a library that: validates the request, writes to a database, sends email, and displays HTML. Bundling poorly structured code in a class does not magically apply structure.

Thanks for the criticism.. now, make it constructive critisism and also tell me what would be the right way to structure this code, then?

[arborint]

This code is a little forced, but hopefully you get the idea.

if ($request->get('submit') == 'Submit') {
// should filter here too
    $validator = new Validator();
    $validator->addRule('username', new UsernameRule());
    $validator->addRule('password', new PasswordRule());
    $validator->addRule('password2', new matchRule('password'));
    $validator->addRule('email', new EmailRule('password'));
    if ($validator->isValid($request)) {
        $user = new User();
        $user->setUsername($request->get('username'));
        $user->setPassword($request->get('password'));
        $user->setEmail($request->get('email'));
        if ($user->insert()) {
            $template = new Template('emails/NewAcctEmail.txt');
            $template->set('username', $request->get('username'));
            $template->set('password', $request->get('password'));

            $ActivationEmail= new Email();
            $ActivationEmail->setMessage($template->render());
            $ActivationEmail->send($request->get('email'));

            echo $view->displayConfirmation($request);
        } else {
            echo $view->displayError($user->getErrorMsg());
        }
} else {
     echo $view->showForm($request);
} 

[DougBTX]

Imagine you have a function library which lets you write this...

$email = parse_template('emails/NewAcct.txt', $_REQUEST);

send_email($email, $_REQUEST['email']); 

Then replace the function paramaters with setters on objects...

$template = new Template('emails/NewAcct.txt');
$template->set_data($_REQUEST);

$email = new Email;
$email->set_message($template->parse());
$email->set_email($_REQUEST['email']);
$email->send(); 

And lets split that big, bad array up into more setters and getters...

$template = new Template('emails/NewAcctEmail.txt'); 
$template->set('username', $request->get('username')); 
$template->set('password', $request->get('password')); 

$ActivationEmail= new Email(); 
$ActivationEmail->setMessage($template->render()); 
$ActivationEmail->setEmail($request->get('email'));
$ActivationEmail->send(); 

oops... so all this object oriented stuff comes down to using global classes instead of global functions?

I don't think so.

Regards,
Douglas

[stereofrog]

IMHO, the complete oop equivalent to the above procedural code would be

$app = new MyApplication();
$app->handleRequest(); 

And yes, this is complete code. It's "testable" and you can now use, improve and refactor it. And that's the greatest thing about oop, compared to procedural.

[DougBTX]

Yep, it is in a class, so it must be OO:

class MyApplication
{
  function handleRequest()
  {
    if (isset($_POST['submit']))
    {
      validate();
      addUser();
      sendActivationEmail();
      displayConfirmation();
    } else {
      showForm();
    }
  }
} 

Don't you love the Façade pattern?

Later,
Douglas

[been]

Imagine you have a function library which lets you write this...

$email = parse_template('emails/NewAcct.txt', $_REQUEST);
  
  send_email($email, $_REQUEST['email']); 

You conveniently left out the validation part, didn't you

[printf]

To me there are so many things to think about when coding. Sometimes a OO is the best approach, other times procedural code using functions pertaining to what you are doing is better, then procedural code without a function call is sometimes better than anything you could think up! While OO will give cleaner code than procedural code the root of the trouble is not one or the other, it is each way that you may do something.

I'll give you example...

In the never ending battle to build the fastest most resource friendly services you will undoubtedly fight with the question 'what is the better way of doing something'. If you do, you know settlings for what others do is the wrong approach to take! Why, because never is one method or function, even core language functions always the best way of doing things! Only testing will prove what is truly better to use!

I myself have not jumped aboard the PHP OO train just yet as OO in PHP is still young and has many concerns for bottlenecking. Unless your serializing your objects I don't see where in all cases it is the smart way of doing everything, but like I said it does work in some places in coding but it will never be that 'use it every where' type of thing!

printf

[arborint]

oops... so all this object oriented stuff comes down to using global classes instead of global functions?

I agree and said the example was a little forced when I posted it. You could just use the email() function there (and I often do). I have always said that you could code fine PHP procedurally unlike the OOP purists. However those middle lines are not really what the example is trying to show. My goal was to present small single use object that work together.

To me there are so many things to think about when coding. Sometimes a OO is the best approach, other times procedural code using functions pertaining to what you are doing is better, then procedural code without a function call is sometimes better than anything you could think up! While OO will give cleaner code than procedural code the root of the trouble is not one or the other, it is each way that you may do something.

I think you misunderstand OO. In PHP, OO is a way to design and orgranize you code for flexiblity and testablity. It is not just about using the class statement everywhere. There are still calls to functions and critical sections look very similar and perform the same.

I myself have not jumped aboard the PHP OO train just yet as OO in PHP is still young and has many concerns for bottlenecking.

PHP4 was released in May 2000 so I don't know about "young", and I would bet that your "bottlenecking" is more theoretical than real.

[KeithT]

I use OOP all the time, I don't know how you see it, but as the email example above, I like the organization MUCH better than in procedural coding.

[Archbob]

Why would you use OO just to group functions, Wouldn't it be easier and the same thing if you just the function prefixes?

In C++, I used classes in stuff like game characters to store life, stamina, and other properties of a characters that were contained in the class. I also used methods in the classes.

But in working with php/mysql, I haven't seen a reason to go OO at all. All the data is stored in the Database as an array and its just as effective an quick for me to write functions to manipulate the data as classes.

I would say only use OO if you see a clear advantage, don't just use it to "look cool" or "look professional" because its not worth it and the code in reality isn't any better.

If your writing a massively OO PHP guestbook, you've probably taken it a bit too far.

[Dr Livingston]

While OO will give cleaner code than procedural code the root of the trouble is not one or the other, it is each way that you may do something.

It has to do with cleaner design, it has to do with a cleaner implementation, it has to do with applying test driven methodologies, and in doing so, it will allow you for easier refactoring and reuse at a later date.

That is the benifits of object oriented programming.

I myself have not jumped aboard the PHP OO train just yet as OO in PHP is still young and has many concerns for bottlenecking.

Learning and using object oriented programming methodologies is not about a gravy train. It's about a way of thinking, a way of life to some, a religion to others. Also, exactly what bottlenecks are you referring to?

I'm just not aware of any that is all

[DougBTX]

You conveniently left out the validation part, didn't you

Well, as you can see from the first code sample I posted, I don't think you should have a validation object in that part of the application. It should only try and save the User to the database, and return error messages from the User if it doesn't work. That's where the OO comes in (IMO), that you simply don't have to worry about the technicalities of validating the User class outside the User class. I shouldn't have to worry about that.

The validator code itself looks fine to me, it is just that it is in the same place you would put procedural functions* to check the validity of the request, rather than taking advantage of using objects and hiding it away.

* Just to proove I'm not talking hot air, the functions could look like this:

$errors = array();
validate_username ($errors, $request, 'username');
validate_password ($errors, $request, 'password');
validate_match    ($errors, $request, 'password', 'password2');
validate_email    ($errors, $request, 'email');

if (!$errors) {
  // do something ...
} 

The advantage of OO code is that if you can encapsulate that validation in the User class, so you don't need to duplicate the above validation each time you want to save a User object, you can just run it with $user->save();

Edit: and just to hammer it home, that could be $user->save(), $account->save(), $post->save(), $article->save(), whatever you like, it would have the same $anything->save() interface. That's polymorphism, and you loose it if you make the validation external to the thing being saved.

As an aside, I wouldn't want explicit UsernameRule or PasswordRules, I'd rather more generic IssetRule and LengthRule classes. You could always use custom ones, but those strike me as a better base set to have.

Regards,
Douglas

[DougBTX]

I agree and said the example was a little forced when I posted it. You could just use the email() function there (and I often do). I have always said that you could code fine PHP procedurally unlike the OOP purists. However those middle lines are not really what the example is trying to show. My goal was to present small single use object that work together.

Yea, we probably share something there. Seems like an inherant mistake to me to have a "single use object", because if you only need to use it once, why bother with an object? There are only a few cases where I only ever need some code once though

Douglas