Questions tagged «design-patterns»

设计模式是解决软件设计中常见问题的通用可重用解决方案。当您对设计模式的实现有疑问时,请使用此标签来提问。请不要在有关文本模式匹配的问题上使用此标签。当在实现上遇到重磅问题时使用此标记-标记实现所使用的代码语言。


8
介体与观察者的面向对象设计模式
为了解决我的一些问题,我一直在阅读《四人帮》,并遇到了Mediator模式。 我之前在项目中使用Observer来制作一些GUI应用程序。我有点困惑,因为我发现两者之间没有太大区别。我浏览找到了区别,但没有找到适合我的查询的答案。 有人可以帮我用一个很好的例子来区分两者吗?

4
C的设计原理,最佳实践和设计模式(或一般而言,过程编程)?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 改善这个问题 在设计C项目时,可以遵循哪些已知的设计原则,最佳实践和设计模式?还是总体上对过程式(命令式)编程有用的设计原则? (我是“面向对象的一代”的孩子,必须第一次设计一个大型的C项目)

16
GOF Singleton模式是否有可行的替代方案?
面对现实吧。Singleton模式是高度争议与成群程序员话题都围栏边。有些人觉得Singleton只是荣耀的全局变量,而其他人则按模式发誓并不断使用它。但是,我不想让“ 单例论战 ”成为我问题的核心。 每个人都可以进行拔河比赛并与之抗衡,看看谁在我所关心的范围内获胜。我要说的是,我不相信有一个正确的答案,而且我并不是故意在煽动党派争吵。当我问这个问题时,我只是对单例替代方案感兴趣: 它们是GOF单例模式的任何特定替代方案吗? 例如,过去很多次使用单例模式时,我只是对保留一个或几个变量的状态/值感兴趣。但是,可以在类的每个实例之间使用静态变量而不是使用单例模式来保留变量的状态/值。 您还有什么其他想法? 编辑: 我真的不希望这是关于“如何正确使用单例”的另一篇文章。同样,我正在寻找避免这种情况的方法。好玩吗 我想我是在用最好的电影预告片声音问一个纯粹的学术问题:“在没有单例的平行宇宙中,我们能做什么?”

5
如果Singletons不好,那么服务容器为什么好?
我们都知道单身人士是多么糟糕,因为它们隐藏了依赖以及其他原因。 但是在一个框架中,可能有许多对象仅需要实例化一次,并可以从任何地方调用(记录器,数据库等)。 为了解决这个问题,我被告知要使用所谓的“对象管理器”(或类似symfony的服务容器)在内部存储对服务(记录器等)的所有引用。 但是,为什么服务提供者不像单纯的Singleton那样糟糕? 服务提供者也隐藏了依赖关系,他们只是包装了第一个实例的创建。因此,我真的很难理解为什么我们应该使用服务提供商而不是单例。 PS。我知道不隐藏依赖项应该使用DI(如Misko所述) 加 我会补充:现在,单例并没有那么邪恶,PHPUnit的创建者在这里解释了这一点: http://sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html DI + Singleton解决了以下问题: <?php class Client { public function doSomething(Singleton $singleton = NULL){ if ($singleton === NULL) { $singleton = Singleton::getInstance(); } // ... } } ?> 即使这不能解决所有问题,这还是很聪明的。 除了DI和Service Container 之外,还有什么好的可接受的解决方案来访问此帮助对象?

3
胖模型和瘦控制器听起来像是在创建上帝模型。
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意测验或进一步的讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 7年前关闭。 我读过很多博客,这些博客提倡胖模型和瘦控制器方法,尤其是。Rails阵营。结果,路由器基本上只是想找出要在哪个控制器上调用的方法,而所有控制器方法都需要在模型上调用相应的方法,然后调出视图。所以我在这里有两个我不明白的问题: 除了仅基于路由在类似于上帝的模型上调用方法外,控制器和路由器实际上并没有执行很多不同的任务。 模型做得太多了。发送电子邮件,创建关系,删除和修改其他模型,排队任务等。基本上,现在您有了像神一样的对象,它们应该执行与建模和数据处理有关或不涉及的一切事情。 您在哪里划界线?这不只是落入上帝的榜样吗?


