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
2. Kevin Berridge @kberridge kevinberridge.com
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!