Hacker News Reader

Comment by rmenke | Hacker News Reader

Think of it less as "Object-Oriented" and more as "Message-Oriented" and things become clear. Every object has a vocabulary of messages it can respond to. The only contract you have with the object is what it can do, not how it does it; therefore, the supplier of the object is free to implement algorithms as he sees fit. (60 words)

Bonus analogy:

The web itself is object-oriented. You ask a server to return a resource for a given URL; what server it is (Apache; IIS) and how the content is generated (static page; CGI; PHP) is unnecessary for the conversation.

View on HN

The smalltalk object system is a nice simple example:

    A Smalltalk object can do exactly three things:
    Hold state (references to other objects).
    Receive a message from itself or another object.
    In the course of processing a message, send messages to itself or another object.

http://en.wikipedia.org/wiki/Smalltalk#Object-oriented_progr...

Good definition. Smalltalk is the only appropriate starter language to learn objects well. Sure there is the difference between class based and prototype based languages, but this hardly matters compared to "getting" objects right in your head in the first place.

The language that fits this description best is Erlang, I would say ... (what, in this definition, is specific to objects compared to processes?)

In smalltalk everything is an object. In Erlang, many things aren't. Processes and messages are a bit higher up in Erlang's world.

Message-Oriented coding is also why commenting is so important. You don't need to know what's going on inside the method, but you do need to know what the method does, which is best accomplished through documentation.

O.O is useful to you because it makes it easier to understand your code, especially if your code base becomes very large. You can look at your code object by object rather than line by line.

O.O is useful for group projects because each member can code an object and the algorithms behind its methods individually. It also makes it easier to swap different functionality in and out.

Finally, O.O also promotes good coding practices, like reusing existing code and writing documentation. It also makes you think about your code's structure, which is crucial to keeping your code maintainable, upgradeable, readable, and reusable.

For me, writing good O.O code is a something that I learned after writing a lot of bad O.O code. So there's no reason to delay - write it and you'll see.

Reply on news.ycombinator.com