About Facading and Dependency Injection

Good evening everyone.

I’ve been meaning to write a post about this for a little while, it’s a common discussion point within developers working on enterprise level software. The argument regarding dependency injection vs. facades; how they’re applied and how they relate to most software systems you work with.

The first point I would like to make on this particular topic is that they are both useful, they both have their place.

For those of you who are not exactly aware of what these concepts are I have broken it down a little bit below; but if you’re not comfortable or familiar with the topic it probably is worth doing some research on before you make your mind up.

In essence, dependency injection is where you declare your class usages in a single place as a dependency, those dependencies are injected into where they are used. The concept behind this is that should you wish to swap out your dependency it should be easy. Take the following example;

I have a class named PermissionChecker. This class is used throughout many Controllers in an MVC framework. Whenever I want to check if someone has a permission I simply call upon functionality within the permission checker, which returns me a true or false.

The basic problem here is when I want to change the PermissionChecker, which contains all of my permission-based logic, it is painful, because I have to go through and replace or remove every instance of the PermissionChecker and hope that it doesn’t break anything, and I test everything heavily.

This is where Dependency Injection (DI) comes in. I create an instance of my PermissionChecker (PC) within the DI container. There are various open source DI solutions out there from Pimple to the DependencyInjector by Symfony. Anyway, the long and short of it is that the declaration of the usage of PC is in a single place, so should I wish to change it for SupremePermissionChecker (SPC) then it is easy and done in a single place, assuming the interfaces through which it is accessed remain the same.

This is the perfect solution to an age old problem!

But beware! There is an issue with DI, in my experience, and that is that either you become so dependent on it that it becomes difficult to utilise functionality and you end up writing lots of code which, in practicality, does very little. Or potentially you can end up over injecting, some parts of your system will be tightly coupled to one another by design, the issue with DI here simply compounds this issue, because the tightly coupling in a lot of days makes the DI redundant; as you couldn’t swap out the dependency even if you wanted to.

Now please don’t, for a second, think that I am slating dependency injection, because I’m really not. I think it is a very useful tool, it’s not my tool of choice but it does have a lot of advantages.

Additionally; don’t think the next thing I am going to mention is mutually exclusive to Dependency Injection either, they can be used in tandem without any issues.

So a facade is where you create a class which hides more complex logic behind it. Taking the same example I might have a PermissionChecker class which facades other functionality, for example fetching a user, fetching permission records which it can cross reference against the permission we are checking into.

In essence a facade is a way of abstracting your functionality a layer further. You have your system which utilises your facade, and your facade utilises whatever it needs to.

The reason I prefer this methodology, personally, is because you end up with all of your facades talking to one another. Which makes your Controllers very readable as you end up with something not dissimilar to:

