SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Member
    Join Date
    Jan 2005
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    a few question of DI & ServiceLocator

    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.

    PHP Code:
    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:

    PHP Code:
    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 ?
    Last edited by stdafx; Sep 11, 2005 at 02:12.

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stdafx
    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
    Hello World

  4. #4
    SitePoint Member
    Join Date
    Jan 2005
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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 ?

  5. #5
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stdafx
    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.

  6. #6
    SitePoint Member
    Join Date
    Jan 2005
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    your explaining made me clear now. thank you very much, kyber.

  7. #7
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stdafx
    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.

  8. #8
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by kyberfabrikken
    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
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •