More Related Content
Similar to Thinking in the OOP way by Mark Musoba
Similar to Thinking in the OOP way by Mark Musoba (20)
Recently uploaded
Recently uploaded (20)
Thinking in the OOP way by Mark Musoba
- 1. OOP ~ Engineering ~ The Discipline ~
- 2. 1940s
- 3. 2008
- 4. 1940s • Invents macros • Invents variables • Invents code stack • Invents sub routines • Invents floating point • Invents binary computing • Invents integer add and logic not
- 7. 1940s ~ Vacuum Tubes
- 8. 1940s ~ Vacuum Tubes
- 9. 1940s ~ Report We shall need a great number of mathematicians of ability because there will probably be a good deal of work of this kind to be done.
- 10. 1940s ~ Report One of our difficulties will be the maintenance of an appropriate disciple, so we do not lose track of what we are doing.
- 11. Discipline • Mathematicians of Ability • A Great number of them • Appropriate Disciple
- 12. 1950s • Solved the memory problem (Magnetic cores that could store memory) • Tubes are being mass produced (music amps) • FORTRAN was invented
- 13. Brief History of Computing Alan Kay
- 14. Brief History of Computing Dennis Ritchie
- 15. Brief History of Computing Brad Cox and Bjarne Stroustrup
- 16. Brief History of Computing What happened to women?
- 17. 1950s We invent the core, a much denser memory.
- 18. 1940s ~ Vacuum Tubes
- 19. A use case driven approach:-- a precursor to user stories OO Software Engineering
- 26. Model View Presenter || MVVM PRESENTER BOUNDARY VIEW MODEL VIEW INTERACTOR ENTITY ENTITY ENTITY RESPONSE MODEL
- 28. What about the Database?
- 30. The database is a detail
- 31. DATABASE as Plugins INTERACTOR ENTITY ENTITY ENTITY ENTITY GATEWAY ENTITY GATEWAY IMPLEMENTATION DATABASE API
- 33. Good architecture lends itself to decision deference
- 34. Good architectures maximize the number of deferred decisions
- 36. ~ Frameworks
- 37. Pluggable Architecture BOUNDARY BOUNDARY REQUEST MODEL RESPONSE MODEL INTERACTOR ENTITIES ENTITY GATEWAY DATABASE
- 38. ~ TDD, for Architecture
- 39. ~ No Setters
Editor's Notes
- https://www.youtube.com/watch?v=ecIWPzGEbFc
- Alan Turing was probably the first person to write code that we could recognize today as code executed in an electronic computer with binary as an instruction format.
- Alan Turing was probably the first person to write code that we could recognize today as code executed in an electronic computer with binary as an instruction format.
- Alan Turing was probably the first person to write code that we could recognize today as code executed in an electronic computer with binary as an instruction format.
- Relay is a coil of wire, which if current is passed through generated a magnetic field that attracts the amateur, pulling it in to grab the switch contact to either close or open the switch. You can either open/close the switch to complete the circuit. These were mainly invented for telegraps, since telegrap signals could go for ~20 miles to amplify the signal, by putting a relay between the signals, which would close the switch on a new battery to relay the signal for another ~20 miles
- A device like this could probably switch 10 times as reliably, the clock rate was ~10 milliseconds. The clock rate on relays was not significant by today’s standards, but was faster than anything
- Vacuum tubes were unreliably slow and could fail often because they could not hold the vacuum for long, the filaments would burn out quickly, they were not standard, but were faster than relays, but they so unreliable to put them in a serial format was unreliable.
- The colossus computer. ACE = Automated Computing Engine Alan Turing designed: He designed the instruction set He designed the word width He designed the concept of the machine The first reliable tube computer that used mercury delay lines. A mercury delay line is a tube of mercury fluid. You put a speaker on one end and a microphone at the other. The sound waves roar through the mercury coming out at the other end, picked up by the microphone transistor, and cycle it around to the beginning of the memory. This was akin to rotating memory like a disc, only that it was memory. They figured they could get 1024 bits into the tube, then they would have 22 tubes, this was a 22 bit word size machine. This was a 1024x22 machine to write code on.
- Alan Turing, in inventing computing foresaw the rigour discipline it would require to do work
- He understood the problems we were going to face in the next 60 years after writing a few lines of software in Base 32.
- He understood the problems we were going to face in the next 60 years after writing a few lines of software in Base 32. Our industry has been hunting for discipline while at the same time rejecting it.
- Alan Turing, in inventing computing foresaw the rigour discipline it would require to do work
- Alan Kay invented Object Oriented Programming in SmallTalk, but not the way we know it now.
- Brief history of C, C++ and Objective C. How many languages have we developed in the last 5 years. Why don’t we agree that we can speak the same language for a long time without inventing and adopting new languages - Had a chapter zero, that Bjarne copied and gave the impression that C++ was the next C.
- These guys popularized OOP. Both wanted a better C, so they wrote preprocessors in front of C to add the imperatives that they were looking for. Objective C was known before C++.
- Woman have a more structured and methodical approach to things that we seem to have lost
- The colossus computer. ACE = Automated Computing Engine Alan Turing: Designed the instruction set Designed the word width Designed the concept of the machine The first reliable tube computer that used mercury delay lines. A mercury delay line is a tube of mercury fluid. You put a speaker on one end and a microphone at the other. The sound waves roar through the mercury coming out at the other end, picked up by the microphone transistor, and cycle it around to the beginning of the memory. This was akin to rotating memory like a disc, only that it was memory. They figured they could get 1024 bits into the tube, then they would have 22 tubes, this was a 22 bit word size machine. This was a 1024x22 machine to write code on.
- A use case does not describe the system, nor the implementation details of the data OOP has two problems, which stem from state abstraction and management: They hide state mutations They share state using pointers These do not lend very well to concurrency and parallel programming
- Entities have application independent business rules Interactors will talk to multiple entities
- Entities have application independent business rules Interactors will talk to multiple entities
- These are output boundaries, that separate the output from the input.
- DM => Delivery Mechanism Output boundaries separate the output from the input.
- This was designed for SmallTalk The model object hides a small business rule The role of the control is to gather input from some device (keyboard, mouse) The control translates the gestures into method calls on the model. The model is not allowed to know what devices control it, the model was not allowed to know where it gets its input from The view registered with the model and the model calls back to the view through an observer pattern, and the view is tasked with presenting the model to the user in an appropriate pattern This is minute. There was a MVC for a button, text box or group of buttons. This is unlike the current web
- What happens here is that you have controller logic leaking into the models Url parsing logic Http request manipulation Etc Business logic also leaks into views, especially if the team cannot keep discipline. The problem is that there are no SOLID boundaries
- The boundary is a hard architectural boundary that separates the business rules. The arrows point to the left of the boundary, and not to the right. This is the gist of the plugin architecture. The UI is a plugin into the business rules, not the other way round If something changes often, it should be a plugin, if something is not going to change often, it should be plugged into. The presenter is a class or set of classes that takes the response model and translates it into a view model. Response model => This is a model that has data in it created in the interactor as a result of a use case, but the data is not presentable (Date, currency) View model => Created by presenter (takes the data and turns them into formatted strings) and contains string formatted data. The view model knows how to format data. All significant processing of the presentation of the screen is done in the Presenter The view has to be so stupid as not to be tested.
- All arrows point in one direction to the left of the boundary point in one direction.
- Frameworks and design patterns are details that should be hidden
- Who calls the database? Grandma?
- The programmer’s job is to separate the details from the things that are general. We separate the things that are important from the things that are not We are ABSTRACTORS The database is a detail for persistence! Persistence existed before relational database. Directory structures Hierarchical databases Flat data structures Why are we preferring the table structures for the last 30 years, abstracted behind a language called SQL. Why databases? Because working with disks is a pain. You have to take into account: Spin velocity Byte marks You had to send accelerate and decelerate velocity 100ms for seeking the byte to write sequence Waiting for rotational latency To write a byte, you had to read a sector (4k bytes) We invented indexing to make dealing with disks easier. Then created tables to hold the indexes and then creates frameworks to abstract all that away.
- The entity gateway has every method for every operation you want to perform on the database. The database specific implementation (SQL) lives in the gateway implementation. The SQL stuff plugs into the business rules. For testing, we replace the gateway implementation with stubs that return test data. If the tests take more than a couple of minutes to run, they will fail in their purpose … If you run the tests yourself and see them execute in real time, you could make decisions based on what happened on those tests.
- An architect is someone who defers design decisions until they are absolutely necessary Good architectures allow major architectural decisions to be deferred. The job of an architect is not to make decisions, the job of a good architect is to defer decisions as long as possible to allow the program to be built in the absence of decisions so that decisions can be made later with the most possible information (or adequate information).
- You need to make some decisions early, like language, but you do not need to decide what database will be used early. You may already know due to existing constraints, but you can still pretend like you don’t know the database and defer that decision as long as possible. If the first thing you type at the beginning of the project is the web framework, you have lost the architecture. The business rules should always come first and then defer the framework decision later.
- And this is achieved by using a plugin model.
- Everything is a plugin to the Use Cases. The Use Cases do not know that they exist, they are indepent to everything else. People have gotten emotional about dependency injection, however, you do not want to inject everything. The thing you want to inject is the factories (and let the rest of the business rules use those factories) and strategies. Do not inject anything into the Use cases! You do not want the Use Case code to know about the DI framework, or any framework for that matter.
- Framework authors are out to screw you! There are not really out to screw you but they will screw you inadvertently since they have their interests in mind, not yours. The relationship between the developer and framework author is fraught to one side: Developers make tremendous commitments to the frameworks, while the framework authors do not make any commitments. The author will change the framework any time he feels like it. A good software developer looks at frameworks and understands that any frameworks come with benefits but also with tremendous costs. And the costs can be pretty high. Use the frameworks but keep them at arms-length. Do not follow the examples of the framework author (that he writes in the docs), because they are comfortable coupling to his framework, but you should not. How do break away from you framework if it becomes a liability? There has to be loose coupling between frameworks and your business logic.
- TDD Use TDD to structure the primary interface to the code
- TDD Use copy constructors
- TDD Use TDD to structure the primary interface to the code