Code Fragmentation

CodeFragmentation refers to the comprehensibility problems that can result from:

• The situation where little bits of functionality are spread into so many tiny chunks that locating the appropriate bit to reuse is difficult because of the sheer volume
• Breaking a system into “too many” layers, creating artificially deep and wide call-graphs (high fan-out, which is bad; as opposed to fan-in, which is generally considered good)

Mitigating techniques include reorganizing the code into a more reasonable hierarchy of well-named containers (namespaces, packages/classes, etc.).

CodeFragmentation can be a result of OverArchitecting?, or inappropriate use of LotsOfShortMethods. It a consequence of violating the principles of YAGNI (in terms of creating unneeded abstractions) and DoTheSimplestThingThatCouldPossiblyWork.

- NaimRu

Would you mind posting an example of class(es) that you feel suffer from CodeFragmentation? --

[Not the page author:] EJBs are one example that comes to my mind - Bean, Local/Remote Interfaces, Home Interface, Deployment Descriptor... a single concept spread out over half a dozen files. The wish to mitigating the mental overhead that comes from such fragmentation probably contributes to the popularity of tools such as XDoclet, which put the fragments back together again ("defragmentation"?).