SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 66 of 66
  1. #51
    ********* 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 wdeboer
    Of course the emphasized part really sounds interesting, how would I do this? Anyone got a idea? Because I am not sure if the above is possible to do this, but I will look into that myself first thing tomorrow morning.
    Hey, I just did a presentation on this for PHPLondon a couple of hours ago .

    Suppose you could do this...
    PHP Code:
    // Aspect
    class MemoryLocked extends DynamicProxy {
        ...
    }

    // Shared object
    class MyStuff implements Stuff {
        ...
    }

    // Application
    $injector Injector::instance();
    $injector->decorate('Shared''MemoryLocked');
    $injector->registerAsSharedMemory('MyStuff');

    // LIbrary
    $injector Injector::instance();
    $stuff $injector->create('Stuff');   // None the wiser 
    A combination of AOP and DI makes adding shared memory objects (for example), called application variables in ASP, relatively easy.

    The slides are at:
    http://www.lastcraft.com/talks/

    Sorry, not much commentary with the slides.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  2. #52
    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)
    But couldn't this be archieved with any kind of factory, including ServiceLocator ?

  3. #53
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    194
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, Marcus I will have a look at it. It toke some time to find out that .xsi is a OpenOffice document Why not use Presentations <g>

  4. #54
    ********* 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
    But couldn't this be archieved with any kind of factory, including ServiceLocator ?
    There are three parts to the problem. The first is to instatiate from memory if possible, the second is to instantiate afresh if it's not there and the third is to make sure the object has appropriate wrappers for instantiation. The serviceLocator/DependencyInjector techniques can handle all of this.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #55
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    Germany
    Posts
    550
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is there a real difference between a ServiceLocator and Registry, or just another name? From what i get in this thread and the CoreJ2EE Patterns site they are doing the same

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

    A DependencyInjector/LightweightContainer is a Registry and Factory combined. The combination is a powerful one though.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #57
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    PHP Code:
    // Aspect
    class MemoryLocked extends DynamicProxy {
        ...
    }

    // Shared object
    class MyStuff implements Stuff {
        ...
    }

    // Application
    $injector Injector::instance();
    $injector->decorate('Shared''MemoryLocked');
    $injector->registerAsSharedMemory('MyStuff');

    // LIbrary
    $injector Injector::instance();
    $stuff $injector->create('Stuff');   // None the wiser 
    A combination of AOP and DI makes adding shared memory objects (for example), called application variables in ASP, relatively easy.
    This might be pushing it, but I'd be really interested in hearing more about what you described above. How does the decorating part work and what are its practical applications? I understand the Aspect part in AOP is about putting features that have a program-wide span to one place. Sounds useful but doesn't get me that far in understanding what you're really doing here.

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

    If the shared memory object is to work properly you have to have some locking.

    The proxy would just lock before every method and unlock after. Because the code get's the original object (a Stuff) from the injector, it has no way of knowing we have wrapped it in this proxy. This means that a perfectly normal class suddenly gains memory locking capability without either the class author, or the application author, being aware of it.

    That's just what you need for this problem.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #59
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Because the code get's the original object (a Stuff) from the injector, it has no way of knowing we have wrapped it in this proxy. This means that a perfectly normal class suddenly gains memory locking capability without either the class author, or the application author, being aware of it.
    How can that be the case? For type hinting to work, the wrapper object would have to implement the same interface as the wrappee. Doesn't seem that plausible. Perhaps a bit more clarification would be in order?

  10. #60
    ********* 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 Ezku
    How can that be the case? For type hinting to work, the wrapper object would have to implement the same interface as the wrappee. Doesn't seem that plausible. Perhaps a bit more clarification would be in order?
    That's correct if you have used type hinting. You probably wouldn't use hints for classes coming out of a container though. After all, the injector has done the work to find the correct type anyway. It's the same for coming out of a Java HashMap, you expect to cast (sans generics).

    If you are hinting hen you can have specific proxy subclasses for those interfaces. Again the dependecy injection can be used to sort this out too...
    PHP Code:
    class ThingProxy extends SharedMemoryProxy implements Thing { }

    $injector Injector::instance();
    $injector->registerDecorator('Thing''SharedMemoryProxy');
    $injector->register('ThingProxy'); 
    ...or some such. None of this is implemented yet so I have probably glossed over a lot of awkward complications.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #61
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    None of this is implemented yet so I have probably glossed over a lot of awkward complications.
    Indeed, but it's all interesting all the same so I shouldn't grumble I suppose

  12. #62
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since we are on the topic, I thought I would share a link I came across today that explains a very concise Dependency Injector in Ruby

    I was nothing short of impressed with how elegantly and succintly the problem is solved in a language a bit more expressive than PHP. After reading the article, it left me drooling over the use of blocks as an argument to the register() function, and how simply and effectively services can be referred to as simple object attributes. One idea I have not seen thrown around in these PHP threads about DI is to refer to each service by its unique name (seems like most of the efforts go the way of letting the container figure out the service/s based on the type of the required object), and I honestly think that approach would solve some of the problems that have been pointed out, such as registering multiple services for the same interface. To be clear:
    PHP Code:
    $container->register('db_dev''AdoDB'$config1);
    $container->register('db_prod''AdoDB'$config2);

    $db1 $container->getService('db_dev');
    $db2 $container->getService('db_prod'); 
    Maybe I am missing something, but it seems like current efforts leave the work of deciding which service to instantiate up to the type of the required parameter, therefore limiting it to one service per interface.
    Garcia

  13. #63
    ********* 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 ghurtado
    Maybe I am missing something, but it seems like current efforts leave the work of deciding which service to instantiate up to the type of the required parameter, therefore limiting it to one service per interface.
    You are right. Really Phemto will be an exploration, but also serve as the simplest introduction. At the end of that process we'll hopefull be in a position to write a much more PHP specific tool.

    Constructor injection does have the big advantage that you have to write hardly any extra code, and it hides the maximum amount of the component from the application.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  14. #64
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ultimately, there is no way to eliminate dependency. Just having the class being instantiated by something else isn't really enough -- ultimately, the code in one class *is* going to depend on implementation in another. You can, in theory, spend a lot of time coming up with the most perfectly elegant solution to the problem, but 9 times out of ten you're just wasting time. To reference kyberfabrikken's example, a car will always depend on an engine, no matter how you cut it. You might change the engine from a diesel to a hybrid, but ultimately you're still left with an engine that exposes the same basic functionality.

    Of course, this does depend heavily on the nature of your application. Ask yourself these questions:

    1.) Do I expect other people to be deriving from and implementing this class, or is this going to be used soley for something with dependencies on other code that you've written?

    2.) Is the implementation ever likely to change in any meaningful way?

    For most PHP projects, the answer to #1 is usually no, and the answer to #2 is almost definitely a no (if you at least come up with a reasonably decent design in the beginning).

    Typically, you make so few changes to those things that you spend more time writing the most abstracted-away methods for accomplishing a task than you will ever spend refactoring code later to add some new piece of functionality.

    Now, that doesn't mean toss encapsulation out the window, of course. Just don't worry about making sure that every single object is completely isolated. Deadlines are always going to beat out academic purity.

  15. #65
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    Ultimately, there is no way to eliminate dependency.
    Who said there was? What you say is mostly true, but you seem to have missed the point.

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

    Dependency injection should be used in very small doses and mainly for frameworks. However whenever you introduce a classical dependency you really introduce two: the usage and the construction process. We know a lot about usage interfaces and have a whole bunch of patterns and language constructs to cope. For construction though, all we have is the "new" operator and it's fixed class name. It's even more important for PHP, because of the way the app. has to be broken up into page scripts.

    The alternative to DI are bunches of AbstractFactories and Builders. These inflict a lot of refactoring and extra classes whenever a new component is added. It's bearable for an application which can be easily refactored, but it's a real problem for framework authors with all their versioning issues.

    I don't think DI has anything to do with academic purity, probably the opposite. It can be very powerful when you need it. A great time saver. The shared memory example is a good one here. Changing a bunch of classes to that approach at run time is a hard problem. With DI it could be a few lines of code.

    That's what's got me interested.

    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
  •