Design Patterns, Components, And Frameworks

Posted: 04 Mar 2013 05:30 AM PST

How do you communicate to new visitors where they’re located within the hierarchy of your site? Do you use breadcrumb navigation that shows the hierarchy? Do you have code on hand to quickly implement it? Do you rely on a package of code that includes a breadcrumb solution along with a collection of solutions to other common problems?

Design patterns, design components, and design frameworks are all related concepts. They share the goals of modular design to reuse code, be flexible, and separate concerns. They aren’t the same, though. Each answers one of the questions posed above. Let’s take a look at all three and see what each is and what each does.

Schematic of a front controller pattern for a website or web app

What are Design Patterns?

In 1977, architect Christopher Alexander book A Pattern Language: Towns, Buildings, Construction was published. Design patterns were born. They’ve since been extended to fields beyond architecture, most notably, software design.

My first encounter with the idea of design patterns was the book Design Patterns: Elements of Reusable Object-Oriented Software, by authors affectionately known as the Gang of Four or GOF if you really know them well. I’ll be relying on the introduction to their book for this post.

A design pattern describes a recurring problem and then describes the core solution to that problem. It should explain the conditions that led to the problem and why they led to it. It should also explain why the proposed solution is a good one as well as when it might not apply.

At the start of this post I presented the problem of how to communicate where in the hierarchy of your site is visitor is located. Breadcrumb navigation is one design pattern to solve that problem.

Design patterns are generic solutions that have been observed to work for multiple instances of real problems. The multiple observed part is important. It suggests that design patterns aren’t things we invent. They’re things we discover.

Once discovered we can work on them over time to improve them independent of any project we’re working on.

There are 4 essential parts to a design pattern

Pattern name — everything needs a way to refer to it.
Problem — a description of the problem, it’s context, and when to apply the pattern. It might also include a list of requirements.
Solution — that describes the elements that make up the pattern and their relationships, responsibilities, and collaborations.
Consequences — the results and trade-offs in using this pattern. What compromises are involved. This is critical for evaluating design alternatives.

As you can see a design pattern is more than a recipe fix.

Design patterns exist at a higher level of abstraction than their most basic building blocks. For example you might have a navigation pattern for an accordion menu, which is made from a nested lists of links. The links and lists aren’t the pattern. They’re building blocks for the pattern. The pattern is going to be at least one level of abstraction higher than the building blocks that make it up.

Remember though, that while they exist at a higher level of abstraction, design patterns are based on practical solutions. They’ve been shown to work. They aren’t theory. They’re real world solutions to real world problems.

Collect and organize a number of design patterns like breadcrumb navigation and you end up with a pattern language or pattern library.

Pattern Libraries

Here are a few pattern libraries available online. You can see that each pattern follows the 4 essentials of what a design pattern should be.

Design Components

One thing you may have noticed in the section above is there was no mention of code. Again design patterns are abstract solutions. A component on the other hand is the concrete implementation of a design pattern. It’s the real visual thing that ends up in a design.

When you decide that your breadcrumb navigation should be a group of html link elements wrapped in a nav container and then styled in some particular way you’ve implemented the design pattern and built a design component. On a future project you can copy that same code, paste it into the new project, and have breadcrumb navigation.

You probably wouldn’t want those breadcrumbs to look exactly the same on each site, so you’d provide a way to change a few things here and there. Ideally your component would be flexible enough to allow for modification. You might also implement the pattern in several ways to provide options for that next project.

A component takes the description of the pattern solution and develops real code that can be used in a design.

If you search the web for design patterns, I think much of what you’ll find will really be design components. They’ll be absent the explanations and descriptions and instead offer a block or two of code for you to copy and modify.

Some will simply show you the component visually on the page with the expectation you’ll view the source for the code. These component libraries are certainly very useful, but they are distinct from pattern libraries.

Componente Libraries

Here are a few libraries that are more component than pattern. You’ll notice they offer code or examples, but lack the 4 essentials of a design pattern.

Design Frameworks

A design pattern is an abstract solution to a specific problem. A component is a concrete implementation of a single design pattern. A framework is a collection of components. It’s also packaged and typically supported with tools and APIs.

The Gang of Four offer these differences between patterns and frameworks.

Design patterns are more abstract than frameworks.
Design patterns are smaller architectural elements than frameworks.
Design patterns are less specialized than frameworks.

Note the last item above. Frameworks tend to be more specialized. When you use a design framework across sites, those sites often end up looking similar. They often function similarly. A framework probably won’t include multiple breadcrumb components, favoring instead a single component.

That doesn’t mean frameworks have to look and function exactly the same way. They’ll generally be flexible enough to offer some variety and allow modification. They are more specialized than design patterns though, which provide no specific code for how to implement the pattern.

Frameworks

Below are a few frameworks you’ve likely heard of and have possibly used.

Summary

Design patterns are abstract solutions that have been observed to work for concrete problems. They define the conditions for the problem, the solution used, and any consequences that might result. They lead to efficiency and reuse. Collect and organize enough patterns and you have a pattern library or pattern language.

Components are concrete implementations of design patterns. They provide code you can copy and paste directly into a project. Ideally they’ll be flexible and offer a mechanism for modification. There can be multiple components for a single design pattern.

Frameworks combine components and package them together. They provide APIs and tools for using the framework and tend to be specialized in nature. Their specialization can lead to a greater chance of similarity in sites that use a particular framework.

The post Design Patterns, Components, And Frameworks appeared first on Vanseo Design.