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

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

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

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

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

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

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

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

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

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

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

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

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`

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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 


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

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”

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

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

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

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

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

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

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

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

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

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

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 


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

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

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

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

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

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

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

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

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

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

speakerdeck.com/lemiorhan