A question about the Registry Pattern

[OldWolf]

Howdy again all,

 

So I was reading through a tutorial on the registry pattern.  It seems like a great idea, but here's where I get a little confused:

For the registry pattern, you "register" an object with something like $registry->set ('db', $db);  Then, to call it, you do something like $db =& $registry->get('db');  Obviously I'm dropping a lot of steps, but these are relevent to my question.

 

What I don't understand (and correct me if my next statement is wrong, that might be the issue) is the idea behind the registry pattern is to avoid using globals to move objects between scopes... but how is it any better than using global, since you're still depending on external code?  Or does it have a different purpose?

 

The reason I ask is because I'm looking for a way to avoid globals within my functions, but I also don't want to pass all the various objects I'll need through the parameters. 

[Liquid Fire]

I personally just use a singleton pattern since the registry pattern is generally used for object that require only 1 instance.  I never seen the advantage of the registry pattern over the singleton pattern(maybe someone can explain that to me)

[dave420]

Registries can be made into singletons if you want to have a respository available from anywhere, or not, if you want to pass them around.

[Liquid Fire]

the issue i have is that way people would access object in my framework.  I like accessing variable like $this->database->query($query); instead of something like $this->registry->get('database')->query($query); of have to set the database variable in every class that need it is the contructor, it is much cleaner to me to just set it in the base the that all classes in my framework extend from in one way or another.  The ability to store objects in another object does not provide anything to me.

[dave420]

For that example, why not use a singleton database object?  Then it's even easier.

[Liquid Fire]

i am, that's my point, no need for a registry pattern.

[Daniel0]

A registry is used to store instances for global use and a singleton is used for only having one instance of a particular class. Those two patterns should both be used sparsely, but not interchangeably.

[dave420]

You can definitely have a singleton registry class for storing objects/variables for everything to access - that's a good way to have a site-wide configuration, for example.

[Daniel0]

Did anyone say otherwise?

[dave420]

No, I'm just emphasising that they can be used together.

 

$panties->unbunch()

[Jenk]

i am, that's my point, no need for a registry pattern.

So what happens if you need to change your database class? Oops! You've got lots of finding/replacing to do!

 

and on platforms that are stateful (i.e. not PHP) the registry is also much more usefull than a singleton, because it can be maintained within the session, and as it's nature is to maintain single instances of objects, it allows you to create instances unique to each session, but maintain the same "singleton" effect.

[puritania]

And for those who really want to make the components re-usable, use the dependency injenction pattern instead of the registry. global stuff like singletons and registries aren't really better than a simple

function x()
{
    global $x;
}

They just look better

[Liquid Fire]

i am, that's my point, no need for a registry pattern.

So what happens if you need to change your database class? Oops! You've got lots of finding/replacing to do!

 

Could you explain how a registry solves this problem, is seems the problem would exist either way?

 

I was only thing that if i use a registry that i would not be able to do $this->database->whatever but that might not be true, I will look into for the new version of my framework but I would still like to know the answer to the question above.

[puritania]

The only way to solve this problem is to define a good interface for Databases. For example:

 

interface DB
{
    public function query($query);
    public function fetch($res);
    // ...
}

class IAmUsingADatabase
{
    private $db;

    public function __construct(DB $db)
    {
        $this->db = $db;
    }
}

 

So your classes are only using the methods of the interface. Now, if you want to use another database class that goes like this:

class 3rdPartyDBClass
{
   public function execute($query)
   {
        // ...
   }

   public function fetchAssoc($res)
   {
        // ...
   }
}

Extend it like this:

class MyDB extends 3rdPartyDBClass implements DB
{
    public function query($query)
    {
        parent::execute($query);
    }

    public function fetch($res)
    {
        parent::fetchAssoc($res);
    }
}

 

I hope this helps. (And again: Registries are ugly, DI's are much better, see post above.)

[Liquid Fire]

What do you mean by DI(what does DI stand for)?

[puritania]

Dependency Injection, i already said that in the post above.

[Daniel0]

That's just type hinting. It's covered in the manual which I suppose everybody dealing with PHP has read.

 

http://www.php.net/manual/en/language.oop5.typehinting.php

[Jenk]

No, Dependency Injection is much, much more than Type Hinting.

[puritania]

No, Dependency Injection is much, much more than Type Hinting.

Thank you for saying that

[Liquid Fire]

No, Dependency Injection is much, much more than Type Hinting.

Thank you for saying that

 

well i don't get DI from that example.  either it is using a function to get a variable or just using the global keywords(which should never be using with proper OOP i think).

[puritania]

I didn't post any example of DI. I just made an example for a good and clean OOP. To understand why this is important, you should read the following article: PDF

 

If you have any questions after reading it, i can show you an example with my classes in my post above.

[Liquid Fire]

ok, here is a code example:

<?php
class base
{
private $configuration;

public function __construct(configuration $configuration)
{
	$this->configuration = $configuration;
}
}

class base_data extends base
{
public function __construct(configuration $configuration)
{
	parent::__construct($configuration);
}
}

class base_controller extends base
{
private $url_helper;

public function __construct(configuration $configuration, url_helper $url_helper)
{
	parent::__construct($configuration);
	$this->url_helper = $url_helper;
}
}

class base_model extends base_data
{
private $database;

public function __construct(configuration $configuration, database $database)
{
	parent::__construct($configuration);
	$this->database = $database;
}
}

class site extends base_controller
{
private $database;

public function __construct(configuration $configuration, url_helper $url_helper, database $database)
{
	parent::__construct($configuration, $url_helper);
	$this->database = $database;
}
}
?>

 

Now is this following DI?  Know i see the point of doing this however I don't see this as a real good option for my mvc framework since all these classes are going to be singletons anyways.  This to me is much easier to maintain and expand apon:

 

<?php
class base
{
private $configuration;

public function __construct()
{
	$this->configuration = configuration::get_instance();
}
}

class base_data extends base
{
public function __construct()
{
	parent::__construct();
}
}

class base_controller extends base
{
private $url_helper;

public function __construct()
{
	parent::__construct();
	$this->url_helper = url_helper::get_instance();
}
}

class base_model extends base_data
{
private $database;

public function __construct()
{
	parent::__construct();
	$this->database = database::get_instance();
}
}

class site extends base_controller
{
private $database;

public function __construct()
{
	parent::__construct();
	$this->database = database::get_instance();
}
}
?>

 

The me which way you would make a framework, the first and or the second way and why.

 

I also thing DI is a bit more useful for single classes however when i am talking about my framework, the framework is designed to work together so coupling them is not a real issue.  Having to maintain and make sure I pass the correct object are being passed is going ot be a lot harder to maintain and extend then if it is done automatically.