9
返回ImmutableMap还是Map更好?
假设我正在写一个应该返回Map的方法。例如: public Map<String, Integer> foo() { return new HashMap<String, Integer>(); } 考虑了一段时间后,我决定创建该地图后就没有理由对其进行修改。因此,我想返回一个ImmutableMap。 public Map<String, Integer> foo() { return ImmutableMap.of(); } 我应该将返回类型保留为通用Map,还是应该指定要返回ImmutableMap? 从一方面来说,这正是创建接口的原因。隐藏实施细节。 另一方面,如果我这样保留它,其他开发人员可能会错过这个对象是不可变的事实。因此,我不会实现不可变对象的主要目标。通过最小化可以更改的对象数量来使代码更清晰。更糟糕的是,过了一会儿,有人可能会尝试更改此对象,这将导致运行时错误(编译器不会对此发出警告)。

3
WinForms中的Model-View-Presenter
我正在尝试使用WinForms首次实现MVP方法。 我试图了解每一层的功能。 在我的程序中,我有一个GUI按钮,单击该按钮会打开一个openfiledialog窗口。 因此,使用MVP,GUI会处理按钮单击事件,然后调用presenter.openfile();。 在presenter.openfile()中,然后应该将该文件的打开委托给模型层,还是由于没有要处理的数据或逻辑,它是否应仅对请求采取行动并打开openfile对话窗口? 更新: 我决定提供赏金,因为我认为我需要对此提供进一步的帮助,并且最好针对我在下面的特定要点进行调整,以便获得背景信息。 好的,在阅读了MVP之后,我决定实现被动视图。实际上,我将在Winform上具有一堆控件,这些控件将由Presenter处理,然后将任务委派给模型。我的具体观点如下: 当winform加载时,它必须获取树视图。我是否正确认为该视图因此应调用诸如presenter.gettree()之类的方法,而该方法又将委托给模型,该模型将获取树视图的数据,对其进行创建和配置,然后将其返回给演示者,该演示者又将转到视图,然后将其简单地分配给一个面板? Winform上的任何数据控件都一样吗,因为我也有一个datagridview? 我的应用程序具有许多具有相同装配的模型类。它还支持插件体系结构,其中的插件需要在启动时加载。视图是否会简单地调用presenter方法,而该方法又会调用加载插件并在视图中显示信息的方法?哪一层将控制插件引用。视图将保留对它们或演示者的引用吗? 我是否认为视图应该处理与表示有关的所有事情,从树视图节点的颜色到数据网格大小等,是否正确? 我认为这是我最关心的问题,如果我了解这些工作的流程,我会没事的。

