Page 1 of 1

In search of real-world PHP OOP examples/tutorials

Posted: Tue Nov 09, 2010 3:34 pm
by Celauran
I've been writing PHP on and off for a few years, but always procedural code. I'd like to learn to write OO code but, for one reason or another, it's just not clicking. I understand the concept of OO; I understand objects, inheritance, encapsulation, polymorphism, etc from a Java course I took a while back, so that isn't the stumbling block. I think it has something to do with the interaction between PHP and SQL.

For example, I figured I'd start out with something pretty simple like a blog. So I start thinking about a BlogPost object. It would ostensibly have, say, title, body, author, and time as properties. Add in some accessors and mutators for each of those properties. So far, simple enough.

I start thinking more about the implementation, about either submitting or retrieving a post (or multiple posts) and that's where the wheels start to come off. I use a form to submit a new blog post; do I really create a new BlogPost object, use the $_POST array to give values to its properties, then stick it in the database? Seems like an extra step for nothing.

So let's leave creating a post aside for now and think about retrieving them. Say I want to display the last 10 blog posts; I've got the mysqli object to submit the query, get a result object back, so where does my BlogPost object fit in with this? Why would I need it?

I'm sure that once I can connect these two, everything else will fall into place. All I've been able to find by way of tutorials, however, are things that attempt to explain what objects are and using real world objects (bikes, cars, elephants) as examples. I already understand that. I know I learn better by seeing and doing, so I've tried downloading existing CMSes and the like, but that ended up being a little too complex and didn't really help my understanding either. Ditto for frameworks; I'm sure I could learn to use Zend/CI/Kohana, but that isn't really the goal. Not yet, at least. I'd like to understand what's going on under the hood first.

Does anyone know of any well-written, practical, real-world PHP5 tutorials that might help here?

Thanks for your time.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Tue Nov 09, 2010 8:24 pm
by s992
Hey, sounds like you're in (close to) the same boat as me. Check out this tutorial on creating an MVC framework that I posted in the Theory and Design forums:

viewtopic.php?f=19&t=124659

If you want to bounce ideas, questions, etc, off of me - feel free to send me a PM here. It'd be nice to work with someone so similar to me who's in the same stages of learning PHP that I am.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Wed Nov 10, 2010 9:03 am
by Celauran
Thanks for the suggestion, I'll be sure to take a look.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Fri Nov 12, 2010 11:55 am
by Celauran
Well, I finally had time to go through those tutorials and, while they gave me some insight into how MVC works, I'm still at a bit of a loss for how to treat my blog example. Is my whole premise of creating a BlogPost object to represent an individual blog post wrong?

Re: In search of real-world PHP OOP examples/tutorials

Posted: Fri Nov 12, 2010 4:38 pm
by s992
This forum post, "when to use OOP", helped me to understand the benefits/detriments a little better - specifically, post #4.

Personally, I enjoy using OOP because it helps me keep everything organized and under control.

