

How to Design Classes (in Ruby, Python, Java or any OOP) - Open-Juicer
http://www.ccs.neu.edu/home/matthias/htdc.html

======
Goladus
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.

~~~
mcantor
I shamelessly clicked away as soon as I realized it was Java. Well, not
completely shamelessly. I kind of feel like a "rassa-frackin' whippersnapper"
disgustedly changing the radio station when stumbling on classical orchestral
music.

Then again I also feel a little dirty for comparing the likes of Tchaikovsky
and Beethoven to Java...

~~~
hxa7241
No, this is quite right. Classical music is as bloated, heavy-handed, and
decadent as Java. Good music is found in the 16th century and earlier, and in
the 20th century and later. We can see this maps to software: good ideas are
to be found in the 70s and earlier, and in some hoped-for new era yet to come
. . .

~~~
Goladus
Check out Haydn's "Lord Nelson" mass, specifically the recording by Banchetto
Musicale (it's very light and clear). For the antithesis of heavy-handedness,
pay attention to movements 2, 4, 5, 7, and 12. But the whole thing is only
about 40 minutes and really easy enjoy start to finish, especially since those
movements I mentioned are meant to contrast with the slower ones.

Movement 5, while not my favorite, is especially notable for being a canon at
the 5th. It's quick, fun, the imitative counterpoint is very easy to hear, and
at a minute-forty, hardly overstays its welcome.

Overall though, Western music between Bach's death in 1750 and Beethoven was
anything BUT bloated and heavy-handed. Balance, taste, and clarity were highly
valued.

------
pkaler
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.

~~~
Goladus
Excellent point. I think that more generally, as it relates to what a student
might be interested in, it fails to address the fundamental question "why am I
learning this?"

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.

------
tylerneylon
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.

------
buff-a
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#).

------
aliukani
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.

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

~~~
Open-Juicer
Eloquent Ruby is the design book to read.

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.

------
bpierre
666 pages.

------
nhannah
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).

