(Design) Patterns in Ruby

Welcome to Ruby (Design) Patterns.

This project began as a way for me to teach some coworkers Ruby, but evolved into a class on Design Patterns, their implementations, and Test Driven Development. All of the code is rdoc complete and each pattern has a full set of rspec tests. Many examples are/will be game development related, as I feel game development is fun! To copy the source:

$ git clone https://github.com/Alistanis/DesignPatterns.git

Tutorials/Blog

I've started a blog where I'll be hosting Tutorials and sharing other posts about software development! Here's the link: alistanis.github.io

Pattern Definitions

Command - declares an interface for executing an operation.
A behavioral design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

Observer - defines and maintains a dependency between objects.
The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems. The Observer pattern is also a key part in the familiar model–view–controller (MVC) architectural pattern.

Chain of Responsibility - delegates commands to a chain of processing objects.
Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.

Singleton - restricts the instantiation of a class to one object.
Ensure a class only has one instance, and provide a global point of access to it. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects.

Type Object/Prototype - Allow the flexible creation of new “classes” by creating a single class.
This is used when the type of objects to create are determined by a prototypical instance, in this case, a type defined by json data. There are two examples - one using only a Type Object and one that uses both Type Objects and Prototype cloning.

Composite - Composes objects into tree structures to represent part-whole hierarchies.
A partitioning design pattern. The composite pattern describes that a group of objects is to be treated in the same way as a single instance of an object.

Bridge - Decouples an abstraction from its implementation so that the two can vary independently.
The bridge pattern is useful when both the class as well as what it does vary often. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

Status - click on a pattern for its api docs

Documentation

Want to see the api docs? Check out the documentation.

Contact

Want to get in touch or have questions? Send a message to ccooper@sessionm.com.