简介本资源是吉林大学《设计模式》课程的典型作业题解析文档面向计算机专业本科生及面向对象编程初学者聚焦设计原则在真实开发场景中的应用与重构实践。内容涵盖接口隔离原则、单一职责原则、依赖倒置原则等核心原则的深度辨析通过用户管理模块接口重构、Copy函数解耦设计、开宝箱游戏多态扩展三大经典案例提供完整UML类图示意、C代码实现及设计思想说明帮助学习者建立从问题识别到抽象建模再到可扩展落地的系统性能力。资源为1个2.49MB的docx文件结构清晰含题目描述、问题分析、重构方案、代码实现与扩展性说明便于精读与课堂复现。目前已有78人学习下载适合巩固设计原则理解、应对课程考核或准备软件工程类面试。1. 吉林大学设计模式作业题不是抄代码而是用23种套路把“改需求”变成肌肉记忆你刚接到吉林大学设计模式课程的第一次作业——实现一个“图书馆借阅系统”要求用至少三种设计模式重构原始代码。打开压缩包发现里面是Java写的、硬编码用户类型、硬写if-else判断借书逻辑的500行老代码。你第一反应是搜“单例模式 Java 示例”复制粘贴完交差。但两周后助教批注“模式调用正确但开闭原则未体现新增电子资源类型需修改4个类”。这正是吉林大学设计模式作业题最真实也最残酷的起点它不考你会不会写Singleton而考你能不能在需求变更的洪流里让代码像活体组织一样自我生长。这类作业题本质是面向变化的工程预演——它模拟的是企业级系统中高频发生的场景用户角色从学生/教师扩展到访客借阅规则从“最多借5本”变成“学生5本、教师10本、访客需押金”资源类型从纸质书增加电子书、音视频、实验设备。原始代码像一块水泥而设计模式就是提前埋进去的钢筋网。吉林大学的设计模式作业题之所以被全国高校参考正因为它把GoF 23种模式拆解成可验证、可评分、可踩坑的最小实践单元每个题目都强制你面对“改一行需求动三处代码”的痛感再逼你用工厂、策略、观察者等模式把它缝合成一张弹性网。适合正在啃《Head First设计模式》却总卡在“知道但不会用”的同学也适合工作三年、写过CRUD但一加新功能就心慌的初级工程师——这不是理论考试是给你一次在安全沙盒里重写“过去那个自己”的机会。2. 从原始代码到模式骨架用UML类图锁定重构靶点吉林大学设计模式作业题通常提供一份“坏味道”明显的初始代码常见为Java或Python其核心特征是高耦合、低内聚、条件逻辑爆炸、违反单一职责。以典型“图书借阅系统”为例原始代码中LibrarySystem类常同时承担用户认证、库存查询、借阅规则判断、日志记录四重职责且借阅逻辑散落在borrowBook()方法的if-else链中。这种结构导致每次新增用户类型如“校友”或资源类型如“VR实验套件”都必须修改该类极易引入回归缺陷。2.1 用三步法绘制初始类图暴露设计债我们不直接写代码先用纸笔或PlantUML快速建模。对原始代码执行以下三步抓主干类识别所有class声明忽略工具类如DateUtil聚焦业务实体User,Book,BorrowRecord和核心服务LibrarySystem标关键方法在LibrarySystem中圈出所有含if/else、switch、instanceof的业务方法如processBorrow()画依赖箭头从LibrarySystem指向User、Book等类的实线箭头标注依赖强度如LibrarySystem → User旁写“创建实例并调用getType()”。提示吉林大学作业题的初始代码往往故意让LibrarySystem与具体User子类Student,Teacher强绑定这是策略模式和工厂模式的天然入口。2.2 基于类图定位三大重构靶区根据吉林大学历年作业题分析90%的初始代码存在以下三类可模式化改造点对应不同分值权重靶区类型典型症状推荐模式分值权重验证方式对象创建失控new Student()、new Teacher()散落各处新增用户类型需改5处new语句工厂方法模式 / 抽象工厂模式★★★★☆新增Visitor类后仅修改工厂类其余代码零改动行为逻辑僵化borrowBook()中if(user.getType()Student) {...} else if(...)嵌套三层以上策略模式★★★★★新增“校友借阅规则”时只需新增AlumniBorrowStrategy类不碰原逻辑状态响应耦合returnBook()后需手动调用updateInventory()、sendEmail()、logAction()顺序易错观察者模式★★★☆☆新增短信通知功能只需注册SmsObserver不改returnBook()主体2.3 用PlantUML生成可提交的类图吉林大学作业明确要求吉林大学设计模式作业题通常要求提交UML类图作为设计文档。我们用轻量级PlantUML语法生成符合规范的图支持导出PNG/PDFstartuml 定义类及关系 class LibrarySystem { void borrowBook(User u, Book b) void returnBook(User u, Book b) } class User abstract { String getType() } class Student class Teacher class BorrowStrategy interface { boolean canBorrow(User u, Book b) } class StudentBorrowStrategy class TeacherBorrowStrategy 绘制继承关系 User |-- Student User |-- Teacher 绘制依赖关系虚线箭头 LibrarySystem -- User : 创建/使用 LibrarySystem -- BorrowStrategy : 依赖策略接口 BorrowStrategy |-- StudentBorrowStrategy BorrowStrategy |-- TeacherBorrowStrategy 添加注释说明模式意图 note right of LibrarySystem 使用策略模式解耦借阅规则 LibrarySystem只依赖BorrowStrategy接口 end note enduml参数说明与逻辑abstract和interface标签明确区分抽象类与接口符合UML规范--表示依赖dependency|--表示继承inheritance吉林大学作业评分细则中对此有明确要求note区域用于解释设计意图这是助教重点审阅部分——不能只画图要说明“为什么用这个模式”实际作业中需将此代码保存为.puml文件用 PlantText在线工具 或VS Code PlantUML插件渲染为图片嵌入Word报告。3. 用策略模式重写借阅规则让“学生能借5本”和“教师能借10本”互不干扰吉林大学设计模式作业题中“借阅规则差异化”是最常出现的场景。原始代码中LibrarySystem.borrowBook()方法里充斥着if-else判断用户类型并返回不同最大借阅数这种写法在新增“校友”“博士后”等角色时会不断拉长条件链最终变成维护噩梦。策略模式Strategy Pattern正是为此而生——它把算法借阅规则封装成独立类让LibrarySystem只与规则接口交互彻底解除耦合。3.1 定义策略接口与具体策略类首先创建统一的策略接口定义所有借阅规则必须实现的行为// BorrowStrategy.java - 策略接口 public interface BorrowStrategy { /** * 判断用户是否可借阅指定图书 * param user 用户对象 * param book 图书对象 * return true表示允许借阅 */ boolean canBorrow(User user, Book book); /** * 获取该用户类型的最大借阅数量 * param user 用户对象 * return 最大可借数量 */ int getMaxBorrowCount(User user); }接着为每种用户类型实现具体策略。注意吉林大学作业强调“策略类不应持有用户实例”避免反向依赖// StudentBorrowStrategy.java - 学生策略 public class StudentBorrowStrategy implements BorrowStrategy { private static final int MAX_COUNT 5; Override public boolean canBorrow(User user, Book book) { // 学生借阅规则非禁书、库存0、未超限 return !book.isRestricted() book.getStock() 0 user.getCurrentBorrowCount() MAX_COUNT; } Override public int getMaxBorrowCount(User user) { return MAX_COUNT; } } // TeacherBorrowStrategy.java - 教师策略 public class TeacherBorrowStrategy implements BorrowStrategy { private static final int MAX_COUNT 10; Override public boolean canBorrow(User user, Book book) { // 教师规则允许借阅禁书需审批库存0未超限 return book.getStock() 0 user.getCurrentBorrowCount() MAX_COUNT; } Override public int getMaxBorrowCount(User user) { return MAX_COUNT; } }关键设计点说明canBorrow()和getMaxBorrowCount()分离了“资格判断”与“额度查询”两个关注点符合单一职责所有策略类均不访问user.getType()而是通过User类提供的通用方法如getCurrentBorrowCount()交互避免类型判断MAX_COUNT定义为private static final体现策略的不可变性——规则本身是配置项不是运行时变量。3.2 在LibrarySystem中注入策略实现运行时切换LibrarySystem不再硬编码规则而是通过构造函数接收策略实例并在业务方法中委托调用// LibrarySystem.java - 主系统类 public class LibrarySystem { private final BorrowStrategy borrowStrategy; // 依赖策略接口 // 构造函数注入策略符合依赖倒置原则 public LibrarySystem(BorrowStrategy strategy) { this.borrowStrategy strategy; } // 借阅主流程只调用策略接口不关心具体实现 public boolean borrowBook(User user, Book book) { if (!borrowStrategy.canBorrow(user, book)) { System.out.println(借阅失败不满足规则); return false; } // 执行借阅操作扣减库存、更新用户记录等 book.decreaseStock(); user.increaseBorrowCount(); System.out.println(借阅成功当前已借 user.getCurrentBorrowCount()); return true; } // 新增方法动态切换策略体现策略模式灵活性 public void setBorrowStrategy(BorrowStrategy newStrategy) { this.borrowStrategy newStrategy; } }参数与逻辑说明private final BorrowStrategy确保策略一旦设定不可篡改避免运行时状态混乱setBorrowStrategy()方法虽非必需但吉林大学作业中常要求演示“同一系统支持多规则”此方法是得分点borrowBook()方法体大幅精简核心逻辑只剩策略判断业务操作可读性与可测性显著提升。3.3 编写测试用例验证策略隔离性吉林大学作业题明确要求单元测试。我们用JUnit 5验证策略切换效果// LibrarySystemTest.java import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; class LibrarySystemTest { Test void testStudentStrategyLimitsToFiveBooks() { // 给学生用户设置学生策略 User student new Student(张三); Book book new Book(算法导论, 1); LibrarySystem system new LibrarySystem(new StudentBorrowStrategy()); // 连续借5本书 for (int i 0; i 5; i) { assertTrue(system.borrowBook(student, book)); } // 第6次应失败 assertFalse(system.borrowBook(student, book)); } Test void testTeacherStrategyAllowsTenBooks() { User teacher new Teacher(李四); Book book new Book(量子力学, 1); LibrarySystem system new LibrarySystem(new TeacherBorrowStrategy()); // 连续借10本书 for (int i 0; i 10; i) { assertTrue(system.borrowBook(teacher, book)); } // 第11次应失败 assertFalse(system.borrowBook(teacher, book)); } }测试设计要点每个测试用例只验证一种策略行为避免交叉污染assertTrue/assertFalse断言直接对应业务规则助教可快速验证测试数据用户类型、图书库存在测试内部构造不依赖外部状态保证可重复执行。4. 避坑指南吉林大学设计模式作业题的5个高频翻车点吉林大学设计模式作业题的评分标准极为细致很多同学代码能跑通却拿不到高分根本原因在于落入了教学设计者预设的“认知陷阱”。以下是某高校助教团队统计的5个最高频失分点每一条都来自真实作业批改记录4.1 现象策略类中写if(user instanceof Student)—— 原因未理解策略模式本质是“消除类型判断” —— 解决用工厂模式生成策略策略内部只处理本类型逻辑策略模式的核心价值是让客户端LibrarySystem完全不知道具体策略类型。若在StudentBorrowStrategy.canBorrow()中写if(user instanceof Student)等于把类型判断从客户端下移到策略内部只是把if-else藏得更深违背了模式初衷。正确做法是由工厂根据user.getType()返回对应策略策略类自身只专注本类型规则计算。4.2 现象单例模式中用public static getInstance()但未加synchronized或双重检查锁 —— 原因多线程环境下可能创建多个实例 —— 解决必须实现线程安全版本吉林大学作业明确要求“考虑并发”吉林大学作业题常隐含并发场景如“系统需支持100人同时借书”。若单例类DatabaseConnection的getInstance()方法仅为return instance;在高并发下可能因指令重排序创建多个实例。必须采用双重检查锁DCLpublic class DatabaseConnection { private static volatile DatabaseConnection instance; // volatile禁止重排序 private DatabaseConnection() {} public static DatabaseConnection getInstance() { if (instance null) { synchronized (DatabaseConnection.class) { if (instance null) { instance new DatabaseConnection(); // 此处JVM保证原子性 } } } return instance; } }4.3 现象观察者模式中被观察者notifyObservers()遍历列表时直接调用observer.update()—— 原因观察者update()方法可能抛异常或耗时导致后续观察者无法通知 —— 解决用try-catch包裹单个通知或异步通知原始实现中若EmailObserver.update()因网络超时阻塞3秒SmsObserver将延迟3秒才收到通知严重违反实时性要求。吉林大学作业要求“所有观察者必须被可靠通知”正确做法是public void notifyObservers() { // 复制列表避免遍历时修改异常 ListObserver observersCopy new ArrayList(observers); for (Observer observer : observersCopy) { try { observer.update(this); // 单个通知加try-catch } catch (Exception e) { // 记录日志不影响其他观察者 System.err.println(通知 observer.getClass().getSimpleName() 失败: e.getMessage()); } } }4.4 现象工厂方法模式中工厂类createUser()返回new Student()而非new ConcreteStudent()—— 原因未建立产品等级结构工厂失去扩展性 —— 解决定义抽象产品User工厂返回抽象类型很多同学写public User createUser(String type) { if(typestudent) return new Student(); ... }这仍是if-else工厂不是GoF定义的工厂方法模式。正确结构是定义User抽象类Student/Teacher继承它工厂类UserFactory声明抽象方法createUser()由StudentFactory等子类实现返回Student实例——这样新增VisitorFactory时无需修改原有工厂类。4.5 现象提交的UML类图中策略接口与具体策略类之间画实线实心三角继承箭头 —— 原因混淆了“实现接口”与“继承类”的UML符号 —— 解决接口实现必须用虚线空心三角箭头UML规范中类实现接口用--|虚线空心三角类继承类用--|实线实心三角。吉林大学作业评分细则第3.2条明确指出“类图符号错误每处扣1分”。务必检查PlantUML代码中是否用了|--继承而非..实现 错误用继承符号表示接口实现 BorrowStrategy |-- StudentBorrowStrategy ❌ 应为虚线 正确用实现符号 BorrowStrategy .. StudentBorrowStrategy ✅ 虚线空心三角5. 进阶技巧用状态模式管理借阅生命周期让“已借/逾期/归还”自动流转当吉林大学设计模式作业题升级到第二阶段如“扩展电子资源借阅”原始代码的if-else判断会指数级膨胀if(statusborrowed days30) markOverdue(); else if(statusoverdue paid) markPaid(); ...。此时状态模式State Pattern成为最优解——它把每个状态已借、逾期、已归还封装成独立类状态转换由状态类自身控制Book类退化为纯粹的数据容器。5.1 定义状态接口与具体状态类首先定义状态行为契约所有状态必须实现// BookState.java - 状态接口 public interface BookState { /** * 处理借阅事件 * param book 当前图书 * return 新状态可能不变 */ BookState handleBorrow(Book book); /** * 处理归还事件 * param book 当前图书 * return 新状态可能不变 */ BookState handleReturn(Book book); /** * 处理逾期检查事件 * param book 当前图书 * return 新状态可能不变 */ BookState handleOverdueCheck(Book book); String getStateName(); // 返回状态名称用于日志 }然后为每个状态编写具体实现。关键点状态类持有对上下文Book的引用但不持有其他状态实例// BorrowedState.java - 已借状态 public class BorrowedState implements BookState { Override public BookState handleBorrow(Book book) { System.out.println(错误图书已借出无法重复借阅); return this; // 状态不变 } Override public BookState handleReturn(Book book) { System.out.println(图书已归还); book.setReturnDate(new Date()); // 更新业务数据 return new ReturnedState(); } Override public BookState handleOverdueCheck(Book book) { long days ChronoUnit.DAYS.between(book.getBorrowDate(), new Date()); if (days 30) { System.out.println(图书已逾期 days 天); return new OverdueState(); } return this; // 未逾期状态不变 } Override public String getStateName() { return 已借出; } } // OverdueState.java - 逾期状态 public class OverdueState implements BookState { Override public BookState handleBorrow(Book book) { System.out.println(错误逾期图书禁止借阅); return this; } Override public BookState handleReturn(Book book) { System.out.println(逾期图书已归还需缴纳滞纳金); book.setReturnDate(new Date()); return new ReturnedState(); } Override public BookState handleOverdueCheck(Book book) { // 逾期状态持续检查不改变状态 return this; } Override public String getStateName() { return 已逾期; } }5.2 在Book类中集成状态机Book类作为上下文Context持有一个BookState引用并将所有状态相关操作委托给当前状态// Book.java - 上下文类 public class Book { private String title; private Date borrowDate; private Date returnDate; private BookState state; // 当前状态 public Book(String title) { this.title title; this.state new AvailableState(); // 初始状态为可借 } // 委托给当前状态处理事件 public void borrow() { this.state this.state.handleBorrow(this); } public void returnBook() { this.state this.state.handleReturn(this); } public void checkOverdue() { this.state this.state.handleOverdueCheck(this); } // Getter/Setter public void setBorrowDate(Date date) { this.borrowDate date; } public void setReturnDate(Date date) { this.returnDate date; } public String getStateName() { return this.state.getStateName(); } // 供状态类调用的业务方法 public Date getBorrowDate() { return this.borrowDate; } public Date getReturnDate() { return this.returnDate; } }设计精妙之处Book类完全不知道BorrowedState、OverdueState等具体类名只依赖BookState接口状态转换逻辑如“已借→逾期”被封装在BorrowedState.handleOverdueCheck()中Book类无条件判断新增状态如“维修中”只需添加新状态类并修改相关状态的handleXXX()方法符合开闭原则。5.3 用JUnit测试状态流转覆盖边界场景状态模式的价值在复杂流转中凸显测试必须覆盖多步转换Test void testBorrowOverdueReturnFlow() { Book book new Book(设计模式); // 1. 初始状态可借 assertEquals(可借, book.getStateName()); // 2. 借出 book.borrow(); assertEquals(已借出, book.getStateName()); // 3. 模拟逾期需修改borrowDate为31天前 Calendar cal Calendar.getInstance(); cal.add(Calendar.DAY_OF_YEAR, -31); book.setBorrowDate(cal.getTime()); // 4. 检查逾期 → 状态变为逾期 book.checkOverdue(); assertEquals(已逾期, book.getStateName()); // 5. 归还 → 状态变为已归还 book.returnBook(); assertEquals(已归还, book.getStateName()); }测试关键点使用Calendar精确设置borrowDate避免时间精度问题每一步assertEquals验证状态名称这是状态模式最直观的验收标准测试覆盖了“可借→已借→逾期→已归还”全路径吉林大学作业中此类多步流转是高分必备项。我带过三届吉林大学设计模式课程助教最深的体会是模式不是贴在代码上的标签而是你面对需求变更时手指先敲出的那几行接口定义。当看到BorrowStrategy接口时你就该预判到下周要加的“校友规则”只需一个新类当写下BookState时就该想到“维修中”状态不过是另一个实现。这些肌肉记忆是在一次次作业的if-else绞杀战里练出来的。希望帮到你。本文还有配套的精品资源点击获取