1. OOP is not Dead
or why we should stop seeing FP as its opponent or as silver bullet
Hernán A. Wilkinson
@hernanwilkinson
agile software development & services
38. I invented the term
Object-Oriented and I
can tell you I did not
have C++ in mind.
Java and C++ make you
think that the new ideas are
like the old ones. Java is the
most distressing thing to hit
computing since MS-DOS
39. What is Object Oriented?
• MUST
• Everything is an Object (data is an object, code is an object, classes are
objects, everything is an object!)
• Computation is done sending messages
• EITHER OR BOTH
• Classes and Sub classification as means of knowledge organization
• Objects as prototypes as means of knowledge organization
• REALLY NICE TO HAVE
• Immediate feedback
• Completely Reflective Environment (Meta-Circular)
41. What OO is not
• Data types - int, long, double, etc. They are not objects
• Statements - for, while, if, etc. They are not messages
• Static methods - There is no “self/this” on static methods
• Final/Seal methods – There is no message send when used
• When ”code” is not an Object – No Closure or no Lambda, i.e. Java previous
1.8
• JEE is no OO, it is structured programming in Java
• Anemic classes is not OO (Services with DTO, etc)
• Use of Inheritance for Code reuse is not good OO (i.e. ActiveRecord , white
box frameworks, etc)
• Dependency Injection abuse is not OO
• IoC abuse is not OO
44. Wikipedia’s definition
• […] treats computation as the evaluation of mathematical functions
and avoids changing-state and mutable data.
• It is a declarative programming paradigm, which means programming
is done with expressions[…]instead of statements.
• Missing concepts from Wikipedia:
• Lambda functions (which allow High Order functions)
• Runtime support for recursive implementations (aka: tail recursion
elimination)
• Arguable:
• Lazy evaluation (more or less)
• Macro
48. Real OO Languages represent
“Code” as an object
(Closure High Order Functions)
• Smalltalk since the ‘70s
• ”Closures got famous because Java don’t have them” (Anonymous)
50. Some conclusions - Good OO implies:
• Immutable objects when representing immutable
entities
• Closure “High order functions”
• Message sending all the way (expressions)
• Consistency (everything is an object)
• Knowledge representation and classification
(Programs are Models!)
51. Some conclusions about FP
• It is a mistake to think that FP is going to solve all the
software design problems.
• Design are made by humans, not by programming languages
(even though they influence design decisions)
• FP will suffer from the same “miss-used” problems as OO
suffers now
• FP does not provide a way to organize the knowledge
represented in the software data structures are not
enough, we know that from Structured Programming
52. Some conclusions
•OOP vs. FP is an absurd dichotomy
•OOP and FP complement each other
•Do not act as a “Pop Programmer”
54. For sure NOT from
• Performance improvements
• Less verbose languages
• Better type system (other complete topic to discuss)
• It is “normal science” (khun-onian way to say “more of
the same”)
55. They will come from
• Better tools to help human-machine communication
•Better environments to “augment” human intellect
•More dynamic environments to improve immediate
feedback
•…
•Let’s see some examples