a few question of DI & ServiceLocator

[stdafx]

from kyber's post:
http://www.sitepoint.com/forums/show...9&postcount=31

so, in this case DI seems better than ServiceLocator because ServiceLocator depends on more things.

but also as i learned from the code above, when using ServiceLocator, we can take control of when to create the $bar object.

class SomeComponent {

  private $bar;

  function __construct(&locator) {

    /* some codes 
            lead to long process here ... */

    // finally we create the $bar ^^
    $this->bar =& $locator->createInstance('Bar');

  }

} 

the object $bar is only instantiated at the time we just need it. however, when using DI, the constructor may implement like this:

function __construct(&$bar) {
  /* long process ... */
  $this->bar =& $bar;
} 

it looks like the $bar is required to be instantiated even before the constructor works. suppose $bar is a very large object contains lots of data, isn't it wasting memories ?

[kyberfabrikken]

You generally wouldn't have heavy processing code in a constructor. The purpose of the constructor is just to initiate the object.
Secondly - the Bar instance is needed no matter how you put it, so it doesn't matter when it's created. The only exception is if an error happens within the constructor, but this is problematic for other reasons aswell. Either way it's not something you would normally expect to happen.

[DougBTX]

it looks like the $bar is required to be instantiated even before the constructor works. suppose $bar is a very large object contains lots of data, isn't it wasting memories ?

As kyberfabrikken says, and also, $bar can take advantage of lazy loading too, and only load up the "lots of data" when it needs it. That would probably give you memory benifits regardless of whether you used DI or a Service Locator.

hth,
Douglas

[stdafx]

Thanks for your answers.

but please excuse my slowness in understanding, Douglas. i'm a little confused of where the 'lazy loading' could took place. :'( since the constructor accepts an $bar object as parameter here, isn't the $bar instantiated before we call the constructor ?

[kyberfabrikken]

since the constructor accepts an $bar object as parameter here, isn't the $bar instantiated before we call the constructor ?

Surely, but the Bar object shouldn't open connections to databases, read massive files into memory etc. before it actually needs it. It's more of a general design-consideration than actually related to dependency-injection.

The problem with such a memory-hungry object doesn't get any worse with DI - the core problem was there even before.

[stdafx]

your explaining made me clear now. thank you very much, kyber.

[33degrees]

so, in this case DI seems better than ServiceLocator because ServiceLocator depends on more things.

From my understanding, DI is especially usefull when you're using code from various 3rd parties and you're trying to tie it all together, something relatively common in the java world. If you're writing all your own code, you can easily program all your constructors to use a ServiceLocator, with the overall result being simpler than using DI, especially in PHP4.

[lastcraft]

Hi...

You generally wouldn't have heavy processing code in a constructor. The purpose of the constructor is just to initiate the object.

Actually, if anything is likely to throw an exception, it would make my life a lot easier if it did it in the constructor. One way achieve this is to move from a service class that can carry out operations to the operation as a class (UnitOfWork, Transaction, Connection). The C++ people have taken this approach for years (backing out of errors being especially painful if you have to manage your own memory).

The problem is that developers don't expect this behaviour when your language has traditionally not supported exceptions. For example, you expect a return value with an error code (ruling out the constructor). Also you get a half finished object anyway, so the gain is not obvious. With everything in the constructor you don't have to worry about lazy loading either, as the application will instantiate when it's ready.

However, I don't see any shift in viewpoint happening right now. This means that heavy constructors will currently confuse.

yours, Marcus