$30 off During Our Annual Pro Sale. View Details »

OOP: You're Doing It Completely Wrong

OOP: You're Doing It Completely Wrong

Presented at CodeMash 2.0.1.4

Chances are, most of us are primarily writing in Object Oriented Languages. But how many of us are truly doing Object Oriented Programming (OOP)? Objects are a powerful abstraction, but when all we do is write procedural code wrapped in classes we’re not realizing their benefits. That’s the tricky thing about OO, it’s easy to have Objects but still not be doing good OOP. This has led to a plethora of principles and patterns and laws, which are very valuable, but also easy to misunderstand and misapply. In this talk we’ll go back to the foundations of Objects, and take a careful look at some of the more useful OO principles. We’ll see how many modern frameworks force us into bad OO, but why occasionally that tradeoff is worth it. When we’re done, we’ll have a more nuanced understanding of what good OO is, what it can do for us, and when we should use it.

Kevin Berridge

January 10, 2014
Tweet

More Decks by Kevin Berridge

Other Decks in Programming

Transcript

  1. OOP

    View Slide

  2. Kevin Berridge
    @kberridge
    kevinberridge.com

    View Slide

  3. View Slide

  4. WHAT IS OBJECT ORIENTED
    PROGRAMMING?

    View Slide

  5. ALAN KAY
    Objects are like biological cells only able to communicate with messages
    Goal: get rid of data
    Never seen a good type system
    Didn’t include inheritance at first
    “It can be done in Smalltalk and in LISP” (2003)

    View Slide

  6. BERTRAND MEYER
    Seamlessness
    Classes
    Assertions
    Classes as modules
    Classes as types
    Feature-based
    computation
    Information Hiding
    Exception Handling
    Static typing
    Genercity
    Multiple inheritance
    Repeating
    inheritance
    Constrained
    Genercity
    Redefinition
    Polymorphism
    Dynamic binding
    Run-time type
    interrogation
    Deferred features
    and classes
    Garbage collection

    View Slide

  7. BERTRAND MEYER: HIGHLIGHTS
    Static typing
    Multiple inheritance
    Design by Contract: Pre/post conditions, invariants
    Seamlessness

    View Slide

  8. OK, SO…
    WHAT IS OBJECT ORIENTED
    PROGRAMMING?

    View Slide

  9. ABSTRACTION LADDER
    Binary instructions sent
    via physical switches
    Assembly language
    Macro instructions
    High-level languages
    Procedures
    Structured
    programming
    Abstract data types
    Objects
    -Rebecca Wirfs-Brock, et al,
    Designing Object-Oriented Software

    View Slide

  10. WHAT DO OBJECTS ABSTRACT?

    View Slide

  11. PROCEDURES
    “Procedural programming concerns itself almost immediately with
    the implementation of the program… Its first question is how.”
    -Rebecca Wirfs-Brock, et al,
    Designing Object-Oriented Software

    View Slide

  12. OBJECTS
    “Object-oriented programming starts with a more abstract focus. It
    asks first about the intent of the program. It ascertains what
    operations need to be performed and what information results.”
    -Rebecca Wirfs-Brock, et al,
    Designing Object-Oriented Software

    View Slide

  13. SO… WHAT DO OBJECTS ABSTRACT?
    HOW
    WHAT

    View Slide

  14. HOW TO WHAT
    Message Sending
    Information Hiding - conceals implementation details
    Encapsulation - behavior only affected through API

    View Slide

  15. HOW TO WHAT
    A B
    “Mr B, please do this thing for me”

    View Slide

  16. HOW TO WHAT
    B
    B, please do this thing for me”
    Array
    Linked List
    Database
    C
    D

    View Slide

  17. WHY CARE ABOUT WHAT?
    CHANGE

    View Slide

  18. OO ENABLES CHANGE
    Localize change
    Reusability/Composability
    Extendibility

    View Slide

  19. EMERGENT BEHAVIOR
    “In a world of objects, new arrangements of behavior emerge naturally.”
    -Sandi Metz,
    Practical Object-Oriented Design in Ruby

    View Slide

  20. EMERGENT BEHAVIOR
    spouse_steps_on_cat
    Spouse Cat

    View Slide

  21. EMERGENT BEHAVIOR
    “Object-oriented design requires that you shift from thinking of the world as a
    collection of predefined procedures to modeling the world as a series of
    messages that pass between objects.”
    -Sandi Metz,
    Practical Object-Oriented Design in Ruby

    View Slide

  22. EMERGENT BEHAVIOR
    “The behavior of the system is an emergent property of the composition of the
    objects. This lets us change the behavior of the system by changing the
    composition of its objects. It’s easier to change the system’s behavior because we
    can focus on what we want it to do, not how”
    -Steve Freeman and Nat Pryce,
    Growing Object-Oriented Software, Guided By Tests

    View Slide

  23. EMERGENT BEHAVIOR
    -David West,
    Object Thinking

    View Slide

  24. EMERGENT BEHAVIOR
    !

    View Slide

  25. “GOOD” OO
    ?

    View Slide

  26. “GOOD” OO
    SWEAT THE SMALL STUFF
    SPECIFIC TECHNIQUES
    PRINCIPLES

    View Slide

  27. SEQUENCE DIAGRAMS
    “The sequence diagrams are experimental
    and will be discarded; your lack of
    attachment to them is a feature.”
    -Sandi Metz,
    Practical Object-Oriented Design in Ruby
    a Trip a Mechanic
    bicycles
    for each bicycle
    clean bicycle(bike)
    pump tires(bike)
    lube chain(bike)
    check brakes(bike)

    View Slide

  28. A trip in order to start must ensure that
    all its bicycles are mechanically sound
    a Trip a Mechanic
    bicycles
    for each bicycle
    clean bicycle(bike)
    pump tires(bike)
    lube chain(bike)
    check brakes(bike)

    View Slide

  29. a Trip a Mechanic
    bicycles
    for each bicycle
    prepare bicycle (bike)
    clean bicycle(bike)
    pump tires(bike)
    lube chain(bike)
    check brakes(bike)

    View Slide

  30. a Trip a Mechanic
    for each bicycle
    prepare trip(self)
    prepare bicycle(bike)
    bicycles
    “I know what I want and I trust you to do your part.”

    View Slide

  31. TRUST
    “This blind trust is a keystone of object-oriented design. It allows objects to collaborate
    without binding themselves to context and is necessary in any application that expects to
    grow and change.”
    -Sandi Metz,
    Practical Object-Oriented Design in Ruby

    View Slide

  32. CONTEXT INDEPENDENCE
    “Each object has no built-in knowledge about the system in which it executes. Whatever
    an object needs to know about the larger environment it’s running in must be passed in.”
    -Steve Freeman, Nat Pryce,
    GOOS

    View Slide

  33. CONTEXT INDEPENDENCE
    Trip Mechanic
    Trip IPreparer

    View Slide

  34. ROLE
    What you can do, not what you are.
    “Orthogonal to class”
    -Sandi Metz,
    Practical Object-Oriented Design in Ruby
    IPreparer

    View Slide

  35. ROLE PAIRS
    IPreparer IPreparable
    Trip
    Mechanic TripCoordinator

    View Slide

  36. OPEN CLOSED
    “Modules that conform to the open-closed principle have two primary attributes:
    !
    1. They are ‘Open For Extension’
    2. They are ‘Closed For Modification’
    !
    In many ways this principle is at the heart of object oriented design.”
    -Bob Martin,
    The C++ Report, The Open-Closed Principle

    View Slide

  37. HOW TO COMPOSE
    Dependency Injection
    Constructor
    Method
    “Inversion of Control”
    Factories
    IOC Containers

    View Slide

  38. SETTING UP THE
    SIMULATION

    View Slide

  39. DEPENDENCY INVERSION
    Trip
    Mechanic
    Trip
    Mechanic
    ITripPreparer

    View Slide

  40. DECOMPOSABILITY

    View Slide

  41. DECOMPOSABILITY
    Modular Decomposability = “helps with task of decomposing a
    software problem into a small number of less complex subproblems,
    connected by a simple structure, and independent enough to allow
    further work to proceed separately on each of them.”
    -Bertrand Meyer,
    Object-Oriented Software Construction

    View Slide

  42. TOP DOWN

    View Slide

  43. COMPOSABILITY
    Modular Composability = “favors the production of software elements
    which may then be freely combined with each other to produce new
    systems, possibly in an environment quite different from the one in
    which they were initially developed.”
    -Bertrand Meyer,
    Object-Oriented Software Construction

    View Slide

  44. COMPOSABILITY
    “Composability is independent of decomposability. In fact, these
    criteria are often at odds.”
    -Bertrand Meyer,
    Object-Oriented Software Construction

    View Slide

  45. TOP DOWN
    VS
    BOTTOM UP

    View Slide

  46. YAGNI

    View Slide

  47. KISS

    View Slide

  48. Red
    Green
    Refactor!

    View Slide

  49. Red
    Green
    Redesign?

    View Slide

  50. DON’T UNDER VALUE THE
    ABILITY TO CHANGE LATER

    View Slide

  51. SIMPLER COMPOSITES
    “The composite object’s API must hide the existence of its component
    parts and the interactions between them, and expose a simpler
    abstraction to its peers.”
    Steve Freeman, Nat Pryce,
    GOOS

    View Slide

  52. TELL DON'T ASK
    “The calling object should describe what it wants in terms of the role
    that its neighbor plays, and let the called object decide how to make
    that happen.”
    Steve Freeman, Nat Pryce,
    GOOS

    View Slide

  53. SINGLE RESPONSIBILITY
    “A class that has more than one responsibility is difficult to reuse.
    The various responsibilities are likely thoroughly entangled within the
    class. It has many reasons to change, and each time it changes there’s
    a possibility of breaking every class that depends on it.”
    Sandi Metz,
    POODR

    View Slide

  54. RESPONSIBILITY?!
    “SRP doesn’t require that a class do only one very narrow thing or that
    it change for only a single nitpicky reason, instead SRP requires that a
    class be cohesive - that everything the class does be highly related
    to its purpose.”
    -Sandi Metz,
    POODR
    “A class has responsibilities that fulfill its purpose.”

    View Slide

  55. REWORD AS A QUESTION
    “Please Mr. Gear, what is your ratio?”
    !
    “Please Mr. Gear, what are you gear inches?”
    !
    “Please Mr. Gear, what is your tire size?”

    View Slide

  56. OBJECTS NOT SERVICES
    “Please Mr. Service, do that thing you do.”
    !
    “Please Mr. Service, do that other thing you do.”

    View Slide

  57. MANAGE DEPENDENCIES
    “Because well designed objects have a single responsibility, their very
    nature requires that they collaborate. To collaborate, an object must
    know something about others. Knowing creates a dependency. If not
    managed carefully, these dependencies will strangle your application.”
    -Sandi Metz,
    POODR

    View Slide

  58. MANAGE DEPENDENCIES
    “Few Interfaces”
    “Small Interfaces”
    Control the public API
    Isolate dependencies

    View Slide

  59. MANAGE DEPENDENCIES
    Abstract Zone Danger Zone
    Neutral Zone Neutral Zone
    Dependents
    Many
    Few
    Likelihood of Change
    Less More

    View Slide

  60. COMPLEXITY SCALE
    Active Record
    Model Binding
    Validations
    Information Hiding
    Dependency Injection
    Factories
    Roles
    VS.

    View Slide

  61. REVIEW
    Change Emergence
    Composability
    What
    Blind Trust
    Context Independence
    Roles
    Cohesive Purpose
    Dependencies
    Top Down vs. Bottom Up
    Appropriate Complexity

    View Slide

  62. REFERENCES
    http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
    -Dr. Alan Kay on the Meaning of OOP, Stefan Ram
    http://www.objectmentor.com/resources/articles/ocp.pdf
    -Bob Martin

    View Slide

  63. KEVIN BERRIDGE
    @KBERRIDGE
    Argue with me!

    View Slide