Okey dokey, next crappy-code-at-work-rant-turned-into-a-real-question (I hope):
So, I'm debugging some code, and we've got something like this:
objFoo.TabIndex = 5 'VB.NET property with setter implicitly called
and TabIndex is a property whose setter is the beginning of an insane call tree, with subroutines and XML and special cases depending on context (like: modes), and so on.
(Gack. You can see what working here is doing to me. I just prefixed Foo with "obj". :( )
Ok, granted, we need to manage state and perform computations and whatnot. Our state is either in the database (but may be expensive to pull out) or it's not yet ready to be committed to the database (e.g., it's only half-baked), so we can't just run out to the d/b every time we need some info, but...
Is it better to manage this state in setters or is it better to do it in getters?
I would think doing it in getters (i.e., lazily) would mean we would compute (and, presumably, cache) only what we need, while doing it in setters means we're essentially overcomputing, anticipating what getters may be called in the future and precomputing their results. (And then, there are the data members that don't have getters at all, they're just global variables in a 6,000-line class.)
Shouldn't we just, as a general rule, set the indicated data member, maybe set some flags indicating other data is now invalid (cache invalidation) and wait for the various getters to be called to recompute?
I can imagine one argument for doing this in setters is that our object is so complex that we really need to configure its state properly, using multiple complex data members. But isn't that a red flag in itself, indicating that a better approach would be to break the object up into smaller objects, not write a complex setter?
(Now, I know there are all sorts of exceptions which people will no doubt point out, but I'm looking for a general rule of thumb and the logic behind it, or the statement that no such general rule of thumb is possible, accompanied by a convincing argument.)