CS 1321

CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 27 November 29, 2001 Fall Semester

Today’s Menu 1.Inheritance

In Our Last Episode… In our last lecture, we began our exploration of the Object- Oriented Paradigm. In the Object-Oriented Paradigm, we create objects. These objects encapsulate a set of internal values (also known as fields) that a user can access and/or modify ONLY by going through a set of defined behaviors. In our last lecture, we created our first “object” in Scheme: a coke machine. After several iterations, we came up with the following structure for our object:

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT Vend (in-money) is-empty?how-manyreload init-machine (in-max) Here we see a simplified version of what we wanted our Scheme code to accomplish. We encapsulate 4 values within our coke-machine object.

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT Vend (in-money) is-empty?how-manyreload init-machine (in-max) The squares represent different behaviors that belong to our coke machine object. (The white square was a special method that was called only when creating new coke machines).

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT Outside code that utilizes our object is unable to gain access to and/or change those values directly… USERS!

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT …unless that code interfaces with one of the behaviors of the object. Thus we strictly define what our objects can and cannot do. is-empty? USERS!

Complexities in Scheme Once again, this code represented an idealized version of how our object should look. Scheme adds some additional complexities to how we actually go about implementing objects. We have to use the idea of lexical closures in order to emulate the effect of creating objects in Scheme. We went about doing this by creating a “service-manager” function that allowed the user to select the particular service (or behavior) that the user wanted to enact.

Service Manager (define (service-manager service) (cond ((symbol=? service 'is-empty?) is-empty?) ((symbol=? service 'how-many) how-many) ((symbol=? service 'reload) reload) ((symbol=? service 'vend) (lambda (n) (vend n))) (else (display "Invalid service")))) Here we can see the code of the service manager we used last time. Note that the user inputs a symbol representing the service he or she wishes to receive access to. The service manager function returns that portion of functionality to the user. Pictorially:

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT Service-manager (service) ‘is-empty?‘how-many‘vend‘reload The user sends the particular service he or she wants access to ‘vend

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT Service-manager (service) ‘is-empty?‘how-many‘vend‘reload The service manager allows the user access to that particular behavior by returning the lambda body from within our “object” Vend (in-money)

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT Service-manager (service) ‘is-empty?‘how-many‘vend‘reload At this point, should the user call the lambda body, passing it the appropriate parameters… Vend (in-money) (.65 )

Constants MAX-CANS COST Variables cans cash COKE-MACHINE OBJECT At which point, the behavior of the closure is logically as if we were doing something like the above. Vend (in-money).65

Ok… So now we have this idea of how to create definitions for objects. We define variables (or fields) specific to the object, a set of behaviors for the user to interact with that access/modify those variables, and (in Scheme) a service manager to allow us to select which behavior we wish to perform on the object’s data.

That’s great, but can you do this? Let’s try another one. Someone mentioned that serious college students, who spent all their evenings hacking at Scheme code, have moved beyond mere Coke to a beverage with much higher caffeine levels…coffee. Fortunately for our little enterprise, some kind (?) soul invented the coffee vending machine to dispense an 8 ounce cup of coffee for a quarter. Why don’t we go ahead and create a coffee machine object?

Coffee Vending Machines When you think about it, there’s really not an incredible amount of differences between a Coffee Vending Machine and a Coke Machine. They both dispense a certain quantity of their stock if the user enters in enough money. They both can be refilled. They both can tell the user if the machine has nothing left to sell.

Coffee Vending Machines Naturally, there are some differences. A coffee machine has a quantity of CUPS and a volume of COFFEE that it dispenses, rather than a single can. It also has this notion of internal temperature for the coffee. We really shouldn’t sell and coffee if it’s anything less than 210 degrees Fahrenheit. We should also report current temperature of the coffee to the user.

