OK. It seems that this is a confusion for many programmers regarding OO techniques. OO programming is NOT about putting all your functions
inside class files.
This is so far from the case! By simply "wrapping" functions inside a class i.e. class databaseQueries { } does not give you any or little benefit
from using a standard include functions file approach and may even add time to developing your application.
OO programming is about identifying the different parts of your application and how they relate to each other. Each part "or object" is created as a class
or a set of classes that may inherit or use functionality from other objects. I will give some examples further down.
Switching from a procedural style approach to an OO approach in your applications is another misconception for many developers.
Whether you decide on an OO or procedural approach should be dependent on the type and scale of application being developed.
Also is the application going to grow with many new features being added or will it remain small with little modification?
If the application is small then a procedural approach is often the best, most cost effective and easy to implement. If the application is
intended to grow then a procedural approach may mean a less cost effective approach as it may take much longer to make modifications and additions
as appose to an OO designed application. Simply using an OO approach for the sake of it can also lead to issues withot proper design.
You firstly need to examine your previous applications and decide if they would have been better with an OO approach. Is there tons of if, else statements
in your functions and procedural code? Is there much code duplication in various files? How easy is it to add additional features to the application?
Lets take a couple of examples.
If I have an application that requires connections to more than 1 type of database lets say SQL and MYSQL. In the future this application may also need to
connect to more databases. This is the perfect case for an OO approach. If I did this procedurally I will probably end up with loads of if, else clauses
for each type of database. An OO approach may incorporate a Database super class and sub classes of MySQL and SQL. The type of object created or "instantiated"
in the code is dependent on the database connection string so:
$database = new database($connectionString);
$database->sendQuery(parameters);
The $database variable will contain either a MySQL or SQL object dependent on the value of $connectionString. New databases can be added by creating a
sub-class. There would be no need to modify any of the current code to deal with this unlike a procedural approach where functions and conditional
statements may need to be modified.
Another example may be a user system with different users having different levels of access. More types of users may need to be added for example admins,
accounts, sales, temps, etc. Adding new user types to a procedural system may be a nightmare if this is a common additional feature. In an OO approach you
may have a User super class that contains common details such as firstname, password, etc.. Then sub-classes of AdminUser, TempUser, SalesUser. The type
of object created may depend on the login details that the user supplied so:
$user = user::login($loginDetails);
$user->printSalesReport();
$user could be any type of user but this method would return false for TempUser meaning that they do not have access to the sales reports.
So in a nutshell if your applications require these sort of features and need to be extensible then an OO approach is the best. Good OO design is
not always easy to acheive and a knowledge of polymorphism, inheritence, interfaces, abstract classes, static methods and variables is required to create
the best design that fits your requirements.
On a final note for PHP development an OO approach is best implemented in PHP5. It is worth scrapping PHP4 and upgrading if not done already.