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.

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