I’ve finally made it to my first Zendcon. Its nice to see some familiar faces and also nice to put new faces to familiar names.
I gave my maintainable PHP talk this morning. I love doing this talk. Thanks to everyone who attended. I’ve put the slides (pdf) up on my talks page.
Much of the material is based on Test Pattern columns that I’ve written for php|architect. Here are some of the specific columns.
One thing I like about both writing on and presenting on the same material is that I get feedback from the presentations that I can put back into the writing and vise versa. I’m looking forward to finding some better ways to explain layering and the depend on abstractions principle. If you saw the talk, was there anything you particularly liked or needed work? Leave a comment here or on the joined.in page.
Here are some of the books I mentioned in the talk.
I sat in on the PHP Code Review talk this afternoon. I thought it was a great complement to my talk. I tend to be a bit theoretical and this talk was very practical, but we covered a lot of the same principles. Nice talk. Nice scheduling, Zend.
I’m really looking forward to tomorrow. Unfortunately, I have to go back to work on Wednesday.
Feed
Subscribe to this blog…
I have to disagree with your list of drawbacks of DI. You mention that DI requires all potential dependencies to be instantiated. I do not see a drawback here, in case you hardcode the dependencies inside your classes you will also need instances of the objects that the class relies on. Optional dependencies can be set via Setter-Injection, thus not every dependency needs to be passed as constructor parameter. Many direct dependencies can force you to pass many parameters to the constructor but in such a case your application design might not be the best.
Very nice slides, i liked it.
Stephan, did author not mean that dependency has to be instantinated locally or become dependency?
I agree it can become an issue as you want to use an object and suddenly you depend on everything it depends on. Then you have to pass these instances in or create them in many many places.
Usually list of dependencies is not that long but it can be still a pain to pass the along everywhere you go. Especially that they add up int a
Lets assume my validator depends on the config (does not matter why or if it makes sense). Now every form using it will need to inject config object. So every controller using forms like that one has to pass config as well etc. Or every form has to create new instance which makes it directly depending on config (even worse i guess).
Optionally for shared instances some people use repository like Zend but i dislike global-ness of that approach a bit. You never know who add stuff to it and when or where. But for some very basic instances it might be the only easy way out.
Art
There are situations where DI and lazy loading conflict. You can do setter injection to inject optional dependencies. that may also force you to move logic outside of the class to make that decision to inject where you’d rather have that decision inside the class.
Managing the dependencies and building the objects should be done by your DI container so you do not need to worry about deeply nested objects. Instead you just have to ask the container for the object you want, all the wiring is done automatically for you.
did author not mean that dependency has to be instantinated locally or become dependency?