SLogo API Review

Pair up with someone from a different team, but a similar area within the project, and discuss the following questions.

Each person should discuss the pieces of the project for which they are responsible, although you can also discuss higher level design issues that have been discussed in your team meetings. Complete each part below together before moving on to the next part.

For the parts below, each person should listen to the other's complete ideas before expressing their own opinion. Feel free to ask questions to clarify your understanding of the design or its justification, but not to be critical of the design. After the person is done with their thoughts, then you can provide constructive comments about the design: if you like it, explain why; if you don't, explain why and provide an example of where you think it fails, focusing on these API design goals:

• Easy to learn
• Leads to readable code
• Hard to misuse
• Provides for extension

Together, try to come up with a better design, instead of just telling them what you think is the "right" way to do it. The easiest way to do this is by asking leading questions.

Part 1

1. What about your API/design is intended to be flexible?
2. How is your API/design encapsulating your implementation decisions?
3. What exceptions (error cases) might occur in your part and how will you handle them (or not, by throwing)?
4. Why do you think your API/design is good (also define what your measure of good is)?

Both people should complete Part 1 before continuing on to Part 2.

Part 2

1. How do you think Design Patterns are currently represented in the design or could be used to help improve the design?
2. What feature/design problem are you most excited to work on?
3. What feature/design problem are you most worried about working on?
4. Come up with at least five use cases for your part (it is absolutely fine if they are useful for both teams).

Submission

Use Gitlab's markdown format to record two versions of the group's discussion (one for each team's API) in files called doc/API_REVIEW_NETIDs.md and push each to the appropriate team's project repository by the end of class. Make sure each file includes both student's NetIDs that worked on it.