Independecy Injection and Service Descriptors

[lastcraft]

Hi...

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...

// 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

[kyberfabrikken]

But couldn't this be archieved with any kind of factory, including ServiceLocator ?

[wdeboer]

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>

[lastcraft]

Hi...

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

[Daimaju]

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

[lastcraft]

Hi...

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

yours, Marcus

[Ezku]

// 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.

[lastcraft]

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

[Ezku]

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?

[lastcraft]

Hi...

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...

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

[Dr Livingston]

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

[ghurtado]

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:

$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.

[lastcraft]

Hi...

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

[Etnu]

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.

[Ezku]

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.

[lastcraft]

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