面向对象设计：简易图书管理系统实战教程

本文以简易图书管理系统为实践案例，深入浅出地诠释了面向对象设计的本质——不是死记概念或堆砌继承结构，而是从现实中的“书、读者、系统”三个核心角色出发，通过合理封装、职责分明的对象协作与灵活的组合方式，自然地将业务逻辑映射为清晰、可维护的类结构；它强调先思考“谁在做事、做什么事、事情怎么分”，用私有属性+行为方法守住边界，让借还书等操作成为对象间的对话而非冗长判断，真正实现小步重构、低耦合、易扩展的设计初心。

面向对象思想不是先背概念，而是从“谁在做事、做什么事、事情怎么分”开始。设计一个简易图书管理系统，关键不是堆功能，而是把书、人、操作这些现实元素，自然地映射成类和关系。

先想清楚三个核心角色：书、读者、系统

别一上来就写代码。拿出纸笔或白板，问自己：

• 书有什么特征？——书名、作者、ISBN、是否借出、借给谁（可选）
• 读者需要什么信息？——姓名、学号/ID、当前借了几本（可限制）、借了哪些书（可记录）
• 系统要完成哪些动作？——添加书、查找书、借书、还书、列出所有书、查看某读者的借阅情况

这三者就是你最该优先定义的类：Book、Reader、LibrarySystem。每个类只管自己的数据和它“本来就会做的事”，比如Book不负责打印列表，但可以告诉别人“我是不是被借走了”。

用封装守住边界：属性私有 + 方法暴露行为

比如Book类，ISBN和借出状态不该被外部随意改写：

• 把is_borrowed设为私有属性（如Python用_is_borrowed，Java用private）
• 提供borrow()和return_book()方法来改变状态，方法内部可加逻辑（例如：只有未借出才能借）
• 用get_info()返回格式化字符串，而不是直接暴露所有字段

这样以后修改借阅规则（比如加入借阅日期），只需改Book类内部，不影响其他部分。

让借还书变成“对象之间说话”，而不是一堆if判断

借书不是“系统查书→查读者→改状态→打印成功”，而是：

• Reader调用request_borrow(book)
• Book的borrow()方法检查是否可借，返回True/False
• Reader根据返回结果决定是否登记、更新自己的借阅列表
• LibrarySystem只做协调者：接收请求 → 找到对应Book和Reader对象 → 让它们交互

这种设计下，如果以后增加“预约”功能，只需在Reader里加reserve(book)，Book加is_reserved，系统层几乎不用动。

继承和多态先放一放，组合更实用

初学者容易过早用继承，比如搞个Book父类，再分TextBook、Novel……但简易系统里，差异往往只是字段（如教材有年级、小说有流派），没必要拆类。

• 不如用一个Book类，加个category字段，查询时按字段过滤
• 真需要扩展时，用组合：比如给Book加一个publisher对象（含名称、地址），比把出版社信息全塞进Book更清晰
• 等你发现10个类都在重复写“计算逾期天数”“生成条码”，那时再抽象出公共父类或工具类，才真正需要继承

不复杂但容易忽略：好设计是让新增需求改动范围小，而不是一开始就把结构画得像教科书。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《面向对象设计：简易图书管理系统实战教程》文章吧，也可关注golang学习网公众号了解相关技术文章。