In "prototypical languages" like JavaScript you can use object-instances to do much anything. Typically you do this by defining "constructors" to specify the DEFAULT properties of the group of objects created by that constructor.
After the constructor gives you the new instance you can re-assign its properties including methods any way you like. Then, and this is the big draw of Prototypical Programming, you can use that modified object as the prototype for further objects. Any object can serve as the prototype for any number of further objects ... which can serve as the prototype of yet further objects and so on. Convenient.
So why does ECMAScript 2015 need "classes"?
In the prototypical paradigm any object can be a "version" of any other object. This may sound like a great idea at first, a great extension, instances can act as "classes" too. Why not! More power to you. Why artificially limit the ability to use any object as a "prototype" from which new objects similar to it are derived?
The short answer is: Classes are constraints. Classes are contracts . Classes are invariants. Those make your program's behavior easier to reason about.
Classes describe the properties of all their instances, so when you see an instance, and you know its class, you know what properties, especially, what methods it has. If you know the class you also know what those methods do, or are supposed to do.
Now if any object can have its own set of methods, which is possible in the prototypical paradigm, it becomes harder to know what properties and methods any instance has, what are its methods and what can you expect from their behavior. That makes it harder to UNDERSTAND such a program, whether written by you or someone else.
Why understandability is the most important property of Software?
Understanding what software does, is THE great big challenge of Software Engineering. If you don't understand how a program works you can't modify it because any small change in one place could have big effects in other parts of the program, possibly crashing it under some conditions. If you can't modify it you can't improve it. Therefore, if you have to modify it you do it very carefully. Which means you can only improve it very slowly. And each improvement is getting more expensive (assuming each improvement is as difficult to understand as the previous ones).
If you can understand your program, you can improve any other property of it. If you can't, you can't.
A class is a declaration of the properties and behavior of the set of objects created by that class. It means you know much about any object simply by knowing its class. That makes it much easier to understand what your program does, as a whole.
If it walks like a Duck it may be a Duck. But it may bark like a Dog. It might. You just don't know.
If it IS a Duck, it will not bark like a Dog. If it is an instance of a class, it will behave as instances of that class do in all the ways prescribed by that class. That's why we need classes.
LINKS:
Copyright © 2017 Panu Viljamaa. All rights reserved
No comments:
Post a Comment