设计模式：单一职责原则
想象一把瑞士军刀 vs. 一套专业厨具🔪
瑞士军刀 (违背 SRP 的类)：
它功能超多！能开瓶盖、开罐头、拧螺丝、削水果、甚至有小剪刀和小锯子。
看起来很方便，对吧？但问题来了：
太“累”了： 它要负责的事情太多了。削水果时，开罐头的部件硌手；拧螺丝时，刀片容易滑。
难“修”/“改”： 如果剪刀坏了，你要修理整个瑞士军刀，可能会影响其他功能，或者干脆就得换掉整把刀。
难“借”给别人用： 你只想借剪刀给别人用？不行，你得把整个多功能刀都借出去，别人可能根本不需要其他功能。
一个变化影响所有： 厂家想改进开瓶器设计？可能得动整个刀的结构，不小心就把螺丝刀改坏了。
专业厨具套装 (遵循 SRP 的设计)：
这里分工明确：
菜刀： 唯一职责就是切菜切肉。（对应
CustomerDataChart只负责 图表生成和显示）锅： 唯一职责就是煮菜。（对应
DBUtil只负责 连接数据库）铲子： 唯一职责就是翻炒。（对应
CustomerDAO只负责 操作客户数据）
这样有什么好处？
各司其职，专注高效： 菜刀只管切得又快又好，锅只管导热均匀，铲子只管翻炒到位。每个工具都专注于做好自己的那一件事。
独立变化，互不影响： 想换把更锋利的菜刀？没问题！换锅？也没问题！换铲子？更没问题！换其中一个完全不影响其他工具的使用。（一个类只有一个引起它变化的原因）
方便组合和借用： 需要切菜？拿菜刀。需要炒菜？拿锅和铲子组合。想借铲子给邻居？只借铲子就行，不用把整个厨房搬过去。（高内聚，低耦合，易复用）
容易维护： 菜刀钝了，磨菜刀就行，不用动锅和铲子。
所以，单一职责原则 (SRP) 的核心思想就是：
一个东西（类、模块、方法）只干好一件事。 👨🍳
这件事应该有且只有一个理由让它发生变化。 🎯
别让一个类变成“万能工具箱”，让它成为“专业工具”。 🔧
套用回你例子里的 CRM 系统：
原来那个
CustomerDataChart类就像瑞士军刀，它包揽了：连接数据库 (相当于开瓶器)
查客户数据 (相当于剪刀)
生成图表 (相当于主刀片)
显示图表 (相当于锯子)
这违反了 SRP，因为它干的事太多，变化原因也太多（数据库变了要改它，图表样式变了也要改它）。
重构后：
DBUtil只干一件事：连接数据库 (专职的“接线员”)CustomerDAO只干一件事：操作客户数据 (专职的“数据管理员”)CustomerDataChart只干一件事：处理图表 (专职的“画图师”)
总结成一句最通俗的话：
“一个类，就让它专心做好一件事，别让它身兼数职、操太多心，这样它才更可靠、更好用、更容易维护！” 💡