The Decoupling Doctrine: Taking Abstraction Too Far

There’s an interesting post on Reddit in which Dracony speaks his mind about decoupling your application code from the framework. That is, about why it’s not too clever to do so.

In a nutshell, he argues that the use case for switching a framework mid-lifecycle for an app is unheard of, and that we should stop coding solutions for problems that aren’t there. By adding in abstractions, we waste valuable time that could be better spent otherwise, and there’s a high chance that even if we get to a point where we do have to change frameworks, we’ll find out we haven’t done a good enough job of abstracting our app, and will have to refactor a big part of it regardless. Time and effort completely wasted, then.

To many, this sounds too extremist - we all know that, for example, Laravel has some helper methods that look “native”, i.e. one might be tempted to think they’re native PHP functions when skimming through the code. Using them in services and components then tightly couples said services and components to the framework, so we should, naturally, decouple and abstract as much as possible. That’s not what Dracony is talking about, however.

In the above case of Laravel’s tentacles latching onto a project, most people who are decent at coding avoid this - we isolate our components into encapsulated packages with no holes through which such infections could spread. What Dracony is talking about, however, is trying to abstract absolutely everything in an app to be completely oblivious to a framework. Have a templating engine? Abstract it with a TemplateEngine interface. Have a MySQL database? Abstract with PDO. Using PDO? Abstract with yet another layer, and another, and another. All in the name of not tying your app to anything concrete. That’s abstraction hell.

The position I agree with is this commenter’s - most frameworks out there are “front end” in that they deal with templates, controllers, routes, forms, validation, while there are few “back end” ones. He suggests we should “couple” the front end stuff - because that all usually belongs in a specific framework anyway - and decouple everything for the back end - our services and other components that provide logic for the front end.

What are your thoughts on this? How much decoupling do you or don’t you do?

I feel using a framework is like buying the pre-built tool kit to repair your car. It has a lot in it, but probably not everything you actually need, depending on the job.

I also think the good frameworks like Symfony are realizing the “framework lock-in” is a bad thing and are doing their best to break down the framework into clear components. Case in example, a quote from Fabien Potencier:

Symfony 3.0 is more decoupled and more reusable than ever (the HttpKernel is going to be split into several smaller ones – the profiler for instance will be standalone; classes are moved from bundles to components; components are extracted from existing ones, …)

So, I don’t think devs should be worrying so much about making framework agnostic code. Rather, I think the frameworks should be worried about reducing the “tentacles” they cause to as few as possible, if not, to none at all.

Other than that, I went searching for other opinions on framework agnostic code.


1 Like

This is a significant point; I think the bigger issue isn’t coupling your application to a framework, but coupling the framework components to each other. At some level, that can’t entirely be helped, but I’ve seen a lot of movement in the PHP community to make individual framework components more reusable outside of the specific framework’s context.

1 Like

It looks like everyone agrees that the model and business layers of an application should be made framework independent but the idea of making controllers decoupled is still not supported by all programmers. I’m still undecided about that - it seems nice and appropriate but I’d love to hear from anyone who has practically benefited from independent controllers. Controllers are intended to be very thin anyway, so the benefits of decoupling them is not so clear cut. Is unit testing controllers important?

Freaking obfuscation.

Every non-native layer that you create / have to learn creates another layer that has to be learned and understood by others working on it now or in the future.

These could be the rantings of an old-school coder who feels more comfortable with a functional codebase rather than an interfaced, implemented and extended object-oriented solution; I’ll knock up a simple MVC framework tailor-made for a solution, with the minimum pre-dispatch and so on - fast, no bloat, and easy for others to understand.

Anyway, frameworks should enable you to get the business end visible to the world as quickly as possible (usually with lots of server-side caching to compensate for the thousands of lines of code to produce “Hello World”) If you switch to another framework, you should be doing it because it’s even easier to do so, and just refactor the business logic already there.

Frameworks vary in their degree of intrusiveness. Most allow a degree of stepping outside the framework so it surely comes down to the developer’s intent and level of comfort.

I played around with Laravel and I can see why you’d jump that way. But at this stage it’s not for me. I also develop in Wordpress which is more like a framework with every release. In that case, there’s most certainly a lot of coupling; it can’t really be avoided. But then we have the micro-frameworks, the popularity of which I’m sure is due not to the misnomer that they’re only for small projects but for the fact that they provide very basic services like routing and leave almost everything else up to the developer.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.