tag : design patterns

JavaScript

JavaScript Design Patterns: Proxy

This is the 9th installment of the JavaScript Design Patterns series and today we’re featuring the Proxy pattern. The word “proxy” can be defined as a substitute, and that essentially explains what a proxy is. A proxy is an object that has the same interface as another object and is used in place of that other object. The only question is why we would use a proxy instead of the original object.

JavaScript

JavaScript Design Patterns: Factory Part 2

In the last post, I started talking about the Factory Design Pattern, which creates objects for you, generally all of which follow the same interface. So far we’ve covered the Simple Factory, which creates this functionality in a Singleton object, which is the _simplest _way of creating a Factory, hence its nomenclature (I love that word). This time I’ll show you the true Factory.

JavaScript

JavaScript Design Patterns: Factory

Another post, another JavaScript design pattern. Today we feature the Factory pattern. The Factory pattern is one of my favorite patterns, especially the “simple factory”, which I’ll explain later. Factories – in real life as well as within the programming world – create objects. It helps clean up your code by removing all of the new operators.

JavaScript

JavaScript Design Patterns: Decorator

Today I’d like to show another JavaScript Design Pattern: the Decorator, which is a way to add features to objects without subclassing or adding extra attributes. This post continues the JavaScript Design Patterns series that I started several months ago. If you’re new to the JavaScript Design Patterns series that I’m running here, you can find a list of the previous and upcoming posts in the series at the bottom of the post.

JavaScript

JavaScript Design Patterns: Adapter

Another post, another JavaScript design pattern. This time we’re featuring the Adapter pattern. If you’d like to view the previous posts from this series, you can check out the links at the bottom of this page. This mean, green, fighting machine can transform interfaces. Ok, it doesn’t exactly transform an interface, it really just creates a new object/function that adapts the interface of an existing object/function to match what the code knows how to use.

JavaScript

JavaScript Design Patterns: Facade

In our 4th installment of the JavaScript Design Patterns Series, we’ll be taking a look at the Facade pattern. Whether you know it or not, I can almost guarantee that you’ve used the Facade pattern if you’ve been programming in any language for more than a second (that might be a bit of a hyperbole, but you’ll forgive me, right?). You can define the Facade pattern as a piece of code that simplifies a more complex interface. You can pretty much call any form of abstraction a facade. Have you ever made a named function that had more than one line of code within it? Yup, that’s technically an example of the Facade pattern.

JavaScript

JavaScript Design Patterns: Composite

My last post was about the Bridge Design Pattern, which continued the JavaScript Design Patterns series that started off with the Singleton. Today we’ve moved onto the Composite Pattern. Composites are quite useful. By definition of the word “composite”, Composites are _composed _of multiple parts to create one whole entity.

JavaScript

JavaScript Design Patterns: Bridge

In my last blog post article I discussed the Singleton Design Pattern and how it is used in JavaScript. This time around the Bridge design pattern is poking its head up and asking for a bit of attention, making it the second in the JavaScript Design Patterns series. Every place I’ve read about the Bridge pattern likes to quote the Gang of Four directly in their description of what the Bridge pattern is, so I figure why not me too? The Bridge pattern should “decouple an abstraction from its implementation so that the two can vary independently.” Bridges are quite beneficial in event-driven applications, which are quite common in JavaScript. Considering that fact, it’s surprisingly one of the most underused design patterns.

JavaScript

JavaScript Design Patterns: Singleton

This is the first in what should be a pretty long series about JavaScript design patterns. In 1995, Erich Game, Richard Helm, Ralph Johnson and John Vlissides (known as the Gang of Four) published Design Patterns: Elements of Reusable Object-Oriented Software, a book cataloging recurring solutions to common dilemmas in software architecture and design. It also started a common vocabulary for referring to these solutions. If you’d like to know more you can find it on Wikipedia.