猿问
下载APP

单身人士真的那么糟糕吗?

单身人士真的那么糟糕吗?

可以理解的是,许多设计模式在某些情况下可能被滥用,就像妈妈总是说:“ 太多好事并不总是好的!

我注意到这些天,我经常使用Singletons,而且我担心自己可能会滥用设计模式,并且越来越深入地研究一种不良习惯的习惯。

我们正在开发一个Flex应用程序,当用户使用它时,该应用程序在内存中保留了相当大的分层数据结构。用户可以按需加载,保存,更改和刷新数据。

这些数据通过Singleton类集中,该类聚合了几个ArrayCollections,Arrays,value对象以及通过getter和setter公开的一些其他本机成员变量。

要从应用程序的任何位置获取对数据的引用,我们执行整个Model.getInstance()方法类型的事情,我确信每个人都熟悉。这确保了我们始终掌握相同的数据副本,因为在我们设计时,我们说在应用程序生命周期中只允许存在一次实例。

从这个中央数据存储库中,我们可以轻松地调度属性更改事件,并且可以有多个引用中央数据的UI组件,更新其显示以反映已发生的数据更改。

到目前为止,这种方法已经有效并且证明对我们的环境非常实用。

然而,我发现,在创建新课程时,我有点过分了。问题应该是一个类是Singleton,还是应该以其他方式管理,例如可能使用工厂,往往有点变得有点困难,有点不确定。

我在哪里画单线?是否有一个很好的指导方针来决定何时使用单身人士以及何时远离他们。

此外,任何人都可以推荐一本关于设计模式的好书吗?


慕仰0522570
浏览 48回答 3
3回答

慕田峪7331174

要记住的关键是设计模式只是帮助您理解抽象概念的工具。一旦掌握了这种理解,将自己专门限制在书中的“食谱”是毫无意义的,并且会损害您编写最适合您目的的代码的能力。也就是说,阅读像GoF这样的书会给你提供更多思考问题的方法,这样当你自己实现某些东西的时候,你将有更广泛的视角来解决问题。在你的情况下,如果在每种情况下使用单身人士都有意义,那么就去吧。如果它“适合”并且你必须以一种笨重的方式实现它,那么你需要提出一个新的解决方案。强制不完美的图案有点像在圆孔中敲击方形钉。鉴于你说“这种方法已经有效并且证明对我们的环境非常实用”,我认为你做得很好。这里有一些好书:Gang of Four Book - 设计模式的经典书籍头脑设计模式 - 我听说过少数人推荐的这种模式

三国纷争

是的,单身人士很糟糕。它们很糟糕,因为它们为你所做的只是结合了两个属性,每个属性在95%的时间都是坏的。(这意味着平均而言,单身人士在99.75%的时间里表现不佳;))由GoF定义的单例是一种数据结构:授予对象的全局访问权限强制只能存在一个对象实例。第一个通常被认为是一件坏事。我们不喜欢全局变量。第二个是更微妙,但一般来说,实际上没有任何情况下这是一个合理的强制执行限制。有时,只有一个对象实例才有意义。在这种情况下,您选择只创建一个。您不需要单例来强制执行它。通常情况下,即使只有一个实例“有意义”,事实证明它根本没有意义。迟早,你需要不止一个记录器。或者多个数据库。或者您将不得不为每个单元测试重新创建资源,这意味着我们必须能够随意创建它们。在我们理解后果之前,它过早地从我们的代码中消除了灵活性。单例隐藏依赖关系并增加耦合(每个类都可能依赖于单例,这意味着除非我们还重用所有单例,否则该类不能在其他项目中重用),并且因为这些依赖关系不是立即可见的(作为函数/构造函数参数) ),我们没有注意到它们,通常在我们创建它们时不会考虑它们。只需拉入一个单例就可以了,它几乎就像一个局部变量一样,所以我们倾向于在它们存在时使用它们很多。这使他们几乎不可能再次删除。你最终,也许不是意大利面条代码,而是意大利面依赖图。迟早,你失控的依赖关系将意味着单身人士开始依赖彼此,然后在尝试初始化时获得循环依赖关系。他们使单元测试非常困难。(如何测试在单个对象上调用函数的函数?我们不希望运行实际的单例代码,但是我们如何防止这种情况?是的,单身人士很糟糕。有时,你真的想要全球化。然后使用全局而不是单身。有时,非常非常非常罕见,你可能有一种情况,创建一个类的多实例是一个错误,它可以没有导致错误进行。(关于我能想到的唯一一个案例,即使这是设计的,如果你代表一些硬件设备。你只有一个GPU,所以如果你要将它映射到代码中的一个对象,它会理解只有一个实例可以存在)。但是,如果您发现自己处于这种情况(并且再次强调,多个实例导致严重错误的情况,而不仅仅是“我无法想到多个实例的任何用例”),那么执行该约束,但不要使对象全局可见。每个这两个属性可以是有用的,在极少数情况下。但我想不出一个案例,他们的组合将是一件好事。不幸的是,很多人都认为“Singletons是符合OOP标准的全局变种”。不,他们不是。除了介绍其他一些完全不相关的问题之外,他们仍然遇到与全局问题相同的问题。绝对没有理由比普通的全球更喜欢单身人士。

aluckdog

软件开发人员似乎分成两个阵营,这取决于他们是赞成理想主义的编码风格还是实用的编码风格:理想主义:永远不要使用单身模式。务实:避免单身模式。就个人而言,我赞成务实的做法。有时违反规则是有道理的,但前提是你真正了解自己在做什么,并愿意接受相关的风险。如果您对以下关于特定用例的问题回答“是”,则单例模式可以产生一些实际好处。单身是你的应用程序的外部吗?数据库,排队服务和ESB都是单例模式的完全有效的宏示例。KISS:你的整个应用仅限于2-3个内部单身人士吗?DRY:那些单身人士本身是否具有全球性,因此不得不在你的应用程序中几乎每个对象中引用参考文献?(例如,记录器或组件介体)?您的单身人士是否仅依赖于彼此和/或操作环境?您是否确保了每个单例的正确启动和关闭顺序,包括内存管理注意事项?例如,“Grand Central”样式的线程池可能需要在main()中具有实例Run()和Shutdown()方法,以便保证任务仅在它们操作的对象处于有效状态时运行。
打开App,查看更多内容
随时随地看视频慕课网APP
我要回答