March 2020 – June 2020
This project was for a graduate software engineering course that focused on code modularity and software design principles. My project team was given an existing codebase, Flutter Cow, a rip off of the original Flappy Bird mobile game. The goal for the course wasn’t to add features to the game. Instead, we made weekly improvements to the code’s quality, adhering to the software principles we learned each week.
Our repository was originally made private and is owned by our instructors. If you’d like to inspect the code, send me an email, and we can set up a time to walk through the codebase together. Below, I have posted a summary of each week’s work that outlines my responsibilities, shares some lessons learned, and provides links directly to our project reports.
I completed this project with three amazing classmates:
- Gabrielle Evaristo
- Qing Niu
- Jake Sutton
Weekly Themes and Reports
Week 1 – Identify Violations of SRP, DRY, and Information Hiding
For this lab, we inspected the codebase for the first time to understand how the program worked. After getting a general feel for logic flow and component responsibilities, we outlined the system’s violations of the Single Responsibility Principle, the Don’t Repeat Yourself Principle, and the principle of Information Hiding.
Report: Lab 01 Report
Week 2 – Fixing Dependencies and LSP Violations
Among the severe limitations of the original codebase were the dependencies of lower level modules on higher level modules. These lower level modules, such as the Sprite classes (which were the objects that moved around the screen), were dependent on GameView and GameActivity, the Android view and activity classes that controlled our game. The dependency on higher level modules was a created a very tight coupling that hindered many system improvements, prevented us from unit testing the lower level modules, and was a clear violation of Information Hiding. In this lab, we made a first attempt at removing the Sprite’s dependencies on GameView and GameActivity. This attempt ultimately failed because of my carelessness when dealing with the chaos of the system, but what I learned about the system while tearing it apart helped us tremendously in future weeks. In this lab my teammates also began making the Sprite inheritance hierarchy into a “type” hierarchy by introducing composition over inheritance and the strategy pattern.
Report: Lab 02 Report
Week 3 – Dependencies (Part II) and Factories
LAB 03 was probably our most intense lab. We reattempted the removal of the dependency on higher level modules and succeeded. Afterward, we created new object interfaces to improve the system’s Orthogonality and better adhere to the Single Responsibility Principle. We then implemented factories, utilizing our new interfaces, so that higher level modules could depend on abstract interfaces instead of concrete instantiations. For this lab, we made enormous strides at decoupling system components and reducing unnecessary dependencies, both from bottom up and top down (dependency inversion). Because of the work we did in this lab (and had started in the previous lab), we gave ourselves a tremendous amount of flexibility to improve the system in later labs. Throughout the quarter, we watched other teams struggle to make improvements to their system because of how severely limiting these dependencies were.
Report: Lab 03 Report
Week 4 – Single Responsibility and Interfaces
Report: Lab 04 Report
Week 5 – Observer Pattern
Report: Lab 05 Report
Week 6 – Mediators and MVP
Report: Lab 06 Report
…page still a work in Progress…