Judging by the contents of both of your classes there is absolutely no reason for you to make any use of the Classica class at all because you are unnecessarily spreading functional responsibility over several classes when you could have it all wrapped up inside a single class.
I see that the only reason why you are using the "parent" class is to connect to your database and do some initial queries. Unless you plan to implement some advanced design patterns later there is absolutely no reason why you could not do this inside the DatabaseQ constructor.
class DatabaseQ {
public $dbhost;
public $dbname;
public $dbuser;
public $dbpass;
function __construct(){
include('config.php');
$this->dbhost = $dbhost;
$this->dbname = $dbname;
$this->dbuser = $dbuser;
$this->dbpass = $dbpass;
$this->connectdb(); // This is a good place to initiate your DB connection
$this->doOtherInitStuff(); // Calling the rest of the init stuff.
}
/**
* This is the place where you do all of your init stuff.
* Note the private status! The environment doesn't need to have access to your DB initialization stuff
*/
private function doOtherInitStuff() {
// Do init stuff
}
#connect to database
private function connectdb(){ // Note the private scope too! Only the object itself needs to know how to connect to the db!
$link = mysql_connect($this->dbhost,$this->dbuser,$this->dbpass);
if (!$link) {
die('Could not connect: ' . mysql_error());
}else {
//echo 'Connected Successfully to Database<br>';
}
@mysql_select_db($this->dbname) or die( "Unable to select database!");
}
#read database
function readdb(){
}
#update database
private function updatedb(){
}
#close database connection
function closedb(){
mysql_close();
}
}
On the other hand if you intend to create a base class which will be used later for let say different DB "drivers" (extended classes with overloaded methods) you could create an abstract class which will only contain the blueprint for all the methods which your extended (driver) classes would need to implement.
But that's a bit advanced story :)
EDIT: If you need a class which would specifically be used for outputting stuff which DatabaseQ retrieves then create an extended class of DatabaseQ and put inside of it everything that will spit data out.
class DatabaseQOutput extends DatabaseQ {
public function __construct(){
parent::__construct(); // You make sure here that the parents constructor is executed and a DB connection and initialization stuff is taken care off
}
public function output() {
}
}
$db = new DatabaseQOutput();
$db->output();
But to tell you the truth you don't actually want any of your database specific classes to be responsible for outputting data because generally that's not their job. Database classes should be considered as models although you are not using MVC which means their role is primarily to serve as an abstraction layer for databases and all data fetching / sending operations.
If I were you I would create a class which is specifically tasked with outputting data which is retrieved with your database classes. That way you would create a class which is acting as a view in a way and will accept all responsibility for outputting data.
