Dennis being all subjective again

The Challenges of Testability: State

Dennis Gurzhii — Fri, 22 Jun 2012 07:03:00 GMT

In the previous article of the series, we have explored the problems of testing a monolithic component and how said problems can be mitigated. This time let's take on another issue that often stands in the way of testing: maintaining a state.

As far as a software component is concerned, state comes in two kinds:

Internal state is represented by mutable data values that are encapsulated in the component. For instance, if a component is in fact a class, which is by far the most popular case, its internal state is typically stored in non-constant member variables.
External state is constituted by conditions and values that, while not being part of the component, exert influence on its behavior. One case of external state is variables in the same scope or above the component itself, such as global variables for instance. Another, slightly more complicated example of external state is a global function that returns a dynamic value, such as GetTickCount().

Consider this contrived example from a video game:

namespace LevelRules
{
    extern int monsterSpeed;
};
 
struct Position
{
    Position() : x(-1), y(-1), z(-1) { }
    int x;
    int y;
    int z;
};
 
class IGameObject
{
public:
    virtual ~IGameObject() { }
 
    // Will be called from the game loop on each iteration
    // to update the object.
    virtual void DoStep() = 0;
};
 
class Player; // defined elsewhere
 
class Monster : public IGameObject
{
public:
    void Move(const Position& position);
    void Attack(const Player& player);
 
    virtual void DoStep()
    {
        DWORD currentStep = GetTickCount();
        DWORD deltaMs = currentStep - _previousStep;
 
        // Change _currentPosition (depending on LevelRules::mosterSpeed)
        // and _animationPhase according to how many milliseconds
        // have passed since the previous step (deltaMs).
 
        _previousStep = currentStep;
    }
 
private:
    struct Order
    {
        enum Action
        {
            Action_None,
            Action_Move,
            Action_Attack
        };
        Order() :
            action(Action_None),
            pTargetPosition(),
            pTargetPlayer() { }
        Action action;
        Position* pTargetPosition;
        Player* pTargetPlayer;
    };
 
private:
    Position _currentPosition;
    Order _currentOrder;
    int _animationPhase;
    DWORD _previousStep;
};

With the current design, it's going to be a pain to unit test the Monster class. Let's see what concrete problems we can identify and fix.

External state

This is usually the nasty kind. In this case, external state relative to the Monster class is represented by:

LevelRules::monsterSpeed is a configuration variable that looks innocent enough and probably changes every once in a while when the user advances to a new game level. As with any other global or static value, our main concern is that it's shared by all threads, meaning that running several unit tests in parallel becomes impossible. Since monster objects most likely don't carry over from one level to another, it seems like a perfectly safe alternative to make it a constructor argument for Monster instead of a global.
GetTickCount is a Win32 API often used to measure time spans with average accuracy. The problem here is that for unit testing purposes we need to be able to simulate the flow of time so that game objects can be tested faster than in realtime. Indeed, we want our tests to run as quickly as possible, preferably in a matter of seconds, which is orders of magnitude faster than how the game pace would appear to a human player. Defining an abstract interface for time measurement and providing that to the Monster class would fix the problem entirely, with unit tests being capable of returning fabricated time stamps while the real game code still implicitly relies on GetTickCount for the underlying implementation. Depending on the semantics of Monster::DoStep, it may instead be possible to make the timestamp delta, deltaMs, into an argument of Monster::DoStep, which would simplify testing even further.

Internal state

The internal state of the Monster class is clearly represented by its data members. The class changes these values as orders are being issued and time passes, but what we want for testing is to be able to easily and momentarily transition a monster object to any kind of conceivable valid state to test various scenarios. As it is, in order to arrive at a certain known hypothetical state, any number of non-trivial manipulations may need to be performed on a monster object, and that would complicate the unit testing code to such an extent as to make it almost not worth it.

The solution? A variation on what is known in the industry as the memento pattern. If we were to provide a safe way for a monster to dump its internal state to an externally accessible data structure and to be able to initialize itself from that state object when required, we'd have a perfect way to manipulate a monster's internal state from our test code. Making it safe for production code, so that it doesn't accidentally mess with a monster object's internal state, is a little bit of a challenge though, so stay tuned.

