Is this the correct approach to an OOP design structure in php?

Question

I'm converting a procedural based site to an OOP design to allow more easily manageable code in the future and so far have created the following structure:

/classes
/templates
index.php

With these classes:

ConnectDB
Games
System
User
User   -Moderator
User   -Administrator

In the index.php file I have code that detects if any $_GET values are posted to determine on which page content to build (it's early so there's only one example and no default):

function __autoload($className) {
    require "classes/".strtolower($className).".class.php";
}

$db = new Connect;
$db->connect();

$user = new User();

if(isset($_GET['gameId']))
{       
    System::buildGame($gameId);
}

This then runs the BuildGame function in the system class which looks like the following and then uses gets in the Game Class to return values, such as $game->getTitle() in the template file template/play.php:

function buildGame($gameId){

    $game = new Game($gameId);
    $game->setRatio(900, 600);

    require 'templates/play.php';
}

I also have .htaccess so that actual game page url works instead of passing the parameters to index.php

Are there any major errors of how I'm setting this up or do I have the general idea of OOP correct?

Answer 1

As far as OOP goes, there's never really a right or wrong way. There's always more roads that lead to Rome.

However, there are some caveats to avoid. Your System class looks like a God object, which is a so-called 'anti-pattern'. Best to avoid those. Also, I suspect that you're using $db and $user as global variables -- those are not encouraged in OOP. It's best to pass the DB handle to the classes that need it, either upon construction or for instance with a setDatabase() method (this is called Dependency Injection, and makes your classes easier to oversee, maintain and debug).

Finally, an autoloader might make your job as a programmer a little bit easier. This will take the job of doing the require calls out of your hands -- and also forces you to structure your code in a logical manner :)

Answer 2

You might take a look at an MVC... you're already splitting your templates and classes for the View and Model/Controller) components, but look at splitting your classes into models and controllers

Answer 3

You might want to employ an autoloader to load all your classes for you.

You could see how I tried to do it in my (m)vc.

Answer 4

So this is probably too old for me to help the OP in any way, and I'm not an expert. However, I'd like to support @Rijk & their accepted answer with a little bit more structure & a few reference books (as outdated as books are starting to be these are, in my opinion, good ones).

So modern OOP, is mostly centered around the SOLID acronym.
Single responsibility, Open-closed principle, Liskov substitution, Interface segregation & Dependency inversion (almost an exact quote from the link).

They are defined better in the linked article than I could do them justice but here are the overall concepts that most of this fits under (but in , as much as I could pull off, less technical sounding terms):

• Do one thing & do it well
• Attempt to keep programming objects smaller & simpler rather than larger & complex (you can still build complex systems with less complex parts and it makes it much easier to understand each part of the complex system... and avoid and fix bugs)
• Make your classes built so they follow the above AND so you can add functionality to them WITHOUT changing the code that makes up the class (when you change working code you are always risking the creation of bugs)
• Design to concepts and ideas before you design your code
• When a concept is implemented in code make an interface for it and anything that fits that concept should support the same interface & that interface to the concept should NOT change
• Based on the above, make more interfaces & more concepts behind them if the interfaces you have created are not sufficient (rather than make the interface you have defined more complex)
• Also avoid complex inheritance chains and instead utilize object composition

It's likely I missed a number of important points and/or failed to convey the proper ideas in what I said so, on to the reference books. These books were recommended to me by multiple programmers with more experience, expertise, & knowledge than I have. So with that recommendation:

• Headfirst Design Patterns
• Code Complete

The second is an excellent book on how to write good software & pull off software projects & plan & design & ... just lots of other valuable stuff.
The first is more accessible in general and is a really great resource for learning, well ... probably all of the principles covered in the SOLID acronym.

The overarching concept seems to be best described as:
writing relatively error free software through writing smaller pieces of code that are proven to work, that also don't need to be changed when you add more functionality.

Hope that's helpful to someone.