我注意到，过去几年我所使用的大多数企业网络应用程序似乎都错误地使用了oo的功能。
也就是说，曾经可能有1000行HTML和脚本，现在经常变成10,000行代码，50个类和2000个方法调用，基本上做同样的事情。即oo和分层架构似乎过度使用和/或使用不当，往往导致更长的开发时间，更高的成本，并且通常是噩梦般的维护。
其他人看到这种情况多久发生一次？
如何有效地利用oo，正如佛陀自己所说：尽量尽量不要伤害......尽量尽量帮助......
答案 0 :(得分：1)
我一直看到这些:(基本上如果人们要弄得一团糟，他们会尝试或不使用oo设计。在任何一种情况下都会同样糟糕。
更新1：重要的是要了解如何/将会重复使用（但不要因为这会妨碍生产力而疯狂），因为我们不想让大量课程在哪里它们中的每一个都不会被重复使用，并且可以完成大量不同的功能。
基本上主要的问题是理解和关心正在构建的内容，因为你可以应用oo，tdd，ddd，任何东西，如果开发人员不理解他们正在做什么，它将最终陷入同样的混乱。 ..或最坏的:(
总的来说，这些事情确实有所帮助，但它们并不神奇，它们不会取代开发人员的技能来创建可维护的代码。
更新2：另请注意，核对表或某些项目符号不会执行此操作。我的意思是我喜欢SOLID，并且还有很多事情要发生，我认为它们确实很清楚，但它们通常会对那些试图避免混乱的人产生最大的影响。
答案 1 :(得分：1)
“通往地狱的道路铺满了最好的意图。”
我自己并没有亲自遇到这个问题，但是我一直听到这些故事似乎是architecture astronauts（花费太多时间思考的人）或糟糕的开发者（也是花钱的人）的问题很少时间思考）。
在编程的早期阶段，由于硬件，语言等的限制，你没有看到这么多。
然而，开发人员现在正在努力专注于编写人类可以理解的松散耦合和更高可维护性的代码，通过尽可能多地结合设计模式和OO原则，但就像它可以完成的一切一样。 / p>
另一方面，一些开发人员可能只是没有充分思考他们试图解决的问题并编写额外的代码只是因为它完成了工作而没有考虑更大的图景。
在任何一种情况下，开发人员可能都不是恶意的，甚至不称职，并且希望他们所从事的项目最好，但他们仍然只是因为他们太努力而过度执行原则。
所以我想说解决方案是提醒开发人员使用OOP原则作为指导，但就是这样。有一点，你必须在思考和编程之间找到一个愉快的媒介，然后停止思考并开始编程。
请参阅：杰夫写了一篇关于这类事情的好文章：KISS and YAGNI。