June 1, 2010 by huionn
A work on software engineering by Ivar Jacobson et al. describes software entropy as follows:
“The second law of thermodynamics, in principle, states that a closed system’s disorder cannot be reduced, it can only remain unchanged or increase. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases. This is known as software entropy.”
Any intelligent idiot can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.
~ Albert Einstein
Last few weeks, I was reading application codes written with EJB 2 architecture. I read plenty of books criticizing EJB 2 before, but until now only I truly understand one of the key reasons – EJB component model encourages procedural code and discourage good Object-Oriented Design. Inheritance in EJB is either cumbersome (session beans, MDB) or impossible (entity beans). As a result, many powerful techniques of OO are less applicable in EJB 2. As the requirements grow over time, so as the lines of code in the classes…
From a books I read many years ago, there are 4 approaches to manage software complexity (it says 5, but I think the last one is less significant). I summarize them with my experience and other books I read.
LAYER – either architecture-driven layer (presentation, business and persistence layers) or domain-driven layer (decision support, operation and capability layers). Communication between layers is one direction only (presentation can access business layer, but not adverse).
MODULE – either architecture-driven deployable packaged modules or domain-driven package structure. Dependency between modules is kept to minimum explicitly (no hidden coupling and strictly no cyclic coupling).
ENCAPSULATION – the internal states are hidden from client and this facilitates bundling of data with behaviors. Client is insulated from any internal implementation changes.
ABSTRACTION – the client only need to know WHAT will be done which are the essential characteristics of a type. Client is also insulated from different implementations.