Design patterns
Download as PPTX, PDF1 like359 views
Design patterns are commonly used to address problems relating to application architecture and design. The concept originated from Christopher Alexander's work noting common building design problems and solutions. Design patterns ensure problems are addressed through well-known solutions, and most problems have likely been solved before. Common patterns include observer/subject to separate user interface from business logic, singleton to control object construction, strategy to allow multiple algorithms, and template method to define an algorithm's structure. The facade pattern provides different views of subsystems to users by hiding implementation details. The command pattern encapsulates requests as objects with a known interface to decouple senders and receivers.
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.
Editor's Notes
- #7: One of the overriding principles of object-oriented development is the proper assignment of responsibility in the given application. Each object in the system should focus on a discrete abstraction within the problem domain and nothing more. In short, 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. One area where the proper separation of responsibility is of special importance is the interaction between the user interface and the underlying business logic. During the development of an application, it is quite common for user interface requirements to change rapidly without an associated impact on the rest of the application. In addition, it is also likely that the business requirements will change without regard to the user interface. In many cases, both sets of requirements will change, as anyone with substantial development experience well knows. Without the benefit of separation between the UI and remainder of the application, modification of either portion may adversely impact the whole.
- #8: One of the overriding principles of object-oriented development is the proper assignment of responsibility in the given application. Each object in the system should focus on a discrete abstraction within the problem domain and nothing more. In short, 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. One area where the proper separation of responsibility is of special importance is the interaction between the user interface and the underlying business logic. During the development of an application, it is quite common for user interface requirements to change rapidly without an associated impact on the rest of the application. In addition, it is also likely that the business requirements will change without regard to the user interface. In many cases, both sets of requirements will change, as anyone with substantial development experience well knows. Without the benefit of separation between the UI and remainder of the application, modification of either portion may adversely impact the whole.
- #9: One of the overriding principles of object-oriented development is the proper assignment of responsibility in the given application. Each object in the system should focus on a discrete abstraction within the problem domain and nothing more. In short, 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. One area where the proper separation of responsibility is of special importance is the interaction between the user interface and the underlying business logic. During the development of an application, it is quite common for user interface requirements to change rapidly without an associated impact on the rest of the application. In addition, it is also likely that the business requirements will change without regard to the user interface. In many cases, both sets of requirements will change, as anyone with substantial development experience well knows. Without the benefit of separation between the UI and remainder of the application, modification of either portion may adversely impact the whole.
- #17: Strategy: This is the interface common to all algorithms. Context uses this interface to perform the operations. ConcreteStrategy: This is the class that implements the actual algorithm. Context: This is the client application that performs the decision making for which strategy should be used and uses the Strategy interface (which is referring to a ConcreteStrategy object) to perform the operations.
- #30: Undo & redo