近期学习新得--重构/设计模式

之前对于设计模式的理解就是减少变化点，并以此判断模式是否适用得当。一个问题来了，假如只是转移而没有减少变化点，那还有必要使用该模式吗？
    比如策略模式，如不使用它，单纯用if/else，变化点不会更多。策略无论增、减、改，两者都只需要修改一处。区别只有一个，使用了模式后一旦需求变化，改起来“貌似”更容易，毕竟人家把代码分成一小块一小块，且建立了良好的封装，可读性更强；如果涉及的策略众多，算法更复杂，它的价值就更大。但说不使用就不符合“开闭原则”，使用后才符合，我不能认同，使用之前需要修改现有代码，使用之后照样要修改，且修改的地方不比原来少，区别只是难易程度。
    “可读性更强”也应该是设计模式的价值之一，否则在此例中大可以只写一个类，里面只有一个方法，却可以干所有的事情。这大概就是策略模式的价值，也是其他类似封装的价值。
     再谈下一个。
     本人虽在设计模式方面尚属才疏学浅，但也感觉到玩转设计模式，其实就是要玩转OO的几大特性，要深刻理解它们的作用，做到活学活用、“不拘于物，草木竹石均可为剑”。
     当然了，知道独孤求败厉害是一回事，学不学他的功夫又是一回事。下面在下就献丑谈一谈近期对方法“封装”的理解。
     1、最直白的作用：解释一段代码的功能，比如将一大段布尔判断提取出来，实现从“怎么做”到“做什么”的语义转变；即使只有这一个地方用也值得。当然前提是方法命名的功力到位。
     2、有利于功能复用。消除重复代码；方法提取粒度越小就越有可能实现复用。
     3、解耦。封装可能变化的部分，避免外界直接对其进行访问。
     4、增加代码可读性。由于方法提取充分，命名恰当，使得原始方法不会太长，且逻辑清晰。
     不足之处还请指正。