Is there a term for this coding practice?

Question

One of the incidental complexities of introducing features to an existing system is that the programmer often has to touch several areas of code that are not immediately adjacent. Over the long haul it can be unclear when looking at a bit of code that it pertains to another bit found elsewhere. It's both ugly design and a maintenance hazard. One of the properties of superior code, in my book, is its ability to keep a concept localized in one place. Sometimes this is built in to an architecture up front making it easy to plug new features into a system.

In scripting languages where all classes remain open to extension at runtime, it can be easy to think of the language as its own platform and not go the route of formalizing how things plug in. An app written in a scripting language could accept a module whereby the module reaches out to the various system components and changes them -- adding aspects to functions, wiring into events, and so on. Essentially, because the architecture wasn't properly designed for extension, we utilize a poor-man's plug-in system and oftentimes this suffices. In effect, we eliminate the need to modify several spots directly and instead tweak the system perhaps in similar spots but in an automated fashion.

That's what I'm focusing on. We still need to modify things that are spread across our system, but we do so in a way that keeps the entirety of the change localized to a single file (module).

In there a design pattern/term for the practice of simply localizing all the code (even if it has tentacles) to a single physical location (its own file)? I'm not sure it's the plug-in pattern or the extensibility pattern because in many cases a scripted system may not have been designed with extensibility in mind; however, it is still possible to localize change. Would this simply be called modularity? I'm really just looking for a shared term that I can use to rightly convey the concept without all the explanation.

Answer 1

A design pattern is (to quote Wikipedia) "general reusable solution to a commonly occurring problem." You're describing a characteristic of good code, not a particular solution to a problem, so "design pattern" doesn't really apply.

I believe the concept you're looking for is cohesion. Strictly speaking, cohesion refers how well the parts of a module belong together, but if changing a single piece of functionality requires touching several different modules, then cohesion must be lacking.

Separation of concerns is a related concept.

You might also be interested in reading about monkey patching (the ability of dynamic languages to extend classes at runtime, as you're describing; usually considered a bad idea, because it can so easily cause problems) and aspect-oriented programming (a more structured approach to putting cross-cutting concerns into a single module).