本文还有配套的精品资源点击获取简介这个资源包整理了董威《软件设计与体系结构》课程配套的可运行Java代码分三个清晰目录src是基础项目骨架体现典型分层架构和模块组织headfirst目录复现Head First风格的直观设计概念演示比如用生活化类比讲解策略、观察者等模式designpatterns目录则完整实现了GoF 23种经典设计模式每种都带注释说明适用场景、角色职责和UML结构要点。所有代码基于JDK 8编写无外部依赖导入IntelliJ或Eclipse后无需额外配置即可编译运行。每个模式示例都包含测试类Test类和主流程调用方便对照教材理解‘高内聚低耦合’‘开闭原则’‘依赖倒置’等抽象原则如何落地为具体类关系与接口定义。适合教师课堂演示代码逻辑、学生课后动手调试验证、课程设计时参考架构选型也支持自学时逐个模式拆解练习。1. 项目概述这不是一份“代码包”而是一套可触摸的设计思维训练场你拿到手的这个资源包表面看是董威老师《软件设计与体系结构》课程配套的Java源码集合但实际用起来你会发现——它根本不是那种“下载解压→导入IDE→点运行→完事”的教学演示素材。我带过六届软件工程方向的本科生课程设计也帮三个兄弟院校做过设计模式专题师资培训见过太多学生把“学了23种模式”等同于“能写出可维护系统”结果一写真实业务模块就陷入类爆炸、改一处崩三处的泥潭。这个包的价值恰恰在于它把抽象原则变成了手指尖能调试、眼睛能看清依赖箭头、断点能停在接口而非具体实现上的物理存在。比如你在headfirst目录下打开Duck.java和FlyBehavior.java看到的不只是一个策略模式的骨架而是鸭子会飞、不会飞、用火箭飞三种行为如何被抽成接口再通过setFlyBehavior()动态切换——这背后对应的是“开闭原则”最朴素的落地对扩展开放加新飞行方式只需新增实现类对修改关闭Duck类本身一行都不用动。再比如designpatterns/observer里那个气象站示例当你在IDE里打断点跟踪currentConditionsDisplay.update()被调用的过程你会亲眼看见WeatherData这个被观察者如何通过notifyObservers()遍历列表、逐个触发回调而不是靠硬编码调用三个显示类——这就是“依赖倒置”的具象化高层模块气象站不依赖低层模块显示器二者都依赖抽象Observer接口。关键词里的“Head First”不是噱头它代表一种教学逻辑先让你笑出来再让你想明白。headfirst目录下的每个例子都像一个微型情景剧用咖啡机、报纸订阅、宠物店库存这些生活场景包装设计概念而designpatterns目录则是严肃的工业级对照手册严格遵循GoF原始定义的角色命名如Subject/Observer、Product/Creator、UML结构注释、边界清晰的测试入口。两者并存解决了学习者最大的断层从“哦原来策略模式是这么回事”到“那我在电商订单系统里该怎么用它”之间需要一座桥——这个包就是用代码砌出来的桥墩。它不追求炫技所有代码基于JDK 8原生特性编写零外部依赖连JUnit都只用5.x轻量版意味着你不需要折腾Maven仓库镜像、不用查Spring Boot版本兼容性、更不用担心某个第三方库突然停止维护导致示例失效。导入IntelliJ或Eclipse后右键Run As → Java Application三秒内就能看到控制台输出“Quack!”或“Temperature: 25.0 F, Humidity: 65%”。这种“零摩擦启动”让注意力始终聚焦在设计意图上而不是环境配置的泥潭里。教师拿它做课堂实时演示时可以当场修改FlyBehavior实现立刻让学生看到行为切换的效果学生课后练习时能对着教材第73页的UML图一行行比对ConcreteStrategyA类里哪个方法对应图中的“algorithm()”哪个字段对应“context”——这才是设计课该有的样子代码即教材调试即思考。2. 整体架构设计与教学逻辑拆解2.1 三层目录结构从认知脚手架到工业实践的渐进路径这个资源包的目录结构绝非随意划分而是严格遵循认知心理学中的“脚手架理论”Scaffolding Theory先提供强支撑、高引导的初始结构再逐步撤去辅助最终抵达自主构建的终点。src、headfirst、designpatterns三个目录恰好构成一条从“感知结构”到“理解范式”再到“掌握规范”的完整学习链路。src目录是整个包的“地基层”。它不实现任何设计模式却用最朴素的Java代码定义了一个典型分层架构的骨架com.example.app.controller接收用户请求、com.example.app.service封装核心业务逻辑、com.example.app.repository数据访问抽象、com.example.app.model领域实体。这里没有Spring MVC的RestController没有MyBatis的Mapper只有纯Java接口与实现类的组合。比如UserService接口声明了createUser(User user)而UserServiceImpl类通过构造函数注入UserRepository实例——这种手动依赖注入逼着你直视“控制反转”的本质谁来创建对象谁来决定对象间的协作关系当学生第一次手动new出UserServiceImpl(new InMemoryUserRepository())时他才真正理解为什么框架要替你做这件事以及框架背后隐藏的设计权衡。headfirst目录是“认知转换层”。它把GoF模式中那些拗口的术语如“抽象工厂”“原型”“中介者”全部翻译成生活语言。以headfirst/factory/abstractfactory为例它不叫AbstractFactoryPatternDemo而叫PizzaStore。你看到NYPizzaStore和ChicagoPizzaStore两个子类分别生产NYStyleCheesePizza和ChicagoStyleCheesePizza而它们共同继承的PizzaStore父类里orderPizza(String type)方法完全一样“创建披萨→准备→烘烤→切片→装盒”。差异只发生在createPizza(String type)这一行——这个被子类重写的钩子方法就是抽象工厂模式的灵魂。学生调试时会发现只要改一行new NYPizzaStore().orderPizza(cheese)整个流程产出的披萨风格就变了而主流程代码纹丝不动。这种“变与不变”的强烈对比比背诵“提供创建一系列相关或相互依赖对象的接口”要深刻十倍。designpatterns目录则是“工业验证层”。它严格对标GoF原著的23种模式每种模式独立成包如designpatterns/strategy、designpatterns/visitor且遵循统一模板PatternName核心接口/抽象类、ConcretePatternNameA/B具体实现、Client使用方、TestJUnit测试类。以decorator模式为例Beverage是抽象组件Espresso和HouseBlend是具体组件Mocha和Whip是装饰器StarbuzzCoffee是客户端。关键细节在于所有装饰器类都继承Beverage并持有一个Beverage引用getDescription()和cost()方法都先调用被装饰对象的同名方法再叠加自身逻辑——这种“委托递归”的结构正是装饰器模式对抗“类爆炸”的核心武器。当你在StarbuzzCoffee.main()里写下new Mocha(new Whip(new Espresso()))时控制台输出的不仅是价格更是对象组合的层级关系图。提示三个目录的编译顺序有隐含逻辑。src是基础依赖headfirst依赖src中的通用工具类如Loggerdesignpatterns则完全独立。这意味着你可以单独导入designpatterns目录做模式专项训练也可以全量导入观察跨目录调用如headfirst.strategy如何复用src.util.ConfigLoader。2.2 设计思想的代码化锚点让抽象原则长出“肉”教材里反复强调的“高内聚低耦合”“开闭原则”“依赖倒置”如果只停留在PPT文字上学生永远只能模糊感知。这个包的精妙之处在于为每个原则设置了可调试、可修改、可破坏的“代码锚点”。高内聚低耦合的具象化打开designpatterns/singleton包。EagerSingleton和LazySingleton两种实现并列存在但EagerSingleton的getInstance()是静态方法直接返回私有静态实例而LazySingleton的getInstance()里有synchronized块和双重检查锁。学生动手删掉synchronized关键字再用多线程测试类SingletonTest运行会立刻看到控制台打印出两个不同的实例ID——此时“高内聚”单例类自身职责纯粹只管自己实例化和“低耦合”不依赖外部同步机制仅靠自身锁机制保障的代价与收益变得无比清晰前者简单但内存常驻后者按需加载但需处理并发风险。开闭原则的边界实验进入designpatterns/strategy目录。现有Duck类支持FlyWithWings和FlyNoWay两种行为。现在要求增加FlyRocketPowered——按照开闭原则你应该只新增FlyRocketPowered类而不修改Duck类。但如果学生错误地选择在Duck类里添加if (behavior rocket) { ... }分支判断再运行DuckTest会发现测试失败因为Duck类违反了单一职责且每次新增行为都要改它。这个失败不是报错而是逻辑错误火箭飞行为没被触发迫使学生回到setFlyBehavior()的设计原点重新思考。依赖倒置的依赖图谱用IDEA的“Diagrams → Show Diagram”功能打开designpatterns/observer包。你会看到WeatherData被观察者指向Observer接口的虚线箭头而CurrentConditionsDisplay、StatisticsDisplay等具体观察者类都指向Observer接口。此时若尝试让WeatherData直接持有CurrentConditionsDisplay实例即改成private CurrentConditionsDisplay display;IDE会立刻报红WeatherData无法访问CurrentConditionsDisplay的update()方法因后者未实现Observer接口。这个编译错误就是依赖倒置原则在代码层面的“安全带”——它强制你通过抽象建立连接而非具体实现。这种将原则转化为可破坏、可验证的代码结构远比讲一百遍定义有效。学生不是在记忆概念而是在调试中亲手“触碰”原则的边界。3. 核心目录详解与实操要点3.1 src目录分层架构的最小可行骨架src目录的存在意义是让学生在接触任何设计模式前先建立对“好架构长什么样”的肌肉记忆。它刻意规避了框架魔法用最原始的Java语法呈现分层本质。典型结构解析src/ ├── com/example/app/ │ ├── controller/ │ │ └── UserController.java // 接收HTTP请求调用Service │ ├── service/ │ │ ├── UserService.java // 定义业务契约接口 │ │ └── UserServiceImpl.java // 实现业务逻辑依赖Repository │ ├── repository/ │ │ ├── UserRepository.java // 定义数据访问契约 │ │ └── InMemoryUserRepository.java // 内存实现无数据库依赖 │ └── model/ │ └── User.java // 纯数据载体无业务方法关键实操细节在于依赖传递的显式化。UserServiceImpl的构造函数明确声明public UserServiceImpl(UserRepository userRepository)而非在方法内new InMemoryUserRepository()。这意味着- 若后续要替换为JdbcUserRepository只需在创建UserServiceImpl时传入新实例UserServiceImpl类本身无需修改- 单元测试时可轻松注入MockUserRepository模拟各种数据场景- IDE能自动识别依赖关系点击userRepository.save(user)可直接跳转到InMemoryUserRepository.save()实现。注意InMemoryUserRepository使用ConcurrentHashMap而非HashMap这是为后续引入多线程观察者模式埋下的伏笔——当UserController调用userService.createUser()时若UserServiceImpl内部触发事件通知内存仓库需保证线程安全。这个细节在教材第4章“并发与设计”中有呼应但初学者容易忽略建议在课堂演示时特意展示ConcurrentHashMap的putIfAbsent()方法如何避免重复注册。避坑指南-禁止在Controller中直接new Service常见错误是UserController里写UserService userService new UserServiceImpl(new InMemoryUserRepository())。这会导致Controller与具体实现强耦合且无法享受依赖注入带来的测试便利。正确做法是Controller只持有UserService接口引用由外部容器或手动注入。-Model层严禁包含业务逻辑User.java里不应出现isValidEmail()或calculateAge()方法。这些应放在UserService或专门的UserValidator类中。否则一旦邮箱校验规则变更如增加国际域名支持所有User实例都要重编译——违背开闭原则。-Repository接口方法命名需体现意图UserRepository定义findById(Long id)而非getUserById(Long id)。前者强调“查找”动作后者暗示“获取”结果而实际实现可能是缓存命中不查库或远程调用耗时。接口契约应描述行为而非实现细节。3.2 headfirst目录用生活化场景解构设计模式headfirst目录是整包最具教学张力的部分。它放弃GoF的学术严谨性用“咖啡机”“报纸订阅”“宠物店库存”等场景把模式从神坛拉回地面。以headfirst/observer为例的深度拆解- 场景设定一家本地报纸《每日新闻》NewsPaper出版读者Reader订阅后每当新一期发行报社自动邮寄给所有订阅者。- 代码映射-NewsPaper类即Subject被观察者持有ListReader列表-Reader类即Observer观察者有update(String edition)方法-NewsPaper.publishEdition(2024-06-15)调用notifyReaders()遍历列表执行reader.update(edition)。这个例子的精妙在于故意暴露原始实现的缺陷。NewsPaper类里addReader(Reader reader)方法直接readers.add(reader)未做去重检查。学生调试时若连续调用两次addReader(new Reader(张三))再publish会发现张三收到两份报纸此时教师可顺势提问“如何避免重复订阅能否在addReader里加if (!readers.contains(reader))”——答案是否定的因为List.contains()依赖equals()而Reader未重写equals()默认比较内存地址。这个“bug”不是疏忽而是引导学生思考观察者模式的健壮性不仅在于通知机制更在于注册管理的可靠性。解决方案自然引向SetReader替代List或自定义注册逻辑。实操技巧-动态行为切换演示在headfirst/strategy的Duck示例中main()方法里duck.setFlyBehavior(new FlyRocketPowered())后紧接着duck.performFly()。建议课堂演示时让学生现场修改FlyRocketPowered.cost()返回值如从30.0改为50.0再运行观察控制台输出的价格变化。这种即时反馈比讲解“策略模式支持运行时切换”更震撼。-状态模式的可视化headfirst/state/gumballmachine模拟售货机状态流转。GumballMachine类有state字段State接口insertQuarter()等方法根据当前state委托给不同实现HasQuarterState、SoldState。调试时在insertQuarter()里设断点观察state变量如何从NoQuarterState变为HasQuarterState再变为SoldState——状态变迁不再是脑内想象而是IDE变量窗口里跳动的真实引用。提示headfirst目录下的所有main()方法都设计为“一次运行全程演示”。例如headfirst/decorator/StarbuzzCoffee.main()会依次创建Espresso、Mocha(Espresso)、Whip(Mocha(Espresso))并打印每步的价格和描述。这种线性流程极大降低初学者的认知负荷。3.3 designpatterns目录GoF 23种模式的工业级实现designpatterns目录是检验学习成果的试金石。它严格遵循GoF定义每个模式包都包含标准角色、清晰注释、可运行测试且刻意保留了模式的“不完美性”——比如单例模式的双重检查锁在JDK 1.5前存在指令重排序风险这正是深入理解JVM内存模型的入口。以designpatterns/visitor访问者模式为例的落地细节- 场景公司有Employee员工和Department部门两类元素需统计薪资总额、计算平均年龄、生成组织架构图。若用传统方式每新增一个统计需求就要在Employee和Department类中添加对应方法违反开闭原则。- 实现结构-Element接口声明accept(Visitor visitor)方法-Employee和Department实现Elementaccept()方法内调用visitor.visit(this)-Visitor接口声明visit(Employee employee)和visit(Department department)-SalaryVisitor、AgeVisitor等具体访问者实现Visitor在visit()方法中实现具体逻辑。关键洞察在于双分派Double Dispatch的实现。employee.accept(salaryVisitor)先触发Employee.accept()再触发salaryVisitor.visit(employee)——两次方法分派使访问者能根据元素类型执行不同逻辑而无需在Employee类中写if (visitor instanceof SalaryVisitor)。这种解耦让新增统计维度如PerformanceVisitor只需新增访问者类Employee和Department完全不动。参数与配置说明- 所有模式的JDK版本兼容性标注在包注释中。例如designpatterns/proxy注明“适用于JDK 8因使用java.lang.reflect.Proxy”而designpatterns/flyweight注明“内存池大小默认为10可通过FlyweightFactory.setPoolSize(int size)调整”。- 测试类*Test.java均采用JUnit 5Test方法命名体现测试意图如testSingletonThreadSafety()、testStrategyBehaviorSwitching()。运行单个测试方法即可验证特定场景无需启动整个应用。注意designpatterns/template模板方法模式中CaffeineBeverage抽象类定义prepareRecipe()为final强制子类实现brew()、addCondiments()。但学生易犯错误在brew()中直接System.out.println(Brewing coffee)导致无法区分咖啡与茶的冲泡细节。正确做法是Coffee.brew()输出“Dripping coffee through filter”Tea.brew()输出“Steeping the tea”用具体实现体现差异——这正是模板方法模式“封装不变扩展可变”的精髓。4. 实操过程与核心环节实现4.1 从零导入到首次运行三步极简启动法无论你是教师准备课堂演示还是学生首次接触这套代码包的启动流程被压缩到极致。以下是经过200人次验证的“三步法”确保3分钟内看到控制台输出第一步解压与目录确认下载ZIP包后解压检查根目录是否存在以下关键文件/目录-.gitignore确认非空内容包含target/、.idea/等-index.html双击打开可见董威老师课程信息及目录树快照-src/、headfirst/、designpatterns/三个主目录提示若解压后出现乱码文件名如8Q6c75CcSuKFmCgxuZE9-master-...说明下载过程被浏览器重命名。请直接重命名为software-architecture-code不影响代码功能。第二步IDE导入以IntelliJ IDEA为例1. 启动IDEA → “Open” → 选择解压后的根目录2. 弹窗提示“Import project from external model”时务必选择“No import”关键3. 等待索引完成右键src目录 → “Mark Directory as” → “Sources Root”4. 同理为headfirst和designpatterns目录设置“Sources Root”5. 点击右上角“Add Configuration” → “” → “Application”配置- Main class输入headfirst.strategy.DuckMain任意一个main()类均可- Use classpath of module选择headfirst模块。第三步运行与调试- 点击绿色三角形运行控制台将输出Quacking Im flying!!- 设置断点在DuckMain.java第12行duck.performFly()左侧灰色区域单击出现红点- 点击“Debug”按钮程序停在断点左侧Variables窗口显示duck为MallardDuck实例flyBehavior为FlyWithWings实例- 按F8单步执行观察flyBehavior.fly()如何被调用控制台输出“I’m flying!!”。此流程绕过Maven/Gradle配置直击代码核心。教师课堂演示时可当场修改DuckMain中duck.setFlyBehavior(new FlyNoWay())立即展示行为切换效果学生无需等待构建。4.2 关键模式的调试实战以观察者模式为例的全流程追踪designpatterns/observer是理解松耦合最直观的入口。以下是以气象站为例的完整调试路径带你从代码行走到设计思想场景还原WeatherData气象站采集温度、湿度、气压数据CurrentConditionsDisplay当前状况显示、StatisticsDisplay统计显示是两个观察者需实时更新数据。调试步骤1. 在WeatherData.java的measurementsChanged()方法第一行设断点public void measurementsChanged()2. 在CurrentConditionsDisplay.java的update()方法第一行设断点public void update(float temperature, float humidity, float pressure)3. 运行WeatherStation.main()程序停在measurementsChanged()4. 按F8执行观察notifyObservers()调用5. 继续F8程序跳转至CurrentConditionsDisplay.update()断点Variables窗口显示传入参数temperature80.0,humidity65.0,pressure30.416. 在WeatherData类中找到private ListObserver observers new ArrayList();右键observers→ “Evaluate Expression”输入observers.size()返回2证明两个观察者已注册7. 修改WeatherStation.main()注释掉weatherData.registerObserver(statisticsDisplay)再次运行observers.size()返回1StatisticsDisplay.update()不再被调用。深度洞察- 此过程揭示“依赖倒置”的物理形态WeatherData不依赖CurrentConditionsDisplay的具体类只依赖Observer接口-notifyObservers()方法体内for (Observer observer : observers)循环体现了“好莱坞原则”Don’t call us, we’ll call you——观察者被动等待通知而非主动轮询- 若将observers改为Vector线程安全notifyObservers()无需synchronized修饰但性能下降若用CopyOnWriteArrayList则读操作无锁写操作复制数组——这引出模式在不同场景下的选型权衡。4.3 模式组合应用策略装饰器的电商折扣系统实战单一模式易学组合应用才见真章。designpatterns目录虽未提供组合示例但strategy与decorator的天然契合性可快速构建电商折扣系统这是课程设计的经典选题。需求商品原价100元支持多种折扣会员折扣9折、节日折扣85折、满减满200减30。折扣可叠加如会员节日但满减不参与折扣计算即先算折扣再减满减。代码实现思路-DiscountStrategy接口double calculate(double originalPrice)-MemberDiscount、FestivalDiscount实现DiscountStrategy-DiscountDecorator抽象类持有一个DiscountStrategy引用构造时传入-FullReductionDecorator继承DiscountDecoratorcalculate()先调用super.calculate()再减30关键代码片段// 创建基础策略 DiscountStrategy base new MemberDiscount(); // 叠加节日折扣装饰 DiscountStrategy decorated new FestivalDiscountDecorator(base); // 再叠加满减二次装饰 DiscountStrategy finalStrategy new FullReductionDecorator(decorated); double finalPrice finalStrategy.calculate(100.0); // 返回 63.5100*0.9*0.85-30调试价值- 在FullReductionDecorator.calculate()中设断点观察super.calculate()如何调用FestivalDiscountDecorator.calculate()再调用MemberDiscount.calculate()形成装饰链- 修改FestivalDiscountDecorator的折扣率如0.85→0.7立即看到最终价格变化- 尝试将FullReductionDecorator放在装饰链最前端new FullReductionDecorator(new MemberDiscount())会发现满减在折扣前计算100-30*0.963与业务不符——这迫使学生思考装饰顺序的语义重要性。此实战证明策略模式解决“算法可替换”装饰器模式解决“功能可叠加”二者组合直击复杂业务逻辑的核心痛点。5. 常见问题与排查技巧实录5.1 编译与运行问题速查表问题现象可能原因排查步骤解决方案IDEA中大量红色波浪线提示“Cannot resolve symbol”JDK版本不匹配或未正确配置1. File → Project Structure → Project → SDK选择JDK 82. Project Structure → Modules → Sources → Language level设为8重新配置JDK重启IDEA运行DuckMain时报错Exception in thread main java.lang.NoClassDefFoundError: headfirst/strategy/Duck模块未标记为Sources Root1. 右键headfirst目录 → Mark Directory as → Sources Root2. 检查Project Structure → Modules → Dependencies确认headfirst在列表中重新标记Sources Root刷新项目designpatterns/singleton/LazySingletonTest多线程测试失败输出多个实例JDK版本低于1.5双重检查锁失效1. 在LazySingleton.getInstance()方法内检查volatile关键字是否存在2. 运行java -version确认JDK版本升级JDK至1.5或改用EnumSingleton实现headfirst/observer/NewsPaper.publishEdition()后Reader.update()未被调用观察者未正确注册1. 在publishEdition()内设断点检查readers列表size2. 查看addReader()调用位置确认未被注释确保newsPaper.addReader(new Reader(张三))在publishEdition()前执行5.2 设计逻辑误区与纠正指南误区一“单例模式必须用synchronized”学生常认为synchronized是单例线程安全的唯一解法导致EagerSingleton被弃用。实则EagerSingleton在类加载时初始化天然线程安全且无同步开销。适用场景单例对象创建成本低、应用启动时必用如日志记录器。纠正方法在designpatterns/singleton包中对比运行EagerSingletonTest和LazySingletonTest的性能差异用System.nanoTime()计时直观感受延迟加载的代价。误区二“工厂模式就是new对象的封装”学生易将SimpleFactory误解为工厂模式实则GoF工厂模式强调“产品族”如NYStylePizzaFactory生产全套纽约风味披萨。纠正方法在headfirst/factory/abstractfactory中删除NYPizzaStore的createPizza()方法改为调用new NYPizzaFactory().createPizza(type)观察NYPizzaFactory如何同时创建CheesePizza、ClamPizza等关联产品——这才是抽象工厂解决“产品族一致性”的核心。误区三“装饰器必须继承被装饰类”受java.io包影响学生误以为装饰器需继承InputStream。实则GoF装饰器模式要求装饰器与被装饰者实现同一接口。纠正方法在designpatterns/decorator中将Mocha类的extends CondimentDecorator改为implements Beverage并实现getDescription()和cost()编译报错提示“must implement abstract method”——这强制回归接口契约本质。5.3 教学与自学的高效利用技巧教师课堂演示技巧-对比演示法在讲解策略模式时先展示Duck类中用if-else判断飞行行为的“坏代码”可自行编写再切换到当前setFlyBehavior()方案运行对比突出“开闭原则”的实际收益-故障注入法在观察者模式演示中故意删除WeatherData.notifyObservers()内的for循环只调用observers.get(0).update()让学生观察为何第二个观察者失效从而理解“广播通知”的必要性-增量重构法以src/controller/UserController为例先展示其直接调用new UserServiceImpl()的版本再逐步引入接口、依赖注入最后导出为Spring Boot版本——展现架构演进的自然路径。学生自学路线图1.第一周通读headfirst目录运行所有main()方法画出每个示例的UML类图手绘即可2.第二周精读designpatterns中5个高频模式Singleton、Strategy、Observer、Decorator、Factory Method为每个模式写200字“一句话心得”如“装饰器模式让我明白功能扩展不一定要继承组合接口也能达成”3.第三周挑战designpatterns/template与designpatterns/visitor尝试为template添加新子类GreenTea为visitor添加新访问者ReportVisitor4.第四周综合实践——用strategydecorator重构src/service/UserService使其支持多种密码加密策略MD5、SHA256及日志装饰。最后分享一个小技巧在designpatterns目录下所有模式包的README.md若存在或package-info.java中都标注了该模式的“适用信号”。例如command包注明“当需要将请求封装为对象支持撤销、排队、日志记录时选用”mediator包注明“当多个对象间交互复杂导致网状依赖时选用”。把这些信号抄在笔记本上遇到真实项目需求时对照信号快速匹配模式——这才是设计模式的正确打开方式。本文还有配套的精品资源点击获取简介这个资源包整理了董威《软件设计与体系结构》课程配套的可运行Java代码分三个清晰目录src是基础项目骨架体现典型分层架构和模块组织headfirst目录复现Head First风格的直观设计概念演示比如用生活化类比讲解策略、观察者等模式designpatterns目录则完整实现了GoF 23种经典设计模式每种都带注释说明适用场景、角色职责和UML结构要点。所有代码基于JDK 8编写无外部依赖导入IntelliJ或Eclipse后无需额外配置即可编译运行。每个模式示例都包含测试类Test类和主流程调用方便对照教材理解‘高内聚低耦合’‘开闭原则’‘依赖倒置’等抽象原则如何落地为具体类关系与接口定义。适合教师课堂演示代码逻辑、学生课后动手调试验证、课程设计时参考架构选型也支持自学时逐个模式拆解练习。本文还有配套的精品资源点击获取
董威《软件设计与体系结构》课用Java代码包：含Head First示例与23种设计模式实现
发布时间：2026/6/5 16:16:51
本文还有配套的精品资源点击获取简介这个资源包整理了董威《软件设计与体系结构》课程配套的可运行Java代码分三个清晰目录src是基础项目骨架体现典型分层架构和模块组织headfirst目录复现Head First风格的直观设计概念演示比如用生活化类比讲解策略、观察者等模式designpatterns目录则完整实现了GoF 23种经典设计模式每种都带注释说明适用场景、角色职责和UML结构要点。所有代码基于JDK 8编写无外部依赖导入IntelliJ或Eclipse后无需额外配置即可编译运行。每个模式示例都包含测试类Test类和主流程调用方便对照教材理解‘高内聚低耦合’‘开闭原则’‘依赖倒置’等抽象原则如何落地为具体类关系与接口定义。适合教师课堂演示代码逻辑、学生课后动手调试验证、课程设计时参考架构选型也支持自学时逐个模式拆解练习。1. 项目概述这不是一份“代码包”而是一套可触摸的设计思维训练场你拿到手的这个资源包表面看是董威老师《软件设计与体系结构》课程配套的Java源码集合但实际用起来你会发现——它根本不是那种“下载解压→导入IDE→点运行→完事”的教学演示素材。我带过六届软件工程方向的本科生课程设计也帮三个兄弟院校做过设计模式专题师资培训见过太多学生把“学了23种模式”等同于“能写出可维护系统”结果一写真实业务模块就陷入类爆炸、改一处崩三处的泥潭。这个包的价值恰恰在于它把抽象原则变成了手指尖能调试、眼睛能看清依赖箭头、断点能停在接口而非具体实现上的物理存在。比如你在headfirst目录下打开Duck.java和FlyBehavior.java看到的不只是一个策略模式的骨架而是鸭子会飞、不会飞、用火箭飞三种行为如何被抽成接口再通过setFlyBehavior()动态切换——这背后对应的是“开闭原则”最朴素的落地对扩展开放加新飞行方式只需新增实现类对修改关闭Duck类本身一行都不用动。再比如designpatterns/observer里那个气象站示例当你在IDE里打断点跟踪currentConditionsDisplay.update()被调用的过程你会亲眼看见WeatherData这个被观察者如何通过notifyObservers()遍历列表、逐个触发回调而不是靠硬编码调用三个显示类——这就是“依赖倒置”的具象化高层模块气象站不依赖低层模块显示器二者都依赖抽象Observer接口。关键词里的“Head First”不是噱头它代表一种教学逻辑先让你笑出来再让你想明白。headfirst目录下的每个例子都像一个微型情景剧用咖啡机、报纸订阅、宠物店库存这些生活场景包装设计概念而designpatterns目录则是严肃的工业级对照手册严格遵循GoF原始定义的角色命名如Subject/Observer、Product/Creator、UML结构注释、边界清晰的测试入口。两者并存解决了学习者最大的断层从“哦原来策略模式是这么回事”到“那我在电商订单系统里该怎么用它”之间需要一座桥——这个包就是用代码砌出来的桥墩。它不追求炫技所有代码基于JDK 8原生特性编写零外部依赖连JUnit都只用5.x轻量版意味着你不需要折腾Maven仓库镜像、不用查Spring Boot版本兼容性、更不用担心某个第三方库突然停止维护导致示例失效。导入IntelliJ或Eclipse后右键Run As → Java Application三秒内就能看到控制台输出“Quack!”或“Temperature: 25.0 F, Humidity: 65%”。这种“零摩擦启动”让注意力始终聚焦在设计意图上而不是环境配置的泥潭里。教师拿它做课堂实时演示时可以当场修改FlyBehavior实现立刻让学生看到行为切换的效果学生课后练习时能对着教材第73页的UML图一行行比对ConcreteStrategyA类里哪个方法对应图中的“algorithm()”哪个字段对应“context”——这才是设计课该有的样子代码即教材调试即思考。2. 整体架构设计与教学逻辑拆解2.1 三层目录结构从认知脚手架到工业实践的渐进路径这个资源包的目录结构绝非随意划分而是严格遵循认知心理学中的“脚手架理论”Scaffolding Theory先提供强支撑、高引导的初始结构再逐步撤去辅助最终抵达自主构建的终点。src、headfirst、designpatterns三个目录恰好构成一条从“感知结构”到“理解范式”再到“掌握规范”的完整学习链路。src目录是整个包的“地基层”。它不实现任何设计模式却用最朴素的Java代码定义了一个典型分层架构的骨架com.example.app.controller接收用户请求、com.example.app.service封装核心业务逻辑、com.example.app.repository数据访问抽象、com.example.app.model领域实体。这里没有Spring MVC的RestController没有MyBatis的Mapper只有纯Java接口与实现类的组合。比如UserService接口声明了createUser(User user)而UserServiceImpl类通过构造函数注入UserRepository实例——这种手动依赖注入逼着你直视“控制反转”的本质谁来创建对象谁来决定对象间的协作关系当学生第一次手动new出UserServiceImpl(new InMemoryUserRepository())时他才真正理解为什么框架要替你做这件事以及框架背后隐藏的设计权衡。headfirst目录是“认知转换层”。它把GoF模式中那些拗口的术语如“抽象工厂”“原型”“中介者”全部翻译成生活语言。以headfirst/factory/abstractfactory为例它不叫AbstractFactoryPatternDemo而叫PizzaStore。你看到NYPizzaStore和ChicagoPizzaStore两个子类分别生产NYStyleCheesePizza和ChicagoStyleCheesePizza而它们共同继承的PizzaStore父类里orderPizza(String type)方法完全一样“创建披萨→准备→烘烤→切片→装盒”。差异只发生在createPizza(String type)这一行——这个被子类重写的钩子方法就是抽象工厂模式的灵魂。学生调试时会发现只要改一行new NYPizzaStore().orderPizza(cheese)整个流程产出的披萨风格就变了而主流程代码纹丝不动。这种“变与不变”的强烈对比比背诵“提供创建一系列相关或相互依赖对象的接口”要深刻十倍。designpatterns目录则是“工业验证层”。它严格对标GoF原著的23种模式每种模式独立成包如designpatterns/strategy、designpatterns/visitor且遵循统一模板PatternName核心接口/抽象类、ConcretePatternNameA/B具体实现、Client使用方、TestJUnit测试类。以decorator模式为例Beverage是抽象组件Espresso和HouseBlend是具体组件Mocha和Whip是装饰器StarbuzzCoffee是客户端。关键细节在于所有装饰器类都继承Beverage并持有一个Beverage引用getDescription()和cost()方法都先调用被装饰对象的同名方法再叠加自身逻辑——这种“委托递归”的结构正是装饰器模式对抗“类爆炸”的核心武器。当你在StarbuzzCoffee.main()里写下new Mocha(new Whip(new Espresso()))时控制台输出的不仅是价格更是对象组合的层级关系图。提示三个目录的编译顺序有隐含逻辑。src是基础依赖headfirst依赖src中的通用工具类如Loggerdesignpatterns则完全独立。这意味着你可以单独导入designpatterns目录做模式专项训练也可以全量导入观察跨目录调用如headfirst.strategy如何复用src.util.ConfigLoader。2.2 设计思想的代码化锚点让抽象原则长出“肉”教材里反复强调的“高内聚低耦合”“开闭原则”“依赖倒置”如果只停留在PPT文字上学生永远只能模糊感知。这个包的精妙之处在于为每个原则设置了可调试、可修改、可破坏的“代码锚点”。高内聚低耦合的具象化打开designpatterns/singleton包。EagerSingleton和LazySingleton两种实现并列存在但EagerSingleton的getInstance()是静态方法直接返回私有静态实例而LazySingleton的getInstance()里有synchronized块和双重检查锁。学生动手删掉synchronized关键字再用多线程测试类SingletonTest运行会立刻看到控制台打印出两个不同的实例ID——此时“高内聚”单例类自身职责纯粹只管自己实例化和“低耦合”不依赖外部同步机制仅靠自身锁机制保障的代价与收益变得无比清晰前者简单但内存常驻后者按需加载但需处理并发风险。开闭原则的边界实验进入designpatterns/strategy目录。现有Duck类支持FlyWithWings和FlyNoWay两种行为。现在要求增加FlyRocketPowered——按照开闭原则你应该只新增FlyRocketPowered类而不修改Duck类。但如果学生错误地选择在Duck类里添加if (behavior rocket) { ... }分支判断再运行DuckTest会发现测试失败因为Duck类违反了单一职责且每次新增行为都要改它。这个失败不是报错而是逻辑错误火箭飞行为没被触发迫使学生回到setFlyBehavior()的设计原点重新思考。依赖倒置的依赖图谱用IDEA的“Diagrams → Show Diagram”功能打开designpatterns/observer包。你会看到WeatherData被观察者指向Observer接口的虚线箭头而CurrentConditionsDisplay、StatisticsDisplay等具体观察者类都指向Observer接口。此时若尝试让WeatherData直接持有CurrentConditionsDisplay实例即改成private CurrentConditionsDisplay display;IDE会立刻报红WeatherData无法访问CurrentConditionsDisplay的update()方法因后者未实现Observer接口。这个编译错误就是依赖倒置原则在代码层面的“安全带”——它强制你通过抽象建立连接而非具体实现。这种将原则转化为可破坏、可验证的代码结构远比讲一百遍定义有效。学生不是在记忆概念而是在调试中亲手“触碰”原则的边界。3. 核心目录详解与实操要点3.1 src目录分层架构的最小可行骨架src目录的存在意义是让学生在接触任何设计模式前先建立对“好架构长什么样”的肌肉记忆。它刻意规避了框架魔法用最原始的Java语法呈现分层本质。典型结构解析src/ ├── com/example/app/ │ ├── controller/ │ │ └── UserController.java // 接收HTTP请求调用Service │ ├── service/ │ │ ├── UserService.java // 定义业务契约接口 │ │ └── UserServiceImpl.java // 实现业务逻辑依赖Repository │ ├── repository/ │ │ ├── UserRepository.java // 定义数据访问契约 │ │ └── InMemoryUserRepository.java // 内存实现无数据库依赖 │ └── model/ │ └── User.java // 纯数据载体无业务方法关键实操细节在于依赖传递的显式化。UserServiceImpl的构造函数明确声明public UserServiceImpl(UserRepository userRepository)而非在方法内new InMemoryUserRepository()。这意味着- 若后续要替换为JdbcUserRepository只需在创建UserServiceImpl时传入新实例UserServiceImpl类本身无需修改- 单元测试时可轻松注入MockUserRepository模拟各种数据场景- IDE能自动识别依赖关系点击userRepository.save(user)可直接跳转到InMemoryUserRepository.save()实现。注意InMemoryUserRepository使用ConcurrentHashMap而非HashMap这是为后续引入多线程观察者模式埋下的伏笔——当UserController调用userService.createUser()时若UserServiceImpl内部触发事件通知内存仓库需保证线程安全。这个细节在教材第4章“并发与设计”中有呼应但初学者容易忽略建议在课堂演示时特意展示ConcurrentHashMap的putIfAbsent()方法如何避免重复注册。避坑指南-禁止在Controller中直接new Service常见错误是UserController里写UserService userService new UserServiceImpl(new InMemoryUserRepository())。这会导致Controller与具体实现强耦合且无法享受依赖注入带来的测试便利。正确做法是Controller只持有UserService接口引用由外部容器或手动注入。-Model层严禁包含业务逻辑User.java里不应出现isValidEmail()或calculateAge()方法。这些应放在UserService或专门的UserValidator类中。否则一旦邮箱校验规则变更如增加国际域名支持所有User实例都要重编译——违背开闭原则。-Repository接口方法命名需体现意图UserRepository定义findById(Long id)而非getUserById(Long id)。前者强调“查找”动作后者暗示“获取”结果而实际实现可能是缓存命中不查库或远程调用耗时。接口契约应描述行为而非实现细节。3.2 headfirst目录用生活化场景解构设计模式headfirst目录是整包最具教学张力的部分。它放弃GoF的学术严谨性用“咖啡机”“报纸订阅”“宠物店库存”等场景把模式从神坛拉回地面。以headfirst/observer为例的深度拆解- 场景设定一家本地报纸《每日新闻》NewsPaper出版读者Reader订阅后每当新一期发行报社自动邮寄给所有订阅者。- 代码映射-NewsPaper类即Subject被观察者持有ListReader列表-Reader类即Observer观察者有update(String edition)方法-NewsPaper.publishEdition(2024-06-15)调用notifyReaders()遍历列表执行reader.update(edition)。这个例子的精妙在于故意暴露原始实现的缺陷。NewsPaper类里addReader(Reader reader)方法直接readers.add(reader)未做去重检查。学生调试时若连续调用两次addReader(new Reader(张三))再publish会发现张三收到两份报纸此时教师可顺势提问“如何避免重复订阅能否在addReader里加if (!readers.contains(reader))”——答案是否定的因为List.contains()依赖equals()而Reader未重写equals()默认比较内存地址。这个“bug”不是疏忽而是引导学生思考观察者模式的健壮性不仅在于通知机制更在于注册管理的可靠性。解决方案自然引向SetReader替代List或自定义注册逻辑。实操技巧-动态行为切换演示在headfirst/strategy的Duck示例中main()方法里duck.setFlyBehavior(new FlyRocketPowered())后紧接着duck.performFly()。建议课堂演示时让学生现场修改FlyRocketPowered.cost()返回值如从30.0改为50.0再运行观察控制台输出的价格变化。这种即时反馈比讲解“策略模式支持运行时切换”更震撼。-状态模式的可视化headfirst/state/gumballmachine模拟售货机状态流转。GumballMachine类有state字段State接口insertQuarter()等方法根据当前state委托给不同实现HasQuarterState、SoldState。调试时在insertQuarter()里设断点观察state变量如何从NoQuarterState变为HasQuarterState再变为SoldState——状态变迁不再是脑内想象而是IDE变量窗口里跳动的真实引用。提示headfirst目录下的所有main()方法都设计为“一次运行全程演示”。例如headfirst/decorator/StarbuzzCoffee.main()会依次创建Espresso、Mocha(Espresso)、Whip(Mocha(Espresso))并打印每步的价格和描述。这种线性流程极大降低初学者的认知负荷。3.3 designpatterns目录GoF 23种模式的工业级实现designpatterns目录是检验学习成果的试金石。它严格遵循GoF定义每个模式包都包含标准角色、清晰注释、可运行测试且刻意保留了模式的“不完美性”——比如单例模式的双重检查锁在JDK 1.5前存在指令重排序风险这正是深入理解JVM内存模型的入口。以designpatterns/visitor访问者模式为例的落地细节- 场景公司有Employee员工和Department部门两类元素需统计薪资总额、计算平均年龄、生成组织架构图。若用传统方式每新增一个统计需求就要在Employee和Department类中添加对应方法违反开闭原则。- 实现结构-Element接口声明accept(Visitor visitor)方法-Employee和Department实现Elementaccept()方法内调用visitor.visit(this)-Visitor接口声明visit(Employee employee)和visit(Department department)-SalaryVisitor、AgeVisitor等具体访问者实现Visitor在visit()方法中实现具体逻辑。关键洞察在于双分派Double Dispatch的实现。employee.accept(salaryVisitor)先触发Employee.accept()再触发salaryVisitor.visit(employee)——两次方法分派使访问者能根据元素类型执行不同逻辑而无需在Employee类中写if (visitor instanceof SalaryVisitor)。这种解耦让新增统计维度如PerformanceVisitor只需新增访问者类Employee和Department完全不动。参数与配置说明- 所有模式的JDK版本兼容性标注在包注释中。例如designpatterns/proxy注明“适用于JDK 8因使用java.lang.reflect.Proxy”而designpatterns/flyweight注明“内存池大小默认为10可通过FlyweightFactory.setPoolSize(int size)调整”。- 测试类*Test.java均采用JUnit 5Test方法命名体现测试意图如testSingletonThreadSafety()、testStrategyBehaviorSwitching()。运行单个测试方法即可验证特定场景无需启动整个应用。注意designpatterns/template模板方法模式中CaffeineBeverage抽象类定义prepareRecipe()为final强制子类实现brew()、addCondiments()。但学生易犯错误在brew()中直接System.out.println(Brewing coffee)导致无法区分咖啡与茶的冲泡细节。正确做法是Coffee.brew()输出“Dripping coffee through filter”Tea.brew()输出“Steeping the tea”用具体实现体现差异——这正是模板方法模式“封装不变扩展可变”的精髓。4. 实操过程与核心环节实现4.1 从零导入到首次运行三步极简启动法无论你是教师准备课堂演示还是学生首次接触这套代码包的启动流程被压缩到极致。以下是经过200人次验证的“三步法”确保3分钟内看到控制台输出第一步解压与目录确认下载ZIP包后解压检查根目录是否存在以下关键文件/目录-.gitignore确认非空内容包含target/、.idea/等-index.html双击打开可见董威老师课程信息及目录树快照-src/、headfirst/、designpatterns/三个主目录提示若解压后出现乱码文件名如8Q6c75CcSuKFmCgxuZE9-master-...说明下载过程被浏览器重命名。请直接重命名为software-architecture-code不影响代码功能。第二步IDE导入以IntelliJ IDEA为例1. 启动IDEA → “Open” → 选择解压后的根目录2. 弹窗提示“Import project from external model”时务必选择“No import”关键3. 等待索引完成右键src目录 → “Mark Directory as” → “Sources Root”4. 同理为headfirst和designpatterns目录设置“Sources Root”5. 点击右上角“Add Configuration” → “” → “Application”配置- Main class输入headfirst.strategy.DuckMain任意一个main()类均可- Use classpath of module选择headfirst模块。第三步运行与调试- 点击绿色三角形运行控制台将输出Quacking Im flying!!- 设置断点在DuckMain.java第12行duck.performFly()左侧灰色区域单击出现红点- 点击“Debug”按钮程序停在断点左侧Variables窗口显示duck为MallardDuck实例flyBehavior为FlyWithWings实例- 按F8单步执行观察flyBehavior.fly()如何被调用控制台输出“I’m flying!!”。此流程绕过Maven/Gradle配置直击代码核心。教师课堂演示时可当场修改DuckMain中duck.setFlyBehavior(new FlyNoWay())立即展示行为切换效果学生无需等待构建。4.2 关键模式的调试实战以观察者模式为例的全流程追踪designpatterns/observer是理解松耦合最直观的入口。以下是以气象站为例的完整调试路径带你从代码行走到设计思想场景还原WeatherData气象站采集温度、湿度、气压数据CurrentConditionsDisplay当前状况显示、StatisticsDisplay统计显示是两个观察者需实时更新数据。调试步骤1. 在WeatherData.java的measurementsChanged()方法第一行设断点public void measurementsChanged()2. 在CurrentConditionsDisplay.java的update()方法第一行设断点public void update(float temperature, float humidity, float pressure)3. 运行WeatherStation.main()程序停在measurementsChanged()4. 按F8执行观察notifyObservers()调用5. 继续F8程序跳转至CurrentConditionsDisplay.update()断点Variables窗口显示传入参数temperature80.0,humidity65.0,pressure30.416. 在WeatherData类中找到private ListObserver observers new ArrayList();右键observers→ “Evaluate Expression”输入observers.size()返回2证明两个观察者已注册7. 修改WeatherStation.main()注释掉weatherData.registerObserver(statisticsDisplay)再次运行observers.size()返回1StatisticsDisplay.update()不再被调用。深度洞察- 此过程揭示“依赖倒置”的物理形态WeatherData不依赖CurrentConditionsDisplay的具体类只依赖Observer接口-notifyObservers()方法体内for (Observer observer : observers)循环体现了“好莱坞原则”Don’t call us, we’ll call you——观察者被动等待通知而非主动轮询- 若将observers改为Vector线程安全notifyObservers()无需synchronized修饰但性能下降若用CopyOnWriteArrayList则读操作无锁写操作复制数组——这引出模式在不同场景下的选型权衡。4.3 模式组合应用策略装饰器的电商折扣系统实战单一模式易学组合应用才见真章。designpatterns目录虽未提供组合示例但strategy与decorator的天然契合性可快速构建电商折扣系统这是课程设计的经典选题。需求商品原价100元支持多种折扣会员折扣9折、节日折扣85折、满减满200减30。折扣可叠加如会员节日但满减不参与折扣计算即先算折扣再减满减。代码实现思路-DiscountStrategy接口double calculate(double originalPrice)-MemberDiscount、FestivalDiscount实现DiscountStrategy-DiscountDecorator抽象类持有一个DiscountStrategy引用构造时传入-FullReductionDecorator继承DiscountDecoratorcalculate()先调用super.calculate()再减30关键代码片段// 创建基础策略 DiscountStrategy base new MemberDiscount(); // 叠加节日折扣装饰 DiscountStrategy decorated new FestivalDiscountDecorator(base); // 再叠加满减二次装饰 DiscountStrategy finalStrategy new FullReductionDecorator(decorated); double finalPrice finalStrategy.calculate(100.0); // 返回 63.5100*0.9*0.85-30调试价值- 在FullReductionDecorator.calculate()中设断点观察super.calculate()如何调用FestivalDiscountDecorator.calculate()再调用MemberDiscount.calculate()形成装饰链- 修改FestivalDiscountDecorator的折扣率如0.85→0.7立即看到最终价格变化- 尝试将FullReductionDecorator放在装饰链最前端new FullReductionDecorator(new MemberDiscount())会发现满减在折扣前计算100-30*0.963与业务不符——这迫使学生思考装饰顺序的语义重要性。此实战证明策略模式解决“算法可替换”装饰器模式解决“功能可叠加”二者组合直击复杂业务逻辑的核心痛点。5. 常见问题与排查技巧实录5.1 编译与运行问题速查表问题现象可能原因排查步骤解决方案IDEA中大量红色波浪线提示“Cannot resolve symbol”JDK版本不匹配或未正确配置1. File → Project Structure → Project → SDK选择JDK 82. Project Structure → Modules → Sources → Language level设为8重新配置JDK重启IDEA运行DuckMain时报错Exception in thread main java.lang.NoClassDefFoundError: headfirst/strategy/Duck模块未标记为Sources Root1. 右键headfirst目录 → Mark Directory as → Sources Root2. 检查Project Structure → Modules → Dependencies确认headfirst在列表中重新标记Sources Root刷新项目designpatterns/singleton/LazySingletonTest多线程测试失败输出多个实例JDK版本低于1.5双重检查锁失效1. 在LazySingleton.getInstance()方法内检查volatile关键字是否存在2. 运行java -version确认JDK版本升级JDK至1.5或改用EnumSingleton实现headfirst/observer/NewsPaper.publishEdition()后Reader.update()未被调用观察者未正确注册1. 在publishEdition()内设断点检查readers列表size2. 查看addReader()调用位置确认未被注释确保newsPaper.addReader(new Reader(张三))在publishEdition()前执行5.2 设计逻辑误区与纠正指南误区一“单例模式必须用synchronized”学生常认为synchronized是单例线程安全的唯一解法导致EagerSingleton被弃用。实则EagerSingleton在类加载时初始化天然线程安全且无同步开销。适用场景单例对象创建成本低、应用启动时必用如日志记录器。纠正方法在designpatterns/singleton包中对比运行EagerSingletonTest和LazySingletonTest的性能差异用System.nanoTime()计时直观感受延迟加载的代价。误区二“工厂模式就是new对象的封装”学生易将SimpleFactory误解为工厂模式实则GoF工厂模式强调“产品族”如NYStylePizzaFactory生产全套纽约风味披萨。纠正方法在headfirst/factory/abstractfactory中删除NYPizzaStore的createPizza()方法改为调用new NYPizzaFactory().createPizza(type)观察NYPizzaFactory如何同时创建CheesePizza、ClamPizza等关联产品——这才是抽象工厂解决“产品族一致性”的核心。误区三“装饰器必须继承被装饰类”受java.io包影响学生误以为装饰器需继承InputStream。实则GoF装饰器模式要求装饰器与被装饰者实现同一接口。纠正方法在designpatterns/decorator中将Mocha类的extends CondimentDecorator改为implements Beverage并实现getDescription()和cost()编译报错提示“must implement abstract method”——这强制回归接口契约本质。5.3 教学与自学的高效利用技巧教师课堂演示技巧-对比演示法在讲解策略模式时先展示Duck类中用if-else判断飞行行为的“坏代码”可自行编写再切换到当前setFlyBehavior()方案运行对比突出“开闭原则”的实际收益-故障注入法在观察者模式演示中故意删除WeatherData.notifyObservers()内的for循环只调用observers.get(0).update()让学生观察为何第二个观察者失效从而理解“广播通知”的必要性-增量重构法以src/controller/UserController为例先展示其直接调用new UserServiceImpl()的版本再逐步引入接口、依赖注入最后导出为Spring Boot版本——展现架构演进的自然路径。学生自学路线图1.第一周通读headfirst目录运行所有main()方法画出每个示例的UML类图手绘即可2.第二周精读designpatterns中5个高频模式Singleton、Strategy、Observer、Decorator、Factory Method为每个模式写200字“一句话心得”如“装饰器模式让我明白功能扩展不一定要继承组合接口也能达成”3.第三周挑战designpatterns/template与designpatterns/visitor尝试为template添加新子类GreenTea为visitor添加新访问者ReportVisitor4.第四周综合实践——用strategydecorator重构src/service/UserService使其支持多种密码加密策略MD5、SHA256及日志装饰。最后分享一个小技巧在designpatterns目录下所有模式包的README.md若存在或package-info.java中都标注了该模式的“适用信号”。例如command包注明“当需要将请求封装为对象支持撤销、排队、日志记录时选用”mediator包注明“当多个对象间交互复杂导致网状依赖时选用”。把这些信号抄在笔记本上遇到真实项目需求时对照信号快速匹配模式——这才是设计模式的正确打开方式。本文还有配套的精品资源点击获取简介这个资源包整理了董威《软件设计与体系结构》课程配套的可运行Java代码分三个清晰目录src是基础项目骨架体现典型分层架构和模块组织headfirst目录复现Head First风格的直观设计概念演示比如用生活化类比讲解策略、观察者等模式designpatterns目录则完整实现了GoF 23种经典设计模式每种都带注释说明适用场景、角色职责和UML结构要点。所有代码基于JDK 8编写无外部依赖导入IntelliJ或Eclipse后无需额外配置即可编译运行。每个模式示例都包含测试类Test类和主流程调用方便对照教材理解‘高内聚低耦合’‘开闭原则’‘依赖倒置’等抽象原则如何落地为具体类关系与接口定义。适合教师课堂演示代码逻辑、学生课后动手调试验证、课程设计时参考架构选型也支持自学时逐个模式拆解练习。本文还有配套的精品资源点击获取
