OOP question: new method vs. child

[nloding]

First, I'm new to OOP (I'm very used to procedural, so this is very much a learning experience).  This is my first attempt at OOP ever.  I'm testing with a database manager class, below:

 

class DbManager() {
//Public variables as normal (ie, $variable)
//Protected variables with _ (ie, $_variable)
//Private variables with __ (ie, $__variable)

protected $_mysqli;

// Create the database connection
function __construct() {	
	$this->_mysqli = new mysqli(DB_SERVER, DB_USERNAME, DB_PASSWORD, DB_DATABASE);

	//If there's an error ...
	if(mysqli_connect_errno) {
		echo "<p>Error: Could not connect to the database: ".$this->_mysqli->error."</p>";
		exit;
	}
}

// Run a simple query and return the result
public function DbQuery($query) {
	$result = $this->_mysqli->query($query);

	if(!$result) {
		echo "<p>Query failed: ".$this->_mysqli->error"</p>";
		exit;
	}

	return $result;
}

// Let's close the database connection
public function DbClose() {
	$this->_mysqli->close();
}
}

 

Now provided that looks good ... say I want to add a very specific query function that spits out the code into an HTML table ... in other words, the query is performed and the method runs a while loop using $mysqli->fetch_assoc() and plugs the data into a table ...

 

Would it be best to create a method within this class, or create a child??

 

I still don't understand the benefit of having a child class vs. adding the method to the original class.

[Jenk]

Encapsulation is the key for OO.

 

Objects should encapsulate a behaviour, and that behaviour alone.

 

In your post (immediately after the code,) I can see patterns for 4 or maybe 5 objects, I shall c+p with notations for where these objects are:

 

Now provided that looks good ... say I want to add a very specific (1. query function) that spits out the code into an (2. HTML) (3. table) ... in other words, the query is performed and the method runs a (4. while loop) using (5. $mysqli->fetch_assoc()) and plugs the data into a table ...

1. Data Mapper - The object responsible for fetching relevant data from your Data Source.

2. HTML Generator

3. Table Generator

4. Iterator

5. Data Source (MySQLi object)

[nloding]

OK, I get that.  I think ... the analogy I was always taught was to think of the class as a car, and what functions does a car need to run?  Gas tank, steering wheel, etc.  Instead, if I get what you're saying, you create the engine of the car inside the parent class, then the gear shifting would be a child class, as would the windshield wipers, and the 4-wheel drive ...

 

Alright, so assuming I got that part right, how does a child class function work?  Continuing with my car analogy ...

 

class Car { public function StartCar() { do something}}
class FourWheel extends Car { public function SpinAllFour() { do something }}
class Wipers extends Car { public function CleanWindows() { do something }}

 

Now what happens if I do this?

 

$fordTaurus = new Car; // this can only call StartCar() ...
$fordTaurus->StartCar;

$mercuryVillager = new Wipers
$mercuryVillager->StartCar; // can I do this?
$mercuryVillager->CleanWindows; // I know I can do this ...

 

Is that how a child works?

 

I'm gonna go get a book on this tomorrow regardless!

[Jenk]

I'd go easy on the extenstions.

 

I personally dislike the way terminology has adapted the whole parent/child thing for classes and their extensions as it can confuse things. It's like giving someone a prosthetic limb and calling it their child limb.. just not right.

 

Anyway, back on topic:

 

Yes, a car would (could) be broken down to several object instead of one big one, that is also what I would do.

 

What I would do instead of extending car with engine, I'd use the engine object as a member object of car, something like (ignoring class definitions for now..):

 

<?php

$car = new Car;
$engine = new Engine;

$car->installEngine($engine); // assign $engine to car.

?>

 

This way, you can allow for modifications of your Car, providing the components (engine, wipers, seats, etc.) all have the same interface (the publically accessible methods and properties of the object)

 

So, let's have a look at the Car class:

<?php

class Car
{
    private $_engine;

    public function installEngine ($eng)
    {
        $this->_engine = $eng;
    }

    public function driveTo ($destination)
    {
        if (!$this->_engine->isRunning) $this->_engine->start(); // gentlemen, start your engines!

        /**
         * calculations for how to move the car to $destination goes here..
         * this could also use a $driver, if the car is a limosuine or bus or whatever..
         * the possibilites with OO are collosall...
         */
    }
}

?>

 

So we can see from there, that providing the the parameter passed to the method installEngine has a method start() and a property isRunning, the Car object does not need (nor care) what type of engine it has installed.

 

This is what OO is about, modularity.

 

[nloding]

It's a lot to wrap my head around, but I see what the use of OOP is, and I see how it becomes modular.  So I'll try to build on my mysqli wrapper and post some code later and see what people think.  Fun new thing to learn, but it's a little odd to look at things like that!