this post was submitted on 20 Jul 2023
4 points (100.0% liked)
Programmer Humor
32448 readers
957 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is the one thing where my opinion might be highly unpopular, but I don't see circular dependencies as something bad. If you write really structured modularised code, and just use the APIs of the different modules, it is completely fine to have different modules all depend on each other. At least in object oriented programming, using this approach that's almost guaranteed to happen.
E.g. imagine a configuration module: Other modules need access to the configuration module to get the different entry values, but the configuration module needs access to other modules to change specific stuff if you change a configuration entry. Of course you could separate that module into one data part and one action part changing the data and doing stuff in other modules, but if you use many modules like that, this will just become even more complicated and lead to duplicated structures (e.g. a specific data tree plus the exact same tree for actions) which would be cleaner if it was directly in the same module.
Or a different example: An (e.g. discord) bot which is connected in one module, and both messages to the bot can lead to the module getting informations from other modules and actions in other modules can trigger the bot, leading to them depending on each other.
Circular dependencies can be removed in almost every case by splitting out a large module into smaller ones and adding an interface or two.
In your bot example, you have a circular dependency where (for example) the bot needs to read messages, then run a command from a module, which then needs to send messages back.
This can be solved by making a command conform to an interface, and shifting the responsibility of registering commands to the code that creates the bot instance.
The
bot
module would expose theBot
class and aCommand
instance. Thecommand_foo
module would importBot
and export a class implementingCommand
.The
main
function would importBot
andCommandFoo
, and create an instance of the bot withCommandFoo
registered:It's a few more lines of code, but it has no circular dependencies, reduced coupling, and more flexibility. It's easier to write unit tests for, and users are free to extend it with whatever commands they want, without needing to modify the
bot
module to add them.