Passing a DB object to other objects

MelodyMaker

Hi, I've just got into PHP Object-Oriented programming, and I wold like to ask to you the following question (I think, to many of you this is maybe a very stupid one):

I have two classes:

A Database class and a SessionManager class. So the question is quite simple: what is the best way to pass to SessionManager a DB instance?

-passing it to the SessionManager constructor?
$session = new SessionManager(Database::getInstance());

-passing it to a SessionManager method?
$session = new SessionManager();
$DB = Database::getInstance() (suppose I use Singleton pattern)
$session->loadDB($D😎

or putting it directly INSIDE the SessionManager Object, maybe in its constructor:

Class SessionManager{
private $DB;
function __construct(){
$this->DB = Database::getInstance();
}
} ...

The questions comes from the fact that there will be many objects in my project and lots of them will use the DB object. I really don't know if there's a "best" solution. Maybe you can help.

Thanks in advance.

Davide

NogDog

If you are using a singleton pattern for your database class (which it appears you are from the use of the "getInstance()" method), then I would put it in the constructor of each class that needs to use it (like your last example).

Shrike

Sorry Nog but I'll have to disagree. Placing the Singleton call inside of the constructor creates an unnecessary dependency. While it makes things easier to begin with the dependency restricts what you are able to do in terms of polymorphism - I suppose the rule of thumb is to deal in objects and not classes.

A prime example would be if you wanted to unit test SessionManager - you wouldn't be able to isolate it, you'd always be testing the Database object at the same time.

NogDog

Shrike wrote:
Sorry Nog but I'll have to disagree. Placing the Singleton call inside of the constructor creates an unnecessary dependency. While it makes things easier to begin with the dependency restricts what you are able to do in terms of polymorphism - I suppose the rule of thumb is to deal in objects and not classes.

A prime example would be if you wanted to unit test SessionManager - you wouldn't be able to isolate it, you'd always be testing the Database object at the same time.

I can see what you mean, but how would you implement it, instead? If you pass it as an argument to the constructor or require that the client call a public method to pass it in, now you're depending on the client to deal with what would seem to be an internal aspect of the class that it would not necessarily need to know about.

I ask out of much ignorance and still relative n00bness to OOP, as I admit I'm not entirely comfortable with any of the options: they seem to just move the dependency to different parts of the application. Having it automatically called by the constructor does seem an undesirable coupling effect, but I haven't figured out what seems the least of all evils. (There's probably an obvious solution I'm not seeing, I'm sure.)

Shrike

NogDog wrote:
I can see what you mean, but how would you implement it, instead? If you pass it as an argument to the constructor or require that the client call a public method to pass it in, now you're depending on the client to deal with what would seem to be an internal aspect of the class that it would not necessarily need to know about.

In this case I would probably make it a constructor argument. Although there are other possibilities:

class SessionManager
{
  function persist( SessionPersister $p )
  {
    // This would write out session data to some storage mechanism
    // we don't care what that is!
    $p->persist( $this );
  }
}
class DbSessionPersister extends SessionPersister{}
class FileSessionPersister extends SessionPersister{}
class MockObjectSessionPersister{} // we'd really use a unit test framework for this ;)

Regardless of how it is done, the desirable outcome is that you code to an interface and have no knowledge of the implementation. Even a classname counts as implementation.

NogDog wrote:
I ask out of much ignorance and still relative n00bness to OOP, as I admit I'm not entirely comfortable with any of the options: they seem to just move the dependency to different parts of the application.

That is really the goal. It's sometimes called Inversion of Control or Dependency Injection. It's generally A Good Thing because the loose coupling promotes reuse. At some point you inevitably have to instantiate something, but the more you can hide that away the better,

NogDog wrote:
Having it automatically called by the constructor does seem an undesirable coupling effect, but I haven't figured out what seems the least of all evils. (There's probably an obvious solution I'm not seeing, I'm sure.)

It is very true that working this way takes up more lines of code. But the flexibility and eventual benefits make it worthwhile.

Phew. That was a bit longer than I intended.

MelodyMaker

Thank you very much for the replies!
Could it be the following one another solution?

abstract class Database{
 abstract protected function DBQuery($query,$line="",$file="");
 abstract protected function DBfetchArray($mode="");
 abstract static protected function DBgetInstance();
...

}

class mysqliDB extends Database{
 private function __construct()... //this should be a singleton
 static public DBgetInstance()  ... //this returns only an Instance of this object
 public function DBQuery ...
 public function DBFetchArray ...

}

class SessionManager{ //or any other object that neeeds a DB connection
 public function loadDB (Database $db){ //type hint
 ....
 }
}

$session = new SessionManager();
$session->loadDB(mysqliDB::getInstance());
//and so on for any other objects that need a DB

Could this be a correct solution?

laserlight

Shrike wrote:
Regardless of how it is done, the desirable outcome is that you code to an interface and have no knowledge of the implementation.

I agree.

Shrike wrote:
Even a classname counts as implementation.

That is not an accurate statement. Class names by themselves are part of the interface of a class, along with the public members (and to subclasses non-private members) of the class. The reason why the original design is fixed to an implementation is that it relies on a concrete class instead of an interface, e.g., one specified by an abstract base class, interface construct, or even the interface of a polymorphic base class.

MelodyMaker wrote:
Could it be the following one another solution?

If all the member functions in your abstract base class are abstract, then you may be better off just turning it into an interface, e.g.,

interface Database {
    function query($query, $line = '', $file = '');
    function fetchArray($mode = '');
    // ...
    static function getInstance();
}

class mysqliDB implements Database {
    private function __construct() { /* ... */}
    public function query($query, $line = '', $file = '') { /* ... */}
    public function fetchArray($mode = '') { /* ... */ }
    // ...
    public static function getInstance() { /* ... */ }
}

Could this be a correct solution?

It is correct, but this is a question of design, so correctness is a given. The limitation of your suggested design is that you are limiting the storage to a database. Shrike's suggestion is to construct a simple persistence framework for flexibility.

Also, it would be good to pass the database/persistence object to the constructor so that the SessionManager will always have a database/persistence object.

MelodyMaker

Thanks for your replies Laserlight and Shrike!
I've got another question about passing objects...let's suppose we'd got :

interface Database{
public function open(...);
public function query(...);
...
public function close();
}

class mysqlDB implements Database{
public function open(...);
public function query(...);
...
public function close();
}

class anyObject{
public function __construct(Database $db){
...
}

}
A page of test (let's say test.php):

$db = new mysqlDB();
$myObject = new anyObject($db);

And here's the question. I see that by putting a type hint in the constructor could be very useful if I change the DBMS. The class anyObject will accept in its constructor any instance of objects that satisfy the interface Database. But what happens if I have 100-200 statements in my code like that above : $db = new mysqlDB(); Suppose I would like to change my DBMS from Mysql to Oracle. I create my OracleDB class. Then, should I make a mega-replace all in my php editor to change that statement to $db = new OracleDB(); or there is a better strategy?

Thanks in advance.

Davide

NogDog

You could take the approach that [man]PDO[/man] uses (or just use PDO, perhaps?) of having the main database class instantiate the specific object for your DBMS based on the constructor's arguments. This could be accomplished via the factory pattern, I would think.

Another similar implementation worth looking at is the PEAR MDB2 package.

laserlight

But what happens if I have 100-200 statements in my code like that above : $db = new mysqlDB(); Suppose I would like to change my DBMS from Mysql to Oracle. I create my OracleDB class. Then, should I make a mega-replace all in my php editor to change that statement to $db = new OracleDB(); or there is a better strategy?

In the first place, it is strange to instantiate a database API wrapper 100-200 times. In fact, we usually only have one connection to the database. As such, I think the solution is to example why you have so many instantiations of mysqlDB, and cut it down to one, or at least only as many as you need.

MelodyMaker

...but if you had a web site made of, say, 100 pages and lots of objects...could that be so unusual?

Using the factory pattern as suggested by NogDog could it be a solution?

laserlight

...but if you had a web site made of, say, 100 pages and lots of objects...could that be so unusual?

Yes, since you would want to have a single point at which you instantiate the database connection object, or otherwise can change that will affect everything else.

Using the factory pattern as suggested by NogDog could it be a solution?

I do not think that the factory pattern is a direct solution to this problem. It can be part of a solution, but ultimately you need some kind of configuration file that would provide a single point to modify. For example, you might include a configuration file that provides the DSN to instantiate a PDO object.

NogDog

My thought about the factory pattern only had to do with being able to support different DBMS's.

I would think that you would want the database object initiated in the main, controlling script that is the ultimate generator of all the objects (either directly or indirectly via the objects it initiates). The actual DB object instantiation might be in one include file that would be require()'d at the start of each page, then every other call to a class constructor/method that needs that DB object would have it passed to it.

MelodyMaker

Thank to all of you, for you answers and excuse me if I insist but this is a question very important to me. Let's suppose that it is NOT a Database object that you want to pass across the pages and use in objects, but anything else (for example a Log or Error object).
Is there a way to change only the class (base class) and, of course, his name without changing every instantiation across the script ($newObject = new newObject()...) something like this, I mean:

interface BaseObject
|
Obj1 OBj2 OBj3 .... (all implement the interface and this objects are interchangeable, I could use Obj1 or Obj2, or Obj3...)
|
Then, a CurrentObject that someway (which?) stores or get the Object I need (Obj1 or Obj2, or Obj3,...)

This way, I can keep the scripts untouched because I instantiate the CurrentObject:

$newObject = new CurrentObject() // does not matter if this uses Obj1 or Obj2 or Obj3...

I don't know if the question is clear, I hope so.

Thanks in advance.

Davide

laserlight

Yes, you can do that.

Shrike

laserlight wrote:
That is not an accurate statement. Class names by themselves are part of the interface of a class, along with the public members (and to subclasses non-private members) of the class.

This might be just pickyness, but I'd say the interface is everything you can define with an actual interface, everything else is implementation, even private methods since they are particular to the class.

laserlight

This might be just pickyness, but I'd say the interface is everything you can define with an actual interface, everything else is implementation, even private methods since they are particular to the class.

Sorry to be picky, but I think it is important to get this right. Using the interface construct as the definition as an interface has a few problems. The first problem is that interface constructs are concerned with a public interface, and thus ignores the interface a base class provides to a derived class, which is not only the public members, but the protected members. If you provide a protected member and later remove it, derived classes that rely on that member would no longer work.

The next problem is that interface constructs in PHP are only concerned with member functions (methods), but declaring a member variable as public makes it part of the interface too, which can be a Bad Thing, since there is a loss of control over the type and even the existence of the member. The same reasoning applies: if you provide a public member variable and later remove it, clients of the class that rely on that member variable would no longer work. Rather, if we use the interface construct as a benchmark, not definition, we can then point out that this is a reason why member variables are not allowed as part of an interface construct (though class constants are allowed, and they are okay in some cases).

Shrike

Well I was suggesting that I was being overly picky :p

I agree that the interface construct is only concerned with the "public" as a whole, but then that is all we should be concerned with when we say "code to an interface". An object sends messages to another object via it's public interface, nothing else.

With regard to inheritance a protected method is just as hidden as a private method to another object and so has no bearing on the available interface.

Public variables are A Bad Thing as you rightly state, but this is the only thing an interface cannot define and yet can still be part of the interface.