Lab 3: Interfaces and Polymorphism We've had four weeks of CS15 and by now, the buzzwords of Object-Oriented Programming (OOP) may be familiar to you. OOP is an extremely powerful and quickly growing modeling paradigm that makes programming large scale applications much easier than before. For the remainder of the course, a good understanding of OOP concepts will be integral to designing and implementing the assignments. This lab is about learning how to make your life as a programmer much easier by writing flexible and reusable code through interfaces and polymorphism. Goal: Learn how to implement polymorphism using interfaces. Life before Polymorphism Let's say you are running a little low on funds, and decided to earn some money and exercise your creative muscles at the same time by opening a car painting business! Since you are a very savvy programmer, you're going to write a program that will do the painting for you. You'll begin by finding cars that need to be painted. Because of the support code for this lab, it is very important to follow the directions in the stencil and in the checkpoints! Name methods exactly as asked and instantiate objects in the given order. Getting Started Run cs015_install lab3 to get the stencil for this lab. Open up the lab3 directory in Atom. You should see five stencil files: App.java, Car.java, Fish.java, Incredibles.java, and PaintShop.java. We'll concentrate on the Car.java file for now. The Car has the following components: roof, body, door, and hood Add a paint(...) method to the Car class. It should take in a javafx.scene.paint.col or as a parameter. It should not return anything. Inside this method you will want to set the color of the Car 's components listed above. Each component has a setcolor(...) method that takes a javafx.scene.paint.color as a parameter. Save the code you added to the Car class. Double-check that there are no errors.
Now that we have a car, let's figure out how to paint it! Painting Cars Add an instance variable to the PaintShop.java class to store the current color. Create an accessor method and mutator method for the current color instance variable. This should be very similar to what you did in LiteBrite. Recall that, by convention, accessors are named getvalue() (in this case, getcolor() ) and mutators are named setvalue(...) (in this case, setcolor(...) ) Add a paintcar(...) method to the PaintShop It should take in a Car as a parameter. It should not return anything. It should paint the Car based on the "current color". HINT: use the Car 's paint(...) method Remember to save! To test what you've done by, begin by instantiating a Car object in the managepaintshop method of App.java. In order for the the instance of PaintShop ( paintshop ) in the managepaintshop method s parameters to "know about" the Car (i.e. to set up an association with the Car ), use the PaintShop ' s add(...) method and pass it the Car you've just created. Question: where is this add(...) method defined? (Think inheritance). Save, compile and run the application. You can paint the Car different colors by selecting a color from the ColorPicker and then clicking on it. Your painting business became very successful and you want to expand your business to paint other things like: walls, roads, tables, chairs, beds, ceilings, squares, circles, and everything else in the world that can be painted. Yes, it seems ambitious, but with Java at your side anything is possible! Your new customers request that you paint some superheroes. Painting Incredibles Hint: This is very, very similar to what you did above. Write a paint(...) method in your Incredibles class ( Incredibles.java ) to color in its components. Save! Like the Car components, each of the Incredibles has a setcolor(...) method.
Write a paintincredibles(...) method in the PaintShop class ( PaintShop.java ). Save! Instantiate an instance of Incredibles in the managepaintshop method of App.java and add it to the paintshop (just like you did with the Car instance). Save! Run the application. You can control which item you are painting using the radio buttons at the bottom. This design so far has a serious problem. Your PaintShop class is very spiffy, and you want everyone to benefit from your hard work. The only problem is, every time someone wants to paint something new, you are going to have to add a new paintthing(...) method in the PaintShop class to paint the new item. If someone wanted to paint a door, you would need to add a paintdoor(...) method, if someone wanted to paint a house, you would need to add a painthouse(...) method and you get the idea. Wouldn't it be nice to just have one method to paint all paintable objects? The issue is that the PaintShop 's paintthing(...) method takes in a parameter: the object it is supposed to paint. For paintcar(...) it took in a Car, for paintincredibles(...), it took in an instance of the Incredibles. What type should it be for the generic version? Tricky, tricky, tricky... One way to do it would be to have classes inherit from a superclass PaintObject that can be painted. This way, we could write our paint method as paintthing(paintobject paintobject) and the method could accept any subclass of PaintObject as an argument. However, there are a few problems with this design. Firstly, since Java classes can only inherit from a maximum of one class, if a class is the subclass of PaintObject, then it cannot be the subclass of anything else. This is the exact situation we are in. The Car and Incredibles classes already extend from another class (see extends in the class definition!), so they can't be the subclass of anything else. Secondly, the relationship between the different subclasses is a weak one; the only thing they have in common is that they can be painted. Using inheritance here would be limiting and unnecessary. Making a Method Generic Welcome to Interfaces Interfaces are like blank classes with only abstract methods. In essence, an interface is like a "contract" for a class, specifying the methods that a class implementing it must have. However, while a class can only subclass a single normal class, it can implement any number of
interfaces. Any class that implements an interface must implement all the methods of that interface. Most of the time, Interfaces are named after the capabilities they enforce: amongst the many possibilities are Sizable, Movable, Cookable, and... Paintable. Back to our example, the PaintShop 's paintcar(...) method doesn't really care that it takes in a Car, it only cares that the Car has a paint(...) method. Likewise, the same applies for the paintincredibles(...) method. In fact, the only thing the paintsomething(...) method cares about is that the argument has a paint(...) method. Interfaces are designed to solve this exact problem by specifying the methods a class must have. Your First Interface Write a Paintable interface that has a paint(...) method that takes in a javafx.scene.paint.color as the parameter. Review the lecture slides on Interfaces to help you write your Paintable interface. Note: Interfaces only provide the method signatures. Like classes, they have to be saved as a separate java file (ex: Movable interface has to be saved as Movable.java ). Implement the Paintable interface in your Car and Incredibles classes. Since they both already define the paint(...) method, you don't need to write one. Checkpoint 1: Check your interface with a TA! Now that the Car and Incredibles are Paintable, let's make the appropriate changes inside the PaintShop Class. Painting Generically Comment out the paintcar(...) method and the paintincredibles(...) methods from the PaintShop class. Save! Write a generic paintobject(...) method in the PaintShop class that takes in one parameter. Consider: What should the parameter's type be? How would you write the body of the method? Save and run the app. It should behave the exact same way as last time. Now that we have all this set up, let's really put it to use and see why that entire interface work paid off...
Painting Nemo Edit the Fish.java file so that it implements the Paintable interface. Save and compile! Look at your error list. You should get an error that says the Fish class has not defined the paint(...) method. Right! If you implement an interface, you must define all of its methods. Write a paint(...) method in Fish.java. Call setcolor(...) on the Fish 's components. Save! Create an instance of Fish in the managepaintshop method of App.java. and tell the PaintShop about the Fish. Save and compile! Run the application to see the results of your hard work It works! No changes had to be made to the PaintShop ; you don't need a paintfish(...) method. Summary The purpose of this lab was to teach you how to implement polymorphism using interfaces. The idea behind polymorphism is that instances of objects can be different types at the same time. Originally, the parameter passed to the PaintShop 's paintcar(...) method was a Car. By adding the interface, the object was not only of type Car, but also of type Paintable, a much more generic type that can be common for a lot of objects, such as cars, superheros, and marine animals. The Paintable interface factors out painting commonality. This is a widely used design pattern to write more generic code, allowing the programmer to write one method instead of many. Some final remarks about interfaces: Interfaces can also extend from other interfaces. For example, if you had a Singable interface that required a sing() method, you could extend this interface to create a Musical interface. It could look as follows: public interface Musical extends Singable { public void act(); public void bedramatic(); }
Anything that implemented the Musical interface would have to define all the methods in Musical as well as all the methods in Singable. Don't forget, a class can implement multiple interfaces. The Car class you wrote could also implement a Transporter interface, as well as any other you deem necessary. You would separate each additional interface with a comma. The syntax to do that would be: public class Car extends cs015.labs.labinterpoly.car implements Paintable, Transporter { /* Code here. */ } Checkpoint 2: Check your PaintShop program with a TA! The Javadocs Javadocs is the documentation of the entire Java API (Application Programming Interface), a vast collection of built-in classes for programmers to use. You re probably familiar with a couple of these classes by now, such as String and javafx.scene.paint.color. Javadocs tell you which classes you can use and how you should use them, as well as providing brief descriptions of what all the methods in each class are and what they do. Javadocs also include information about the inheritance structure of classes and much, much more The Javadocs will be the most thorough resource you have for information about Java libraries. They can also be a little overwhelming because they contain so much information. In this lab you will learn how to look at the Javadocs to answer your questions. You can find a convenient link to them on the CS15 website (Documents» Java Documentation >> Javadocs ), or choose the first result when you Google Java 8 API.
A window that looks like this will open: There are three parts to the Javadocs: 1. Package List : Lists all the available packages (for example: java.lang ) that are a part of the API. 2. Class List : Lists all the classes contained within a particular package. For example, if you select java.lang from the package list, you would find the String class listed here among many others. 3. Class Details : When you click on a class from the class list it will display all information specific to that class. Hint: Clicking No Frames at the top will make the Package and Class list disappear. Click Frames to bring it back.
Class Detail will probably be the most useful part of the Javadocs. Here is a small overview of what you will find using the Color class, which you used in this lab. The header shows the inheritance hierarchy for a given class, as well as any implemented interfaces and known subclasses (if applicable). Constructor Summary describes the different options for a constructor which can be used when an instance of the class is instantiated. (Objects can have multiple constructors that take in different parameters). Method Summary describes all of the methods that the class has, as well as all of the methods that the class has inherited from superclasses.
Hint: If you Google a class that you need (for example, JavaFX Color), the relevant JavaFX document will be the first or second result. Learning about Javadocs Open up a blank text file in Atom (type atom & in a shell). Navigate to the Javadocs (you can find it from the CS15 Documents page). In your Atom document, answer the following questions: a. Name four subclasses of the javafx.scene.paint.paint class. (Javadocs for Paint here: https://docs.oracle.com/javafx/2/api/javafx/scene/paint/paint.html ) b. List all the boolean return type methods of the class LinearGradient. c. What method would you call to invert a Color ( javafx.scene.paint.color )? d. What interfaces does String implement? Check Point 3: Grab a TA and get checked off. You are done with lab 3!