Individual Ownership Destroys Encapsulation


Keith Ray
: …because everyone is afraid to modify other’s
classes, their own classes become kitchen-sinks full of stuff that
really belongs elsewhere — this does make classes harder to
understand, because they end up being badly designed and violating
encapsulation “in reverse” — the big fat
individually-owned-classes have many “internal” pseudo-objects they
depend tightly on, when they should be having looser connections
with external classes.
[via

Patrick Logan
]

I’ve worked on a number of projects where I’ve tried to move
people aware from a sense of ownership of the code they’ve written.
It’s not always easy and it is a complex problem trying to get many
people in a group to understand how most of a system or subsystem
works so they can code against it. However, in the face of more
agile programming methods with sufficient unit tests providing the
confidence to refactor then the situation improves.

What I find time and again is that when different people look at
code that has already been written, mostly they find places where
refactoring makes sense in order to simplify the code so that they
can understand it. The original developer got too close and knew
exactly how things were composed and didn’t need further
simplification but the system benefitted from the
restructuring.

This happens in other professions too. I know that whenever I’m
given some kind of document in Word or whatever, I find it much
easier to critique and offer editorial changes than it would be to
have written the document myself in the first place. In general it
is easier to work with something that needs polish than to start
from scratch. I say again that changing code can be a dangerous
thing but unit tests can give you confidence to make modifications
knowing you haven’t broken any tested behaviour.