The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
You probably could, with a bit of thinking about it - it's obvious when you see it, but it's a stinker to spot if you didn't write the code (and probably even harder if you did if you are anything like me: I tend to see what I meant to write, rather than what I did )
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
Roughly 90 seconds, mostly working out which Console.WriteLine call was which.
Spoilers ahead - select the block to view:
Take a copy of the static field;
Create a new instance, thus overwriting the static field;
Compare the new instance to the copy of the old value of the static field - result = false;
Compare the new instance to the current value of the static field - result = true;
Damnit Chris, we need a <div class="spoiler">!
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
The problem is that you're assigning a static variable inside the instance constructor to that instance . So every time you create an object you're changing the Context property. The reason the tests are different is because you pass the Context as a parameter so even after the update the parameter still has the old Context.
A fix would be to not do that because it's bad design I'd make Context an instance property and implement your own ==, !=, Equals, etc unless you want referential equality.
Yeah, but it's never used that way - two different connection strings. But ideally, it shouldn't be possible to use it that way.
Sigh. The irony of this is that it's code I wrote a while back that my DataContext extension methods rely on, and looking at this now, it's some serious code smell. Fortunately, fixing it affects only a couple web servers that are in operation, but I feel embarrassed. But I blame .NET's DataContext. It does way to much with regards to the state of the Table object. I get what they're trying to do, but there must be a better way that doesn't end up throwing exceptions like "this object was created in a different data context."
The reason for the results are pretty obvious, when a new instance is created in "CreateNewContext", the parameter "context" is still referring to the original context, not the new one ==> false; When the main program does the compare afterwards, the comparison is done to the static that holds the new context ==> true.
Fixing this is not obvious because you didn't specify what the correct behavior should be.
Do you wish it to be "True" always, or "False" always
Simply update the context parameter in the method to get True always, but I would personally recommend to re-write this whole thing, it is full of code smells. Perhaps some practice in TDD would also be helpful.
It's the assignment of the static member from the instance constructor. HUGE no-no. If you want to make a singleton without using a DI framework, at least make the constructor private and have the static "Context" member be a property that will create a new object if one doesn't exist, and set it to a backing field. Something like this (might need to make Current a method instead of property if you need to pass constructor arguments, but you get the idea):
public class Singleton
private Singleton _current;
public Singleton Current
if (_current == null)
_current = new Singleton();