Showing posts from February, 2012

Design Patterns Series 21 - How to create your own pattern?

By this post we finish our design pattern series. This post gives you a guide for how to build your own pattern in ten easy steps. Just follow along, and you are on the route to fame and fortune. If you don't see an established design pattern where you think there should be one?. You can create your own design pattern, and you can publicize that pattern, getting it into design pattern repositories around the world. Remember, design patterns are supposed to make solutions easier. Don't create a design pattern just for the sake of creating a new pattern if it's not going to be helpful. After all, patterns are supposed to be tools, not hindrances. Pattern Catalog Style : The best way to start anything is with a guide of some kind, and for design patterns, that guide is the Pattern Catalog Style . There are ten sections in a pattern catalog style : Intent Motivation Applicability Structure Participants Collaborations Consequences Implementation/Sample Code Kn

Design Patterns Series 20 - Double Buffer, Recycle Bin, and MVC Patterns

In this post we will explore the last three patterns in our design patterns list, Double Buffer Pattern , Recycle Bin Pattern , and Model/View/Controller (MVC) Pattern. Double Buffer Pattern : Double Buffering is used to avoid screen flicker when you are displaying graphics. The idea is that you perfrom your multi-step graphics creation off-screen in a buffer and then flash the results on the screen when they're complete. The process is called Double Buffering  because the screen display buffer is one buffer and the buffer in which the images are prepared is the second buffer. Use a Double Buffer  when generating revised datasets for an asynchronous processor. When the new data is complete and self consistent, redirect the asynchronous processor to the alternate buffer. Recycle Bin Pattern : If your code uses many objects and the object-creation process is time - and resource - intensive, you might want to use the Recycle Bin Pattern . The idea is that when you're don

Design Patterns Series 19 - Circular Buffer Pattern

Circular Buffer Pattern : Circular Buffer  is perfect when one part of your code stores data and another part reads that data asynchronously. Makes very efficient use of memory. A Circular Buffer  is a memory allocation scheme where memory is reused when an index, incremented modulo the buffer size, writes over a previously used location. A Circular Buffer  makes bounded queue when separate indices are used for inserting and removing data. The queue can be safely shared between threads (or processors) without further synchronization so long as one processor en-queues data and the other de-queues it. You store data items in the various locations in a ring buffer and keep track of reading and writing operations  by labeling one location the Head  and one the Tail . When you store an item in the Circular Buffer you store the item at the tail location, and the tail advances to the next location. When you read an item, you read the item at the current head location, and the

Design Patterns Series 18 - More Design Patterns

This Post will discover more than one design pattern. They are all good patterns, but some are not used these days. And some are just plain hard to implement, like the Interpreter Pattern . Abstract Factory Pattern : The Abstract Factory Pattern describes a factory of factories, or, more properly thought of, an abstract specification for an actual object factory . Here's the problem: sometimes you might need more than one factory to create objects of a similar nature. An Abstract Factory  is usually implemented as an abstract class that real, concrete factories extend. That unifies what the concrete factories do, while allowing leeway to fit differing requirements. The Abstract Factory Pattern  should " provide an interface for creating families of related or dependent objects without specifying their concrete classes. " Prototype Pattern : The Prototype Pattern  says that when it takes a lot of resources, or a lot of code, to create an object, you should co

Design Patterns Series 17 - Mediator Pattern

The Mediator Pattern : The Mediator Pattern supports coordination between objects. it makes the coupling looser by having all objects report state changes to the mediator and take commands from the mediator. When you use a mediator, you are encapsulating the interaction between objects. Each object no longer has to know in detail how to interact with the other objects. The coupling between objects goes from tight and brittle to loose and agile. You can use the Mediator Pattern to " define an object that encapsulate how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. " The  Mediator Pattern  should your first choice as a possible solution any time you have a set of objects that are tightly coupled. If every one of a series of objects has to know the internal details of the other objects, and maintaining those relationships becomes a problem, th