Two OOPHP questions.

[dafydd]

The starting point is my database connection class.

 

$cxn = new Database();

 

Creating it has been educational, but I'm sure a couple of my shortcuts will make you cringe.

 

The first is that I use associative arrays in two methods. One builds a record deletion statement, the other builds a record update statement.

 

$cxn->deleteRecord($table, $fields);
$cxn->updateRecord($table, $primaryKey, $fields);

 

In each case,

$fields

is an associative array of the form

fieldName => value

. The method will then assemble and run the

DELETE FROM

or

UPDATE $table SET

statements.

 

How illegal is this?

 

Second, suppose I have a Person class that picks up its information from the database? Am I allowed to pass a Database object into it?

 

$cxn = new Database ();
$user = new Person ($cxn);

 

Or, do I have to extend Database when I create in instance of Person?

 

class Person extends Database () ...

 

The first case would allow me to share a single connection among several instances of Person. The second would force me to have to create a separate connection for each instance of Person.

 

Thanks!

dafydd

[falkencreative]

I wouldn't say there is anything illegal about what you are doing with arrays. If anything, that sounds like the logical way to go about it.

 

Regarding connecting your database object with your person object... I wouldn't have a Person extend the database object, since a Person isn't a database. You could potentially pass it in like you suggested:

 

$user = new Person ($cxn);

but I would actually do it slightly differently, using the "global" command to make the database object available to the Person object, even though they don't share the same variable scope. So, for example:

 

in your main index.php file:

 

$cxn = new Database ();
$user = new Person ();

and within your person class:

 

<?php

class Person
{
     private $db;

     function __construct()
     {
           global $cxn;
           $this->db = $cxn;
     }

     ...more code here...
}

This will should give you access to your database object throughout your Person class, without having to pass it in as an argument when creating the Person object, or making the Person object extend the database. This page discusses "global" a little bit more: http://php.net/manual/en/language.variables.scope.php

[administrator]

A final comment:

 

The use of inheritance in OOP is something you should do rarely in most cases. You only want to extend classes that will probably NEVER be changed ... so we are talking about hardcore foundation classes ... rare objects in your typical web application. Why? Because if you have to change a base class, you may very well break some or all the child classes .. a big mess.

 

Inheritance (though a key part of OOP,) is dangerous because the process of inheritance creates a tightly coupled relationship - an interdependency that we as OO programmers try to avoid like the plague - or me, my ex girlfriend.

 

 

Instead, use interfaces to keep the code structure consistent and use composition to reuse code.

 

Stefan

[dafydd]

Thanks, Ben & Stefan,

 

I like the idea of using a global $cxn, but one counter-thought occurred to me: wouldn't using a global like that reduce portability?

 

If I share my Person class as a way to share my Person database,[1] using a global "$cxn" would force other users/developers to use "$cxn" as the variable for their Database instance, right? Passing the Database instance in when the Person instance is created[2] means any variable name can hold the Database object, so long as the Database instance is created from the specified Database class. Or, am I thinking backwards?

 

Also, Stefan, I would like to discuss inheritance more with you. In the context of my first footnote, many of the departments also track department-specific information that isn't needed or useful in a general demographics database. In cases like that, I'd like to be able to tell those departments that they can extend Person in order to also link to whatever department-specific information they need. (Er, I just realized that may mean having to pass two database connection objects... Must think about that.) If I do build Person as a base class, future versions can only add functions, not subtract, right? And, while code inside the functions can change, the returned output needs to be consistent, version over version. What else do I need to think about? (Finally, should this inheritance discussion get its own thread?)

 

Thanks, again!

dafydd

 

[1] - The organization to which I'm contributing doesn't have good departmental access to the main volunteer database. So, departments with larger staffing needs are building their own applications, and volunteers are having to submit their demographic information to the org in general ~and~ each department with which they work. If my after-hours coding gets adopted, I reduce that inefficiency.

 

[2] - I hate the word "instantiate." "Create an instance of" is too hard to express?

[administrator]

I can see a base person class given all people will have the same basic attributes:

 

- name first

- name last

- age

 

etc ... Perhaps making it abstract to prevent direct instantiation. Doing so, will let other coders know that the intention of the person class, is to provide the template for the subsequent child classes. Makes sense?

 

... Again, part of the reason for OOP is to keep the code consistent and understandable on both a macro and micro level. Macro being the class hierarchy itself, keeping objects fine grained and task specific (no monster jack of all trades classes please!) and micro, seen in the class names, variable naming conventions, etc.

 

So here is a situation where you can establish (via the person base class) what the company wants to track about all employees. Of course, you could do that with an interface as well, freeing programmers from the being locked into a structure that might be too restrictive - if that makes sense?

 

Stefan