I use classes in almost every aspect - it becomes more like a plugin. Here's how I would generally use it:
<?php
class_base.php:
//class c_base
{
function c_base()
{
//constructor
}
function db_fetch_table()
{
// your db functions to fetch whole table
// or you can wrap adodb here or other db
// abstraction tools here
}
// Other db function goes here
}
?>
//-------------
//class_businessrules.php
<?php
require_once "class_base.php";
class c_businessrules extends c_base
{
function c_businessrules()
{
c_base::c_base();
}
function getUsername($strUserID)
{
$strSQL = "SELECT username FROM usertable WHERE userid='{$strUserID}'";
$arResult = $this->db_fetch_table("usertable", $strSQL);
return (!empty($arResult[0]["username"])? $arResult[0]["username"] : FALSE);
}
}
?>
//--------------
///plugin_usersalary.php
<?php
class c_user
{
function c_user($oFactory)
{
$this->oFactory =& $oFactory;
}
function getUsername($strUserID)
{
$strResult = "Unable to obtain salary information";
$strUsername = $this->oFactory->getUsername($strUserID);
if (($dSalary = $this->getSalary($strUserID)) != FALSE)
{
$strResult = "Hello ". $strUsername. " your salary thus far is ". $this->getSalary($strUserID);
}
return ($strResult);
}
function getSalary($strUserID)
{
$strResult = FALSE;
$strSQL = "SELECT * FROM salarytable WHERE userid='{$strUserID}' AND salaryslip='{$strSalaryslip}'";
$arResult = $this->oFactory->db_fetch_table("salarytable", $strSQL);
if (!empty($arResult[0]["amount"]))
{
$strResult = $arResult[0]["amount"];
}
return $strResult;
}
function getRegion($strUserID)
{
$strResult = FALSE;
$strSQL = "SELECT regionid FROM regionmembers WHERE userid='{$strUserID}'";
$arResult = $this->oFactory->db_fetch_table("regionmembers", $strSQL);
if (!empty($arResult[0]["regionid"]))
{
$strResult = $arResult[0]["regionid"];
}
return $strResult;
}
}
?>
//---------------
// plugin_sales.php
<?php
class c_sales
{
function c_sales($oFactory)
{
$this->oFactory =& $oFactory;
}
function getsalesbyregion($strRegionID)
{
$strSQL = "SELECT sum(salesamt) FROM salessummary WHERE regionid='{$strRegionID}' GROUP BY regionid";
$arResult = $this->db_fetch_table("salessummary", $strSQL);
return (!empty($arResult[0]["salesamt"])? $arResult[0]["salesamt"] : FALSE);
}
}
?>
//---------------
//getallsalaries.php <--- not a class regular php file
<?php
if (!empty($_GET["userid"]))
{
require_once "class_businessrules.php";
require_once "plugin_user.php";
require_once "plugin_sales.php";
$obj = new c_businessrules();
$oUser = new c_user(&$obj);
$oSales = new c_sales(&$obj);
$strRegionID = $oUser->getRegion($_GET["userid"]);
$strUsername = $oUser->getUsername($_GET["userid"]);
$dSalary = $oUser->getSalary($_GET["userid"]);
$dRegionSales = $oSales->getsalesbyregion($strRegionID);
echo "{$strUserID}, paid \${$dSalary} monthly works in ".
"a team that produces \${$dRegionSales} a month.";
}
?>
This way you have your core classes separated from your core business logic and you can have atomic business units as plugins.
There are easier ways to do it (e.g. your atomic units actually extends the core business logic class but this in turns bloat the atomic units up if you want to combine more than one atomic unit together (e.g. getting the user salary data and comparing the users sales data - which can be a separate business unit).
In PHP, this is obviously not the fastes way to do things - as all these files are scripts that have to be interpreted and having to include many files is always going to cost you some time overhead.
I don't think classes could be compared with associative arrays (although PHP's object functionality is quite retarded for the moment) as you can apply methods and functions (which in turn provide appropriate behaviours to each object). If you can visualize your project into business objects, and foresee that your project will be quite substantial, building classes to contain your logic may be the best step forward.
I suppose if you are familiar with OOP in Java and C++ you would have no problem handling the very basic OOP structures of PHP.
