Better Software - December 2008 - (Page 12)

Code Craft Train Wreck Spotting by Kevlin Henney The story so far: In my November 2008 Code Craft column, “Encapsulation and Vampires,” I clarified some of implications of encapsulation that are typically overlooked when programmers reduce the concept of encapsulation to mean nothing more than using the private keyword on data. A more robust definition can be found in the New Oxford Dictionary of English: encapsulate • Enclose (something) in or as if in a capsule. • Express the essential feature of (someone or something) succinctly. • Enclose (a message or signal) in a set of codes that allows use by or transfer through different computer systems or networks. • Provide an interface for (a piece of software or hardware) to allow or simplify access for the user. The emphasis here is on enclosure, essence, and simplified usage. In code, the idea of data privacy follows from this, but it is a consequence rather than the main driver or the sole definition of encapsulation. This view of encapsulation shifts the emphasis from being supplier-centric, where the supplier is the author of the class, to consumer-centric, where the consumer is a user of the class. The good news is that, in the long run, caring for the consumer also makes life easier for the supplier. class recently_used_list { public: void insert(const std::string & most_recent) { std::vector ::iterator found = std::find( elements.begin(), elements.end(), most_recent); if(found != elements.end()) elements.erase(found); elements.insert( elements.begin(), most_recent); } // state-changing operations, such as clear const std::vector & list() const { return elements; } private: std::vector elements; }; Listing 1 Barely Encapsulated The C++ code in listing 1 is where we left off last time. It shows a class that represents a recently used list—a set of strings held in order of insertion. Although the data members are declared private, the code is at best barely encapsulated (barely, adverb: [1] only just; [2] nakedly). Some might consider the code in listing 1 to be a strawman and dismiss it out of hand. It represents, however, coding habits that are more common than not. This approach to class design publishes incidental assumptions, reduces options, and leads to train wrecks. While it can be tricky to recognize your own assumptions (they’re assumptions, after all), and it’s not always obvious when your options are being reduced, it is easy to spot train wrecks. Chain of Irresponsibility The train wreck description is sometimes applied to a method-call or scope-qualification pileup in code, where chained calls traverse an object hierarchy and scopes are drilled into. For example, if you want to query anything useful about the recently used list defined in listing 1, you have to write code such as that shown in listing 2 (train wrecks are in italics). 12 BETTER SOFTWARE DECEMBER 2008 www.StickyMinds.com ISTOCKPHOTO http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2008

Better Software - December 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles What's a Manager to Do? Six Thinking Hats for Testers The Key to Good Interviewing 2008 Salary Survey Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.