菜鸟阿P的逆袭：用设计模式驯服“需求怪兽”
阿P，一个刚毕业的码农，加入了“江湖科技有限公司”。他的第一个任务：给公司的核心产品“江湖通APP”添加一个 “武林秘籍推送” 功能。
噩梦开局：面条代码
阿P兴冲冲打开代码，眼前一黑：
# 原来的代码 - 一团乱麻！
class UserManager:
def __init__(self):
self.users = [] # 用户列表
# ... 其他用户相关代码 ...
def add_user(self, user):
self.users.append(user)
# 硬编码的通知方式！新增推送秘籍，要改这里！
print(f"【邮件】通知：新用户 {user.name} 注册成功！") # 邮件通知
# 如果还要短信通知、APP推送？再加几行？不敢想！
class SecretManager:
def __init__(self):
self.secrets = [] # 秘籍列表
def add_secret(self, secret):
self.secrets.append(secret)
# 秘籍添加也要通知？再写一遍通知代码？
print(f"【系统消息】新秘籍《{secret.title}》上架！")
# 通知方式也写死了！要改全得动！
# 使用
user_mgr = UserManager()
user_mgr.add_user(User("张无忌")) # 输出：【邮件】通知：新用户 张无忌 注册成功！
secret_mgr = SecretManager()
secret_mgr.add_secret(Secret("九阳神功")) # 输出：【系统消息】新秘籍《九阳神功》上架！问题来了：
通知方式硬编码：邮件通知写死在
add_user里。老板说“用户注册要加短信提醒”，阿P就得改UserManager代码。万一改坏了其他功能？重复代码：秘籍添加也要通知？阿P得在
SecretManager里再复制粘贴一遍通知代码？太蠢！紧耦合：用户管理、秘籍管理和通知方式死死绑在一起，像一团乱麻。想换个通知服务？牵一发动全身！
阿P感觉头大如斗，需求像怪兽一样朝他咆哮。这时，技术大牛“扫地僧”师傅出现了。
第一式：【观察者模式】 - 消息灵通的“江湖广播站”
“阿P啊”，扫地僧师傅笑眯眯地说，“你这通知方式，像小贩沿街叫卖，累死个人。咱们搞个‘江湖广播站’（发布-订阅模型）！”
核心思想：
主题 (Subject)：发生事情的地方（比如新用户注册、新秘籍上架）。它只负责喊：“喂！有情况啦！”
观察者 (Observer)：关心这个事情的人或模块（比如邮件服务、短信服务、APP推送服务）。它们提前在“广播站”登记：“我对新用户注册感兴趣！” 或者 “我对新秘籍上架感兴趣！”
解耦：主题完全不知道有哪些具体的观察者，也不关心它们怎么处理。它只管喊。观察者自己决定要不要听，听到后自己干活。