The Basis of Object Oriented Programming
These days, everyone knows the foundations of object oriented programming - Encapsulation, Polymorphism, and Inheritance. Nobody (well, almost nobody) seems to argue that these concepts aren't important. But why is it that they are important? How do they help software development?
Consider encapsulation. It hides the implementation of an object behind a set of methods and only accesses the implementation through the methods. This means that we can change the implementation of a class without changing all the users of the class. So? So, it's easier to make changes to our system.
How about polymorphism? Why is polymorphism important? With polymorphism, we can treat different classes of objects in the same way. So? Well, the caller doesn't have to worry about what specific kind of object it's talking to. So? So it's easier to write the calling code.
How about inheritance? Inheritance allows you to implement a new class without having to re-implement a lot of code. So? So, it's easier to write the new class.
Do you see a pattern here? The key is ease of development. Encapsulation, polymorphism and inheritance all make it easier to write code. Software development is hard. OO techniques try to make it easier.
Now, let's look at some other programming concepts. How about static typing? The purpose of static typing is to try to prevent the programmer from making mistakes. To do so, most statically typed programming languages require the programmer to explicitly state the types of all variables. These types then act as a restriction on what the programmer is allowed to do. At times, the programmer must explicitly cast the types in order to make the system work properly. Does this make it any easier to develop software?
How about the "final" class declarations. The purpose of final is to prevent programmers from subclassing another class. The intent is to try to prevent misuse. Does it make it easier to develop software? I don't think so. In most cases, it makes it harder.
How about checked exceptions. Does that make it easier to develop software? In most cases, it's a pain declaring the throws through each method that the exception passes through. It might help ensure that the exception is handled somewhere, but does it simplify things? I don't think so.
That's why I like Smalltalk. Smalltalk lets developers to their work without throwing roadblocks in their way. It makes it easier to develop software. It doesn't try to restrict what the programmer can do to protect him from himselt. As I said, software development is hard. Why should your development tools make it harder?
Comments
In praise of dynamic typing
[Bernard Notarianni] May 21, 2005 12:37:41.081
Trackback from Bernard Notarianni In praise of dynamic typing David Buck has a very nice interpretation of object orientation concepts and static versus dynamic typing. It doesn't try to restrict what the programmer can do to protect him from himself. As I said, software development is hard. Why should your de......
restrictions = ease
[Darren Oakey] May 22, 2005 14:38:48.141
Let's suppose you are buying a product, and you have 25 choices. How long does it take to decide? How EASY is it to choose? Suppose there are only 2 choices? or 1. Is it easier then? Almost all boundaries, especially in programming, make life _EASIER_. Static typing makes life easier because it SIMPLIFIES the decisions you have to make. Then it makes life orders of magnitude easier because it allows the IDE to provide useful and high quality information about what you want to do - there without changing context, without looking a different IDE. Final classes, checked exceptions make life EASIER because you don't make mistakes. The protect you from both misuse, and the far more common programmers affliction of stupidity - and that protection makes programming EASIER because your program works. First time and every time. You don't have to spend weeks debugging. You don't get a call at midnight telling you the company has just lost $1000000 because "something went wrong". Almost all boundaries and protections make life simpler. Simpler = easier = safer.
Drowning in the koolaid
[James Robertson] May 22, 2005 15:37:47.383
Trackback from Smalltalk Tidbits, Industry Rants Drowning in the koolaid by James Robertson
Darren Oakey, commenting on David's post, has not only drunk the koolaid, he's swimming in it. To wit:
Yep, "final" makes things easier, IF the original designers thought of every possible contingency that I as a developer might ever run across, anytime, anywhere. Static typing makes it so easy that developer never, ever have to use casts. Not once - it simply never happens.
The last part of his comment is the telling part - he wants these things in order to protect the developer from his own stupidity. Just remember that the next time you use one of the mainstream languages - many of the "features" were designed with the idea in mind that you, the developer, are a moron.
As to his last comment, that these things ensure that your program works right the first time and every time? Pardon me while I go have a giggle fit...
Simpler = easier = safer?
[Vassili Bykov] May 22, 2005 18:37:14.478
Sorry, I didn't notice how "simpler" got in the picture as you were promoting more restrictions. It actually sounded more like: restrictions = complexity = reduced productivity = less done = fewer errors = safer. But I even that line is doubtful, seeing all the crap crashing software written in the supposedly "safe" statically typed languages compared to, say, Bottom Feeder or any of Smalltalk environments, which keep running happily even after an error.
I disagree Darren
[Anonymous Coward] May 22, 2005 20:15:12.598
Every day, I work with C# and VB.NET. Every night, I work in some small way with Smalltalk.
I'm not following you when you mention how these "features" of C# help, or how limiting your number of choices is a good thing? I have yet to find a piece of Smalltalk code where you are presented with 25 choices. Usually a choice in a dynamic language comes down to this:
Hmm, method is expecting object which implements #next. I must pass it an object which responds to that message. Where are the 25 options?
Can you please enlighten me on your secret bag of tricks which makes a statically compiled language makes things work first time, every time? Why is it that we get service releases of the framework itself, if things are working right first time every time?
I think you have never even used a real, type safe, dynamic language. I think your mind is closed to new ideas. I think you are talking about things you don't really understand. I think you are talking out of your ass.
I question Anonymous C..
[Dominique Jocal] May 23, 2005 11:51:08.345
Are you saying you look at code implementation to know what "type" is expected ? Or there is a way to express this "requirement" in signatures with Smalltalk ?
For #2, strong typing is the classical solution for javaists and C-sharpers. If smalltalk has a solution with dynamic typing, well, it's cool..
Yes Dominique, Smalltalk is cool ;-)
[Bernard Notarianni] May 25, 2005 15:10:21.751
Yes Dominique, Smalltalk is really cool ;-) For istance, looke how easy it is to implement an efficient, lightweight, powerfull web framework: http://seaside.st/ The main problem with smalltalk is that once you looked at it, it is very difficult to come back to Java/C#/C++/C familly of langage.
Method signatures as documentation
[Richard Demers] May 25, 2005 20:07:18.698
Trackback from Smalltalk Musings
Method signatures as documentation by Richard Demers
David Buck has an interesting item on the The Basis of Object Oriented Programming. Dominique Jocal, who is apparently a fan of static typing (which she mislabels as strong typing) commented
Actually, Dominique has a point. There is nothing in a Smalltalk method header that says what kinds of objects are required or permitted as arguments. However, this is offset by a helpful convention that is followed by most Smalltalkers; giving arguments a name that reflects the kind of object expected -- for example,
aString,anArray,aSymbolOrArray, etc. One can argue that this doesn't reflect the role of the argument in the method, but given the small size of most methods, it's not much of a problem. Further, in application methods, many (most?) arguments are of application defined classes, rather than system-defined classes like String or Array. An argument name ofanEmployeeis a strong indication that an object of class Employee is required.All this is good, but there is still a problem. Today's Smalltalk systems (take VisualWorks as an example) is loaded with all kinds of useful subsystems for doing all kinds of programming tasks. It only makes sense to want to use them to reduce the size of a project. These subsystems are organized into packages that can be loaded into an image as needed, but then which classes and which methods are part of the subsystem's API? The typical answer one hears is "Read the __ code" which is not at all helpful.
This, to my mind, is a significant problem with Smalltalk today. It fails to be helpful to programmers who want to use existing subsystems by not providing adequate documentation at the subsystem level.