任何人都可以阅读GoF书籍以了解设计模式是什么以及如何使用它们,但是什么是确定设计模式何时解决问题的过程?模式的知识是否推动了设计,或者有没有办法弄清楚如何使用模式来改变设计?
换句话说,模式有模式吗?
我强烈推荐阅读O'Reilly的Head First Design Patterns.这解释了如何在现实世界中使用这些模式.
我还要补充一点,不要试图设计过多的图案.更多,寻找模式可能有助于解决的"代码味道".
设计模式都应该提供一种结构,其中的问题是可以解决的.在解决实际问题时,您必须考虑解决该问题的许多微小变化,以确定是否符合设计模式.特别是,您可能需要概括您的问题或其解决方案,以使设计模式适合.
答案是,这是一门艺术. 了解设计模式无疑是重要的一步.习惯这种事情的一种方法是研究设计模式的应用,而不仅仅是模式.查看一种模式的许多不同应用程序可以帮助您随着时间的推移更好地将任务映射到模式上.
大多数人都没有理解的基本模式的核心概念.不要将它们视为数据结构或算法.
相反,将您的代码视为发送消息的人,例如传递笔记或发送信件.每个对象都是一个"人".
您组织"人员"的方式以及他们用来向对方发送消息的模式是模式.
把问题翻过来:你应该做的模式是"什么模式适合我的问题".考虑一个非常简单的模式,在数组中查找元素.在C中,它就像是
TYPE_t ary[SIZE] = // ... gets initialized somehow size_t ix ; // Your index variable for(ix=0; ix < SIZE; ix++){ if (ary[ix] == item) { return ix ; } }
你不看代码并想"我在哪里可以使用它",你看问题并说"我知道如何在数组中找到一个元素吗?"
更广泛的模式确实以同样的方式工作.您需要拥有许多不经常更改的数据结构副本 - 这会让您想到"Flyweight".你想要一些生活在网络边界两侧的东西,你认为是代理.
当你研究模式,尤其是GoF时,问问自己"这种模式需要什么样的情况?我以前看过这种模式吗?我以前的工作中有什么用呢?我在哪里可以找到一个这样的例子? "
设计模式?你在浸泡它们!
设计模式没有什么特别之处,它们只是设计模式.所有开发都使用设计模式.在面向对象的编程中存在一组特定的设计模式,这些模式被认为是通常期望的并且已经成为规范的设计模式.但是也存在许多不期望的或其他无关紧要的设计模式(例如设计反模式)以及未发现和/或未记录的模式.
编程时无法避免使用模式.但是你可以更加了解你正在使用的模式,以及某些模式何时有用以及何时不可用.从GoF书中学习规范设计模式将有助于学习代码气味和重构.对于何时应该使用特定的设计或设计模式,没有一个正确的答案,您需要积累使用和实现它们的经验,以便知道何时何地使用哪种模式.
经验.了解其用途的模式和实际示例.每当您做出设计决策时,请考虑您知道的模式是否适用于它.随着时间的推移,您会变得更好,并且您会发现将模式应用于更广泛问题的新方法.