How all the pieces fit together

Considering the analysis above, here's what a unit testing friendly version of the code in question might look like:

struct ITimer
{
    virtual ~ITimer() { }
    virtual unsigned long long GetTimeStamp() = 0;
};
struct Position
{
    Position() : x(-1), y(-1), z(-1) { }
    int x;
    int y;
    int z;
};
 
class IGameObject
{
public:
    virtual ~IGameObject() { }
 
    // Will be called from the game loop on each iteration
    // to update the object.
    virtual void DoStep() = 0;
};
 
class Player; // defined elsewhere
 
class Monster : public IGameObject
{
public:
    Monster(int speed, ITimer* pTimer);
    void Move(const Position& position);
    void Attack(const Player& player);
 
    virtual void DoStep()
    {
        DWORD currentStep = _pTimer->GetTimeStamp();
        DWORD deltaMs = currentStep - _previousStep;
 
        // Change _currentPosition (depending on LevelRules::mosterSpeed)
        // and _animationPhase according to how many milliseconds
        // have passed since the previous step (deltaMs).
 
        _previousStep = currentStep;
    }
 
private:
    struct Order
    {
        enum Action
        {
            Action_None,
            Action_Move,
            Action_Attack
        };
        Order() :
            action(Action_None),
            pTargetPosition(),
            pTargetPlayer() { }
        Action action;
        Position* pTargetPosition;
        Player* pTargetPlayer;
    };
    struct State
    {
        State();
        Position _currentPosition;
        Order _currentOrder;
        int _animationPhase;
        DWORD _previousStep;
    };
    friend class MonsterManipulator;
    void GetState(State& state) const;
    bool SetState(const State& state);
private:
    ITimer* _pTimer;
    int _speed;
    State _state;
};
// This class is only defined in the unit testing code,
// not in production code.
class MonsterManipulator
{
public:
    static void GetMonsterState(const Monster& monster, State& state)
    { monster.GetState(state); }
    static bool SetMonsterState(Monster& monster, const State& state)
    { return monster.SetState(state); }
};

When designing with testability in mind, the second version is what you will normally come up with on the first try. It is unit testing friendly without sacrificing readability, security, functionality or ease of use. Of course, as ever, there are many ways to skin it. I'm sure you can come up with other ways to improve this interface, so please feel free to comment below.

Of subject and object

Dennis Gurzhii — Mon, 07 May 2012 22:10:00 GMT

Object-oriented programming is all about recreating real-life objects and patterns of their interaction in code. However, since most of the concepts we deal with in our daily programming routine in fact have little to no physical representation (JSONParser, AccountPayable, MediaStream, you name it), we instead create a mental model of what these objects and their behavior would be like if they were to materialize. Even if a software class stands for a physically existing class of objects, it's likely to be but an abstraction, an imitation that only contains the properties and exhibits the behaviors that are directly relevant to the application intended by the author of the class.

Quite often, the model that we come up with strays far from how an object would behave under normal circumstances in a presumable real-life situation or assigns unnatural responsibilities to classes. Consider the following code:

class StreetAddress; // defined elsewhere
 
class GeoCoordinates
{
public:
    GeoCoordinates(int latitude, int longitude);
    int GetLatitude() const;
    int GetLongitude() const;
    StreetAddress GetNearestStreetAddress() const;
};
 
class Car
{
public:
    void Drive(const GeoCoordinates& destination, int speedMph = 40);
    void Stop();
    void RefillGas(const GeoCoordinates& gasStation);
};

What's the problem here? Cynical disregard for the passive nature of the classes involved. Stop for a second and ponder over these simple questions: can geographical coordinates actually do something, like look up a street address for instance? Can a car drive or stop itself? Or does it perhaps make sense for a car to fill itself up on gas? We tend to think of these classes as objects of actions, not exhibiting any active behaviors but rather acting as supplement and arguments to the actions of other parties.

Those classes look innocent enough because our eye is trained to ignore such "minor" inconsistencies in abstractions. After all, every abstraction has its limits, and we often and quite rightly let things slip. However, as it turns out, ignoring the nature of a class by wrongfully assigning it the role of a passive object or conversely that of an active subject in an interaction can often be the telltale sign of a more concrete and measurable problem in the making.

