This is definitely not my original idea in the least. I wish I knew where I originally found this so I could share that, but seeing that I can’t find it and I haven’t seen it anywhere else, I’d like to share this idea so it can become more well-known.

What is a cyclic dependency? It is one of mutual dependency, where one class depends on another that also depends on the first one, as shown below.

There can also be more classes in between as shown below, where it just eventually circles back to the beginning.

You probably know this, but in case you don’t, you should know that you don’t want these types of situations. They hurt the understandability of your system and make it harder for garbage collectors to clean them up when they’re done. There are probably more reasons, too, but I’ve never paid much attention to this, and it seems that as a whole, the community knows that they should avoid cyclic dependencies but doesn’t do much to avoid it.

Anyway, what you’re looking for is a nice acyclic directed graph of dependencies as shown below, where all the arrows point down.

So, how do we go from this

To an acyclic directed graph? What would that graph look like?

Well, it would look like this!

You take the part of the class that is depended on by the other class and extract it. Do this for both classes, and your problem is solved!

With these super vague graph images, it may be difficult to really see how this can actually be done, so I’ll give you a really simple code example (written in Kotlin and Python!). It should help you get started when breaking apart your cyclic dependencies.

The two classes are almost exactly the same, but that doesn’t really matter. What matters is that the dependent parts can be extracted. What parts of type B does A depend on? And vice versa? Each class depends on the other’s alert() method. So let’s extract those out:

You may notice that, due to the cyclic dependencies, there was no way to create instances of the original classes without null/None because each one would require an instance to exist in order to make it.

Now, it’s possible to create an instance where the constructor takes in all of the fields without any temporary nulls/Nones.

Outro

As I said before, I realize that this is a super simple example, and I don’t expect it to make you into experts on removing cyclic dependencies. What I do expect is that you now have your mind wrapped around the basics and can start trying to take apart some of these when you see them.

I will admit that there is at least one “kind” of cyclic dependency that this doesn’t fix: A child pointing back to its parent. For example, you have a FilingCabinet with a list of Files in it, and those Files also have a pointer back to the FilingCabinet they’re in if you ever need a way to traverse back up the tree when you don’t know the original already.

The advice I’ve seen on this is to lose the link going back to the parent and instead put in a method that does some kind of lookup to find the parent. This is silly; it still has the cyclic dependency; it’s just that the dependency is either one step further removed (for a fully in-memory, in-language lookup) or is pulled into a different kind of system (for something like a database lookup).

I recommend either trying to make it so that the code doesn’t need to go back up the tree or that the parent is passed in along with the child, possibly in some sort of custom parent-child pair type.

Some of you who follow me may have noticed a tendency of mine to “hack” programming languages more than really use them (other than reflection via annotations in languages such as Java; I hate that stuff), and today is no different. Today, we look as using what would be normal higher-order functions as Python decorators to create new functions that encapsulate the idea of both the higher-order function as well as the passed-in function under one name. Continue Reading

A while back, I did a post on making instance-level properties in Python where the implementation of it required inheritance as well as messing with __getattribute__() and __setattr__(), which are a little dangerous to mess with. Then I had another idea last night (as of the time of writing this): Use normal descriptors to delegate to “Delegated Properties” (name taken from Kotlin, the original inspiration). These Delegated Properties can be designed very simply in a way that they only have to worry about the value on one instance, instead of figuring out how to store the value per instance. Continue Reading

So, this post was going to be completely different. I was going to do a post on how you can restrict the creation and scoping of certain objects using Python’s with code blocks. Unfortunately, with doesn’t restrict scope. Take the following code sample: Continue Reading

Some of you may know that Apress contacted me a little bit ago, wanting to publish my book under their brand. Well all the work is done now, and the book is up for sale on their web site, and soon it will be up on Amazon!

So go add the book to your wish lists!

Thanks for all your support, everyone. If I didn’t have a decent following, I’m not sure I would have written the book in the first place.

P.S. My second video is recorded. I just need to do some editing, and it will be put up soon.

This is going to be a short one to get me back into writing again. I just wanted to point out some interesting things I’ve noticed about Python inheritance that I’m (sometimes) sad that Java or C# don’t do. Continue Reading