深入探究【观察者模式】:简单音乐会售票系统案例分析

2025-12-13 0 205

文章目录
1.观察者模式概述
基本概念:
工作原理:
2.案例-音乐会抢票
2.1.具体实现
2.1.1.被观察者接口
2.1.2.被观察者实现类
2.1.3.定义观察者接口
2.1.3.定义观察者实现类
2.1.4.测试观察者
3.总结
3.1.优点和局限性

3.2.思考

1.观察者模式概述
观察者模式是一种行为型设计模式,它允许对象(称为观察者)订阅另一个对象(称为被观察者或主题)的状态变化,并在状态发生变化时自动接收通知和作出相应的响应。观察者模式是一种松耦合的设计模式,使得被观察者和观察者之间的关系不会紧密耦合,从而提高了系统的灵活性和可扩展性。

基本概念:
被观察者(Subject):也称为主题或发布者,是状态的持有者,当其状态发生变化时会通知所有订阅者。被观察者通常包含注册、删除和通知观察者的方法。
观察者(Observer):也称为订阅者,是被动接收被观察者状态变化通知的对象。观察者需要实现接收通知并作出相应动作的方法。
通知(Notification):是被观察者向观察者发送的消息,用于告知观察者被观察者的状态发生了变化。
工作原理:
建立订阅关系:观察者通过订阅(注册)的方式与被观察者建立联系。被观察者维护一个观察者列表,可以动态添加或删除观察者。
状态变化通知:当被观察者的状态发生变化时,它会遍历观察者列表,依次调用每个观察者的通知方法,将状态变化的消息传递给观察者。
观察者响应:每个观察者接收到通知后,会执行预定义的更新逻辑,以便与被观察者的状态保持一致。观察者可以根据通知的内容进行相应的处理,比如更新界面、发送邮件等。
解耦合:观察者模式通过将被观察者和观察者解耦,使得它们之间的关系更加灵活和可扩展。被观察者不需要知道具体的观察者是谁,而观察者也不需要了解被观察者的具体实现细节,从而降低了对象之间的依赖关系。
2.案例-音乐会抢票
在软件开发中,设计模式是一种被广泛应用的解决方案,它们提供了解决特定问题的模板和指导原则。观察者模式是其中的一种重要模式,它允许对象之间建立一种一对多的依赖关系。当一个对象的状态发生变化时,所有依赖它的对象都会得到通知并自动更新。观察者模式的应用场景非常广泛,包括软件开发、系统设计以及实时数据处理等。为了更深入理解观察者模式的原理和应用,我们将以一个实际案例——音乐会售票系统,来进行分析和探讨。

音乐会售票系统是一个用于管理音乐会门票销售的应用程序,它提供了用户购买音乐会门票的功能,并且能够实时更新剩余门票数量,以便用户了解门票的售罄情况。

在音乐会售票系统中,观察者模式被应用于实现对门票销售情况的观察和通知功能。以下是系统中的角色和交互关系:

被观察者(Observable):音乐会售票系统充当被观察者,负责维护观察者列表,并在门票数量发生变化时通知观察者。
观察者(Observer)
粉丝服务(FansService):作为观察者之一,粉丝服务负责接收到系统通知后,更新粉丝购票页面上的剩余门票数量。
黄牛服务(CattleService):同样作为观察者,黄牛服务在接收到门票售罄通知后,可以采取一些特定的行动,比如通知其他黄牛或者调整策略。
交互关系:
用户购票时,系统会更新门票数量并通知所有观察者。
粉丝服务和黄牛服务接收到通知后,根据通知内容更新自身状态或采取相应措施。
观察者与被观察者之间的交互是松散耦合的,被观察者不知道具体的观察者身份,而观察者只需关注自己的业务逻辑即可。
通过观察者模式,音乐会售票系统实现了对门票销售情况的实时监控和通知,提升了系统的可维护性和扩展性,同时为用户和其他利益相关者提供了更好的用户体验和服务。

2.1.具体实现

2.1.1.被观察者接口
/**
* 被观察者接口
* @author 13723
* @version 1.0
* 2024/1/29 10:12
*/
public interface Observable {
/**
* 添加观察者
* @param observer 观察者
*/
void addObserver(Observer observer);

/**
* 删除观察者
* @param observer 观察者
*/
void removeObserver(Observer observer);

/**
* 通知观察者
* @param count 通知内容
*/
void notifyObserver(AtomicInteger count);

}

2.1.2.被观察者实现类
构建被观察者:ConcertTicketSalesService类的设计与实现,包括售票操作和通知观察者的功能。

