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 uses the proxy design pattern
meet with your mentors now that things have progressed in the course

The following are the new concepts covered in this lab:

polymorphism
design patterns in general, but the adapter and proxy design patterns more specifically

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

The composite design pattern is just one example of a design pattern. Design patterns are "best practices" solutions to recurring software development problems. Design patterns are mined from existing code, written by software developers, and therefore represent examples of high-quality designs that practicing software developers actually use.

The idea of design patterns actually come from the field of architecture. The architect Christopher Alexander's work on patterns in architecture inspired the so-called "Gang of Four", Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (who sadly passed away recently), to catalog a set of design patterns in a book, called Design Patterns: Elements of Reusable Object-Oriented Software. This book catalogs several design patterns; since then (it was published in 1995) many design patterns have been catalogued.

In this course we introduce you to several very useful design patterns. The first, you saw in lecture was the Holder Pattern. In this lab, we will look at the Adapter Pattern and the Proxy Pattern. Throughout the rest of the semester you will be introduced to a selection of fundamental patterns which will help you understand the design of pieces of the Java class libraries (such as the graphical library).

What you need to do

**** PLAN TO MEET WITH A MENTOR GROUP ****

During the weeks of February 26th, March 5th, or March 19th, you should plan on attending at least one of the mentor group meetings. It can be the mentor group you attended before, or a different one that fits better into your schedule. You will find a schedule at the bottom of this page. At the meeting, the mentors will be discussing different topics of interest for the course and even for this lab. Come prepared to speak. Note that this part of the assignment is worth a non-trivial portion of the grade for this lab (think 1/3 of the points or more). CSE 503 students are encouraged to go to participate in the discussion and to ask questions, but are formally exempt from this as a requirement.

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.dia 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 4 before coming to lab the first week. You should make sure to read chapter 5 before coming to lab the second week. Also make sure you have reviewed your lecture notes.

Lab set-up tasks
If working from home on this lab, please see these directions.

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.

Step 1: Log in

Step 2: Start Eclipse

Step 3: Check out Lab6 project from LabSkeletons repository

Step 4: Do the required lab work (instructions above)

Step 5: When finished, export your project and submit it (instructions below)

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.dia.

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 27	Monday, March 19
Wednesday, February 28	Tuesday, March 20
Thursday, March 1	Wednesday, March 21
Friday, March 2	Thursday, March 22

Mentor Meeting Schedule (Emails below)

Monday, February 26	Tuesday, February 27	Wednesday, February 28	Thursday, March 1	Friday, March 2
1:00pm - Jon, Russ & Robert 102 Clemens	4:00pm - Amy Seal of Student Union	11:00am - Zeb 229 Bell Where to work on projects, importance of naming conventions and documentation of code	4:00pm - Mike Classes to take	5:30pm - Shijo 21 Baldy Polymorphism
4:00pm - Jon, Russ & Robert 112 Baldy		6:00pm - Eric & Hung 21 Baldy	5:00 - Mobain
5:00pm - Adam 229 Bell Methods, method calls & parameters
5:00pm - Josh Map Room in Capen
5:00pm - Jack Flag Room in Student Union
6:00pm to 6:30 - Adam 229 Bell Methods, method calls & parameters

Monday, March 5	Tuesday, March 6	Wednesday, March 7	Thursday, March 8	Friday, March 9
1:00pm - Jon, Russ & Robert 102 Clemens	4:00pm - Amy Seal of Student Union	11:00am - Zeb 229 Bell Methods, method calls, parameters	4:00pm - Mike Summer courses	5:30pm - Shijo 21 Baldy Polymorphism
4:00pm - Jon, Russ & Robert 112 Baldy		6:00pm - Eric & Hung 21 Baldy	5:00 - Mobain
5:00pm - Adam 229 Bell Resources available while working on projects (what to do when you are stuck)
5:00pm - Josh Map Room in Capen
5:00pm - Jack Flag Room in Student Union
6:00pm to 6:30 - Adam 229 Bell Resources available while working on projects (what to do when you are stuck)

Monday, March 19	Tuesday, March 20	Wednesday, March 21	Thursday, March 22	Friday, March 23
1:00pm - Jon, Russ & Robert 102 Clemens	4:00pm - Amy Seal of Student Union	6:00pm - Eric & Hung 21 Baldy	4:00pm - Mike	5:30pm - Shijo 21 Baldy
4:00pm - Jon, Russ & Robert 112 Baldy			5:00 - Mobain
5:00pm - Adam 229 Bell
5:00pm - Josh Map Room in Capen
5:00pm - Jack Flag Room in Student Union
6:00pm to 6:30 - Adam 229 Bell

Mentor Emails

Jon (jcc28)

Amy (amevans)

Jack (jgreeney)

Mike (mjh32)

Adam (aahelak)

Zeb (zelohnes)

Robert (rlongtin)

Russ (rm68)

Eric (emilillo)

Josh (jbrogers)

Mobain (mshaikh)

Elana (etrudell)

Hung (hungvan)

Shijo (skz)