This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: The Iceberg Class and Predicting the Future
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Someone on a mailing list asked why would he take his private methods that unpack a legacy code data-structure out of his class that uses them, "just to test them." Here's my answer:
LegacyDataStructureUnpacker sounds like a great stand-alone class. If its code is embedded as private methods in some other class, that makes the program much harder to understand, and that other class has too many responsibilities (unpacking as well as processing, or whatever). Extracting LegacyDataStructureUnpacker into a stand-alone class not only makes it testable, but also more understandable. Understandable code is less likely to be abused or misused.
And if some other 'user' besides the tests and the processing class, needs to re-use LegacyDataStructureUnpacker, there it is, ready for re-use. Made re-useable because of test-driven-development and the extract-class-refactoring. The processing class is a user, the tests are another user. By having two users, the class LegacyDataStructureUnpacker is more likely to be reusable.
We can't predict the future, but making classes have a single responsibility makes us agile enough to handle the future. Glomming loosly-related sets of functionality into the private methods of big classes keeps us from being agile. That creates Iceberg Classes. It's attempting to predict the future : "no one else will need this set of private methods, ever".
"But I don't want anyone else using this" is the objection that comes up. You don't want this "public" now, but who knows what the future will bring? However, you do want this correct (and thus tested) now, and understandable now, so those are good enough reasons to make the functionality into a stand-alone class now.
The keyword "private" is small protection, when anyone can rewrite "private" into "public" in your source code, or if you're using Java or some other environments, effectively changing private into public by hacking your .class file without changing the source. If you don't want the extracted class used by others, then explain WHY in comments, documentation, and face-to-face.
Previous Topic
