6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.2.6 An initial class hierarchy Now, lets add another new class as a subclass of professor, this I PERSON define ap-I tmake-arrog mtor ed nfalliMte) one called an arrogant-prof. An arrogant-prof is distinguished by the fact that he ends everything he says with WHOAREYou - niee weather we are having.obviously The obvious(sorry!) way to do this is to have the arrogant profs method of saying simply be a delegation of saying to its PROFESSOR superclass(professor), with obviously tacked onto the end Note that we delegate one step up the superclass chain because LECTURE that is the only way arrogant-prof can eventually get to the person. The ar a pointer to its imme superclass, but not to superclasses higher in the chain. B I delegating one step up the chain, the ordinary inheritance mechanism will take over when the system determines that the professor doesn t have a say method of its own Slide 14.2.7 An initial class hierarchy Now an interesting issue arises if we ask an arrogant-prof to lecture. What should he say? One view is that, because PERSON (define ap-1 (make-arrag antpraf'Bed'Infallible) arrogant-prof has no lecture method, lecture'ing will be ask ap-1 ' LECTURE Inice weather we are havin)) handled by the method in the professor class, which in turn will WHOAREYOU? delegate to person after tacking on a" therefore". The result will LECTURE ARROGANT An initial class hierarchy Slide 14.28 But another view says that arrogant- prof inherits the lecture [PERSON defie ap-l (make -ar eg mtofBed'Infau he) method from professor, so conceptually the lecture method is are having) sitting there in the arrogant-prof class. As a result, the lecture OAREYou?+ Therefore,nie method should give arrogant-prof a chance to see whether it knows how to say something, rather than instantly delegating to a say method found up the superclass chain. And of course, arrogant-prof does know how to say something; it has a say method, one that should shadow the say method of a person As a result, asking an arrogant-prof to lecture, under this view, should result in the following sequence of events cant find a lecture method in arrogant-prof class; use the method from the superclass, professor the lecture method from professor asks the current instance(an arrogant-prof) to say the original stuff, with"" prepended to the front. Note what has changed and what hasnt under this view Lectureing is still saying something with"therefore"on the front, but now we are asking the current instance, an arrogant-prof, to do the saying, instead of handing it up the superclass chain the arrogant-prof has a say method, which works by adding obviously to the end of the statement and finally, delegating the resulting statement up the inheritance chain to the next say method that can be found(which turns out to be in the person class) The result is as shown a key issue, we will then see, is to decide as we build our object oriented system, how we want methods to inherit from other methods. Ideally we will want the ability to choose as a programmer, when we decide on our classes of
6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 14.2.6 Now, let’s add another new class as a subclass of professor, this one called an arrogant-prof. An arrogant-prof is distinguished by the fact that he ends everything he says with “obviously”. The obvious (sorry!) way to do this is to have the arrogantprof’s method of saying simply be a delegation of saying to its superclass (professor), with obviously tacked onto the end. Note that we delegate one step up the superclass chain because that is the only way arrogant-prof can eventually “get to” the person. The arrogant-prof has a pointer to its immediate superclass, but not to superclasses higher in the chain. By delegating one step up the chain, the ordinary inheritance mechanism will take over when the system determines that the professor doesn’t have a say method of its own. Slide 14.2.7 Now an interesting issue arises if we ask an arrogant-prof to lecture. What should he say? One view is that, because arrogant-prof has no lecture method, lecture’ing will be handled by the method in the professor class, which in turn will delegate to person after tacking on a “therefore”. The result will be as shown. Slide 14.2.8 But another view says that arrogant-prof inherits the lecture method from professor, so conceptually the lecture method is sitting there in the arrogant-prof class. As a result, the lecture method should give arrogant-prof a chance to see whether it knows how to say something, rather than instantly delegating to a say method found up the superclass chain. And of course, arrogant-prof does know how to say something; it has a say method, one that should shadow the say method of a person. As a result, asking an arrogant-prof to lecture, under this view, should result in the following sequence of events: • can’t find a lecture method in arrogant-prof class; use the method from the superclass, professor • the lecture method from professor asks the current instance (an arrogant-prof) to say the original stuff, with “therefore” prepended to the front. Note what has changed and what hasn’t under this view: Lectureing is still saying something with “therefore” on the front, but now we are asking the current instance, an arrogant-prof, to do the saying, instead of handing it up the superclass chain. • the arrogant-prof has a say method, which works by adding “obviously” to the end of the statement, and finally, delegating the resulting statement up the inheritance chain to the next say method that can be found (which turns out to be in the person class). The result is as shown. A key issue, we will then see, is to decide as we build our object oriented system, how we want methods to inherit from other methods. Ideally we will want the ability to choose as a programmer, when we decide on our classes of
6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology objects, whether we want to delegate behaviors to specific superclasses, or to simply inherit behaviors by following up the chain of classes Slide 14.2.9 An initial class hierarchy Now lets add one final type of object to our system, a student. (define stud (make student "bert sesame)) tudents are al ways very polite, so they have their own say method, which prepends the words"Excuse me, but to the front ask stud SA not understand)) of everything they say. WHOAREYOU?)Exeuse me, bu An initial class hierarchy Slide 14.2.10 Now suppose we go back to our class diagram, and decide to PERSON tnam。 modify our classes. For example, we want students to have the ability to ask a question of a professor. And of course, we need to add the ability for a professor to answer which we choose do within the arrogant-prof class. But we also decide that occasionally even a professor might have the need to ask a question In terms of our object system, this simply would require redefining whatever mechanism we use to create instances. so that a new method is included in that class definition Slide 14211 An initial class hierarch Note that in this case, we want our objects to take several (ask std'question why does this rode work) arguments, in particular, both the question and the object to PERSON→ hoeld be obvious t which the question is being directed. Also note the use of ap-1 as an argument, meaning we want the actual instance, not just the name of that instance We still have to define how we want the arrogant-prof to PROFESSOR STUDENT respond. We choose to incorporate the following behavior. If the OUESTION question is being asked by a student, then the arrogant-prof will respond by saying this should be obvious to you ARROGANT-P ANSWER
6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. objects, whether we want to delegate behaviors to specific superclasses, or to simply inherit behaviors by following up the chain of classes. Slide 14.2.9 Now let’s add one final type of object to our system, a student. Students are always very polite, so they have their own say method, which prepends the words “Excuse me, but” to the front of everything they say. Slide 14.2.10 Now suppose we go back to our class diagram, and decide to modify our classes. For example, we want students to have the ability to ask a question of a professor. And of course, we need to add the ability for a professor to answer, which we choose to do within the arrogant-prof class. But we also decide that occasionally even a professor might have the need to ask a question. In terms of our object system, this simply would require redefining whatever mechanism we use to create classes and instances, so that a new method is included in that class definition. Slide 14.2.11 Note that in this case, we want our objects to take several arguments, in particular, both the question and the object to which the question is being directed. Also note the use of ap-1 as an argument, meaning we want the actual instance, not just the name of that instance. We still have to define how we want the arrogant-prof to respond. We choose to incorporate the following behavior. If the question is being asked by a student, then the arrogant-prof will respond by saying “this should be obvious to you