Troy
Unregistered
|
|
First, let me complement the author on several things. This article was much more balanced than the previous two. There was a discussion of when you have to use getters and setters. Even the example used getters and setters (and called them adders and providers), but limited the scope of their use. Best of all, nothing was called evil.
Of course, I couldnt agree with everything. How boring is that! So let me make an observation about Object Oriented Programming. In 1990, I took a class called Object Oriented Programming, taught by a nice man named Ralph Johnson. You might have heard of him, he went on to co-author a book called Design Patterns. Ralph was a big Smalltalk fan, and Smalltalk is a nice language. But Smalltalk never achieved much commercial success, in spite of the fact that many examples in the Design Patterns book were in Smalltalk.
One of principal problems with Smalltalk was its poor performance. Some of this poor performance was due to the fact that everything in Smalltalk was an object, including simple data types like integer. In order to add two integers in Smalltalk, you had to make a method call on the first integer object passing the second integer object as a parameter. This overhead for simple things like addition really hurt overall performance.
When Java was written, they decided they wanted to make an object-oriented language, but they compromised on integers. They made int, double, boolean, and other data types primitives, not objects. While this means that Java is not 100% object-oriented, that compromise improves its performance and simplicity dramatically. As we all know Java is now a very popular language, and I havent seen many ads for Smalltalk development lately.
I think this principal of compromise is very important. Can we design our systems to be 100% Object Oriented? Of course we can. But there times when designing a piece of the system to violate an OO principal can improve performance, simplicity, maintainability, and is easier to understand. Even though MVC and Model-Delegate violate encapsulation, they are useful in many cases and should not be ignored as options.
Please note that the authors own solution also violates encapsulation and introduces coupling. Any system with more than one class has coupling to some extent. Any system that needs to have different sub-systems will violate encapsulation. I think the key is to pick your spots to break the rules, rather than the extremes of breaking them all the time, or never, ever violating them.
Troy
A VB programmer and a VC++ programmer walk into a bar. The Java programmer ducks.
|
Anonymous
Unregistered
|
|
The idea that everything in Smalltalk is an object is just the programming model. Under the hood the Smalltalk VM is free to perform whatever optimisations it can. Messages sent to numbers, booleans and other fundamental classes are dispatched to methods in a way that massively improves performance. Smalltalk VMs are faster than Java VMs, and always have been. Java's primitive types are a good example of premature optimisation.
|
Troy
Unregistered
|
|
Quote:
The idea that everything in Smalltalk is an object is just the programming model. Under the hood the Smalltalk VM is free to perform whatever optimisations it can. Messages sent to numbers, booleans and other fundamental classes are dispatched to methods in a way that massively improves performance. Smalltalk VMs are faster than Java VMs, and always have been. Java's primitive types are a good example of premature optimisation.
Interesting. When I worked with Smalltalk, this performance issue was a real problem. But admittedly, that was 1990. I always did think it unnecessary that Smalltalk treats "primitive" data types as objects.
Do you have a view as to why Smalltalk has achieved so little commercial success compared to Java and C++?
|
Anonymous
Unregistered
|
|
I would say that it was all due to timing. OO really started to take off when people realised how much easier it was to write GUI code with object-oriented rather than procedural designs. At that time, desktop machines were not very powerful and C had taken over from Pascal as the most common language for PC programming. Smalltalk had wierd syntax for programmers used to C and a strange development style for programmers used to using batch compilers. So they turned to C++: it was the good old C that programmers were used to but with added object oriented buzzwords.
A few years later, when people started realising the limitations of C/C++ (slow development speed, buffer overruns, etc.). At that time Sun made a fantastic innovation: they realised that heavy marketing is as good at selling a programming language as it is at selling junk food! So with great fanfare and a cute mascot they launched Java. It may have been slow as a dog and extremely immature when compared to Smalltalk but it was much better than C++. And it had curly braces. That was enough to convince all the people who had been writing bad OO code in C++ to switch to writing bad OO code in Java.
So now we're all stuck with Java and all of its warts. But let's not contentrate on the negatives. Give thanks that we're not stuck with C++ and dream of the day that we will all be programming in a language that's as good as LISP or Smalltalk.
|
Anonymous
Unregistered
|
|
Hahaha. The IBM JVM has an execution speed that's only seventy percent slower than FORTRAN code, according to IBM research. All the SmallTalk developers I ever talked to weren't very technical-- they love to just sit around and talk. You're a boob if you think that you can't write high-quality code in Java, and at least as easily as in SmallTalk. Have you ever programmed in Java?
|
Unregistered
|
|
Yeah...
But thing like DosNotUnderstand would be useful very often...
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
