winform 窗体中的状态地狱

在winform 开发中, 最麻烦的莫过于状态纬度太多.
状态纬度的增加会导致编程复杂度 程 几何倍的增长.
一般程序员能控制在4-5个纬度状态的相互影响下,就已经很不错了.
超过4-5个纬度的状态一般人都控制不了. bug会超级多. 想都想不到.

举个例子, 比较容易理解, 一般最常见的情况是. 编辑界面上都会有个当前的状态是不是编辑状态的字段,
用来区分当前数据是否在编辑中.

还有一些业务中一般 有一个字段是用来判断 当前数据是否已审核.

还有些用来判断是否已打印

还有些用来判断是否已真实保存到数据库中. 针对没有保存到数据库中的数据要如何处理, 针对已经保存到数据库的数据要如何处理.

还有些控制用户界面是否可用的状态, 用户在某些情况下可以用这个按钮, 某些情况又不可以用.
还有一些你根本考虑不到的用户操作. 完全不按照正常情况的越轨操作. 这些问题的处理一般情况下都是判断状态是否满足要求…

这些都不是问题,

问题是这些问题相互叠加, 相互干扰,相互制约的时候. 这个程序就会变成一个非常麻烦的排列组合问题.
另外再加上一些程序纬度的 null指针的判断. DBNull判断, 数据合理范围判断. 等等. 这么多的事情. 搞的焦头烂额.
如果某些 业务中再增加几个特殊字段, 会影响系统运行方向的.系统关键字段.
如果这种系统关键字段 超过3个, 而且还会跟其它字段形成排列组合问题…
这个系统想也不用想 越多越不稳定.

程序员不是不会写程序, 而是被这无底的状态叠加给打败了.

谁能彻底的解决这些问题呢?

设计模式中是否有好的模式可以解决状态地狱问题?

或者有什么好的方案可以解决这种状态地狱问题?

作为一个老程序员, 我一般都是尽量避免引入全局状态. 把状态控制在一个函数内是最好的.
全局状态的引入,会增加系统的复杂度. 越多越复杂, 越多越不稳定.

新手的第一选择一般就是引入状态. 而对于吃过亏的老程序员. 都明白, 状态要越少越好.