In his latest post Matt Frost takes a look at dependency injection. He thinks out loud about some of the common uses for it but wonders if there's a middle ground for using a DIC and injecting manual dependencies.

The question I have is what if a dependency in one class also has a dependency? To illustrate what I mean, here's an example with some code to follow. [...] I'm not really concerned about the code here as much as I am about the concept that I'm trying to illustrate, in order to use a dependency injection container for this scenario.

In his example code, he shows a "DBAuthMethod" class that extends the "AuthMethod" interface and an "Auth" class that requires an instance of "AuthMethod" as a constructor parameter. He wonders about constructor versus setter injection and thinks that a mix of the two may not be the best structure for the code.

I just can wrap my mind around a scenario where you could ONLY use a DIC, and if you can't use the concept exclusively what benefit is there to using it?

Have any suggestions to share? Let him know - this is a problem more and more developers run into as DIC becomes more widely used.

On PHPMaster.com there's a new tutorial showing you how to use Pimple (the dependency injection container from the Symfony folks) in your application to manage objects and resources.

In application development, we try to create independent modules so that we can reuse code in future projects. But, it's difficult to create completely independent modules which provide useful functionality; their dependencies can cause maintenance nightmares unless they are managed properly. This is where Dependency Injection comes in handy, as it gives us the ability to inject the dependencies our code needs to function properly without hard coding them into the modules.

They start with a look at the problem with working with "concerete dependencies", ones that are hard-coded into your classes making them not only hard to test but potentially difficult to maintain. They include an example of this (a "SocialFeeds" class and friends) and then one of two ways to fix the situation. They start with using constructor-based injection, injecting the Twitter service into the main feeds object. They also talk about another method - setter-based injection - where the objects are injected via specific methods on the object.

As a third alternative, though, they get to using Pimple to manage the objects, making it easier to inject just the one resource into your classes and extract the objects you need from there. There's also a bit of "advanced" usage of Pimple showing the use of the "share" and "extend" methods.

On NetTuts.com today there's a new tutorial introducing dependency injection and how it compares to other injection types (like setter and constructor). It shows how to apply the "Inversion of Control" methodology to create a container that can be reused across the entire application.

Chances are, at some point in your learning, you've come across the term, "dependency injection." If you're still relatively early in your learning, you likely formed a confused expression and skipped over that part. Still, this is an important aspect of writing maintainable (and testable) code. In this article, I'll explain it in as simple a way as I'm capable of.

He starts with an example of setter/constructor injection and talks about how they can make it difficult to use the class as things get more complex. His solution is to create a simple DIC (dependency injection container) that stores instances of objects or closures that can be extracted an reused.

Kevin Schroeder has a new post in his series looking at dependency injection in Zend Framework v2 applications. In this new post he shows how to work with setter injections that coordinate to properties in the class.

In a previous article I showed how you could pass in a fully qualified parameter name into the Dependency Injection Container (DiC) if you needed to be specific about where you need to have something injected. There is an alternate method here that is cleaner than what I did before.

He illustrates with a "Test" class that has a "$test" property and shows how to, using the ZendDi component, inject the class into the container. Using the "injections" configuration value, he uses the "setTest" method to push a value into the "Test" class instance in the "$test" variable.

Josh Adell has a new post to his blog talking about a debate between developers over which is the better method - using public properties or getters and setters to work with values on your objects.

I was recently having a debate with a coworker over the utility of writing getter and setter methods for protected properties of classes. On the one hand, having getters and setters seems like additional boilerplate and programming overhead for very little gain. On the other hand, exposing the value properties of a class seems like bad encapsulation and will overall lead to code that is more difficult to maintain. I come down firmly on the get/set method side of the fence.

In his opinion, the getter/setter method provides an explicit interface to the class that describes what it can do and how you can work with it. He gives code examples, comparing the two methods - simple setting of properties on one object and using get*/set* methods on the other. He brings up the point that, if ever in the future you wanted to handle the data for a property differently, say always make it an array or object. He also points out that this still doesn't prevent the setting of new properties directly, so he uses the magic __get and __set to deal with that.

