Loose vs Tight Coupling

in software engineering we sometimes refer to our code and systems as being tightly or Loosely coupled but what does coupling really mean and what are the trade-offs involved when you try to make your code Loosely coupled coupling refers to how closely two parts of your system depend on or interact with each other in one sense it's how much of the logic and implementation details of these two parts begin to blend together when two pieces of code are interdependent this way they are said to be tightly coupled on the other side if two pieces of code are highly independent and isolated from each other they are said to be Loosely coupled when you hear coupling you'll often also hear of a very related term cohesion while coupling refers to how much two parts of your system depend on each other cohesion refers to how well the code within a single part fits together often when you have tight coupling you'll end up with low cohesion and when you have low coupling you'll often have high cohesion when you write code there are benefits of making your code Loosely coupled and cohesive first it can be easier to maintain because you're going to find that all the code related to a particular concern is co-located and together second it's going to give you more flexibility you have the ability to change the internals of one part of your code base without those changes spilling over into the rest of your system you could even completely swap out one part entire entirely in the other parts use system don't need to be aware of that so far this has all been very abstract so let's try to look at a more concrete example imagine that we're working on a simple system that is going to read in a comma separated file from disk then do some calculations on that data for the user we have two big chunks of logic here reading a CSV file and doing some calculations in one possible implementation we might have the calculation logic call into the CSV parsing logic get some CSV row objects back run the calculations and return the results bundled with the CSV data in this implementation the parsing logic and Report logic are pretty coupled together first the report code is explicitly calling the CSV Parson code second the report code is working internally with CSV row objects which means that the reporting code depends on some of the internals of the Parson code you can see how the parsing and Reporting concerns have started to blend a little bit together if we want it to change our system say to read Excel files instead of CSV files you can imagine having to trace how far the concept of a CSV file has permeated through the reporting code if we wanted to make these pieces of logic Loosely coupled we would want to find a way to make the two pieces of logic more independent there are a couple ways that we could do this one approach would be to have CSV parsing logic that sits isolated from calculation Logic the calculation logic could then Define an interface for how it expects to be supplied data a little bit of glue code could then use the CSV parsing logic transform the data to the form expected by the report code and then call the report code at this point because the parts are so isolated we could freely change or swap out a new file parser or even report logic without impacting the other loose coupling is a desirable trait for your code to have and if it isn't too expensive I recommend applying it however I also recommend being thoughtful when you choose to apply it I think in software engineering we sometimes have this tendency to take Concepts like loose coupling and interpret them as absolute laws that we need to imply in every circumstance however in reality I find that engineering is much more about making and weighing trade-offs so what are the trade-offs involve when you're trying to decide if your code should be more Loosely coupled on the positive side like we mentioned earlier loose coupling gives you a lot more flexibility separation of concerns and maintainability on the negative side it will call for some degree of abstraction or indirection we saw that in our example in the form of an additional interface and a little bit of glue code you might have heard the phrase premature optimization is the root of all evil however I think premature abstraction can also be the source of a lot of pain to help make the decision of when to decouple I like to ask myself a few questions what benefit am I going to get from this decoupling is this a real benefit or just a theoretical one how expensive will it be to decouple and by this I mean how much indirection or abstraction will I need do I have enough knowledge to make good abstractions yet if I don't I may end up doing more harm than good about decoupling the systems and it would be better to wait a little bit longer and see a little bit more examples of how these systems are going to be used how naturally interconnected are these two concerns the more they are the more costly it will be to separate the answers to these questions will often guide me to a solution all things being equal I generally prefer Loosely coupled designs because I find that the benefit will often outweigh the costs that said there are absolutely cases where I have left code tightly coupled and as far as I know I haven't been sent to engineering hell for it

Channel: Scott Bailey

Views: 9,583

Keywords:

Id: uWseUdUqM5U

Length: 5min 36sec (336 seconds)

Published: Mon Feb 27 2023