CSE 115 - Spring 2008 - Banner
   CSE 115 - Spring 2008 - Introduction to Computer Science for Majors I
CSE 115 - Spring 2008 - Navigation CSE 115 - Spring 2008 - Lab 6

Lab 6

Introduction

Learning to program is not an easy task. Teaching people to program is not easy either. There is no fomula to show that once you plug in all the right elements, you have a working program. To that end, many have attempted to provide an environment to students learning how to program so that the beginner can focus on design or algorithmic thinking rather than specifics about exactly "how" a particular effect is achieved within the computer. Two such examples are Karel the Robot and LOGO Turtle Graphics. Another example (perhaps less famous) is the environment we give you in CSE 115 with our own graphics package.

In this lab, you will work with elements from all three of these environments and create a set of controls that can manipulate any one of them. Essentially, this is an integration problem. One that we will solve by using two different design patterns.


Objectives

The high-level objectives of this lab are to have you,
  • create your own interface
  • develop a solution that uses the adapter design pattern
  • develop a solution that once again uses the proxy design pattern
The following are the new concepts covered in this lab:
  • polymorphism
  • adapter design pattern

Assignment Specifications

Background and motivation

Innovations and inventions that are built for the same purpose are not often built at the same time, nor are they compatable with each other in some way. For example, when the VCR was first being introduced, there were two formats for video cassette tapes, Beta and VHS. VHS won out and Beta tapes disappeared. However, an interesting problem arose. Some people had purchased Beta tapes and VCRs. Unfortunately, the Beta technology and the VHS were not compatible. If only there was a way to make the Beta tapes work in the VHS VCRs and vice versa.

With software, we have an opportunity to make seemingly uncompatible things compatible and view those uncompatible things interchangeably, using the adapter pattern and polymorphism.

Design patterns

In this lab, we will look at the Adapter Pattern and the Proxy Pattern again.

Your task is to create a control system and a user interface that will control Karel or the Turtle from the lab6lib package or a graphic object from the graphics package in Classlibs. Each of these three things have a different interface with different methods that you can call on them. However, they all have the ability to move. Your job will be to create controls to move each of them in the directions Up, Down, Left, and Right. The user will choose which of the three elements he/she wishes to move. However, no matter what the user's choice, the movement must occur with the same result. For example, if the user chooses to move the Turtle up and then chooses to move the graphic up, each will move the same distance in the upward direction.

Step 1

First, sketch out a design of what you would like your final GUI to look like. This can easily be done on a piece of scrap paper. You should decide what graphical components you need and how you would like the eventual finished product to look.

Next, go about making this "look" a reality. Create the code that creates your columns/rows and buttons or other components. Keep working with that until you have something you are happy with. You will need a graphics.DrawingCanvas to put all three elements (Karel, Turtle, the graphic) on, and it should be quite large so you have enough area to "play" with those elements. You should not worry yet about how all these items will function, but rather simply getting them on the screen.

Lastly, you should put an instance of Karel, the Turtle, and a graphic on the DrawingCanvas so you can see how to create them and initially position them.

Step 2

Discover how Karel, the Turtle and graphics work. You should look at the Javadocs provided for each to see how you can manipulate each one of these elements. You should note at this point that each one of them is manipulated in totally different ways. For example, Karel can only turn to one of four directions and then move forward in whatever direction it is facing. The turtle can be set to face a particular direction (indicated in degrees) and then move forward in that direction. A graphic can be set to any location, but does not have the same notion of movement as the other two elements.

This is a problem. Your controls must control each of the three elements, so we need a common way to speak to each of them - a common interface! However, you can not make changes to the code of Karel or the Turtle, or the graphics package, so what can you do? You can use an Adapter!

First, create an interface with the type of controls you wish to have. Remember, you want each of these things to move up, down, left and right.

Then we'll start with the Karel Adapter. You make a class that implements the interface that you just wrote and knows a Karel object. Leave the interface methods blank for now. Now, include the creation of this adapter object in your code and make sure that you can still see Karel (and all of the rest of the elements on the screen).

You can do the same for a Turtle Adapter and Graphic Adapter, each time, making sure that creating this adapter object does not break what you currently have in your code.

Step 3

We should have our buttons talk to the adapter for Karel so that we can program the adapter to make Karel do what we'd like him to do when we ask him to move up, down, left, or right. Concentrate on up first. Look back at the Javadocs and see how we could make Karel move up. Write the code for that in the Karel Adapter class. Then you should test out to make sure it works. Therefore, you will need the movement buttons to have action listeners. Create the action listener for the up button and make sure it talks to the Karel Adapter (and only the Karel Adapter for now). Run the program and see if Karel moves up. If not, go back and fix it so that Karel does.

Continue in this way for the rest of the three directions. Now you have a set of controls that can move Karel.

Step 4

Modify your controls so that they communicate with a Turtle Adapter (and only the Turtle Adapter). Write the code in the Turtle Adapter methods so that the turtle behaves appropriately when the buttons are clicked. Remember that the turtle should move as far on the screen as Karel does and Turtle steps are smaller so you will have to adjust the movement to get them to move at the same pace. Make sure that all of the buttons work and control your Turtle Adapter properly.

Step 5

