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
@ 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
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
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
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
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
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
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
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
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
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`
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!
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
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
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
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
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
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
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
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
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
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
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
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
Object-oriented programming is a technique for programming – a paradigm for writing ‘‘good’’ programs for a set of problems. Object Oriented Style of Programming
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
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
/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”
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
lemiorhan
sakaitakeshi
epicsdao
kzkmaeda
lambda
shuta13
simboss
rotomx
hayato_ukuk
yutadayo
yukukotani
opdavies
akmur
malarkey
mojombo
holman
lynnandtonic
matthewcrist
geeforr
destraynor
jakevdp
sachag
bluesmoon
lara
