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.Jan.02 Fri
Allen Holub has an article on Why extends is evil. The main points are two: that declaring variables and arguments to be of concrete class types makes changes more difficult, and that changing the internal behavior of a base class can cause problems for subclasses that relied on the internal behavior.
That second problem, Holub calls "the fragile base class problem". The "fragile base class problem" as described by Holub is NOT the "fragile base class" problem experienced in C++ where code that is compiled (at different times) against different versions of the same class can have incorrect offsets for the vtable (method pointers) and data members, sometimes resulting in mysterious bugs -- and stepping through the debugger shows the instruction pointer jumping around in ways that don't correspond to the visible source code.
Holub's "fragile base class problem" is just a specific instance of unexpected coupling between two classes (which are connected via inheritance in his example, but could be coupled by a "uses" relationship). This problem often immediately detectable if you have a thorough suite of unit tests (as practiced by TDD), and you run them all after making changes. If you have modified the base class so it doesn't perform the way the subclass expects, the subclass's tests should fail, alerting you to undo your change, or modify the class or its subclass.
His recommendation to use more 'interface' inheritance rather than 'implements' inheritance is a good one - not all problems can be seen in the tests, and the flexibility of interface inheritance allows using mock objects to get better tests ("what happens to Y if one of its calls on X fails?").
The first problem - being tied to too-specific type declarations goes away in languages that don't have type declarations. Smalltalk, Python, Ruby, Javascript, and so on. (And some new ones like Scarlet and Groovy, though Groovy has optional type declarations, like Objective C.
The "fragile base class" problem still exists in any language that has "extends"-style inheritance. Scarlet doesn't have inheritance; I'd like to hear how people are using it, but I don't know if it has any people programming in it other than its creator.