if ( $permissionChecker->hasPermission(‘make-payment’) ){

$paymentThing->makePayment( $account, $sortCode );


Which I feel is very “English” in that it’s quite easy to read it and understand what’s going on. Additionally the advantage, for me, is that if Developer A (DA) and Developer B (DB) are both working on functionality within the same version it is easy. DA can be modifying whatever he wants in PC whilst DB can be happily working away on changing the payment gateway PaymentThing is using, as long as the interfaces remain the same then it’s all good.

To add to the mix, remember where I said earlier the two weren’t mutually exclusive? PaymentThing and PermissionChecker could well have both been dependency injected into their current context, so they could be switched out.

My only real question there is: why? If my functionality is all hidden behind facades, which provide easy interfaces to use, if ever I want to change them or do anything with them, I do it behind the facade and I’m fine. With that in mind, does Dependency Injection become a bit overkill?

Both of these concepts, as with all concepts, methodologies and rules within web development, are designed to make maintaining my software easier, rather than having invisible dependencies and entangled tight coupling which is impossible to defuse. That’s a developer’s nightmare when someone says “can’t we just take the payment functionality from X project and put it into Y project?”.

I think we have to sometimes be careful in web development and programming in general that we’re not making more work for ourselves. If facades are working for the separation of concerns, does it matter if the dependencies are scattered through the code, because somewhere that once needed to make a payment will always need to make a payment, and if that requirement changes, the code will need to change anyway, so we cut out the bit that says make a payment. We don’t have to remove the dependency or do anything else.

When I want to include payments into a new set of functionality on the site all I have to do is utilise the use statement to bring in the Facade, which handles everything else, and use the functionality contained therein.

Maybe I am missing the point and the value. And I would rather have Dependency Injection than nothing, but I would rather have an easy-to-utilise set of Facades, than have to Dependency Inject everything I want to use, and remember to rip it out when I don’t.

I’d love to hear other developers’ opinions on this one though, as it is something of a bone of contention in the community.

Take care all!

Keep your eyes on the prize, money matters

In this article I am going to share with you some of my thoughts about the business aspect of web development, and how that needs to apply to our principles as web developers (or indeed contributors to any project).

As programmers, developers, coders, whatever you want to call us, we solve many problems. In essence our entire job is to help businesses solve problems, we do it with technology in the same way that accountants do it with financial matters. When there are no problems left to solve we try to make things better.

I believe that good web developers know a range of technologies and how to apply them, this may be in the form of technologies or languages, it may be in the form of methodologies or frameworks, or content management systems. I can’t make an educated decision on the nutritional value of a Wispa Duo (my favourite chocolate bar!) and an apple, if I didn’t know the apple existed, or that the Wispa is bad for my waistline. For the record I concede that I am festively plump in February, and that’s fine.

Now, in order to normalise the many ways of skinning a cat, and to create maintainable software – remembering that money is everything – we, developers, have created a bunch of rules. Things like the SOLID principles, MVC architecture, the separation between logic and display, and everything like that. Hell, WordPress is widely adopted because it solved a common problem with easy (blogs and brochure sites), without having to hire a web developer every time.

So we have all the rules and, unless we have a decent reason not to, we should follow them. Absolutely, without a doubt, not questioning it for a minute. Well, maybe a little bit. You need to know the rules exist, and how to apply them, and I’m a strong advocate of all of them in almost all scenarios.

But the reason I’m an advocate of all of these things has nothing to do with whether I like them or not. They do help us build better software, undoubtedly. However, that’s not the point. The point is fast to build, easy to maintain, quality software is good value for money.

The reason I’m an advocate of SOLID, of MVC, of the various issues of PSR and all of those things, is because it makes my life easier, but the more important side effect of this is that it means I can build and maintain software quickly, with high quality, and high maintainability. It means when the business wants to see my output, or modify a requirement, or change something I can do it. It makes me an asset to a business, rather than a burden, a “no” man or a “that’s going to take some time, boss” guy.

This is why I’m an advocate of rapid application development frameworks. Because they allow the rapid development of high quality software. Time is money, so as far as our value to a business goes it’s about producing high quality stuff and doing it quickly. The same goes when we have to maintain it, which is why the rules are good.

This in mind, I don’t mind bending the rules when there’s a decent case for doing it. If the code is clear in it’s function, it is easy to work with and easy to find. I don’t see the issue.

I could be wrong, but I’m yet to meet a Managing Director, Chief Executive Officer or an Accounting Director who cares about PSR-2, PSR-4, MVC, OOP, SOLID or any of the cool stuff we insist we must know. And that’s absolutely fine! It’s not in their remit to know about those things, they’re our job.

It’s our job, and our responsibility, to deliver quality and efficiency. Once we are a few years into our careers we are expensive resources, with decent salaries, expensive equipment and software, usually a fairly high turnaround (most developers move on within 6 – 24 months). So it’s important we hit the ground running, and prove our worth.

I like making my clients and employers happy, with my ability to turn quality products out in record time. It makes my job far safer than ivory towers in legacy code. I don’t mind bending or even breaking the odd rule to achieve this, if another developer can work on, and modify/extend, the software with ease, then I’m happy. The rules are only there to make our life easier, if I’m not making life harder than I personally think any argument against it is moot.

If I’m showing a fast return on investment to the business, and there’s no question whether I’m providing value for money without cutting the quality of my work, then there’s no question as to whether I should be doing it.

Remember guys; we want to build awesome software that changes the world. We want to build quality software that’s easy to maintain and upgrade; but I’m hired by businesses. If I’m not making the business money, or showing a valuable contribution in decent timeframes, I’m not likely to be around much longer. Eventually I’ll be replaced, or the role itself dissolved and the work outsourced to someone who is doing the above.

Time is money, and money is time. Quality is important, but time is equally important. You have to be able to justify the resource poured into you, and you have to justify it by proving your worth and having tangible output