Exercise : Understanding Design Patterns

This exercise is intended to help you to better understand Design Patterns so you can use them to help organize and justify your design choices as well as direct your Refactoring.

Submitting your Work

As a team, summarize your discussion in the file PATTERN_DISCUSSION.md and push it to the doc folder of the master branch of your team's provided, shared Gitlab repository using the commit message "lab_patterns - participating NETIDs".

Understanding Patterns

You already know how to implement Design Patterns since they just describe how to use basic design skills and follow SOLID design principles you have you have learned and practiced throughout the semester. In fact, you have likely already implemented at least one Design Pattern in your code without knowing there was a "name for it". Thus, Design Patterns are primarily a good shorthand for referring to how a group of classes work together to achieve a design goal as well as describing the implementation's design trade-offs since just about any abstraction you create has a design goal.

Still, learning about Design Patterns can often open up your thinking about different ways to solve a design problem you are having — even though, as you can see from these examples, sometimes the final implementation can seem very simplistic:

• Factory pattern: Roulette example
• Strategy pattern: Bins example
• Observer pattern: TestFX example

Compare the implementation of these classes with the standard description of the Design Pattern they implement:

• What abstractions and methods are part of the pattern's application in the code?
• How is the implementation the same or different from the pattern's description?
• Was there anything specific you liked, disliked, or learned about design from the example?

Patterns in Java

Java and Design Patterns came out around the same time, so Java was heavily influenced by them and, in fact, used many of their names directly for interfaces and classes (making it very confusing since patterns are intended to describe how multiple classes interact rather than one single class or abstraction).

Consider the following examples from the Java source code:

• Iterator pattern: Iterator and Iterable, also Scanner
• Factory pattern (static methods): LocalDate and OpenJFX Color
• Factory pattern (class): XML DocumentBuilderFactory
• Strategy pattern: Comparator
• Template Method pattern: AbstractCollection
• Builder pattern: Calendar.Builder and Locale.Builder
• Observer pattern: Observer and Observable (now Deprecated), also OpenJFX's Node
• Decorator pattern: BufferedReader and BufferedWriter

Compare the documentation of these classes with the standard description of the Design Pattern they implement:

• What abstractions and methods are part of the pattern's application in the code?
• How is the implementation the same or different from the pattern's description?
• Was there anything specific you liked, disliked, or learned about design from the example?