What design pattern do you use the most?

Question

The reason I ask is because many applications, particularly web applications, do things in a similar fashion. Of course, the pattern used varies with the task at hand, perhaps even a combination of patterns. I'm guessing that many of us use a primary pattern for apps that we start out from scratch and I'm wanting to see if there is a commonality.

I'm also curious if others are coming to the same conclusion on what patterns they feel comfortable with and which ones work well in the test of time.

Edit: Many of the responses so far are architectural patterns. I'm also really interested in creational design patterns.

Answer 1

I think the MVC approach is tried and true at this point, especially for web apps. I'm a fan of the CodeIgniter implementation of it.

Answer 2

MVC followed closely by Strategy

Answer 3

Undoubtedly the most common design pattern in use is the Big Ball of Mud.

Answer 4

By far, the pattern I've dealt with most of all at the various places I've worked is the

Ball of Mud Pattern, and its brother Stovepipe System

Answer 5

MVC, Delegate, Observer

Answer 6

Without a doubt, the one I utilize the most would be the Iterator. It is used so often that it doesnt have the aura of a Pattern anymore.

Answer 7

• State
• Facade
• Iterator
• Strategy
• Data Transfer Object
• Data Access Object
• ... and all of Domain-Driven Design

Answer 8

Patterns I use constantly:

• State: The state pattern is a behavioral software design pattern, also known as the objects for states pattern. This pattern is used to represent the state of an object. This is a clean way for an object to partially change its type at runtime.
• Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library.
• Iterator: Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation. An Iterator object encapsulates the internal structure of how the iteration occurs.
• Strategy: The strategy pattern (also known as the policy pattern) allows algorithms can be selected at runtime.
• Data Transfer Object: Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database.
• Data Access Object: An object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database. It provides a mapping from application calls to the persistence layer. This isolation separates the concerns of what data accesses the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), and how these needs can be satisfied with a specific DBMS, database schema, etc. (the implementation of the DAO).
• Domain-Driven Design:
  • Entities (a.k.a. Reference Objects): An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity.
  • Value Objects: An object that describes a characteristic of a thing. Value Objects have no conceptual identity. They are typically read-only objects and may be shared using the Flyweight design pattern.
  • (Domain) Services: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.
  • Repositories: methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
  • Factories: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.
• Chain of responsibility: the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains a set of logic that describes the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.
• Provider pattern/model: Used to allow an application to choose from one of multiple implementations in the application configuration, for example, to provide access to different data stores to retrieve login information, or to use different storage methodologies such as a database, binary to disk, XML, etc. The .NET extensible provider model allows a "component" to have multiple implementations using an abstract factory pattern approach. Providers are a subclass of the ProviderBase class and typically instantiated using a factory method.
• Builder: The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects.
• Dependency Injection: the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to describe the mechanism more clearly.
• Inversion of Control (similar to DI): an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.

Principles that should be adhered too:

• SOLID
  • S SRP: Single responsibility principle
  • O OCP: Open/closed principle
  • L LSP: Liskov substitution principle
  • I ISP: Interface segregation principle
  • D DIP: Dependency inversion principle
  • DRY or DIE: Don't repeat yourself
  • YAGNI: If you aren't going to need it then don't build it. Don't write code that is not yet going to be use (TDD is helpful here)

Patterns that others use humorously:

• DDD: Design Driven Development: where your software project is driven by a photoshop designer pushing new colorful ideas your way which you ultimately have to make a reality in code
• RDD: Resume Driven Development: using a new technology simply for the cause of listing it on your resume
• BBOM: A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.
• Stovepipe System: A legacy system that is an assemblage of inter-related elements that are so tightly bound together that the individual elements cannot be differentiated, upgraded or refactored. The stovepipe system must be maintained until it can be entirely replaced by a new system.

Answer 9

Use the gray tee-shirt pattern, with just a touch of pizza sauce and NOS (ahh... the sweet taste of donkey sweat)

Answer 10

I don't concern myself with names of techniques but what the job is. If it happens to fall into some named pattern, so be it, but I wouldn't know what that is. I don't constrain myself to such things.