Next: DSPOOM as a Graphical Up: Is DSPOOM ``truly'' Object Previous: Is DSPOOM ``truly'' Object
The ``classical'' way to interpret an object-oriented system is as a set of entity objects that hold data inside and respond to messages that can modify the internal data and state. According to some design methodologies (see [Abbot, 1983]) each noun in the domain's terminology must become an object and each verb must become a method on an object. The Expert pattern included in the GRASP catalogue [Larman, 2002], which is dedicated to illustrate basic and fundamental concepts in object-oriented analysis and design, recommends to assign the operations to the class who owns the data needed by the operation. According to some OO purists objects that only hold data inside or only have methods but no attributes should be considered degenerated objects.
Nevertheless, there are many signs that this conception of a class as an extension of an abstract data type is too constrained and not always recommendable. First it is interesting to note that modern object-oriented design has not followed this model. Design patterns and magical objects such as containers, iterators and traits[Alexandrescu, 2001] are good examples of objects that would be considered ``degenerated''.
It would be fairly simple to implement this classical object-oriented model (a class is a set of attributes plus a collection of methods that can be applied to these data) if we were just to model simple time-domain processes. An Audio class might have, for example, a DoIIRFilter() method. The Audio class would respond to this message by invoking the corresponding Infinite Input Response filtering algorithm. Even in this case the class would grow to the infinite and would not be maintainable or extensible.
Furthermore such a model does not stand true if more complex processes are to be applied, specially if a particular process is meant to change the representation of the data. As an example imagine how you would model an FFT. We could still have an Audio class with a DoFFT() method. This method, though, would change the representation of the signal in such a way that it would be very difficult to maintain this same representation as data of the same Audio class.
In many cases, it is interesting to keep a conceptual distinction between operations and data. This idea has been used in many different situations. In [Halbert and O'Brien, 1987], the authors say that there are times when operations are so complex that it is better they become objects in themselves. The authors list the following reasons for doing so:
Our domain is digital signal processing and we need to find a metaphor that is close to the experts understanding of their domain. In digital signal processing, users expect to find a clear distinction between a process and its input and output data.
At this point it is important to stress that our point of view on object-oriented design is very close to that of Nygaard's, already described in 1.2.3. An object-oriented model is always modeling a system. And a system, as explained in section 1.2.1, is a set of interacting objects, which are usually representing processes in the system. Our definition of a Processing object is in line with this idea of object-orientation and would be even be admitted by more traditional definitions. Booch [Booch, 1994b], for instance, after citing more restrictive definitions ends up defining an object as ``anything with a crisply defined boundary'' and he gives the example of a chemical process in a manufacturing plant.
And although the objects in a system are usually representing processes, we believe that we should also model as an object all the data involved in them. As a matter of fact, a model can be only classified as good or bad if it fits its purpose (see section 1.2.2). Other authors have also agreed on this same idea. In [Graham, 1991], Ian Graham describes several methods for deciding what should and should not be an object but he also emphasizes the fact that ``purpose is the chief determinant of what is to be a class''.
Finally, another hint that promote the idea that DSPOOM is ``truly'' object-oriented is that it provides many of the advantages of object-orientation such as:
2004-10-18