Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

cf.Objective() 2017 - Design patterns - Brad Wood


Published on

This session covers what programming design patterns are, how they got their start, and reviews common design patterns and antipatterns.

Published in: Software
  • To get professional research papers you must go for experts like ⇒ ⇐
    Are you sure you want to  Yes  No
    Your message goes here
  • Ted's collection of plans are some of the best I've seen. If you're a woodworker, you really don't want miss out on this great deal. ▲▲▲
    Are you sure you want to  Yes  No
    Your message goes here
  • Loving the plans. Got lots of different ideas and inspiration. I'm sending you a photo of a bed frame I did for my daughter! ☺☺☺
    Are you sure you want to  Yes  No
    Your message goes here
  • Ted, these are awesome stuff! The plans are easy to read and understand for someone like me Plenty of detailed instructions making it easy to learn the techniques that I'm struggling with. ✔✔✔
    Are you sure you want to  Yes  No
    Your message goes here
  • Free Shed Plans, 12000 SHED PLANS. FREE SHED PLANS CLICK HERE ✤✤✤
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

cf.Objective() 2017 - Design patterns - Brad Wood

  1. 1. Design Patterns COMMON SOLUTIONS TO COMMON PROBLEMS Brad Wood @bdw429s Ortus Solutions
  2. 2. Me ● Work for Ortus Solutions ● Developer Advocate ● Love rewriting Node code in CFML ● Lead developer of CommandBox CLI ● Live in Kansas City ● Musician ● 3 Ridiculously cute daughters ● Like eating spicy foods
  3. 3. Design Patterns
  4. 4. Software Craftsmanship
  5. 5. Design Patterns Christopher Alexander, architect Born in Vienna in the 30’s
  6. 6. Architectural Design Patterns
  7. 7. A Pattern Language 1977 book on architecture, urban design, and community livability The book creates a new language, what the authors call a pattern language derived from timeless entities called patterns. Patterns describe a problem and then offer a solution. (253 patterns)
  8. 8. What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment, 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
  10. 10. Gang of Four (GoF)
  11. 11. Design Patterns: Elements of Reusable Object-Oriented Software Inspired by Christopher’s work 23 programming patterns Written by the “Gang of Four” in 1994 ● Erich Gamma ● Richard Helm ● Ralph Johnson ● John Vlissides
  12. 12. Design Patterns: Elements of Reusable Object-Oriented Software Creational Patterns ● Abstract Factory ● Prototype ● Singleton
  13. 13. Design Patterns: Elements of Reusable Object-Oriented Software Structural Patterns ● Composite ● Decorator ● Facade
  14. 14. Design Patterns: Elements of Reusable Object-Oriented Software Behavioural Patterns ● Chain of Responsibility ● Iterator ● Strategy
  15. 15. Inspiration, not copy/paste examples “The examples are there for inspiration and explanation of the ideas in the patterns. They aren't canned solutions; in all cases you'll need to do a fair bit of work to fit them into your application.” Martin Fowler
  16. 16. Let’s look at some examples
  17. 17. Object Factory
  18. 18. Object Factory ● An object that creates other objects ● Abstracts details of how the final objects are created ● Removes creation code from inside object to separate concerns ● Often used with the dependency injection pattern ● CFML Examples are WireBox or DI/1
  19. 19. Singleton
  20. 20. Singleton ● Ensure class only has one instance ● Provide global access to this instance ● Just-in-time initialization ● Often times doesn’t hold state ● Object must be thread safe!
  21. 21. Singleton function onApplicationStart() { application.myService = new models.myService(); }
  22. 22. Strategy
  23. 23. Strategy ● Define a family of algorithms ● Each one is encapsulated and interchangeable ● Often times each strategy implements an interface ● Each implementation can be different ● Strategies can be chosen at runtime ● Strategy in use is invisible to the program
  24. 24. Strategy logger.setAppender( new fileAppender() ); logger.logMessage( ‘This is my message’ ); logger.setAppender( new dbAppender() ); logger.logMessage( ‘This is my message’ );
  25. 25. Decorator
  26. 26. Decorator ● Add responsibilities to a class dynamically ● Alternative to subclassing (not really an “is-a”) ● Decorator wraps original class ● Wrapping can be recursive ● Can be applied at runtime ● User of class does not know (or care) if it’s been decorated
  27. 27. iceCream = new iceCream(); iceCream.make(); sprinkledIceCream = new sprinklesDecorator( iceCream ); sprinkledIceCream.make(); Decorator
  28. 28. Adapter
  29. 29. Adapter ● Modify the API of a class to be different ● Can “adapt” a class to work in another system ● Wraps the original class with a new interface ● Allows greater reuse ● Doesn’t modify original class
  30. 30. Adapter oldCache = new oldCacheEngine(); oldCache.retrieve( ‘item’ ); adaptedCache = new cacheAdapter( oldCache ); adaptedCache.get( ‘item’ );
  31. 31. Front Controller
  32. 32. Front Controller ● A single point of entry for a web app ● Simplifies URL routing ● Makes global concerns like security checks easier ● Utilizes a controller to dispatch to the appropriate handler ● Usually index.cfm in CFML apps
  33. 33. Front Controller
  34. 34. Chain of Responsibility
  35. 35. Chain of Responsibility ● You have a large or dynamic list of handlers that need to respond to a request ● You don’t want to couple the sender to the responders ● Creates a pipeline of linked handlers ● Each handler calls the next link in the chain ● A handler can abort the chain by not calling the next handler
  36. 36. Chain of Responsibility function securityHandler( request ) { if( !request.params.authenticated ){ throw ‘Not logged in’! } // Pass control to the next link in the chain request.proceed(); }
  37. 37. Memento
  38. 38. Memento ● Capture and externalize an object's internal state ● Can be used to “snapshot” an object ● Can be used to restore an object to a previous state ● Great for serialization ● Can include composed objects
  39. 39. Memento oUser = userService.loadUser( id=123 ); currentUserState = oUser.getMemento();
  40. 40. Observer (publish/subscribe)
  41. 41. Observer (publish/subscribe) ● Defines “events” that are broadcast ● Defines zero or more observers who are listening to those events ● Promotes decoupling of a large system ● Listener can receive data about the event that has happened ● Bind listeners at runtime for dynamic behaviors ● Don’t call us, we’ll call you!
  42. 42. Observer (publish/subscribe) $.ajax({ url: "test.html", context: document.body }).done(function() { $( this ).addClass( "done" ); });
  43. 43. Double Checked Locking
  44. 44. Double Checked Locking ● Protects creation of a shared resource with multithreading ● Reduces overhead of acquiring exclusive locks by first performing a read-only check ● If creation is required, only then is an exclusive lock acquired ● Once a thread has the exclusive lock, the check is performed a second time to ensure another thread hasn’t completed it ● Ensures thread safety without excessive locking
  45. 45. Double Checked Locking if( isDefined( 'data' ) ){ return data; } lock name="generateData" type="exclusive" timeout=60 { if( isDefined( 'data' ) ){ return data; } data = produceData(); return data; }
  46. 46. Anti-patterns (Avoid these!)
  47. 47. Anemic Domain Model
  48. 48. Anemic Domain Model ● When domain model is too “thin” and lacks any behavior ● Beans are only value objects with no behavior present ● Services are empty, meaning business logic has probably ended up in your controllers or views ● Creates excessive classes ● Bloats application code
  49. 49. Anemic Domain Model component accessors=true { property name=’name’; property name=’age’; property name=’department’; }
  50. 50. God Object
  51. 51. God Object ● A class with too much responsibility ● API is watered down with many unrelated methods ● Usually happens over time as code is added and never refactored ● Hard to maintain and test ● Lazy domain design and lack of planning
  52. 52. God Object util = new generalControllerUtil(); util.createOrder(); util.addUser(); util.login(); util.runScheduledTasks(); util.orderPizza();
  53. 53. Premature Optimization
  54. 54. Premature Optimization ● Coding early-on for perceived efficiency ● Sacrificing good design, maintainability ● Often times overstating a negligible speed improvement ● Sometimes “proven” by a flawed “loop test” ● The “root of all evil” -- Donald Knuth
  55. 55. Improbability Factor
  56. 56. Improbability Factor ● Leaving known bugs in your system because they’re “not likely to happen” ● Gambling with fate to save time and be lazy ● This is just inviting Murphy’s Law to come into full effect ● Can bite you later at the worst possible time
  57. 57. Improbability Factor reportService.runAsyncReport(); // Meh, this should be enough sleep( 5000 ); fileRead( ‘/reports/sales.pdf’ );
  58. 58. Honorable Mentions
  59. 59. Law of Demeter
  60. 60. Law of Demeter ● Principle of least knowledge ● A unit of software should have limited knowledge about the other units ● Software units should talk to friends and not to strangers ● Keeps low coupling between systems ● Rule of thumb: be careful accessing methods on objects obtained from other objects (the “dot” rule)
  61. 61. Law of Demeter orderCity = cart .getOrder() .getOrderDetails() .getUser() .getAddress() .getCity() .getName();
  62. 62. Principle of Least Astonishment
  63. 63. Principle of Least Astonishment (POLA) ● Applies to UI and software design ● "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature” ● User controls should have a consistent behavior ● Predictable software is easier to use ● Basically, don’t make your users go “WTF!?”
  64. 64. Principle of Least Astonishment (POLA) // Has side effect of removing all login history user.getAPIKey();
  65. 65. Brook’s Law
  66. 66. Brook’s Law ● “Adding manpower to a late software project makes it later" ● Coined by Fred Brooks in his 1975 book The Mythical Man-Month ● Software development is knowledge work, and not fungible ● Throwing devs at a project will slow it down at first ● A larger team has more points of contact ● If 1 woman can have a baby in 9 months, it doesn’t mean 9 women can have a baby in 1 month
  67. 67. Resources
  68. 68. Head First Design Patterns: A Brain-Friendly Guide
  69. 69. Software Architecture Design Patterns in Java
  70. 70.
  71. 71. Thanks for coming! Contact me ● ● ● @bdw429s ● Ortus Solutions