This shouldn’t be that bad… All we really have to do is tweak that coke-machine code just a tad. We’ll start off with our internal variables: (define coffee 0) (define cups 0) (define cash 0) (define heat 0) (define MAX-COFFEE 0) (define MAX-CUPS 0) (define COST.65) (define SERVE 210)

Coffee Machine: Initialization We need to be able to specify the maximum number of cups of coffee we should be able to dispense. Let’s say that we’ll just have the user input a number of cups and set our coffee level to 8 times that number (8 ounces of coffee to a cup): (define (init-machine in-max) (begin (set! MAX-CUPS in-max) (set! MAX-COFFEE ( * 8 in-max)) (set! cups MAX-CUPS) (set! coffee MAX-COFFEE) (set! heat SERVE)))

Coffee Machine: Reload Let’s set our coffee and cups back to their max values: (define (reload) (begin (set! cups MAX-CUPS) (set! coffee MAX-COFFEE)))

Coffee Machine: is-empty? Let’s test to see if we have any coffee and cups left: (define (is-empty?) (or (= 0 cups) (= 0 coffee))) Here, we assume a lack of either cups or coffee makes the machine unable to vend.

Coffee Machine: is-hot? We should have a function that tells us if the coffee is hot enough to serve up: (define (is-hot?) (>= heat SERVE))

Coffee Machine: add-heat So this function doesn’t really exist on coffee machines, but it would be nice if it did: (define (add-heat) (set! heat (+ heat 10)))

Coffee Machine: vend Once again, vend adds complexity to our little world. We’re going to take in an amount of money, make sure the user has enough money, make sure that we have enough coffee and cups, and make sure that we have coffee piping hot. Then and only then can we sell this person coffee. Oh, by the way, whenever we dispense coffee, we lose 3 degrees from our heat due to tachyon emissions or something.

(define (vend in-money) (cond ((is-empty?) (begin (display “Out of Service”) in-money)) ((not (is-hot?)) (begin (display “Too cold”) (add-heat) in-money)) ((< in-money COST) (begin (display “add more”) in-money)) (else …)))

(define (vend in-money) (cond … (else (begin (display “Have some Coffee”) (set! cash (+ cash COST)) (set! cups (- cups 1)) (set! coffee (- coffee 8)) (set! heat (- heat 3)) (- in-money COST)))))

