This came up in a conversation I was having online, and it occured to me that I have no idea how this is supposed to work: Quite a lot of programmers seem to just take as a given- indeed, obvious that classes are a necessary language feature for managing huge software projects.
It’s not obvious to me how they do this.
My question to you is, how do you know? What objective measures are there that show that classes increase productivity, code reuse, and reduce the complexity of the production of a program? What aspects of classes make them ideal for large teams to collaborate on?
And now, there’s a question I would like to ask, that is somewhat difficult to express. I’m sorry if I get this wrong and end up confusing or angering anyone:
Objectively, how do you know that the use of classes is not the cause of the application being large to begin with? That is, is it possible that a program with equivalent function could have been written, with much less code, small enough to not need any special measures to ‘manage’ it, using some other code re-use strategy? (there are lots to choose from, such as those in functional programming paradigms, or aspect oriented programming).
That last bit is something that Steve Yegge has been hinting at on his blog. But I’m kind of sceptical of both sides of the argument, due to a real lack of any hard data from anyone, and not enough experience to come to a conclusion on my own.
What do you think?
edit: In particular I’m interested in why many programmers think prototypal style inheritance is not up to the task when it comes to large applications. I’m sorry of this question is vague- it’s a product of my lack of understanding about this topic.
edit2: there seems to be some confusion over what I mean by functional programming. (I don’t think any version of VB was ever functional, certainly not older versions). Please refer to the wikipedia article. http://en.wikipedia.org/wiki/Functional_programming
edit3: and let me emphasize that I’m looking for Objective measures. Not subjective opinions.
Encapsulation theory provides one objective reason why classes are better than having no classes at all.
The International Organisation for Standardization defines encapsulation as, ‘The property that the information contained in an object is accessible only through interactions at the interfaces supported by the object.’
Thus, as some information is accessible via these interfaces, some information must be hidden and inaccessible within the object. The property such information exhibits is called information hiding, which Parnas defined by arguing that modules should be designed to hide both difficult decisions and decisions that are likely to change.
Note that word: change. Information hiding concerns potential events, such as the changing of difficult design decisions in the future.
Consider a class with two methods: method a() which is information hidden within the class, and method b() which is public and thus accessible directly by other classes.
There is a certain probability that a future change to method a() will require changes in methods in other classes. There is also a certain probability that a future change to method b() will require changes in methods in other classes. The probability that such ripple changes will occur for method a(), however, will usually be lower than that for method b() simply because method b() may be depended upon by more classes.
This reduced probability of ripple impacts is a key benefit of encapsulation.
Consider the maximum potential number of source code dependencies (MPE – the acronym is from graph theory) in any program. Extrapolating from the definitions above, we can say that, given two programs delivering identical functionality to users, the program with the lowest MPE is better encapsulated, and that statistically the more well-encapsulated program will be cheaper to maintain and develop, because the cost of the maximum potential change to it will be lower than the maximum potential change to the less well-encapsulated systém.
Consider, furthermore, a language with just methods and no classes and hence no means of information hiding methods from one another. Let’s say our program has 1000 methods. What is the MPE of this program?
Encapsulation theory tells us that, given a system of n public nodes, the MPE of this system is n(n-1). Thus the MPE of our 1000 public methods is 999,000.
Now let’s break that systém into two classes, each having 500 methods. As we now have classes, we can choose to have some methods public and some methods private. This will be the case unless every method is actually dependent on every other method (which is unlikely). Let’s say that 50 methods in each class is public. What would the MPE of the systém be?
Encapsulation theory tells us it’s: n((n/r) -1 + (r-1)p) where r is the number of classes, and p is the number of public methods per class. This would give our two-class systém an MPE of 499,000. Thus the maximum potential cost of a change in this two-class systém is already substantially lower than that of the unencapsulated systém.
Let’s say you break your systém into 3 classes, each having 333 classes (well, one will have 334), and again each with 50 public methods. What’s the MPE? Using the above equation again, the MPE would be approximately 482,000.
If the systém is broken into 4 classes of 250 methods each, the MPE will would be 449,000.
If may seem that increasing the number of classes in our systém will always decrease its MPE, but this is not so. Encapsulation theory shows that the number of classes into which the systém should be decomposed to minimise MPE is: r = sqrt(n/p), which for our systém is actually 4. A systém with 6 classes, for example, would have an MPE of 465,666.