Design patterns
Topics related to Design patterns:
Getting started with Design patterns
This section provides an overview of what design-patterns is, and why a developer might want to use it. Examples may provide a graphical representation of the pattern, a scenario consisting of a problem given a context in which a pattern can be used and mention possible trade offs.
It should also mention any large subjects within design-patterns, and link out to the related topics. Since the Documentation for design-patterns is new, you may need to create initial versions of those related topics.
Strategy Pattern
Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
-- GOF 1994
Decorator pattern
Dependency Injection
The basic idea behind dependency injection is to create more loosely coupled code. When a class, rather than newing up its own dependencies, takes in its dependencies instead, the class becomes more simple to test as a unit (unit testing).
To further elaborate on loose coupling - the idea is that classes become dependent on abstractions, rather than concretions. If class A depends on another concrete class B, then there is no real testing of A without B. While this sort of test can be OK, it does not lend itself to unit testable code. A loosely coupled design would define an abstraction IB (as an example) that class A would depend on. IB can then be mocked to provide testable behavior, rather than relying on the real implementation of B to be able to provide testable scenarios to A.
Tightly coupled example (C#):
public class A
{
public void DoStuff()
{
B b = new B();
b.Foo();
}
}
In the above, class A depends on B. There is no testing A without the concrete B. While this is fine in an integration testing scenario, it is difficult to unit test A.
A more loosely coupled implementation of the above could look like:
public interface IB
{
void Foo();
}
public class A
{
private readonly IB _iB;
public A(IB iB)
{
_iB = iB;
}
public void DoStuff()
{
_b.Foo();
}
}
The two implementations seem quite similar, there is however an important difference. Class A is no longer directly dependent on class B, it is now dependent on IB. Class A no longer has the responsibility of newing up its own depedencies - they must now be provided to A.
Builder Pattern
Separates the construction of a complex object from its representation so that the same construction process can create different representations.
- Separate the logic from representation.
- Reuse logic to work with different set of data.
Singleton
The Singleton design pattern is sometimes regarded as "Anti pattern". This is due to the fact that it has some problems. You have to decide for yourself if you think it is appropriate to use it. This topic has been discussed several times on StackOverflow.
See: http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons
Command pattern
Observer
What is the intent ?
- Adopt the principle of separation of concerns.
- Create a separation between the subject and the observer.
- Allow multiple observers to react to change a single subject.
What is the structure ?
- Subject provides a way to Register, Unregister, Notify.
- Observer provides a way to update.
Facade
Bridge Pattern
Composite pattern
Visitor Pattern
Adapter
Template Method
Prototype Pattern
The prototype pattern is a creational design pattern. It is used when the type of objects to create is determined by a prototypical instance, which is "cloned" to produce new objects.
This pattern is used when a class need a "polymorphic (copy) constructor".
Static factory method
Chain of Responsibility
Null Object pattern
Null Object is an object with no referenced value or with defined neutral behaviour. Its purpose is to remove the need of null pointer/reference check.
Mediator Pattern
Monostate
As a side note, a few advantages of the Monostate pattern over the Singleton:
- There is no 'instance` method to be able to access an instance of the class.
- A
Singletondoes not conform to the Java beans notation, but aMonostatedoes. - Lifetime of instances can be controlled.
- Users of the
Monostatedon't know that they are using aMonostate. - Polymorphism is possible.
Repository Pattern
About the implementation of IEnumerable<TEntity> Get(Expression<Func<TEntity, bool>> filter): The idea of this is to use Expressions like i => x.id == 17 to write generic requests. It is a way to query data without using the specific query language of your technology. The implementation is rather extensive, therefore you might want to consider other alternatives, like specific methods on your implemented repositories: An imaginary CompanyRepository could provide the method GetByName(string name).
Data Access Object(DAO) design pattern
blackboard
Multiton
Multitonitis
Same as Singleton, Multiton can be considered a bad practice. However, there are times when you can use it wisely (for example, if you building a system like ORM/ODM to persist multiple objects).
Iterator Pattern
Publish-Subscribe
MVC, MVVM, MVP
It can be argued that MVC and related patterns are actually software architecture patterns rather than software design patterns.
SOLID
Composite pattern
The composite pattern applies when there is a part-whole hierarchy of objects and a client needs to deal with objects uniformly regardless of the fact that an object might be a leaf (simple object) or a branch (composite object).
Open Close Principle
Like every principle Open Close Principle is only a principle. Making a flexible design involves additional time and effort spent for it and it introduce new level of abstraction increasing the complexity of the code. So this principle should be applied in those area which are most likely to be changed. There are many design patterns that help us to extend code without changing it, for example decorator.