Weekly Journal : OOGA Project Analysis

In writing, we explore new connections and make new combinations. We sift through our schemata - reforming, rearranging, hypothesizing, and testing until we hit upon the answer, the solution to our problem. — Patricia Carlson

This analysis is your opportunity to demonstrate your own thinking and knowledge of design concepts represented (or not) in the project's code. The course staff can readily identify the good and bad aspects of project's design, so we are looking to see if you can also acknowledge these as well. The goal of this retrospective is to draw meaningful conclusions to help you learn from your past successes and failures.

Submission

In your individual portfolio_NETID repository provided for you in the course's Gitlab group, push the following:

• a Markdown file, named week16_ooga_analysis.md, with your reflection on the project's design
• in the masterpiece03 folder, Java file(s) showing an example of well designed code you primarily wrote during the project
• in the masterpiece03 folder, a new example data file that shows off something interesting about your project

Specifications

Example

Create your own "interesting" example data file(s) that show off important design elements of your project by focusing on creative or powerful things your design provides. The data file(s) do not need to represent a complete or fun/sensical game, but instead highlight something specific.

Include "comments" at the top of the data file that explain what you think makes the settings interesting.

Code Masterpiece

Choose part of the code you primarily wrote that you feel demonstrates what you think of as good design. It should represent a feature or component within your larger project that is small enough to be separable, but functionally significant enough to have some interesting design element. The term "component" is used rather than "class" because it may be several classes that work together, e.g., a few classes that work together or a superclass and its sub-classes. Note, if your component is specifically intended to be superclass, it must include enough detail that it is clear how to extend it and at least one example subclass to how it supports an abstraction.

• Every line of code in the class(es) you submit will be judged, you cannot specify parts of a class to ignore or include large sections of commented out code
• Add comments to the top of each class included that describe the class's purpose and why you think it is well designed

Simply copy only the Java code files you want to be reviewed from your project to your portfolio without renaming them so we can easily compare them to previous versions (you do not have to include other files they depend on as we will not be compiling these versions, just commenting on them).

Your masterpiece code must be in your portfolio's masterpiece03 folder and total between approximately 150-300 lines, including comments.

Design Review

Explain your view of how the program is organized and why it was done that way. This can also be an opportunity for you to describe how you might fix a problem, conceptualize something you thought about but could not figure out how to implement, or present an alternate design if you did not agree with the team or did not have time to actually change the code.

If you think something is good, justify your opinion. If you think something is bad, justify your opinion and suggest how to improve it. Use specific code examples and supporting reasons related to design principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, no design is perfect so including both pros and cons of a design (i.e., its trade-offs) or alternate designs you considered is highly encouraged.

• Overall Design. Reflect on the entire project by reviewing all the code, especially parts you did not write:
  • Describe the overall design of the program in your own words, without referring to specific data structures or actual code (focus on how the APIs/classes relate to each other through behavior (methods) rather than their state (instance variables)).
  • Describe how the five SOLID Design Principles and the four pillars of Object-Oriented design are displayed in the project's design based on the following change scenarios:
    • What is needed to add a new game variation (such as new code, resources, data, or asset files)?
    • Which classes would be affected by changing the format of the data files that determine the game variations (say from JSON to XML)?
    • How would you add a new view to the Player (say the games played most often or log of details about when each game was played)?
  • Describe one Design Pattern in the project's design and refer to the specific classes and methods that implement it.
  • Describe two project APIs (one or more class's public methods) — one that you feel was fairly stable and one that you feel changed or emerged during the project:
    • What service does this API provide?
    • What makes this API easy to use and hard to misuse?
    • What implementation detail does this API hide and how does it support extension?
  • Review two features a teammate implemented in detail — one that you feel is well designed and one whose design could be improved:
    • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
    • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Your Design. Reflect on the coding details of your part of the project:
  
• Describe two design challenges you wrestled with:
  • What are the trade-offs of the design choice?
  • What alternate designs did you consider?
  • How did you eventually handle it?
  • Why are you satisfied or not with the final solution?
• Describe two abstractions (either inheritance hierarchy or class that uses polymorphism effectively) you created (or wish you had created) and how it helped (or would have helped) your design.
• Describe two features you implemented in detail —one that you feel is well designed and one whose design could be improved:
  • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
  • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Conclusions. Reflect on what you have learned about designing programs through this project:
  
  • What part(s) of the code did you spend the most time on (e.g., debugging, adding to, rewriting, or even just thinking about)?
  • Consider how your coding perspective and practice has changed during the semester:
    • What is your biggest strength as a coder/designer?
    • What are two specific things you have done this semester to improve as a coder/designer?
    • What is your favorite part of working on "large" team software projects (it may or may not be the actual coding)?

Your analysis must include at least these sections and cite specific code examples from the project and citations from the course readings.