Java 建议使用简洁的类模型/模式来解决方法中的多个微小变化

我有一大堆需要实现的数据库报告，将来还会有更多，所以我对构建可扩展代码和避免重复的逻辑和代码特别感兴趣。我是用PHP实现的，但问题更一般。除了PHP，可以自由地在爪哇、C++、C等中发布例子。 我面临的问题是，这些报告的差异太大，我无法轻松地组合所有用于构建SQL的代码，更难的是，构建HTML输出。例如，一个报表包含一列长文本消息，需要使用CSS样式并启用Javascript才能使鼠标指针显示整个消息，而其他报表则包含将值转换为百分比的列，或有条件地显示为“小于1%”并累积到“其他”类别中

所以我开始使用策略模式。我的班级模型的一个非常简单的草图可以在这里看到：

我有一个抽象报告，每个报告类型都有一个具体的实现。报表有两个属性，它们引用封装的功能（通过接口的具体实现），用于不同的SQL builder和每个报表的输出数据格式。但这看起来好像每个报告都有太多的类。还有其他更好的方法吗

实现上述模型的代码草图：

<?php
abstract class Report {
   private $sqlBuilder = null;
   private $dataFormatter = null;
}

class ReportOne extends Report {
   public function __constructor() {
       $this->sqlBuilder = new ReportOneSqlBuilder();
       $this->dataFormatter = new ReportOneDataFormatter();
}
class ReportTwo extends Report {
   // similar to ReportOne
}

interface SqlBuilder {
}
class ReportOneSqlBuilder implements SqlBuilder {
}
class ReportTwoSqlBuilder implements SqlBuilder {
}

interface DataFormatter {
}
class ReportOneDataFormatter {
}
class ReportTwoDataFormatter {
}
?>

---

其思想是将所有公共代码保留在抽象类中，并在各种具体子类中保留特定的差异。写这篇文章时，我突然想到，我也需要用于SQL和数据格式化的抽象类，因为接口不能真正承载任何实现细节。

有时最好保持两个类似但有重要区别的东西，完全分开，即使这不利于实现（不要重复）原则

事实上，这样做有很好的理由。重要的是，如果您试图重用代码的某些部分，并且以后需要修改一些只会影响其中一个报告的内容，那么无论如何您都必须破坏该常见代码

设计模式很可爱，当然也有其用途，但是，在某些情况下，最好使用可能部分重复自身的不同逻辑，并使代码尽可能简单。比DRY更重要的是代码可读性，如果您为一个真正不需要复杂的功能使代码复杂化，您将几乎毫无收获地损害你的可读性

---

如果您真的认为这两个报告有很强的相似性，并且值得将您的应用程序复杂化，或者如果您这样做是为了练习您的设计模式实现技能，那么就去做吧。如果您只是想高效地完成工作并使您的应用程序易于以后修改，只需保持简单并使用两种不同的逻辑即可

很好的观点，这正是我正在努力解决的问题。可能90%到95%的代码在我现有的3个报告中被复制。我可能需要在不久的将来添加第四个。因此我希望保持干燥。：-）如果真的有90%到95%的代码被复制，那么它是值得修复的。虽然很难在没有上下文的情况下帮助您进行设计。我如何帮助您提供所需的上下文？你想知道或看到什么？