Smalltalk is a message-passing language. Java is a method-calling language.
A book about object-oriented programming that doesn't distinguish between message-passing and method-calling fails to express how languages like Ruby and Objective-C work.
21–26 of 26 posts
Smalltalk is a message-passing language. Java is a method-calling language.
A book about object-oriented programming that doesn't distinguish between message-passing and method-calling fails to express how languages like Ruby and Objective-C work.
I found this to be a great (ruby based) design book. Ruby best practices by Gregory Brown (free download http://rubybestpractices.com/ )
Why not import some of HtDC best ideas to the Ruby world, for those of you think HtDC is Java biased? Actually, many good ruby books are adapted from the Java land.
A side note: To many rubyists' surprise, Matz is not a language-biased guy who would like to start a language war.
But. Fundamentally, designing classes upfront is simply the wrong way to go about it. The argument may be made that the end result (I now know what good classes look like) justifies the method, but I disagree. It is the journey that is important, not the result. The students will not remember what a good jogging journal class hierarchy is. They will remember how to design classes on paper. In my experience, classes hierarchies written on paper or on fancy UML software, are bound to be "wrong". This is a Bad Thing.
UPDATE: In fact, any tutorial about how to design classes that does not describe an iterative process, and make use of all the refactorings built into Eclipse or IntelliJ, is guaranteed to fail to teach kids what I do every day I program java (or C#).
This book is rather naive. It starts with a quote by, the inventor of Smalltalk, Alan Kay. The book focuses on Java. Smalltalk is a message-passing language. Java is a method-calling language. A book about object-oriented programming that doesn't distinguish between message-passing and method-calling fails to express how languages like Ruby and Objective-C work.
I think if I were going to design a book or course in object-oriented programming I would either approach top-down using a dynamic language or bottom-up with C. In the top-down version I would focus on the advantages of OOP as a discipline and why seemingly arbitrary restrictions really are useful (not just some hand-waving about static type checking) Going the other way, I'd have them write method dispatchers and basically implement classes without the features of modern object-oriented languages and then discuss OO languages in terms of the features they provide to simplify that style.