Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

潜在的逻辑复杂度与封装

  还记得上学时有这么一道物理题:“有若干个单刀双掷开关,如何设计一个电路,使得任何一个开关都可以控制灯的状态。”。这题目本身并不难,把每个开关视为一个布尔值,将各种会让灯泡发光的状态组合连接即可。但问题是,这样的电路复杂度会因为开关的个数指数增长。

这是个糟糕的设计

  小时候听到物理老师给我们解释这个问题时觉得好厉害啊。但厉害归厉害,实际上这种设计是非常不易扩展使用的。要是有100个开关,这电路是要变得多复杂?所以这种方案绝对是糟糕的设计。

组件与封装

  如果真有这么奇葩的需求甚至更复杂的需求,还不如开发个手机APP,用一个终端去管理灯的开关,既简单又实用。我们根本不需要了解手机的构造,不需要了解其他硬件或驱程序动的构造,拿说明书直接用就行了,因为这些都是封装好的组件。

我们也同样糟糕

  电路设计上是如此糟糕,我们平时的程序更是如此。比如有两个元素需要控制显示隐藏,我们就在注册的事件中隐藏一个,显示另一个。当元素达到三个时就需要添加三个事件,每个事件操作三个元素。当达到四个元素时,总共就需要有十六个元素的显示隐藏操作?虽然复杂度的增量比前面的电路设计小,但这足以让开发者抓狂了。

我们也需要封装

  不封装的设计就一定会遇到以上问题。类似显示隐藏这样的布尔操作,虽然看似简单,但堆积起来就和单刀双掷开关一样可怕,所以应该尽量避免潜这些潜在的复杂逻辑。
  一旦有了需求就需要封装,电路的问题我们用的第三方的封装来解决。我们自己的编程问题也可以通过第三方来解决,还可以自己封装相应的组件。但无论何种做法,遇到潜在的复杂逻辑问题就一定要封装。除非你打算撒手不管程序将来的维护,否则绝对不要放任布尔逻辑。

网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^