QT Legacy
Posted by rickb on 8th January 2010
It’s occurred to me that, having worked in a number of languages and platforms, lately, just how much an influence Qt has been, particularly the signal-slot mechanism.
That single mechanism is, in my mind, as much an innovative development as the subroutine, the library, and the class.
Why so?
Fundamentally, because it provides a mechanism for incredibly strong isolation of modules, which, in turn, makes them more likely candidates for re-use. It also allows for stronger modular development in general – you can focus tightly on the functionality of the module and – perhaps even more importantl – you can hook tests to the module with ease. Unit testing is an easy and natural fallout of signals and slots.
IT’S WHAT I HAVE coined as ‘connection-based architecture’. (In ‘pattern-speak’, it’s called the observer pattern.)
Whatever you want to call it, it’s the best thing since sliced bread.
Once you’re exposed to it and have to go over to another language or toolkit, you immediately look for an equivalent mechanism in that technology. Some toolkits/languages provide the function inherently, others somewhat. For instance, Objective C implements it as part of the language construct. In fact, you could look at Objective C and wonder if Trolltech didn’t use it as a model – in effect turning C++ into an Objective C implementation. The syntax of Objective C for sending messages is a bit funky, but the functionality permeates every class declared in the language, which is better than Qt can do – you have to derive from QObject or embed a QObject-based instance to use it in C++.
The .NET CLR languages have a corollary in their delegate mechanism (not to be confused with Qt’s ‘delegate’ base class). Essentially, you can declare a delegate as a singular notification mechanism that behaves very much as a signaler, and you can register classes to receive it’s signals on a function. Syntax variants to declare and use delegates vary from language to language. In VB, it’s terrible (unless changed recently.) In C# (really the only language to write .NET apps in, IMHO), it’s easy.
As you go down the language line, it becomes increasingly difficult to use this kind of mechanism. ECMA-based scripting languages (ActionScript3, JavaScript), for instance, don’t have quite an equivalent mechanism, but the event mechanism is closely analogous. It’s reasonably easy to create a custom event and provide handlers for the event.
Server side languages are harder. Java actually has an Observer class, but it’s kind of clunky to use and not typesafe. Perhaps with the emergence of the generics construct, it may be easier to implement a signal-slot type of mechanism.
Of course, signals and slots are not the only thing that makes Qt a standout technology – the window and widget abstraction are often the rationale for using Qt in the first place. If you’ve ever tried to create a multi-platform application from scratch (I have – pre-Qt), it’s a lot of work and you’re often restricted to lowest-common-denominator functionality.
And, Qt provides some other niceties, as well – the bundled 3rd party functionality for things like XML handling relieves you from having to build and support these things as extras (which can be a difficult endeavor in a multiple-platform effort.)
But, the real conceptual leap (unless you’ve been a NEXT/Mac developer working in Objective C) is the signal-slot mechanism. The rest is UI abstraction, a certain amount of architectural framing (which is useful), and bundling.
That dynamic connection-based isolation capability is what I look for any time I have to make a move.
Posted in C++, Programming, Qt, Software Development | No Comments »
