一、前言
大家都知道，在OO中有个很重要的设计原则：高内聚低耦合。就是一个功能，对外要尽可能隐藏起实现细节，只通过接口（函数声明）与外部进行通讯，这也是面向接口编程的重要思想，也是分责的重要体现。这样做的优点是，避免内部修改对外部的影响，而且内部设计的错误，也不会蔓延到外部去，就像疫情期间的封闭隔离一样，也有利于系统部件的复用（我只要函调这个类就可以了）。
在讨论内聚原则的时候，大家一般是在谈类的设计，后台的实现。其实这个原则不仅仅限于后台，在前台设计上也同样遵循这原则，前台功能，前台UI等等。
下面我就讲个实际工作中遇到的UI设计违反内聚原则的一个例子。
二、例子
大家看上面的这个界面。我们看和动作相关的几个UI元素。
查询，重置，导出。导出按钮后面还有两个radiobutton单选选项：实时导出，定时导出。
你看到这里是不是“一愣”。是的，我看到这个界面也是这个反应，但是随即就明白了这个选项的意思：选择导出的两种模式。
其实单从功能上来讲，这个导出的两种模式还是不错的。
（1）实时导出，点导出按钮后，会马上将表格中的数据形成excel文件，并下载到本地；
（2）定时导出，则会创建一个导出任务，系统在后台自动执行导出任务，执行导出的操作。这种比较适合数据量比较大的业务场景。
这个设计确认很棒。
但是在ui设计上，就不是那么他好了，我们来分析下。
三、问题分析
它这个界面的设计有什么问题呢？
1、违反了功能内聚的原则，将实现细节（两种导出模式）暴露在了外边。
这就相当于把你家的电源控制面板装在了家门外。显然是不好的设计。
应该如何设计了。有两个方案：
（1）将这个导出选项放到【导出】功能内部，也就是，在点击【导出按钮】之后的弹出的导出界面中，选择是 实时导出 还是 定时导出
（2）或者，拆成两个安按钮：实时导出，定时导出。去掉这个选项。
2、增加了功能间的耦合（其实也是违反了内聚）
我们将导出 和 导出选项 看做2个功能，这两个功能的耦合性太强了。就是导出功能，受 导出选项 这个功能的控制。
3、带来的第三个问题就是。
如果我要删除 【导出】功能，要同时删除 【导出】按钮 和 【导出选项】这两个raddiobutton 界面元素。因为导出选项 只和 导出按钮有关，没有其他用处。这个会给维护人员带来困扰：我只是要删除导出功能，只删除导出按钮就好啊，为啥还要删除 这个raddiobutton呢？当然这个例子利这个连个ui元素的关系是显然的，这个困惑不会很突出。
4、禁用 导出 功能的时候， 不仅仅要禁用【导出】按钮，还要禁用【导出选项】。这个在权限控制的时候也是个麻烦。因为我们在控制权限时，一般是只控制 作为动作入口的按钮的权限，而不会考虑其他界面元素。这增加了我们功能权限控制的复杂性。
四、总结
很多设计原则往往贯穿软件开发的哥哥环节，哥哥方面，需求，设计，实现，后台逻辑，前台界面都有设计。我们在学习设计模式时，要抓住其本质，学习其精髓，活学活用。这才是产品化思维的真正内涵。
标签：选项,功能,产品化,内聚,导出,按钮,设计,设计模式 来源： https://www.cnblogs.com/senline/p/dp_ui_hcohesion_lcoupling.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。