Unlearn OOP: Deleted Scenes, Misconceptions, Unspoken Truths

OOP
UNLEARN
deleted scenes, misconceptions, unspoken truths
lemi orhan ergin
co-founder, craftgate

View Slide

Hi Lemi

I think it's more a case of your background isn't quite right for what we need
right now. We can look to readdress this in the next 6-12 months however
we feel you have a lot of things we would need you to "unlearn" and we feel
you over-engineer solutions and currently we don't have the bandwidth in
the team to support your onboarding.

I hope this makes sense, please let me know if you have any more
questions.

Best Wishes
rejected
you are
13.10.2014
After five interviews, a project
developed with tdd and bdd having
and code review session, I was
rejected
100% code coverage and a pair programming
I am pushing myself to re-learn the fundamentals
Of agile, software design, architecture,
and programming paradigms
including oop

View Slide

LEMi ORHAN ERGiN
lemiorhanergin.com

co-founder @ Craftgate

the community guy @ Software
Craftsmanship Turkey
CRAFTGATE
cloud based payment gateway

payment hub for your virtual poses

with dynamic pos routing, you always
pay the lowest commission to banks
craftgate.io
 
blood and tears ;)
the only cloud based
payment hub in Turkey
current mood

View Slide

There are no solutions, there are only trade-o
ff
s.
 
You try to get the best trade-o
ff
you can get,
 
that’s all you can hope for.
Thomas Sowell
There is no best or worst in the world
 
everything is it-depends
OOP neither better nor worse than
 
any other paradigms, that’s another way
 
of thinking software design
Economist, Social Theorist
A great list of his books can be found at h
tt
ps://www.amazon.com/Thomas-Sowell/e/B00J5BK55K
DISCLAIMER

View Slide

LET’S START FROM THE BEGINNING
guess who is smiling ?

View Slide

The focus is on describing how a program operates using
statements and commands for the computer to perform
Decide which statements you want;
 
let the computer runs for you one by one
Imperative Programming
the hardware implementation
Complete algorithm or functionality wri
tt
en step-by-step

Code would have tons of GOTOs

Imperative is the counter part of declarative

(describes the computation without specifying how the program should run)

Pure assembly language is imperative language

The majority of programming languages are imperative
PROGRAMMING PARADIGM

View Slide

The focus is on the design of the processing, the algorithm
needed to perform the desired computation.
Decide which procedures you want;
 
use the best algorithms you can find.
Procedural Programming
aka. top-down approach
Simply the opposite of OOP

Describes the global ordering of the program

Structured code where functions dominate over data

Data is global, and all the functions can access global data

Languages like Fortran, Algol60, Algol68, C and Pascal

View Slide

The focus is on keeping the state changes localized to procedures
or restricted to explicit arguments and returns from procedures
Decide which conditional jumps you want;
 
prepare the best flow for you algorithm
Structured Programming
composing with control structures
The next step up from the ability to jump to another instruction:
conditional jumps

Uses structured control
fl
ow constructs of selection (if/then/else)
and repetition (while/for), block structures, and subroutines.

Edsger W. Dijkstra coined the term at the publication of the
in
fl
uential “GOTO Statement Considered Harmful” article.

Most frequently used for cases such as when exception handling
has to be performed.

Fortran, Cobol, and Basic originally lacked programming structures
now have them.

View Slide

The focus is on separating the functionality of a program into
independent, interchangeable modules
Decide which modules you want;

partition the program so that data is hidden
in modules
Modular Programming
aka. data hiding principle
A set of related procedures with the data they manipulate is o
ft
en
called a module.

The goal is code reuse and modularity.

High-level decomposition of an entire program code into pieces.

Many names, same concept: Header file, package, assembly, module

O
ft
en modules form a directed acyclic graph (DAG) and prevents cyclic
dependency.

The elements defined in the interface are detectable by other modules
DESIGN TECHNIQUE
interface
implementation

View Slide

The focus is on the way to decompose big problems according to
the data used to solve the problem
Decide which classes you want;

provide a full set of operations for each class;

make commonality explicit by using inheritance
Object Oriented Programming
data with functionality
Programs are divided into small entities called objects.

Data structures with functions a
tt
ached that operate on the data.

Allows distinction between the general properties of any shape and
the properties of a specific shape.

Supports inheritance, encapsulation, abstraction and polymorphism.

View Slide

