Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OOP: You're Doing It Completely Wrong

OOP: You're Doing It Completely Wrong

Presented at CodeMash

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

More Decks by Kevin Berridge

Other Decks in Programming


  1. OOP

  2. 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)
  3. 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
  4. 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
  5. 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
  6. 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
  7. HOW TO WHAT Message Sending Information Hiding - conceals implementation

    details Encapsulation - behavior only affected through API
  8. HOW TO WHAT B B, please do this thing for

    me” Array Linked List Database C D
  9. EMERGENT BEHAVIOR “In a world of objects, new arrangements of

    behavior emerge naturally.” -Sandi Metz, Practical Object-Oriented Design in Ruby
  10. 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
  11. 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
  12. 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)
  13. 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)
  14. a Trip a Mechanic bicycles for each bicycle prepare bicycle

    (bike) clean bicycle(bike) pump tires(bike) lube chain(bike) check brakes(bike)
  15. 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.”
  16. 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
  17. 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
  18. ROLE What you can do, not what you are. “Orthogonal

    to class” -Sandi Metz, Practical Object-Oriented Design in Ruby IPreparer
  19. 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
  20. 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
  21. 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
  22. COMPOSABILITY “Composability is independent of decomposability. In fact, these criteria

    are often at odds.” -Bertrand Meyer, Object-Oriented Software Construction
  23. 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
  24. 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
  25. 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
  26. 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.”
  27. 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?”
  28. OBJECTS NOT SERVICES “Please Mr. Service, do that thing you

    do.” ! “Please Mr. Service, do that other thing you do.”
  29. 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
  30. MANAGE DEPENDENCIES Abstract Zone Danger Zone Neutral Zone Neutral Zone

    Dependents Many Few Likelihood of Change Less More
  31. REVIEW Change Emergence Composability What Blind Trust Context Independence Roles

    Cohesive Purpose Dependencies Top Down vs. Bottom Up Appropriate Complexity
  32. 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