 In a previous video, we wrote a class to simulate a toaster. Here's the UML diagram. Everything that the toaster needs is built into one class, as if a manufacturer built all the parts a toaster needs. In reality, no manufacturer builds the entire toaster. Instead, they buy the power supply and the dials from some other manufacturer and then put those into the toaster frame, which they themselves build. In an object-oriented world, we use what the book calls composition or aggregation, where instances of one class contain references to instances of another class. In essence, we have classes that are composed or made up of other classes. We'll create a power supply class and a dial class. The power supply has the voltage and it can be turned on and turned off. The dial class has a minimum and maximum value to make it more generally useful. For example, some companies might buy a dial that goes only from 1 to 4 instead of 1 to 10. Now that we have the power supply and dial classes, we can put those parts into our toaster. Composition is a has a relationship. A toaster has a power supply and a toaster has a dial. In the code, here's the power supply class and the dial class. There's nothing particularly new in them. But in the toaster, we now have a power supply attribute called power and a dial attribute called darkness. That means that in the constructor, we have to create a new power supply object for the power attribute and a new dial object for the darkness attribute. When inserting bread, we have to ask the power supply if it's turned on. That's because the is turned on method belongs to the power supply, not to the toaster. Similarly, in the to-string method, we need to get the voltage from the power supply attribute and the dial value from the dial object. Now let's look at what has to change in the main method. We can't say toslot.turnon because the turn-on method belongs to the power supply. We could change it to an expression like this. Read from right to left, we're telling the toslot toaster to get the power supply and tell it to turn on. That's called a chain of method calls. But that's fairly ugly, and it's sort of like asking the customer to access the power supply in order to turn on the toaster. Instead, we'd like all the dial and power functionality to appear to be part of the toaster. We'll add some methods to the toaster class to make it look like it's all one unit, and those methods will call the methods in the subparts of the toaster. Here's what the code looks like for the turn-on and turn-off methods. The turn-on method in the toaster will call the power supplies turn-on method, and similarly, the turn-off method for the toaster will call the power supplies turn-off method. To make the dial appear to be part of the toaster, we'll have a public int getDialValue, which will return the darkness controls getDialValue, and we'll have a public void setDialValue, which is given a dial value by the user, and we'll pass that on to the darkness controls setDialValue method. Once we do that, we can keep everything as it is, and we don't need to do a chain of method calls anymore. We can compile and run it successfully. Toaster will learn another way of adding functionality to objects, inheritance. While many Java books and tutorials strongly emphasize inheritance, current best practice says to prefer composition over inheritance.