A3
Reading Code, Plugging into and Architecture, FileIO, File Parsing, Regex, Using a Design Pattern.

Due: December 2 by 11:59 pm
Late penalty:20% if handed in up to 48 hours late. Not accepted after that.
Hand in: Electronic submit via git, that is, you should have your code checked into your repository by the due date. We will check it out from there. Please indicate the commit ID you want us to mark in this page. Otherwise we will not check your code out of the repository for marking.
Marking:
Groups and Repos: Groups of size 1.

Getting started

A good architecture for Paint+Persistence

You should modify the given application to add USER STORY 3.1, 3.2, 3.3, 3.4, 3.5 IN THAT ORDER! You must add the USER STORIES and BUGS in the specified order. You must conform exactly to the paintSaveFileFormat.txt. This document also appears in your repo.

  1. [10 marks: Medium] USER STORY 3.1 Polyline

    Hint: Understand Squiggle.
    Objectives:

    • Practice reading and understanding a large code base.
    • See and understand the use of design patterns in code.
    • Extend existing code by plugging into design patterns.

  2. [10 marks: Easy] USER STORY 3.2 Save

    Objectives:

    • Practice file writing
    • Some understanding of an existing design pattern is needed here.
    • The result of Saving a file should be a completely correct Paint Save file. My parser should be able to read your files.

  3. [10 marks: Medium] USER STORY 3.3 Load

    Your parser should pass all of my PaintFileParserTest test cases. DO NOT BREAK THE PaintFileParser public interface!! Hint: Since spaces don't matter, strip them out of the line immediately after you read them from the file. This simplifies your regular expressions! That is, in PaintFileParser.parse, add

    l = l.replaceAll("\\s+",""); // right at the start of the while loop
    Objectives:
    • Practice file reading
    • Regular Expressions
    • File parsing via a finite state machine

  4. [10 marks: Hard] BUG 3.4, Visitor1 Drawing

    Objectives:

    • Demonstrate understanding of an advanced design pattern, refactoring existing code to take advantage of the design pattern.
    • Since we won't help you apply the design pattern, this requires that you search resources, understand them, understand how to map the pattern onto existing code and then modify the existing code. Our notes do have a good collection of examples though.

  5. [10 marks: Medium] BUG 3.5, Visitor2 Save

    Objectives:

    • Once the architecture is in place, this exercise gives you a chance to see how this simplifies and localizes concepts.

Note: We will not answer questions about Visitor above. Why? Because part of being a developer is understanding the literature and applying it to your code. These are intended as a challenge.

Questions and Answers

