我想向侄女解释设计模式,但是总是很难做到。这在很大程度上是由于我对设计模式缺乏清晰的了解。您如何建议以简单的术语来解释MVC,Singleton,Factory,Repository等模式,即使10岁的孩子也能理解。
我正在寻找可以简化理解模式的示例。例如玩具,电影,音乐等。
我想向侄女解释设计模式,但是总是很难做到。这在很大程度上是由于我对设计模式缺乏清晰的了解。您如何建议以简单的术语来解释MVC,Singleton,Factory,Repository等模式,即使10岁的孩子也能理解。
我正在寻找可以简化理解模式的示例。例如玩具,电影,音乐等。
Answers:
我认为Wikipedia文章的开头可能是一个好的开始:
A design pattern is a general reusable solution to a commonly occurring problem.
还是您想解释这些特定模式的细节?
这取决于您为什么要解释它。如果您只是想解释模式的概念,我将借鉴A Pattern Language中的架构示例。这些研究人员发现,建筑物或房间的某些方面使人们在该建筑物或房间中享受生活或工作-在世界各地,他们具有不同的文化,不同的建筑材料和不同的居住区。例如“两面的光”。在两个墙壁上都装有窗户的房间比只有一个(或没有)窗户的房间好得多。软件中也存在类似的模式-即使使用不同的编程语言,也会重复出现某些模式。甚至使用非常不同的软件-游戏,财务计算工具,Facebook内部引擎等等。
然后,如果您要讨论一种特定的模式(不确定为什么要使用10年的模式),可以先给出示例使用的示例,然后再尝试解释它的工作原理。因此,Composite使您可以在计算手提箱重量时避免显式递归,方法是将容器的重量与所有容器的总和及其所容纳的零散物加起来,但它也可用于计算公司的薪资负担或制造工厂的产能。如果这对于10岁的孩子来说还是有点有趣,那么您可以尝试解释它的工作原理。
之所以存在设计模式,是因为有人意识到有一些方法可以使一些软件很好地协同工作,并希望分享他们的见解。
您可以以与思考人群相同的方式来思考设计模式。例如,有时我们有一个人主持我们的所有会议。这就像一个控制器模式,它促进了对象之间的交互。
或想象一个听众,房间前面的某人看着有人举手,然后重复这个问题,以便其他人都可以听到,或者可以通过回答来做出反应。那将类似于主题/观察者模式。
有些模式的行为类似于翻译器(适配器模式),安全卫士(代理服务器),领域专家(单身人士)或检查您的汽车正在工作的人(验证者)。
对象与人之间的区别在于,我们几乎可以根据需要创建任意数量的对象,并具有多个不同的副本。因此,重要的是要了解对象应该承担的职责,将其职责保持在很小的范围内,并尽量避免重复他们的职责,以免软件变得过于复杂。专家们在这方面有丰富的经验,他们为我们提供了有效的软件交互方式的这些模式,以便我们可以确定哪种角色是我们要完成的工作的最佳隐喻,并且可以软件以最合适的方式进行协作。
这些设计模式大多数都是面向对象设计的一部分。您无法真正向不了解OOD的人解释它们。您可以描述使用给定模式实现的目标,但不能描述它的工作原理,也不能描述为什么需要它。除非您当然要解释整个OOD。
首先介绍了用于架构的设计模式。诸如广场,建筑物和其他通常重复布置的位置之类的东西。您可能从这里开始。主入口朝向街道,门朝向房间一角,以及其他您能想到的东西。原始作者的模式并未得到广泛使用。据报道,他现在说模式本身还不够。
讨论在房间内移动东西。在门前放一把椅子。将窗户或门移到其他地方是否有意义?为什么或者为什么不?
尝试在餐桌上摆个位置。尝试按大小排列东西,远离您。不是正常的模式,很难使用。正常设置。这是一杯果汁的合适布局吗?模式并不总是合适的。
我们一直生活在模式之中。拿三本书或四本书开始翻阅。布局中有明显的图案;标题页,目录,内容和索引。并非所有组件都是必需的,但是看到它们不正确会令人困惑。
设计模式对于软件开发而言就像夹具对木工一样。它是一种工具,您可以使用它进行知名的“剪切”以在较大的项目中使用。
请注意,您不需要夹具即可进行切割,在某些情况下它更容易。
我觉得我的其他答案代表一般情况,但是OP要求提供详细信息(因此,我认为这是一个单独的答案)。遗憾的是,我对存储库模式不熟悉,但是我会刺探其他模式。通常,我认为解释这些问题的最佳方法是通过您要解决的问题,您要解决的原因以及问题是如何实现的。
当我们要保证只有某种东西时使用这种模式。通过阻止其他人创建我们的对象来完成该模式。
此模式用于使事物保持模块化,并具有随之而来的所有优势。视图是“用户界面”,模型是数据(包括业务逻辑),控制器是用户操作如何操纵模型。有了这种模块化,没有什么可以阻止我使用多个视图/控制器来使用同一模型。对于过于简化的示例,我可以通过网站,桌面应用程序和iPhone(“视图+控制器”)与电子邮件(“模型”)进行交互。如果我有一个共享的组邮箱,则可以创建一个不会发送电子邮件的控制器,并重用相同的应用程序视图和电子邮件。(是的,过于简单,但希望可以理解:))
此外,有了这种定义明确的关注点分离,一个(理想情况下)的更改就不需要更改另一个。具体的例子,如果我需要支持对MySQL数据库而不是Oracle数据库的读/写,则只需要更改模型,视图/控制器就不会更改。
这里要小心,因为有许多类似的模式称为Factory ...我将讨论Abstract Factory,但是您应该也知道还有Factory Method模式。
基本上,当我知道要执行哪些步骤时,我将使用抽象工厂,但是有关如何完成这些单独步骤的步骤可能会有所不同。例如,我可能正在构建一个应用程序,需要在其中创建一个带有按钮的对话框。通过让我的代码使用一个假设的UI工厂,如果我需要在Mac或Linux而不是Windows上运行我的代码,我将提供一个不同的工厂,其余代码不会更改。对于一个可能更疯狂的示例,我可能有一个Web工厂,突然,支持我的桌面应用程序的大多数代码现在也为一个富网站提供了动力:)(出于其他原因,虽然不切实际,但从理论上讲:))