Consider what happens if at some point a new competing algorithm for street address lookup is found and the implementation of GetNearestStreetAddress() becomes the second best, but not completely obsolete. You would definitely want to provide the client with the ability to invoke either method of address lookup, so you come up with the following:

class GeoCoordinates
{
public:
    // ...
    enum LookupMethod
    {
        LookupMethod_One,
        LookupMethod_Two
    };
    StreetAddress GetNearestStreetAddress(LookupMethod method) const;
};

It's all well and good until a third lookup method appears. That method has a parameter that's vital to its operation. Not to worry, there's always a way to fix this:

StreetAddress GetNearestStreetAddress( LookupMethod method,
              int someParameterForLookupMethodThree = 0 ) const;

To add insult to injury, now you've got to have an extra argument just for that method which is useless for the other two. Meh. As you can see, a seemingly innocent flaw in an abstraction can have dire consequences on the quality and longevity of the code. This code above is now officially a throwaway grade mess.

So what went wrong? Hopefully, it's painfully obvious at this stage that there has to be a set of separate active classes tasked with performing operations on GeoCoordinates in their own unique ways and on their terms so that the coordinates themselves are relegated to a passive data container:

class StreetAddress; // defined elsewhere
 
class GeoCoordinates
{
public:
    GeoCoordinates(int latitude, int longitude);
    int GetLatitude() const;
    int GetLongitude() const;
};
 
class AddressLookupAgentOne
{
public:
    StreetAddress GetNearestStreetAddress(
                  const GeoCoordinates& coordinates,
                  int someArgument) const;
};
// A few more agents go here, with their
// own unique interfaces if necessary ...

With the freedom that this latter approach gives you, the code is more resilient to changes in requirements and generally stands a better chance of remaining structurally sound in the long run*. Please do always take the time to scan your abstractions for possible violations of the "subject vs object" rule and restructure the code whenever you spot inconsistencies in how roles are assigned to various entities. Although being just one example of what Joel Spolsky calls a leaky abstraction, this one can really ruin your day.

An attentive reader will notice that the Car class from the first example was thereupon left untouched, although it's haunted by the same problem we've just discussed. I leave it as an exercise to the reader to fix the car so it looks less like something out of a DARPA challenge and more like a vehicle you can actually drive.

(*) One of the senior architects at the Microsoft Skype Division says there is no such thing as "the long run" where code is concerned. I wish I could disagree.

The Challenges of Testability: Monolith

Dennis Gurzhii — Sun, 06 May 2012 11:10:00 GMT

One can often hear that "well-designed software is easy to test". Truth be told, testability is rarely just a lucky side-effect of good design, but a competent architect will keep testability in mind when planning for any sufficiently large or important body of code. In this series I will explore the various challenges of designing components for testability (not to be confused with test-driven development, which is a somewhat broader concept) and how these challenges can be addressed in production quality code.

Perhaps the main elephant in the room full of testability problems is monolithic encapsulated design. A huge black box with enormous surface area and obscure contents is the hardest thing to test, as anyone ever involved in manual exploratory UI testing will tell you. But let's set UI aside for now as a special case of the more general problem: being able to test something efficiently requires the means to access its internals.

Consider an online billing component with the following (entirely speculatory) interface:

struct CreditCardInfo; // defined elsewhere
typedef int ErrorCode;
typedef long long Money; // for simplicity
 
class IBilling
{
public:
    virtual ~IBilling() { }
    virtual ErrorCode Charge( const CreditCardInfo& creditCard,
                              Money amount ) = 0;
};

If this interface is all you have access to when implementing tests, you are in trouble. Consider for a second what this component would do internally to accomplish its function. You bet it involves data verification, numeric computations, complex networking over a secure protocol, robust transaction support and whatnot. Notice how all of it is cleverly hidden under the hood, which is Well and Good. After all, you wouldn't want clients to poke around the billing code, of all things, right? Encapsulation is often quite rightly the #1 priority, but it does apparently get in the way of testing.