/**
*
* 被观察者实现类
* @author 13723
* @version 1.0
* 2024/1/29 10:14
*/
public class ConcertTicketSalesService implements Observable{
private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

/**
* 观察者集合
*/
private final List<Observer> observers = new ArrayList<>();

public static final AtomicInteger count = new AtomicInteger(0);

/**
* 添加观察者
* @param observer 观察者
*/
@Override
public void addObserver(Observer observer) {
this.observers.add(observer);
}

/**
* 删除观察者
* @param observer 观察者
*/
@Override
public void removeObserver(Observer observer) {
this.observers.remove(observer);
}
/**
* 通知观察者
* @param count 通知内容
*/
@Override
public void notifyObserver(AtomicInteger count) {
// 通知所有观察者
for (Observer observer : this.observers) {
observer.make(count);
}
}
public void sale(int ticketNum){
count.addAndGet(ticketNum);
logger.error(\”原始售票数量:{}\”,ticketNum);
logger.error(\” ——— 开始售票 ——— \”);
notifyObserver(count);
}
}

2.1.3.定义观察者接口
/**
* 观察者接口
* 观察者模式又称为发布/订阅(Publish/Subscribe)模式,在对象之间定义了一对多的依赖,
* 这样一来,当一个对象改变状态,依赖它的对象会收到通知并自动更新触发行为
*/
public interface Observer {
/**
* 观察者接收到通知后的处理逻辑
* @param count 通知内容
*/
void make(AtomicInteger count);

}

2.1.3.定义观察者实现类
FansService 和 CattleService类的设计与实现,描述了粉丝和黄牛作为观察者接收通知并进行抢票的行为。

/**
* 粉丝接收通知,开启抢票
* @author 13723
* @version 1.0
* 2024/1/29 10:23
*/
public class FansService implements Observer {
private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

/**
* 粉丝接收通知,开启抢票
* @param count 通知内容
*/
@Override
public void make(AtomicInteger count) {
int andDecrement = count.getAndDecrement();
logger.error(\”粉丝接收通知,开启抢票,剩余票数{}\”,andDecrement);
}
}

/**
* 黄牛接收通知,开启抢票
* @author 13723
* @version 1.0
* 2024/1/29 10:26
*/
public class CattleService implements Observer{
private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

/**
* 黄牛接收通知,开启抢票
* @param count 通知内容
*/
@Override
public void make(AtomicInteger count) {
int andDecrement = count.getAndDecrement();
logger.error(\”黄牛接收通知,开启抢票,剩余票数{}\”,andDecrement);
}
}

2.1.4.测试观察者
public class ObserverTest {
private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

@Test
@DisplayName(\”测试-观察者模式\”)
public void test(){
ArrayList<Thread> threads = new ArrayList<>();
// 创建被观察者
ConcertTicketSalesService concertTicketSalesService = new ConcertTicketSalesService();
// 创建观察者(粉丝)
for (int i = 0; i < 30; i++) {
Thread thread = new Thread(() -> {
FansService fansService = new FansService();
concertTicketSalesService.addObserver(fansService);
}, \”f\” + i);
threads.add(thread);
}
// 创建观察者(黄牛)
for (int i = 0; i < 10; i++) {
Thread thread = new Thread(() -> {
CattleService cattleService = new CattleService();
concertTicketSalesService.addObserver(cattleService);
}, \”t\” + i);
threads.add(thread);
}
threads.forEach(Thread::start);
// 被观察者开始执行卖票操作
concertTicketSalesService.sale(100);

}
}

上面这段代码实现了观察者模式,用于模拟音乐会售票系统。其中,ConcertTicketSalesService是被观察者,负责售票操作,并在售票时通知所有观察者。观察者包括粉丝和黄牛,它们分别在收到通知后开启抢票。粉丝和黄牛通过实现Observer接口来接收通知,并通过Observable接口实现被观察者与观察者的交互。ObserverTest类则用于测试观察者模式的正确性,创建了30个粉丝和10个黄牛,并模拟了音乐会售票过程。

3.总结
3.1.优点和局限性
优点

松散耦合(Loose Coupling):观察者模式通过定义了一个抽象的观察者接口和被观察者对象之间的联系,使得它们可以相互独立地变化。这种松散耦合的设计使得系统更易于维护和扩展。
可扩展性(Scalability):由于观察者模式将被观察者对象与观察者对象分离,因此可以方便地增加新的观察者或者修改现有的观察者,而不需要修改被观察者对象的代码。
通知机制(Notification Mechanism):观察者模式提供了一种通知机制,使得被观察者对象发生改变时能够自动通知所有的观察者对象。这样可以确保所有相关的对象都能及时获取到最新的信息。
解耦合(Decoupling):观察者模式可以降低对象之间的耦合度,使得系统中的各个对象之间相互独立,降低了代码的复杂度。
局限性

