Comments on: Anti-Patterns and Worst Practices – Heisenbugs

By: Sorin

Sorin — Tue, 02 Jun 2009 10:26:32 +0000

What do you think about something like:
…
private int? _cachedValue = null;
public int CachedValue
{
get {
if(!_cachedValue.HasValue)
_cachedValue = repository.GetValue();
return _cachedValue.Value;
}
}

…
private void ResetCache()
{
_cachedValue = null;
}
…

By: Chris Missal

Chris Missal — Tue, 02 Jun 2009 05:34:02 +0000

@Jacob

That’s a very good point. While in my example the name of the method was a giveaway as to what was going on, there’s nothing wrong with that name. Since I wasn’t doing concurrent operations in my sample code, the name seemed to give something away. If you are doing this type of transaction, something along the lines of a Unit of Work implementation is probably more suited to your needs. Really, anything transactional could encounter situations like this. I’ll be honest, I don’t work in these types of environments, so I don’t always keep them in mind.

By: Jacob Stanley

Jacob Stanley — Tue, 02 Jun 2009 04:07:43 +0000

Aren’t methods with semantics like GetNextNotification() required in a concurrent environment? That is, an environment where you need to atomically execute a command as the result of a query.

How would you handle this kind of operation in a concurrent system without breaking the rules?

By: colinjack

colinjack — Sat, 30 May 2009 19:23:22 +0000

@Joe
Its a query but it doesn’t mean we’re breaking tell dont ask. Agree its not great code, I wouldn’t put this sort of code inside a setter for a start, but I just didn’t see it as particularly violating CQS is all.

@Chris
Definitely that makes perfect sense and agree on getters/setters.

By: Chris Missal

Chris Missal — Sat, 30 May 2009 15:31:49 +0000

@Colin

I should have shown the bad code I wanted to avoid altogether, logic inside the getter (code shown is of the object being called). This would be breaking CQS. I opted to show more realistic code that does some work inside the setter. This is more common in my experience, but in my opinion is just as bad as putting command logic in the getter. Getters/setters serve as a way of, just that, getting values or setting values. When they do more than what is on the surface there are usually problems. While you could consider my setter example above in no way breaking CQS, I’d like to point out that it isn’t as discoverable as it should be as @Joe also points out. Hopefully this clears up some ambiguity.

By: Joe Moore

Joe Moore — Sat, 30 May 2009 14:50:32 +0000

Maybe Chris considers “value.IsValidFor(this)” a query? It certainly does appear to query the current object, though a lot of my methods would also fail CQS horribly for the same reasons.

The first couple examples smell regardless because they fail the Rule of Least Surprise.

By: Chris Missal

Chris Missal — Sat, 30 May 2009 14:35:25 +0000

@Colin

My mistake, if you’re *not* careful, thanks. :)

By: colinjack

colinjack — Sat, 30 May 2009 14:03:38 +0000

“If you do, good for you; this is the kind of code that breaks CQS guidelines and can creep into your codebase if you’re careful. ”

I’m missing something, why do you say this is breaking CQS?

As you say later if it was in the getter that’d be different, and its not great code either way, but I’m missing why its a CQS violation.