 Let's start on chapter 14 today. The two concepts that we want to talk about are composition and inheritance, and those are two very different things, and depending on what you're doing, you use one or the other, or maybe both. So let's start with composition, and that happens when an object is made up of other objects. So in chapter 13, the deck consists of a bunch of cards. So the card, essentially, a deck is composed of cards. And this is also known as a has a relationship. A deck has an array of cards. And here's the terminology, which I probably will not ever ask you about, but somebody might on the future test in another course, so you should know it. And here's how we draw such a relationship in UML. We use a diamond headed arrow. This one and many says that one deck contains many cards. So you can have a one-to-one relationship or one to many and so on and so forth. And now that we know about composition, let's give ourselves an example by doing a Java simulation of a toaster. So we have to ask ourselves, well, what's a toaster built from? Well, it has a chassis with a number of slots, usually at least one, at most four, at least for most toasters I've ever seen. And there's a lever to push the bread down or pop it out. Then a toaster has a power supply somewhere in it to provide the heating element with the power and you can turn the toaster on and off. And finally, a dial to control how dark you want the toaster to be. Now, if you look at any real toaster built by a toaster company, they will build the chassis and the lever pretty much all that mechanism, the chassis with the heating elements and the lever. They build that stuff pretty much themselves. But most companies that build toasters don't build their own power supplies and they don't really build their own dials. Instead, what they do is they farm that out to some other company. They contract it out. If they're going to be building a thousand toasters, they call up the power supply company and say, hey, send me a thousand power supplies. They call the company that makes dials and say, hey, send me a thousand dials with label from one to 10. And then they put all of that stuff together. So that means that our toaster has a power supply object and has a dial object. And here is the UML diagram. Let me show you a larger version of it here. And these are by the way, they one to one. One toaster has one power supply and a toaster has a single dial. It may could be one to many. I've seen toasters where you have a different dial for every slot. But in this case, we've designed a toaster where there's one darkness setting that sets the darkness for all the pieces of bread. The toaster does the stuff that the toaster company wants. The number of slots, the number of slices currently in this toaster. And the power is a power supply object and darkness is a dial object. We have a constructor and then we have an insert bread and pop bread. The power supply is responsible for knowing what the voltage is and whether the power supply is turned on or not. There's one thing missing from this diagram. I think I'll put it in. I may have to redo the diagram, but let's not worry about that now. And the dial is responsible for knowing what its minimum and value maximum values are. And again, you can set the dial value. I think there's also a getter for the dial value and a getter for the whether it's turned on or not. Let's look at the actual code and see which ones I actually which ones I implemented. Okay, so a power supply has a voltage and whether it's turned on or not. When we create a power supply, we have to say which voltage we're building. Are we building it for the United States 110 volts or for Europe, which is 220. And if you don't give me a 110 or 220, I'll just settle on 110 so that we don't end up with some weird toaster that can't be used anywhere in the world. And I also set the turned on to be false. We have getters for the voltage. And we also have, once this is set by the way, the voltage does not change. So if you have a 110 volt toaster, it will not magically become a 220 volt toaster. And we could have designed it that way. There are some toasters that have a transformer in them so that it can run on either 110 or 220. But that's not the ones we're building here. Now this is the getter for turned on. And there's an important point here. For example, if I have something like, oh, for example, integer or double price, that's one of my attributes. Then I have a public double yet price, which will return this price. If I have something like a string name, and then I will have a getter that's called public double yet name, which will return this dot name. When I have a Boolean, we have a different convention. So if I have a Boolean called turned on, I do not say public Boolean get turned on. Instead, I say public Boolean is turned on where I return this dot turned on. So essentially for a Boolean attributes, the getter follows the name pattern is attributes. And that's just the way people will expect you to write Java code. Again, this is a convention. It's not a requirement, but people will look at you funny if you don't follow that convention. And that's why I have is turned on returns. And by the way, this could also return this dot voltage and this dot turned on, and that makes it more in line with what the book says. Now, whether the power supply is turned on or not certainly can be changed. And the setter always starts with the word set. So set turned on will set the value to whatever we gave it. So there's our power supply class. Now let's look at our dial class. It'll have a value which is okay, where is the dial turned to. And that's a double because you could set something at a lot of the dials are analog and you can set to like five and a quarter. You don't have ones where it's either five or six, but nothing in between. And there will be a minimum value and a maximum value. And we're going to create it with a minimum and maximum value and we'll always ship it. The dial set to the lowest value. And again, we can get and set the dial value. And what I've done here with this min and max business is to make sure it's always between the minimum and value maximum value. If you give me something that's larger than the maximum value of the dial, it go be sets to the maximum value. If you give me something less than the minimum value, it sets to the minimum value. There are getters for this minimum and maximum value, but there are no setters for them because those are set at construction time. If I have a dial that's labeled from one to five, I can't magically change it into a dial that's labeled one through seven. That just doesn't happen. Or at least that's my design decision. Now I'm ready to build the toaster. The toaster company figures out how many slots there are and keeps track of how many slices you have in the slots. And then this is where it's going out to the power supply company and the dial company to buy those and put them into the toaster. And the constructor mirrors this. There's a new power supply with the voltage and a new dial, which will be set from one to 10. And then the number of slots again we're using the max and min to make sure that we never go less than one slot or more than four slots. And when we ship a toaster we do not want any bread in it because that could get pretty messy. So the number of slices in the toaster when we construct it is zero. And these three attributes, the power and the dial and the number of slots will never change. We need to be able to get the access to the power supply and get access to the dial and get the number of slots so that we can check to see if we put in the correct amount of bread. But none of those will change so we're never going to set power because we're not going to change the power supply object once we get it. We can set darkness we can set the value of the dial, but we're not changing the dial itself. And then we can get the number of slices and set the number of slices and again, make sure that we don't go beyond the number of slices that are available. And then when I insert in slices of bread, if the power is turned on, I can set the number of slices. If the power isn't turned on, we're not going to let you put in the bread. This is like real toasters. If it's not plugged in, you can't push down the lever. It won't click down. And again, you can't pop the bread out unless the power is on. That's probably bad design, by the way, if the power fails, you'd really like to be able to pop out the bread. Whoever designed this toaster was not thinking ahead, but oh well. And this pops out all of the bread because the number of slices will become zero. Now, remember that nobody has access to the power supply directly. Why? Because it is a private power supply. So here's a problem that we would run into if we did this. We could say, for example, toaster. My toaster is a new toaster that has two slots and it's a 220 volts. Now, if I want to turn the toaster on, I cannot say my toaster dot turn on. Or better yet, let's say set turned on to true. I think that's what I called it. Yes. Let's see. Do I want to put this in a, unfortunately, the way I have this set up right now, I can't demonstrate it. Hold on a second. I'm going to pause for a moment and figure out how to get around this. Okay, I took out some of the code and put this in a different file here called toaster test zero. Oh, by the way, I do have a two string method as well. Namely, it's going to give me the, let me clear that by the way. And it tells me how many slots there are, what the voltage is and how many slices and where the darkness is set to. And whether it's on or off. So the number of slots, I get the voltage from the power supply, which tells me the amount of voltage. And notice by the way here, I am using a ternary operator. So it'll say that they say one slice, but three slices. That's what this S does. It fills in this guy. And then there's the darkness and then I check to see if it's turned on. And if it's on, I say on say off. In fact, let's do this here real quick. And let's run it. And we have a four slot 220 volt toaster with zero slices and darkness one and it's off. Now, here's the problem that I was going to have to solve a little bit earlier. What happens if I want to say this, I want to turn on the toaster. If I try and say Euro four dot set turned on, it's going to complain that says you can't find that symbol. Why? Because your four is a toaster. And if we look at a toaster, it does not have a turned on method. The set turned on method belongs to the power supply, which is right here. That means what we would really have to do is we'd have to take our toaster, get its power supply and tell that to turn on self on. So we're going to call the set turned on method belonging to the power supply that's inside of our toaster. And now it works great. And in fact, if we were to run this, now notice that the toaster is on. And similarly, because we have the dial value, we'd have to say, okay, we want to get the dial and then set its value to four. Insert bread doesn't need anything special because insert bread remember belongs to the toaster. Oh, very good. I'm sorry, it's called to get darkness to run it. This is ugly. It's almost like saying, okay, every time you want to turn the toaster on, you have to go and look at the actual power supply inside the toaster and flip a switch on the power supply. Yuck. Okay, that's not the way toasters work in the real world. In the real world, what we do is the power supply has its own internal switch. And we put a switch out on the chassis so that you don't have to worry about turning it on and off by reaching underneath and digging around inside the power supply, which is pretty dangerous anyway. And here in our toaster test Java, I have put in some extra stuff in the toaster. So inside the toaster I'm providing methods so that they can get and set the attributes of the power supply without having to do that sort of a chain. So I'm going to have an is turned on method. And that's going to go and access the power supply for me so that you don't have to dig around in it. Similarly set turned on is going to now belong to the toaster, and it's going to intermediate for you by going and actually fiddling around with the power supply. The same with the dial value. I'm going to if you want the dial value I'm going to look at the darkness control, which is not really part of that which is part of the toaster but it's not something you have access to directly. And similarly for set dial value. And now once I have those, I can now access everything as though it were part of the toaster. If I compile this everything's going to work great. Because when I say set turned on for the toaster, it's going to say okay, I'll set the turned on to whatever you want and I'll do it on the power supply for you so that you don't have to go and do it by digging around with the wires. And in fact, if we compile this and run it. We get this a similar sort of thing here. I didn't print it out before so let's print it out before. So that's somewhat of that's why I want to say at this point about composition. And again here's some other examples of composition. The printer has a power supply they go out and buy it from someone else, the printer drum and the toner cartridge they make go they might not build their own they might get it from a company that specializes in printer drums and toner cartridges. Bicycles are made up of a gear assembly to handbrakes and two tires. So that's what you use to compose a bicycle. A refrigerator has a power supply and an ice maker and it also has a compressor and a window and a word processor has a again it's composed of a text area, a ribbon the icons at the top, and the two scroll bars are part of the window. And the text here in the book goes and explains what I just talked about here. So we use composition when we have objects that are built up from other objects. And you should always provide methods in an object to give users access to private attributes of the sub objects. They can still get to it by using the getter getter methods but it's ugly. It's ugly as in this business that I have so this is, let me put a comment here, providing method in the toaster class. Users would have to access the power supply using the get power method in order to turn the toaster on. And they'd have to use get darkness to access its set dial value method and get rid of that that's no longer needed. And let's see where we are here. What's inheritance? Inheritance is an is a relationship, not a has a relationship. So in a card game, if you have a hand, it is also a collection of cards. In some games you take some of the cards that have been played and you put them on a discard pile. That pile is a card collection. So the hand that you're looking at the cards in your hand they're a collection of cards. The discard pile is also a card collection. And here's how we do inheritance using an open arrowhead. The diamond arrowhead is for composition. The regular arrowhead is for inheritance. Here's some other examples. An electric bicycle is a regular bicycle. It has extra attributes and capabilities. A trumpet is a bugle. Bugles don't have vowels or keys. A trumpet lets you play more notes because it has those little keys you can press. An alarm clock is a desk clock with extra attributes and capabilities. And if you've ever seen these combo boxes in a computer application, that is a dropdown menu. And in addition, it has extra capability that lets you type the value as well as select it from a list. So let's look at a world without inheritance when we don't have an is a relationship, such as electric bicycles and bicycles. I should probably display that shouldn't that's a little bit easier to see. And let me make that a little bit larger. So bicycle has a color, a frame size, a number of gears in the current gear. And the electric bicycle also has a color frame size, a number of gears and current gear. And in addition, it has the battery capacity, current charge and max speed. But all of these getters here, the color, frame size, gears and the setter, we have to duplicate all of those. And then we can go and get the battery capacity and the current charge, which is the extra stuff that we've put in there. And also there's a maximum speed that you can go on an electric bicycle. So do you see there's a lot of duplication here. This is ugly. We would like to get away from having this duplication. So here's what we're going to do. We are going to use inheritance. And let's look at that diagram. And by the way, I'm going to be uploading these in the sample file so you can look at them yourselves later on. The bicycle has a color frame size, a number of gears and current year and the appropriate getters and setters. An electric bicycle is a bicycle which additionally additionally has a battery capacity, the current charge and the maximum speed. Now all I have to specify inside of electric bicycle is its constructor. And also all the stuff that we need to do here to take care of the battery. Now I don't have to duplicate the get color, get frame size or any of these attributes, they come along automatically. An ordinary bicycle inherits all of the attributes and all of the methods of bicycle, and then adds whatever attributes and methods its needs to distinguish it from an ordinary bicycle. So short exercise composition or inheritance. So the question is, the relationship that classes as composition or inheritance and draw a UML diagram showing that relationship I'm not going to do any drawing I'll just let's do the first one for example. Address and student. Is that composition or inheritance. And the answer is that's composition. A student object has a address object. A student object has a relationship. What about car and vehicle. That's inheritance a car is a vehicle. And I'll let you go and figure out some of these the rest of these on your own. Also for his classes that exhibit the inheritance relationship could you name a few data fields for the superclass the superclass is the parent class by the way. So this is the parent class or the superclasses bicycle. The child class or the subclass is electric bicycle. And an example here teacher is a person. So that's the subclass and the person is a superclass. So every person has a name and age and an address teachers however. In addition to having a name and age and address, they also have the name of the school they work with the date they were hired. The classes are the subject that they teach a whole bunch of other stuff that ordinary persons wouldn't have. I think this is a good place to stop talking about inheritance and I'm going to pick this up on Monday. Or if I feel exceptionally motivated, I might do a mini lecture tomorrow and talk about more about inheritance. And then at some point I'm going to get on to polymorphism and dynamic binding, which is a big issue subject. But that's for another day. And I will see you all around online. That's it for today.