An overview of some commonly used design patterns

1. Binu Bhasuran
Microsoft MVP Visual C#
Blog http://proxdev.com/

2. During the course of a given development project,
it is not uncommon to use the concept of design
patterns to address certain problems relating to
application design and architecture.

3. The origin of software design patterns is attributed
to the work of Christopher Alexander. As a building
architect, Alexander noted the presence of
common problems and related solutions within a
given context. A design pattern, as Alexander
termed this problem/solution/context triad,
enabled an architect to rapidly address issues in a
uniform manner during building design.

4. Although not a magic bullet (if such a thing exists),
design patterns are an extremely powerful tool for
a developer or architect actively engaged in any
development project.

5. Design patterns ensure that common problems
are addressed via well-known and accepted
solutions.
The fundamental strength of patterns rests with
the fact that most problems have likely been
encountered and solved by other individuals or
development teams

6. An object should do one thing and do it well.
This approach ensures that a crisp boundary
exists between objects, enabling greater reuse
and system maintainability.
The need to provide a distinct boundary
between the user interface and business logic is
a common problem that spans applications.

7. The observer is the object responsible for
displaying data to the user.
The subject, on the other hand, represents a
business abstraction that is modeled from the
problem domain.

10. Separating the complex object construction from
its representation.
A common software creational design pattern
that's used to encapsulate the construction logic
for an object.
The intention is to abstract steps of construction of
objects so that different implementations of these
steps can construct different representations of
objects.

11. Break up the construction of a complex object.
Hide the construction process from the
consumer, and allow for additional
representations of the product to be added with
ease.
Separation of concerns and promotes
application extensibility.

12. Break up the construction of a complex object.
Hide the construction process from the
consumer, and allow for additional
representations of the product to be added with
ease.
Separation of concerns and promotes
application extensibility.

15. There are many scenarios in application
development where there are multiple ways of
doing the same operation.
The philosophy of the Strategy pattern is to
have multiple strategies for doing some
operation and let the user choose (or some
algorithm based on input data) the appropriate
strategy to carry out the operation.

18. Defines the skeleton of an algorithm in an
operation, deferring some steps to sub-classes.
The Template Method lets sub-classes redefine
certain steps of an algorithm without changing
the algorithm's structure.

19. Abstract Class.
This will be an abstract class, that will have the
abstract methods of our technical and test rounds,
that will be implemented in the sub-classes based
on the departments and the non-abstract methods
of the group discussion and the HR rounds.
Most importantly, this class will contain a Non
Abstract method that will be calling the abstract
methods or any other method defined in this class,
to outline the flow of the overall process in a step-
wise call to these methods, or you can say, it will
contain the sequence of an algorithm.

20. Concrete Class
These will be concrete implementations of our
abstract steps of the tests and technical
interviews, depending on the departments.

22. The Prototype pattern creates new objects by
cloning one of a few stored prototypes. The
Prototype pattern has two advantages: it speeds
up the instantiation of very large, dynamically
loaded classes (when copying objects is faster),
and it keeps a record of identifiable parts of a
large data structure that can be copied without
knowing the subclass from which they were
created.

25. The role of the Façade pattern is to provide
different high-level views of subsystems whose
details are hidden from users. In general, the
operations that might be desirable from a user's
perspective could be made up of different
selections of parts of the subsystems.

26. Facade pattern hides the complexities of the
system and provides an interface to the client using
which the client can access the system.
This pattern involves a single wrapper class which
contains a set of members which are required by
client. These members access the system on behalf
of the facade client and hide the implementation
details.
The facade design pattern is particularly used when
a system is very complex or difficult to understand
because system has a large number of
interdependent classes or its source code is
unavailable.

29. Command pattern encapsulates a request as an
object and gives it a known public interface.
Command Pattern ensures that every object
receives its own commands and provides a
decoupling between sender and receiver. A
sender is an object that invokes an operation,
and a receiver is an object that receives the
request and acts on it.

30. Command Pattern as "Encapsulate a request as
an object, thereby letting you parameterize
clients with different requests, queue or log
requests, and support undoable operations." So
let us look at the class diagram for the
command pattern and try to understand it.