Abstraction can help with the don't repeat yourself principle when coding. It can also cause trouble. Here's why...
There are some developers out there who like adding complexity into their code. Here’s why complexity is a bad idea.
Solving problems by writing code is hard already, right?
Yet there are developers who try too hard to be programmers rather than developers.
Developers develop solutions using tools frameworks and libraries to get the job done.
Yes, some developers build those frameworks and libraries. But they are fewer in number than those building websites.
Developers trying to be programmers end up writing code that is complex. And if the code is complex to begin with, it can only get worse.
That has many negative effects. But here’s the big two:
In coding terms, we abstract out the varying bits of code to leave behind the consistent parts.
That means we achieve the “don’t repeat yourself” principle.
In theory, it sounds like a great idea.
In practice, it often means we end up creating layers to achieve a single piece of functionality.
Here’s the kind of thing I’m talking about. Start with a PHP framework.
Then, add repository classes with a service class layer above that.
So, you call a service that calls a repository. Then, the model gets called too.
How does this result in clean, maintainable code? Well, it doesn’t. It results in code gone mad - that’s a nightmare for any other developer to work on.
It’s a good thing to try avoiding duplication. But to do it by adding multiple layers complicates things.
Adding a class to handle some common functionality is fine (you can even call it a service class).
You might have a blog posts resource. And you want to be able to share posts elsewhere around the website.
A service class would be a good way to do that, so you can create a method that returns the latest five posts (for example).
You can then use that functionality by calling on the service class anywhere you need it. The point being, it’s two layers, not four.
The other point being, another developer will be able to see what your intention was. And then build on, or otherwise maintain, that functionality.
I’ve worked on projects recently where this has been a real problem.
In one case, two of us had to tear down what was there. Then, start again (with a significant impact on the profitability of the project).
Not only was the code multi-layered to death, much of it didn’t work because of the layers.
After 20 years of coding, my advice to developers is this:
Keep it simple.
Discover the easiest way to get done what the website needs.
Don’t spend time adding stuff because it makes you feel more like a programmer.
Don’t spend time adding complexity to something that’s already complex.
Talented developers like solving problems. And they are good at it. But remember the old adage: good developers are lazy. That means they find the quickest and easiest solution to solving problems.
It doesn’t mean writing code that creates new problems.