In a quick new post to his blog, Rob Allen has shared a snippet for the Sublime Text 2 editor to make creating getters and setters for your class simpler (dynamically too).

As with a lot of editors, Sublime Text supports snippets which are essentially text expansions of a short phrase into more text. I needed to create a few getXxx() and setXxx() methods for some properties of a class and decided that the easiest way to do this would be with a snippet.

Included in the post is the code you'll need to put into the snippet - a simple find (regular expression based) looks at the currently selected variable and expands out the getter and setter for it. For more information on the Sublime Text 2 editor, see the product's website.

Bence Eros has put together a new post to his blog looking at some of the results he's found from performance testing the use of getters and setters in PHP.

The usage of getter and setter methods instead of public attributes became very popular in the PHP community, and it's going to become the standard coding convention of so many PHP libraries and frameworks. On the other hand many developers - including me too - strongly unrecommend such convention, because of its performance overhead. I wanted to make some performance comparison for years, and today I had time to do that. In this post I would like to show what I found.

He starts with a question every developer asks as their working in their application - why and when should they use getters and setters for their classes. He talks about using them as primary functionality or as fallbacks only when needed. He includes the simple benchmarking script he used to compare accessing/setting public attributes directly and using a getter/setter to do the same. The results aren't very surprising if you think about the "magic" that has to happen for getters and setters to work. See the rest of the post for those numbers.

Shawn Stratton has a new post to his blog talking about a topic he calls "flame bait" - the use of accessors in PHP applications (getters and setters) to access class properties.

Objects have prop­er­ties which some­times need spe­cial logic on how they are retrieved and set. There are sev­eral solu­tions to this and every­body has a dif­fer­ent view point about which is cor­rect, none are pretty and all have draw­backs which range from writ­ing extra code, cre­at­ing some­thing that has poor exten­si­bil­ity, or has issues with con­sis­tency. These don't even breach the issues with IDE code com­ple­tion and analy­sis. Lets look at some of these solutions.

The solutions are the direct access to the class properties (which can cause some painful inconsistencies when things get complicated) and the alternative of setting up getters/setters for everything. Shawn's alternative makes use of the __get and __set magic methods to catch the property values being set and handle them correctly, developers being none the wiser.

On DZone.com's Web Builder Zone Giorgio Sironi has posted a few methods you can use to help get rid of getters and setters in your OOP PHP applications.

Encapsulation is (not only, but also) about being capable of changing private fields. If you write getters and setters, you introduce a leaky abstraction over private fields, since the names and number of your public methods are influenced coupled to them. They aren't really private anymore:

To show his alternatives, he uses a sample "User" class with a whole list of private properties. There's initially a get/set for the nickname and password values, but he suggests a few replacements:

• passing values in through the constructor
• using the "Information Architect" pattern to have the most responsible method handle the value setting
• the "Double Dispatch" method that uses dependency injection
• using the Command pattern and changesets of data

He also briefly mentions the Command-Query Responsibility Segregation (CQRS) method, but doesn't have any code example to go with it.

In a new post Berry Langerak wonders if the getters and setters commonly used in PHP applications are a necessary evil and if they should be used at all.

Although I do still feel like getters and setters are to be avoided most of the time, it's hard to tell where to use them and where you shouldn't. [...] While writing the code for [PFZ.nl], I started to notice that each and every class in the system had accessors for most, if not all, protected fields. I've started a discussion with my fellow developers, and this is what I've argued.

He mentions a few things including an article he'd written previously on the topic, some of the points behind OOP programming, encapsulation and accessors and collaborators. He also includes several code examples showing what he considers right and wrong ways to do thing (warning, opinions ahead).

All in all, I don't think accessors are evil per se, but you should only ever use the accessors in cross-layer situations. Don't use accessors to build functionality, but only because you need the value to display and/or save.