0

実装する必要があるデータベース レポートがたくさんあり、今後さらに増える予定です。そのため、拡張可能なコードを構築し、ロジックとコードの重複を避けることに特に関心があります。私はPHPで実装していますが、質問はより一般的です。PHP に加えて、Java、C++、C# などの例を自由に投稿してください。

私が直面している問題は、レポートが非常に異なっているため、SQL を構築するためのすべてのコードを簡単に組み合わせることができないことです。さらに難しいのは、HTML 出力を構築することです。たとえば、あるレポートには長いテキスト メッセージの列が含まれており、マウスオーバーでメッセージ全体が表示されるように CSS スタイルと Javascript を有効にする必要があります。他のレポートには、値がパーセンテージに変換される列、または条件付きで "less" として表示される列があります。 1％未満」であり、「その他」のカテゴリーに蓄積されます。

そこで、戦略パターンを使用することから始めました。私のクラス モデルの非常に単純なスケッチをここで見ることができます: http://static.inky.ws/image/4044/ClassDiagram.png

抽象的なレポートと、各レポート タイプの具体的な実装があります。レポートには、さまざまな SQL ビルダーおよび各レポートの出力データの書式設定のためにカプセル化された機能を (インターフェースの具体的な実装を介して) 参照するいくつかの属性があります。しかし、これはレポートあたりのクラス数が多すぎるように見え始めます。これにアプローチする別のより良い方法はありますか？

上記のモデルを実装するためのコードのスケッチ:

<?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 とデータの書式設定にも抽象クラスが必要であることに気付きました。

4

1 に答える 1