Hide menu

TDDB84 Design Patterns

Lab 2 — Reading Design

These instructions are valid from the fall of 2016.

Code

You will be working with the FreeCol codebase, which resides locally at gitlab.ida.liu.se/tddb84/freecol.

Assignment

The lab consists of finding out what design decisions have been made within the part of the application you are assigned to.

First, you will investigate the Java package that belongs to you and analyze it with respect to the design patterns you find, and detect three instances of design patterns in your parts designated packages. If you are unsure which packages belong to your part please see the table below. Workflow Flowchart

Trivially, we may find examples of where the developers have used functionality from the base Java API to access elements of compound structures through the use of an Iterator, but what we would like to see if they have designed any part of the application-specific code according to existing design patterns.

To help you with the distinction, here is an example of what is interesting:

An implementation of the Iterator pattern for a custom data structure, where the developers of FreeCol have created the encapsulation of iteration logic in a custom Iterator class.

And here is an example of what is NOT interesting:

Simply listening for mouse events by using built-in listener interfaces in Java, or iterating over built-in Iterable collections in Java.

That is, we would like you to identify at least three places in the code where it seems that the developers have solved a problem particular to FreeCol by implementing a good solution that also follows some design pattern. Identify at least three such locations. By location, we mean either a particular class and a (set of) methods in that class, or a collection of classes together.

Second, we would like you to identify at least two locations where design decisions have been made that seem to violate the principles of SOLID, or general object-oriented programming principles. The purpose of identifying these locations is that it will be the basis for your work in subsequent labs, so take good care to investigate the code base.

Each group shall submit to the other two groups the locations where you have identified both good design and things you would like to improve. You shall NOT, however, reveal to one another WHAT DESIGN PATTERN OR DESIGN VIOLATION you believe you found at each location in the code base, only that you found A DESIGN PATTERN OR DESIGN VIOLATION. When you have received submissions from your peer groups, you shall review these suggested locations and try to find patterns or violations of some OOP design at these spots. During the seminar, you will get to sit down with your peer groups and have a discussion about each location, and what different subgroups found at each location. Even if you end up being wrong about some of your design patterns initially, it is not necessary to find new ones, rather it is the discussion of how and why your findings differed that is of importance. In your summary report, you shall reflect upon the findings you made as well as your peer groups.

Lastly, you shall write a summary regarding your own subgroup’s specific area, reflect on the possible differences in evaluating the code base, and submit your report to your teaching assistant.

In summary your task is the following:

  1. Together with your partner, inspect the code relevant to your subgroup area: "Missions and Resources", "Model" or "Communication and Stuff". Note the occurrences of where you find design patterns as well as where you find violations of SOLID or general OOP design.
  2. Notify the other subgroups in your project group (for instance, if you are in the "Model" group you notify the "Missions and Resources" and the "Communications and Stuff" group) about the location of your findings, but not what your findings were.
  3. Receive the notification about the other subgroups' findings, and see what you can find there.
  4. During the seminar for lab 1, you will sit together with the three subgroups and discuss your findings all together. Did everyone find the same patterns and make the same observations?
  5. Write a report regarding your findings and the other subgroups’ comments.
Missions and Resources Model Communications and Stuff
A list of packages belonging to each part. You do not have to consider sub-packages of the packages listed below, but you may need to understand some other sections of the code base to understand what is going on in your specific section of the code.
common.resources, common.model.mission, common.model.pathfinding common.model common.networking, common.option, net.sf.freecol.util.test* (* in the test/src source folder)
A list of patterns that you are most likely to find (although it is not impossible to find other patterns)
  Facade Facade
Strategy Strategy Strategy
State State State
Template Method Template Method Template Method
  Memento  
Iterator Iterator Iterator
Composite Composite Composite
Builder Builder Builder
Factory method Factory method Factory method
Decorator Decorator Decorator
Some additional questions that could get you started
How does the game decide which path to take from one tile to another in the application? How are movements decided? How can the application switch from one way of calculating the cost of movement to another? Look at the common.model.pathfinding package for more information on this. How are game elements in the model serialized and deserialized when saving and loading a game, respectively? Look at the methods called read-something or write-something. How are server requests from a client to the server? Look at the methods in class common.networking.ServerAPI and the way methods in this class are invoked by other classes in the game. Find a suitable behavioral design pattern to describe the function of the class.
Look at the structure of (common.model.mission.CompoundMission). Is there a structural design that you recognize? How is the class model.TransactionListener used? What is its purpose? What is the purpose of the clone method in the common.option.AbstractOption class?
How are string identifiers used to obtain resources in the class common.resources.ResourceManager? What is the purpose of the enum values model.DiplomaticTrade.TradeStatus? What behaviour depends on the current trade status? What happens when the methods common.option.*Option.setValue are invoked? What behavioral pattern is that an example of?

Use the questions above as a starting point, but do not expect them to show you all that you need to find in order to pass the assignment.

Reporting your results

The submission of the lab report is done after the corresponding seminar (see the corresponding seminar for information to submit to the groups and seminar assistant).

Each lab pair should submit a report to the email address of your teaching assistant as it is described in Lab 1.

  • A short description of the design patterns and SOLID violations that you believed that you found in your part of the code base and submitted to the two other pairs.
  • A summary of whether your peers found the same patterns and SOLID violations in your section of the code base as you did, and if so, if they described their details in the same way. If there were any differences, resolve them by referring to the literature first, and then by consulting your peer groups to understand why you identified different patterns and considered SOLID violations differently. Take notes to remember all your communication in between the groups so that you with ease can summarize your conclusions, and possibly to hand to your assistant upon request.
  • A description of how the code you found differed from canonical representations of the design patterns that are found as examples in the literature, on Wikipedia, and in the lecture material.

Thus, you do NOT have to write in your report anything about design patterns and SOLID violations in the sections of the code base that the other pairs studied, only the design patterns and SOLID violations that you found in your own section.

Report your results to your teaching assistant for LAB1 no later than the last time and date set for the second lab. See the timetable.

Page responsible: Alachew Mengist
Last updated: 2018-09-12