Design Patterns: Consultant Hype or Best Practices?
It is not always obvious that we should use design patterns. We have to use our professional judgement, with an eye to simplicity. Presented at the second York Region PHP Group on Nov 14, 2016
11 Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book describing software design patterns. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk. It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages. The authors are often referred to as the Gang of Four (GoF).[1] https://en.wikipedia.org/wiki/Design_Patterns
14 Design patterns provide solutions to common software design problems. In the case of object- oriented programming, design patterns are generally aimed at solving the problems of object generation and interaction, rather than the larger scale problems of overall software architecture. They give generalised solutions in the form of templates that may be applied to real-world problems. http://www.blackwasp.co.uk/gofpatterns.aspx
15 Design patterns are a powerful tool for software developers. However, they should not be seen as prescriptive specifications for software. It is more important to understand the concepts that design patterns describe, rather than memorising their exact classes, methods and properties. It is also important to apply patterns appropriately. Using the incorrect pattern for a situation or applying a design pattern to a trivial solution can overcomplicate your code and lead to maintainability issues. http://www.blackwasp.co.uk/gofpatterns.aspx
17 Creational Patterns Instantiate single objects or groups of related objects. 1. Abstract factory 2. Builder 3. Factory method 4. Prototype 5. Singleton http://www.blackwasp.co.uk/gofpatterns.aspx
21 Re-usable code? Well, not quite… A design pattern is not a detailed spec. Rather, one may think of it as a description of the accumulated experience…
22 Each pattern describes a problem which occurs over and over… and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander AIS, 1977 https://en.wikipedia.org/wiki/Christopher_Alexander
26 Anti Pattern: An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by Andrew Koenig,[3] was inspired by a book, Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective. (https://en.wikipedia.org/wiki/Anti-pattern)
27 9 Anti-Patterns Every Programmer Should Be Aware Of 1. Premature Optimization 2. Bikeshedding 3. Analysis Paralysis 4. God Class 5. Fear of Adding Classes 6. Inner-platform Effect 7. Magic Numbers and Strings 8. Management by Numbers 9. Useless (Poltergeist) Classes (http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with- examples.html)
28 Best Practices or Bravo Sierra? What If… It took more code to do the design pattern than the actual thing you are coding? You were told that you suck as a programmer because you did not use a well known design pattern? You could code faster sticking with how a framework does it, but you are sure that you would be better off with a “framework agnostic” solution that uses a better implementation of an established design pattern?
29 Does blind adherence to design patterns impart guaranteed benefits? If it did, then IMO I doubt this subject would be controversial enough to be debated so passionately for over 2 decades. And, I suspect that I would have been subject to major grief for the title of this talk.
30 Professional Judgement • Knowledge • Experience • Objectivity It’s not always obvious what design patterns to introduce into your software. You have to make decisions.
31 Technical Debt The extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. (https://www.techopedia.com/definition/27913/technical-debt)
32 Technical Debt Technical debt is a metaphor that equates software development to financial debt. Imagine that you have a project that has two potential options. One is quick and easy but will require modification in the future. The other has a better design, but will take more time to implement. In development, releasing code as a quick and easy approach is like incurring debt - it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future. Taking the time to refactor is equivalent to paying down principal. While this takes time in the short run, it also decreases future interest payments. (https://www.techopedia.com/definition/27913/technical-debt)
33 Technical Debt Ward Cunningham, a programmer who is also known for developing the first wiki, describes this concept in 1992: "Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." (https://www.techopedia.com/definition/27913/technical-debt)
35 Automated Software Testing, the Composer Eco-System, and Continuous Integration It’s not 1994. As Chris Hartjes said at our inaugural meet-up, we need to think about Continuous Integration. We have to think about the software pipeline. Getting code from commit to production. Software has to be test-able. With the composer eco-system exploding, when do we use external packages?
39 Thank you! Questions? Contact me at: • @bobbloom • LaSalleSoftware.com • [email protected] • Github.com/LaSalleCMS This presentation was created using Powerpoint (!) This presentation created for the November 14, 2016 York Region PHP Group meet-up. See YorkRegionPHP.ca and Meetup.com/York-region-php-user-group. Design Patterns: Consultant Hype or Best Practice? Copyright 2016 South LaSalle. This work is licensed under Creative Commons Attribution ShareAlike 4.0 International. For uses not covered under this license, please contact the author.
hiragram
sakawe_ee
tosuri13
azukiazusa1
codeforeveryone
rei315
kubotak
yoshyum
nealle
lnit
kazatohiei
74th
palkan
eileencodes
tammyeverts
zakiyama
addyosmani
afnizarnur
marcduiker
colly
philnash
mraible
lara
kastner
