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.