标签: anti-patterns

有谁知道重构上帝对象的最佳方法？

它并不像将它分成许多较小的类那样简单,因为有很高的方法耦合.如果我拿出一种方法,我通常会把所有其他方法拉出去.

PHP作为一种钝器

我听说PHP最近遭遇了很多.在很多项目中,我已经看到了疯狂的PHP代码库 - 你真的很想知道这个人在编写代码时是否使用致幻药物.有时,我想知道如果最初的开发人员对不该做的事情有更多的指导,代码会是什么样的.

但是,我也看到了一些非常有条理的PHP项目,这些项目是用100%OOP完成的,并且很乐意维护,但它们不是由"php程序员"编写的.

我给所有初级开发者提供了Java Anti-Patterns的链接.该页面的一个好处是特定于Java的示例,因为Java的许多功能都适用于常见错误.我希望找到一个类似的PHP列表,但谷歌搜索没有透露任何有意义的.

关于编程PHP时开发人员应该知道的问题已经存在一些问题,但我想关注负面问题.

您在PHP中看到的常见问题应该避免哪些常见问题以及以更好的方式执行相同操作的常见解决方案是什么？

我想到的一些明显的例子我会想到,但不是PHP具体的:

• 不要连接SQL.使用准备语句或适当的转义.
• 不要盲目地将PHP嵌入到HTML中 - 使用模板/ MVC.
• 不要盲目发布未经过滤的原始用户输入 - 将其擦除以进行XSS攻击.
• 不要手动尝试解析所有POST和GET - 使用Web框架.

这里有一些我会考虑PHP特定的例子:

• 不要有太多的文件包含/要求链接层,并尽量避免条件链接.相反,有一个合理的命名约定,并与您的组织保持一致.
• 不要使用PHP原始数据库API,除非您可以帮助它,而是使用像ADODB这样的数据库框架.
• 不要过度使用PHP的动态类型,方法是将变量设置为一个地方的字符串,将布尔值设置在其他地方,然后期望布尔测试有意义.

那么,你最喜欢的PHP 不应该做什么,你是如何做到的？

我们都听说过早优化,但您如何看待过早的重构？你认为有这样的事吗？这是我得到的.

首先,阅读Martin Fowler的开创性作品"重构"在字面上改变了我在编程方面的生活.

然而,我注意到的一件事是,如果我开始过快地重构一个类或框架,我有时会发现自己编码到一个角落里就可以说了.现在,我怀疑这个问题本身并不是真正的重构,但可能是过早/糟糕的设计决策/假设.

您对此问题有何看法,见解和/或意见？您对此问题有任何建议或共同的反模式吗？

编辑:

从阅读你的答案和更多地反思这个问题,我想我已经认识到,在这种情况下我的问题实际上是"过早设计"的问题,而不一定是"过早的重构".在编码过程的早期,我一直在设计和重构这个方向.我保持一定程度的设计不可知性并专注于对清洁代码进行重构,这让我有点耐心,这使我无法走下这些设计兔子的道路.

在阅读[关于11000行C++源文件怎么办？]帖子时,我有dejavu的感觉,但我不认为我可以自己开始采取行动,因为我没有权力采取行动.所以我认为第一步是说服组织中的人们认为大块代码是坏的.

我有一个类似的情况,有一个单独的类有11975行代码,每次有新功能,这个类很有可能变得越来越大.

为什么人们使用RMI,或者什么时候应该使用RMI？我在oracle的网站上阅读了关于RMI的那些教程.但它没有提供足够的实际例子.

根据我的理解,软件的模块应尽可能"无关和分离".RMI似乎是一个与我高度耦合的例子.为什么这不是一个糟糕的编码实践？我认为客户端应该只发出指令,而对象的所有实际操作都是由服务器完成的.

(我目前正在攻读计算机科学学士学位并且缺乏经验,所以如果我理解这些概念错误,请纠正我.)

提前致谢!

我在维基百科上找到了关于软编码反模式简洁和令人困惑的条目.什么是软编码？在什么环境下这是一种不好的做法(反模式)？此外,什么时候可以被认为是有益的,如果是的话,应该如何实施？

我最近读了一篇关于" 贫血领域模型模式 "的文章引起了我的注意.当我读完这篇文章时,我发现Anemic Domain Model描述适用于我已经开发和构建的许多项目.我从未认为这是一个糟糕的设计决定,因为它感觉非常自然.我认为,在领域模型重量轻且不是非常复杂的情况下,贫血领域模型的名字非常适合.为什么要增加域模型的复杂性,而不必仅仅因此"Anemic Domain Model"的标题不能恰当地描述您的代码？

问题:在您的服务/应用程序层中填充更多代码复杂性的时间点变得不正确,有利于暴露实体对象的复杂性？我在一个实体上拥有一个"Total"属性,它在内部可以计算出Total的值.我不是让实体直接与各种其他小工具通信,以确定其中一个属性的结果.因此,贫血领域模型的概念是一种反模式还是一种良好的关注点分离？标题贫血领域模型总是一件坏事吗？

只是好奇其他人对这种设计(反)模式的看法.

设计模式何时会使您的软件变得更糟？

我见过一个程序,他们使用GUI和逻辑之间的Facade模式.他们认为没有任何对象可以通过它传输,因此只使用原始类型,这使得编码变得困难.

OO编程中的典型问题是钻石问题.我有父类A,有两个子类B和C.A有一个抽象方法,B和C实现它.现在我有一个子类D,它继承了B 和 C.钻石问题现在,D使用什么实现,B或C之一？

人们声称Java不知道钻石问题.我只能有接口的多重继承,因为它们没有实现,我没有钻石问题.这是真的吗？我不这么认为.见下文:

[删除车辆示例]

钻石问题总是导致糟糕的类设计,也不是程序员和编译器需要解决的问题,因为它首先不应该存在？

更新:也许我的榜样选择不当.

看到这个图像

_{(来源:suffolk.edu)}

当然你可以用C++创建Person虚拟,因此你只有一个人在内存中的实例,但真正的问题仍然存在恕我直言.你如何为GradTeachingFellow实现getDepartment()？考虑一下,他可能是一个系的学生,另一个系教学.所以你可以退回一个部门或另一个部门; 对于这个问题没有完美的解决方案,并且没有实现可以继承(例如学生和教师都可以作为接口)似乎并没有解决问题.

我正在使用jsp/jquery/ejb/jboss开发一个java webapp.

我有一个Web表单,使用户可以从数据库中选择100个字段(所有来自不同的不相关表/对象)的任意组合.然后,这些字段通过java servlet输出到excel电子表格.执行存储过程,始终返回所有100个字段.

Web表单在传输对象(TO)中设置100个布尔值,以确定是否应该显示数据.然后引用该TO以产生电子表格的标题行,并且还产生来自迭代的数据库的每一行.

一切正常,但感觉不对.我想不出一种可行的方法,它不会引用100个布尔值(N + 1次)来确定是否应该在输出的电子表格中包含一个字段.当我说可行时,我的意思是,例如,我不想重写存储过程或创建100个不同的存储过程.