Skip to content

First Semester

Jump to bottom Edit New page
Dave Slinn edited this page Sep 5, 2018 · 34 revisions

Week 1 - Factory Pattern

It helps to start with a "thing". This will help to give our application an identity to drive context and brainstorming.

Week 2 - Interpreter Pattern

The next step in our critical thinking is to decide how user input will be translated into something our context can understand.

Week 3 - Context Object Pattern

A context is a container that logically groups related data. Usually aware of what it's currently doing and what it's already done (within reason). It provides a convenient (lightweight) object that can be passed between tiers and modules.

Week 4 - State Pattern

A critical part of our context is the ability to tell what state it is currently in. This along with other metadata can be used to implicitly drive functionality.

  • Code: ebf53b109f21a45217ffd57b679afa287a866d0c
  • Video: YouTube
  • Resource(s):
  • Pattern Detail: DoFactory | The State Design Pattern vs. State Machine
  • Pattern Kata:
  • Musing: The State pattern is very similar to the Strategy pattern. Where they differ is that the State pattern when changed should give the appearance that the context itself has changed classes. For example: A video game has a 'Menu' state and a 'Playing' state however the input device is the same. The buttons take on a totally different personality between the two states. One state is designed for option navigation and the other is for player control. Now when inside the game a different strategy might be loaded in order to control a player differently in different scenarios. The 'attack' button may employ in different ways but it always attacks. When in the 'Menu' state you'd never expect the attack button to start firing missiles! Because of this the changing of state can be an expensive operation. Assets need to be loaded or disposed of or entire subsystems may need to be brought online or taken down. While this is a behavioral pattern it offers performance and maintenance benefits that rival most of the Structural and Creation patterns when compared in isolation.

Week 5 - Chain of Responsibility Pattern

Now we want to give some basic flow to how our application moves input through the system. This canal system of locks and channels allows for well structured and extensible code.

Week 6 - Facade Pattern

Lastly, let's give our context something of an API so that using it is less confusing. Moving forward we'll pay a lot of attention to keeping our API clean, and intuitive.

  • Code: 8c015c1eda93851e72e28bd6473aae1ea5ffc29f
  • Video:
  • Resource(s):
  • Musing(s): We're starting to create something fairly 'opinionated'. I think this has a very special and well meaning definition in the software world. Ideally it means that you give up some creative freedom in exchange for built in functionality, solid architecture, and some level of abstraction from lower level programming. This 'buy in' is a big part of what makes programming in C# (or any high level language) so productive. Especially in MS frameworks stacked on stop of .NET (i.e. WCF, MVC, WebAPI, MEF, etc). We don't have to really understand the code running close to the metal. We can appreciate and digest as we go. This allows us to be productive on day one. Design patterns can be very opinionated in this way. We want to give ourselves and other developers a way to use, develop, and extend the application will still giving all code a sense of consistency. So hopefully as we close out on the facade pattern what you've gained is an opinionated approach to starting off a project with good architecture. tl;dr - All code should appear to be written in the same 'voice'. This requires an opinionated approach with guidelines and constraints.
  • Vocab: Process Flow Diagram, Business Process Diagram, Open / Closed Principle
Add a custom footer
Add a custom sidebar

Clone this wiki locally