Design patterns session presentation. Presented in Horizonssoftware http://harouny.wordpress.com/

1. Part 2
Prepared By: Ahmed EL-Harouny

2. Agenda
 What is design patterns?
 Strategy Pattern
 Demo
 What is architecture patterns?
 Model-View-Controller Pattern
 Demo
 Repository Pattern
 Demo
 Questions?

4. Design Patterns in life

5. Design Patterns In Programming

6. Why?
•Experience reuse.
•Don’t reinvent the wheel.
•Patterns allows you to stand on the shoulder of giants.
•We can focus on creative solutions.
•Mix patterns to come up with new combinations.
•Common Language, patterns allows us to communicate effectively.

7. How?
•Determine the need for a pattern.
•Not all situations need patterns.
•Ask yourself; will the pattern will add value and simplify the solution?
•Find the right pattern. (The proper selection of patterns comes with the
experience of selection wrong patterns sometimes)
•Don’t use the pattern unless you are sure that pattern adds value!!!

8. Apply the pattern
1. Get some free code.
2. Play with it in a simple test project to understand the pattern well. (get a
sense of the gained value)
3. Implement the pattern in your code.

10. What is Strategy Pattern?
•The strategy pattern is useful for situations where it is necessary to dynamically
swap the algorithms used in an application. The strategy pattern is intended to
provide a means to define a family of algorithms, encapsulate each one as an
object, and make them interchangeable.

11. Benefits
•Allows us to divide up the behaviors
•Used to provide a model for quickly updating and changing behaviors as
needed.
•Allows for a wide variety of behaviors without having to maintain the same
behavior in multiple classes.

12. When to use it?
In a scenario where you have objects that share some basic functionality
but have a lot of different behaviors; without strategy pattern you have
two options each one have a drawback:
1. Classic Inheritance (you have to add behaviors to objects that doesn’t
need . Or reduce that amount of shared functionality in base classes
which will lead to maintainability problems)
2. Interfacing (you have to re-implement behaviors in all classes which
will lead to maintainability problems)

15. Architectural Patterns
 Architectural pattern are software patterns that offer well-established
solutions to architectural problems in software engineering. It gives
description of the elements and relation type together with a set of
constraints on how they may be used. An architectural pattern expresses a
fundamental structural organization schema for a software system, which
consists of subsystems, their responsibilities and interrelations. In
comparison to design patterns, architectural patterns are larger in scale.
Some architectural patterns are implemented in software frameworks which
can be used to more quickly build specific programs.

17. Model–view–controller
Model–View–Controller (MVC) is an architectural pattern used in software engineering.
It isolates business logic from input and presentation, permitting independent
development, testing and maintenance of each.
It is common to split an application into separate layers that can be analyzed, and
sometimes implemented, separately.
MVC is often seen in web applications, where the view is the actual HTML or
XHTML page, and the controller is the code that gathers dynamic data and
generates the content within the HTML or XHTML. Finally, the model is
represented by the actual content, which is often stored in a database or in XML
nodes, and the business rules that transform that content based on user actions.

18. Example
1- The user interacts with the user interface (Provided by the view) in some
way (for example, presses a mouse button).
2-The controller handles the input event from the user interface, often via a
registered handler or callback.
3- The controller notifies the model of the user action, possibly resulting in
a change in the model's state. (For example, the controller updates the user's
shopping cart.)[5]
4- A view uses the model indirectly to generate an appropriate user interface
(for example, the view lists the shopping cart's contents). The view gets its
own data from the model. The model and controller have no direct
knowledge of the view.

21. Repository
Mediates between the domain and data mapping layers using a collection-like
interface for accessing domain objects.
A Repository mediates between the domain and data mapping layers, acting like
an in-memory domain object collection. Client objects construct query
specifications declaratively and submit them to Repository for satisfaction.
Objects can be added to and removed from the Repository, as they can from a
simple collection of objects, and the mapping code encapsulated by the
Repository will carry out the appropriate operations behind the scenes.
Conceptually, a Repository encapsulates the set of objects persisted in a data
store and the operations performed over them, providing a more object-oriented
view of the persistence layer. Repository also supports the objective of achieving a
clean separation and one-way dependency between the domain and data
mapping layers.

22. Benefits
A system with a complex domain model often benefits from a layer, such as the one provided by
Data Mapper , that isolates domain objects from details of the database access code. In such
systems it can be worthwhile to build another layer of abstraction over the mapping layer where
query construction code is concentrated. This becomes more important when there are a large
number of domain classes or heavy querying. In these cases particularly, adding this layer helps
minimize duplicate query logic.

23. Diagram