You don't need to pass any methods, you need to have the objects available at any time. You will need to think in OOP and simplify the code initially. So get rid of the OOP details in PHP5 and concentrate in the structure.
so create an interface to handle common objects
// Objects Interface Begin
class common_stuff {
static $_objects = array();
static function create($name) {
if( !class_exists($name) ) {
die('invalid class: ' . $name);
}
if( !isset(common_stuff::$_objects[$name]) ) {
common_stuff::$_objects[$name] = new $name;
}
}
static function &get($name) {
common_stuff::create($name);
return common_stuff::$_objects[$name];
}
static function get_array() {
$result_array = array();
$args = func_get_args();
foreach( $args as $class ) {
$result_array[$class] =& common_stuff::get($class);
}
return $result_array;
}
}
// Objects Interface End
Now create the common helpers lets say for database and sessions
class sql_handlers {
function query($string) {
$result_array = array('empty sql_handlers array');
// sql query or $this->error()
// .......
return $result_array;
}
function num_rows($resource) {
$result = 0;
// num_rows
// .......
return $result;
}
function error() {
$qerr = mysql_error();
if( !empty($qerr) ) {
// An error occurred
echo $qerr;
}
return !empty($qerr);
}
}
class session_handlers {
var $_data;
function session_handlers() {
$this->_data = array('session default data');
}
function start() {
// Start session
return true;
}
function &get() {
return $this->_data;
}
}
And finally create the application section to utilize the common helpers. The application doesn't need to know the interface details but it needs to have a way to get all objects it needs at any time.
class foo {
function some_function() {
// Get multiple objects
extract(common_stuff::get_array('sql_handlers', 'session_handlers'));
// Utilize the objects and do something
$string = 'select from table........';
$result_array = $sql_handlers->query($string);
print_r($result_array);
$session_handlers->start($string);
$result_array =& $session_handlers->get();
print_r($result_array);
// Get a single object - complicated use the get_array instead
$cSQL =& common_stuff::get('sql_handlers');
$result_array = $cSQL->query($string);
$rows = $cSQL->num_rows($string);
print_r($result_array);
echo $rows;
}
}
echo '<pre>';
$cfoo = new foo;
$cfoo->some_function();
echo '</pre>';
So the interface section handles the objects then the application code utilizes it.
In this example the sql class is instantiated the moment another piece of code needs it and only keeps a single object in the objects array. If an objects is already present is returned. If you wanted to sql error handling you do it inside the sql_handlers class. It's the one that performs the queries.
The extract method makes a series of objects immediately available to any function that needs them, therefore the application needs to know the methods of the classes (ie: it needs to know there is a method called query in order to use it). An alternative call is also shown, if you wanted say a single object reference. Object instantiation is dynamic, totally transparent to the application and to the helper classes.
Because the particular helper classes typically require a single instance in a script, with this example the interface is static.
So in OOP break down the requirements establish a logic for the primitive objects and write the application to utilize them.
In your example if you wanted to print the mysql error you do that in the sql class and/or have other functions from other classes to print it via an interface because they can call the helper methods having the objects available at any time. So this class that you have now,
class OtherClass{
function bar() {
// get the sql object
extract(common_stuff::get_array('sql_handlers'));
// do queries, print the error get result
// query...... $sql_handlers->query('select....')
if( $sql_handlers->error() ){
die('Error');
}
}
}
doesn't need to get any arguments, it retrieves the sql object and invokes an sql method to print the error if it exists. And also it doesn't use directly the mysql methods but it provides the helper making the code more portable to be used with other database types because and you don't need to change the application details when you port it. Usually you have the sql methods print the error as it is typically a critical/syntax one if the query fails.
