编码思考与设计模式

业务系统的挑战和价值 业务系统的真正的挑战并不是技术，技术只是一个工具，基本上都有成熟的组件来使用。业务系统真正的价值也不是技术，而是实现了对企业有价值的业务逻辑。所以一个业务系统真正的挑战在于如何快

具体问题的设计方案根据实际场景千变万化，其背后的设计原理几乎从未未改变。设计原理是比设计模式更抽象一级的方法论，接近于哲学。高度的抽象使得设计原理使用范围很广，小到代码书写，方案设计，大到生活的方方面

SQL中是否应该写逻辑 问题 如果我们有不同业务需要更新表的不同字段，我们是应该为每个业务单独写SQL，还是写个更新全部字段的SQL，还是写个动态SQL根据传入的对象非空拼接？ 问题举例-用户信息更改

1. 引言 学习模式的时候，会不会这种想法，不就是接口，抽象类，属性组合这些基本语法吗？为啥搞这么复杂？模式并不会改变编程语言的基础。我们是不是可以换个角度，从编程语言提供的基础能力来审视下。（本文使

分层是大自然的杰作，或者说是造物者的设计。而软件通过分层来抽象逻辑，构成整体与部分的树形分形结构。下图是秋天的落叶，树叶脱离枝干，散落地上，很凌乱，你很难去观察这些树叶。

你可以尝试打开一篇中文文章，大概几秒钟就能速读完了解大概；再打开一篇英文文章，需要多少时间呢？可能需要几十倍的时间。代码长度是一个永恒的争议，目前主流观点认为应该抽取小方法，消除长方法。在实践中，我发

1. 业务逻辑与代码 1.1 逻辑与代码的关系 需求文档是业务逻辑的一种展现形式，而代码不过是业务逻辑的另一种表现形式；如果逻辑本身有问题，那么它的各种展示形式自然也是错的，所以写代码前应该先思考清楚

摘要：学习的过程是由已知概念去学习未知概念，编程中的很多概念，并不是新的概念，平时生活中都有使用。我们通过生活中的经验和编程类似概念类比思考，来加速我们的学习过程。 本文讨论GOF中最常用的设计模式