To answer your question more directly(and keep in mind that I am pretty new at OOP myself), I don't think there's anything wrong with your concept of the BlogPost object. Like you said in your original post, there's probably an additional step here or there - but you're rewarded with much cleaner and easier to maintain code.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Fri Nov 12, 2010 6:49 pm
by Christopher
Celauran wrote:I've been writing PHP on and off for a few years, but always procedural code. I'd like to learn to write OO code but, for one reason or another, it's just not clicking. I understand the concept of OO; I understand objects, inheritance, encapsulation, polymorphism, etc from a Java course I took a while back, so that isn't the stumbling block.
It sounds like you know the "how" of OOP, but not the "why." That is probably because the problems that OOP solves are not apparent to you.
Celauran wrote:I think it has something to do with the interaction between PHP and SQL.
This is the curious thing you said. I suspect that you do not understand about creating layers/tiers in your application.
Celauran wrote:For example, I figured I'd start out with something pretty simple like a blog. So I start thinking about a BlogPost object. It would ostensibly have, say, title, body, author, and time as properties. Add in some accessors and mutators for each of those properties. So far, simple enough.
I think you are forgetting that a BlogPost class would allow you to set its properties and then save it -- or to load an existing blog post.
Celauran wrote:I start thinking more about the implementation, about either submitting or retrieving a post (or multiple posts) and that's where the wheels start to come off. I use a form to submit a new blog post; do I really create a new BlogPost object, use the $_POST array to give values to its properties, then stick it in the database? Seems like an extra step for nothing.
Typically the values from POST would be encapsulated in a Request object. It would put the data, plus code to identify the HTTP method (POST/GET), and possibly filtering and validation. I may also provide conveniences like allowing you to provide default values.
Celauran wrote:So let's leave creating a post aside for now and think about retrieving them. Say I want to display the last 10 blog posts; I've got the mysqli object to submit the query, get a result object back, so where does my BlogPost object fit in with this? Why would I need it?
The mysqli object would be used within the BlogPost object. You should consider the BlogPost object to be in a lower layer than the rest of your application that get the Request and generates the output. It is independent and below that code. technically the mysqli object is in a layer below the BlogPost object (often called the Datasource layer). The point of this layering is that the BlogPost object stays independent so changes in one area of you app can have side-effects in another area.
Celauran wrote:Does anyone know of any well-written, practical, real-world PHP5 tutorials that might help here?
It is difficult to recommend books/tutorials because different people learn from different presentation styles. There are many tutorials on the web. Find some that are in a style that works for you. If you are not sure of the quality -- post the links here and people will check them out for you.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Fri Nov 12, 2010 8:31 pm
by Celauran
Christopher wrote:This is the curious thing you said. I suspect that you do not understand about creating layers/tiers in your application.
Are you referring to things like database abstraction layers, or have I completely missed the point?
Christopher wrote:I think you are forgetting that a BlogPost class would allow you to set its properties and then save it -- or to load an existing blog post.
Again, I'm not sure I'm following. How do you mean by 'set its properties' if not via mutator methods? As for loading an existing post, do you mean a method within the class that would fetch a single entry from the database, perhaps through a call to a method in the db abstraction layer?
Christopher wrote:Typically the values from POST would be encapsulated in a Request object. It would put the data, plus code to identify the HTTP method (POST/GET), and possibly filtering and validation. I may also provide conveniences like allowing you to provide default values.
OK, that makes sense. I guess I got so caught up with the BlogPost object that I developed some tunnel vision and wasn't considering the interaction between objects.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 3:06 am
by Christopher
Celauran wrote:Are you referring to things like database abstraction layers, or have I completely missed the point?
In a typical PHP application, DAL objects would typically be in the lowest layer, which I referred to as the Datasource Layer. Your BlogPost object (which I would probably name PostModel) would be in what I would call the Domain Layer. The rest of your app that used the BlogPost object would be in the Presentation Layer.
Celauran wrote:Again, I'm not sure I'm following. How do you mean by 'set its properties' if not via mutator methods? As for loading an existing post, do you mean a method within the class that would fetch a single entry from the database, perhaps through a call to a method in the db abstraction layer?
Objects are data + code, so when I say 'set its properties' I mean assign a value to a property by whatever means. That could be directly or via a setter, but preferable would be upon construction or by a method that you ask to do something like findPost() or findAllPosts().
Celauran wrote:OK, that makes sense. I guess I got so caught up with the BlogPost object that I developed some tunnel vision and wasn't considering the interaction between objects.
:)

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 3:41 am
by internet-solution
Celauran - I was in the same boat as yourself some months ago; I was aware of OOP / MVC, but not sure about the benefits. Then I started working on a project with CakePHP and looked at MVC design seriously. I was converted after reviewing this wiki example - may be it will help you.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 6:44 am
by Celauran
Christopher wrote:In a typical PHP application, DAL objects would typically be in the lowest layer, which I referred to as the Datasource Layer. Your BlogPost object (which I would probably name PostModel) would be in what I would call the Domain Layer. The rest of your app that used the BlogPost object would be in the Presentation Layer.
This is beginning to sound an awful lot like MVC. While I understand that you can in theory have an OO project that doesn't involve MVC, I'm beginning to wonder about the practicality of it. Consequently, I'm starting to question whether my idea to learn OO before learning a framework doesn't need to be reevaluated.
Christopher wrote:Objects are data + code, so when I say 'set its properties' I mean assign a value to a property by whatever means. That could be directly or via a setter, but preferable would be upon construction or by a method that you ask to do something like findPost() or findAllPosts().
I can see how this would work for a new object (pass the properties as arguments to the constructor), or for something like findPost() (allow null values in the constructor, then immediately populate with data from DB), but what about findAllPosts()? I've had this notion of one post = one object (EDIT: one post = one instance of an object would be more precise) which I'm beginning to suspect is incorrect, but I can't necessarily see the alternative. If you have a single object retrieve multiple posts from the database (which a method like findAllPosts() as well as your previous suggestion to create the mysqli object within the Post class seem to suggest), then how would something like return $this->propertyName remain meaningful?

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 4:17 pm
by Christopher
Celauran wrote:This is beginning to sound an awful lot like MVC. While I understand that you can in theory have an OO project that doesn't involve MVC, I'm beginning to wonder about the practicality of it. Consequently, I'm starting to question whether my idea to learn OO before learning a framework doesn't need to be reevaluated.
All applications, whether OO or procedural, should implement these basic layers. They keep dependencies correct and reduce side-effect. The fact that MVC also implements this same layering (going back to N-Tier) is only because it continues to be a best practice.