Modify your controls so that they communicate with a Graphic Adapter (and only the Graphic Adapter). Write the code in the Graphic Adapter methods so that the graphic you have chosen behaves appropriately when the buttons are clicked. Make sure that all of the buttons work and control your Graphic Adapter properly.

Step 6

Now, we want to create code so that the user can select which element they want to control and then the program will control that element.

For this, we will need the Proxy Pattern to hold onto the currently selected element (Karel, Turtle, or Graphic). Create the Proxy so that it can hold onto any of these three things. Hmmm - how can I do that - they all have different types? Well, they do, but we've created some things already that will help us. There are Adapters for each of these elements and the Adapters all implement the same interface, so the Proxy can hold onto an element of that type and we can then assign any object whose class implements the interface to that variable (that's polymorphically delicious). Set the proxy up with the proper mutator method and so it delegates properly when it's methods are called.

Change the directional movement buttons so that they talk to the Proxy instead of the Graphic Adapter. To test to make sure things are working correctly, create a Proxy object and set its initial element to be the Karel Adapter. Test all of the buttons to make sure they work. Now modify it so that the initial element is the Turtle Adapter and test again. Modify one more time so that the initial element is the Graphic Adapter and test once more. Change it back so that the initial element is Karel and move on to Step 7.

Step 7

Now, you need your selection buttons to communicate with the Proxy. Create an action listeners for the Karel selection button so that it will notify the proxy when it has been clicked to change the "current element" to Karel. Run your program, select teh Karel button and make sure you can move Karel.

Now create a listener for the Turtle selection button. Run the program and make sure you start off initially controlling Karel, then can control the Turtle, and then Karel again, then the Turtle.

Lastly, create a listener for the Graphic selection button. Run the program and make sure you start off initially controlling Karel, but then can arbitrarily switch between the three elements. After this - you're all done with the coding!

Step 8

It is probably adviseable to keep your UML up to date as you proceed through the steps, but you need to submit a UML diagram for this assignment. Your diagram must include the entire lab6 package and all of its related classes. Be sure to save this file as Lab6.grn in your workspace, and be sure to include this file when you export your solution to hand in.

For this lab, we will begin to look at your code more closely. First, you should make sure each of your code files is spacing and tabbed nicely. There is an automatic formatting feature of Eclipse to help you do this. Use whitespace to increase readability.

Second, look at the names of all your classes - do they make sense and explain what the class is doing. Classes named Button and ActionListener ARE NOT GOOD AND DESCRIPTIVE NAMES. Those buttons and action listeners have a purpose. Rename your classes to reflect that purpose.

Third, go through your variable and method names. Any variable and method names you have control of should be meaningful. Variables named x, c, or p are not good descriptive names. Change them!

Fourth, pay attention to the class coding standards and naming conventions. Watch capitalization and make sure your code conforms to the class standards.

Fifth, go through and comment your code. Every class should have a comment stating its purpose. Every instance variable should have a comment stating its purpose. Every method should have a comment stating its purpose. Inside methods, comment any code that uses an algorithm that is not immediately understandable from looking at the code. If the class is part of a design pattern, state the pattern and this class' purpose in the pattern.

 

Helpful Hints

Read through the entire lab before you start working, so that you know what to expect. Make sure you save your work often, and keep track of what you are expected to submit.

Do not be afraid to refer to earlier labs to recall what things mean or what commands are available for you to use.


Reading

Make sure you have read to the end of chapter 6 before coming to lab the first week. Also make sure you have reviewed your lecture notes.


Lab set-up tasks

At your lab session your teaching assistant will briefly discuss how to carry out each of the set-up tasks below. She or he will also be available to answer questions you might have. Before you start work on the lab itself, you must carry out each of the following set-up tasks. Your teaching assistant will guide you through this process. Refer back to other lab assignments if you do not remember how to complete these tasks.

Check out the Lab6 Skeleton from the repository. If you don't remember how to do this, refer to earlier lab assignments.


What you hand in

When you are finished, you need to export your solution from the Eclipse environment so that you can submit it. You need to follow the same steps as you did for disconnecting from the repository in Lab 2. If you are not sure how to do this, please refer back to those instructions. This time, you should name your Jar file Lab6.jar. Your JAR should include your Java Source Code files and a UML diagram representing your solution to the problem named Lab6.grn.

Then you can submit the Lab6.jar file using the electronic submission program. If you do not remember how to use the the submission program, refer back to earlier labs.


Due dates

You have two weeks from the meeting of your lab to submit your solution.  The due dates are summarized in the table below. You are always welcome to submit early. If you submit more than once, the later submission will simply overwrite the previous one. Please note that even though Spring Break is included in this time, it is not expected that you work on this assignment over break. For our purposes, break is a week that does not exist.

To check that your lab was submitted, you can always refer back to the Submit Inspector on the Resources page of the website. After you have entered your user name, your submissions will be shown. Clicking on the name of a file that is a zip file will show you the contents of the zip file so you can verify that you indeed zipped up all the correct files.

Date of lab Due date for electronic submission
Tuesday, February 26 Monday, March 17
Wednesday, February 27 Tuesday, March 18
Thursday, February 28 Wednesday, March 19
Friday, February 29 Thursday, March 20

 

CSE 115 - Spring 2008 - Footer

 

 
Page Maintained by: Adrienne Decker