Question:
After I merge my userstory/bug fix, can I delete my branch?
Answer:
No, please leave it for us to see your work.
Question:
Do I have to name the branches as described in the repo? Do I have to add my name to user stories/bugs?
Answer:
Yes and yes. This is part of communicating with the team and with us.
Question:
Can I see the branches in the git log (command line?)
Answer:
git log --graph --abbrev-commit --decorate --date=relative --all
Question:
If there are platform issues where should our final project run?
Answer:
Your project must run on the lab systems. Please test there before the final due date.
Question:
Do we get marked for scrum on this?
Answer:
Yes, even though you are a single person working on this assignment, please work as if you were in a team. Branch on user stories, add, commit and push etc.
Question:
Can I add classes and methods to the Paint starter code.
Answer:
Yes, if it makes the code simpler, better. You should not have to add much.
Question:
Can I change the signature of the given starter code methods?
Answer:
Please do not change ... PaintFileParser public boolean parse(String fileName) private boolean parse(BufferedReader inputStream, PaintModel model) PaintFileSaver public static boolean save(PaintModel model, File file) { Nor the way these classes function. That is, for PaintFileParser each time it is given a fileName, it should start a new parse and leave associated information in the described places. We will be autotesting via these methods.
Question:
How will the version number change?
Answer:
It does not, this is version 1.0 of the protocol. If anything else appears in the initial Paint Save File Version 1.0 line your program should reject it with an appropriate message.
Question:
How many states is reasonable?
Answer:
Between 15 and 30. Do not try to be efficient on this, it may end up that by combining states, you will misparse a file.
Question:
What if my parser can parse a file that the solution parser can't.
Answer:
Then your parser may be wrong. You must parse exactly the language specified in the document, not more, not less. Not trying to be mean about this, doing different would mean that you are not parsing the specified language.
Question:
I want to ask about the PaintFileParser, should our code work in a manner that if an error occurs, it just returns either true or false and causes the code to stop at that point?
Answer:
Parsing the file should stop when it encounters the first error. The program then reports the error, and then continues. That is, the program itself does not exit/crash etc. The user can now choose to load a different file etc.
Question:
I do have another question though. When I load a file, should all the shapes in the panel that existed before the load be erased?
Answer:
Yes.
Question:
Also, should the parser be case-insensitive?� For example, In the assignment page we have: Paint Save File Version 1.0 Circle Should my parser also parse: Paint Save File Version 1.0 CIRCLE note: circle is capitalized
Answer:
It should match the exact case as outlined in the specification. That is, it is case sensitive.
Question:
What about negative coordinates?
Answer:
You should allow negative coordinates. Not negative radius.
Question:
How do I go about understanding all of the Paint code?
Answer:
This is precisely the skill we wanted you to practice for part of A3. How do you understand code you have not seen before. Below, I give some steps, specific to Paint, but they apply more generally...
The Goal: Teach yourself enough about the code so that you can simply explain it. 1) Run Paint and play with it a bit to understand what it does. 2) Take a quick look at the code, you can see a few different categories of classes, with familiar names... Model, View, Strategy, Command. This leads to some questions, What are the strategies about, what are the commands about? 3) A quick dive into Paint tells you that the application consists of just a few main pieces. The Model and the View. 4) Focus on some simple operation, this is one we will try to understand in some depth. For example, drawing a circle. 5) Trace through the code for drawing a circle, from the first click on the Circle button to the click in the canvas and the drag. 6) Where is the code for this, well we are looking for Buttons and for what happens when they are clicked. Search the code for Buttons, you might be interested in their event handler. 7) Now we have a choice, we can trace through the code by hand, or place a breakpoint on the event handler, debug the code and click on the Circle Button. 8) Note which classes are involved in the Circle Button click. Form some hypothesis about what these classes are doing. 9) Check the code to see if what you think is going on is correct. 10) Modify the code slightly to see if it behaves as expected. 11) Continue iterating through 4-10 until you have figured out what the purpose behind each class is and how they fit together. 12) Test your knowledge by telling a short story about the code. When you click the Circle Button, ... Now when you click on the canvas, ...
Question:
Someone posted on reddit: "@CSC207 profs: I really appreiciate how much you care about us not falling behind, but... ...not all of us can start the assignment as soon as it's released lol." Responces include things like: "Suck it up like the rest of us that did this before." What gives? Why are you pressuring us?
Answer:
I answer these things because I worry that there may be some misconceptions more widely held in the class. First, I have been meaning to get a T-Shirt that says... You may have mistaken me for someone that doesn't care! So why do I say that? Well I just want you to approach things we do in this course from the point of view that it has a purpose, that we don't do it to make you suffer, or something strange. Here is the simple reason why I am bugging you to start early: 1) I just want you to do some simple work with the code, a scan, load it up in your laptop. Put some question in your brain about it. Then you can let it sit. 2) It actually makes the assignment easier. Get things in your brain early, give your brain time to adjust and understand, and later progress will be easier. Try it! Do it for CSC236 as well, it really really works. Get the problem in your head early, then walk around doing other things, later when you come back to the problem, you will find you have made connections, the solution will be easier to find. You won't believe how well it works!! I do this all the time, I did this when I was a student. Riding home on the subway, I would scan the questions think a bit about some of them, by the next day, they were easier.
Question:
I go to office hours asking how to implement a solution to Polyline, and the TA starts asking me questions about how paint works.
Answer:
The skill we are teaching here is understanding a code base. We encourage you to think about code rather than telling you how to implement the solution. We will help you to think, show you how to approach the problem, not remove the opportunity to experience this.
Question:
How do I prevent my branch from flattening out into master when I merge on the command line?
Answer:
git merge --no-ff <branch> See this