A more complex OOP website

Now that we've got our very basic site down, I want to briefly discuss how you could extend it to be more interesting. The key here is to take the skeleton framework we have currently and extend it with site-specific classes, so that rather than using generic classes like cpage we can use a specific class like cfrontpage or ctutorialpage.

So, as there will be specific pages to handle each type of page on the site, we no longer really need cpage to be instantiatable. We still need the class, because we want to be able to use type hints to check that we have a cpage being used, but we no longer need to create a page without a specific type - people should be using subclasses of the cpage class. Therefore, the first step is to mark cpage as abstract: don't let people create cpage classes any more.

Then you need to decide what types of page there will be: tutorials? Messageboards? Reviews? News? Some may be have the same style, and so can be clumped together into a single class. Once you have a list of the classes that are unique, you can create files for each of them and define them. Make sure they extend from cpage, otherwise the type hints will fail. Then you just need to override the call to render() with page-specific rendering - perhaps some pages have a left-hand menu, others have extra footers or a special picture in the header.

If you want to go for really advanced pages, you can even subclass the subclasses - perhaps you have a PHP tutorial series that should have a purple header bar but otherwise have the same as the main tutorials class, so create a cpagetutorialphp class. Don't go too far, though!

One thing you should definitely consider is site-wide database and session management using your csite class. If you always want to have a database connection and session data to hand with your site, you have two options: take away the purity of the csite class and have it always open a connection and start a session, or simply subclass the csite class to have a class specifically for the current site, eg: csitehudzillaorg for hudzilla.org. This would enable you to remove the initialise_site() function, because you can hard-code standard elements directly into the csite subclass.

Another thing to keep in mind is that you should allow your objects to be used in more ways than you were planning. By that I mean that it's all very well if you create a beautiful object-oriented messageboard, but wouldn't it be even better if you could re-use parts of that code elsewhere - for example, be able to say:

$mb = new messageboard("chat");
$mb->getNumMessages();

So while your messageboard class is capable of doing all sorts of clever threading and emoticons, it also has a neat little accessor function that grabs the number of messages posted on there so you can print the count on your front page without having to write the necessary SQL queries. Remember, this encapsulation is what makes OOP great: if you had to embed the SQL to grab the number of messages directly into your index page, then it will simply break if the table schema for the messageboard changes. Similarly, if you update the code to check for new messages, the messateboard and the index page get the improvements automatically. OOP, when used correctly, can really make adding features to your site a cinch.

Copyright ©2015 Paul Hudson. Follow me: @twostraws.