Uncoupling • Michael Nygard • GOTO 2018

[Music] [Applause] thank you I'm really happy to be here addressing you today coupling and uncoupling has been a subject on my mind for a long time more than 10 years as it turns out though I didn't recognize it as such at the time so some ways back I got exposed to operations and spent some time living with my software and other people's software and discovered that it didn't really perform that well when it met contact with the real world that led me to write this book release it a few things have changed since 2007 when it was originally published I think I had a comment somewhere in there that virtualization may be a solution to this problem in the future if it becomes mainstream well yeah since then quite a few things have changed so I wrote this second edition and released release it second edition back in January I am currently with a company called cognate echt we're the stewards behind closure and closure script so we helped run the community so the language creator can think big thoughts and do big things we are the people behind the database des Tomic and a number of open-source tools in the closure space so when I think about coupling I think about the kind of molasses that we all have to deal with the mud the difficulty of changing things especially when we go to micro services we think about coupling a lot and we need to uncouple them and usually the story goes something like this you've been working on your system for a long time you think things are going pretty well you've got to decomposed into small pieces in an orderly arrangement there's even some beauty in the complexity of the system you've got and then one day everything changes that one requirement comes in that requires a kind of variation that you never contemplated before it's something that just doesn't fit and there's no way to accommodate it in the model you've got so you make a change and you discover somehow you need a corresponding change on the other side of the world you change that and find that something else breaks for no apparent reason what you start to realize is that your system is not this lovely arrangement of independent pieces rather than the small buckyballs like that it's a different buckminster fuller structure something called tensegrities a tensegrities structure is made up of beams and ropes or elastic and it holds itself together by the tension on the parts and by the beams resistance to tension it's a nest of opposing forces and if you remove the wrong beam the whole thing flies apart it's held back from chaos by a network of interwoven dependencies you pull one part and it pushes a different part you push another piece and it pushes back at some point you start making enough changes that you realize you've descended into no Tegrity it's not integrity not tensegrities it's just nothing and the blob engulfs you and your system the system fights your changes and at some point a rewrite starts to sound like a pretty good idea because you know how long could it take it's only like two weeks to rewrite it right this is when we say we've fallen prey to coupling that there was unexpected coupling hidden coupling latent coupling tight coupling and so on we use this word but we don't often define what it means we have a sort of a gut feeling that coupling means two things are linked together but there's a more precise definition of coupling that comes from other industries in large engineering systems a coupling can be something that provides safety rather than resistance we use coupling as kind of a dirty word we say coupled you know these services are coupled and it's kind of synonymous with just bad we don't like the way they in but this is an example of a coupling on a train this is the Scharffen Berger plur it was invented about a hundred years ago and is still in use today inside of this device you have a cone-shaped depression on one side and a cone-shaped outdent on the other side and there's a rod that extends from the cone and engages with a slot in a disc on the other side the disc rotates increasing the length of a spring until it rotates far enough then it shortens the spring and latches the coupling closed well this coupling provides safety you don't want your trains uncoupling somewhere as you're you know racing along the tracks although apparently in the UK for quite some time this is a way to drop passengers off at a station without stopping the Train you would just unhook their cars and let them drift to a stop it's not used so much these days we like our trains to stay together in engineering we have these things called linkages which are bars connected by couplers now in this case this is Watts linkage named for the Scottish engineer who invented it and it was a way of translating rotary motion into linear motion it's a simple arrangement of three bars and four couplers the couplers allow the movement to take place but keep the movement along this arc sometime later another person named chebyshev invented a different linkage that provides a better version of linear motion from rotary it's also three bars and four couplers but they're arranged differently and so we get a different style of coupling that provides different motion coupling is absolutely everywhere and I really mean everywhere in the standard model of physics that describes all of matter we talk about the coupling coefficients and the way that these different fields coupled to each other so coupling actually allows and everything to exist so this is not really synonymous with bad anymore it's something necessary when we think about coupling we want to think about specific aspects of it and we're gonna dissect coupling and look at different varieties of coupling and how we can change them but it's important to keep in mind that coupling determines the degrees of freedom in a system degrees of freedom simply means the ways that it can move so if you imagine the human knee it allows movement in one plane basically you know back and forth I would demo this but you've all seen knees and mine aren't working so well lately so I'm gonna avoid that the idea is that the knee enables certain movements like walking and running it inhibits other movements if your knee bends the wrong way something has gone very wrong a coupling also connects effects from one place to another so with the knee we're connecting the effect of a muscle motion in one part of the body to a movement of another part of the body in watts and chebyshev's linkages we were connecting the effects of motion at the pivot points on the fixed ends of the rods to the motion of the center point of the bar but I have another example of coupling connecting effects in a much bigger scale and that has to do with this this is Iapetus moon of Saturn it's sometimes been called the Death Star moon because of that very prominent crater with the central feature there it's a weird moon it's got a bunch of anomalies you may not be able to see it on the the darker picture but there's a sort of a ridge all the way around the equator that probably came from when the impact created that Death Star crater liquefied the surface of the Moon and waves rippling back and forth solidified to form that Ridge we don't know this for sure but it's the only theory that seems to explain it otherwise it may just be a enormous walnut waiting to be cracked but perhaps the most obvious feature is this two-tone coloration it's bright on one side and dark on the other side that two-tone coloration was actually observed by Giovanni Cassini for whom the probe is named and for whom the gap in the Rings is named so we've known about this dual coloration for hundreds of years in 2009 we discovered the likely cause of this coloration and that is this moon called Phoebe Phoebe is a tiny insignificant little moon we can judge it we can look down on it it's not even big enough to pull itself together into a sphere it's this sort of potato shape 213 kilometers across at its widest if you were on the surface of Phoebe you could throw a baseball off of the moon you could hit a golf ball out of orbit and hit you know hit with escape velocity to send a golf ball to Saturn Phoebe is very far out from Saturn in fact it is at the outer edge of this ring system here this diffuse faint red ring that we discovered in 2009 it's 40 times bigger than the entirety of the rest of the ring system that we know but we couldn't see it from Earth because it's very faint and very diffuse Phoebe is at the outer edge of this ring being ablated by micro meteoroids that blast material off the surface because it's gravity is so weak that material reaches escape velocity and goes into orbit around Saturn where it forms this ring over time solar pressure on this side of this ring closer to the Sun causes the particles to move or get a little force a little acceleration toward Saturn it's weaker on the far side so they don't get the acceleration there this causes a spiraling orbit where they move inward to the inner edge of this ring which you've probably guessed by now is where we find a Appetit I happy toises they're sweeping up the dust from Phoebe so we think that that too coloration is caused by this long-distance long-term coupling of micrometeoroids Phoebe photons from the Sun gravity from Saturn and a tidally locked moon when I say everything is coupled I mean everything but we don't think about the coupling of this moon system around Saturn when we're designing software we can ignore it because its effects are relatively small so we we often look at these systems as independent because the coupling effect is small but it doesn't mean it's absent so we have the ambient temperature well it's certain levels of temperature your servers begin to fail and so you are actually coupled to the ambient temperature in your data center we're coupled to atmospheric pressure your disk drives are evacuated for the most part if you start punching holes in them you let air in the heads crash bad things happen acoustic vibrations over time can cause parts to come loose and they actually can cause discs to fail there was an online backup company that wrote a paper about the effect of acoustic vibrations on hard disk failure rates they tested this by having somebody go into the data center and scream at the disks and that was enough to cause some failure rate that they could observe and measure and report on well we don't worry about all of these things all of the time if you're a data center engineer you may worry about temperature and and pressure and vibration all the time but when you're writing software probably not there are kinds of coupling that affect us the most and I've taken some time to try to analyze this and break it down and see if there were ways to classify the coupling and I found that there are so we have these different types of coupling that affect us at different times and in different strengths all of these may be present at the same time in varying degrees so operational coupling is the kind that we think about the most when weird services if the provider is calling a or if the consumer is calling the provider and the provider goes away the consumer either fails or has to adapt to it and if you've read my book you know I have some suggestions about how to adapt to that failure another kind of coupling that we encounter though is this development time coupling this is when somebody changes a function or a method signature in such a way that you also have to make a change this can happen with external api's as well as internal api's when somebody makes a breaking change we should think about breaking changes as meaning that you go and break a kneecap on whoever makes the change but we need that coupler to move in in a certain plane so we're not actually gonna break kneecaps metaphorical kneecaps that's what we want to break semantic coupling occurs when you have the same concept represented in more than one place and someone changes the concept I'll have an example of this a little bit later on but it happens a lot because within a company or within a domain we start to think of certain concepts as being real and fundamental would in fact they're abstractions for bundles of attributes and we spread this concept throughout our systems up and down the chain when we might do better to separate it into its constituent facets and only have other systems deal with those facets they need functional coupling occurs when you have several components that have similar responsibilities and so they create similar code and similar mechanisms for working with them this can affect multiple places when you need to change one of those especially cross-cutting concerns like logging and monitoring and then we have incidental coupling which in some ways is the the worst things break for no good reason any of these can be visible or they can be latent so you can imagine that latent incidental coupling is is the absolute worst when something breaks for no good reason and you don't know why it broke until you figure it out after the fact well I'd like to take some examples and analyze how these different kinds of coupling manifest in some systems that that we can look at so we've got one here that's taken from Simon Browns excellent c4 model comm where he's presenting a way of representing systems and this is one of the example systems represented there I'm taking some liberties with his system so apologies if I mischaracterized any of these things in one of the components he's looking at something that sends email via an off-the-shelf email system in this case Microsoft Exchange operationally we would say that this is strong coupling smtp is a conversational protocol it's synchronous and it has to have a connection active for the whole conversation if it's interrupted at any point you have to restart the conversation the email sender obviously can't do anything useful if the email receiver is not there or not functioning but if we think about the development time coupling we would say that that's relatively weak SMTP is well understood it's been around for decades there are plenty of standards written about it plenty of libraries and vendors and providers have done these interoperability swap meets where they get together with their different pieces of software and try them out together and make sure they work together so I'm not that concerned that developers will change Microsoft Exchange in a way that requires me to change my email sending component we do have very strong semantic coupling the notions of email and senders and recipients attachments mime types are deeply embedded in both exchange and the email sender component here but I don't necessarily worry about that very much because again they're unlikely to change and when they do change there's going to be a very long period of overlap and in terms of functional coupling also quite weak because you know they both use networks but other than that their responsibilities are distinct the job of the exchange server is to validate addresses store and forward make connections the job of the email component is really about marshalling the initial message and sending it across the wire there's not that much that I'm gonna worry about there let's take another example in this case a component in the system that was reading reference data from an external system inside the same enterprise so this data importer is making a sequel connection to a database very strong operational coupling if the database goes away the importer can't do its job and even if the database is in a clustered topology the caller still has to deal with failover semantics sequel exceptions don't really distinguish very well between one exception that says you should retry this because I've just done a failover and you can get results from the new database versus your query is bad and you should go away and feel bad and never send it again development coupling very strong changes that they make in the reference data system will almost certainly cause me to make changes in the importer semantic coupling also very strong the database server uses concepts like tables columns joins and the reference data importer certainly knows about querying from tables and doing joins functional coupling week we don't have to worry about it very much the job of the database server and the job of the importer are non-overlapping now let's imagine that we want to change this to get better characteristics we would say instead of a direct sequel connection maybe there is a rest interface to the reference data system so what does that look like in terms of coupling operationally it's strong coupling but it's not as strong so if the reference data system goes away we still can't do our job but the failover story is a lot easier for clients to deal with than it is in the case of the sequel server the development coupling strong but a little bit less so we have at least one place where we can isolate ourselves from data format changes we can also use open formats like JSON with extensible fields so there are some kinds of changes on the reference data system that would not impact us on the importer semantic coupling is still pretty strong you've got an HTTP server on one side an HTTP client on the other side they both understand things about headers cookies media types and so on functional coupling still weak not too worried about this we can take the same interface and invert the flow of control and see what that does to our coupling story so in this case we would say instead of me going and importing data whenever I needed I'm going to have the reference system publish its data as it changes and we'll go through some kind of a message broker in this case the operational coupling is quite weak the reference data system can disappear for some period of time and the receiver no longer an importer but a receiver can operate with stale data for some period of time depending on how long the outage is relative to the rate of change of data the development coupling is now weak we have at least two places where we can insulate ourselves from format changes we've got the message broker that can do some translation for us and we've got the receiver that can receive in one format and translate it to an internal format to vend out to the rest of the system the semantic coupling is pretty strong although somewhat less we do have a place where we can remap some of the concepts then the functional coupling now is increased because everybody's dealing with messages everybody has to connect broker everybody's probably using the same message technology even if they're in different languages and using different libraries so in all of those examples we had coupling there with different strengths of different kinds not only is it inescapable but it's actually necessary if you fully isolate two systems they can't work together they can't do anything they don't accomplish anything so some degree of coupling is necessary places where we want to really have caution are around chains of coupling so this is an example from retailer they had a far upstream system for managing the the retail data this is called recheck they had a product information management system they had a variety of feeds and down streams and like a lot of retailers they had this concept called ask you ask you for those of you who haven't done ecommerce is a stock keeping unit and it keeps track of the kind of thing that you're selling you can think of it as a class for retailers the SKU represents how much a thing costs how much it weighs what shelf space it takes up what it where it gets placed in distribution centers and a variety of other things once we get to online selling it also includes display attributes like what name should we show it as and what long description what imagery do we have well over time people began to think of this stock keeping unit as a real thing even though it just began as a number that you could use to relate together these different facets of information when you start thinking about breaking this into services you'll be tempted to say we need a SKU service or we need an item service that holds all of that information but in fact that information didn't naturally belong together anyway we now sell things that don't take up any shelf space we could just null out those columns or return zeros or negative one or something like that but isn't it better to just say there are things which take up shelf space and there things that don't likewise we have some things that have a price and a cost we have other things that have a price but we don't know the cost until we're done selling them for example skins in video games are priced by tier if you sell a million of them you get a better break on the price than a vendor that sells a hundred thousand of them so we could separate those attributes as well when you start slicing it apart you realize I don't need a SKU service but I do need an identifier that I can use to get all of these different types of attributes now another thing that happened in this same location was that they started selling these digital items and had many many more SKUs than they had in the past and managing the prices had previously been done by manually entering prices on specific items no longer viable and so they invented the notion of a price point this was a new concept I would say this track is available for $0.99 and then when they wanted to change it to 89 cents they could change the price point and it would take effect for all of the tracks this was a reasonable concept it was a way of getting leverage in a particular set of use cases but the trouble came when the price point went from a mechanism for managing prices in one system to being visible throughout all the other systems so the price point became a new feed where you would get a SKU that had a price and he would get other SKUs that related to a price point which meant that all of the downstream systems needed to accommodate this new concept and this change became very widespread very pervasive everybody had to update for this idea of a price point when all they really wanted was a price if it had been flattened out upstream everyone else would have been able to avoid introducing this new concept and would have saved a ton of money and a lot of change for the system when you have this kind of concept leakage that knits together a whole string of two tendencies like that I think of it as a semantic polymer it's like a long chain molecule where everything is tied together by these shared concepts another kind of coupling to watch out for is something called a long arrow so this is when you're looking at one of these system diagrams and you think that this arrow represents a simple call between two components but you discover that each interface is actually a chain of different moving parts so one example you know involves tables to files files across a network files into tables and then reprocessed into a new database and then swapping databases quite a number of moving parts there if we were to examine the coupling of all of those we would find that we get the worst characteristics the whole interface has the characteristics of the worst of each of those steps so latency is strictly worse than the slowest part of the chain availability is strictly worse than the least available link and so on so I've presented some places where we can analyze coupling and look at these different aspects of it but what can we do about it how do we how do we find solutions that uncouple operationally reduce the functional and development coupling to acceptable levels for this I often go back to David Parnas who gave us the term information hiding he later said he wishes he had called it decision hiding because that's a better encapsulation of his paper but this paper provides a specific example as a way of understanding how to assign behavior to modules in a system and even though he wrote this in the days when it was running on core memory and only on one machine I think there's a lot that we can learn from this about how we create interfaces in our systems today so the system he was talking about was to create a keyword index where every keyword appears in a circular shift of every place every sentence in which that keyword is used and so I just have an example here to try and illustrate that we take the sentence software comprises an endless supply of structures it's got six words so we find it under six different shifts did I miss count yeah seven words seven different shifts each time rotating it so different word is first and then we alphabetize the whole thing if you've ever used the UNIX command apropos that's how this is how apropos works it takes a circular shift that's been sorted by the keyword and then it finds you all the documents that include that word now in this paper Parnas presents two different modular ization x' and you sort of get the sense reading it that he lost a design argument with his team and in his company and then he wrote the paper to try and win the argument in print that he lost in person but he doesn't present a straw man he presents two working solutions so one of them starts with the input module that packs characters into an array it's got the circular shifter that looks at that first array and makes an in index array with pairs of addresses the alphabetize er takes two arrays makes a new array of pairs but alphabetized and then the output sort of walks through the alphabetized array finds the index looks into the original array and uses that to format the output the control module just calls each of these in sequence now it's not hard to see that this approach would work you could write this program and it would do the job you expect but what partners points out is that changes tend to ripple through every part of that system so if you wanted to change from the episodic character encoding to ASCII encoding or Unicode what would need to change essentially every module in that first design would need to change with the possible exception of the control module if we wanted to stop using pack characters and store one per word in the most profligate waste of memory they would have seen at that time then you would have to change essentially every module because they were all using the addresses created by the first module we would say that they were functionally coupled the second modular ization uses this extra piece so we actually have more modules here the first one is now called line storage and it presents this functional interface what we would represent or understand today is an API to set a character get a character get a word delete a word delete a line and so on the input module still reads the episode it character z' but this time instead of directly stuffing them into an indexed array it calls line storage to place the characters into storage the circular shifter now does something very interesting it presents the same story the same interface as line storage and just makes it look like all the shifts are there do you know if it actually did the shifts or not we don't know we're not allowed to know and we're not supposed to care the alphabetize er has a different interface where it is it's got an init because sorting takes a long time and then it's got an indexed access er that says you know walk me through the array output then just calls everything through the alphabetize ER and prints each line so let's think about similar sets of changes now if we wanted to change from a episodic to ASCII we might only have to change the input module and possibly the output module depending on how the printer works if we wanted to stop using packed characters we would only change the line storage module if we wanted to use offline storage instead of core we would only have to change the the line storage module so one interesting difference here is that we have defined interfaces and multiple implementers of the same interface that helps us hide decisions because that functional interface provides no insight for external callers to try and find out how is this really being done under the covers it's got this abstraction it's got the information hiding crucially decision hiding the decision about how we store characters is hidden inside the line storage module the decision about whether we sort immediately or we sort only when you start asking for results is hidden inside the alphabetize er if I diagram this it looks kind of like this in UML ish ball-and-socket notation apologies to anyone who's been traumatized by UML in the past I still find it useful to do sketches like this sometimes what we have here are components that offer interfaces and require interfaces so the input module requires the line storage interface it doesn't really care who's providing that interface the storage module does provide the line interface so that's good circular shifter does something very interesting it requires and provides the same interface what we find is having a smaller number of interfaces improves our composability and reduces the coupling between things it's somewhat counterintuitive we often think coupling is reduced if we have more AP is a smaller number of well-defined interfaces with a smaller number of data types is more composable and this is the composition that we would get if we plug these things together and if we if we went through this and analyzed it we could look at each connector with respect to each of those kinds of of coupling we'd find that operational coupling was high in every case for Parnas because this is all running in one process you know they hadn't really thought of distributed systems yet because you know there was probably only a market for six computers in the world the development coupling is greatly weakened by that functional interface the semantic coupling is also reduced due to using interfaces rather than direct access and the functional coupling is reduced because we don't have that repeated notion of character indexing and array manipulation so somewhat surprisingly composability is inversely proportional to your number of interfaces and your number of data types so if you find that you have services with too broad and interface they may be exposing too much of their internals which is going to encourage semantic and functional coupling you're better off finding ways to split that interface and break it down into different facets so that then you're more likely to find the interface here is doing the same thing as the interface they're just with different names at that point you can bring them together and raise the level of abstraction by saying I now have a common interface that's implemented by different services or components so when we're uncoupling things we want to think about orthogonality as well and orthogonality in math has a great definition you take the dot product of two vectors if there's no overlap than they're orthogonal meaning there's no projection of one onto the other no shadow from one vector to the other in software when we talk about orthogonality we're talking about separating concerns creating high cohesion low coupling and little overlap this is how we achieve the decision hiding I'm gonna walk through just a few more examples from this same system that was in C for model this is a component view inside a container so the container is the light colored box there that's labeled batch process it does have a dashed line around it but that may be sort of impossible to discern from the back that's fine inside the components or inside the container we have the components in this case they're all running inside that batch process they're all part of the same codebase they've been linked together so the operational coupling is going to be very high in all cases I am borrowing this from c4 model comm there's the URL when we look at this even from this distant and altitude we can start to see some places where there's likely to be different kinds of coupling sneaking in so for instance over here on the right hand side we have two components where the risk calculator is producing something that the report generator is meant to consume and so we expect that there is some shared knowledge some semantic coupling between those components over here on the left we have a couple of different data importers that are both talking to external systems they probably have very similar implementations and so we're likely to find some functional coupling between those two we have this report checker up here that says it checks to see if the report has been generated by a particular time of day if not it uses the alert er to send an alert and presumably you know go wake somebody up to produce the risk report before it gets seen or the absence of it gets seen but the report checker and the report distributor don't have any direct connection even though presumably the report checker knows where to look in the file system to see if the report was created so this is an example of latent coupling where we have shared knowledge baked into both of these components and it's shared knowledge about a third party and so it's likely to be quite a nasty surprise once we finally discover it this thing called an Orchestrator it's not going to surprise anybody that the orchestrator is probably doing a lot of well orchestration calling things and translating formats back and forth that's kind of the nature of an Orchestrator so we won't dig into it too much more but I do want to look at some things we can do about those problem areas we highlighted so here we've got these an excerpt of an excerpt just the interaction among the risk calculator and report generator so what can we do to reduce the semantic coupling among these in this case we're inside a windows service but in other styles of architecture we would apply other decisions like making a standard document format within a single service I would say we take the simple approach and create a shared library to represent that interface between those two over on the other side of the diagram we had some possibly redundant implementation details and so that might be something that we factor out and have both of the components using it and up here with the report checker and our file system layout I would say we would want to hide the decision about the file system layout from both of those by creating a module that they could both call on now in all three of those situations I'm using a library but in different ways so one of them was a meeting point between two components to hide the decision about how that data was being held and represented in the other I was using it to extract repeated functionality to hide the decision about how we handle retries and reconnects and so on and then for the file system layout it was to isolate this shared concept to encapsulate a decision about where to put files that would need to be used in at least those two places and probably also in the web server that lets people view the report so we were looking at a component diagram that was representing the runtime structure we were analyzing the functional and semantic and development time coupling when we found solutions by introducing more parts which would seem to increase coupling but by using the modules at development time we are hiding those decisions and weakening some of the kinds of coupling and strengthening other kinds but strengthening it in a single location instead of spreading it out so we have one place to make a change later and I often find that you can sort of rotate a diagram by 90 degrees so when you're looking at components think about the modules that make up those components maybe there's a solution to your your problem in sharing code or reducing shared code when you're looking at the code think about the components the runtime structure maybe there's a solution in running in more places or fewer places and because I work in closure a lot I have to you know say when I'm looking at data I think about code when I'm looking at code I think about data because code is data and I can kind of go back and forth the idea though is to use all of the tools you have at your disposal so use the layout of your libraries in your code use the component structure and use the ability to abstract so find higher-level interfaces that speak more generally and find ways to split into smaller interfaces that are more specific to the task at hand so to recap when we talk about coupling it is necessary it's essential every time we have a coupling it allows movement in one direction the sort of expected direction of the coupling but it does inhibit other movements and usually we don't notice when we're using a coupling that allows a particular kind of change because it's it's easy and we we notice when things are hard we don't notice as much when it's easy coupling does connect effects and when we run into trouble is when we've got these long chains of effects that are connected from far distant parts of the system we want to keep in mind all four of these kinds of coupling operational development semantics functional and that they can all be present in varying degrees some of them are more difficult to deal with in different architectural styles some of them are easier to deal with in other styles where you can hide your decisions hide them behind api's hide them inside modules hide them inside components pick which degrees of freedom matter for your system and accept that some changes that come along later will require degrees of freedom that you didn't anticipate and didn't build in watch out for those semantics polymers concept leakage is one of the biggest things that will damage your enterprise over time use both the static structure of your code and the dynamic structure of your components not everything needs to be a service there's still room for shared libraries and find more instances of fewer more general interfaces and of course prefer explicit coupling to tacit or latent coupling so if you if the coupling is going to be there but it's only in your head find some way to write it down in the code and make it visible in the code to whoever comes after you so that is my somewhat abstract thesis on coupling and especially uncoupling thank you for your attention [Applause] thank you Michael any questions yeah one so there's a strategy design pattern which is kind of a that you start looking at your system and you'll find out where places they're likely to change and you isolate them and you abstract them and a lot of frameworks in Java came up with very over bloated frameworks for that and solutions for that or and you when you try to avoid these kind of situations and over coupling you tend to over abstract and abstract and isolate everything start with so is there a good solution to start with or is this all just learning and refactoring as you go so you mentioned over abstracting the the problem with that notion is it's a bit of a tautology what is it - over abstract well you know when you've done it you've gone too far it's too difficult to work with I could do another long talk just on abstraction but I won't do that now the key to abstraction is that you are bringing together dissimilar things and emphasizing the the the similarities they do have so I often go back to this seek abstraction in closure seek has two things it has a head and it has a next and when you get the next you get a seatback that abstraction is super simple literally irreducible you can't make it any smaller and yet it allows us to treat strings and vectors and lists and xml documents and file systems all with the same set of functions so i would regard that as a successful example of an abstraction over abstraction is probably what you mean by someone who's who's getting close to the inner platform effect where you take your relational database and you make table tables object attribute and relationship and you sort of build a new database inside of your old database when you get to the point where your API is expressing a general-purpose programming language you've probably over abstracted but if you focus on emphasizing similarities and papering over differences you're not going to run into that any other questions and do you think that there are certain like pairings or coding languages that influence coupling that like favor rice coupling or favor i's uncoupling hmm boy you guys are really trying to load me into or lure me into dangerous territory I'm gonna speak primarily in the context of distributed service based systems personally I favor frameworks that allow me to treat requests and entities coming over the network as data rather than trying to turn them into objects at the earliest possible opportunity and partly that's because when you map them to objects it's like saying I have a concrete type that I'm receiving on this this interface so imagine an analogy in the functions inside of your your program if I write a function that takes a collection say for Java programmers takes a collection you're allowed to pass me any kind of a collection if I write something that takes ArrayList then you must pass me an ArrayList right and so sort of the more concrete I get in my function definition the less freedom I'm allowing you as a caller conversely the more abstract I am in my interface actually the more restricted the provider is because there's less you can assume about the data coming in and so you you have to be more careful so the languages and frameworks that allow you to treat your calls as data upfront allow you to be in that more abstract area rather than saying you know this is an ArrayList that's directly mapped to JSON last question what do you think about graph QL versus versus rest in terms of coupling I'm not gonna do a versus on them I'm gonna look at each of them in terms of those dimensions of coupling so graph QL and rest they both have exactly the same functional or operational coupling you know it's orthogonal to how you express the query I think the semantic coupling in graph QL is probably stronger because you've got a web of objects that you're querying and have knowledge about somewhat mitigated by the fact that those could be interface layer objects they don't have to be your domain layer objects and I think in in rest the semantic coupling if you do pure rest you know level five Richardson style rest the semantic coupling is quite strong because consumers are sort of allowed to change any aspect of the representation and and put it back and so they're sort of encouraged to develop knowledge about everything in that resource thank you Michael [Applause]

Channel: GOTO Conferences

Views: 22,967

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOams, GOTO Amsterdam, Uncoupling, DevOps, Software Architecture

Id: esm-1QXtA2Q

Length: 52min 50sec (3170 seconds)

Published: Thu Nov 08 2018