一、知易行难——设计模式应用的问题
“形而下者谓之器，形而上者谓之道”。
有很多人熟读且牢记每一个模式的内容，但到真实项目中时却总感觉到无从下手去实践设计模式，不知道什么情况下应该用，不知道为什么要这样用。这种情况说明，很多人只是掌握了设计模式的器，并未掌握设计模式的道。设计模式的器，只是告诉了我们如何去做，设计模式的道，就是告诉我们为什么要使用和什么时候去使用。
二、拨云见日——寻找设计模式之道
设计模式都有其适用的场景。我们如何去选择一个合适的模式应用到场景中呢？《设计模式》书本中每一个模式后都有阐述适用性，但是23个模式本身内容就不少，能熟记所有的内容就不好做到，更不要说记住每个模式的适用性了。那么在实际应用中，要解决什么时候去使用某个设计模式？为什么要使用？这两个疑难点，其实只要一句话就足以概括——“对变化的概念进行封装；找到变化，封装变化”。
所以当我们在实际开发中，某个场景中遇到了关于扩展性的问题，那么说明这个场景中是有变化存在的，那么我么就首先解决了where的问题。再根据场景扩展性的需要，去看哪个模式最适合解决这个问题，那么就解决了why的问题
三、庖丁解牛——解析设计模式之道
首先，“找到变化”解决了“在哪里”使用设计模式的问题，即回答了where的问题。
根据对行业的了解和经验，很容易在某个场景下找到哪些业务是可能会变化的，那么我们就去封装这个业务的变化。但是，如果我们涉及到的需求是个从来没接触过的行业，那么我们怎么去确定哪些业务场景是存在变化的？这时，因为我们对这个行业的经验不够多，因此我们可以将“唯一不变的就是变化”这句话做为准则，去怀疑一切业务场景都可能发生变化。但是，在去怀疑一切业务场景时也必须有个结束条件，这个条件一般就是时间。我们可以通过1年内、3年内或5年内，哪些业务是有可能发生变化的，去寻找变化，当确定了一个时间范围后，我们可以向有经验的老鸟请教某某业务X年内可能发生变化吗？这样也显的不会无的放矢。
其次，“封装变化”解决了“为什么”使用设计模式的问题，即回答了why的问题。
为什么要封装变化呢？因为变化对系统而言不好，注意，这里是仅指对系统。变化对业务来说是好的，因为业务要与时俱进，要不断的去适应市场的变化，这样才能立于不败之地。毕竟开发的系统是为业务服务的，那么业务需要经常变化，因为需求的变化会引起的代码修改量增加、测试量增加、重复的构建、上线而导致系统出现新BUG、不稳定，所以我们为了尽量减少这些后果，所以要对变化进行封装隔离，使变化仅在有限的范围内产生影响，降低在变化到来时系统维护的成本。