LPOO_<T><G> - <project name>
Include here one or two paragraphs explaining the main idea of the project, followed by a sentence identifying who the authors are.
In this exciting platform game you can help KangarooBoy save the world, by collecting all the coins throughout ten different levels in which you will […].
This project was developed by John Doe (firstname.lastname@example.org) and Jane Doe (email@example.com) for LPOO 2018⁄19.
This section should contain a list of implemented features and their descriptions. In the end of the section, include two or three screenshots that illustrate the most important features.
- Jumping - The game character will jump when the space bar key is pressed.
- Getting hidden coins - When the game character hits a platform from below (by jumping beneath it) it will smash that segment of the platform and will get any coins that may exist hidden there.
This section is similar to the previous one but should list the features that are not yet implemented. Instead of screenshots you should include GUI mock-ups for the planned features.
This section should be organized in different subsections, each describing a different design problem that you had to solve during the project. Each subsection should be organized in four different parts:
- Problem in Context. The description of the design context and the concrete problem that motivated the instantiation of the pattern. Someone else other than the original developer should be able to read and understand all the motivations for the decisions made. When refering to the implementation before the pattern was applied, don’t forget to link to the relevant lines of code in the appropriate version.
- The Pattern. Identify the design pattern to be applied, why it was selected and how it is a good fit considering the existing design context and the problem at hand.
- Implementation. Show how the pattern roles, operations and associations were mapped to the concrete design classes. Illustrate it with a UML class diagram, and refer to the corresponding source code with links to the relevant lines (these should be relative links. When doing this, always point to the latest version of the code.
- Consequences. Benefits and liabilities of the design after the pattern instantiation, eventually comparing these consequences with those of alternative solutions.
Example of one of such subsections:
The jump action of the KangarooBoy should behave differently depending on its state
Problem in Context
There was a lot of scattered conditional logic when deciding how the KangarooBoy should behave when jumping, as the jumps should be different depending on the items that came to his possession during the game (an helix will alow him to fly, driking a potion will allow him to jump double the height, etc.). This is a violation of the Single Responsability Principle. We could concentrate all the conditional logic in the same method to circumscribe the issue to that one method but the Single Responsability Principle would still be violated.
We have applied the State pattern. This pattern allows you to represent different states with different subclasses. We can switch to a different state of the application by switching to another implementation (i.e., another subclass). This pattern allowed to address the identified problems because […].
The following figure shows how the pattern’s roles were mapped to the application classes.
These classes can be found in the following files:
The use of the State Pattern in the current design allows the following benefits:
- The several states that represent the character’s hability to jump become explicit in the code, instead of relying on a series of flags.
- We don’t need to have a long set of conditional if or switch statements associated with the various states; instead, polimorphism is used to activate the right behavior.
- There are now more classes and instances to manage, but still in a reasonable number.
Known Code Smells and Refactoring Suggestions
This section should describe 3 to 5 different code smells that you have identified in your current implementation, and suggest ways in which the code could be refactored to eliminate them. Each smell and refactoring suggestions should be described in its own subsection.
Example of such a subsection:
The PlatformSegment class is a Data Class, as it contains only fields, and no behavior. This is problematic because […].
A way to improve the code would be to move the isPlatformSegmentSolid() method to the PlatformSegment class, as this logic is purely concerned with the PlatformSegment class.
- Screenshot of coverage report.
- Link to mutation testing report.
In this section describe how the work regarding the project was divided between the students. In the event that members of the group do not agree on a work distribution, the group should send an email to the teacher explaining the disagreement.
- John Doe: 40%
- Jane Doe: 60%