PHP Objects - Patterns and correct usage

Question

I'm just wondering if someone can help me understand how to make the best use of objects in PHP.

My understanding of a PHP object is that is should represent an entity, providing methods to get and alter the properties of that entity. For example an object entitled Post would hold all the properties of a single post, which could be accessed and modified as appropriate.

What causes me some confusion is that libraries like CodeIgniter don't use objects in this manor. They treat classes more like wrappers for a group of functions. So a 'Posts' class in CodeIgniter would not hold properties of one post, it would provide functions for fetching, editing and deleting posts.

So what happens if I want to get every post out of a database and put it into a Post object? My understanding of it is I would in fact need two classes 'Posts' and 'Post', one that defines the Post object and one that handles fetching the Posts from the database and putting them into Post objects.

Do these two types of class have a name ('Proper' objects / Collections of functions)? And is it common to have two classes working together like this or have I completely misunderstood how to use objects?

Instead of having a Post object would it make more sense to have a method in my Posts class called getSinglePost($id) that just returned an array?

Hopefully that question makes sense, looking forwards to getting some feedback.

@MadaraUchiha agreed. that's why I deleted it as a suggested possible dupe. cant revoke the cv though. — Gordon, Oct 07 '12 at 12:19

score 5 · Accepted Answer · edited May 23 '17 at 11:59

For an introduction, see What is a class in PHP?

For the answer, I'll just address your questions in particular. Search for the terms in bold to learn more about their meaning.

My understanding of a PHP object is that is should represent an entity, providing methods to get and alter the properties of that entity.

Entities are just one possible use for objects. But there is also Value Objects, Service Objects, Data Access Objects, etc. - when you go the OO route, everything will be an object with a certain responsibility.

What causes me some confusion is that libraries like CodeIgniter don't use objects in this manor.

Yes, Code Igniter is not really embracing OOP. They are using much more of a class-based-programming approach, which is more like programming procedural with classes and few sprinkles of OOP.

They treat classes more like wrappers for a group of functions. So a 'Posts' class in CodeIgniter would not hold properties of one post, it would provide functions for fetching, editing and deleting posts.

That is fine though. A posts class could be Repository, e.g. an in-memory collection of Post Entities that has the added responsibility to retrieve and persist those in the background. I'd be cautious with Design Patterns and Code Igniter though since they are known to use their own interpretation of patterns (for instance their Active Record is more like a Query Object).

So what happens if I want to get every post out of a database and put it into a Post object?

Lots of options here. A common approach would be to use a Data Mapper, but you could also use PDO and fetch the data rows directly into Post objects, etc.

My understanding of it is I would in fact need two classes 'Posts' and 'Post', one that defines the Post object and one that handles fetching the Posts from the database and putting them into Post objects.

That would be the aforementioned Repository or Data Mapper approach. You usually combine these with a Table Data Gateway. However, an alternative could also be to not have a Posts class and use an Active Record pattern, which represents a row in the database as an object with business and persistence logic attached to it.

Do these two types of class have a name ('Proper' objects / Collections of functions)? And is it common to have two classes working together like this or have I completely misunderstood how to use objects?

Yes, they work together. OOP is all about objects collaborating.

Instead of having a Post object would it make more sense to have a method in my Posts class called getSinglePost($id) that just returned an array?

That would be a Table Data Gateway returning Record Sets. It's fine when you don't have lots of business logic and can spare the Domain Model, like in CRUD applications

Peter Ilfrich · Answer 2 · 2012-10-07T12:09:57.540

Your understanding of an object is correct. A post is a single object of a class Post. But of course you need a function, that retrieves posts from a database or collects them from somewhere else. Therefore you have so called Factory classes. That's what can cause some confusion.

Factories can be singletons, which normally means that you have one instance of this class. But you don't need to instantiate a factory at all (and instead use static functions to access the functionality):

$posts = PostFactory::getPosts();

And then the function:

static function getPosts() {
  $list = array();
  $sql = "select ID from posts order by datetime desc"; // example, ID is the primary key
  // run your sql query and iterate over the retrieved IDs as $id
  {
  ...
    $post = new Post($id);
    array_push($list, $post);
  }
  return $list;
}

Inside this factory you have a collection of "access"-functions, which do not fit elsewhere, like object creation (databasewise) and object retrieval. For the second part (retrieval) it is only necessary to put the function into a factory, if there is no "parent" object (in terms of a relation). So you could have an entity of class Blog, you instantiate the blog and then retrieve the posts of the blog via the blog instance and don't need a separate factory.

The naming is only there to help you understand. I wouldn't recommend to call a class Post and it's factory Posts since they can easily be mixed up and the code is harder to read (you need to pay attention to details). I usually have the word "factory" mixed in the class name, so I know that it is actually a factory class and others see it too.

Furthermore you can also have Helper classes, which don't really relate to any specific entity class. So you could have a PostHelper singleton, which could hold functionality, which doesn't fit neither in the object class nor in the factory. Although I can't think of any useful function for a Post object. An example would be some software, which calculates stuff and you have a Helper, which performs the actual calculation using different types of objects.

Correct. I changed the explanation a bit. I usually access factory functions in a static way, because it is very convenient. — Peter Ilfrich, Oct 07 '12 at 12:03
well, just because you access them statically doesnt warrant the use of a Singleton though. You should use a Singleton only if kittens die when you instantiate a second instance and when you cannot inject the object and need the global access. A Factory doesnt qualify for that imo. Also see my answer http://stackoverflow.com/questions/4595964/who-needs-singletons/4596323#4596323 — Gordon, Oct 07 '12 at 12:15
Hehe, nice graph in your answer. And I agree! Especially since PHP is not very strict in terms of OOP (and basically just uses Perl arrays to manage the objects). I just wanted to mention the word singleton (for further reading) to illustrate the usage of a factory, since both concepts (static factories and singletons) are different from the classic object - ofc thinking more in terms of real OOP languages, where singletons actually make sense. — Peter Ilfrich, Oct 07 '12 at 12:40

score 0 · Answer 3 · answered Oct 07 '12 at 11:55

Class should ideally has the same interpretation as anywhere else in PHP as well. Class starts with abstraction, refining away what you don't need. So it's entirely up to you to define the class the way you want it. Codeigniter does have a strange way of initiating and accessing objects. Mainly because they are loaded once and used afterwards, prevents it from having functionality around data. There are ways around it and normal handling of classes still possible. I usually use a auto loader and use normal classes. "So what happens if I want to get every post out of a database and put it into a Post object? My understanding of it is I would in fact need two classes 'Posts' and 'Post'," You are essentially referring to a MODEL to access the data ("posts") and an Entity to represent the "post". So you would load the model once and use it to load up as many entities as you would like.

$this->load->model("posts");
$this->posts->get_all(); // <- This can then initiate set of objects of type "Post" and return. Or even standard classes straight out from DB.

PHP Objects - Patterns and correct usage

3 Answers3