MIT 6.001 Structure and Interpretation of Computer Programs, Spring 2005
At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
I don't think i understand your question. But will try to reply how I have understood. I know it is a long read, but i hope this answers your question. however if you have anything else to ask, feel free to drop in a question(s). best of luck! You, first, need to review the question 'what is data?' which has been discussed in detail in more than one parts of the book (SICP) elaborating it step by step. We first discovered that numbers and text are data. Then we found out that the procedures we define are data as well: precisely EVERYTHING is data. Procedures can also be passed as arguments to other procedures. Precisely, we were introduced to lambdas. Lambdas/procedures are also data and they can be passed as arguments to other lambdas/procedures. After that we talked about building more complex objects which were precisely lambdas but we had additional data encapsulated within them. So, we first learned about 'dispatch procedures' and 'message passing'. The basic idea was you pass a message to an object and in return it performs according to the message you have passed to it. Below is an example (haven't run it on my PC so there could be some issue with the syntax, but looks fine to my eye): (define (calc number) (define error "undefined command") (lambda (message) (cond ((= message 'SQUARE) (* number number)) ((= message 'SQRT) (sqrt number)) ((= message 'DOUBLE) (* 2 number)) (else error) ) ) ) now, (define x (calc 4)) After this we can use it as, >(x 'DOUBLE) 8 >(x 'SQUARE) 16 >(x 'SQRT) 2 >(x 'HIPHOP) undefined command So, the basic idea is that first out procedures could just do one job. Now, by the technique of message passing, we can get one lambda expression/procedure to perform multiple tasks depending on the message passed to it. Such procedures are called dispatch procedures. (Which makes normal procedures also dispatch procedures which can perform just one job). So, how to model objects using Object Oriented Programming (OOP)? (That was your original question)... We used the idea of dispatch procedures. Adding in as much functionality as we may want. And then passing on an appropriate message to that object (which is a lambda expression) to do the required task. There are then other technicalities when we want to implement a bug free interface where different kinds object can interact with each other and relate to each other. So, then we were introduced to another technical term 'inheritance'. The implementation of this in this course is manual, unlike in courses in other languages which directly support OOP. Scheme doesn't directly support OOP, so we had to manually create the link from one type of an object/class to another type of an object/class. So, the general idea is if i am a human. I can be a professor or i can't be. If i am a professor, I can have a nice voice and or I cannot. So, if there is a professor object, it will have inside a human part and a singer part. So, if i asked a professor's object to sing, it will pass on that message to the singer part inside it. And this so called human-part or singer-part are stored inside the professor class/object as local variables (just like the local variable error in the above example).
Since you posted in the MIT 6.001 course, that's why I referred to SICP and Scheme.
First para after the code, first line: it's *our, not 'out'
When you design using OOP you must model the problem domain using entities called objects. This entities and their interactions solve the problem of the problem domain. The objects are compound by two parts: internal state and behavior. The internal state is encapsulated in the object itself and any other object can't see the internal state of other object directly. The objects comunicate between them sending messages and responding to messages of other objects. The set of messages that an object can respond to is called the object interface. The behavior of an object is defined in its interface. The only way to alter the internal state of an object is sending messages to the object. In the OOP model all is an object, so the messages itself are object too. Thus a program in OOP is a network of objects that interact each other sending messages to solve the problem of the problem domain. Of course that is an abstract model and its implementation depends of the programming language. Even in Smalltalk, the OOP language par excellence, not all is an object. Is important to distinguish the model from its implementation. For example, in Java exists the classes that are templates of objects used by the class loader to make runtime objects, but the concept of classes is not an OOP concept at all. This kind of things make OOP sometimes dificult to understand. The key is know the model and, again, distinguish the model from its implementation. I hope that help you to understand a little bit more about OOP, and sorry about my english because I'm not an english native speaker.