面向对象设计应从现实角色出发，优先定义Book、Reader、LibrarySystem三类，通过封装隔离变化，用对象协作替代流程判断，以组合和小步重构代替过早继承。
面向对象思想不是先背概念，而是从“谁在做事、做什么事、事情怎么分”开始。设计一个简易图书管理系统，关键不是堆功能，而是把书、人、操作这些现实元素，自然地映射成类和关系。
先想清楚三个核心角色：书、读者、系统
别一上来就写代码。拿出纸笔或白板，问自己：
- 书有什么特征？——书名、作者、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个类都在重复写“计算逾期天数”“生成条码”，那时再抽象出公共父类或工具类，才真正需要继承
不复杂但容易忽略：好设计是让新增需求改动范围小，而不是一开始就把结构画得像教科书。
