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.
Design Patterns
The Good, the Bad, and the Anti-Pattern
Barry O Sullivan 2016
Who am me?
My name is Barry O Sullivan @barryosull
- Product Developer - Systems Architect
- Development Manager - Freelan...
What is a Design pattern?
A design pattern is a general, repeatable
solution to a commonly occurring problem in
software d...
What does this mean?
It means we can design our systems to support
change, rather than fight it.
It’s about expressing you...
That sounds amazing!
So we should all use them right?
Well there’s a catch
Design patterns make it very easy to do one thi...
In other words
Using the wrong pattern is worse
than using no pattern at all
The Anti-Pattern
Patterns that seem like they’ll work but don’t
Anti-Patterns are usually emergent and are
always bad
Ball of Mud
• No discernable architecture
• Everything is different
• Extracting it piece by piece doesn’t work
You just e...
God Class
And God said
“Let’s put all the functionality in the user class”
Large, bloated classes that do everything and a...
The Big Reveal
Using the wrong design pattern
Is an Anti-Pattern
The Awkward Truth
A ball of mud is better than a system built with
all the patterns and zero design
>
Design patterns
The usual suspects
1. Singleton
2. Fluent Interface
3. Command
4. Observer
5. ActiveRecord
6. MVC
Singleton Pattern
“There can only be one”
For when there should only be one instance of an
object system wide
Singleton Pattern
Where to use it?
• Logging
• DB connection
• Message Bus
• Command Handler
$handler= CommandHandler::ins...
Singleton Pattern
Where not to use it?
• Globally accessing a class
(Laravel Facades, I'm looking at you!)
Use DI instead
...
Fluent Interface
“You talking to me?”
Chain methods together to make complex
programs easier to compose and read
$customer...
Fluent Interface
Where to use it
For representing strongly defined grammars
• SQL (eg Eloquent)
• Domain Specific Languages
Fluent Interface
Where to not use it
Anywhere else
If you’re not representing a language,
don’t use this interface
Main of...
Command pattern
“Can I take your order sir?”
Encapsulate a command that can be handled now
or later.
Contains all the data...
Command pattern
Where to use it
Anywhere you just want something done and don’t
care about the details
(Controller => Appl...
Command pattern
Where not to use it
Anywhere it gets in the way
You’re creating a wall.
Only use it if the wall is useful
Observer Pattern
Decoupled systems that want to alert each other
of changes
An observer registers itself with a subject. W...
Observer Pattern
Where to use it
Messaging systems
Anywhere that the relationships can change
Modular systems
Observer Pattern
Where not to use it
Where the objects scope will never change
Ie, it's created internally, used, then
dis...
Active Record (ORM)
“We're all connected”
Make it easy to store your class hierarchy in a
Database, without having to writ...
Active Record (ORM)
Where to use it
Simple CRUD based domains where your objects
have simple relational structures
Not a l...
Active Record (ORM)
Where not to use it
Complex domains with multiple views on data,
rather than just the basic view
Eg. A...
Active Record
Alternatives
The Repository pattern:
Keep the domain logic separate from the storage logic
CQRS:
Have a sing...
MVC
“Divide and Conquer”
Structure your app into three distinct areas of
responsibility, Model/View/Controller
MVC
Where to use it
Any complex application that's more than a
single form
You’re most likely already using it at work
(If...
MVC
Where it goes wrong
MVC doesn't explain the M part very well.
M is where Design patterns really come into play
All exa...
Is it worth it?
Definitely!
Imagine your code as network cables,
now imagine going from this to this
=>
Light at the end of the tunnel
A well designed system is a pleasure to change and
test
It just takes time and effort to un...
Choosing the right pattern
Don't just pick one and assume it will be fine
Research them all, understand their shape
Look a...
Honourable mentions
• Factory pattern
• Repository pattern
• Interfaces (just in general)
• Dependency injection
• Façade
...
Further Reading
“If I have seen further, it is by standing on the
shoulders of giants.”
• http://www.martinfowler.com/
• h...
Thank you
Any questions?
Upcoming SlideShare
Loading in …5
×

Design patterns - The Good, the Bad, and the Anti-Pattern

657 views

Published on

The slides from my talk on design patterns, and when good design patterns turn bad. I go through various patterns I've seen abused (by myself as well as others) and I offer advice on how to avoid these mistakes. Design patterns are a tool, use the right one for the job,

Published in: Software
  • Be the first to comment

  • Be the first to like this

Design patterns - The Good, the Bad, and the Anti-Pattern

  1. 1. Design Patterns The Good, the Bad, and the Anti-Pattern Barry O Sullivan 2016
  2. 2. Who am me? My name is Barry O Sullivan @barryosull - Product Developer - Systems Architect - Development Manager - Freelancer Current position Finishing up as Development Manager for Hiup (Going to back to contracting, shhhhh)
  3. 3. What is a Design pattern? A design pattern is a general, repeatable solution to a commonly occurring problem in software design
  4. 4. What does this mean? It means we can design our systems to support change, rather than fight it. It’s about expressing your intent • Changes become easier • Less hacks • Code is easier to read and understand • Faster development • Fewer bugs
  5. 5. That sounds amazing! So we should all use them right? Well there’s a catch Design patterns make it very easy to do one thing, by making it harder to do others It’s architecture, which is about tradeoffs
  6. 6. In other words Using the wrong pattern is worse than using no pattern at all
  7. 7. The Anti-Pattern Patterns that seem like they’ll work but don’t Anti-Patterns are usually emergent and are always bad
  8. 8. Ball of Mud • No discernable architecture • Everything is different • Extracting it piece by piece doesn’t work You just end up with mud everywhere.
  9. 9. God Class And God said “Let’s put all the functionality in the user class” Large, bloated classes that do everything and are impossible to understand and maintain.
  10. 10. The Big Reveal Using the wrong design pattern Is an Anti-Pattern
  11. 11. The Awkward Truth A ball of mud is better than a system built with all the patterns and zero design >
  12. 12. Design patterns The usual suspects 1. Singleton 2. Fluent Interface 3. Command 4. Observer 5. ActiveRecord 6. MVC
  13. 13. Singleton Pattern “There can only be one” For when there should only be one instance of an object system wide
  14. 14. Singleton Pattern Where to use it? • Logging • DB connection • Message Bus • Command Handler $handler= CommandHandler::instance(); try { $handler->handle( new BeEgyptian($SeanConnery) ); } catch (NobodyIsBuyingItException $e) { …. }
  15. 15. Singleton Pattern Where not to use it? • Globally accessing a class (Laravel Facades, I'm looking at you!) Use DI instead (like the Laravel 5.1 request object)
  16. 16. Fluent Interface “You talking to me?” Chain methods together to make complex programs easier to compose and read $customer->add_to_basket($hat, 1) ->add_to_basket($dress, 2) ->apply_discount_code(“23453”) ->purchase(“4242-4242-4242-4242”, “123”, “12/12”);
  17. 17. Fluent Interface Where to use it For representing strongly defined grammars • SQL (eg Eloquent) • Domain Specific Languages
  18. 18. Fluent Interface Where to not use it Anywhere else If you’re not representing a language, don’t use this interface Main offender, jQuery $(“.elem”).parents(“.main”).find(“input.name”) .data(“name”,”john”).addClass(“selected”) .removeClass(“.meh_class”).val(“what the?”)
  19. 19. Command pattern “Can I take your order sir?” Encapsulate a command that can be handled now or later. Contains all the data required to run the command
  20. 20. Command pattern Where to use it Anywhere you just want something done and don’t care about the details (Controller => Application Layer) Message passing Scheduled tasks
  21. 21. Command pattern Where not to use it Anywhere it gets in the way You’re creating a wall. Only use it if the wall is useful
  22. 22. Observer Pattern Decoupled systems that want to alert each other of changes An observer registers itself with a subject. When the subject changes, it alerts the observer
  23. 23. Observer Pattern Where to use it Messaging systems Anywhere that the relationships can change Modular systems
  24. 24. Observer Pattern Where not to use it Where the objects scope will never change Ie, it's created internally, used, then discarded Sometimes things should be coupled, and that’s ok
  25. 25. Active Record (ORM) “We're all connected” Make it easy to store your class hierarchy in a Database, without having to write all the translation code (eg. to SQL) $team= NewsTeam::find(‘Evening News Team); $new_insult = new Insult(); $new_insult ->target = ‘Their Clothes’; $new_insult->question =‘Purchase location’; $new_insult ->punchline = ‘The Toilet Store’; $team->insults[] = $new_insult ; $team->status = ‘rekd’; $team->save();
  26. 26. Active Record (ORM) Where to use it Simple CRUD based domains where your objects have simple relational structures Not a lot of domain behavior Mostly just key value pairs
  27. 27. Active Record (ORM) Where not to use it Complex domains with multiple views on data, rather than just the basic view Eg. A checkout process that has promotions and special offers based on your address Anything with lots of analytics
  28. 28. Active Record Alternatives The Repository pattern: Keep the domain logic separate from the storage logic CQRS: Have a single data model, multiple views built from that core model NoSQL: Worth a mention, store trees of data with dynamic shapes
  29. 29. MVC “Divide and Conquer” Structure your app into three distinct areas of responsibility, Model/View/Controller
  30. 30. MVC Where to use it Any complex application that's more than a single form You’re most likely already using it at work (If not, I’m feel your pain)
  31. 31. MVC Where it goes wrong MVC doesn't explain the M part very well. M is where Design patterns really come into play All examples code use ORM, so people think that you just use ORM and your M part is sorted That's not design, that's laziness. Learn patterns, git gud! (Dark Souls!)
  32. 32. Is it worth it? Definitely! Imagine your code as network cables, now imagine going from this to this =>
  33. 33. Light at the end of the tunnel A well designed system is a pleasure to change and test It just takes time and effort to understand the patterns “You have to get worse, before you can get better”
  34. 34. Choosing the right pattern Don't just pick one and assume it will be fine Research them all, understand their shape Look at the problem, figure out what changes and why it’s hard to change. Find the pattern. Try to use them and fail (on a branch)
  35. 35. Honourable mentions • Factory pattern • Repository pattern • Interfaces (just in general) • Dependency injection • Façade • Iterator • Abstract classes
  36. 36. Further Reading “If I have seen further, it is by standing on the shoulders of giants.” • http://www.martinfowler.com/ • https://sourcemaking.com/ • https://en.wikipedia.org/wiki/Software_design_pattern Also, why not talk to the other developers here? (I’m sure we’ve all fucked up with patterns as much as I have . . . )
  37. 37. Thank you Any questions?

×