《Structure and Interpretation of Computer Programs》lecture 18 webhan.pdf_大学文库

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 14. 4 Slide 14.4.1 Cleaning up some details of our implementation So we have seen a first pass at building an object-oriented tem, using Scheme as the base. There are a few details that The need for self-reference we still need to clean up however. These include what to do if a.Dealing withtags'" class does not have a method to handle some request, the need to be able to refer to the object within methods belong to an object (i.e. an ability to recursively use methods of an object within an object), and the need to identify types of objects Detection of methods (or missing methods) Slide 14. 4.2 Use (no-method) to indicate that there is no method What happens if the object doesnt know how to handle a ( define n。- method message? We need a way to detect if we actually have a method (lot ((tag (list No-METHOD))) available To do this, we first need a kind of tagged system that will tell us when we have no method but remem ber our convention anytime we ask an object for something, it should return a procedure. Thus our way of saying no method exists also needs to be a procedure, as shown with no-method, a procedure of no arguments with access to a local frame enclosing a specia Slide 14. 4.3 Detection of methods(or missing methods) Then, to check if we have a method we take an object, such as Use (no-method) to indicate that there is no method might be returned by as k and we do the following: First, is the define n。- method argument a procedure? If it is, we assume it is a method, and we proceed. If it is not, we check to see if the value passed in is a no lambda ( tag))) method. We do this by applying no-method to get out. Check if something is a method the tag, then checking to see if the argument is eg? to it. If it is, (define (nethod? x) then we return false to indicate that no method exists for this eq?x(n。- nethod) object and message. Otherwise, we signal an error. else So why go through all of this? We need to distinguish between (err。r" Obect returned non- mes sage”x))) an error in our implementation and an error in trying to get an instance to handle a message it doesn t know about This lets us separate the details of the implementation from use of the implementation

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14. 4 Limitation- self-reference We have now seen an example of creating a class definition, (one of these maker- procedures), and we have seen an example of using that class definition to create a particular nstance(in this case a person). We have also seen how to separate out getting methods from actually invoking those methods to execute an action. And we have seen how to build a generic interface to the objects, so that we uniformly ask any object to do anything Slide 14.4.5 Limitation - self-reference So now we can use this. We can ask g to say "The sky is blue askq"sr·( the sk with the behavior shown nuf-said We can also ask the object its name, and we can ask the object (ask g 'CHANGE- NAME 'ishmael change its name. as shown. But in this latter case. it would be want g to""his nice if we could get the object to"say"its new name whenever it. We want a person to call its own method, but hanged its name. So doing the mutation to change the variable binding is easy. But how do we get a person to use it's own one of its methods, ask itself to do something(e.g. SAnP7 method that is, how do we get a person to recursively, with Limitation-self-reference Slide 14. 4.6 (ask g 'sAY t(the sky is blue)) Well, we have a problem here. In particular, we don 't have insic the code of this object any access to the object itself. We have ing that points to the procedure representing the object want g to SAY his new name whenever it changes which would allow us to "ask"it to do something We want a person to call its own method, but Problem: no access to the object"from inside itself Slide 14.4.7 Limitation- self-reference What we need is an explicit reference to the object itself. Our way of doing this is to add an explicit argument(called self) the sk as blue to all our methods. The goal in doing this is to allow us to have coat o mnmg sx he m hertha something within a method, it can ask itself to get other method We want a person to call its own method, but to do execute other actions Problem: no access to the" object"from inside itself! Solution: add explicit self argument to all methods

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.4. 8 Better Method Convention (1)-self So here is the first change needed to make this happen. In our (detine class definition, we ensure that each method has a self rgument as its first argument, by convention (( WHOJREYOU?)(1 ambda《se1f)nam。) (lambda (self new-name)(set! Ename new-name)) (lambda (self list-of-stuff) 《dsp1a一曲ag。1nt-o-tufe UF-sND》) Slide 14 4.9 Better Method Convention(1)--self The second modification is within the CHaNge-naMe method We want the object to ask itself to say its new Thus, we ask the self object to handle a SAY mes WHOAREYOU?)(lambda (self) Ename)) (CHANGE-NAME) Notice that this should then ask the same procedure, the (lambda (selt new-name) procedure representing the object, to handle this new message, which should in turn return a new method for doing exactly that (k1EAx4时11m20m)) (lambda (self list-of-stuEE) e1se(n。- method))))) Better Method Convention(2)--ask Slide 14,4.10 Of course we will also need to modify as k. This is easy since (let ((nethod n命a9 object))) we just need to explicitly include the object as an argument when (apply nethod object args) applying the method, since each method expects an object in that r No nethod for nes gage" message) place in its argument list. Notice an important design issue here By separating out a s k from other parts of the system, and especially separating out the idea of getting a method from the idea of applying it, we have made it easier to incorporat changes such as this one Slide 14.4.11 Better Method Convention(2)--as So how does this change give us more capabilities in our system,I(define (ask object message. arga) especially our ability to ask an object to do something within the (let((method(get-method message object:))2 context of another method? Suppose we evaluate (ask g (if (method? metH apply nethod object arg CHANGE-NAME ishmael). This will first get the aLor"。 nethod￡ox m9)))) method for changing names from g. That returned procedure is task g'CHAISE-RANMBE shaly then applied to the object that corresponds to g (i.e. the value bound to g in this environment)and the argument ishmael This will first mutate the binding for fname in this environment, from george to ishmael. And then it will ask this object; the value associated with g or more particularly

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.4.19 Thus, we have seen how to create (in Scheme)a system for Summary describing simple object-oriented frameworks. The system includes a means of defining classes, a means of creating instances of those classes, and ways of referring to instances of Tagging object classes classes, including oneself. Using environments and procedures to capture and chang provide methods that can access and change the state or eo We have seen how we can use the idea of an environment to capture local state, and to use procedures created on demand to instances of classes In the next lecture, we will turn to more complex ways of creating and using classes, especially the issues of inheritance and delegation 6.001 Notes: Section 14.5 Slide 14.5.1 Steps toward our Scheme OOPs In the last part of this set of lectures, we looked at the basic elements of object-oriented programming. We examined the 1. Basic Objects A. messages and methods covention role of objects as a paradigm for structuring systems, and we saw B. self variable to refer to oneself how we could use our knowledge of scheme to construct a framework for building classes and instances in an object 2. Inheritance e A internal superclass instances, and oriented system B. match method directly in object, or get-method from So where are we? We have established ways of creating classes C delegation: explicitly use methods from intemal objects and instances in our object oriented system, as well as conventions for dealing with messages and methods, and 3. Multiple Inheritance conventions for allowing objects to refer to themselves to support methods calling other method Now we want to look at using these ideas to explore the idea of inheritance. Recall that inheritance meant having the ability to create subclasses of objects, or specialized classes of objects, which could inherit behaviors from the superclass of objects. The goal was to have different specializations of a general class so that the common methods between specializations could be captured in the superclass, and the variations of unique methods could be isolated within subclasses hy inheritance? Slide 14.5.2 Now why would we want the ability to inherit, within a olation of shared values in single variable maintains hierarchy of classes? First, by isolating a shared value in a single variable, we make it easier to maintain consistency of are basic units of programming. By allowing values. In other words, we avoid having multiple versions of the same variable, and thus isolate changes in that variable to a single location Second, under this new view of programming, classes become our basic units of code construction. As a consequence, we would like to enforce modularity as much as possible on classes and by enabling the construction of hierarchies of classes, in which a subclass can inherit methods (as well as variables) from

