Graham Lee - Rethinking Object-Oriented Design

[Music] thank you very much very warm introduction so it's become very popular recently to to reject object-oriented programming and to say that you know we've got to find another way of thinking another way of working as if like somehow it's possible for thinking about the software that we're building to be a failure and I think what's happened here is like you know a lot of the reason that we're interested in saying oh we've moved on from oo P now and we're like rejecting it in favor of rediscovered older things like functional programming or very similar constructions you know Protocol oriented programming has a lot of similarities to ROP so why are we saying like this is the new hotness and that things being rejected and is old-fashioned or I suppose we might say considered harmful in the programming world I think it's got a lot to do with like a lot of complexity that built up around the world things like inheritance design patterns solid principles these you know these are not like core to the idea but if you add all of those things and say like you don't understand this thing until you understand all of these other ideas as well then it just becomes a lot harder to well you know let's use the buzzword it becomes a lot harder to reason about but I think that you know what we need to do is rather than like reject this thing just take the the core principles and build up an understanding that's going to to work for us so let's start from the beginning and try again and my assertion is that this is the beginning that an object is a function so for those of us who think we shouldn't be rejecting functional programming for those of us who love our functional programming and object is a function so we're all happy there we're keeping the functional programmers on board this is useful and what it does is take the name of an operation that you want to happen and give you a function that does that operation so all we do is looking up a function at runtime by name that if you want a justification of that then this is the conclusion of my dot Swift talk I'm just going to use this result and build on it today but if you want you know more kind of convincing that this argument holds then go and watch that talk but the point is that all we're doing is saying I want this thing to happen and I don't care how we do it yeah you you do the thing that's right and and I will trust you on that that's well is that really useful let's let's find out looks like I've just added some complexity doesn't it because here if we take a language like Swift or C or Java or any other programming language that doesn't have message sending and then add message sending to it then we've got all of these tools that we already use for choosing what code to run and now I've added another tool for choosing what code to run like I've just added some complexity anime because now you know I could have a big switch statement that decides what code to run I could have a function maybe an anonymous function a closure a closure closure the language closure closure the construct closure both of those things let's have both of them let's all have all of the letters between Clos and Europe anyway we can have any of those we can have a higher-order function and now I've said there's this specific type of higher-order function that I'm calling an object that I'm calling message sending and I'm going to add this as another way to have bits of my program communicate aren't I just making life harder for myself well the way that we design things is by looking at the situation looking at the context and adding constraints to make the thing that we're doing the obvious choice of thing in those circumstances this is what Christoph's talk was about was saying well let's constrain ourselves to not having all of this code here yeah this code could go anywhere and it could go in the view controller let's say no it doesn't go there let's say it goes in some other place and dave was talking about exactly the same thing as well so I'm saying let's pick a line in the sand and say this is where we use messages and this is where we don't use everything else at any other situation we use everything else we don't use messages what is that line in the sand I want us to turn our big computer programs into small computer programs and I want each of those computer programs to work independently of the other ones and to have some published interface that says how you're allowed to use it and the way that we connect those things together is to send messages to them the way that we build them is to do something else so our people in here familiar with like microservices from the kind of back end wall could have a show of hands people who have heard of the phrase and who have implemented a micro service have implemented more than one micro service I'm glad that's mostly the same group of people bike services are this aren't they they say right you can build your program out of programming language but it's got to be a small isolated program that works well independently and that has a published interface and you send messages to it over some protocol in this case probably HTTP Google protocol buffers graph QL whatever and those messages say how the program fits into the system that I'm trying to build turns out that you know microservices is just reinventing IOP based on having message sending and that's what I want to do now so I'm going to take some weird complex program and you might think this weird complex program like the state of programming that we had before we even have structured programming like yeah this is the kind of thing that like Edgar Dijkstra would recoil in horror from my assertion is that a loss of modern software written in swift Objective C Java Kotlin Ruby JavaScript any sort of program a programming language even ones that a way you claim that your program is object-oriented currently looked like this and some of the rules we have that are designed to get us away from this don't necessarily do that because if you apply them in isolation you don't gain any design benefit rubyists for example have a rule that you shouldn't have more than three lines of code in a method which seems like it's going to address this problem because we would definitely not have that great big decision tree that but great big floaty on the right of the slide here if we only had three lines of code but if those three lines are a third precondition set the value of some internal state through whatever I was just passed by the you know by the caller and by the way Jeff Goldblum there is no step three then I've still got this I've still got this state because I can make any change to my code anywhere if I've got a setter method that I haven't got object-oriented programming because I'm allowing the whole program to change any piece of the state anywhere in the application but we can see that you know there are a couple of things are happening in this in this program it looks like we start with some kind of tree structure and then we make a decision based on something to do with that tree and then on the Left we well that's clearly an iteration over a list because we start at the beginning as a list then we make a decision and we maybe go back and if we can exit that decision and we must be traversing the list or doing something and then there's like the other branch this uses a couple of random pieces of of data so we've got a thing a chunk of program that works on the tree and a chunk of program that works on the list but notice that there's some coupling here at this decision point this die diamond at the bottom of the left branch we're using both the list and they're at the tree so let's separate that out so we've got a sub program that's just dealing with the tree and a sub pre program that's just dealing with the list and when it gets to its decision point it's not going to say well I'm going to go and look at that tree because it doesn't have the tree it's not allowed the tree the tree is somebody else's problem what it's going to do is to send a message yeah this idea that this function that takes a method name of selector and returns and implementation is message sending that's what's going to happen at this point so we're now going to have two independent programs one that works on a tree and one that works on the list and when the list program wants to know whether it should advance or exit it's going to send a message to someone and to get our original program back that someone will be the program that looks after the tree but we can go further yeah we can build our tree out of things that look after a single node of the tree and the connections to the rest of the tree we can build our list out of programs that look after the node of a list and that have connections to the rest of the list and people who are used to functional programming will recognize that way of dealing with a list as a functional programming way to build a list who has used a lisp or Flo whatever goes next closure closure anyone use one of those languages a couple of hands going up anyone used Haskell a few more hands going up so we've all seen that a list is a thing with a tail that is the rest of the list or it is the empty list that's object-oriented programming that is so what we've done now is drive down our programs to be incredibly tiny independent programs to communicate over a message passing interface why is that any different from just writing a big-ass program you may ask well because now there's only two things they have to do for the this is one of my tiny programs and those of us who have done any work we've liked the next-step platform does anyone recognize this of seeing some thumbs up from there's some gray haired people in the front of the audience the here this is the jelly donut model of an object because like if you gave someone a piece of cake and some Jam like that would be a mess right and so what you do is you encapsulate the jam inside the cake and then you've got a donut which is something that you can easily pass around between people and and deal with without getting into a right mess and next description of the Objective C programming language from like 1987 I think used this model of the object and this is still the only thing that you need to know about the mod about an object if a monad is a burrito an object is a jam donut thank you very much now though I've still so we've got our methods which are our kind of like tiny flowcharts and notice none of these flowcharts have got any branches anymore because they're all really simple they're just looking at a very small piece of an application they are around the outside and are preventing access to the few pieces of data that are in the middle that are the you know the kind of storage the internal state of this object anything that comes from the outside has to be a message and the message will go to one method which chooses which of the other methods to run so now we've only got two questions one is do the way that our methods interact with our data make sense you know given this tiny amount of data do we always leave that in a consistent state for any operation that you're allowed to invoke by sending a message and secondly is the collection of messages you're allowed to send compatible with that set of requirements that we just came up with this is why I said that we have to be careful about exposing things like getter and setter methods because that is a way to have a message that changes arbitrary state inside the object it is that which is confusing it is javabeans which is confusing it is key value coding which is confusing it is not an object it's building passive data structures in calling them objects which allows us to build unstructured programming but pretend that we're doing objects that was the bit that was confusing but gram I hear no nobody say apart from me so I like filled in that awkward silence for you this seems like insufficient because all we've done now is go from a big flowchart of program that was working on data to a big flowchart of messages sent between small programs they're working on data are we actually in a better position than we were before well let's go back to what this constraint about message sending meant it said that these programs have to be independent and that if they represent different things then they have to communicate via message passing they shouldn't communicate via the rest of the programming language and that means that we can also use messages to go between problem domains so at the like the bottom we've got foundational objects Dave is talking about the fact that we might want to use different data structures like trees or sets or arrays or tries or you know whatever kind of crazy data structure is appropriate for your problem well those are like object interfaces and if I've got a thing the models an employee you how many of you are M most of you who work at companies or who are employers hands up if if any of your employees have a hashmap no weirdly enough not so we don't like we can't model our employee as a thing that owns a hashmap we but we can model some aspects of an employee by communicating with a hashmap to find some particular information about that employee so we're communicating across problem domains across levels of abstraction we're going to use messages we're going to turn these into separate programs and now I've got something that's a bit like a biological system I've got cells at the bottom which are things that look after individual bits of data and build them into useful data structures I've got kind of you know organs or something at the next level which is collections of cells that are related for performing some particular function in organisms at the top level which are collections of organs that work together to achieve some kind of goal sorry that we've been making this difficult and you're also wondering but Graeme you're only about halfway through the running time for this presentation if that like is this really a good point to stop well I'm sorry that we've been making this so hard for decades I'm sorry that like you know that I can sum up 30 years of evolution of thinking in software architecture in a 15 minute presentation but my my belief so this is a bit well apart from the cameras and the microphones and everything this is just between you and me right that the reason that this got so weird in like the 1980s and the 1990s was the object technology companies because back then you could make money running a developer business they yeah it wasn't just JetBrains who could do it anyone who had a developer tool could find developers who would pay tens of thousands of pounds to have that tool because that made them more efficient than two programmers who didn't have that tool so it was worth nearly somebody else's salary in order to buy the tool right and so the first thing that happened was that the people who wanted to sell AOP to us you know the stepstones the OT eyes their eve I am syns and the object technologists of the world said this isn't actually that hard this is very similar to what you're doing if you're already doing structured programming in C or Pascal then we can sell you an objective-c or an object Pascal that means that you're already doing object-oriented programming like buying my tool will make you better and won't be hard to learn and so they did that and that was the first wave and they made like you know thousands and thousands of pounds off of each of us doing that and then they went oh but now it's not very hard like you can't sell consultancy services anymore because we just claimed that we'd solved all the problems so did you know that a square is a rectangle and did you know that a rectangle is a square wait you have some difficult problem if you come to me and try and pay my exorbitant day rate I can solve this problem for you and so we built this kind of ever-increasing like you know Babel like Tower of complexity in order to keep the consultants in business for a few decades you can see that happening with agile now you can't see it happening with functional programming yet because I'm not sure that we've got to that level of maturity with the next wave of functional programming but you could see it happening with object-oriented programming so what about all of this other stuff that we were talking about for the last 30 years you know what what happened to inheritance what happened to mutable state what happens to design patterns and whether a horse and the motorcar inherit from each other or have a common parent or multiple common parents or whatever well let's have a look at a couple of those and things you remember that I broke my the my kind of abstract multiple level hierarchy of problem domains into three right I had foundational objects I had models of objects in my problems this in my problem domain and then I had like user goals as objects that negotiated their way through the network of lower objects well if I've got a user story that's kind of like another user story right now if someone if I've got a user story that says that I can you know purchase a book from an online bookstore that's very similar to being able to purchase a new a lawnmower from an online lawnmower store we're just like a little bit of distinction so what I might want to do is to say well this story is bait this is the buying stuff use the story which is a prototype and now when I want the behavior of buying a book I'm going to inherit from that prototype or clone that prototype and put my book nurse into it or my lawnmower nurse or whatever it is and using that like phraseology using that collection of new of ideas we might come up with something like JavaScript or i/o or the self programming language where we have prototypes and we have objects that like extend from prototypes and add their own custom behavior so we have the buying stuff user story and then that is inherited by the buying books user story that makes a lot of sense but if I start to think about the objects in my problem domain well I might say like a book is an SKU in my store but a book is also a publication so now I've got two categories of things and a book has characteristics of both of these things so now I need multiple inheritors right because I've got two parents my book so it sounds like just by describing this problem I want multiple Herot inheritance something like C++ in that context and if we go down to like their foundational type so if we go down to the data structures then we definitely want some kind of type system is some kind of subtyping so that we know that the preconditions and invariants and post conditions of our algorithms are being honored so if I've got this kind of dictionary node and then I build a subtype of a dictionary then the dictionary stuff still works properly so that sounds like I want single inheritance there and I want my inheritance tree to look like type tree as it does in Objective C or small talk or Java or C sharp or any of those languages so can I have all three of these inheritance systems at the same time please well the answer is actually yes like the problem we the problem with saying yes is that a language like Java doesn't let you do that but the concept of object-oriented programming does let you do that remember an object is just a function that chooses what method to run like if you go and find the the dot Swift presentation you will find a one-line implementation of message send so just like write your own message send and then choose what kind of inheritance you want when you're solving the problem this is actually a lot easier than trying to contort your problem until it fits like a java inheritance tree or until it fits the JavaScript inheritance tree or until it fits a Swift inheritance tree there our inheritance is just a special type of delegation that has you know conditions attached to it so if you want different conditions just implement a different form of delegation and say it's only a very small function to do another thing that I mentioned another problem was mutable state right that yeah this is a common reason for rejecting object-oriented programming is well now I have to think about whether different things are changing my data at the same time one like different things changing your data at the same time we decided earlier was out of the scope of what we're doing because each of these objects is an independent program that's doing its own thing but secondly if modeling time as as the successive values of your computer's Ram is not working for you then just don't model time like that you know why not have the history of your object as the thing that you store in memory and the time index as the way to work out what the value of that object is you can do that in functional programming you know something like do Tomic does this you can do this in a Joey into programming you could do this in assembly language if you want to because they're all interchangeable my point is that object oriented equals mutable state equals bad therefore object-oriented programming is bad is fallacious because object-oriented programming equals mutable state is not true object-oriented programming equals modeling stuff here is one way to model time that means we don't have mutable state anymore so it's just messages between programs each of those programs work each of those programs represents a single thing and we can build a program out of it sorry that we made it so hard and sorry there took 30 years to get to this point thank you [Applause] you

Channel: Swiss Mobile Developers Association

Views: 1,505

Keywords:

Id: 6OQq2kE5wUY

Length: 25min 36sec (1536 seconds)

Published: Mon Apr 23 2018