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).
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).