I'm used to writing a lot of functions for reusable code, but now I'm shifting over to OOP. So this is what I'm used to:

function getUsers(){
  return selectQuery("SELECT * FROM `users` ORDER BY `last_name` ASC"); 
}

But now, should I create a completely separate class for the purpose of getting a list of users from the database? Something like:

class UsersList 
{
  public function __construct()
  {
    return selectQuery("SELECT * FROM `users` ORDER BY `last_name` ASC");
  }
}

    A class constructor cannot return anything, so you would have to create a separate method. However, if you are only going to have a class do one thing, I don't know that whatever you might gain in terms of organization would be worth the additional processing*. Normally a class is a collection of related data and functions (methods) to deal with processing needs for a particular problem domain.

    For the example in the original post, you would more likely have some sort of user class that might have several methods for dealing with user data, including one for getting a list of users.

    • I suppose you could make it a static method, then you would not have to create an object: 
      class UsersList
{
   public static getList()
   {
      return selectQuery("SELECT * FROM `users` ORDER BY `last_name` ASC");
   }
}
// usage:
$list = UsersList::getList();
      But, what does that gain over just defining and using a stand-alone function?

      The class will probably also allow you to order by certain fields, exclude users by a certain criteria, etc., so it should end up doing more than one thing. I guess I'm just trying to figure out a good balance between OOP and procedural and how it relates to OOP.

        They're different perspectives. Object-oriented programming focuses on what the entities you're working with are and what they do; procedural programming focuses on the steps they follow in order to do them. In short, one addresses the objects in your problem domain, the other addresses procedures.

          So there's really no overall better solution, is what I think I'm learning, correct? However, there are situations where one might be better suited than the other.

            In part the answer will depend on the size and scope of the project. Generally, the bigger the project, the more the organization and loose-coupling that a good OOP approach imposes adds to the manageability of the project. But even with a large, OOP project, you can still use pieces of procedural code/functions where objects may not necessarily be required.

            Neither technique is necessarily "better", but my experience is that most developers who start working with OOP come to prefer it as their general MO over procedural development, once they have that "Eureka moment" when it all starts to make sense in their brain. (For me that started to happen about halfway through Matt Zandstra's book PHP Objects, Patterns, and Practice.)

              Not sure, but can be also something like,

              class User
{
   public static getAll()
   {
      return selectQuery("SELECT * FROM `users` ORDER BY `last_name` ASC");
   }
}
// usage:
$list = User::getAll();

                Thanks, NogDog, I really appreciate it. I just pre-ordered the third edition which comes out May 31. I own and have read David Powers' PHP Object-Oriented Solutions, which is pretty good, as well as various other ActionScript 3.0 books and OOP design articles, but am still waiting for that "Eureka moment", as you say.

                  Write a Reply...