> where if you have a "sufficiently complex combination of state and code" you probably have a problem rather than a candidate for wrapping in a class Ironical

> where if you have a "sufficiently complex combination of state and code" you probably have a problem rather than a candidate for wrapping in a class Ironically, I think most people in that situation would agree with you that they "probably have a problem" -- the difference is that they see the problem as the important thing to focus investing resources into solving whereas you see its existence as an inherently poisoned entity that must be conceptually purified. While both parties would probably agree on the existence of /a/ problem, the definition of what needs to be addressed and how is likely to differ, and I can't say that the latter attitude is the norm at any high productivity engineering organization I've ever worked at, built, or encountered.