考点频率★★★★★上午选择题必考下午案例题也常涉及难度⭐⭐建议理解内聚耦合的评价原则和判断准则重点掌握评价模块设计质量的方法1️⃣ 什么是“高内聚、低耦合”高内聚、低耦合是软件工程中模块化设计的核心原则也是判断模块设计好坏的黄金标准。用一个比喻来理解高内聚一个模块就像一个专业的团队——团队成员各司其职但目标一致每个人都围绕同一个核心任务工作。比如一个“财务计算”模块团队里所有人都在做财务相关的事情没人分心去做UI设计或网络通信。低耦合模块之间的关系就像合作公司——彼此之间有业务往来调用接口但各自内部怎么运作互不干涉。比如“订单模块”和“支付模块”通过API交互支付模块改了内部算法订单模块不需要跟着改。一句话理解低耦合是“管好自己的事少管别人的闲事”高内聚是“把自己那一亩三分地精耕细作好”。2️⃣ 高内聚与低耦合的评价原则判断一个设计是否符合高内聚、低耦合可以从以下几个维度来评估评估维度优秀设计表现高内聚低耦合糟糕设计表现低内聚高耦合单一职责每个模块只负责一个明确的功能一个模块既做数据计算又写日志还发邮件接口简洁性模块间接口简单清晰参数数量少建议≤4个接口复杂传递大量参数或复杂数据结构变更影响面修改一个模块只需在该模块内部进行改一处代码牵连好几个模块都要跟着改复用性模块可以在不同项目中直接使用模块依赖太多外部条件离开当前项目就用不了可测试性每个模块可以独立进行单元测试测试一个模块必须先准备好一堆其他模块变更隔离性模块内部的修改不会扩散到外部调用方修改模块内部实现导致所有调用方都要改代码可理解性看一眼模块名就知道它大概做什么看完模块全部代码也不知道它到底想干嘛变化频率不同模块的变化频率相互独立需求一变所有模块都得跟着大改判断逻辑实践经验如果新增一个功能时你需要修改3个以上的模块才能完成 → 说明模块划分可能不合理耦合度过高或内聚度不足。3️⃣ 低内聚、高耦合的典型表现反面案例在实际项目中模块设计不良常表现为以下几种“症状”这有助于你在选择题或案例题中快速判断模块质量问题3.1 低内聚的典型表现代码臃肿一个模块几千行代码什么都往里塞不知道它到底负责什么职责发散模块中的函数看起来“各有各的想法”找不到一个共同的核心目标频繁修改只要有需求变更这个模块总是要改说明它承担了不该承担的责任3.2 高耦合的典型表现改一牵十修改一个模块的接口导致大量其他模块需要跟着改全局变量满天飞多个模块频繁读写同一个全局变量数据流向混乱循环依赖模块A调用BB又调用A形成一个环直接访问内部数据模块A直接读写模块B的私有属性或缓存4️⃣ 如何在设计中践行高内聚低耦合4.1 提高内聚的方法方法说明单一职责每个模块只做一件事情功能内聚的目标面向接口编程模块之间通过接口协作而非具体实现。即使模块内部分解为多个类也通过接口暴露功能合理拆分当一个模块代码量超过200行或职责超过2个时考虑进一步拆分命名即文档模块名要准确反映其职责如TaxCalculator比Utils好4.2 降低耦合的方法方法说明减少参数数量能传1个参数就别传3个能用简单值就别传整个对象避免标记耦合升为内容耦合避免控制耦合不要让调用方传控制变量来决定被调用方的行为——把“选哪条路”的决定权放在被调用方内部避免全局变量通过参数传递而非全局变量共享数据遵循依赖倒置原则高层模块不应依赖低层模块的实现细节5️⃣ 典型例题例题1下列关于“高内聚、低耦合”原则的叙述中正确的是 。A. 模块之间传递的数据越复杂耦合度越低B. 模块内部各元素之间联系越弱内聚度越高C. 高内聚、低耦合是模块化设计的理想目标D. 高内聚必然导致模块之间的高耦合解析A错误——传递的数据越复杂耦合度越高数据耦合→标记耦合B说反了——内部联系越弱内聚度越低D错误——高内聚和低耦合是独立属性一个模块内部做得好不代表它和外部的关系差。C正确。选C。例题2真题改编某系统在设计时模块A直接通过访问模块B的全局变量来获取数据这种设计违反了 原则。A. 高内聚B. 低耦合C. 高内聚和低耦合D. 以上都不违反解析通过全局变量共享数据 →公共耦合耦合度高违反了“低耦合”原则。选B。6️⃣ 记忆口诀高内聚模块内部一条心低耦合模块之间少操心。接口要简单依赖要清晰改了不扩散测了不牵连。7️⃣ 小测验评论区对答案以下哪种做法最有助于实现“低耦合”的设计目标A. 模块之间通过全局变量进行数据共享B. 模块A调用模块B时传递一个控制标志让B决定执行逻辑C. 模块A和模块B通过定义清晰的接口进行交互不共享内部实现D. 模块A直接访问模块B的内部数据结构以提高效率本专栏日更点击头像 → 专栏《软考中级高频考点》订阅第一时间接收新内容#软考中级 #软件设计师 #高内聚 #低耦合 #模块设计 #软件工程