两种不同的代码行为模式
虽然不知道这是什么,但是在代码行为上很明确地可以被区分成二种不同的"行为模式"(行为模式is?).举例来说的话一个主界面包含多个子界面,当显示不同的子界面的时候,要求主界面的某些属性也要发生改变.所以应该怎么来处理这样的情况呢?
- 通知主界面,让主界面自己管理
在这种情况下,子界面无需知晓主界面任何API,当子界面被打开显示的时候,仅是告诉主界面该子界面被显示了,然后主界面根据当前的界面来改变自己的属性;当子界面被关闭隐藏的时候,同样的道理,也仅是告诉主界面该子界面被关闭了,然后主界面根据当前被关闭的界面来改变自己的属性.
这样做的好处是:代码剥离会很清楚,代码耦合低,但是可能写起来需要系统地考虑之后再来组织代码,后续维护的时候也需要多盯一下代码,因为子界面打开时显示的元素并不是由自己直接控制的,而是由主界面直接控制的.
- 主界面提供接口,子界面来管理
这种情况下,主界面需要暴露大量的API给子界面,子界面显示或隐藏的时候,自己调用主界面方法控制主界面的元素变化.这是大多数情况下信手拈来的行为模式.
这样写的好处是:逻辑比较清楚,子界面显示/隐藏都是在由子界面来管理,所以逻辑上感觉很顺.但是这样的代码耦合高,并且当子界面较多时会比较乱,尤其是多个人在维护一份代码的时候.
- 两种模式之比较
在我看来,如果用吃饭打比方的话,主界面好比餐厅,子界面好比不同的顾客,在第一种模式下,顾客只用进入餐厅吃饭(打开显示子界面),吃完饭之后付账走人(关闭隐藏子界面),其他的诸如提供餐具,食物,打扫之类的都由餐厅来负责.而在第二种情况下,好比吃自助餐,每个顾客要自己拿盘子,拿食物,最后打扫.第一种模式体验好,但是要付出更高的花费,第二种模式灵活直接,但是多人就餐之后可能会比较杂乱.
除此之外,也可能有二种模式混用的情况,比如有些元素是主界面来控制,而有些元素是子界面来灵活调度,但二种模式不控制好的话,我想更容易产生糟糕的代码吧.
最后一点,要说的是无论是哪种情况都要在子界面关闭隐藏之后做好清理和还原工作,清理和还原无论是在UI上还是在逻辑中,无论在何种情况下都是有必要去进行的.
