Page 1 of 4

Object Oriented Blog System Class Structure

Posted: Tue Jul 27, 2010 6:32 pm
by Jonah Bron
Hello, world!

I'm working on my blog, and I've completed the concept art for the home page.

I'm new to using object object oriented programming for medium-to-large scale projects. However, I am familiar with simply creating classes, inheritance, instance variables.

So my question is, how would a blog system's class set be structured? I've got some vague ideas that may or may not be relevant, like a class for blog entry objects, comment objects, etc.

Advice?

P.S., I don't really feel like sifting through the Wordpress code. :wink:

Re: Object Oriented Blog System Class Structure

Posted: Tue Jul 27, 2010 8:31 pm
by Benjamin
:arrow: Moved to PHP Theory and Design

Re: Object Oriented Blog System Class Structure

Posted: Wed Jul 28, 2010 2:49 am
by Christopher
Seems like you'd want to start with Authors, Posts and Comments classes. Those are the basics of a blog.

Re: Object Oriented Blog System Class Structure

Posted: Wed Aug 04, 2010 4:19 am
by josh
Do you want to talk about architecture? Like Model view controller & Active Record? Or about business entities like blogs, posts, comments, pages, feeds, etc..? Probably a bit of both eh? Those things like posts, pages, feeds, etc.. are "models" in the MVC (model view controller). Models are kind of like nouns, they are everything and anything that is a "thing".

The controller is like the lady on the automated phone system. Push 1 for me to do this, push 2 for me to do that. In other words it controls the application, it *is* all your "actions" and that stuff.

The view, well is everything the user views. That's where HTML markup and CSS goes.

Code: Select all

PostController
{
 function viewAction()
 {
  $this->view->post = $this->findPost(5); // A "controller" usually sends the "view" a "model"
 }
}

Code: Select all

// "view" figures out how to present that "model", like by echoing its title
echo $this->post->title()
So controller - use actions
Model - nouns, "business logic"
View - presentation logic.

Some people would put a database query in the view. Thats not MVC. You don't have database queries and HTML in the same files. Some people would put their database query in the controller. That is getting closer and is technically MVC. The ideal thing to do in my opinion is put the business logic in the model, this is an accepted practice. There's a saying "thin controller fat model". You'll notice my controller I shared was only 3 lines. This is just a made up example but for all you know getting the title of the post took me 500,000 lines of code. If that were the case MVC did us a great justice by hiding that from the view & controller.

Re: Object Oriented Blog System Class Structure

Posted: Thu Aug 05, 2010 5:03 pm
by BDKR
josh wrote:There's a saying "thin controller fat model". You'll notice my controller I shared was only 3 lines. This is just a made up example but for all you know getting the title of the post took me 500,000 lines of code. If that were the case MVC did us a great justice by hiding that from the view & controller.
I couldn't agree with this more. Too much business or domain logic in the controller really begins to look and smell like a god object (http://en.wikipedia.org/wiki/God_object).

Re: Object Oriented Blog System Class Structure

Posted: Tue Aug 17, 2010 11:27 am
by Jonah Bron
Sorry about the delay, I forgot about this post :mrgreen:

That's some good info. I've been reading up on the MVC framework. Could you give an abstract graphical representation of some example classes, there inheritance structure, and their type (model, view, or controller)?

Re: Object Oriented Blog System Class Structure

Posted: Tue Aug 17, 2010 6:14 pm
by josh
In the framework I use (Zend Framework) MVC works like this. Controllers & Models are classes. Views are just scripts. A view might just be some HTML and the only PHP will be very simple, usually just echo'ing a variable.

It actually all comes together like this

1) user requests a URL through their browser /user/view/1

2) A "route" (usually just a string or an array that "configures" the framework) is added to the "router" by the programmer (the router is a global object). The route is setup with a string usually, like this
:controller/:action/:id
like a pattern match for the above request URL in #1

3) the "Front controller" (your index.php basically) goes through all the routes and finds the one that matches the request. This is all done by the framework automatically. All you actually do is setup the route and start coding. So it would load the User controller which is a class called UserController. It would call the view action since that's what was in the request URL. So the "front controller" looks at the request, the routes, and finds the "controller" (called UserController) and calls the viewAction() method

4) This viewAction() method internally would find the user:

Code: Select all

function viewAction() {
 $user = $this->findUser();
 ....
.. and then it assigns it to the "view object" (which is different than the view script) ...

Code: Select all

$this->view->user = $user;
The framework uses the name of the controller & action from the request to find the view script (user/views/view.phtml) so (:controller:/views/:action:.phtml).. something like that. It does it for me based on the name of the function & class of the controller & action.

5) Execution in the controller has now been passed off to the "view script". THis is what programmers talk about when they refer to a "stack". Each time execution is passed from one file to another, like an include()

