/ This is a quasi-translation of an older post. Enjoy! /
Hands full of paradigms
Without actually thinking about it, we are constantly jumping between programming paradigms. A typical "N layer" application can easily grow this complex before the release:
- Java or .NET Back end
- Some legacy services we use through XML Web Services
- Relational database, document store, etc.
Lets count the paradigms here:
- Procedural (JavaSript, Back end, Database Stored Procedures)
- Declarative (HTML, XML, CSS, SQL)
- Object Oriented (Back end)
Isn't it interesting we ended up more paradigms than architectural layers? What if we toss some Domain Specific Languages in? Is it a good or bad thing?
At certain points of your architecture, you need to convert them from one paradigm to another.
Those are the points where all hell break loose.
When the worlds collide
The "white zone" in the center is the matching point between your paradigms. This is where you can safely implement your "things".
The "gray zone" on the other hand is covered by some of your paradigms but not all. Using these features is dangerous, but sometimes we take the risk: the feature feels so perfect. Sometimes it worth the effort. Other times we regret taking the unbeaten path. A performance issue or an unforeseen twist in requirements points to the lovechild as the bottleneck of future growth.
What can we do?
- Play safe and never leave the "white zone": will be boring after a while. You will copy paste all day along and then fix copy-paste errors.
- Play hard and code around: Of course you would never do that, would you? If you did this in the past, there is a fair chance you will end up in the "less feature for the same development effort = end of life-cycle is near" state. Try harder (or safer?) next time.
- Let's buy the perfect framework: For every generic problem there is a generic solution, right? Get Hibernate and solve the Object Oriented vs. Structured paradigm gap instantly. You will end up coding against an API, solve performance issues against an API, and generally live and die by the API of your choice. No silver bullet here. Move along.
- Keep it simple: the only smart way out is to keep the paradigms at the bare minimum. The simplest the architecture, the less paradigm collisions you need to overcome. Over time, there will be guys who want to bring their favorite framework, server, programming language because it is so cool and trendy. Resist them. Show them this blog post. Throw them out of the window if they don't listen. Anything but don't add architectural complexity to the design.
Have you found any other way around this? Let me know in the comments!