6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.3. 4 Steps toward our Scheme OOPs So here is the blueprint we are going to use throughout the rest 1. Basic Objects of this lecture. We will start by building basic objects, A. messages and methods convention B. self variable to refer to oneself determining the methods we need and the conventions for dealing with such methods. We will see why we need a 2. Inheritance particular way of getting a handle on the object itself as ar al superclass instances, and method directly in object, or get-method from argument to methods, as we will see in a set of examples B We will then turn to the notion of inheritance. how to build an C. delegation: explicitly use methods from intemal objects internal superclass, and then deal with getting methods from that 3. Multiple Inheritance object itself or from internal instances of superclasses. We will see that there are variations on inheritance that become important I when designing object-oriented systems Finally, we will turn to the notion of multiple inheritance, having objects that can inherit methods from different kinds of superclasses So we are going to use this blueprint both to build an object oriented system in Scheme, and to see how such ideas can be used in general to design systems around the concepts of objects as a tool for controlling complexity in large systems Slide 14.3.5 Today's Example World: People, Professors We are going to develop these ideas using the particular example Arrogant-profs, and Students we developed previously, with a world of people professors PERSON arrogant-profs and students. As we progress, we will see how these classes relate to one another in terms of superclasses and inheritance of methods To start. we design a first class. This means creating a cl diagram, and we will start with the simplest thing: a person Here is the definition for the person class. It has two internal variables, an fname and an lname. It also has some methods that it can handle: returning its name, and saying things< (since that is what a person"does") 1. Method convention Slide 14.3.6 The response to every message is a method Now we are ready to implement our first class. Remember we A method is a procedure that can be applied to actually do the work said our class will be characterized as a procedure which, when (define (make-porson fname Iname) species he person class invoked. will construct instances of the class Here is our make bda(》 trame) person procedure, which defines our person class ((eq? message CHANGE-MY-NRME) To set this up, we have to make some design choices. Remember that instances of a class do different kinds of things. It may (lambda (1ist-of-stuff) l1splay-nessage lIst-or-stutn simply want to return some information, e.g. its name. It may 锅AT) want to change internal information, e.g. change the name. Thus alse (no-nethod))))) ve need methods that return information and methods that change information, and here is our design choice. We are going to require the response of an instance to every message to be a method. This is simply a choice on our part, though we believe it will be a convenient one as we add capabilities to our system. Note that it says we can't just return a value, we return procedures, the application of which may then return a valu6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 14.3.4 So here is the blueprint we are going to use throughout the rest of this lecture. We will start by building basic objects, determining the methods we need and the conventions for dealing with such methods. We will see why we need a particular way of getting a handle on the object itself as an argument to methods, as we will see in a set of examples. We will then turn to the notion of inheritance, how to build an internal superclass, and then deal with getting methods from that object itself or from internal instances of superclasses. We will see that there are variations on inheritance that become important when designing object-oriented systems. Finally, we will turn to the notion of multiple inheritance, having objects that can inherit methods from different kinds of superclasses. So we are going to use this blueprint both to build an object oriented system in Scheme, and to see how such ideas can be used in general to design systems around the concepts of objects as a tool for controlling complexity in large systems. Slide 14.3.5 We are going to develop these ideas using the particular example we developed previously, with a world of people, professors, arrogant-profs and students. As we progress, we will see how these classes relate to one another in terms of superclasses and inheritance of methods. To start, we design a first class. This means creating a class diagram, and we will start with the simplest thing: a person. Here is the definition for the person class. It has two internal variables: an fname and an lname. It also has some methods that it can handle: returning its name, and saying things (since that is what a person "does"). Slide 14.3.6 Now we are ready to implement our first class. Remember we said our class will be characterized as a procedure which, when invoked, will construct instances of the class. Here is our make￾person procedure, which defines our person class. To set this up, we have to make some design choices. Remember that instances of a class do different kinds of things. It may simply want to return some information, e.g. its name. It may want to change internal information, e.g. change the name. Thus we need methods that return information and methods that change information, and here is our design choice. We are going to require the response of an instance to every message to be a method. This is simply a choice on our part, though we believe it will be a convenient one as we add capabilities to our system. Note that it says we can't just return a value; we return procedures, the application of which may then return a value