| I am an admitted object-oriented fanatic. I have been designing and implementing object-oriented software for more than twenty years. When I started designing and implementing object-oriented MATLAB®, I encountered many detractors. They would say things like “The object model isn’t complete,” “You can’t have public variables,” “The development environment doesn’t work well with objects,” “Objects and vector operations don’t mix,” “Object-oriented code is too hard to debug,” and “MATLAB objects are too slow.” None of these statements matched my experience with MATLAB objects. It quickly became obvious that MATLAB objects don’t have a capability problem; rather, they have a public relations problem. Part of the public relations problem stems from the fact that the sheer genius behind the design and implementation of MATLAB’s objectoriented extensions is masked by the abbreviated discussion in the user’s guide. If you want to use MATLAB to develop object-oriented software, ignore the critics, study the examples in this book, and reap the benefits.
Mark Levedahl exposed me to the possibility of developing object-oriented MATLAB software in 2001. Both of us had written a lot of C++ code, and we spoke the same object-oriented dialect. MATLAB objects are seductive because they seem so easy. Without help, trying to get everything right is anything but easy. My first object-oriented implementation was terrible. Construction was dicey. Interfaces were terrible. Modules were slow. The code was very hard to maintain. Maybe the critics were right. I was still learning. The lessons improved the next implementation, but there still seemed to be a fundamental difference between, for example, object-oriented programming in C++ and object-oriented programming in MATLAB.
MATLAB object-oriented code always bumped up against the same limitation. The elements spelled out in the object-oriented design didn’t map easily to an m-file implementation. Part of the reason for the poor match comes from the fact that each design element must be spread into more than one m-file: one module to get a value, another module to set it, and yet another to display it. In an evolving design, files can easily get out of synch. Couple this with the fact that a developer is free to define the mapping, and the result can be chaos. Faced with many competing alternatives, it is fair to ask, “Is one alternative better than the others?” After a lot of consideration and study, I believe the answer is yes. Following the best alternative improved the object-oriented implementations by orders of magnitude. Armed with the best mapping, a software tool to keep the modules and design in synch is a matter of design and implementation. Version 3 of the MATLAB Class Wizard will do this. The Class Wizard tool is included on this book’s companion CD. |