3

I have a PHP application (a web service). It consists of files grouped in directories by theme like : 

    /customer
        /search.php

with this example content :

Auth::authenticate($options);
$db = new Db($options);
$db->query("select ... ");
echo json_encode($db->fetch_all();

A basic way to convert this code to object oriented code would be to map a URL /object/method.php to $Object->method($post_parameters) using a basic router. The above example code would become (in file /Customer.php):

class Customer
{
    function search($post_parameters)
    {
        Auth::authenticate($options);
        $db = new Db($options);
       $db->query("select ... ");
       echo json_encode($db->fetch_all();
   }
}

Advantages

  • It is that it is easy to convert the code, it will not take much time. 
  • I can use autoloading of the classes. 

Disadvantages :

  • It is merely formally object oriented. It still remains mainly procedural code. 
  • I still call Auth::authenticate() and create a new Db in each method (but not always with the same parameters). 

Am I on the right track ? Is there a better way to approach that code refactoring ? Or is there an obvious next step ?

Do you think is what I described a legitiate use case for procedural code ? Is there a middle ground between this and an object oriented approach with a full fledged framework like Zend framework for instance ? 

  • 8
    What is your end goal? What do you hope to gain by making the code object-oriented, other than being able to call it object-oriented? – Robert Harvey Nov 18 '14 at 21:44
  • I agree with Robert Harvey: What makes you think that converting from procedural to object-oriented will improve your code? – Giorgio Nov 18 '14 at 22:07
  • 1
    @Lorenz:Back when OO was becoming "The thing", most developers simply did structured designs but used classes. Most developers also had those same projects turn into utter failures. OO and structured designs are orthogonal to each other. Thus, they tend to not mix or play nicely together. (e.g. structured design passes data around with every expectation of having that data acted upon, OO hides data). Not much room for compromise there. If you aren't intending to do a proper OO design then don't bother doing what you are trying to do. Your listed issues are just the tip of the iceberg. – Dunk Nov 19 '14 at 18:09
  • @Dunk Thanks for the clear statement that there is no middle ground. That means that there is no way to gradually move towards OO. Rather I stick to my coding style for this project. It means also that I need extended training in order to start maybe a next project in OO. – Lorenz Meyer Nov 19 '14 at 19:31
  • 1
    @Lorenz:I highly recommend that. If you were experienced in both styles and there was a compelling reason to make the transition then you could probably make it work somewhat but even there it would be a risk. Probably the most "right" way to make that kind of transition would be to do an OO design of the system and import functionality from the original code across your OO classes rather than try to turn your modules into classes. Structured design using classes tends to give you the worst of both worlds instead of the best. – Dunk Nov 19 '14 at 22:52
7

There is nothing so bad that it cannot be used as a bad example, at least. To me, your example is not even "formally object oriented", it is just as procedural as the original. The only noteable thing you changed is the namespace where the search function "lives".

A customer object should represent the data and some business logic of a customer (there is not even one attribut in your class, and the search method does not work on a customer object). A "search" function for customers could return a customer object, or a collection of customer objects (echoing some json string has nothing to do with that). Such a function is probably not a member function of a customer class (it could be placed there as a static function, or somewhere else, for example, in a CustomerFactory). And a reasonable customer search should avoid coupling to global attributes and methods (like $options, Db, or Auth::authenticate).

So if your goal is to introduce more "object oriented structure" into your program, you may be better off by doing a little bit more upfront design first. For example, start by designing a customer class first and think about how a search function must look like for delivering such objects.

  • There is a contradiction : since the search could yield several customers, it should return a collection of customer objects. As such search cannot be a method of the customer object. This means that there should coexist a customer object representing the row in the database and the real life person, and a CustomerController that allows to do stuff with a group of customers. – Lorenz Meyer Nov 19 '14 at 6:53
  • This rises another question : why is it better to have a customer data object rather than an associative array and a collection of methods that enforces its consistency with business rules ? Clearly, while everybody favors object oriented programming, it looks just like a huge overhead to me. – Lorenz Meyer Nov 19 '14 at 7:03
  • 2
    @LorenzMeyer: a "search" function is probably not well suited inside the customer object - that was exactly the point in my posting, not "a contradiction", please read my answer again. A "CustomerFactory" maybe a better place, indeed. An "associative array, bound together with a collection of methods for the business rules" is exactly how object orientation is implemented in some languages - to implement this again "manually" when the programming language has in-built OO support is typically more overhead than to use the OO features of the language directly. – Doc Brown Nov 19 '14 at 7:10
  • 1
    @LorenzMeyer: you are correct - when your primary goal is to write some small tools for dynamic data processing, the "classic OO approach" is often less efficient than a generic, dynamic approach. That's why dynamic languages like Perl, Python, Javascript or (ugh) PHP are so popular. However, if you are writing bigger programs, where the individual business logic of each object is more important, incorporating "classic OO" starts to pay off. – Doc Brown Nov 20 '14 at 13:03
  • 1
    @LorenzMeyer: nethertheless I think you are seeing things too "black-and-white". I wrote OO style programs for data processing in Perl several years ago. From that experience I can tell you, though there is a little bit additional overhead, you can still get a lot of benefits from the dynamic nature of that language and implement some parts very generically. – Doc Brown Nov 20 '14 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.