〇、小故事
小王大学毕业后，找了一份像样的工作，早八晚五轻松自在，并且收入也不错。自从大学毕业后，家里用的电脑还是他上大学的时候用了四年的电脑，配置性能早已跟不上现在的时代了。他决定用自己赚的工资买一台家用电脑。
他咨询了他的好朋友，好多人都建议他买一台苹果的一体机，所有硬件都集成在了显示器中，而且设计非常帅气，占用空间也小，他也去实体店看了一下，一眼就看中了，然后兴高采烈的买了一台。
新电脑配置也高，流畅度也特别的好。但是，过了几个月，他的好朋友跟他说，我们一起玩《逃离塔科夫》这款游戏吧，非常好玩，咱们几个兄弟一起组队，杀他个天翻地覆！小王当然也想一起玩，但是这款游戏要求的是独立显卡，并且对显卡性能要求也比较高，小王的苹果一体机是集成显卡，不符合游戏的最低要求。
小王纠结了好几天，他也咨询了他的朋友们，他的朋友说，你这是一体机，没法更换显卡，如果当初你买的是一台正常的台式机，配件更换就容易得多了。没办法，小王只好将心爱的苹果一体机卖掉了（损失惨重啊……），然后买了一台正常的台式机。
一、原则定义
从上面的小故事，我们可以看到，小王没法玩这款游戏的主要原因就是显卡配置太低了，由于一体机对于硬件升级的“开闭原则“很不友好，所以，只能通过更换电脑这种高昂的代价还满足用户的需求了。
而对于普通的电脑来说，显卡不行升级显卡就可以了；主板不行升级主板；硬盘不行升级硬盘……，我们发现，对于不同的需求，只需要进行小范围的调整，而不至于去更换整台电脑。那么，这就满足了我们即将要介绍的开闭原则了。
下面，我们来看一下这个设计原则的定义：
针对类、方法、模块应该对扩展开放，对修改关闭。通俗讲，就是添加一个功能应该是在已有的代码基础上进行扩展，而不是修改已有的代码。
二、原则实践
通过上面小王买电脑的例子和原则的定义描述，我们已经对开闭原则有了大致的了解，为了更加加深大家对这个设计原则的理解，我们举个业务上的例子，来进一步了解它在实践上的应用。
业务场景：
我们有一款app，需要去做用户活动相关的功能，也就是说，每逢618、双11、节假日都会开展一系列的用户活动，这种用户活动会频繁的创建，活动截止时间一到这个活动也就下线了。那么对于这种需求我们应该如何设计呢？
需求特点：
活动的上线和下线会很频繁，每段时间同时上线的活动列表也各不相同，活动服务具有很大的不稳定性。
那么，针对这种情况，我们的理想应对方式是这样的：
PM过来跟你商量最新的上线及下线活动，你只需要“配置一下”或者较少的修改，就可以轻松应对PM的需求了。
那么，这种场景，就一定要遵循开闭原则的设计方式，否则，你就将会被层出不穷的活动需求搞得焦头烂额，手忙脚乱。
那具体应该怎么设计呢？我们可以通过模板方法+策略模式的方式进行设计，灵活性可以通过在配置中心/DB中配置活动列表来实现，在业务逻辑调用的时候，从配置中心/DB中获得某个活动对应的beanName，然后从IOC中获取实例对象进行操作即可。具体的设计请见下图所示：
今天的文章内容就这些了：
写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。
更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ \(^o^)/ ~ 「干货分享，每天更新」