1. 为什么面向对象这一章值得单独拎出来死磕软件设计师考试里第七章面向对象技术是个很特殊的存在。它不像数据结构那样需要你现场推演算法也不像操作系统那样概念密集到让人头皮发麻但它有个更阴险的特点——分值分布广、题型跨度大、上午选择题和下午大题两头都占。我翻过近七八套真题上午场里面向对象相关的题目稳定在6到8分下午场的数据流图、UML图、设计模式填空加起来能占到15分往上。换句话说这一章你要是拿不稳上午可能刚好卡在及格线边缘下午直接丢掉一道大题。很多人备考时的误区是把这章当成“背概念”来处理封装继承多态背得滚瓜烂熟一到UML类图题就懵。问题出在哪儿面向对象技术的考试重点从来不是让你复述定义而是考你能不能把现实问题翻译成对象模型。上午题考的是你对UML图元素、关系符号、设计模式特征的识别能力下午题考的是你从一段文字描述里提取类、属性、方法再画出类图或者填出缺失代码的能力。这两件事的底层能力是同一个对象建模的思维习惯。我当初备考的时候这一章前后过了三遍。第一遍通读教材感觉什么都懂第二遍做真题发现UML关联关系里的聚合和组合永远分不清第三遍才摸到门道——原来这章的核心不是记忆是建立一套从需求文字到类图元素的映射规则。这套规则一旦建立起来上午题扫一眼就能排除错误选项下午题看到“包含”“由……组成”“管理”这类动词就能条件反射地判断关系类型。这篇内容适合两类人看一类是刚翻开教材、对面向对象只有模糊印象的零基础备考者另一类是已经刷过题但正确率卡在60%上下、需要把知识体系重新捋一遍的老考生。我会把这一章拆成概念底座、UML图解法、设计模式识别、下午题实操套路四个板块每个板块都配上我实际做题时总结的判断口诀和踩坑记录。你不需要有编程经验但需要准备好纸笔因为下面很多内容是要你跟着画的。2. 概念底座把封装继承多态从口号变成判断依据2.1 封装到底在考什么信息隐藏的边界感教材上对封装的经典定义是“把数据和操作数据的方法捆绑在一起并隐藏对象的内部实现细节”。这句话你背十遍不如做一道题来得实在。考试里考封装从来不会直接问你“什么是封装”而是给你一个类图问你这个类的属性前面加了下划线或者减号代表什么或者问你某个方法应该设为public还是private。我自己的理解方式是这样的封装考的是你对“可见性边界”的敏感度。UML类图里属性和方法前面那些符号——是public-是private#是protected~是包内可见——这些符号的用法是有套路的。属性绝大多数情况应该是-因为数据要藏起来方法则要看它是不是对外提供的服务接口是的话用只给自己内部调用的辅助方法用-。这里有个我踩过的坑下午题里经常出现“某类负责计算总价”这种描述很多人会把计算方法设成public但实际上如果这个计算只是被另一个类内部调用它应该是private的。判断依据很简单——看这个方法有没有被其他类的对象直接调用。如果没有就藏起来。考试出题人特别喜欢在“辅助方法”上设陷阱你稍微不注意就把可见性标错了。实操心得做类图题时先把所有属性一律标成-再逐个检查方法。只有那些在题目描述里明确出现“供外部使用”“对外提供”“可以被调用”字眼的方法才标其余全部-。这个粗暴规则能帮你避开八成以上的可见性错误。2.2 继承与多态的联合考法父子类替换的逻辑继承单独考的时候很简单就是箭头指向父类、子类继承父类的属性和方法。但考试真正爱考的是继承和多态绑在一起的场景。典型题目会给你一个父类“图形”和子类“圆形”“矩形”父类有个方法“计算面积”然后问你运行时调用哪个方法。这里的关键知识点是动态绑定。很多零基础的人不理解为什么要有这个东西我用一个生活化的类比来解释你去餐厅点菜菜单上写的是“招牌菜”但每家分店做出来的招牌菜不一样。菜单就是父类接口分店就是子类实现你点菜这个动作在运行时才决定到底吃的是什么。考试里考多态就是考你能不能判断出“声明类型”和“实际对象类型”不一致时方法调用跟着谁走。上午题里常见的坑是给你一段伪代码父类引用指向子类对象然后调用一个父类有、子类也重写了的方法问你输出什么。答案永远是子类重写后的版本。但如果子类没有重写那就走父类的实现。这个判断链条要练到条件反射。下午题里多态考得更隐蔽。题目描述里会说“系统需要支持多种支付方式且未来可能增加新的支付方式”这就是在暗示你用多态——定义一个支付接口各种支付方式实现它调用方只依赖接口不依赖具体实现。你看到“未来可能增加”“支持多种类型”“可扩展”这类词脑子里就要亮灯这里要留抽象类或接口。2.3 抽象类与接口的取舍考试里的判断信号抽象类和接口的区别是上午选择题的高频考点但很多人背了七八条区别还是不会做题。我总结了一个极简判断法看题目里有没有“默认实现”的需求。如果题目说“所有子类共享某段逻辑但又有各自不同的行为”那就用抽象类因为抽象类可以有方法体如果题目说“只定义规范不关心怎么实现”那就用接口。考试里还有一个隐藏信号看类之间的关系强度。如果两个类之间是“is-a”的关系比如“经理是一种员工”用继承抽象类如果是“can-do”的关系比如“可序列化”“可比较”用接口。这个判断法在下午题填类图时特别管用因为题目描述里往往不会明说用哪个你得从语义里抠。我备考时整理过一张对比表做题时直接对照判断维度选抽象类选接口是否有共享代码有公共方法体只有方法签名关系语义is-a是一种can-do能做什么子类约束单继承强约束多实现弱约束题目关键词“共享”“通用逻辑”“基类”“规范”“协议”“能力”这张表不是让你背的是让你在做题时快速定位的。看到“共享”找抽象类看到“能力”找接口基本不会错。3. UML图解法六种关系一张图理清楚3.1 依赖、关联、聚合、组合的箭头密码UML类图里的关系判断是上午题的送分题也是下午题的丢分重灾区。四种关系——依赖、关联、聚合、组合——画法不同、语义不同但题目描述往往很模糊。我当初在这上面栽过跟头后来总结了一套“从弱到强”的判断顺序做题时按顺序套准确率能到九成以上。先看强弱排序依赖 关联 聚合 组合。依赖是最弱的临时性的一个类的方法里用到了另一个类关联是长期的一个类持有另一个类的引用聚合是整体和部分的关系但部分可以独立存在组合也是整体和部分但部分不能独立存在生命周期绑定。画法上的区别必须记牢依赖是虚线箭头关联是实线箭头或者实线无箭头聚合是空心菱形加实线组合是实心菱形加实线。考试里经常把聚合和组合的菱形画反或者把依赖和关联的线型搞混。我用一个记忆口诀“虚依实关空聚实组”。虚线是依赖实线是关联空心菱形是聚合实心菱形是组合。这个口诀我写在便利贴上贴了两个月做题时扫一眼就能对上。题目描述里的关键词对应关系是这样的出现“使用”“调用”“依赖” → 依赖出现“拥有”“包含”“关联” → 关联出现“由……组成”“整体部分”且部分可独立 → 聚合出现“不可分割”“同生共死”“完全属于” → 组合注意聚合和组合的判断是下午题的高频失分点。我见过一道真题描述“一个部门包含多名员工”很多人画成组合但员工离职后部门还在员工也可以调到别的部门所以是聚合。判断标准就一条——部分对象能不能脱离整体单独存在。能就是聚合不能就是组合。3.2 泛化与实现的区分箭头方向别画反泛化就是继承画法是实线加空心三角箭头箭头指向父类。实现是类实现接口画法是虚线加空心三角箭头箭头指向接口。这两个的箭头都是空心三角区别在线型实线是泛化虚线是实现。考试里最爱考的是箭头方向。很多人画反把箭头指向子类。记住一个原则箭头永远指向更抽象的一方。子类比父类具体所以箭头从子类指向父类实现类比接口具体所以箭头从实现类指向接口。这个原则想通了方向就不会错。下午题里泛化和实现经常混在一起考。比如题目描述“系统中有多种报表所有报表都需要实现导出功能但每种报表的导出格式不同”这里“多种报表”之间如果有共性可能有一个抽象基类泛化而“导出功能”如果定义成接口就是实现关系。你得从描述里拆出两层抽象类层次的继承用泛化行为规范的实现用接口。3.3 类图元素速查从类名到多重度类图题里除了关系还有几个细节容易丢分。第一个是类的 stereotypes也就是interface、abstract这些标记。题目如果说“定义了一个接口”类名上面必须加interface不写要扣分。第二个是多重度也就是关联两端的数字比如1、0..*、1..*。题目描述里出现“一个订单包含多个商品”订单端标1商品端标0..*或者1..*具体看描述里有没有“至少一个”的意思。第三个是属性名的命名规范。考试不强制要求驼峰命名但属性名要能反映含义不能写a、b、c。我一般用题目里出现的名词直接当属性名比如“书名”“价格”“库存数量”这样既不会错也不会漏。我整理了一张类图元素检查清单做完题后逐项打勾[ ] 类名是否与题目描述一致[ ] 抽象类和接口是否加了构造型标记[ ] 属性和方法的可见性符号是否正确[ ] 关系类型依赖/关联/聚合/组合/泛化/实现是否判断准确[ ] 箭头方向是否指向抽象方[ ] 多重度是否标注且与描述吻合[ ] 方法名是否体现了职责这张清单看着琐碎但下午题一道类图填空动辄十几分丢一个细节可能就是两三分的事。4. 设计模式识别二十三种模式的考试筛法4.1 按目的分类创建型、结构型、行为型设计模式二十三种全背下来不现实但考试有考试的筛法。上午题考设计模式基本只考模式的特征识别——给你一段场景描述问你该用哪个模式或者给你一个类图问你这是哪个模式。下午题考得更深一点可能让你填某个模式的缺失代码。我的策略是按目的分三组每组记三到四个高频模式。创建型里高频的是单例、工厂方法、抽象工厂、建造者结构型里高频的是适配器、装饰器、代理、组合行为型里高频的是观察者、策略、模板方法、命令、状态。这十几个模式覆盖了历年真题的绝大多数考点剩下的低频模式考前扫一眼特征就行。创建型模式的共同特征是把对象的创建过程封装起来。题目里出现“希望只创建一个实例”就是单例“根据参数决定创建哪种对象”就是工厂“创建过程复杂、分步骤”就是建造者。结构型模式的共同特征是处理类和对象的组合。出现“接口不兼容、需要转换”是适配器“动态添加功能”是装饰器“控制访问”是代理。行为型模式的共同特征是处理对象间的通信和职责分配。出现“一对多依赖、状态变化通知”是观察者“多种算法可互换”是策略“固定流程、部分步骤可变”是模板方法。4.2 高频模式的特征速记与易混辨析单例模式的识别信号最明显私有构造方法 静态私有实例 静态公有获取方法。类图里看到构造方法是-有一个静态的自身类型属性基本就是单例。考试里常考的是懒汉式和饿汉式的区别懒汉式在获取方法里判断实例是否为空再创建饿汉式在类加载时就创建。题目如果说“第一次使用时才创建”选懒汉式。工厂方法和抽象工厂容易混。工厂方法是一个工厂生产一种产品抽象工厂是一个工厂生产一族产品。判断信号题目说“一个工厂类负责创建一种产品”是工厂方法说“一个工厂类负责创建多个相关产品”是抽象工厂。我记的口诀是“单产品找工厂方法产品族找抽象工厂”。适配器和装饰器也容易混。适配器是改变接口让原本不兼容的两个东西能合作装饰器是增强功能在不改变接口的前提下加新行为。题目里出现“已有类接口不符合需求”是适配器出现“动态地给对象添加职责”是装饰器。观察者和策略的区分看通信方向。观察者是主题状态变化后主动通知多个观察者是一对多的推送策略是客户端选择一种算法交给上下文执行是主动的选择。题目说“状态改变时自动通知”是观察者说“运行时切换算法”是策略。我整理了一张高频模式速查表考前反复看模式识别关键词类图特征单例唯一实例、全局访问私有构造、静态自身属性工厂方法一种产品、子类决定创建工厂接口产品接口抽象工厂产品族、一系列相关产品工厂接口含多个创建方法适配器接口转换、兼容适配器实现目标接口、持有源对象装饰器动态添加功能装饰器实现组件接口、持有组件引用代理控制访问、间接调用代理实现主题接口、持有真实主题观察者通知、一对多、状态变化主题持有观察者列表策略算法互换、运行时选择上下文持有策略接口4.3 下午题里的模式填空套路下午题考设计模式通常是给你一段代码框架让你填缺失的类名或者方法名。这种题的套路是先判断模式再套模板。判断模式靠题目描述里的关键词套模板靠你对这个模式标准结构的熟悉程度。比如题目描述“系统需要支持多种日志记录方式且可以在运行时切换”这是策略模式。标准结构是一个策略接口定义日志方法多个具体策略实现它一个上下文类持有策略接口的引用并提供切换方法。填空时你只需要把题目里的具体类名往这个结构里套。再比如“系统需要在数据变化时自动更新多个界面组件”这是观察者模式。标准结构是一个主题接口定义注册、注销、通知方法一个具体主题维护观察者列表一个观察者接口定义更新方法多个具体观察者实现它。填空时注意主题里的观察者列表类型是观察者接口的集合不是具体观察者。实操心得下午题的模式填空先把题目里出现的所有类名列出来然后对照标准模式结构看哪个类对应接口、哪个对应具体实现、哪个对应上下文。对应关系理清了填空就是体力活。我做过一道真题题目给了五个类名标准观察者结构需要四个角色多出来的那个是干扰项你得能识别出来它不属于模式结构。5. 下午题实操从需求文字到类图的完整推演5.1 需求描述的信息提取方法下午题第一道大题通常是数据流图第二道是数据库设计第三道就是UML类图或者设计模式。类图题的题干一般是一段业务描述两三百字里面藏着类、属性、方法和关系。我的提取方法是三遍阅读法。第一遍通读圈出所有名词。名词大概率是类或者属性。比如“系统管理图书信息图书包含书名、作者、ISBN”这里“图书”是类“书名”“作者”“ISBN”是属性。第二遍通读圈出所有动词。动词大概率是方法或者关系。比如“管理员可以添加图书”这里“添加”是方法“管理员”和“图书”之间可能有关联。第三遍精读找数量词和限定词。“一个订单包含多个商品”里的“一个”和“多个”就是多重度“必须”“至少”这些词影响的是约束条件。三遍读完你手里应该有一张草稿左边列类名右边列属性和方法中间画关系连线。这时候再往答题卡上誊写基本不会漏。我踩过的一个坑是把属性当成了类。题目说“图书有出版社信息”很多人会把“出版社”单独拎出来当一个类但如果题目没有进一步描述出版社的属性它就应该作为图书的一个属性出版社名称处理。判断标准看题目有没有对这个名词做进一步展开描述。展开了就是类没展开就是属性。5.2 类图绘制的标准流程与检查点画类图的标准流程我总结为五步定类、定属性、定方法、定关系、定多重度。这五步顺序不能乱因为后一步依赖前一步的结果。定类的时候优先找题目里的核心业务实体。比如图书管理系统核心实体是图书、读者、借阅记录。辅助类比如“数据库连接类”如果题目没提就不要加。定属性的时候每个类至少要有两到三个属性属性名从题目描述里直接摘。定方法的时候注意题目里描述的动作归属哪个类——“管理员添加图书”这个动作方法应该放在管理员类还是图书类答案是看谁执行这个动作。管理员执行添加方法在管理员类但如果题目说“图书信息被更新”更新方法可能在图书类。定关系是重头戏。我一般先画泛化和实现如果有再画组合和聚合最后画关联和依赖。因为强关系优先确定弱关系后补。多重度标注时注意关联两端的数字要成对出现不能只标一端。画完之后对照检查清单过一遍类名有没有遗漏、属性可见性是不是都标了-、方法可见性有没有区分、关系类型对不对、箭头方向对不对、多重度标了没有。这套流程走下来一道15分的类图题拿12分以上是稳的。5.3 代码填空题的上下文推断技巧下午题里还有一种题型是给出一段Java或者C代码框架让你填缺失的部分。这种题考的是你对面向对象语法和设计模式结构的双重理解。推断技巧分三步。第一步看类名和接口名判断这是什么模式。类名里有“Factory”就是工厂相关有“Adapter”就是适配器有“Observer”就是观察者。第二步看继承和实现关系确定哪个类实现哪个接口、哪个类继承哪个父类。第三步看方法签名缺失的方法参数和返回值类型往往能从调用处反推出来。比如题目给了一个接口Payment里面有方法pay(double amount)然后有一个类WechatPay实现了它但方法体是空的让你填。你只需要在方法体里写一句打印或者返回true就行因为考试不要求真实逻辑只要求语法正确、结构完整。注意代码填空题里接口方法前面的public可以省略接口默认就是public但实现类里重写方法必须写public不写会编译错误。这个细节很多人忽略白白丢分。6. 常见问题与排查技巧实录6.1 关系判断总出错怎么办关系判断出错九成是因为没有按强弱顺序排除。我的排查流程是这样的先问“这两个类之间是不是整体和部分的关系”是的话再问“部分能不能独立存在”能就是聚合不能就是组合。不是整体部分关系的话再问“是不是临时使用关系”是就是依赖不是就是关联。最后问“是不是继承或实现”是的话看箭头和线型。这个流程走一遍四种关系基本不会混。我当初把聚合和组合搞混就是因为跳过了“部分能否独立存在”这一问看到“包含”就直接画组合。后来强迫自己每道题都走完整流程正确率才上来。6.2 设计模式选错怎么补救设计模式选错通常是因为只看了关键词没看结构。题目说“支持多种算法”你选了策略但题目还说“算法有固定流程、部分步骤可变”那其实是模板方法。补救方法是选完模式后用标准结构反推一遍看题目给的类能不能填进这个结构。填不进去说明模式选错了。比如你选了策略模式标准结构需要策略接口、具体策略、上下文三个角色。如果题目只给了两个类没有上下文那可能不是策略而是模板方法父类定义流程、子类实现步骤。结构反推是检验模式选择的最可靠方法。6.3 多重度标注的常见误区多重度标注的误区主要有三个。第一个是只标一端关联两端都要标哪怕一端是1也要写出来。第二个是把*和0..*混用考试里两者等价但建议统一写0..*更规范。第三个是忽略题目里的数量限定题目说“至少一个”就要标1..*说“可以没有”就标0..*不能一律标*。我整理了一张多重度速查表题目描述多重度标注一个A对应一个B两端都标1一个A对应多个BA端1B端0..或1..至少一个BB端1..*可以没有BB端0..*多个A对应多个B两端都标0..或6.4 考前一周的复习节奏建议考前一周面向对象这章的复习我建议分三天走。第一天过概念和UML符号把六种关系的画法和判断口诀默写一遍把类图元素检查清单过一遍。第二天刷真题上午题刷近五年面向对象部分下午题重点做类图和模式填空做完对答案错题标注原因。第三天复盘错题把错题对应的知识点回到教材或者笔记里重新看一遍确保同样的坑不踩第二次。我自己的经验是这章考前突击的性价比很高因为它的考点集中、题型固定三天时间足够把高频考点覆盖到位。但前提是你得动手画光看不动笔考场上画类图还是会手生。最后分享一个我做下午题的小习惯拿到类图题先在草稿纸上把题目里所有名词列出来用横线划掉明显是属性的剩下的就是候选类。然后每个候选类旁边写两三个可能的属性再根据动词确定方法归属。这套流程走熟了一道题从读题到画完不超过十五分钟。考试时间紧这个速度是练出来的不是看出来的。 
长河君 · 2026/10/25 13:04:51 · 阅读 1.2k 软件设计师面向对象技术：UML图解法与设计模式识别
1. 为什么面向对象这一章值得单独拎出来死磕软件设计师考试里第七章面向对象技术是个很特殊的存在。它不像数据结构那样需要你现场推演算法也不像操作系统那样概念密集到让人头皮发麻但它有个更阴险的特点——分值分布广、题型跨度大、上午选择题和下午大题两头都占。我翻过近七八套真题上午场里面向对象相关的题目稳定在6到8分下午场的数据流图、UML图、设计模式填空加起来能占到15分往上。换句话说这一章你要是拿不稳上午可能刚好卡在及格线边缘下午直接丢掉一道大题。很多人备考时的误区是把这章当成“背概念”来处理封装继承多态背得滚瓜烂熟一到UML类图题就懵。问题出在哪儿面向对象技术的考试重点从来不是让你复述定义而是考你能不能把现实问题翻译成对象模型。上午题考的是你对UML图元素、关系符号、设计模式特征的识别能力下午题考的是你从一段文字描述里提取类、属性、方法再画出类图或者填出缺失代码的能力。这两件事的底层能力是同一个对象建模的思维习惯。我当初备考的时候这一章前后过了三遍。第一遍通读教材感觉什么都懂第二遍做真题发现UML关联关系里的聚合和组合永远分不清第三遍才摸到门道——原来这章的核心不是记忆是建立一套从需求文字到类图元素的映射规则。这套规则一旦建立起来上午题扫一眼就能排除错误选项下午题看到“包含”“由……组成”“管理”这类动词就能条件反射地判断关系类型。这篇内容适合两类人看一类是刚翻开教材、对面向对象只有模糊印象的零基础备考者另一类是已经刷过题但正确率卡在60%上下、需要把知识体系重新捋一遍的老考生。我会把这一章拆成概念底座、UML图解法、设计模式识别、下午题实操套路四个板块每个板块都配上我实际做题时总结的判断口诀和踩坑记录。你不需要有编程经验但需要准备好纸笔因为下面很多内容是要你跟着画的。2. 概念底座把封装继承多态从口号变成判断依据2.1 封装到底在考什么信息隐藏的边界感教材上对封装的经典定义是“把数据和操作数据的方法捆绑在一起并隐藏对象的内部实现细节”。这句话你背十遍不如做一道题来得实在。考试里考封装从来不会直接问你“什么是封装”而是给你一个类图问你这个类的属性前面加了下划线或者减号代表什么或者问你某个方法应该设为public还是private。我自己的理解方式是这样的封装考的是你对“可见性边界”的敏感度。UML类图里属性和方法前面那些符号——是public-是private#是protected~是包内可见——这些符号的用法是有套路的。属性绝大多数情况应该是-因为数据要藏起来方法则要看它是不是对外提供的服务接口是的话用只给自己内部调用的辅助方法用-。这里有个我踩过的坑下午题里经常出现“某类负责计算总价”这种描述很多人会把计算方法设成public但实际上如果这个计算只是被另一个类内部调用它应该是private的。判断依据很简单——看这个方法有没有被其他类的对象直接调用。如果没有就藏起来。考试出题人特别喜欢在“辅助方法”上设陷阱你稍微不注意就把可见性标错了。实操心得做类图题时先把所有属性一律标成-再逐个检查方法。只有那些在题目描述里明确出现“供外部使用”“对外提供”“可以被调用”字眼的方法才标其余全部-。这个粗暴规则能帮你避开八成以上的可见性错误。2.2 继承与多态的联合考法父子类替换的逻辑继承单独考的时候很简单就是箭头指向父类、子类继承父类的属性和方法。但考试真正爱考的是继承和多态绑在一起的场景。典型题目会给你一个父类“图形”和子类“圆形”“矩形”父类有个方法“计算面积”然后问你运行时调用哪个方法。这里的关键知识点是动态绑定。很多零基础的人不理解为什么要有这个东西我用一个生活化的类比来解释你去餐厅点菜菜单上写的是“招牌菜”但每家分店做出来的招牌菜不一样。菜单就是父类接口分店就是子类实现你点菜这个动作在运行时才决定到底吃的是什么。考试里考多态就是考你能不能判断出“声明类型”和“实际对象类型”不一致时方法调用跟着谁走。上午题里常见的坑是给你一段伪代码父类引用指向子类对象然后调用一个父类有、子类也重写了的方法问你输出什么。答案永远是子类重写后的版本。但如果子类没有重写那就走父类的实现。这个判断链条要练到条件反射。下午题里多态考得更隐蔽。题目描述里会说“系统需要支持多种支付方式且未来可能增加新的支付方式”这就是在暗示你用多态——定义一个支付接口各种支付方式实现它调用方只依赖接口不依赖具体实现。你看到“未来可能增加”“支持多种类型”“可扩展”这类词脑子里就要亮灯这里要留抽象类或接口。2.3 抽象类与接口的取舍考试里的判断信号抽象类和接口的区别是上午选择题的高频考点但很多人背了七八条区别还是不会做题。我总结了一个极简判断法看题目里有没有“默认实现”的需求。如果题目说“所有子类共享某段逻辑但又有各自不同的行为”那就用抽象类因为抽象类可以有方法体如果题目说“只定义规范不关心怎么实现”那就用接口。考试里还有一个隐藏信号看类之间的关系强度。如果两个类之间是“is-a”的关系比如“经理是一种员工”用继承抽象类如果是“can-do”的关系比如“可序列化”“可比较”用接口。这个判断法在下午题填类图时特别管用因为题目描述里往往不会明说用哪个你得从语义里抠。我备考时整理过一张对比表做题时直接对照判断维度选抽象类选接口是否有共享代码有公共方法体只有方法签名关系语义is-a是一种can-do能做什么子类约束单继承强约束多实现弱约束题目关键词“共享”“通用逻辑”“基类”“规范”“协议”“能力”这张表不是让你背的是让你在做题时快速定位的。看到“共享”找抽象类看到“能力”找接口基本不会错。3. UML图解法六种关系一张图理清楚3.1 依赖、关联、聚合、组合的箭头密码UML类图里的关系判断是上午题的送分题也是下午题的丢分重灾区。四种关系——依赖、关联、聚合、组合——画法不同、语义不同但题目描述往往很模糊。我当初在这上面栽过跟头后来总结了一套“从弱到强”的判断顺序做题时按顺序套准确率能到九成以上。先看强弱排序依赖 关联 聚合 组合。依赖是最弱的临时性的一个类的方法里用到了另一个类关联是长期的一个类持有另一个类的引用聚合是整体和部分的关系但部分可以独立存在组合也是整体和部分但部分不能独立存在生命周期绑定。画法上的区别必须记牢依赖是虚线箭头关联是实线箭头或者实线无箭头聚合是空心菱形加实线组合是实心菱形加实线。考试里经常把聚合和组合的菱形画反或者把依赖和关联的线型搞混。我用一个记忆口诀“虚依实关空聚实组”。虚线是依赖实线是关联空心菱形是聚合实心菱形是组合。这个口诀我写在便利贴上贴了两个月做题时扫一眼就能对上。题目描述里的关键词对应关系是这样的出现“使用”“调用”“依赖” → 依赖出现“拥有”“包含”“关联” → 关联出现“由……组成”“整体部分”且部分可独立 → 聚合出现“不可分割”“同生共死”“完全属于” → 组合注意聚合和组合的判断是下午题的高频失分点。我见过一道真题描述“一个部门包含多名员工”很多人画成组合但员工离职后部门还在员工也可以调到别的部门所以是聚合。判断标准就一条——部分对象能不能脱离整体单独存在。能就是聚合不能就是组合。3.2 泛化与实现的区分箭头方向别画反泛化就是继承画法是实线加空心三角箭头箭头指向父类。实现是类实现接口画法是虚线加空心三角箭头箭头指向接口。这两个的箭头都是空心三角区别在线型实线是泛化虚线是实现。考试里最爱考的是箭头方向。很多人画反把箭头指向子类。记住一个原则箭头永远指向更抽象的一方。子类比父类具体所以箭头从子类指向父类实现类比接口具体所以箭头从实现类指向接口。这个原则想通了方向就不会错。下午题里泛化和实现经常混在一起考。比如题目描述“系统中有多种报表所有报表都需要实现导出功能但每种报表的导出格式不同”这里“多种报表”之间如果有共性可能有一个抽象基类泛化而“导出功能”如果定义成接口就是实现关系。你得从描述里拆出两层抽象类层次的继承用泛化行为规范的实现用接口。3.3 类图元素速查从类名到多重度类图题里除了关系还有几个细节容易丢分。第一个是类的 stereotypes也就是interface、abstract这些标记。题目如果说“定义了一个接口”类名上面必须加interface不写要扣分。第二个是多重度也就是关联两端的数字比如1、0..*、1..*。题目描述里出现“一个订单包含多个商品”订单端标1商品端标0..*或者1..*具体看描述里有没有“至少一个”的意思。第三个是属性名的命名规范。考试不强制要求驼峰命名但属性名要能反映含义不能写a、b、c。我一般用题目里出现的名词直接当属性名比如“书名”“价格”“库存数量”这样既不会错也不会漏。我整理了一张类图元素检查清单做完题后逐项打勾[ ] 类名是否与题目描述一致[ ] 抽象类和接口是否加了构造型标记[ ] 属性和方法的可见性符号是否正确[ ] 关系类型依赖/关联/聚合/组合/泛化/实现是否判断准确[ ] 箭头方向是否指向抽象方[ ] 多重度是否标注且与描述吻合[ ] 方法名是否体现了职责这张清单看着琐碎但下午题一道类图填空动辄十几分丢一个细节可能就是两三分的事。4. 设计模式识别二十三种模式的考试筛法4.1 按目的分类创建型、结构型、行为型设计模式二十三种全背下来不现实但考试有考试的筛法。上午题考设计模式基本只考模式的特征识别——给你一段场景描述问你该用哪个模式或者给你一个类图问你这是哪个模式。下午题考得更深一点可能让你填某个模式的缺失代码。我的策略是按目的分三组每组记三到四个高频模式。创建型里高频的是单例、工厂方法、抽象工厂、建造者结构型里高频的是适配器、装饰器、代理、组合行为型里高频的是观察者、策略、模板方法、命令、状态。这十几个模式覆盖了历年真题的绝大多数考点剩下的低频模式考前扫一眼特征就行。创建型模式的共同特征是把对象的创建过程封装起来。题目里出现“希望只创建一个实例”就是单例“根据参数决定创建哪种对象”就是工厂“创建过程复杂、分步骤”就是建造者。结构型模式的共同特征是处理类和对象的组合。出现“接口不兼容、需要转换”是适配器“动态添加功能”是装饰器“控制访问”是代理。行为型模式的共同特征是处理对象间的通信和职责分配。出现“一对多依赖、状态变化通知”是观察者“多种算法可互换”是策略“固定流程、部分步骤可变”是模板方法。4.2 高频模式的特征速记与易混辨析单例模式的识别信号最明显私有构造方法 静态私有实例 静态公有获取方法。类图里看到构造方法是-有一个静态的自身类型属性基本就是单例。考试里常考的是懒汉式和饿汉式的区别懒汉式在获取方法里判断实例是否为空再创建饿汉式在类加载时就创建。题目如果说“第一次使用时才创建”选懒汉式。工厂方法和抽象工厂容易混。工厂方法是一个工厂生产一种产品抽象工厂是一个工厂生产一族产品。判断信号题目说“一个工厂类负责创建一种产品”是工厂方法说“一个工厂类负责创建多个相关产品”是抽象工厂。我记的口诀是“单产品找工厂方法产品族找抽象工厂”。适配器和装饰器也容易混。适配器是改变接口让原本不兼容的两个东西能合作装饰器是增强功能在不改变接口的前提下加新行为。题目里出现“已有类接口不符合需求”是适配器出现“动态地给对象添加职责”是装饰器。观察者和策略的区分看通信方向。观察者是主题状态变化后主动通知多个观察者是一对多的推送策略是客户端选择一种算法交给上下文执行是主动的选择。题目说“状态改变时自动通知”是观察者说“运行时切换算法”是策略。我整理了一张高频模式速查表考前反复看模式识别关键词类图特征单例唯一实例、全局访问私有构造、静态自身属性工厂方法一种产品、子类决定创建工厂接口产品接口抽象工厂产品族、一系列相关产品工厂接口含多个创建方法适配器接口转换、兼容适配器实现目标接口、持有源对象装饰器动态添加功能装饰器实现组件接口、持有组件引用代理控制访问、间接调用代理实现主题接口、持有真实主题观察者通知、一对多、状态变化主题持有观察者列表策略算法互换、运行时选择上下文持有策略接口4.3 下午题里的模式填空套路下午题考设计模式通常是给你一段代码框架让你填缺失的类名或者方法名。这种题的套路是先判断模式再套模板。判断模式靠题目描述里的关键词套模板靠你对这个模式标准结构的熟悉程度。比如题目描述“系统需要支持多种日志记录方式且可以在运行时切换”这是策略模式。标准结构是一个策略接口定义日志方法多个具体策略实现它一个上下文类持有策略接口的引用并提供切换方法。填空时你只需要把题目里的具体类名往这个结构里套。再比如“系统需要在数据变化时自动更新多个界面组件”这是观察者模式。标准结构是一个主题接口定义注册、注销、通知方法一个具体主题维护观察者列表一个观察者接口定义更新方法多个具体观察者实现它。填空时注意主题里的观察者列表类型是观察者接口的集合不是具体观察者。实操心得下午题的模式填空先把题目里出现的所有类名列出来然后对照标准模式结构看哪个类对应接口、哪个对应具体实现、哪个对应上下文。对应关系理清了填空就是体力活。我做过一道真题题目给了五个类名标准观察者结构需要四个角色多出来的那个是干扰项你得能识别出来它不属于模式结构。5. 下午题实操从需求文字到类图的完整推演5.1 需求描述的信息提取方法下午题第一道大题通常是数据流图第二道是数据库设计第三道就是UML类图或者设计模式。类图题的题干一般是一段业务描述两三百字里面藏着类、属性、方法和关系。我的提取方法是三遍阅读法。第一遍通读圈出所有名词。名词大概率是类或者属性。比如“系统管理图书信息图书包含书名、作者、ISBN”这里“图书”是类“书名”“作者”“ISBN”是属性。第二遍通读圈出所有动词。动词大概率是方法或者关系。比如“管理员可以添加图书”这里“添加”是方法“管理员”和“图书”之间可能有关联。第三遍精读找数量词和限定词。“一个订单包含多个商品”里的“一个”和“多个”就是多重度“必须”“至少”这些词影响的是约束条件。三遍读完你手里应该有一张草稿左边列类名右边列属性和方法中间画关系连线。这时候再往答题卡上誊写基本不会漏。我踩过的一个坑是把属性当成了类。题目说“图书有出版社信息”很多人会把“出版社”单独拎出来当一个类但如果题目没有进一步描述出版社的属性它就应该作为图书的一个属性出版社名称处理。判断标准看题目有没有对这个名词做进一步展开描述。展开了就是类没展开就是属性。5.2 类图绘制的标准流程与检查点画类图的标准流程我总结为五步定类、定属性、定方法、定关系、定多重度。这五步顺序不能乱因为后一步依赖前一步的结果。定类的时候优先找题目里的核心业务实体。比如图书管理系统核心实体是图书、读者、借阅记录。辅助类比如“数据库连接类”如果题目没提就不要加。定属性的时候每个类至少要有两到三个属性属性名从题目描述里直接摘。定方法的时候注意题目里描述的动作归属哪个类——“管理员添加图书”这个动作方法应该放在管理员类还是图书类答案是看谁执行这个动作。管理员执行添加方法在管理员类但如果题目说“图书信息被更新”更新方法可能在图书类。定关系是重头戏。我一般先画泛化和实现如果有再画组合和聚合最后画关联和依赖。因为强关系优先确定弱关系后补。多重度标注时注意关联两端的数字要成对出现不能只标一端。画完之后对照检查清单过一遍类名有没有遗漏、属性可见性是不是都标了-、方法可见性有没有区分、关系类型对不对、箭头方向对不对、多重度标了没有。这套流程走下来一道15分的类图题拿12分以上是稳的。5.3 代码填空题的上下文推断技巧下午题里还有一种题型是给出一段Java或者C代码框架让你填缺失的部分。这种题考的是你对面向对象语法和设计模式结构的双重理解。推断技巧分三步。第一步看类名和接口名判断这是什么模式。类名里有“Factory”就是工厂相关有“Adapter”就是适配器有“Observer”就是观察者。第二步看继承和实现关系确定哪个类实现哪个接口、哪个类继承哪个父类。第三步看方法签名缺失的方法参数和返回值类型往往能从调用处反推出来。比如题目给了一个接口Payment里面有方法pay(double amount)然后有一个类WechatPay实现了它但方法体是空的让你填。你只需要在方法体里写一句打印或者返回true就行因为考试不要求真实逻辑只要求语法正确、结构完整。注意代码填空题里接口方法前面的public可以省略接口默认就是public但实现类里重写方法必须写public不写会编译错误。这个细节很多人忽略白白丢分。6. 常见问题与排查技巧实录6.1 关系判断总出错怎么办关系判断出错九成是因为没有按强弱顺序排除。我的排查流程是这样的先问“这两个类之间是不是整体和部分的关系”是的话再问“部分能不能独立存在”能就是聚合不能就是组合。不是整体部分关系的话再问“是不是临时使用关系”是就是依赖不是就是关联。最后问“是不是继承或实现”是的话看箭头和线型。这个流程走一遍四种关系基本不会混。我当初把聚合和组合搞混就是因为跳过了“部分能否独立存在”这一问看到“包含”就直接画组合。后来强迫自己每道题都走完整流程正确率才上来。6.2 设计模式选错怎么补救设计模式选错通常是因为只看了关键词没看结构。题目说“支持多种算法”你选了策略但题目还说“算法有固定流程、部分步骤可变”那其实是模板方法。补救方法是选完模式后用标准结构反推一遍看题目给的类能不能填进这个结构。填不进去说明模式选错了。比如你选了策略模式标准结构需要策略接口、具体策略、上下文三个角色。如果题目只给了两个类没有上下文那可能不是策略而是模板方法父类定义流程、子类实现步骤。结构反推是检验模式选择的最可靠方法。6.3 多重度标注的常见误区多重度标注的误区主要有三个。第一个是只标一端关联两端都要标哪怕一端是1也要写出来。第二个是把*和0..*混用考试里两者等价但建议统一写0..*更规范。第三个是忽略题目里的数量限定题目说“至少一个”就要标1..*说“可以没有”就标0..*不能一律标*。我整理了一张多重度速查表题目描述多重度标注一个A对应一个B两端都标1一个A对应多个BA端1B端0..或1..至少一个BB端1..*可以没有BB端0..*多个A对应多个B两端都标0..或6.4 考前一周的复习节奏建议考前一周面向对象这章的复习我建议分三天走。第一天过概念和UML符号把六种关系的画法和判断口诀默写一遍把类图元素检查清单过一遍。第二天刷真题上午题刷近五年面向对象部分下午题重点做类图和模式填空做完对答案错题标注原因。第三天复盘错题把错题对应的知识点回到教材或者笔记里重新看一遍确保同样的坑不踩第二次。我自己的经验是这章考前突击的性价比很高因为它的考点集中、题型固定三天时间足够把高频考点覆盖到位。但前提是你得动手画光看不动笔考场上画类图还是会手生。最后分享一个我做下午题的小习惯拿到类图题先在草稿纸上把题目里所有名词列出来用横线划掉明显是属性的剩下的就是候选类。然后每个候选类旁边写两三个可能的属性再根据动词确定方法归属。这套流程走熟了一道题从读题到画完不超过十五分钟。考试时间紧这个速度是练出来的不是看出来的。