Rogue Dependencies
public class CookieHandler {private static readonly string CookieName = "TheCookie";public void DoSomething() {string cookie = Cookies[CookieName];Process(cookie);}}
...and all was good with the world.Now at some point some other code needs access to the same cookie. We have a couple of different ways of dealing with this issue:
- Make some common library that deals with cookies
- Copy-and-paste inheritance and just copy the string "TheCookie" over
- Make the private a public and just use that across assembly boundaries
The first option is the best in my opinion. It's also typically the costliest which is why it's not done often.Both of the other options suck, but for different reasons.The copy-and-paste now hides the fact the the string is magical now. If ever someone wants to change the name of the cookie, something unrelated breaks. It engenders fear into everyone that touches code. This is a vicious cycle of only adding code and never refactoring because touching, or even looking at working code might break it. This leads to even more copy-and-pasting until you have spaghetti. Congratulations, you made an invisible dependency!The second one breaks encapsulation and introduces a rogue dependency in the code. It might be easy for you to just reference another assembly or library, but now you're dragging around more and more crap with your system. The notion of libraries having a good and defined purpose starts to slip. As this continues the system slowly turns into the proverbial ball of mud. Hard to understand and maintain with strange dependencies.The real key is to have the confidence to be able to refactor your code. Depending on who you talk to, you'll get different responses. The underlying concept is the same: confidence. Much more importantly, the lack of fear.