The focus is on the way to decompose big problems according to
the operations used in its solution
Declare the functions you want;

Use them to calculate output from the input
Functional Programming
mapping values to other values
The central mode for abstraction is the function, not the data
structure.

Functions are treated as first-class citizens, meaning that they can be
bound to names, passed as arguments, and returned from other
functions, just as any other data type can.

When a pure function is called with some given arguments, it will
always return the same result, and cannot be a
ff
ected by any mutable
state or other side e
ff
ects.

View Slide

FP and OOP are
 
compatible and complementary
 
they can work together
Using objects doesn’t make your
code object-oriented and
 
programming with functions doesn’t
make your code functional
Closures are behavior with a
tt
ached data
Object is indistinguishable
from Closure
Objects are data with a
tt
ached behavior

View Slide

Precious time and brainpower are being spent thinking about ‘abstractions’
and ‘design pa
tt
erns’ instead of solving real-world problems
Ilya Suzdalnitski
from his article “Object-Oriented Programming — The Trillion Dollar Disaster”
is it possible that he was right?
most probably she has a 16 inch
Macbook pro with intel chipset

and connects it to an external
monitor
monitor could burn
 
when I forget that I change

log level to `trace` and fall

asleep while doing a `tail`

View Slide

YOU CAN WRITE COBOL
 
IN ANY LANGUAGE
as an old saying from the 60s:
poor designers come up with poor designs
clean and elegant so
ft
ware development depends on clean
and elegant designers and builders
Quote from Alan Kay’s answer at Quora: h
tt
ps://qr.ae/pGVOVv
IT’S SMELLING BAD
OOPS!

View Slide

Ge
tt
ers and se
tt
ers expose implementation
details.

Mutating state is so easy and fundamental in
OOP, but a design choice, not an obligation.

The lifecycle of units changing the same data
may overlap, that leads unexpected results.

Someone di
ff
erent decides to update my
data, I am not in charge of making decisions.
Mutating states
any temporary data
stored in memory
CODE
SMELL
1

View Slide

Objects having too many use cases and
behaviors implemented become GIANTS
and god objects.

When data and behaviors are separated,
we end up with many DWARF data objects
doing nothing but state mutating and
breaking encapsulation.

Giants can never be tested in fully
isolation. No one wants to mock such a big
number of dependencies.
Giants and dwarfs
CODE
SMELL
2

View Slide

Data and behavior are separated. Domain
logic does not live in the the domain objects.
They are simply bags of ge
tt
ers and se
tt
ers.

All domain logic is in the services. These
services are thick, live on top of the domain
model and use the domain model for data.
Anemic domain models
CODE
SMELL
3

View Slide

Objects are too abstract and out of
mental model, probably from outer
space.

With premature complexity, we build
walls before knowing the actual
fl
oor
plan.

Instead of doing the business, we build
objects making other objects doing the
business.
Unreal world modeling:
 
PlayerShootingService
CODE
SMELL
4

View Slide

Singleton objects having one interface,
mainly for using while mocking and
injecting dependencies.

We always talk about inheritance and
polymorphism but no one really cares.

Using inheritance makes code complex
and we really don’t know where to use it
Lonely interfaces for nothing
interface
interface
interface
interface
interface
interface CODE
SMELL
5

View Slide

Common modules, components, objects,
global state are in everywhere.

Common modules start with good
intentions but end up with lots of hackie
implementations and copied code for
changing freely.

Common components create extra
dependency to maintain.
Reusability honeypot
CODE
SMELL
6

View Slide

Too much thinking about persistence and
view models while designing the system.

When the design starts from infrastructure,
design is shaped based on infrastructural
choices and technologies, not based on user
needs.
Infrastructure Driven Design
CODE
SMELL
7

View Slide

Static classes, utility methods with business logic, abused usage of dependency injection.

Methods can be called from anywhere, like the old days of Fortran.

Spreading complexity to many methods and classes increase complexity and coupling.
Coding with GOTOs without using GOTOs
CODE
SMELL
8

View Slide

We mix what is stable with what changes a
lot, therefore every change has impact on a
bigger area.

Impossible to find the use cases and the
behavior without tracing the call stack and
debugging the codebase.

Requires a lot of hacking your own code,
breaking self-defined coding rules and
adding tons of exceptional cases.
Layers of self-hacking
Web
Domain
Persistence
CODE
SMELL
9

View Slide

Same nouns are everywhere: service,
manager, repository, handler, controller…

