2 ms·
The most tantalizing idea here was that "Local code should explain, or at least hint at the overall system design." I was disappointed that there was no further
by akkartik 14y ago
The most tantalizing idea here was that "Local code should explain, or at least hint at the overall system design." I was disappointed that there was no further reference to it after the introduction.
In the end, much of the article was yet another articulation of syntactic preferences.
- larsmak 14y agoI had to stop and think about that one myself. But it makes sence, at least if you emphasize on "hint at". When you wander though the source code, cascading the layers of abstraction, and jumping from place to place, it's nice that the code is somewhat bound to the same context.. in a way. It could be naming conventions, and using the same names for the same things consistently throughout the code. Another way to hint at the overall design is strict structure, e.g. layers: DAO-layer handles persistence, Business-layer handles business, Service-layer handles the interfaces to other parts of the application / other applications, etc. Naming the code-artifacts accordingly hints strongly at what it's doing. Also code that is not directly dependant on the context (business domain) should be put in a special place, in Java that would be in util-methods "hidden" away in some common-package. This way it does not clutter the rest of the code, and allows for easier reuse.