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.

35e74c48a612d8a6786f8ab6424b49a1?s=128

Kevin Berridge

January 10, 2014
Tweet

Transcript

  1. OOP

  2. Kevin Berridge @kberridge kevinberridge.com

  3. None
  4. WHAT IS OBJECT ORIENTED PROGRAMMING?

  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)
  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
  7. BERTRAND MEYER: HIGHLIGHTS Static typing Multiple inheritance Design by Contract:

    Pre/post conditions, invariants Seamlessness
  8. OK, SO… WHAT IS OBJECT ORIENTED PROGRAMMING?

  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
  10. WHAT DO OBJECTS ABSTRACT?

  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
  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
  13. SO… WHAT DO OBJECTS ABSTRACT? HOW WHAT

  14. HOW TO WHAT Message Sending Information Hiding - conceals implementation

    details Encapsulation - behavior only affected through API
  15. HOW TO WHAT A B “Mr B, please do this

    thing for me”
  16. HOW TO WHAT B B, please do this thing for

    me” Array Linked List Database C D
  17. WHY CARE ABOUT WHAT? CHANGE

  18. OO ENABLES CHANGE Localize change Reusability/Composability Extendibility

  19. EMERGENT BEHAVIOR “In a world of objects, new arrangements of

    behavior emerge naturally.” -Sandi Metz, Practical Object-Oriented Design in Ruby
  20. EMERGENT BEHAVIOR spouse_steps_on_cat Spouse Cat

  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
  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
  23. EMERGENT BEHAVIOR -David West, Object Thinking

  24. EMERGENT BEHAVIOR !

  25. “GOOD” OO ?

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

  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)
  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)
  29. a Trip a Mechanic bicycles for each bicycle prepare bicycle

    (bike) clean bicycle(bike) pump tires(bike) lube chain(bike) check brakes(bike)
  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.”
  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
  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
  33. CONTEXT INDEPENDENCE Trip Mechanic Trip IPreparer

  34. ROLE What you can do, not what you are. “Orthogonal

    to class” -Sandi Metz, Practical Object-Oriented Design in Ruby IPreparer
  35. ROLE PAIRS IPreparer IPreparable Trip Mechanic TripCoordinator

  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
  37. HOW TO COMPOSE Dependency Injection Constructor Method “Inversion of Control”

    Factories IOC Containers
  38. SETTING UP THE SIMULATION

  39. DEPENDENCY INVERSION Trip Mechanic Trip Mechanic ITripPreparer

  40. DECOMPOSABILITY

  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
  42. TOP DOWN

  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
  44. COMPOSABILITY “Composability is independent of decomposability. In fact, these criteria

    are often at odds.” -Bertrand Meyer, Object-Oriented Software Construction
  45. TOP DOWN VS BOTTOM UP

  46. YAGNI

  47. KISS

  48. Red Green Refactor!

  49. Red Green Redesign?

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

  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
  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
  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
  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.”
  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?”
  56. OBJECTS NOT SERVICES “Please Mr. Service, do that thing you

    do.” ! “Please Mr. Service, do that other thing you do.”
  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
  58. MANAGE DEPENDENCIES “Few Interfaces” “Small Interfaces” Control the public API

    Isolate dependencies
  59. MANAGE DEPENDENCIES Abstract Zone Danger Zone Neutral Zone Neutral Zone

    Dependents Many Few Likelihood of Change Less More
  60. COMPLEXITY SCALE Active Record Model Binding Validations Information Hiding Dependency

    Injection Factories Roles VS.
  61. REVIEW Change Emergence Composability What Blind Trust Context Independence Roles

    Cohesive Purpose Dependencies Top Down vs. Bottom Up Appropriate Complexity
  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
  63. KEVIN BERRIDGE @KBERRIDGE Argue with me!