cf.Objective() 2017 - Design patterns - Brad Wood
1 like1,376 views
This session covers what programming design patterns are, how they got their start, and reviews common design patterns and antipatterns.
Ad
More Related Content
What's hot (20)
Similar to cf.Objective() 2017 - Design patterns - Brad Wood (20)
Ad
More from Ortus Solutions, Corp (20)
Ad
Recently uploaded (20)
![Pixologic ZBrush Crack Plus Activation Key [Latest 2025] New Version](https://cdn.slidesharecdn.com/ss_thumbnails/fashionevolution2-250322112409-f76abaa7-250428124909-b51264ff-250504160528-fc2bb1c5-thumbnail.jpg?width=560&fit=bounds)
cf.Objective() 2017 - Design patterns - Brad Wood
- 1. Design Patterns COMMON SOLUTIONS TO COMMON PROBLEMS Brad Wood @bdw429s Ortus Solutions
- 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
- 5. Design Patterns Christopher Alexander, architect Born in Vienna in the 30’s
- 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. 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
- 9. A Pattern Language 37 HOUSE CLUSTER 76 HOUSE FOR A SMALL FAMILY 159 LIGHT ON TWO SIDES OF EVERY ROOM
- 10. Gang of Four (GoF)
- 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. Design Patterns: Elements of Reusable Object-Oriented Software Creational Patterns ● Abstract Factory ● Prototype ● Singleton
- 13. Design Patterns: Elements of Reusable Object-Oriented Software Structural Patterns ● Composite ● Decorator ● Facade
- 14. Design Patterns: Elements of Reusable Object-Oriented Software Behavioural Patterns ● Chain of Responsibility ● Iterator ● Strategy
- 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. Let’s look at some examples
- 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
- 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. Singleton function onApplicationStart() { application.myService = new models.myService(); }
- 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. Strategy logger.setAppender( new fileAppender() ); logger.logMessage( ‘This is my message’ ); logger.setAppender( new dbAppender() ); logger.logMessage( ‘This is my message’ );
- 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. iceCream = new iceCream(); iceCream.make(); sprinkledIceCream = new sprinklesDecorator( iceCream ); sprinkledIceCream.make(); Decorator
- 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. Adapter oldCache = new oldCacheEngine(); oldCache.retrieve( ‘item’ ); adaptedCache = new cacheAdapter( oldCache ); adaptedCache.get( ‘item’ );
- 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
- 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. 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(); }
- 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. Memento oUser = userService.loadUser( id=123 ); currentUserState = oUser.getMemento();
- 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. Observer (publish/subscribe) $.ajax({ url: "test.html", context: document.body }).done(function() { $( this ).addClass( "done" ); });
- 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. Double Checked Locking if( isDefined( 'data' ) ){ return data; } lock name="generateData" type="exclusive" timeout=60 { if( isDefined( 'data' ) ){ return data; } data = produceData(); return data; }
- 47. Anemic Domain Model https://en.wikipedia.org/wiki/Anemic_domain_model
- 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. Anemic Domain Model component accessors=true { property name=’name’; property name=’age’; property name=’department’; }
- 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. God Object util = new generalControllerUtil(); util.createOrder(); util.addUser(); util.login(); util.runScheduledTasks(); util.orderPizza();
- 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. Improbability Factor https://en.wikipedia.org/wiki/Improbability_factor
- 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. Improbability Factor reportService.runAsyncReport(); // Meh, this should be enough sleep( 5000 ); fileRead( ‘/reports/sales.pdf’ );
- 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. Law of Demeter orderCity = cart .getOrder() .getOrderDetails() .getUser() .getAddress() .getCity() .getName();
- 62. Principle of Least Astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishment
- 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. Principle of Least Astonishment (POLA) // Has side effect of removing all login history user.getAPIKey();
- 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. Resources
- 68. Head First Design Patterns: A Brain-Friendly Guide
- 69. Software Architecture Design Patterns in Java
- 71. Thanks for coming! Contact me ● [email protected] ● www.codersrevolution.com ● @bdw429s ● Ortus Solutions