过多的通知:如果被观察者对象频繁地发生改变,可能会导致观察者对象收到过多的通知,造成性能上的开销。
可能引发循环依赖:在某些情况下,观察者和被观察者之间可能出现循环依赖的情况,导致系统设计不合理。
难以调试:由于观察者模式中对象之间的关系比较复杂,当系统出现问题时,可能需要花费较多的时间和精力来进行调试和定位问题。
可能引起内存泄漏:如果观察者没有被正确地移除或者被长期持有,可能会导致内存泄漏问题,影响系统的性能和稳定性。
3.2.思考
观察者模式是一种强大的设计模式,能够有效地实现对象之间的解耦合和协同工作。在实际项目中,合理地应用观察者模式可以提高系统的灵活性、可维护性和可扩展性,但也需要根据具体情况来权衡其利弊,避免滥用和不必要的复杂性。在下面几个方面观察者模式发挥着很重要的作用

事件驱动架构:观察者模式可以作为构建事件驱动架构的基础之一。通过将各个模块之间的交互建立在事件的发布与订阅之上,可以实现系统的高内聚、低耦合,使得系统更加灵活和可扩展。
异步通信:观察者模式可以与异步通信结合,实现异步事件处理。通过消息队列或者异步任务,观察者可以在收到通知后异步处理事件,提高系统的并发能力和响应速度。
领域驱动设计(DDD):在领域驱动设计中,观察者模式可以用于实现领域事件的发布与订阅。各个领域对象可以作为观察者,订阅感兴趣的领域事件,从而实现领域对象之间的解耦合和协同工作。
消息传递:观察者模式可以被用作消息传递的机制。不同模块之间的消息交互可以通过观察者模式实现,从而简化系统的通信方式,提高系统的灵活性和可维护性。
————————————————

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原文链接:https://blog.csdn.net/q1372302825/article/details/136357872

收藏 (0) 打赏

感谢您的支持,我会继续努力的!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

申明:本文由第三方发布,内容仅代表作者观点,与本网站无关。对本文以及其中全部或者部分内容的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。本网发布或转载文章出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,也不代表本网对其真实性负责。

左子网 编程相关 深入探究【观察者模式】:简单音乐会售票系统案例分析 https://www.zuozi.net/36564.html

常见问题
  • 1、自动:拍下后,点击(下载)链接即可下载;2、手动:拍下后,联系卖家发放即可或者联系官方找开发者发货。
查看详情
  • 1、源码默认交易周期:手动发货商品为1-3天,并且用户付款金额将会进入平台担保直到交易完成或者3-7天即可发放,如遇纠纷无限期延长收款金额直至纠纷解决或者退款!;
查看详情
  • 1、描述:源码描述(含标题)与实际源码不一致的(例:货不对板); 2、演示:有演示站时,与实际源码小于95%一致的(但描述中有”不保证完全一样、有变化的可能性”类似显著声明的除外); 3、发货:不发货可无理由退款; 4、安装:免费提供安装服务的源码但卖家不履行的; 5、收费:价格虚标,额外收取其他费用的(但描述中有显著声明或双方交易前有商定的除外); 6、其他:如质量方面的硬性常规问题BUG等。 注:经核实符合上述任一,均支持退款,但卖家予以积极解决问题则除外。
查看详情
  • 1、左子会对双方交易的过程及交易商品的快照进行永久存档,以确保交易的真实、有效、安全! 2、左子无法对如“永久包更新”、“永久技术支持”等类似交易之后的商家承诺做担保,请买家自行鉴别; 3、在源码同时有网站演示与图片演示,且站演与图演不一致时,默认按图演作为纠纷评判依据(特别声明或有商定除外); 4、在没有”无任何正当退款依据”的前提下,商品写有”一旦售出,概不支持退款”等类似的声明,视为无效声明; 5、在未拍下前,双方在QQ上所商定的交易内容,亦可成为纠纷评判依据(商定与描述冲突时,商定为准); 6、因聊天记录可作为纠纷评判依据,故双方联系时,只与对方在左子上所留的QQ、手机号沟通,以防对方不承认自我承诺。 7、虽然交易产生纠纷的几率很小,但一定要保留如聊天记录、手机短信等这样的重要信息,以防产生纠纷时便于左子介入快速处理。
查看详情

相关文章

猜你喜欢
发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务