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