johnson@p.cs.uiuc.edu (07/26/89)
Every so often I see a message that makes me want to mount a soap-box and preach. My apologies to Edward Berard. This is certainly not an attack on you, even though you are the cause of it! I am usually suspicious of software metrics. In general, we do not know what to measure of software. We really need to measure the IDEAS in software, not the lines of code, though nobody knows how to do that. The typical size of a class depends on how good the design is. Those new to OOP often write huge classes, but a good design will have a larger number of smaller classes. The proper way to meaure the size of a class is NOT in source code instructions but in methods (member functions, etc), since the most important aspect of a class is its external interface. The number of methods is directly related to the number of source code instructions since no method should be more than a page long. In Smalltalk, the median size of a method is three lines. A class with more than 50 methods is probably getting too large. All classes are not equal. A minor variation of a well-understood concrete class can be built in a few minutes. A concrete subclass of a well-designed abstract class takes a few hours. Designing a good abstract class can take months. Thus, "the typical amount of time necessary for a designer to design a class" is simply not a well-formed question! This is like asking the average lifetime of a mammal. It makes a big difference whether you are a mouse or an elephant. In my opinion, the difficulty of moving to the object-oriented paradigm is overrated. The problem is that you have to have somebody who understands it who can teach the others. This person has to focus on teaching, not on building or designing. Most groups don't have anybody like this. I have just started teaching all the employees in a small company object-oriented programming and design. My guess is that it will take about 3 months before they are able to use the tools of the trade well and 6 months to become experts. This is based on the time it takes for me to train my own students. The effort required to build systems using object-oriented technologies depends almost entirely on the size and quality of the existing class libraries. Designing these libraries is hard and requires good designers. Using them is much easier. One of the major advantages of Smalltalk is that it comes with a good class library. Of course, eventually the other languages will have something similar, but telling people to just go out and write their own is silly. The whole point of object-oriented programming (in my opinion) is code reuse, and a system for code reuse that doesn't come with any reusable code doesn't do much good in the short term. You will first have to spend the long process of writing reusable classes before you can recieve the tremendous payback that is possible from object-oriented programming. The size and performance of a system depends as much on the language implementation and the class libraries as anything else. Object-oriented language implementation is still at an early stage, so size and speed should improve a lot in the future. For example, C++ is as efficient as other languages, though programs that make heavy use of class libraries tend to be a lot bigger because they tend to include code they don't need. Smalltalk programs have a very large minimum size because they all include the programming environment (though this will change) but they grow a lot slower because of code reuse and efficient representations of programs. Purely numeric Smalltalk programs are orders of magnitude slower than the equivalent FORTRAN programs, but programs that use a lot of graphics or that depend heavily on polymorphism might be just as fast or faster than their C equivalents. Thus, it is impossible to make simple statements about relative size and speed. Ralph Johnson