Design Patterns

Recently I began learning more about Design Patterns within Software Engineering. In a previous life, I was a ‘patternmaker’ working in sustainable fashion. The name alone ‘Design Patterns’ piqued my interest. In fashion design, pattern design is the technical craft of creating a two-dimensional template (typically made of paper, cardboard, or paperboard) from which the parts of a garment are traced onto fabric before being cut and assembled and ultimately worn by all of us. There are two primary methods of patternmaking; the flat-pattern method and the draping method. Patterns also take on different ‘rules’ determined by their applications. For example, patternmaking in the industry is much more structured and precise than patternmaking as a home-sewer. Much like how coding as a hobby is much different than working as a professional engineer. Scalability often dictates design decisions in the practice of pattern making based on two main concerns: how will a pattern fit when graded(scaled to a larger size), and how much fabric is being wasted. Patternmaking also has its own library of symbols and commands, quite similar to the design patterns of SE.

One of the main inquiries in my learning of design patterns is ‘what is the difference between these patterns and Object-Oriented normalities with which I am familiar? Let’s review some of the fundamentals:

OO Basics:

• Abstraction
• Encapsulation
• Polymorphism
• Inheritance

OO Principles

• Encapsulate what varies
• Favor composition over inheritance
• Program to interfaces, not implementations
• Strive for loosely coupled designs between objects that interact
• Classes should be open for extension but closed for modification
• Depend upon abstractions. Do not depend upon concrete classes
• the list goes on…

OO Patterns

• There are many design patterns, 23 universally accepted which can be classified into three categories: Creational, Structural, and Behavioral.
• As you can imagine, design patterns are constantly utilizing the basics and principles in their construction.

Design Patterns provide many advantages to engineers that go beyond those of basic OO principles. One of the more prominent advantages is that they give you a shared vocabulary — a shorthand, that allows you to communicate with other programmers more efficiently. Another advantage is design patterns your thinking to a higher level where you are thinking in terms of patterns, which provide proven constructs and principles, rather than thinking in the lower level terms of implementation, objects, and classes.

Compound Patterns

Advantages aside, I was excited to see Model-View-Controller is also considered a Compound Design Pattern —meaning that I’ve been implementing design patterns unknowingly! What an interesting surprise. So, what’s happening with a ‘compound pattern’?

Compound Patterns combine two or more patterns that solve a recurring or general problem.

In the standard MVC structure, The View utilizes the Observer pattern to keep the views and controllers updated on the latest state changes. The View and the Controller implement the Strategy Pattern, where the controller is the behavior of the view, and it can be easily switched to another controller if you want different behavior. The View itself also uses. pattern internally to manage the windows, buttons, and other elements of the display: The Composite Pattern.

A Closer Look

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. The Strategy pattern lets the algorithms vary independently from the clients that use it.

• It belongs to the Behavioral category of patterns, scoped on the Object level.

In the MVC, the view and the controller implement this classic pattern where The View is an object that is configured with a strategy which the controller provides. The view is only concerned with the visual aspects of the application and delegates to the controller for any decisions about the interface behavior. The Strategy Pattern also keeps the view decoupled from the model with the use of controller — which is responsible for interacting with the model to carry our user requests so that The View need not know about how any of that logic gets implemented.

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

• just as the Strategy Pattern, the Observer belongs to the Behavioral set of patterns, with the same Object-level scope.

The Model implements the Observer Pattern object to keep interested objects updated when changes occur. By using this pattern, the model maintains complete independence from the views and the controller. It is what allows different views to be used with the same model.

The Composite Pattern composes objects into tree structures to represent part-whole hierarchies. The Composite Pattern allows clients to treat individual objects and compositions of objects uniformly.

• The Composite Pattern belongs to the structural classification of patterns, and just as the former models, scoped at Object-level.

The display(generated by The View) consists of a nested set of windows, panels, buttons, labels, etc. Each component is a composite (such as a window) or a leaf (similar to a button). When the controller tells the view to update, it only has to tell the top view component, and the Composite takes care of the rest.