6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 14.4.19 Thus, we have seen how to create (in Scheme) a system for describing simple object-oriented frameworks. The system includes a means of defining classes, a means of creating instances of those classes, and ways of referring to instances of classes, including oneself. We have seen how we can use the idea of an environment to capture local state, and to use procedures created on demand to provide methods that can access and change the state of instances of classes. In the next lecture, we will turn to more complex ways of creating and using classes, especially the issues of inheritance and delegation. 6.001 Notes: Section 14.5 Slide 14.5.1 In the last part of this set of lectures, we looked at the basic elements of object-oriented programming. We examined the role of objects as a paradigm for structuring systems, and we saw how we could use our knowledge of Scheme to construct a framework for building classes and instances in an objectoriented system. So where are we? We have established ways of creating classes and instances in our object oriented system, as well as conventions for dealing with messages and methods, and conventions for allowing objects to refer to themselves to support methods calling other methods. Now we want to look at using these ideas to explore the idea of inheritance. Recall that inheritance meant having the ability to create subclasses of objects, or specialized classes of objects, which could inherit behaviors from the superclass of objects. The goal was to have different specializations of a general class so that the common methods between specializations could be captured in the superclass, and the variations of unique methods could be isolated within subclasses. Slide 14.5.2 Now why would we want the ability to inherit, within a hierarchy of classes? First, by isolating a shared value in a single variable, we make it easier to maintain consistency of values. In other words, we avoid having multiple versions of the same variable, and thus isolate changes in that variable to a single location. Second, under this new view of programming, classes become our basic units of code construction. As a consequence, we would like to enforce modularity as much as possible on classes, and by enabling the construction of hierarchies of classes, in which a subclass can inherit methods (as well as variables) from

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology superclass instances, we ensure consistency of behavior and isolate changes to a single method Slide 14.5.3 Example World: Professor Subclass Let's extend our current example to look at this issue. We already Viage have a class, called a person. We can create a subclass of A professor prefaces all lecture person, called a professor. A professor, because it is a kind of material with"Therefore person, has the same capabilities as a person. It has an internal variable for its names; it has methods for returning its name, for PROFESSOR changing its name, and for saying things. However, a professor has a unique capability, different from normal people. When a professor is"lecturing", it prefaces all said material with the word"Therefore. Thus it has a new method. LECTURE which does that Example World: Professor Subclass Slide 14.5. 4 Therefore"the behavior we expect is the following: If we define A professor prefaces all lecture material with "Therefore e in the global environment to be an instance of a professor (define e(nake-protessor erie rimson)) using a make- procedure that we will discuss shortly, then we aske“ AHIOARE YONI? Professor grimson can ask e to SaY things. In this case, it behaves just like a person, as it inherits the SAY method from its superclass ask e 'SAY (the sky is blue) the sky is blue If we ask e its name we get a different behavior from a normal 2 uuf-said person, which suggests that we will need a new method that (ask eLECTURE '(the sky ig blue) therefore the sky is blue shadows the persons method --)nuf-lectured I Finally, we can ask e to LECTURE about the chromaticity of the atmosphere. In that case, e as a professor should use the LECTURE method. This will, as a consequence, say therefore the sky is blue So we see that this object e should both have the ability to use methods specific to a professor and the ability to inherit methods from an underlying person Slide 14.5.5 2. Approach: Inheriting Superclass Methods Here is the approach we will take to make this happen. In Subclass will Inherit superclass behavior by adding an particular, we are going to allow the inheritance of methods from"interna profe or wl have an intemal per son object superclasses to subclasses, by within each subclass creating an If message is not recognized, pass the buc internal instance of a superclass. In other words, a professor will have within it an internal instance of a person. Then, if message is passed to the professor, the professor will first see if it has an explicit method for that message. If so, it does its thing If not, it"passes the buck"to the internal person instance, asking it to handle this message

6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. superclass instances, we ensure consistency of behavior and isolate changes to a single method. Slide 14.5.3 Let's extend our current example to look at this issue. We already have a class, called a person. We can create a subclass of person, called a professor. A professor, because it is a kind of person, has the same capabilities as a person. It has an internal variable for its names; it has methods for returning its name, for changing its name, and for saying things. However, a professor has a unique capability, different from normal people. When a professor is "lecturing", it prefaces all said material with the word "Therefore". Thus it has a new method, LECTURE, which does that. Slide 14.5.4 "Therefore" the behavior we expect is the following: If we define e in the global environment to be an instance of a professor, using a make- procedure that we will discuss shortly, then we can ask e to SAY things. In this case, it behaves just like a person, as it inherits the SAY method from its superclass. If we ask e its name, we get a different behavior from a normal person, which suggests that we will need a new method that shadows the person’s method. Finally, we can ask e to LECTURE about the chromaticity of the atmosphere. In that case, e as a professor should use the LECTURE method. This will, as a consequence, say therefore the sky is blue. So we see that this object e should both have the ability to use methods specific to a professor and the ability to inherit methods from an underlying person. Slide 14.5.5 Here is the approach we will take to make this happen. In particular, we are going to allow the inheritance of methods from superclasses to subclasses, by within each subclass creating an internal instance of a superclass. In other words, a professor will have within it an internal instance of a person. Then, if a message is passed to the professor, the professor will first see if it has an explicit method for that message. If so, it does its thing. If not, it "passes the buck" to the internal person instance, asking it to handle this message

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.5.6 2. Approach: Inheriting Superclass Methods Using that idea, we can then build a make- procedure for Subclass will Inherit superclass behavior by adding an professors, that is, we can implement the class definition of message is not recognized, pass the buci professors. Recall that it is going to be a subclass, which is going subclass to inherit from persons. Note how the constructor works.It et(nt person(make-person name inam )))/ superclass creates an internal person, i.e., it literally calls the make i new method procedure for persons and creates a binding for int (ambda (self) erson to that internal instance. It then returns an object that display-message (list 'Professor lname)) Inane ))tho erra iteron represents an instance of this class. As before, it is a message passing procedure. Here, it has one thing it explicitly knows how I to do: to LECTURE. Otherwise, it gets the method for the message from its internal instance of a person. This means it literally passes "the buck"back to the internal person, saying"You figure out how to handle this message and return a method for me Notice the form used. This object satisfies our convention, as it will return a method (or procedure) for all messages But the default, rather than saying there is no method, is to ask the superclass instance to handle things. Thus, if we ask e to SaY something, since e is a professor it will first look for an explicit SAY method, and then deducing it doesn' t have one, it will ask its internal person to say. This will, as we saw in the earlier slides then return a method for saying things, and apply it Slide 14.5.7 How the internal object works So lets trace this through. We will suppress some of the details of the environment model, so that we can see the general flow of computation Defining e to be a professor using the appropriate make procedure should have the following behavior ed by application ect1s1t一吧报0 object writh an Internal eton inside) How the internal object works Slide 14.5.8 rwke-person: First, applying ma ke-professor will drop a frame in which the variable fname is bound to the symbol eric and the variable lname bound to the symbol Grimson Thus, frame El is created by the application of ma ke professor mMH1Hmp油tmam1m1

6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.5.12 How the internal object works In particular, e in the global environment points to a structure: a professor object (the thing enclosed in blue), which is a procedure with access to local frames. within that object, there is an object, an internal person(the thing enclosed in red). Notice that it is referred to by a local variable that points to one of these structures: a message-passing object that has access to some local frames Thus. we have an internal instance within another 二日灬签:=二二二二 instance, and this will support the idea of inheritance tands makr-presteasan All we have to do is specify how the top-level object will pass 细邮#H=m1…mm如,| along requests for methods to the internal object Slide 14.5. 13 How the internal object works First, suppose we ask this object to identify itself. In this case, the process of"ask ing will eventually cause the system to apply the object e to the message whoareyou? Because the rofessor class has an explicit method for handling this message, it will create a procedure relative to this frame. And since this frame is scoped by the frames created during the construction of the object, the procedure will have access to the internal variables, and can thus identify the object for us ok e " SHOP m过13如( Et wath as iternal person inside How the internal object works Slide 14.5.14 But suppose we ask this object to say something. In this case, the process of ask ing will again cause the system to apply the object e to the message say. Because the professor class does not have an explicit method for handling this message, it (Case will try to inherit a method from its internal person ob professor oh)ect cirith an Internal pereon indol Slide 14.5. 15 How the internal object works This means that the same message will be sent to the object that corresponds to the internal instance of the superclass. As a consequence, we will create a method for handling this request with respect to this frame, and then proceed Thus we see that an object can inherit methods from internal consequence, if we decide to change how a class handles a method, we need only do it in the definition of that class and the changed behavior will then be automatically inherited by subclasses d sold object is our new professor abject (nith an internal person inmhdey

6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 14.5.12 In particular, e in the global environment points to a structure: a professor object (the thing enclosed in blue), which is a procedure with access to local frames. Within that object, there is an object, an internal person (the thing enclosed in red). Notice that it is referred to by a local variable that points to one of these structures: a message-passing object that has access to some local frames. Thus, we have an internal instance within another instance, and this will support the idea of inheritance. All we have to do is specify how the top-level object will pass along requests for methods to the internal object. Slide 14.5.13 First, suppose we ask this object to identify itself. In this case, the process of “ask”ing will eventually cause the system to apply the object e to the message whoareyou? Because the professor class has an explicit method for handling this message, it will create a procedure relative to this frame. And since this frame is scoped by the frames created during the construction of the object, the procedure will have access to the internal variables, and can thus identify the object for us. Slide 14.5.14 But suppose we ask this object to say something. In this case, the process of “ask”ing will again cause the system to apply the object e to the message say. Because the professor class does not have an explicit method for handling this message, it will try to inherit a method from its internal person object. Slide 14.5.15 This means that the same message will be sent to the object that corresponds to the internal instance of the superclass. As a consequence, we will create a method for handling this request with respect to this frame, and then proceed. Thus we see that an object can inherit methods from internal instances of superclasses. As a consequence, if we decide to change how a class handles a method, we need only do it in the definition of that class, and the changed behavior will then be automatically inherited by subclasses