CRTP for static dispatching

So, virtual dispatching is just too much overhead for you? I bet you do need every femtosecond from your CPU. Even if you don't, who doesn't like weird C++ constructs? Take CRTP, for example, a Curiously recurring template pattern:

template <class Derived> struct CRTP {
    const char* greeting() const {
        const Derived* self = static_cast<const Derived*>(this);
        return self->greeting();
    }
};

struct Hello : public CRTP<Hello> {
    const char* greeting() const { return "Hello world"; }
};

struct Bye : public CRTP<Bye> {
    const char* greeting() const { return "Bye world"; }
};

#include <iostream>
template <class T> void print(const CRTP<T> &x) {
    std::cout << x.greeting() << "n";
}

int main() {
    print(Hello());
    print(Bye());
    return 0;
}

Using this weird looking (ain't them all?) template device you can have static dispatching with most of the flexibility of dynamic dispatching. As a bonus, you'll drive all your cow-orkers insane! Bonus non useful information: In C++ 0X you could use variadic templates and have a proxy object with static dispatching. How cool is that?

Time your time

"time" is a useful command line utility to measure how long it takes for your super optimized algorithm to run, but it's useful as a timer too: just write "time read" and press enter when you get tired of waiting. Instant timer on your console!

Moving away from DB IPC

Last time I wrote about why DB IPC is bad. Now I intend to write about the way to start moving away from it, towards a better architecture.

As I mentioned, this pattern is deeply rooted across all the enterprise platform, so removing it is not an easy task, and it can only be done in small steps. Small steps means a compromise solution, you won't be going from IPC DB to a restful application in a week, so having an ugly-but-not-so-much-as-ipc-db solution is the way to go.

The first step to move from DB IPC to a services oriented architecture is moving from data driven applications to event driven applications. That means, instead of polling the database for changes, receive a notification that the data has changed and act upon the event.

A way to implement notifications without polling is having the DB notify you of any changes occurred. A way of doing this is using something like otl_subscriber, a wrapper to Oracle's notifications features. Postgres has its own notification schema, MySQL AFAIK doesn't.

Once you have managed to separate the responsibility of processing the event and the data of the event itself, it's easy to go one step beyond and implement a messaging platform, like CORBA or something like AMQP.

Conclusion: the architecture may not be nice with DB notifications either, but you have taken the first step towards decoupling two different components. From this schema to a real queue there's only one step, and once there you can finally begin to have a db-schema for each application.

DB IPC: Communicating processes the wrong way

A common pattern in enterprisy applications is DB IPC, probably one of the worst kind of coupling you can have. If you tell me you never saw it I won't believe you, but in any case: DB IPC is an architecture antipattern, in which you have several semi-independent components which must share some kind of information, and do so through a database. The producer writes into a table, the consumer polls the table for changes.

For an otherwise perfectly designed application, DB IPC may seem like a bad thing but not the worst kind of architecture possible. Clearly a god object may look uglier than an IPC DB. Yet this kind of architecture leads to a tight coupling between the component's inner data structures, making any change in them very unlikely, if not impossible.

Inhouse applications tend to rely a lot on this pattern, albeit unknowingly, for historical reasons: components which are now different applications were once part of a single process, in which no IPC was needed. After these components start growing, instead of a careful and planned change IPC DB gets implemented. It is the path of less resistance, after all.

Steering away from this pattern is very difficult, as it requires a lot of changes to every single application on the enterprise platform, and the introduction of new technologies like CORBA or web services. Seeing this is maintenance job and not productive (i.e. money making) development, it tends to get delayed.

Not everything is lost. An intermediate solution, not as ugly as IPC DB but not so nice as CORBA, is implementing a queue using the DB itself. We'll see a way of doing just that next time.

Truth be told

I bet 90% of enterprisey architecture diagrams are more or less like this one.



From Geek and Poke