Service Manager (define (service-manager service) (cond ((symbol=? service 'is-empty?) is-empty?) ((symbol=? service ‘is-hot?) is-hot?) ((symbol=? service 'reload) reload) ((symbol=? service 'vend) vend) (else (begin (display “BAD CHOICE”) (lambda () 0)))))

Put it all together… (define (make-coffee-machine max) (local ( (define coffee 0) (define cups 0) (define cash 0) (define heat 0) (define MAX-COFFEE 0) (define MAX-CUPS 0) (define COST.65) (define SERVE 210) (define (init-machine in-max) …) (define (reload) …) (define (is-empty?) …) (define (is-hot?) …) (define (add-heat) …) (define (vend in-money) …) ) …))

Put it all together… (define (make-coffee-machine max) (local (…) (begin (init-machine max) service-manager)))

And it all should work…

You know what? If we stop to think about it, that was a lot of duplication of effort. With the exception that a coffee machine kept track of cups and volume of liquid and its current heat, the functionality of a coffee machine is pretty much the same as the functionality of a coke machine. There were just a few minor tweaks we had to make, and a few minor functions we had to add to make the whole thing work.

Back in the Good Old Days Back in the days of functional programming, we saw a way around this whole debacle of duplicating a huge amount of effort in multiple functions by using the idea of ABSTRACTION to extract out the common features of our functions into a “master” function that our customized programs would make use of. The same idea exists in Object Oriented programming. But we’ve given it a different name…

Inheritance Object Oriented Programming is big on the idea of inheritance. Inheritance is the idea of creating a parent or root object definition that has a certain set of features and values. We then decide that we need to alter or extend that set of behaviors for a customized object definition. Rather than writing our basic set of features over and over again in each new object definition, we state that our new child object definitions INHERIT the parent’s features and definitions. We can then tweak and extend that inherited functionality to our hearts content.

Confused? Let’s look at our previous examples. What do coke machines and coffee machines have in common, and where do they differ?

Both machines contain an idea of stock of items we wish to sell: coke cans and cups of coffee. But coffee machines also keep track of a volume of coffee in the machine. Both machines have the ability to reload their stock to its maximum capacity. But coffee machines also refill the volume of liquid at the same time as the cups. Both machines have the ability to tell you if they are empty. But coke machines test only against their stock, where coffee machines also test their volume

Both machines have some sort of initialization routine that’s inaccessible to the user except during the actual creation process where we set our variables to their maximum. Coke machines can tell you how many cokes are left. Coffee machines can add heat to their coffee if they try to sell coffee that’s not hot enough. Both machines sell their stock by taking in money and checking it against COST But coffee machines deal with heat as well as stock and money

So what do we have in Common? A set of common features cash, stock, MAX-STOCK, COST A way to check if stock is empty A way to sell items based on money taken in and COST A way to reload our stock to MAX- STOCK An initialization methodology A service manager

So what would we have to change in a coke-machine? A set of common features cash, stock, MAX-STOCK, COST A way to check if stock is empty A way to sell items based on money taken in and COST A way to reload our stock to MAX- STOCK An initialization methodology A service manager We’d have to add the ability to check how many items there were in the machine.

So what would we have to change in a coffee-machine? A set of common features cash, stock, MAX-STOCK, COST A way to check if stock is empty A way to sell items based on money taken in and COST A way to reload our stock to MAX- STOCK An initialization methodology A service manager We’d have to add the ability to check and add heat Our vending method takes away volume and heat as well as stock (cups)

So what would we have to change in a coffee-machine? A set of common features cash, stock, MAX-STOCK, COST A way to check if stock is empty A way to sell items based on money taken in and COST A way to reload our stock to MAX- STOCK An initialization methodology A service manager We have to reload our volume as well as our stock

The Inheritance Point of View Vending Machine is-empty? vend (in-money)reload init-machine (in-max)

The Inheritance Point of View Vending Machine is-empty? vend (in-money)reload init-machine (in-max) Coke Machine how-many

The Inheritance Point of View Vending Machine is-empty? vend (in-money)reload init-machine (in-max) Coke Machine how-many The coke machine inherits the functionality of a vending machine, but also adds new functionality as well.

The Inheritance Point of View Vending Machine is-empty? vend (in-money)reload init-machine (in-max) Coffee Machine is-hot? is-empty? vend (in-money) reload init-machine (in-max)

The Inheritance Point of View Vending Machine is-empty? vend (in-money)reload init-machine (in-max) Coffee Machine is-hot? is-empty? vend (in-money) reload init-machine (in-max) The coffee machine inherits the basic functionality from our vending machine, but then extends it to handle temperature. We also add new functionality as well (is- hot?) The coffee machine inherits the basic functionality from our vending machine, but then extends it to handle temperature. We also add new functionality as well (is- hot?)

But how does this all work? One way to think about what inheritance actually does is as follows: Whenever I create a coffee machine, what I’m really doing is creating an instance of its parent class, the vending machine. We take that instance of a vending machine and put wrapper functions around its behaviors to give us extra functionality. We also create entirely new definitions to give us new functionality. So….

is-hot? is-empty? vend (in-money) reload init-machine (in-max) Coffee Machine Vending Machine init-machine (in-max) reload vend (in-money) is-empty? heat coffee SERVE MAX-COFFEE stock cash MAX-STOCK COST

Actual Code Once again, be warned that the code for demonstrating inheritance in Scheme is not the prettiest piece of work on the block. Much of what you’re about to see is built into object- oriented languages such as Java, allowing for much “prettier” code. This is merely an attempt to demonstrate the concept.