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.
v-----------\
bot command_foo
\-----------^
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.
main <---
^ \
| \
bot ---> command_foo
The bot module would expose the Bot class and a Command instance. The command_foo module would import Bot and export a class implementing Command.
The main function would import Bot and CommandFoo, and create an instance of the bot with CommandFoo registered:
// bot module
export interface Command {
onRegister(bot: Bot, command: string);
onCommand(user: User, message: string);
}
// command_foo module
import {Bot, Command} from "bot";
export class CommandFoo implements Command {
private bot: Bot;
onRegister(bot: Bot, command: string) {
this.bot = bot;
}
onCommand(user: User, message: string) {
this.bot.replyTo(user, "Bar.");
}
}
// main
import {Bot} from "bot";
import {CommandFoo} from "command_foo";
let bot = new Bot();
bot.registerCommand("/foo", new CommandFoo());
bot.start();
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.
It does not get more complicated to split your example. What gets more complicated is giving all sort of unrelated responsabilities to a single class, simply because it is the path of least resistance.
In your example, all you need is an extra module listening for configuration changes and reacting to it. This way you leave your context-specific logic out of your data model, no need for cyclic dependency. There are so many downsides to cyclic dependency, to justify it because splitting your logic is “too complicated” really isn’t a strong argument.
I honestly don’t see a single downside, as long as it’s modularised, maintainable and with clean APIs. And e.g. with a configuration module: The place where I’ve experienced this was a place where bigger parts of the configuration module were classes to build specific custom tree configurations. And if one module would just save what should happen at the change of each entry (and not save that with that entry), it would need to duplicate the whole structure and map it to the entries, which is ugly. It just makes sense to put those strongly related configurational things into one configuration module which provides an easy API (one method for changing and one for retrieving a config element after constructing it and adding other modules).
What you seem to be describing is one big module with lots of responsabilities, and not circular dependency. Personally, I don’t think it is ideal, and I don’t know about your specific case so I could be wrong, but I have never seen a legit case for bloated classes. That being said, making a big module is still much better than splitting it into inter-dependant modules. Modules that know each other are so cohesive that they might as well be the same module anyway.
To add onto the circular dependency problem, it is not just about readability and cognitive load (though there is some of that), but cyclic dependencies actively break things, and make it much harder to manage the lifecycle of a program. No dependency injection, poor memory management, long compile times. It is a huge hack, and I understand that you think it can be the proper solution sometime, but it is really just a bad thing to do, and it will bite you some day.
Satan has created a library that runs as efficiently as possible and covers every possible use case, and all we need to do to get access is sacrifice 1000 virgins. Do it for the cause.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
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.
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
botmodule would expose theBotclass and aCommandinstance. Thecommand_foomodule would importBotand export a class implementingCommand.The
mainfunction would importBotandCommandFoo, and create an instance of the bot withCommandFooregistered: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
botmodule to add them.It does not get more complicated to split your example. What gets more complicated is giving all sort of unrelated responsabilities to a single class, simply because it is the path of least resistance.
In your example, all you need is an extra module listening for configuration changes and reacting to it. This way you leave your context-specific logic out of your data model, no need for cyclic dependency. There are so many downsides to cyclic dependency, to justify it because splitting your logic is “too complicated” really isn’t a strong argument.
I honestly don’t see a single downside, as long as it’s modularised, maintainable and with clean APIs. And e.g. with a configuration module: The place where I’ve experienced this was a place where bigger parts of the configuration module were classes to build specific custom tree configurations. And if one module would just save what should happen at the change of each entry (and not save that with that entry), it would need to duplicate the whole structure and map it to the entries, which is ugly. It just makes sense to put those strongly related configurational things into one configuration module which provides an easy API (one method for changing and one for retrieving a config element after constructing it and adding other modules).
What you seem to be describing is one big module with lots of responsabilities, and not circular dependency. Personally, I don’t think it is ideal, and I don’t know about your specific case so I could be wrong, but I have never seen a legit case for bloated classes. That being said, making a big module is still much better than splitting it into inter-dependant modules. Modules that know each other are so cohesive that they might as well be the same module anyway.
To add onto the circular dependency problem, it is not just about readability and cognitive load (though there is some of that), but cyclic dependencies actively break things, and make it much harder to manage the lifecycle of a program. No dependency injection, poor memory management, long compile times. It is a huge hack, and I understand that you think it can be the proper solution sometime, but it is really just a bad thing to do, and it will bite you some day.
5 interdependent modules? how sweet…
only 5?
Pentagram for demon summoning ⛤
Luckily, we have an endless supply of virgins to sacrifice. Nobody said they have to be female, right?
But then, who will maintain the code?
We’ll outsource it to India.
Better to use China, they’ve got plenty of excess virgins
Nah, let’s start from US -> Virgin Islands
Think maybe the project manager will fall for it?
Satan has created a library that runs as efficiently as possible and covers every possible use case, and all we need to do to get access is sacrifice 1000 virgins. Do it for the cause.
Sacrifice 1000 programmers, got it
Well i fell for it already and now there is no going back 😨
5? Those are rookie numbers, gotta pump up those dependency graphs!