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.

Submitting your Work

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

• ooga folder:
  • Code Masterpiece: Java file(s) showing an example of well designed code you primarily wrote during the project
• top-level (as usual):
  • Design Review: a Markdown file, named week16_ooga_analysis.md, with your reflection on the project's design

Specifications

Code Masterpiece

Choose part of the code you primarily wrote that you feel demonstrates what you think of as good design, totaling approximately 150-300 lines (including comments). 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).

Design Review

Explain your view of how your program is organized and why it was done that way. This can 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 citations from the course readings to support your opinions 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 how SOLID Design Principles and the 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)?
    • How would you add an Extension Feature of your choice that your team was not able implement?
  • Describe one Design Pattern in the project's design (or that you wished for)
    • Describe the specific design problem it changed your perspective on or solved
    • What specific classes and methods that implement it?
    • How did it help (or would have helped) the design?
  • 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 one assumption or choice made about the assignment specifications or the code that had a global or significant impact on your design (and, perhaps, how it was removed)
• 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 are two specific things you have done to improve as a coder/designer?
  • What are two specific things you have done to improve your teamwork or to be a better teammate?
  • What are two specific things you have done to improve how you manage "large", ambiguous, open ended projects?
  • What are your two biggest strengths 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)?