$30 off During Our Annual Pro Sale. View Details »

Unlearn OOP: Deleted Scenes, Misconceptions, Unspoken Truths

Unlearn OOP: Deleted Scenes, Misconceptions, Unspoken Truths

Lemi Orhan Ergin

October 23, 2021
Tweet

More Decks by Lemi Orhan Ergin

Other Decks in Technology

Transcript

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

    View Slide

  2. 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

  3. 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

  4. 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

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

    View Slide

  6. 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

  7. 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
    PROGRAMMING PARADIGM

    View Slide

  8. 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.
    PROGRAMMING PARADIGM

    View Slide

  9. 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

  10. 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.
    PROGRAMMING PARADIGM

    View Slide

  11. 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.
    PROGRAMMING PARADIGM

    View Slide

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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
    Four Pillars of Object Oriented Programming
    communicating

    with messages
    dispatch decision

    made on runtime
    protect the state

    space of class

    View Slide

  38. 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
    Four Pillars of Object Oriented Programming
    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

  39. 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

  40. 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

  41. 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

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

  43. Decouple modules by le
    tt
    ing them communicate inward
    with messages and outward with runtime polymorphism
    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

  44. Decouple modules by le
    tt
    ing them communicate inward
    with messages and outward with runtime polymorphism
    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

  45. 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

  46. 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

  47. 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

  48. 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

  49. 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
    tt
    ps://youtu.be/pdtpWYNBzqM
    h
    tt
    ps://speakerdeck.com/lemiorhan/it-is-not-solid-anymore

    View Slide

  50. Separate code that changes frequently from code that is stable


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


    Decouple modules by le
    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


    Never allow mutation on shared states
    KEY TAKEAWAYS

    View Slide

  51. 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

  52. speakerdeck.com/lemiorhan


    View Slide