16
tar:将所有文件和目录添加到当前目录中,包括.svn等
我尝试在tar.gz目录中使用 tar -czf workspace.tar.gz * 生成的tar包含.svn子目录中的目录,但不包含当前目录中的目录(因为*在传递给tar之前已扩展为仅“可见”文件 我尝试过了 tar -czf workspace.tar.gz .相反,但是然后我得到一个错误,因为“。” 阅读时发生了变化: tar: ./workspace.tar.gz: file changed as we read it 有没有技巧可以*匹配目录中的所有文件(包括点缀)? (在Linux SLES-11(2.6.27.19)上使用bash

7
依赖注入和单例设计模式
我们如何确定何时使用依赖注入或单例模式。我在许多网站上都读过,他们说“对单例模式使用依赖注入”。但是我不确定我是否完全同意他们的观点。对于我的中小型项目,我肯定看到单例模式的使用很简单。 例如记录器。我可以使用Logger.GetInstance().Log(...) But,而不是使用它,为什么我需要使用记录器的实例注入我创建的每个类?

2
“反应器模式”及其应用的简单说明
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 改善这个问题 Wikipedia中对Reactor模式进行了说明,它有点抽象。您可以更具体地描述这种模式吗?理想情况下,使用代码片段或描述反应堆模式某些应用程序的高级类图。

14
Java中的抽象类与接口
我被问到一个问题,我想在这里让我的答案复习。 问:在哪种情况下,扩展抽象类而不是实现接口更合适? 答:如果我们使用模板方法设计模式。 我对么 ? 很抱歉,如果我不能清楚地说明问题。 我知道抽象类和接口之间的基本区别。 1)当需要满足以下条件时使用抽象类:对于特定操作(实现方法),我们需要在每个子类中实现相同的功能,而对于某些其他操作(仅方法签名),则需要实现不同的功能 2)如果需要使签名相同(并且实现不同),请使用接口,以便可以遵循接口实现 3)我们可以扩展一个抽象类的最大值,但是可以实现多个接口 重申一个问题:除了上述提到的情况之外,还有其他情况需要专门使用抽象类吗(可以看到模板方法设计模式仅在概念上基于此)? 接口与抽象类 在这两者之间进行选择确实取决于您要做什么,但幸运的是,对于我们来说,Erich Gamma可以为我们提供一些帮助。 一如既往地需要权衡取舍,接口为您提供了关于基类的自由,抽象类为您提供了以后添加新方法的自由。–埃里希·伽玛(Erich Gamma) 您不能去更改接口而不必更改代码中的许多其他内容,因此避免这种情况的唯一方法是创建一个全新的接口,这不一定总是一件好事。 Abstract classes应该主要用于紧密相关的对象。Interfaces擅长为不相关的类提供通用功能。

5
访客模式中的accept()方法有什么意义?
关于将算法与类分离的讨论很多。但是,一件事搁置不明。 他们这样使用访客 abstract class Expr { public <T> T accept(Visitor<T> visitor) {visitor.visit(this);} } class ExprVisitor extends Visitor{ public Integer visit(Num num) { return num.value; } public Integer visit(Sum sum) { return sum.getLeft().accept(this) + sum.getRight().accept(this); } public Integer visit(Prod prod) { return prod.getLeft().accept(this) * prod.getRight().accept(this); } 访问者不是直接调用visit(element),而是要求元素调用其visit方法。它与已宣布的关于访客的阶级不了解的思想相矛盾。 PS1请用您自己的文字解释或指向确切的解释。因为我得到的两个回答是关于一般性和不确定性的。 PS2我的猜测:由于getLeft()返回basic Expression,因此调用visit(getLeft())将导致visit(Expression),而getLeft()调用visit(this)将导致另一个更合适的访问调用。因此,accept()执行类型转换(aka转换)。 PS3 …

4
MVC应用程序在哪里适合“业务逻辑层”?
首先,在有人大声疾呼之前,我很难用一个简单的标题来概括它。另一个标题可能是“域模型和MVC模型之间有什么区别?” 或“什么是模型?” 从概念上讲,我将模型理解为视图和控制器使用的数据。除此之外,对于构成模型的原因似乎有很多不同的意见。什么是领域模型,应用程序模型,视图模型,服务模型等。 例如,在我最近询问存储库模式的问题中,有人告诉我空白是存储库是模型的一部分。但是,我还读过其他意见,认为该模型应与持久性模型和业务逻辑层分开。毕竟,存储库模式是否不应该将具体的持久性方法与模型分离?其他人说,域模型和MVC模型之间是有区别的。 让我们举一个简单的例子。MVC默认项目中包含的AccountController。我已经读过一些意见,认为其中包含的帐户代码设计不佳,违反了SRP等。如果要为MVC应用程序设计“适当的”成员资格模型,那将是什么? 您如何将ASP.NET服务(成员资格提供程序,角色提供程序等)与模型分开?还是你会吗? 从我的角度来看,模型应该是“纯”的,也许带有验证逻辑..但是应该与业务规则(除了验证)分开。例如,假设您有一条业务规则,该规则规定在创建新帐户时必须向某人发送电子邮件。在我看来,这并不真正属于模型。那么它属于哪儿呢? 有人在乎这个问题吗?

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.