You might think a software designer simply dreams up unique ideas based on a problem given to them by a client or a problem they create. The reality is a little different.

There are no truly unique software designs, for example. And some design solutions work more often than other solutions. As a result, software designers often work within a small universe of possible solutions based on their education, experience, and personal preferences.

Consider music as one instructive example. There are only so many instruments and, for each instrument, only so many notes to play and hear. Plus the combination of instruments and notes is finite. Yet the variety of music we hear in our lives is astounding even if the instruments and notes are limited. One reason, of course, is that musicians are human beings who might play a note or instrument differently from another musician. But the limits to instruments and notes, the constraints, also give us an amazing variety of possible music.

Software design has the same dynamic, a limited number of possible solutions yet an amazing variety of actual solutions you see in the real world. These constraints are what give shape to wonderful website and software application designs.

One constraint to possible software design solutions are patterns. These divide into design patterns and anti-patterns. Both kinds can yield interesting solutions.

What’s a Design Pattern?

Design patterns for software grew out of architecture design patterns. These patterns are ways to solve common problems found in architecture, software design, interaction design, and other disciplines. Instead of reinventing the wheel, software designers often look to see if a design pattern already exists.

If a pattern exists, the software developer likely will either use the pattern as is or adapt it. The main benefit of a pattern for people who use software is familiarity. If you’ve ever used Microsoft Word, for example, and need to create a new document file, you know to go to the File menu at the top left and select New then File from the submenus. Other wordprocessing software typically use the same pattern because people are used to it.

There are design patterns to create and structure software, as well as behavior and communication between parts of the software.

Here are some examples of software design patterns to solve the problem of sharing files and data that is updated while others might read the data:

Locks — When a resource is used by multiple parts of an application, the resource should be locked when in use.

Read-Write Locks — When a resource is used by multiple parts of an application, the resource should be locked only when modified. Reading the resource does not trigger a lock.

While the Read-Write Locks pattern is more complex, because the software must tell the difference between reading a resource and modifying a resource, in some cases this complexity is needed. In other cases, the simplicity of the Locks pattern works fine.

What’s a Design Anti-Pattern?

Probably the best thing about anti-patterns are the names of these patterns: Analysis Paralysis, Cargo Cult Programming, Death March, Group Think, Throw it Over the Wall, and Vendor Lock-In, to name a few. As you can tell, anti-patterns are software development processes that do not work.

Analysis Paralysis, for example, is simply an individual or group that over-thinks possible solutions. The trick with software design is to balance the need for problem analysis with the need to create a solution and solve the problem. Analysis Paralysis happens when the analysis portion takes so long there is little or no time to create and test solutions.

Anti-patterns translate well to other activities beyond software design and development, as you might guess.

Are Patterns a Good Thing?

One complaint about design patterns is that they limit possible solutions. There are a number of ways to design software. Patterns appear to work best as part of an overall design process that includes looking at different ways to solve a problem.

The Model-View-Controller (MVC) concept, for example, takes a broad view of the software application and lets designers organize functionality and code in an efficient way. The Model manages the data, logic, and rules of the application. Views are any output of data within the application, for example, a success or failure message, a screen, or a chart. The Controller handles inputs to the application and converts inputs into commands for the Model or View.

This simple MVC concept is itself a design pattern and predates the first book about software design patterns, published in 1994. MVC is a simple and logical way to organize the pieces of a software application.

Patterns are a useful way to state problems in software development but not complete solutions. Programmers and others must actually design and code software, at times violating a pattern to get the job done in a way users expect and want.

Learn More

Software Design Patterns

http://en.wikipedia.org/wiki/Software_design_pattern
http://sourcemaking.com/design_patterns

Software Design Anti-Patterns

http://en.wikipedia.org/wiki/Anti-pattern
http://sourcemaking.com/antipatterns

Model-View-Controller Pattern

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Design Patterns

http://en.wikipedia.org/wiki/Design_pattern