Questions tagged «design-patterns»

设计模式是解决软件设计中常见问题的通用可重用解决方案。

3
在业务层缓存与在数据层缓存
我一直在使用DAL进行缓存的项目中工作,基本上只是在您要对数据库进行调用时,它会检查缓存中是否已经有数据,如果存在,它不会进行调用,并且而是返回该数据。 我最近才读到有关在业务层进行缓存的信息,因此基本上可以缓存整个业务对象。我可以立即看到的一个优势是响应时间更快。 您什么时候比另一个更喜欢?并且在业务层缓存是一种常见的做法吗?

2
MVCS-模型视图控制器存储
我最近决定开始学习iOS开发,为此,我一直在阅读iOS编程:The Big Nerd Ranch Guide。在这本书中,作者描述了一种设计模式MVCS-Model-View-Controller-Store,其基本思想是,由于许多应用程序使用多个外部数据源,因此将请求逻辑保留在控制器中可能会变得非常混乱。建议将所有请求逻辑从控制器中移出并移到单独的对象中。 简而言之,引用这本书 Model-View-Controller-Store将请求逻辑放入一个单独的对象中,我们将此对象称为存储(图28.4)。使用存储对象可以最大程度地减少冗余代码,并简化获取和保存数据的代码。最重要的是,它把处理外部资源的逻辑转移到了一个清晰且目标明确的类中。这使代码更易于理解,也易于维护和调试,并与团队中的其他程序员共享。 和 关于异步存储的一个很酷的事情是,即使很多对象在处理一个请求上做了很多工作,但请求的流及其响应却在控制器中的一个位置。这给我们带来了易于阅读且易于修改的代码的优势。 我想了解更多关于这种模式的信息,并想看看其他人可能要说些什么,但是在网上搜索时,我唯一能找到的参考是同一本书(这种模式也许以其他名字叫吗?)。 在我看来,作者的逻辑似乎很有意义,而且似乎是常规MVC模式的逻辑扩展,但这也许是因为我实际上对MVC模式没有太多的经验(除了涉足iOS开发之外,我还拥有带有骨干 .js的已使用MVV (也就是说,如果您将其视为MVC)。 我希望也许有更多经验的人可以阐明我所缺少的MVCS模式是否存在任何明显的缺陷/问题。


2
在ASP.NET MVC中分离数据访问
我想确保我遵循行业标准和最佳实践,这是我第一次真正接触MVC。在这种情况下,它是使用C#的ASP.NET MVC。 我将对我的模型使用Entity Framework 4.1和代码优先对象(数据库已经存在),因此将有一个DBContext对象用于从数据库中检索数据。 在我在asp.net网站上进行的演示中,控制器中包含数据访问代码。这对我来说似乎不正确,尤其是在遵循DRY(不要重复自己)做法时。 例如,假设我正在编写要在公共图书馆中使用的Web应用程序,并且有一个用于创建,更新和删除目录中书籍的控制器。 某些操作可能需要一个ISBN,并且需要返回“ Book”对象(请注意,这可能不是100%有效的代码): public class BookController : Controller { LibraryDBContext _db = new LibraryDBContext(); public ActionResult Details(String ISBNtoGet) { Book currentBook = _db.Books.Single(b => b.ISBN == ISBNtoGet); return View(currentBook); } public ActionResult Edit(String ISBNtoGet) { Book currentBook = _db.Books.Single(b => b.ISBN == ISBNtoGet); return …


6
是否有适用于折扣模型的设计模式?
有没有实施折扣模型的已知设计模式? 通过折扣模型,我的意思是: 如果客户购买产品X,产品Y和产品Z,则可获得10%或$ 100的折扣。 如果客户购买100个产品X,他将获得15%的折扣或$ 500 如果客户去年带来的收入超过$ 100K,则可获得20%的固定折扣 如果客户购买了2个单位的产品X,则可以免费获得1个单位的产品X(或产品Y)。 ... 是否可以使用一种通用模式来处理所有上述情况?我正在考虑一些模型,但无法遇到通用模型。

2
如何改进Bloch的Builder模式,使其更适合在高度可扩展的类中使用
Joshua Bloch的《 Effective Java》(第二版)对我的影响很大,可能比我所读过的任何编程书都影响更大。特别是他的“建造者模式”(项目2)产生了最大的影响。 尽管Bloch的构建者在几个月内使我比过去十年更深入,但我仍然发现自己碰壁:使用自返回方法链扩展类充其量是令人沮丧的,更糟的是噩梦--especially当仿制药开始发挥作用,并特别与自我参照仿制药(如Comparable<T extends Comparable<T>>)。 我有两个主要需求,在这个问题中,我只想关注其中的第二个需求: 第一个问题是“如何共享自返回方法链,而不必在每个...单个...类中重新实现它们?” 对于那些可能感到好奇的人,我已经在本答案的底部讨论了这一部分,但这不是我想在这里重点讨论的。 我要评论的第二个问题是“如何在自己打算由许多其他类扩展的类中实现构建器?” 与构建者一起扩展课程比没有构建者扩展难度更大。扩展具有构建器的类也很麻烦,Needable因此也具有重要的泛型。 所以这是我的问题:我如何改进(称为)Bloch Builder,这样我就可以随意将构建器附加到任何类上,即使该类是可能成为“基础类”的,扩展和扩展了许多次- 在不影响我的未来自我或我的图书馆用户的情况下,由于构建器(及其潜在的泛型)施加了额外的负担吗? 附录 我的问题集中在上面的第2部分,但是我想详细说明问题一,包括如何处理它: 第一个问题是“如何共享自返回方法链,而不必在每个...单个...类中重新实现它们?” 这并不是要防止扩展类不得不重新实现这些链,当然,它们必须-而是如何防止希望利用这些方法链的非子类重新实现。 -实现每个自返回功能,以便他们的用户能够利用它们?为此,我提出了一个需要需求的设计,我将在此处打印界面框架,并暂时保留该框架。它对我来说效果很好(此设计需要花费数年的时间……最难的部分是避免循环依赖): public interface Chainable { Chainable chainID(boolean b_setStatic, Object o_id); Object getChainID(); Object getStaticChainID(); } public interface Needable<O,R extends Needer> extends Chainable { boolean isAvailableToNeeder(); Needable<O,R> startConfigReturnNeedable(R n_eeder); R getActiveNeeder(); boolean …

4
Model-View-Presenter实现思想
我试图很好地掌握如何在UI和模型之间实现良好的解耦,但是我在弄清楚究竟在哪里划分线时遇到了麻烦。 我一直在研究Model-View-Presenter,但不确定如何实现它。例如,我的视图有多个对话框。 是否应该有一个View类,其中包含每个对话框的实例?那么在这种情况下,对话框应如何与Presenter交互?即。如果单个对话框需要通过Presenter向模型请求数据,该对话框应如何获得对Presenter的引用?通过引用在施工期间提供给它的视图? 我在想也许视图应该是静态类?然后对话框GetView并从那里获取Presenter ... 我一直在考虑将其设置为具有View和Model所有权的Presenter(而不是具有拥有Presenter和Presenter具有Model的View的所有者),并且Presenter在View中注册事件的回调,但这似乎很多耦合性更高(或至少取决于语言)。 我试图: 使它尽可能地分离 理想情况下,可以将Presenter / Model与其他语言的视图结合起来(我还没有做过很多中间语言的工作,但是我知道void(void),至少可以将C#应用程序与C ++库... 保持代码干净简单 所以..有什么建议应该如何处理交互作用?

12
将通用对象存储在容器中然后从容器中获取对象并向下转换对象是否有代码味道?
例如,我有一个游戏,其中有一些工具可以提高玩家的能力: Tool.h class Tool{ public: std::string name; }; 和一些工具: 剑 class Sword : public Tool{ public: Sword(){ this->name="Sword"; } int attack; }; 盾 class Shield : public Tool{ public: Shield(){ this->name="Shield"; } int defense; }; 魔术衣 class MagicCloth : public Tool{ public: MagicCloth(){ this->name="MagicCloth"; } int attack; int defense; }; …

8
如何确定一个班级是否符合单一责任原则?
单一责任原则基于高度凝聚力原则。两者之间的区别在于,具有高度凝聚力的班级具有一系列密切相关的职责,而遵守SRP的班级仅具有一个职责。 但是,我们如何确定某个特定类别是否具有一组职责并因此具有高度凝聚力,或者它是否仅具有一项职责并因此遵守SRP?换句话说,是不是有些主观,因为有些人可能认为一类非常细化(因此相信该类遵循SRP),而另一些人可能认为它不够细密?


2
适配器模式和代理模式之间的区别?
据了解,适配器模式正在为我们感兴趣的实际对象创建一个包装对象,只是一个间接的层次,它提供了灵活性。灵活性在于,如果更改了真实对象的接口,那么我们将更改指向真实对象的包装器接口,而使客户端暴露的接口保持不变。 该代理模式是相同的,与每一个代理包装只提供真实对象的功能一致的子集的区别。当我们努力使“一门课为一个目的”超出我范围时,为什么这会有用。 我正确理解了吗?

11
设计模式通常是造就好坏的力量吗?[关闭]
我听说它辩称,自切面包以来,设计模式是最好的选择。我还听说过有人认为设计模式会加剧“第二系统综合症”,它们被过度使用,并且使用户认为自己是比实际更好的设计师。 我倾向于更接近以前的阵营,但是最近我看到了这样的设计,其中几乎每个交互都被观察者关系所取代,而所有事情都是单例。 那么,考虑到收益和问题,设计模式通常是好是坏,为什么?

6
渐进增强与单页面应用程序
我刚从波士顿的一次会议“ An Event Apart”回来。 演讲者中一个真正流行的主题是渐进增强的想法-网站的内容应以HTML形式出现,而JavaScript仅应用于增强行为。 发言者提出的逐步提高的论点非常有说服力。它不仅是支持旧版浏览器和低带宽网络设备的可靠模式,而且HTML失败的可能性要远远超过JavaScript(例如,不支持的标记会被忽略,而如果浏览器在执行您的浏览器时抛出异常)脚本-您被水喉)。 杰里米·基思(Jeremy Keith)对此进行了特别有见地的演讲。 但是,诸如Backbone和Angular的单页Web应用程序呢?这些框架背后的整个设计似乎促使开发人员将内容移出HTML,并移入JSON API之类的东西。 我似乎无法凝结这两种设计模式:渐进式增强与单页Web应用程序。有没有一种情况比另一种更好?还是它们甚至不是对抗性技术,而我的思维模式却在这里缺失了一些东西?

7
我该如何防止意外地重复代码?
我在相当大的代码库上工作。数百个类,大量不同文件,许多功能,花费15分钟以上的时间才能提取新副本等。 如此庞大的代码库的一个大问题是,它具有相当多的实用程序方法,它们执行相同的操作,或者具有可能时不使用这些实用程序方法的代码。而且,实用程序方法不只是全部在一个类中(因为这将是一个巨大的混乱)。 我对代码库比较陌生,但是多年来致力于该代码工作的团队负责人似乎也遇到了同样的问题。这会导致很多代码和工作重复,因此,当发生问题时,通常会分成4个基本相同的代码副本 我们如何遏制这种模式?与大多数大型项目一样,并非所有代码都已记录在案(尽管有些文件已记录在案),并且并非所有代码都...很整洁。但是从根本上说,如果我们能够在这方面提高质量,那真是​​太好了,这样将来我们就可以减少代码重复,并且更容易发现实用程序之类的东西。 而且,实用程序函数通常在某个静态帮助器类中,在单个对象上工作的某些非静态帮助器类中,或者是主要“帮助”于其上的类的静态方法。 我进行了一个实验,将实用程序功能添加为扩展方法(我不需要该类的任何内部组件,并且肯定只在非常特定的情况下才需要)。这样可以防止主类杂乱无章,但除非您已经知道,否则实际上再也找不到了。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.