How to Design Classes (in Ruby, Python, Java or any OOP) (opens in new tab)

This looks like a great book, but I'm not sure it really represents a good way to learn how to design classes in Ruby or Python. It seems heavily biased towards designing classes in a statically-typed, non-type-inferring, java-style language. Programming in Python is a lot more about knowing when defining a new class (rather than using built-in types and classes) even a good idea to begin with.

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 found this to be a great (ruby based) design book. Ruby best practices by Gregory Brown (free download http://rubybestpractices.com/)

This book is too long for the subject it purports to impart.

Good coding is not a craft of many secrets; rather it is an art of a few core principles. Mastering them is a matter of direct experience. I believe a good book can point a programmer in the right general direction, but it is up to her to go the distance.

Compared to bicycles and shapes, this book is a step in the right^H^H^H a different direction in that it is data-oriented rather than object-oriented. Rather than make the claim (as they do in the introduction) that other textbooks are doing it wrong, I would have prefered to see acknowledgment that different tasks call for different approaches, and highlight that the data-oriented design presented here is usually left out of other texts. Giving examples, as they do, of tasks where the goal is simply to store and present data, it is only natural that a data-oriented design is what shows up. That does not mean that there are not programs whose job is to act on and manipulate data.

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 is the textbook for one of my classes at Northeastern. The prerequisite class used HtDP (http://www.ccs.neu.edu/home/matthias/HtDP2e/) and Racket (http://racket-lang.org/), and the focus was on design principles and writing good code more than it was on the actual language we were using. I'm expecting the same from this class, but I'm not against becoming more experienced with Java either.

666 pages.

Nice to see NEU on here, they are big Scheme fans there I know so I don't know how much Ruby it will relate to. Python is used in some classes as well I believe (I was an ME major with friends in CS).