Second Semester

Week 1 - Command Pattern

We want the commands/requests that we send through to start taking on a shape of their own. This week we implement the pattern and see what changes it forces in our application.

• Code: e9b8449504be2d2ae8255726092ff32d3c9b3886
• Video: YouTube
• Resource(s):
• Pattern Details: Example from 'doFactory'
  • Musing(s): We discovered that our Interpreter design pattern served as a decent 'Receiver' of commands. We also decided against encapsulating that receiver inside every Command. Instead we have the command inside the receiver. Hopefully this can be abstracted out using the dependency inversion principle later. Our Chain of Responsibility is still in control of our application flow, and our State pattern is doing a good job of isolating the business logic.
• Vocabulary: Single Responsibility, Encapsulation, Dependency Inversion.

Week 2 - Builder Pattern

We're going to take advantage of our state pattern and the need for games to do some fancy stuff on creation. We already have a Factory pattern to find the game. Next we want to be able to finally control how exactly the game 'boots' depending on things like the current players position in the game.

• Code:
• Video:
• Resource(s):
• Pattern Details:
  • Musing(s): What does all of this single responsibility and abstraction buy us? 'Polymorphic' is a very lego-esque term. We're now using the builder pattern to introduce complexity to our game(s). However, the plumbing for how this will integrate with the application flow is already established. In doing so we've cut through a lot of the initial design required for any module or component we wish to create. This is closely related to the idea api driven development. If we were mechanical engineers we'd say we're starting our design with the things it interfaces with. That interface is almost always driven by constraints. i.e - "This valve has a through put of X and pressure of Y. Design a filter to attach to it." In our case we have this evolving chain of responsibility and a way to attach a game module as part of the flow. Our constraints (read: design patterns) free us to consider the "what" instead of losing time on the "how" or the "what". Additionally, any performance or style constraints can be called out clearly in framework we're attaching to.
• Vocabulary: Polymorphic