Code: Select all

<div class="hello world">Hello <?=$this->user->name()?></div>




So to recap. A request basically makes the controller execute, which in turn grabs a model and "pushes" it to the view.

I have described one type of MVC. "model push".
Here's the guy I learned from, he posts here and works on the Zend Framework: http://blog.astrumfutura.com/archives/3 ... nning.html


To take it to the next level you could have different views for any single given action. So you could let someone view something in plain text, or a variety of different HTML layouts. Like when you are shopping and they have "grid view", "list view", etc... all for the same page, you wonder how they do it? MVC. Heck a "view" could be just a program that beeps the output to the user in morse code.

Re: Object Oriented Blog System Class Structure

Posted: Tue Aug 17, 2010 9:13 pm
by Jonah Bron
Thanks josh. That clarifies things a bit. This...
josh wrote:A request basically makes the controller execute, which in turn grabs a model and "pushes" it to the view.
...was what really clinched it. I'll do some more reading and start coding.

Cheers.

Re: Object Oriented Blog System Class Structure

Posted: Tue Aug 17, 2010 9:35 pm
by alex.barylski
For what it's worth, when you inject/push the model into the view, the view becomes directly dependent on that model object and without additional constraints, you make the model API available to the view and that "can" promote a bad practice, such as updating models in the view. You can of course prevent this using a few techniques but now it's just extra code, and IMO over-engineering.

The alternative to the classical MVC depenency, you have passive view, which works well if your views are simple:

http://martinfowler.com/eaaDev/PassiveScreen.html

Now the view remains entirely decoupled from the model, as the controller would query the model and pass the view nothing more than a native PHP array of results which are easily rendered. It's debatable whether this decoupling will make your templates more reusable, personally I find my API changes a PITA so to save some of my users a headache in the event I change the API I usually pass in an array, so client templates (which are commonly overloaded/replaced) do not need updating if and when something changes.

As with anything in software, there are trade-offs with everything frequently dictated by user/developer requirements.

Cheers,
Alex

Re: Object Oriented Blog System Class Structure

Posted: Thu Aug 19, 2010 2:58 am
by josh
Basically what PCSpectra said is instead of passing a $user object from the controller and calling $user->getName() in the view - instead of that you could call $user->getName() from the controller and pass just that string :-) Just a matter of preference. I prefer passing the whole object.

I agree a view should not update information. It should not call any "setter" methods. Only "getters". Really its not so much of a "view" as it is a "presentation", and as such you should be presenting content not recording content. Recording content (creating new records) usually happens in the controller or model.

Re: Object Oriented Blog System Class Structure

Posted: Thu Aug 19, 2010 8:34 am
by alex.barylski
Just a matter of preference. I prefer passing the whole object.
For me, it's not so much preference, as it is requirements. When the application is frequently used by designers, they usually have little interest in working with an API, they just want native arrays. Also, keeping in mind that some template engines may or may not support method queries, in which case a native array might be the only option. Not to mention, templates are customied more than most parts of a system, so a simple API change:

selectAll() changed to selectAllProducts()

Could cause hundreds or thousands of templates to stop working <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> off a lot of people over a trivial moot change.

That being said, there are times when a view/model coupling is prefered, such as the case for a Pager control. Otherwise you find yourself passing the pager all the page index, offsets, etc in each listing that uses a pager, which gets redundant.

Cheers,
Alex

Re: Object Oriented Blog System Class Structure

Posted: Fri Aug 20, 2010 3:28 pm
by josh
PCSpectra wrote: selectAll() changed to selectAllProducts()

Could cause hundreds or thousands of templates to stop working <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> off a lot of people over a trivial moot change.
And not making that change has its own cons (ex why rename it if you don't want it renamed). When I rename something its all or nothing. Thats how systems get hard to understand when they aren't even self consistent anymore.

Re: Object Oriented Blog System Class Structure

Posted: Fri Aug 20, 2010 5:22 pm
by Christopher
Agreed. Global renaming is the easiest refactoring. The problem is when a "designers" wrap selectAll() in code to get the featured products, sale products, etc. -- and then the schema changes. Now you have to find the breakage. That instead of requiring the creation of selectFeaturedProducts() or selectSaleProducts(). Better to bite the bullet or entropy will eventually make even more work for you.

Re: Object Oriented Blog System Class Structure

Posted: Sat Aug 21, 2010 1:15 am
by josh
Is there possibly a mantra for this? Instead of "law of Demeter" would it be called "law of indirection"? :?:

Re: Object Oriented Blog System Class Structure

Posted: Mon Aug 23, 2010 6:18 pm
by Christopher
I think there are two things at work: you Law of Indirection that says to create the cleanest, simplest interface (even if it is more work) and also a more general Law of Conscience that says to do the right thing (even if it is more work) ;)