Download to read offline
Applying design patterns
- 2.
- 3. When does itcame to light? • The applying design patterns method has become increasingly popular in 1990’s. • Due to some ground-breaking presentations and books on the subject released to the object-oriented world. • The book: Elements of Reusable Object-Oriented Software, by E. Gamma, R. Helm, R. Johnson, and J. Vlissides • This book gave 23 patterns each with a solution for a recurring problem faced in object-oriented design.
- 4. What are designpatterns? In software development, a design pattern is a written document that describes a general solution to a design problem that recurs repeatedly in many projects In object-oriented programming, a pattern can contain the description of certain objects and the general approach to how to solve the problem. Programmer's can use more than one design pattern to solve a specific problem. A collection of patterns is called a pattern framework.
- 5. What is abad design? • Software design principles,set a guideline to avoid bad design. • These design principles was formulated by ROBERT MARTIN. • According to robert martin there are 3 characteristic of bad design that should be avoided: 1. Rigidity-it affects the too many parts of a system 2. Fragility-unexpected parts of a system may break 3. Immobility-other than current application it can work in other
- 6. Principles of designpatterns: Open close principle Dependency inversion principle Interferance segregation principle Single responsibility principle Liskov’s substitution principle
- 7. Open close principle •Software entities like classes, modules and functions should be open for extension but closed for modifications • Example: library management system. • It can be ensured by use of abstract classes and concrete classes. • This will enforce having Concrete Classes extending Abstract Classes instead of changing them. • Some particular pattern are template pattern and strategy pattern
- 8. Dependency inversion principle High-level modulesshould not depend on low-level modules. Both should depend on abstractions Abstractions should not depend on details. Details should depend on abstractions. when a software module need some other module, it initializes and holds a direct reference and couple the two modules. Again in order to decouple, first module provides a hook to second module
- 9. Interface segregation principle: Clientsshould not to be forced to depend on the interface that they don’t use. when we write our interface we should take care only methods that should be there. Example: if we add a class worker and add a method lunch break, all the workers have to implement it . What is the case if it is a robot? When any method is not specific to the interface we call it as fat or polluted. we should avoid them.
- 10. Single responsibility principle oAclass should have only one reason to change. oWhen we want to change anything in a class we need to split it into two classes and repair it. oWhen there is a need to change the class with more responsibility; it may affect the functionality of classes.
- 11. Liskov’s substitution principle •Derived types must be completely substitutable for their base types. • It is the extension of open close principle • The new derived class should be able to replace the base class without any change in code.
- 12. Applying design patterns: Theapplying design patterns include; 1. State-each is represented as Not ready Ready Pending Submitted 2. Observers- to update,edit and submit
- 14. Requirements: When a orderis first created,it is not ready for online submission as it is missing required information. It is ready to submit when it is filled with required information Pending order is a order that was interrupted admist online submission. Once a order is submitted it cannot be edited and resubmitted.
- 15. Learning process: • Studydesign patterns with genuine interest to deeply understand and apply them in real-world scenarios. • Look for every opportunity to apply in them • Learn to recognize when a design pattern is absolutely necessary and helpful and when it is just over-engineering.
- 16. How to applyX design pattern in Y scenarios ? • Do all of you decide design pattern before coding? • Is there is any design patterns which you have applied after coding? • What are the design patterns which is predominantly used? • What are the DPs that you apply while tweaking code? • Are there any hints in code (technical not functional stuff) that suggest that you should apply a DP ? • Do you use any Micro-DPs that makes you feel good about the code you've written ?
- 17. Design patterns includethe following types of information: 1. Name that describes the pattern 2. Problem to be solved by the pattern 3. Context, or settings, in which the problem occurs 4. Forces that could influence the problem or its solution 5. Solution proposed to the problem 6. Context for the solution 7. Rationale behind the solution (examples and stories of past successes or failures often go here) 8. Known uses and related patterns 9. Author and date information 10. References and keywords used or searching
- 18. Critical things indesign patterns: Increase the speed of the design process. Ensure that lessons learned are adopted. Reduce overall costs by finding ways for certain capabilities to be reused.
- 19. How to createmaster design patterns? Create your own design pattern taxonomy Come with a standard approach for pattern visualization Come up with standard template for pattern description Standardize your own design terminology Align your design patterns with your ALM.