Homework 10

Last updated: Thu, 14 Dec 2023 14:17:27 -0500

Out: Mon Dec 11, 2023, 00:00 EST

Due: Sun Dec 17, 2023, 23:59 EST

Overview

In this assignment, we’ll explore how the ideas we learned in CS450 this semester still work, even when programming in an OO-style!

This hw will be graded as follows:

Setup

Create a new repository for this assignment by going to the CS450 Fall 2023 GitHub Organization page and clicking "New".

When done click "Create repository".

Starter Code

Here is a hw10 starter repo. It contains the code from lecture 27, which illustrates how to write "OO style" code with structs.

(Note: The code is meant to be used as a guide. Please don’t submit any lecture 27 code as (part of) a solution. It will result in heavy deductions.)

Submitting

1 Before Submitting

2 Common Problems

Common submission problems:

• a required identifier is not provided or defined in the homework file

• an external file has not been uploaded to GitHub

• the code is in an infinite loop, e.g., do not start a big-bang loop automatically when running a file. (Instead, it should be in a main function)

3 Files

A submission must have the following files in the repository root:

• hw10.rkt: Contains the hw solution code. This code in this file should be written in Racket. In other words, you should have #lang racket at the top.

• tests.rkt: This file should require hw10.rkt and define tests for it.

• README.md: Contains the required README information, including the GitHub repo url.

Also, the repository must have appropriate commit messages. See How to Write a Git Commit Message if you are unsure how to write a commit message.

4 GradeScope

When ready, submit this assignment to GradeScope using the "GitHub" submission feature with your hw10 repository selected.

Submission link: GradeScope HW10

HW Tasks

For this assignment, create a Racket big-bang program that allows the user to draw shapes onto a canvas. Only rectangles and circles are required, though you may add extra shapes for some extra credit (see Overview above).

Here is an online demo (roughly) illustrating the expected behavior: HW 10 demo.

The Shape code must be written in an object-oriented style, using structs. This means that a Shape data definition should be implemented with a struct whose fields are the required Shape methods (see lecture 27-28 for more details). Further, each method should have a "dispatch" function that accesses the correct field from a Shape instance and calls it with the instance.

Also, there should be a separate data definition for each shape item, and each of these items should have implementations of the required methods, and an alternate constructor where the method arguments are hidden.

Here more detailed specifications for the assignment:

• Canvas should be 400 by 400 pixels

• A tool bar should appear at the top-left of the canvas with individual toolbar buttons arranged vertically. Each button should be a 40 x 40 square.

  • Each button should have "selected" and "unselected" state. A selected button should somehow be highlighted to distinguish it. Only one button may be selected at a time.

  • The top button should be a "pointer" button. No drawing should occur when this is selected

  • For the remaining buttons, there should be one per shape. Selecting one of these allows drawing of that shape.

• When drawing:

  • A "button-down" mouse event starts drawing the selected shape.

  • A "button-up" event finishes the drawing. All shapes should be drawn with 2htdp/image draw functions with "black" "outline" parameters.

  • Between these events, the program preview what the finished shape would look like, and the preview should change as the mouse is moved.

  • The "start" and "end" of a shape can be any two points on the canvas, so your program needs to handle this, but in an appropriate number of separate functions! Do not dump all code into one large function! Specifically, for each shape, define a separate function that computes an instance of the shape from any given two points (Posns).

    For example:

    ;; create-rect : Posn Posn -> Rectangle

    ;; Creates a Rectangle object with the two given opposite corners.

• Moving the mouse outside the canvas at any time erases all shapes on the canvas.

As usual:

• Concise code is readable code (most of the time). This means that any extraneous code negatively affects readability, so get rid of it!

  This is bad programming practice because (1) it decreases your ability to understand the code you are writing, and (2) it tends to leave extraneous code in the program, which kills readability (and shows that you don’t understand the code you are writing — not good!). For this assignment, any extraneous code in the program may result in large deductions.

• Related to above, this means that you should not include broken, commented out code in the submitted program. Also, don’t submit any comments that I may have written in (lecture) code, which are intended to instruct. I don’t need to read my own comments. (Obviously, Design Recipe components in comments should remain.)

• Also, related to above, do not include explicit Code Templates in the submitted program. Templates are for your own benefit to help write functions. They also help you cleanly split larger functions into smaller ones. But you dont need to leave an explicit copy in the code (it’s obvious if you followed the template or not).

• Examples should help readability and be carefully selected to help explain the behavior of the functions. (They cannot be the same as the tests.) I will look to these to try to understand the code.

• Tests must thoroughly test correctness. Make sure tests include both correct and error-producting programs. In this assignment, any missed corner cases may also result in large deductions.

• Just "trying to get the code working" will not earn a good grade on this assignment.

• You may update existing Data Definitions (or create new ones) first, before starting to write any code. At this point in the semester, since we are no longer creating small programs, it’s unlikely that the assignment can be completely without focusing and understanding the data representations first.

• All other steps of the design recipe—e.g., name, description, signature, examples, and tests—must also be followed and will also be crucial towards successful completion of this assignment.

• Functions should be split properly so that each performs "one clear task". One way to know when this is the case is if the function is easy to name and explain concisely. Another way is if a function only processes one kind of data.