SitePoint Sponsor |
|
User Tag List
Results 51 to 66 of 66
-
Aug 4, 2005, 17:29 #51
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by wdeboer
.
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
The slides are at:
http://www.lastcraft.com/talks/
Sorry, not much commentary with the slides.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Aug 5, 2005, 02:41 #52
- 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 ?
-
Aug 5, 2005, 06:18 #53
- 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>
-
Aug 5, 2005, 07:07 #54
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by kyberfabrikken
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Aug 5, 2005, 08:09 #55
- 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
-
Aug 5, 2005, 08:45 #56
- 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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Aug 20, 2005, 09:01 #57
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
-
Aug 21, 2005, 12:50 #58
- 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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Aug 23, 2005, 11:48 #59
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
-
Aug 23, 2005, 11:58 #60
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Ezku
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');
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Aug 23, 2005, 13:48 #61
- 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.
-
Aug 23, 2005, 14:44 #62
- 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');
Garcia
-
Aug 23, 2005, 15:43 #63
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by ghurtado
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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Aug 26, 2005, 16:13 #64
- 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.
-
Aug 26, 2005, 16:30 #65
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Etnu
-
Aug 26, 2005, 16:33 #66
- 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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Bookmarks