Class-based object-oriented languages, such as C++, C#, and Java, are dominant today in enterprises. Yet, classes are not the only way to model programming concepts in object-oriented software. In a recent blog post, Is the World Class-Oriented?, Ola Bini ponders if classes or prototypes—a technique pioneered by Self—are more natural when modeling programming concepts in OO software:
We, as programmers, need to have powerful ways to model the world. But ... we also need to be able to model abstract concepts. I’m getting more and more convinced that prototype based OO is easier to work with and reason around than class based OO...
Working with ideas categorized as classes constrain us. As an example, most programs start out as some vaguely formed thoughts, and these thoughts get clearer and clearer as we continue developing the system. In most cases we end up refining the class definition in a source file and recompiling. But working with a prototype based system, this isn’t the only choice. You can instead create an initial set of objects and then continue to refine and refine with new objects. This is especially powerful when doing exploratory programming...
Is the world really class oriented? No. Is it prototype based? Not really... We can see the world in class oriented glasses, or we can see it using prototype based lenses. Both choices work well for certain things, and when modeling it’s nice to have both. So the question is this - can you express the one naturally in the other?
Bini points out that prototype-based systems provide a different view on modeling programming concepts:
And then there is Self. Self was a programming language and environment based on Smalltalk, that introduced prototype based object orientation. This model basically removes the distinction between classes and other objects. Even in really open systems, where classes are instances just like other objects, classes still is the only thing you can make instances of in a class based OO language. In Self you clone an object to create a new one. Both values and methods are slots, and all slots of an object is copied when an object is cloned...
Self influenced several other languages, most notably JavaScript, NewtonScript, Io and REBOL. All of these have their own special take on prototyping, but the general distinction between prototype based and class based languages is easy to make.
In your experience, do you believe that classes or prototypes provide a better tool for developing object-oriented systems? And what is your take on hybrid approaches, such as ActionScript?
I don't think that either of the two provides the best approach for all problems, or that OOP in general is always the best approach (see C++ STL). A good language should provide basic facilities that can be used to create all kinds of useful abstractions.
First, I think he does a terrible job explaining what a prototyping system is. I read the post twice and as far as I can tell it's just a quick and dirty way to get multiple inheritance where you have little chance of knowing what's happening. I hope it's something better. :-)
In one paragraph he says
"...most programs start out as some vaguely formed thoughts, and these thoughts get clearer and clearer as we continue developing the system. In most cases we end up refining the class definition in a source file and recompiling. But working with a prototype based system, this isn’t the only choice. You can instead create an initial set of objects and then continue to refine and refine with new objects. This is especially powerful when doing exploratory programming."
Doesn't this leave behind a ton of obsolete objects? The amount of work should be about the same, but with classes the dinosaurs are extinct. (They live on in the fossil record as old revisions of CVS). It sounds like with the prototypes there are still dinosaurs around???
if 'prototype-oriented programming' in general is defined by the way it is implemented in javascript, the answer should be clear---seriously, even programming in assembler or brainf*ck is bound to be a more pleasant experience than programming within the javascript prototypes concept.
i have read so many articles about it, i have seen so many writers struggling with it and getting it wrong in the details, i find it so full of pitfalls and unobvious side-effects, i find it so devoid of obvious advantages over more mainstream object-oriented models that i fail to see why i should bother with it.
i mean, face it, javascript may not have a formal distinction between classes and other objects, but you still say 'foo = new Foo(42)' to obtain an instance. so while you probably defined 'var Foo = function(x) { ... }' earlier, the fact that this thingie must still be instantiated before it can be used makes the definition-time usage of the keyword 'function' (instead of 'class') a convenience of rather doubtful value.
other prototype-oriented languages may not be quite as awful as javascript, which managed to seriously disparage the concept of prototyping in the eyes of many a programmer.
> The world is not class-oriented. We do stuff on things > based on what those things provide, not on what those > things are called.
True, but that doesn't mean that classes are obsolete. Think 'structural typing' in statically typed languages (OCaml, for example) or 'duck typing' (Ruby, ...) in dynamically typed ones. No nominal typing there as in most mainstream OO languages but still classes.
The essence of object orientation is that objects collaborate to achieve some desired result. Classes and prototypes force programmers to focus on one object at the time. We need a new programming paradigm that supports programming in terms of networks of communicating objects. One proposal is a paradigm I have called DCI (Data-Context-Interaction), see http://heim.ifi.uio.no/~trygver/2008/commonsense.pdf
As far as I know, not even Platon and Aristotle could agree on whether ideas/concepts or items/objects comes first. Isn't it about time we reach a conclusion on this matter?
> > The world is not class-oriented. We do stuff on things > > based on what those things provide, not on what those > > things are called. > > What does a wheel provide?
> > > The world is not class-oriented. We do stuff on > things > > > based on what those things provide, not on what those > > > things are called. > > > > What does a wheel provide? > > What kind of wheel?
That's kind of the point but lets say, 'steering wheel'.
@Achilleas Margaritis @"The world is not class-oriented. We do stuff on things based on what those things provide, not on what those things are called. "
The world is probably best described using a UML Package Diagram. Also, a class is subservient to a role defined in the system.
My basic building blocks are a package diagram and a data dictionary, and one helluva domain expert.
Brain specialists say that humans organize their environment along two orthogonal axis: What things ARE and what things DO. Both are equally useful, neither comes first.
Programming with classes lets us specify what the objects ARE. Programming with collaborations lets us specify what objects DO.
Flat View: This topic has 17 replies
on 2 pages
[
12
|
»
]
Previous Topic
