Scientific software development encompasses two domains. The algorithm-discovery domain is concerned with the development of a solution, typically in MATLAB where double precision is the default data type and exploratory ease trumps compute efficiency. The software-engineering domain is concerned with hosting algorithms on some architecture, whether it's a desktop Pentium, embedded Texas Instruments' digital signal processor (DSP), or Xilinx field-programmable gate array (FPGA); and in some language, perhaps C, C++, or Verilog; all the while paying attention to compute resources, multithreading, real-time I/O, and software extensibility and maintainability.

A few years ago when tasked with developing algorithms for digital communications signal-processing in MATLAB, I found myself fully in the first domain although much of my career has been spent hosting algorithms crafted by others. After reaching a critical mass of code in the form of numerous MATLAB functions and scripts, the natural question arose as to how the solution might "hang-together" in an environment where the flow of the algorithm could change dynamically at different phases of operation as well as conditions in the data. What quickly came to mind was an abstract object-oriented framework of signal-processing modules more naturally expressed in a language like C++. Because my algorithms had not been fully fleshed out and required a lot more research than development, it was premature to start implementing in a low-level language. Although MATLAB provided a richness of functionality, it needed more in terms of answering the architecture question.

Simulink, a sibling product of MATLAB created for simulation and modeling, purports to address some of the issues of block I/O, control, and implementation. Using another product from The MathWorks called Real-Time Workshop, models can be automatically translated into C for a targeted platform. But for a solution that was in its infancy and likely to change over time, Simulink is cumbersome and subtracts greatly from the ease MATLAB traditionally provides, especially for initial research.

At the time, I opted to tame the function-based language of MATLAB into the abstract framework I had imagined. What resulted was a pseudo-object-oriented, pass-by-value, crude-in-the-extreme mock-up, but sufficient for casting signal-processing stages into an archetypical anatomy that could be readily implemented in C++. By and large, the question of how the algorithm hangs together was answered but not in a way that would trivialize implementation.

Recently The MathWorks released an improved object-oriented programming feature with the 2008a version of MATLAB. Concurrent with research, scientific programmers can now structure algorithms into a set of classes complete with abstraction, virtual methods, encapsulation, reference passing, and even an event-listener model that, eerily, mimics the one I developed in my crude prototype. This article describes the new object-oriented programming features of MATLAB and how they can be leveraged for signal processing development.