We build procedural code running in
multiple objects.

Names of the operational objects filled
with verbs masquerading as nouns:
strategies, factories and commands.
Kingdom of Nouns
UserController
UserManager
UserService
UserHelper UserUtils
UserRepository
CODE
SMELL
10

View Slide

Object Oriented Programming is an polysemic term
 
having di
ff
erent views of orientation and programming
 
since the terms evolve as problems do
having several
possible meanings
that is the reason why we have
 
too many conflicts between definitions

and theory and practice while defining OOP
THE ROOT REASON

OF ALL CONFLICTS

View Slide

Object Oriented Style
of Programming
Object Oriented Programming
means both in practice
Designing So
ft
ware in
Object Oriented Way
OOP
focuses on code organization,
implementation constructs
focuses on the design
principles, the philosophy
 
and values
context and boundaries
are pretty clear
design approaches evolves
as the problems do
di
ff
erent views on the same subject

View Slide

BJARNE STROUSTRUP’S SCHOOL OOP
Creator of C++
h
tt
ps://www.stroustrup.com/whatis.pdf
Object-oriented programming is a technique for programming – a paradigm for writing ‘‘good’’
programs for a set of problems.
Object Oriented Style
of Programming

View Slide

Four Pillars of Object Oriented Programming
wrapping up of data
 
under a single unit
acquiring the properties
 
from one class to
 
other classes
showing only
 
essential details
 
to users
ability of an object to
 
be in many forms
Inheritance Encapsulation Polymorphism
Abstraction
reducing cognitive load
thinking about reuse
defining conceptual
 

View Slide

reducing cognitive load
thinking about reuse
defining conceptual
 
under a single unit
acquiring the properties
 
from one class to
 
other classes
showing only
 
essential details
 
to users
ability of an object to
 
be in many forms
We always focus on HOW these concepts work
 
NOT WHY we need these concepts and
 
WHEN we should and should not use these concepts
people blame inheritance and polymorphism

because no one knows why and when to use them

View Slide

ALAN KAY’S SCHOOL OOP
Creator of SmallTalk
h
tt
ps://users.cs.duke.edu/~rodger
 
/articles/AlanKay70thpoints-of-view.pdf
I made up the term ‘object-oriented', and I can tell you I didn’t have C++ in mind
Designing So
ft
ware in
Object Oriented Way
from the section wri
tt
en by David P. Reed
 
at “Points of View - A Tribute to Alan Kay”

View Slide

Ole-Johan Dahl
Kristen Nygaard
code is from h
tt
ps://en.wikipedia.org/wiki/Simula
They were interested in running simulations
like modeling the spread of infection across a fixed population,
especially using Monte Carlo Simulation

Their need was simple: run simulation and get output

They defined simulation in terms of simulations, as objects!
They created Simula and Simula 67
at the Norwegian Computing Center in Oslo

It has objects, classes, inheritance, subclasses, and virtual methods
Recognized as co-Inventors of OOP
ACM gave a Turing award to Nygaard and Dahl

Simula recognized as first object oriented language
Alan Kay did not
 
invent objects
SIMULA
TURING AWARD WINNERS, 2001

View Slide

Ivan Sutherland demonstrating Sketchpad
 
image from h
tt
ps://en.wikipedia.org/wiki/Sketchpad
Ivan Sutherland created Sketchpad application
It was created between 1961 and 1962 and published in his Thesis in 1963

Objects were data structures representing graphical images displayed on an
oscilloscope screen

Pioneered human–computer interaction (HCI)

Considered the ancestor of modern computer-aided design (CAD) programs
The idea of the distinction between Classes and Instances
Any shape could become a “master” (i.e. class), and additional instances of
the shape were called “occurrences” (i.e. object)
Ivan Sutherland
TURING AWARD WINNER, 1988
Sketchpad inspired Alan Kay
Sketchpad completely changed the ways Alan Kay looked at computing

He learned Simula 1 in a week and learned the advantages of instantiating
processes
Alan Kay
TURING AWARD WINNER, 2003

View Slide

ARPAnet was grown (i.e. foundations of Internet)
In the late 1960s, ARPAnet (an early version of the internet) was going
build, that allowing many computers to intercommunicate as
decentralized network resilient to a
tt
acks like atomic bombs
But ARPA programmers had di
ff
iculties
They could isolate separate processes like virtual versions of the hardware

