It reminds me of the argument to move from structural programming to object-oriented programming. What? Isn't object-oriented good enough for programming-in-the-large?
At the end of the day, I don't get it. Who wouldn't want to reap the benefits of modular object-oriented programming in Java? Who wouldn't want to maintain an internal API -- between component parts of an application, not just an external API for external component parts?
The answer is simple. We use the term "modular" without clear definition. What does it mean exactly?
It means independence. You can write, develop, test and deploy a module without regard for everything that everyone else is doing. A feature of an application is independently deployed to the production environment. It is compiled independently from everything else that needs to be compiled. It is built independently.
A module is loaded at runtime -- independently from all of the other modules. It is unloaded independently.
This independence means that a feature can be developed in isolation, tested in isolation and used in a production environment without nasty surprises because of unknown or unexpected interaction with other concurrent modules.
If you are installing and upgrading software from a DVD ISO9660 image, it isn't exactly modular, is it?
If you are upgrading production components after hours, you're not modular.
If your build engine recompiles all of the components in your application in order to create the new build, you're not modular. (You do have a build engine, don't you?)
On the other hand, if multiple versions of business logic are running simultaneously in your production environment, you might be modular. Maybe.
Is your Java application modular in the same way that your GNU/Linux operating system is modular? To upgrade your kernel, do you have to reboot your computer? To upgrade your production application, do you have to restart your JVM?
No comments:
Post a Comment