About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2004.Mar.01 Mon
Individual Ownership Destroys Encapsulation
Jeff De Luca, quoted by David J. Anderson:
If you do not use class ownership, when you assign a feature to someone then they must touch four classes (for example) in the system. They must have knowledge of four classes in the system.[...] Encapsulation is one of the founding principles of objects and is about a class being able to hide[...]
And how hard it is for a member of jelled team to have (or get) an understanding of the major classes of the system? In fact, how hard is it to understand any class of a system, if it's got intention-revealing names, "simple code", unit tests that reveal if your changes have broken anything, and so on? What I've seen happen many times in individual-class-ownership environment is not that the classes are intrinsically hand to understand, but that people defend their turf by discouraging other people from understanding their classes.
Also, 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.