5 ms·

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 o

by rmenke 18y ago

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.

dood 18y ago
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_programming http://en.wikipedia.org/wiki/Smalltalk#Object-oriented_progr...
- jhancock 18y ago
  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.
- dr_strangelove 18y ago
  The language that fits this description best is Erlang, I would say ... (what, in this definition, is specific to objects compared to processes?)
  - davidw 18y ago
    In smalltalk everything is an object. In Erlang, many things aren't. Processes and messages are a bit higher up in Erlang's world.
Spyckie 18y ago
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.

by rmenke 18y ago

dood 18y ago

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_programming http://en.wikipedia.org/wiki/Smalltalk#Object-oriented_progr...

jhancock 18y ago
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.
dr_strangelove 18y ago
The language that fits this description best is Erlang, I would say ... (what, in this definition, is specific to objects compared to processes?)
- davidw 18y ago
  In smalltalk everything is an object. In Erlang, many things aren't. Processes and messages are a bit higher up in Erlang's world.

Spyckie 18y ago

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.