封装是用边界、权限和契约管控数据与行为；需按职责分包、属性私有+行为暴露、接口统一入口、构造器调用set校验，确保修改可控、扩展无感、维护清晰。
直接说重点：封装不是加几个 private 和 get/set 就完事，而是用边界、权限和契约把数据和行为真正管起来。对第一个控制台项目（比如图书管理系统）来说，合理封装能让你改一处不崩全盘、加功能不翻车、别人接手不抓狂。
按职责分包，让每个类只干一件事
别把所有代码塞进一个 Main.java 或 Book.java 里。参考标准分层结构：
- book 包：只放 Book（单本图书的属性+校验逻辑）、BookList（书架数组+增删查基础操作），不碰菜单、不处理用户权限
- user 包：User 是抽象父类，定义 login()、showMenu() 这类共性；AdminUser 和 NormalUser 各自实现自己能干的操作，不越界
- ioperations 包：每个功能一个类（AddOperation、BorrowOperation），只专注“做这件事”，不掺杂输入输出或流程控制
这样改借阅逻辑，只动 BorrowOperation；换管理员菜单，只改 AdminUser.showMenu() —— 影响范围清晰可控。
属性私有 + 行为暴露，用方法代替字段直写
比如 Book 类里：
- 把 name、author、isBorrowed 全设为 private
- 提供 setIsBorrowed(boolean b)，内部自动校验：不能对已借出的书重复借，也不能对未借出的书重复还
- 提供 toString() 统一格式化打印，而不是在 Main 里拼字符串
以后想加借阅时间戳、记录操作人，只改 Book 类内部，所有调用方完全无感。
接口统一入口，把“怎么做”藏起来
定义 IOperation 接口，声明一个 exec(BookList bookList) 方法。所有功能类（FindOperation、DelOperation…）都实现它。
Main.java 的菜单循环就变成：
operations[choice].exec(books);新增一个“按作者统计数量”功能？只写新类 AuthorCountOperation 实现接口，注册到数组里，Main 一行代码都不用动。
构造器也走封装通道，别绕过校验
Book 构造器如果直接给 this.name = name，那 new Book("", -5) 就合法了。正确做法是：
- 构造器里调用 this.setName(name) 和 this.setPrice(price)
- 所有校验逻辑只写在 set 方法里，一处维护，处处生效
哪怕只是控制台小项目，这种习惯一上来就养成，后面对接数据库、加日志、做权限拦截，骨架已经立住了。
