OOP - "Accessibility"

[jeffrydell]

I have a database wrapper class which I would like to have 'available' all the time (in all classes).

Currently, I have to pass the class to every child class from the master which I think is a pretty clumsy way of handling the task. It's set up like this:

<?php
class Master
{
	var $db;				// Holds the Database wrapper class

function Master($config)
{
	// create the $db ojbect
	$db = new Database($config['server'], $config['user'], $config['pass'], $config['database'], $config['tablePrefix']);
	$db->connect();

	........ OTHER CODE .......

            $child = new ChildClass();
}
?>

Can't access the $db stuff inside the ChildClass unless I "pass" $db specifically.

Is there a better way? Just thinking out loud, should I instantiate db first, then make Master "extend" db? Would that make the db object available to all classes under Master?

[jeffrydell]

So over 30 of you have read this question and nobody has a word to say. Is the question too hard, not clear, what?

Please help me figure out how I can communicate in a way that you'll be able to help with this problem. I'm really at a road block until I can figure out why (what appears to be) simple inheritance isn't working.

Certainly I'm not trying to 'attack', just to (hopefully) move the conversation forward.

Thanks!

[NogDog]

30 viewers without a response is not actually many at all.

The 2 most common options, I think, are to either pass the DB object to each class that needs it, or to implement the database class as a "Singleton" and instantiate it within each class.

I have come to prefer the first method (passing it to each required instance) due to the drawbacks of the "global" nature of singletons, but it's not really that big a deal (IMHO).

class Example
{
   private $db;
   public __construct(MyDBClass $db)
   {
      $this->db = $db;
   }
   public something($sql)
   {
      $this->db->query($sql);
   }
}

$db = new MyDBClass($connection_stuff);
$ex = new Example($db);

[jeffrydell]

OK - I'm doing that but really thought OOP allowed 'child' classes to inherit properties.

So, when I have a method that is called by a method within a child class, do I have to "pass the $db from the Master Class to the Child Class and then from the Child Class to the method and from that method to the next method down?

It just seems that OOP could be a little more intuitive.

[NogDog]

I suspect you need to differntiate more in your mind between classes and the objects instantiated from them. A child class inherits the (non-private) class variable definitions from its parent class, but they are only definitions: they have no contents. It is not until you instantiate an object from a given class definition that any of the object's variables can actually become populated with a value. Perhaps a good way to think of it is that a class is a blueprint, while an object is an actual thing built from the design specified by that blueprint -- the class is a concept, the object a concrete item.

A book I recommend to anyone trying to come to grips with OOP in PHP is Matt Zandstra's PHP Objects, Patterns, and Practice. (It helped me a lot to really get my head around both the concepts and the implementation.)

[jeffrydell]

That was another 'a-ha' moment thank you. Twice today!

Very much appreciated.

The cynic in me would say "Of course, let's just pass along information ABOUT what is in the class without actually passing along the data ... why make it so easy that everything would just BE THERE?"

I find OOP cumbersome ... life was so much easier when one could write a script and part B knew what happened as a result of part A's transactions.

Now we need to write part B, instantiate part B, tell part B that part A exists, tell part B how to get what is IN part A, then have part B ask part A for the exact result of what part A did.

Yeah, that's so much better. Maybe not.

I know - it's not your fault and verbalizing my observation won't make it any better. Too bad ... but 'progress' marches on.

[NogDog]

All I can say is don't give up. When you achieve your OOP Eureka Moment ™ you'll find that for non-trivial projects it makes it much easier to keep your application design sane and maintainable (and reusable). But for all of us who started out learning to program in a procedural mode, it almost always seems to take awhile for our minds to make the paradigm shift to object-oriented thinking and really "get it". But now that I have pretty much gotten it, I much prefer it for anything more than a simple web form or two.

[Weedpacket]

jeffrydell wrote:

why make it so easy that everything would just BE THERE?

The problem with having everything just BE THERE is that .... everything is just there. You'd still have to find what it was you were looking for among it all - and you'd have made no progress towards doing that. Trick is to figure out in advance what will be needed and what won't, so that when you get there you've got just what you want.

life was so much easier when one could write a script and part B knew what happened as a result of part A's transactions.

Yep; the problem was that part B also knew what parts C, D, E, and F did, and part F knew what parts G, H, and I did, while part I knew what part J did, and when J did something that part I responded to, part F responded to that and changed what B did when B's behaviour wasn't supposed to change as a result of happened in part J .... it took a while to figure out what was going on.

Like NogDog implies, object oriented programming - like any other programming paradigm - is more a matter of how you think about what your program is and what it is supposed to achieve.