“过于面向对象”

我具有强大的OO背景，并且我最近开始在一个组织中工作，尽管该代码是用Java编写的，但与过去相比，我对良好的OO设计的重视程度要低得多。有人告诉我，我引入了“太多的抽象”，而我应该以一直采用的方式编写代码，这是Java中的一种过程样式。

TDD在这里也不太常用，但是我想拥有可测试的代码。在大型“神类”（这似乎是该团队的常态）中以静态私有方法掩埋业务逻辑不是很可测试的。

我很难向同事清楚地传达自己的动力。有谁对我如何说服我的同事使用OO和TDD导致更容易维护的代码有任何建议？

这个问题有关技术债务是关系到我的问题。但是，我试图避免首先产生债务，而不是在另一个问题所涵盖的事实之后偿还债务。

您并没有抱怨它无法维护，只是不喜欢您。如果这是故意选择的样式，则可能只是创意差异不可调和，您应该调整样式以适合自己，或在某个地方找到适合自己偏好的样式。

人们可以并且确实始终以程序方式编写模块化，高效，抽象性强，相对无缺陷的代码。对于这样的商店来说，Java是一种奇怪的语言选择，但是我可以看到，如果外部因素决定了这种语言，比如说需要为Android开发，它就会发生。

每个人都是天才。但是，如果您通过鱼类爬树的能力来判断它，那么它会终生相信它是愚蠢的。- 艾尔伯特爱因斯坦

如果这是一个故意的选择，则不能真正通过它们遵循良好的面向对象设计原则的程度来真正地判断它们，应该通过它们遵循良好的过程设计原则的表现程度来进行判断，并相应地进行重构。Java不允许您在类之外编写代码，因此仅存在一个类并不意味着他们打算使模块成为面向对象的。

另一方面，如果代码在任何一个范例中都是一团糟，那么您可能应该减少损失。

在阅读您的问题时，我想起了《实用程序员》一书的一个技巧。

其提示之一是Be a Catalyst for Change：

您可能处在确切知道需要做什么以及如何做的情况。整个系统只是出现在您的眼前-您知道这是正确的。但是，请允许您解决整个问题，您会遇到延误和茫然的表情。人们将组成委员会，预算将需要批准，而且事情将会变得复杂。每个人都将保护自己的资源。有时这被称为“启动疲劳”。

是时候煮石汤了。算出您可以合理要求的东西。好好发展。掌握之后，向人们展示，让他们惊叹不已。然后说：“当然，如果我们添加……会更好。” 假装这并不重要。请坐下，等待他们开始要求您添加最初想要的功能。人们发现更容易加入持续的成功。向他们展示未来，您将使他们团结起来。

因此，我认为，如果您开始凭借自己的OO和TDD知识做好工作，那么他们很快就会开始寻找并询问您的工作。

要销售新的工作方式，您需要显示出明显的好处。编写更多的抽象层，没有明显的好处，但却含糊其词：“对将来可能是有益的”是行不通的。

在工厂制造的地方制造一种以上类型的物体。使用依赖注入，它立即显示出好处。制作实际上将由一个以上类实现的接口。

我在“真正的面向对象”中经常看到的是，先进的技术被用来以过于复杂的方式解决非常简单的问题。

如果工厂只会制造相同的对象，那么如何显示工厂的好处？在代码中找到一个可以从高级技术中受益的问题，并从中显示您的观点和工作。

战争一次赢得一场战斗。

您只能说服一小段代码，并在其上实现TDD和更好的OO实践以实现收益，才能说服他们。您已经将他们带到了应许之地，而不仅仅是显示漂亮的明信片。

当然，我认为当今许多代码库中都存在过度抽象的情况。仅放入您需要的内容，其中还包括抽象。