FYI - in order to take the next step and implement MVC (if you want to), you would need to additionally separate your Presentation layer into Request and Response halves. I would recommend learning the basic layering and then move to MVC.
Celauran wrote:I can see how this would work for a new object (pass the properties as arguments to the constructor), or for something like findPost() (allow null values in the constructor, then immediately populate with data from DB), but what about findAllPosts()? I've had this notion of one post = one object (EDIT: one post = one instance of an object would be more precise) which I'm beginning to suspect is incorrect, but I can't necessarily see the alternative. If you have a single object retrieve multiple posts from the database (which a method like findAllPosts() as well as your previous suggestion to create the mysqli object within the Post class seem to suggest), then how would something like return $this->propertyName remain meaningful?
The modern way to deal with an object that contains multiple items it for it to implement the Iterator interface. They you can just foreach($blogPostObj as $row).

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 4:39 pm
by Celauran
Christopher wrote:All applications, whether OO or procedural, should implement these basic layers. They keep dependencies correct and reduce side-effect. The fact that MVC also implements this same layering (going back to N-Tier) is only because it continues to be a best practice.

FYI - in order to take the next step and implement MVC (if you want to), you would need to additionally separate your Presentation layer into Request and Response halves. I would recommend learning the basic layering and then move to MVC.
Would I be correct in understanding that this layering is fundamentally the separation of logic (for lack of a better word) from presentation?
Christopher wrote:The modern way to deal with an object that contains multiple items it for it to implement the Iterator interface. They you can just foreach($blogPostObj as $row).
Is this meaningfully different than having a class method that implements the foreach construct and returns an array? Additionally, if you're returning an array to the presentation page/layer/whatever it's called, you'll have to iterate through that again. Would it not make sense to simply return the object and iterate through it, displaying the required elements immediately?

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 7:07 pm
by Christopher
Celauran wrote:Would I be correct in understanding that this layering is fundamentally the separation of logic (for lack of a better word) from presentation?
Yes ... exactly. And 'logic' is often called Business Logic, though I think calling it the Domain (or Domain Model) is a clearer and more modern name. There is nothing magic about N-Tier. It is one of the oldest and best ideas in design. Most often when code it a mess, it is because there is not clearer layering and dependencies.
Celauran wrote:Is this meaningfully different than having a class method that implements the foreach construct and returns an array? Additionally, if you're returning an array to the presentation page/layer/whatever it's called, you'll have to iterate through that again. Would it not make sense to simply return the object and iterate through it, displaying the required elements immediately?
Yes, just return an object and iterate through it. PHP arrays are certainly nice and have lots of support, but in many cases an object can better encapsulate the data and deal with error cases.

Re: In search of real-world PHP OOP examples/tutorials

Posted: Sat Nov 13, 2010 8:12 pm
by Celauran
Christopher wrote:Yes ... exactly. And 'logic' is often called Business Logic, though I think calling it the Domain (or Domain Model) is a clearer and more modern name. There is nothing magic about N-Tier. It is one of the oldest and best ideas in design. Most often when code it a mess, it is because there is not clearer layering and dependencies.
Well, I understand the rationale behind it, I just need more practice putting it into, well, practice. Thanks so much for your time, you've been a tremendous help.