But procedures were too tightly coupled with data making the code fragile
h
tt
ps://www.rand.org/content/dam/rand/pubs/research_memoranda/2007/RM5290.pdf
ARPANet inspired Alan Kay
Robustness using components that are hot-swappable, having a
decentralized network and filesystem and the philosophy of ge
tt
ing rid of
data of ARPANet inspired Alan Kay
Alan Kay coined the term “Object Oriented”
As a programmer in the Air Force, he worked on creating a semantic file system
a B5000 computer. Alan Kay: “It was probably in 1967 when someone asked me
what I was doing, and I said -It’s object-oriented programming”
h
tt
ps://en.wikipedia.org/wiki/ARPANET

View Slide

Alan Kay imagined objects as independent
machines acting like biological cells,
operating on their own isolated state, and
communicating via message passing
OOP is building so
ft
ware as decoupled independent blocks
 
and ge
tt
ing rid of shared mutable state
… the whole point of OOP is not to have to worry about what is inside an
object. Objects made on di
ff
erent machines and with di
ff
erent languages
should be able to talk to each other …
Alan Kay
from “The Early History Of Smalltalk by Alan Kay”
 
h
tt
ps://ramix.org/smalltalk/TheEarlyHistoryOfSmalltalk_VI.html
BUILDING BLOCKS

View Slide

The key in making great and growable systems is much more to
design how its modules communicate rather than what their internal
properties and behaviors should be.
Alan Kay
from Alan’s email about “Prototypes vs Classes”
 
h
tt
p://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
Instead of designing large systems,
 
we design small systems and combine
these small systems such that they solve
these problems in concert
COMMUNICATION

View Slide

classes

objects

performance

inheritance

abstraction

hierarchy

java, c#, c++

aesthetics

how the code looks
None of them
 
are among the
 
primary ideas of
 
Object Oriented
 
Programming

View Slide

Encapsulation
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things
Alan Kay
from Alan’s email about “the meaning of Object Oriented Programming”
 
h
tt
p://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
Message
 
Passing
Extreme Late
 
Binding
communicating
 
with messages
dispatch decision
 
made on runtime
protect the state
 
space of class

View Slide

Encapsulation
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things
Alan Kay
from Alan’s email about “the meaning of Object Oriented Programming”
 
h
tt
p://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
Message
 
Passing
Extreme Late
 
Binding
communicating
 
with messages
dispatch decision
 
made on runtime
protect the state
 
space of class
It is NOT REALISTIC to have objects mixed business logic and infra logic
 
always communicating with message passing and
 
binding to the algorithm at runtime
today, solutions to problems sometimes require

thousands of different objects to run in harmony

View Slide

SIC TRANSIT GLORIA MUNDI
LET’S GET BENEFIT real
simple
that
is
oop
BOTH
FROM
SCHOOLS
OH HOW QUICKLY THE GLORY OF THE WORLD PASSES AWAY

View Slide

Separate code that changes frequently from code that is stable
1 Keep all business logic in domain module and handle all integration needs on infra module
Keep the inner module
 
framework free, then you
can test whole business
logic by only unit tests
Keep the outer module with
only integration points,
then you can test whole
technology specific logic by
integration tests
The diagram is from h
tt
ps://github.com/AlicanAkkus/Modular-Architecture-Hexagonal-Demo-Project

View Slide

Implement use cases, not a bunch of objects calling each other
2 “Value the behavior of the system, not the behavior of the object” - James Coplien
Use Case is the sequences of tasks towards
a business goal
End users mental model drives structure of
the program, not the programmer’s intention
Use cases are identified by behavior analysis
like in DDD and domain analysis
Use cases are triggered by a context and
transformed into algorithms, business
fl
ow
For more details about the this new perspective, please take a look at:
 
The DCI Architecture: A New Vision of Object-Oriented Programming
h
tt
ps://www.artima.com/articles/the-dci-architecture-a-new-vision-of-object-oriented-programming
MUST
 

View Slide

Decouple modules by le
tt
ing them communicate inward
with messages and outward with runtime polymorphism
3
the original idea of messages
are not method calls
messaging is between modules,
not objects of today
messages are contexts
triggering a request for action
Bertrand Meyer's principle of
Command-Query Separation:
 
a message either instructs an
object to do something or asks
the object for information but
never does both
message
passing
runtime
polymorphism
direction of
fl
ow, not the
dependency

View Slide

