Design Pattern Abuse

Design patterns should emerge from your code, not be forced upon it, but too many times we are blinded by our own ambitions. Even when we desire to do implement the best possible solutions, we misuse the greatest tools we have at our disposal.

This presentation discusses some of the ways that we abuse design patterns, so that we can recognize our mistakes and learn to use design patterns in the most beneficial ways possible.

Transcript

1. Design Pattern ABUSE Patrick Delancy
2. NOTICE!!! This slide deck has been adapted from a presentation that was intended to be given live, in person…. like with a real person in front of real people. You know… breathing the same air and all that. The key points have been transcribed onto separate slides, so you still get some benefit from reading through it all, but you are still missing out on all of the great stories, witty banter, hilarious costumes, stunning arias … or something like that. If you REALLY want to get the most out of this presentation, go to patrickdelancy.com and ask him to come give it to your group!
3. The Almighty Pattern
4. Some people love patterns, some people hate them. I do both.
5. I love the idea of known “good” solutions to common problems.
6. I hate how the harder I try to use them, the worse my code suffers.
7. The right ways to use Design Patterns ll ll
8. Exessorize “If a little bit is good, more must be better!”
9. Start by using a pattern well, but extending that use so far that the product suffers.
10. Blinder Junkie This pattern is awesome! It can do anything!
11. Become so enamored by a pattern that you don’t consider other options to solve a problem.
12. Off Fleek So on fleek, you fell off the other side.
13. Work hard to implement a pattern perfectly, but take it too far.
14. Pokeball Gotta use ‘em all!
15. Measure success (even a little bit) by the number of patterns you use in your code.
16. Swayze Clench Never. Let. Go.
17. Even when a pattern turns out to be wrong for your solution, you keep pushing forward with it.
18. The right way to use Design Patterns ll ll ll ll
19. Don’t.
20. By that, I mean don’t start with the pattern. Instead, write code that fulfills the requirements
21. Code by Intention This might be a pattern one day
22. Write clean code that might resemble a pattern…someday.
23. This won’t work as well unless you have studied your design patterns, though!
24. Refactoring to Patterns Ah… now I see it!
25. You may notice that your code looks a little like a specific pattern…
26. …and with a little refactoring, you can add more of the pattern’s benefits.
27. Once again, this won’t work unless you know your design patterns!
28. The Main Point If you get anything from this presentation… this is it.
29. Design patterns should emerge from your code, not be forced upon it.
30. Patrick Delancy patrickdelancy.com This Presentation: patrickdelancy.com/presentations/... @patrickdelancy linkedin.com/in/patrickdelancy github.com/patrickdelancy google.com/+patrickdelancy