So how do we approach the problem of testing this beast? There are several valid solutions to the problem, and they very much depend on the domain specifics of the code as well as its internal design (which is what the quote in the beginning was all about). Let's explore our options below.

The Back Door

The typical way to test a monolithic component without compromising its structure is to provide debugging entry points that are normally invisible to the end user, but only available to debugging clients. Similar to how complex integrated boards and chips are often tested via special extra pins that provide direct access to internal state information and allow the tester to perform certain privileged actions, we might create a special interface that would allow us to easily debug the various aspects of a component's functionality separately. Consider the following example:

class IBillingDebug : public IBilling
{
public:
    virtual ~IBillingDebug() { }
    virtual ErrorCode ValidateCC(const CreditCardInfo& creditCard) = 0;
    virtual ErrorCode VerifyEnoughMoney( const CreditCardInfo& creditCard,
                                    Money amount ) = 0;
    virtual ErrorCode CheckConnectionToBillingServer() = 0;
 
    // etc. etc.
};

There can be all sorts of weird requirements and restrictions on the usage of these debug functions, and the requirements are not frozen, i.e. they are allowed to change regularly as the system evolves. These may be, for instance, the order of execution or specific states in which execution is allowed, the accepted argument values etc. The ever changing requirements often stem from the fact that debug functions access the component's internals, which are legitimately subject to frequent changes.

While not perfect, this approach allows for testing to be performed on a monolithic component's internal logic units without having to decouple them, which isn't always possible. However, the question of decoupling brings us to the second technique.

Decomposition

If all you've got in front of you is the tip of the iceberg, it's time to blast that iceberg into smaller, more manageable pieces with larger surface area. But herein lie the challenges: if the pieces end up being too small, the whole iceberg will disintegrate and melt away; and if the ice is too thick, it may not be possible to crack so easily. Before I take the metaphor too far, let me translate this to geek speak: functional decomposition of a component facilitates testing by providing the test code with privileged access to a number of smaller sub-components that can be tested individually in isolation.

This boils down to formalizing interfaces of sub-components and making sure that those sub-components are usable on their own without being integrated into a larger system. It is important to ensure that:

The additional levels of abstraction created by introducing internal isolated sub-components actually make sense. Too much functional decomposition can also ruin a component by making its structure too ad hoc to be resilient to possible changes in the requirements.
The large component is using nothing but these internal interfaces to interact with its sub-components in order for them to be unit-testable separately from the component's code.
Sub-component inter-dependencies are minimized. Whenever any two or more sub-components depend on each other, testing becomes more complicated, but it's still possible using mocking, which is a fit topic for a whole another discussion.

This is the preferred technique as it essentially prevents a monolithic design from even occurring in the first place, although to the end users the components still appears to be a monolithic black box.

Did I forget any other techiques? I'm sure I have. Various domains and implementations will have their own unique manifestations of the monolith problem, and these will call for special approaches to ensuring testability, so your mileage may vary. Please feel free to contribute your thoughts in the comments below.

Exceptions considered harmful

Dennis Gurzhii — Sat, 28 Apr 2012 08:27:00 GMT

The doctrine of object-oriented programming dictates that exceptions are the mechanism of choice to raise (and, possibly, handle) severe error conditions that cannot be safely ignored by the client code. Let me just take a step back to explain why I think exceptions are all but inappropriate in most situations by definition.

Now let's forget about exceptions for a second.