tt
3
In Smalltalk: doesNotUnderstand
 
in Ruby: method_missing()
 
In Groovy: methodMissing()
 
In Java: Not Exists
Objects can send messages
 
to one another
 
without having to know
others' implementations
 
if objects know how to
interpret messages
Objects can implement
 
matching logic at method
missing and dispatch the
fl
ow
accordingly

Some languages do not have
this capability, like java
IN DYNAMICALLY TYPED LANGUAGES
Re
fl
ection is just hacking
communication with methods
of old COBOL days

View Slide

tt
3
In languages like Java, beans should be registered to a
dispatcher to let them be identified when a related
message arrives
for fully working implementation: h
tt
ps://github.com/AlicanAkkus/Modular-Architecture-Hexagonal-Demo-Project
The object at outer module publishes a message via
publisher and let it dispatch the message to corresponding
object at inner module
IN STATICALLY TYPED LANGUAGES

View Slide

cache

interface
cache

implementation
business

object
uses
domain, business code

code we really care about

changes o
ft
en
integrations, infra code

write once and forget

hard to change
HIGH LEVEL MODULE LOW LEVEL MODULE
cache fake

implementation
DEPENDENCY INVERSION PRINCIPLE
Use runtime polymorphism to change program behavior
at runtime and enables plugin architecture
4
Learn the real intent behind SOLID Principles, especially their impact on modularity

View Slide

infra module domain module infra module database
(like controller) having business
 
logic
(like repository)
PaymentController PaymentUseCaseHandler PaymentPort PaymentDataAdapter
m b m
b
message passing
late extreme binding
4
With extreme late binding, implementation of a message handler can change in runtime
Use runtime polymorphism to change program behavior
at runtime and enables plugin architecture

View Slide

Stop creating anemic domain models, let them have behaviors
5
Domain object is the center of the design, it’s harder to change it if its operations don’t belong to it
All domain logic is in the services

Just a procedural style design

Breaks encapsulation, internal state of
objects become not internal at all

The logic that should be in domain object is:
business rules, validations, calculations,
anything not contradicting to SOLID

Service layer should be thin, it should
coordinate tasks, delegate work, and build
algorithms

Domain objects should not know anything of
the infrastructure

View Slide

Never allow mutation on shared states
6
The purpose of encapsulation as a way to protect the state space of a class
Having functionality in objects do
not mean adding JPA dependencies
to domain objects

Take Single Responsibility Principle
into account

View Slide

6
The purpose of encapsulation as a way to protect the state space of a class
Having functionality in objects do
not mean adding JPA dependencies
to domain objects
tt
ps://youtu.be/pdtpWYNBzqM
h
tt
ps://speakerdeck.com/lemiorhan/it-is-not-solid-anymore

View Slide

Separate code that changes frequently from code that is stable

Implement use cases, not a bunch of objects calling each other

tt
ing them communicate inward with
messages and outward with runtime polymorphism

Use runtime polymorphism to change program behavior at runtime
and enables plugin architecture

Understand the real meaning SOLID principles, not definitions

Stop creating anemic domain models, let them have behaviors

KEY TAKEAWAYS

View Slide

Layered Architecture, The Evil

Separation of Concerns

Information Hiding
 
Inversion of Control

Dependency Injection

Dependency Inversion
Maintainability, Flexibility

Ports and Adapters

Hexagonal Architecture

Testing in Hexagonal Arch.

How TDD Evolves Code

Modular Monoliths
SOLID Actually Means

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle
Evolution of Code to Modularity
1
4
Micro services in Mono Repository

Multi-layer Automated Testing

Hexagonal Architecture

Message Passing between Modules

Use Case Handling

Sync and Async Flow Execution
2
5
Test Double and Usages

Mocking Anti-Pa
tt
erns

When Mocking Sucks

Writing Mock-Free Code

Unit Testing Best Practices

Test Doubles and Modularity
3
6
Programming Paradigms

Code Smells in OOP

Stroustrup’s School of OOP

Alan Kay’s School of OOP

Message Passing in Practice

Misconceptions about OO

View Slide

speakerdeck.com/lemiorhan

View Slide

Unlearn OOP: Deleted Scenes, Misconceptions, Unspoken Truths

Unlearn OOP: Deleted Scenes, Misconceptions, Unspoken Truths

Lemi Orhan Ergin

More Decks by Lemi Orhan Ergin

Other Decks in Technology

Featured

Transcript