

That’s why in Canada virtually everyone is a “Software Developer”. Same job across in the state you’ll be called an “engineer”.
That’s why in Canada virtually everyone is a “Software Developer”. Same job across in the state you’ll be called an “engineer”.
Why bother with NP++ if you already own sublime, which is arguably equivalent or better, is my question. I use Sublime and I am wondering what feature could be missing to justify still having NP++ installed.
Genuine question, why use both Sublime and NP++?
This but non-ironically.
What you seem to be describing is one big class 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 class is still much better than splitting it into inter-dependant classes. Classes that know each other are so cohesive that they might as well be the same class 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. And I am assuming here that you’re using a language that is friendly, in some languages you won’t even compile past a certain point, and good luck cleaning up that mess.
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.
Agree with you, but small nitpick, password sharing was encouraged at some point, at least from the PR side of the business.
We did something similar with our APIs. It broke every conventions and expectations of the product and the language, and of course didn’t follow any logical good practices. Man did the boss love to tell me users had to read the doc anyway so we might just as well do whatever. Then later on when issues arose and I suggested making better APIs I was hit by some dull remark about how we shouldn’t violate the principle of least-surprise by going a different direction. Bitch are you kidding me? You broke that very principe in the first place by making grotesquely alien APIs.