I have implemented or used logging in several companies I've worked for. It's a pretty common thing to do, and any logger will usually provide several levels of log messages so that any messages below a certain threshold level can be automatically ignored to avoid cluttering the log with the less useful information. This implies that every log message has to be assigned some level value, or severity if you will. These typically range from Debug (safe to ignore unless you're trying to debug an error in the surrounding code) to Error (unexpected failure that could be causing problems for the user) to Fatal (so bad that the program will have to be abnormally terminated), with a few intermediate levels in between. This is all fairly trivial and seemingly off topic, but bear with me.

The single most annoying problem with logging levels is that severity (or level) of a particular log event is highly context dependent. What one client of a particular piece of code considers to be a truly fatal condition can be safely shrugged off by another. However, since logging itself occurs inside the aforementioned piece of code and not inside its client code, severity is forever fixed at some assumed, one-size-fits-all kind of value. Let's take an example. Here's client #1:

std::ifstream file("accounts.db");
if(!file.good())
    die_a_painful_death();

and client #2:

std::ifstream file("debug_dump.dat");
if(file.good())
{
    // dump some debug information
}

If, for the sake of argument, ifstream were to do logging, what kind of severity level would it assign to the error message when a file cannot be opened, let's say, due to lack of access rights? It wouldn't have a clue. Depending on the choice, we'd either have an overreacting log message or a message that can be easily lost when it in fact bears some real meaning. And all of this, mind you, is purely context dependent. This kind of confusion happens on most levels of abstraction in pretty much every corner of any sufficiently large source code base, because you bet that the client code I just gave you as an example also has some kind of client code of its own, and this goes all the way to the top.

Now take a moment and think about what exceptions are. An exception is an assumption that the error which is being propagated using that exception is severe enough that it has to be handled by client code and cannot be ignored, or else the program will have to terminate abnormally. But really, who is to judge, at any level of abstraction but the highest one (user interface in most cases), what is or is not a potentially fatal error condition? It's all highly dependent on what the client's intentions are, and any assumptions to that end are simply a waste of breath.

So what assumptions are normally made by exception-reliant code? I think you can make an educated guess. Every marginally important error condition in code that relies on exceptions is, and in fact has to be, treated as a potentially fatal error. And there's your problem right there. What ensues is what my former boss (a fervent supporter of exceptions, no less) called "exception spam". It happens all the more often when code is reused across several projects and severity assumptions of certain errors don't hold true for all of the reusing clients. Exceptions just keep coming (and being handled) on all sorts of seemingly innocent occasions. The problem is, once the "break on exceptions" debugger functionality is off the table due to exception spam, you are totally on your own. There are literally no techniques in your toolbox other than manual code analysis at this point. Consider this familiar client code snippet:

std::ifstream file("accounts.db");
//if(!file.good())
//    die_a_painful_death();

If ifstream were to throw an exception on error, there would possibly be no if clause afterwards to check for that exception because it may well be handled a few call frames above, by the client code at some distant level of abstraction. You can't set a breakpoint on a line of code that doesn't exist, can you? Bottom line, in order to figure out what the hell is going on one has to get their hands dirty, disable their debugger's "break on exceptions" functionality and go find that bug the old-fashioned way, using eyeball Mk 1. Well, either that or add try-catch blocks immediately around every theoretically throwing function call. Good luck with that!

If you have it in you to endure another rant on the pain of debugging exceptions, see this post on Joel's blog.

Exceptions, while a theoretically sound and clean concept that allows you to write less code and handle errors more rigorously, eventually introduce more severe (if less obvious) problems than they solve. I recommend you stay away from them unless there's a very compelling reason to do otherwise.

C++ Component Interface Design: Basic Isolation

Dennis Gurzhii — Thu, 12 Apr 2012 18:14:00 GMT

Designing an efficient interface that decouples a component from its client is a fairly routine task that's easy to mess up. A component is supposed to be highly reusable, flexible and easy to use, not to mention well isolated. Satisfying these diverse (and often mutually exclusive!) requirements is no easy feat and often comes down to certain tradeoffs in the component interface.

There's no one right answer to the big question of how exactly a component's classes should be exposed to the client in terms of isolation, but the problem boils down to three main issues: exposing the interface, encapsulating the implementation details and providing a way to instantiate the component's classes. We'll have a look at some of the popular choices, just as you'd probably do when considering various alternatives for a real-life production quality C++ component interface.

We'll use a classical Car & Garage example for the code snippets below.

1. The simplistic approach

// Component header, take #1
 
class Car
{
public:
    Car();
    ~Car();
 
    bool Drive(int speed);
    bool Stop();
 
private:
    void SoundAlarm();
 
private:
    int speed_;
};
 
class Garage
{
public:
    Garage();
    ~Garage();
 
    AddCar(const Car& car);
 
private:
    std::vector<Car> cars_;
};

This is a working interface that will probably do its job, and in many cases it is in fact the model of choice. For one thing, it's the fastest method of all. No complications, no problems. Instantiate the classes as you're all set. However, several potential issues are worth noting if this code is supposed to be a component interface:

Unchecked instantiation. A client can spawn as many instances of the component's classes as they please (both on the stack and on the heap). This becomes a nasty issue if those classes grow in size (storing large objects on the stack can be sub-optimal) or come to require certain instantiation restrictions (typically such as only one Garage object per client application). Since you never really know what the future requirements to the component might be, taking precautions against these problems early on seems reasonable enough.
Lack of insulation. Note how the client is exposed to a technically unnecessary detail of implementation in the form of private member variables and methods. These cannot be invoked by the client directly for apparent reasons, but they do present a temptation to manually edit the component header or use other nasty tricks to access the private implementation details of the component. As if this was not enough, there's the added inconvenience of having to recompile each client every time you alter the private stuff in the exposed classes, as opposed to merely having to re-link if those private things were duly insulated.

Albeit somewhat flawed, I find this isolation model useful for libraries that contain a loose affiliation of unrelated and relatively simple helper classes that just do not warrant a more sophisticated approach.

Let's try and refine the above interface to deal with its inherent problems.

2. The pImpl idiom and the singleton

// Component header, take #2
 
class CarImpl;
 
class Car
{
public:
    Car();
    ~Car();
 
    bool Drive(int speed);
    bool Stop();
 
private:
    CarImpl* pImpl_;
};
 
class GarageImpl;
 
class Garage
{
public:
    static Garage& GetInstance();
 
    AddCar(const Car& car);
 
private:
    Garage();
    ~Garage();
    Garage(const Garage&);
    Garage& operator=(const Garage&);
 
private:
    GarageImpl* pImpl_;
};

This time we applied standard solutions to control instantiation of the component classes and insulate their private contents: the singleton pattern and the pImpl idiom respectively. Note how the client doesn't have the definition of the pImpl classes and therefore cannot mess with them. Neither can the client create more than one instance of the Garage class (you can also impose other instantiation restrictions similarly). Job done? Umm... Not quite.

It appears that by addressing the problems with the initial interface we've inadvertently introduced other serious issues:

Object's lifetime control is far from perfect. Singletons and similar instantiation restrictions imply that either a) the class obscurely controls the lifetime of its own object (e.g. Meyers singleton) or b) the client has to manually destroy the object (e.g. Gamma singleton). Any special function that produces a class object is haunted by this ugly ambiguity - unless it's returning a smart pointer that is. Sigletons are also subject to static initialization and finalization issues that are somewhat beyond the scope here, but let's just say I don't recommend using them without a very good reason.
Performance overhead. PImpl has to be allocated dynamically, thus introducing a minor performance penalty for every class instantiation.
Code editing is burdensome. Insulation has its price: adding even a single function to the pImpl'ed class means you'll have to edit the back-end class as well as the interface class. If both classes are non-inline (which is probably the way they are supposed to be), it means editing too much code for comfort.

Singletons surely have their valid uses, but they almost never make it to interfaces of my components except as occasional supplements to make pre-fabricated shared versions of some of the other classes. As for the pImpl idiom, I find it to be only marginally useful compared to other alternatives.

Looks like the interface may need yet another makeover. Oh well.

3. Interfaces and smart pointers

// Component header, take #3
 
struct ICar
{
    virtual ~Car();
    virtual bool Drive(int speed) = 0;
    virtual bool Stop() = 0;
};
 
typedef boost::shared_ptr<ICar> PCar;
 
struct IGarage
{
    virtual ~Garage();
    virtual AddCar(PCar car) = 0;
};
 
typedef boost::shared_ptr<IGarage> PGarage;
 
PCar CreateCar();
PGarage CreateGarage();

The classes have gone abstract, and there's a simple factory in place to produce objects of those classes. Note how the factory is returning smart pointers this time, the magnificent boost::shared_ptr to be precise (you can also use std::shared_ptr if your compiler supports C++11, which it should). For some purposes std::auto_ptr would also do a satisfactory job in this case. So what do we have here?

Perfect encapsulation and insulation. Absolutely no class internals are revealed, in fact even the implementation classes themselves are hidden.
Controlled instantiation. The factory functions are in complete control over how the classes are instantiated, how many instances can be created etc.
Convenient lifetime control. The client can use the objects in the "fire and forget" mode most of the time while easily delaying or precipitating destruction of the objects as they please through controlling the lifetime of the original smart pointers and copies thereof. shared_ptr supports custom deleters that don't affect the type of shared_ptr template instantiation (see here, for instance), so this solution also supports allocating memory for the objects with something other than operator new.
Minor editing inconvenience. Adding new functions to the classes entails changes to both back-end implementations and front-end interfaces, but we're talking pretty small changes here. Definitely worse than the naive approach #1 but much better than the pImpl case.
Minor performance hit. Creating objects on the heap and using virtual functions makes for a barely noticeable but positively present performance hit. It's worse than both #1 and #2 in this respect because as many as two dynamic memory allocations will be done per class instantiation: one for the object itself and another for the reference counter internal to shared_ptr.
Unfortunate susceptibility to the infamous new/delete issue with statically linked CRT in a DLL library. For this reason, I prefer not to author DLL class libraries if at all possible.

Conclusion

Where does this leave us? In my humble opinion, the interface & shared_ptr solution by far outclasses other conceivable alternatives and makes for an almost perfect all-round instantiation model for a component interface in C++. I've used it too many times to count, and never had any significant problems or encountered major limitations except for the abovementioned CRT issue.

I will continue looking at other, more complicated aspects of component interface design in future articles, but this is it for today.

Design and productivity

Dennis Gurzhii — Thu, 12 Apr 2012 17:35:00 GMT

Each programmer has their own way of thinking. Some of us churn out countless lines of code per day by concentrating on what they are trying to achieve rather than how exactly they are doing it. Others, often regarded as slower thinkers, tend to ponder over details of implementation and produce fewer lines of code resulting in apparently lower performance than that of their hasty colleagues. Obviously a programmer's efficiency is adequately measured by the amount of code they produce in a given unit of time. Or is it?

Sometimes I find myself feeling guilty for staring at the IDE and thinking, apparently wasting precious work time that I'm being paid for. None of my superiors have ever scolded me for that, but a subconscious guilt is always there, prompting me to write that code as it comes to mind and never think twice or look back. Having seen lots of open-source code I can safely assume most GPL developers tend to do just that. Hardly structured, vastly copied-and-pasted code lacking any sensible architecture at all - that's what you're likely to get on SourceForge or wherever you prefer going for open-source inspiration. Now before you get all excited and start telling me about a gift horse's mouth, allow me to remind you that this was just an example to illustrate a common truth: poorly thought out code sucks. To name a few reasons why:

Low reusability. Code monolith is what you're likely to get unless you deliberately think what goes where in the code and how it's going to be (re)used later. Unless you make a habit of deliberately thinking about reusing code it will seldom be fit for any purpose outside its immediate intended environment.
Excessive complexity. Unstructured code tends to get complex. It is not unknown for such code to overwhelm its own authors let alone any support programmers unfortunate enough to be assigned to fix/update that code! Excessive code complexity creates new bugs and prevents the old ones from being fixed or even identified.
Bad example. Thinking less often means coding more (and I do mean literally coding rather than programming). This sets a very wrong example for teammates if a manager were to praise such a coder for superior productivity.
Domino effect. When assigned to support junk code, even careful and thoughtful programmers often subconsciously seek overly simplistic (i.e. wrong) ways to fix/update the code in order to get rid of it ASAP. The "this code is so screwed up, why bother thinking, let's just patch it up a bit" attitude creates a chain reaction whereby code evolves from bad to worse.

Writing the initial code is just 20% of the job, and I'm being optimistic here. The other 80% is supporting and reusing that code hopefully for years to come. By speeding up the initial 20% coders often neglect the other 80% and make someone's (or their own) job much harder at later stages of the code's life cycle. Which brings me to a conclusion: writing hasty code is utterly counterproductive. As a matter of fact, thinking about the grand scheme of things is one of the most productive things a programmer can do. Maybe that'll make me feel less guilty next time I stare at the screen, doing "nothing".