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.
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 theexperience of selection wrong patterns sometimes)•Don’t use the pattern unless you are sure that pattern adds value!!!
Apply the pattern1. 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.
What is Strategy Pattern?•The strategy pattern is useful for situations where it is necessary to dynamicallyswap the algorithms used in an application. The strategy pattern is intended toprovide a means to define a family of algorithms, encapsulate each one as anobject, and make them interchangeable.
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.
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)
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.
Model–view–controllerModel–View–Controller (MVC) is an architectural pattern used in software engineering.It isolates business logic from input and presentation, permitting independentdevelopment, 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.
Example1- The user interacts with the user interface (Provided by the view) in someway (for example, presses a mouse button).2-The controller handles the input event from the user interface, often via aregistered handler or callback.3- The controller notifies the model of the user action, possibly resulting ina change in the models state. (For example, the controller updates the usersshopping cart.)4- A view uses the model indirectly to generate an appropriate user interface(for example, the view lists the shopping carts contents). The view gets itsown data from the model. The model and controller have no directknowledge of the view.
RepositoryMediates between the domain and data mapping layers using a collection-likeinterface for accessing domain objects.A Repository mediates between the domain and data mapping layers, acting likean in-memory domain object collection. Client objects construct queryspecifications declaratively and submit them to Repository for satisfaction.Objects can be added to and removed from the Repository, as they can from asimple collection of objects, and the mapping code encapsulated by theRepository will carry out the appropriate operations behind the scenes.Conceptually, a Repository encapsulates the set of objects persisted in a datastore and the operations performed over them, providing a more object-orientedview of the persistence layer. Repository also supports the objective of achieving aclean separation and one-way dependency between the domain and datamapping layers.
BenefitsA system with a complex domain model often benefits from a layer, such as the one provided byData Mapper , that isolates domain objects from details of the database access code. In suchsystems it can be worthwhile to build another layer of abstraction over the mapping layer wherequery construction code is concentrated. This becomes more important when there are a largenumber of domain classes or heavy querying. In these cases particularly, adding this layer helpsminimize duplicate query logic.