最不喜欢的设计模式

时间:2008-09-26 13:07:44

标签: design-patterns

好吧,我不是在寻找反模式 - 我正在寻找那些不是模式的东西,或者是那些被滥用的模式。

我个人最不喜欢的是“助手”模式。

E.g。我需要创建一个SQL查询,所以调用SQLQueryHelper。这需要处理一些字符串,因此它又调用StringHelper。等等。

请参阅 - 这根本不是一种设计模式......

[编辑] 投票给你的人不是认为你应该添加一个建设性的评论吗?

6 个答案:

答案 0 :(得分:25)

单件。

它是伪装的全局变量,难以模拟/存根进行单元测试。

服务定位器更好,依赖注入/控制反转仍然更好。

wikipedia article上的大多数参考资料都是为什么它是邪恶的。

答案 1 :(得分:11)

'经理'课程。 e.g。

DataManager
BusinessLogicManager
WidgetManager

“经理”的意思是什么?更加详细一些!如果您的WidgetManager具有如此多的Widget职责,那么没有更具体的名称,那么将其分解。

这是我在查看旧代码时与自己进行了太多次的对话。

答案 2 :(得分:5)

我认为不应盲目使用设计模式,仅仅因为它很酷而实施它们:它们有明确的上下文,并在适当的时候使用它们可能有帮助,但在任何其他情况下它们只是浪费时间,当不妨碍正确的系统运作时。

答案 3 :(得分:4)

我最不喜欢的是“把'助手'或'经理'放在班级名称”模式的末尾。

编辑:我已经证明了我是一个蹩脚的程序员,克里斯指出,忘记了“Util”。

答案 4 :(得分:2)

<强>策略

原因是我怀疑大多数人都被教导使用类和方法来实现它。

考虑以下Haskell代码:

ascending = sortBy compare somelist
descending = sortBy (flip compare) somelist
pairsBySecondComponent = sortBy (comparing snd) somelist

这就是战略模式:compare(flip compare)(comparing snd)是这种情况下的具体策略(它们是普通的旧函数),以及函数签名{{1战略“界面”。

这简洁说明设计模式不必如此重量级或笨重。您希望在Java(接口,类)中实现策略的方式是一种好方法。这是一种围绕Java工作的方式,为您需要做的工作提供错误的抽象。这应该被认为是正常的或可接受的。

因此,假设我对其教授方式的假设是正确的,我不太喜欢策略模式。

还有一些其他模式也是一般“功能指针”模式的特定实例。出于同样的原因,我也不太喜欢它们。

答案 5 :(得分:1)

MVP。它是MVC但是坏了。

哦,不,等等,开发一个应用程序完全不同于遵循良好的做法,例如“这只是一个观点”。

<强>更新

我从“实用程序员”一书中引用“它只是一个观点”。我的主要问题是几乎每一个MVP实现都有视图保持演示者并告诉演示者做事情。这在概念上是倒退的。 UI不应该依赖逻辑。这只是一种观点。逻辑是应用程序的主要原因,如何显示该逻辑是次要问题。我可以使用一个winform,或者我可以使用很多。天啊,我可以把整个事情都输入到ASCII文本中,或者通过在艺术家身上发送电荷来创建“视图”,该艺术家通过插图舞蹈的媒介渲染视图。

实际上,这个前提确实有一些可行的用途。我过去编写的一些控制器具有许多外部暴露的视图,可以在应用程序认为合适时将其推送到UI中。考虑实时数据馈送。我可以将其显示为统计数据,如线图,如饼图。也许所有人都在同一时间!然后保持控制器的视图看起来有点傻,父级是控制器,子级是视图。

传统(表格持有演示者)MVP实施还有其他后果。一个是你的UI现在依赖于执行逻辑的代码,这意味着它还需要引用逻辑需要的所有东西(服务等)。

解决这个问题的方法是传入一个接口(同样,我看到的大多数MVP实现都有创建演示者的表单,但是嘿)。然后它变成了一个可行的模型,虽然我从未成为将args传递给表单构造函数的粉丝。

在一天结束时,感觉就像人们在试图证明一个破碎的模型是合理的。我个人认为MVP模式纯粹是为了合理化Visual Studio Windows Forms应用程序的工作方式而存在。他们从“形式第一”的心态开始。

“噢,这是你的表格,现在就把你的控件和逻辑放到用户界面中”

任何具有超出工具的应用程序经验的人都会意识到这种工作方式无法扩展。我认为MVP是实现这种规模的一种方式,但这只是一种围绕IDE推动的破碎的“形式优先”开发模式的架构乐队助手。

我认为MVC只是MVC,MVP是模式的混蛋。事实上,MVC的整个定义有点倒退。其中重要的部分是关注点的分离。您正在使用的UI,逻辑,数据和/或服务。保持这些分开。您没有实现MVC来执行此操作,您执行此操作并通过这样做最终得到一种MVC 形式。 MVP并不适合这个,因为如果你开始考虑分离关注你最终得到MVP,如果你被困在“Form First”的土地并且你觉得你应该做的事情更多MVCish。

无论如何,这是我对它的看法......