Note that there are some explanatory texts on larger screens.

plurals
  1. POIncremental Refactoring Toward Null Object: C++ overloading
    text
    copied!<p>We've got a large legacy C++/ObjC++ application that could benefit from Null Object to replace thousands of redundant checks:</p> <pre><code>Thing *thing=CurrentSelection(); if (thing) thing-&gt;Drill() </code></pre> <p>If, when nothing was selected, CurrentSelection returned an instance of NotAThing</p> <pre><code>class NotAThing public: Thing { public: virtual ~NotAThing(){} virtual bool IsValid() const { return false;} virtual void Drill() {} }; </code></pre> <p>We could get rid of almost all those checks. For a well contained class with few clients, Null Object can be a Good Thing. But this class is ubiquitous; dozens of classes depend on it and there are thousands of checks.</p> <p>Can we incrementally refactor <em>toward</em> Null Object?</p> <p>One approach would be to overload operators on NotAThing to lie:</p> <p>We'd need to overload !, !=, and probably the casts to bool and int. And that still won't catch the explicit comparison "thing==nil". And I can already hear Scott Meyers (<em>Effective C++</em>) warning that this was lies madness. At minimum, it's a code smell. </p> <p>And, while we might incrementally back out some of these and lean on the compiler in order to find and remove unneeded nil tests, I worry about coercion chains causing confusing and unexpected results -- one reason to avoid those casts.</p> <p>On the other hand, there’s all those nil checks. They’re a code smell, too.</p> <p>What’s the wisdom for large-scale refactoring toward null object? The mechanics in Fowler and in Kerievsky are sound, but they’re designed for classes with a small number of clients</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload