看完了head first 设计模式那本书，非常有收获。设计模式的定义是：在某些场景（context）下，针对某些问题的解决方案。不过也不用拘泥于这个定义，它只是帮你更好的和别人沟通。
打个比方，你用微波炉来做爆米花，建议方式是高火+3分钟，这个方式就是一种模式：
- 场景：做爆米花
- 问题：设定多少时间，微波用哪个级别？
- 解决方案：设定高火 + 3分钟
因为这个问题持续的出现，所以就出现了这个模式。设计模式也是类似，行业内持续的遇到类似的问题，所以总结出来解决问题的模式。
设计原则不像设计模式，设计原则要更抽象一些。设计原则在这里就是：做出美味的爆米花。我可以用中火 + 6分钟也行。只要能把爆米花做熟就好。当你发现有糊味的时候，要赶紧停止，不能死守模式。
也不能乱用设计模式，因为不是所有的东西都适合高火 + 3 分钟，食物会烤焦的。玉米就需要 4-5 分钟。
我们在应用时，可以多思考我们是否可以用到设计模式。但首先，我们应该，或者说始终要选择最简单的实现方式，因为我们的目标是用简单的方式解决问题，而不是如何在这个问题中使用设计模式。正确的说法是，为了让我们的设计更有弹性，有时候使用设计模式是最好的方法。
设计模式是在开发和设计进行的过程中，逐渐显现出来的，你可以对你的系统中的变化保持关注，那些地方可能就是应用设计模式的好地方。务必要知道，加入模式是要应对可能发生的改变，而不是假想的改变。
重构的目标是改善代码的组织结构，保持行为不变。重构是一个比较好的时机检查自己的设计是否可以应用设计模式。比如如果条件语句比较多，那可能可以应用状态模式或者策略模式。
设计模式会让系统变复杂，多了更多的类和层级，如果没有必要，不要增加这种复杂性。
是否使用设计模式，可以参考设计模式的类目，比如经典的GoF，有关于使用场景，作用，代码，类图等信息。
我们的项目到现在都没用redux，也是适用最简单的方式解决我们问题的一个好的例子吧。我们团队鼓励持续的重构，用测试来保证不出错，这样可以让自己和代码都持续的进步。
网友评论