5 Tips To Achieve Low Coupling In Your Python Code

In this video I share 5 tips to help you write code that has low coupling. I'll show you several examples and also share a story of a technique I used several times in the past that has really help me reduce coupling and solve more complex software design problems.

🎓 Courses:

👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!

👀 Code reviewers:
- Yoriz
- Ryan Laursen
- James Dooley
- Dale Hagglund

🔖 Chapters:
0:00 Intro
1:32 What is coupling?
2:08 Tip 1: Avoid deep inheritance relationships
5:49 Tip 2: Separate creating resources from using them
8:01 Tip 3: Introduce abstractions
12:40 Tip 4: Avoid inappropriate intimacy
15:55 Tip 5: Introduce an intermediate data structure

#arjancodes #softwaredesign #python

DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!

[alexliu]

Intermediate structures are the key idea of building data applications, analysis. Using data standards as an interface so that you can split the pipeline into decoupled parts. Create smaller data structures as objects when necessary to lessen the burden of larger classes. Thanks Arjan!❤

[POINTS]

6:48 Using a helper function to create objects works great! Ever since I watched your other videos on decoupling, I was at a loss for a simple way to create objects that were previously in the class initializer.

10:58 Showing how a Protocol class is useful here especially with third-party libraries is really helpful. Again, after watching your previous videos on decoupling, I wasn't sure how to setup my class to work with both an ABC and the third-party library. Using a Protocol class will solve this.

Thanks for the great video!

[TheCalcaholic]

What really taught me to avoid strong coupling in my code is when I started working with rust.
The variable ownership concept of rust makes heavily coupled data structures (as I was used to to from working with strongly object oriented languages) very painful.
I really learned to think about software architecture differently from that :)

[jasonx]

We used intermediate structures a lot in the enterprise search I worked on. We had individual parsers for different file types like PDF or Word or HTML, etc, that all converted to our internal XML that kept the relevant information we needed like sentence and paragraph structure, but didn’t care about any other formatting. So the actual search indexer didn’t need to know anything about the original document formatting. We supported cross language search, as well, so we had intermediate objects to represent the “idea” that the user searched for, which we could retrieve in any language, not just the one they used. (Mostly useful for multilingual support orgs where documentation is not always in sync across languages.)

[zubirhusein]

Very good set of tips here. This is extremely useful for working with databases and schemas. It's way easier to test when you abstract the DB details away into a database adapter class and abstract schema. Need to change database? Now you only need to change the adapter instead of every piece of business code that interacts with the data.

[sjmarel]

Nice! I recently applied many techniques you have described in your videos to several projects at work. Protocol produced lots of awesomeness. We had this problem were we have several database sources that didn't share a common engine, and also different database destinations. Using protocols we just described the interface for the extraction class and the loader class and then, each time we had to add a new source or destination, we just added a new class from that protocol. A configuration file described which subclass to use. The course is so clean and concise now... Thank you again!

[robertbrummayer]

Great video, Arjan. I agree, low coupling is generell a good thing to aim for. Moreover, when combined with high cohesion in each individual module, this is usually a sign of excellent code quality.

[TheBlazeThrower]

I was looking for this exact video in your channel over the last few days for a project where I’m struggling with coupling. Amazing timing! This helps so much

[djl]

I really like these kinds of videos, which are brief reminders of what your channel is really about. As a personal observation, intermediate data structures can be a challenge to design effectively in non-trivial cases. The sheer effort required to perform the raw analysis of a non-trivial problem domain and subsequent design of the data structure(s) to adequately cover the solution domain is only part of the challenge, the larger part of the challenge tends to be posed by the management style of the "average project manager" -- this translates into time pressure to "get things done". Then again, this could be said of any of the best practices that you cover on this channel.

[ankursrvstva]

This is amazing and so well explained with examples. The protocol way is much cleaner and makes more sense after watching this video.
Thank you so much!

[MichelAlbert]

The "Inappropriate Intimacy" reminds me about a "code-smell" I look out for during reviews: Overuse of list-indices. I've come to realise that the more time I invested into code-maintainability, decoupling, separation of concerns and dependency injection/inversion the number of times I need to use list-indices has plummeted. They are still necessary at times. But more often than not, there are better/more appropriate datatypes than list or tuples. If I spot excessive index-usage I do tend to take a closer look to see if nothing can be done about it.

[EldorJ]

This is a really great tips not just in python but almost all programming languages. Great stuff here Arjan!

[kwanyise]

wow, terrific video.
I have been watching your videos for for some past few months now and and you are really good at what your doing. if you could help us create a series of videos on a any of your side project showing us how you will apply all what you have been doing in your videos (from design, code refactoring etc), like combining everything in a single project. Thanks Sir @Arjan.

[gleep]

You have no idea how long I've been looking for this kind of content. Thank you so much.

[Smartskaft]

I love this stuff. I use it all the time, for as many third party libraries or utilities as I can. Configuration parameters, inputs and outputs, visualization data. A simple data structure goes a long way of making life so much easier when your dependencies change. And keep you sane while unit testing your code, since you can avoid any mocking or stubbing procedures over-engineered by the library developers.

[mrswats]

Inappropriate intimacy is such a funny name

[bkyuch]

I'm really amused by how good your content is. I've worked only 2 years as a software dev and can learn so much from your explanations. Thank you, Arjan! :)

[Yotanido]

One thing I have learnt the hard way, though, is that you sometimes have to be careful not to reduce coupling too much. Strong coupling is bad, but splitting your code into a million tiny pieces that barely interact with each other is also terrible.
I've now switched to writing coupled code first, and refactoring it once it becomes a problem. I suppose it is kind of like avoiding premature optimisation, if you abstract too much too fast, you might accidentally end up with Java.

Then again, especially some of the earlier (negative) examples in this video were... well. Gotta be honest, I wouldn't even have considered those approaches.

[astronemir]

This is the perfect follow up to your ABC/Protocol and Uncle Bob's videos. Thanks so much for sharing. Your videos have helped me immensely. I now maintain several code bases that thanks to separation of concerns, are well tested And easily extensible. The last part is super important for the astrophysics research I do. Previously, I would write a new set of scripts, (20-100) for each research project just because they are all so different., and my attempts at creating libraries were never quite successful. But I realized that it was the degree of coupling which made it really hard to extend and re-use my codes. I am both more productive and a much better coder.

[Pirake]

Fantastic video @Arjan, I love these best practice practical guide videos.