如何学习理解设计模式?

22-12-20 banq

神奇的是,设计模式没有什么神奇的。
许多被认为是复杂的模式在表面下反而显得很简单,甚至是容易的。
  • 以事件源为例:简而言之,你可以在流的末端追加事件,然后从流中读取所有事件。所以要追加关于对象或流的新的业务事实,然后读取所有的事件,并从中建立当前的状态,这样才能知道发生了什么,并做出下一步的决定。
  • 或者CQRS:你只是按业务操作来切分你的应用程序,并把它们分成两个行为:读取和写入业务逻辑。
  • 或者Outbox模式:你在同一个数据库事务中把消息和状态变化叠加在一起,然后用重试等方式异步发送消息,以确保全局流的一致性。


然而,这些模式并不容易解释,因为要把所有的要点联系起来并不容易。

"给我看看真正的生产代码",我经常听到这样的话。

但是如果要学习模式,你就需要孤立的例子来练习和理解它们。然后,我们需要投入更多的精力来练习组合这些模式的技能。

直接进入别人的代码并不能教会你正确使用模式,因为你看到的是已经进行了权衡设计的结果!你很难理解他们是故意还是无意地应用这些模式的。

在你用吉他演奏独奏之前,你需要学习音阶、和弦和节奏。

如何学习设计模式
当我们学习模式时,我们应该去了解原始材料。阅读原作者的想法。理解设计它的预期背景上下文。我们可能会相当惊讶。很多时候,你可能会意识到,我们玩的是中国式的耳语。

学习的最好方式是通过实践。在一个较小的规模上进行实验,了解权衡,尝试不同的配置,并将其投入生产,清洗,冲洗,重复。

例如,当我开始学习事件源时,我创建了一个样本库,以了解模式和工具,而不破坏我工作中的系统。我尝试在沙盒环境中玩不同的想法。一旦我觉得更舒服了,我就把有用的东西带到一个常规项目中。然后,我继续进行下一步的迭代,对其他我想深入探索的东西进行研究。

解决问题
每件事情都有优点和缺点:
我们不要总是用技术手段来解决一些问题,要相信一些工具会神奇地解决我们的用例。
我经常看到,人们不知道他们要解决什么问题,却已经选择了一个技术栈,然后,他们试图将模式的定义与所选择的工具相挂钩。

提炼出模式,并思考它如何与其他模式组合,它在哪些方面可以很好地工作,在哪些方面可能会失败。然后找到最好的匹配工具来帮助你。

意识到这一点应该使你成为一个更好的开发者和架构师。你将能够做出正确的决定并理解你所做的权衡。

复杂性来自权衡
架构是这样的:

你需要学习基本模式,然后分析如何将它们连接起来。
我们习惯于看到复杂性,以至于当我们面对孤立的模式时,我们会说 "它不可能那么简单!"。
实际上,它通常是简单的,但这并不总是意味着它很容易:

与其他模式的组合以及与现实世界的权衡带来了复杂性
 

1