優れた実践における乾燥の原則？

私は、できる限り一生懸命プログラミングのDRY原則に従うようにしています。最近、私はOOPでデザインパターンを学んでいますが、結局、かなりの量を繰り返しています。

永続性を処理するために、FactoryパターンとGatewayパターンとともにRepositoryパターンを作成しました。私はアプリケーションでデータベースを使用していますが、ゲートウェイを交換して、必要に応じて別の種類の永続性に切り替えることができるはずなので、それは問題ではありません。

最終的に自分で作成した問題は、所有しているテーブルの数に対して同じオブジェクトを作成することです。たとえば、これらはテーブルを処理する必要があるオブジェクトになりますcomments。

class Comment extends Model {

    protected $id;
    protected $author;
    protected $text;
    protected $date;
}

class CommentFactory implements iFactory {

    public function createFrom(array $data) {
        return new Comment($data);
    }
}

class CommentGateway implements iGateway {

    protected $db;

    public function __construct(\Database $db) {
        $this->db = $db;
    }

    public function persist($data) {

        if(isset($data['id'])) {
            $sql = 'UPDATE comments SET author = ?, text = ?, date = ? WHERE id = ?';
            $this->db->prepare($sql)->execute($data['author'], $data['text'], $data['date'], $data['id']);
        } else {
            $sql = 'INSERT INTO comments (author, text, date) VALUES (?, ?, ?)';
            $this->db->prepare($sql)->execute($data['author'], $data['text'], $data['date']);
        }
    }

    public function retrieve($id) {

        $sql = 'SELECT * FROM comments WHERE id = ?';
        return $this->db->prepare($sql)->execute($id)->fetch();
    }

    public function delete($id) {

        $sql = 'DELETE FROM comments WHERE id = ?';
        return $this->db->prepare($sql)->execute($id)->fetch();
    }
}

class CommentRepository {

    protected $gateway;
    protected $factory;

    public function __construct(iFactory $f, iGateway $g) {
        $this->gateway = $g;
        $this->factory = $f;
    }

    public function get($id) {

        $data = $this->gateway->retrieve($id);
        return $this->factory->createFrom($data);
    }

    public function add(Comment $comment) {

        $data = $comment->toArray();
        return $this->gateway->persist($data);
    }
}

それから私のコントローラーは

class Comment {

    public function view($id) {

        $gateway = new CommentGateway(Database::connection());
        $factory = new CommentFactory();
        $repo = new CommentRepository($factory, $gateway);

        return Response::view('comment/view', $repo->get($id));
    }
}

だから、私はデザインパターンを正しく使用し、良い慣行を守っていると思ったが、このことの問題は、新しいテーブルを追加するときに、他の名前だけで同じクラスを作成しなければならないことだ。これは、私が何か間違ったことをしているのではないかという疑念を引き起こします。

インターフェイスの代わりに、クラス名を使用して操作する必要があるテーブルを把握する抽象クラスがありますが、それは正しいことではないようです、ファイルストレージに切り替えるか、テーブルがないmemcache。

私はこれに正しく近づいていますか、または私が見なければならない別の視点がありますか？

あなたが取り組んでいる問題は非常に基本的です。

数百のWebページと100万行以上のJavaコードで構成される大規模なJ2EEアプリケーションを作成した会社で働いていたときに、同じ問題を経験しました。このコードは永続化のためにORM（JPA）を使用しました。

この問題は、アーキテクチャのすべてのレイヤーでサードパーティのテクノロジーを使用している場合に悪化し、テクノロジーはすべて独自のデータ表現を必要とします。

使用しているプログラミング言語のレベルでは問題を解決できません。パターンを使用するのは良いことですが、ご覧のとおり、コードの繰り返しを引き起こします（より正確には、デザインの繰り返し）。

私の考えでは、考えられる解決策は3つしかありません。実際には、これらのソリューションは同じものになります。

解決策1：永続化する必要があるものだけを記述できる他の永続化フレームワークを使用します。おそらくそのようなフレームワークがあります。このアプローチの問題は、パターンがすべて永続性に関連するとは限らないため、かなり単純だということです。また、ユーザーインターフェイスコードのパターンを使用するため、選択した永続化フレームワークのデータ表現を再利用できるGUIフレームワークが必要になります。それらを再利用できない場合は、GUIフレームワークと永続化フレームワークのデータ表現を橋渡しするボイラープレートコードを記述する必要があります。これはDRYの原則に反しています。

解決策2：設計コードを再利用できるように、反復設計を表現できる構造を持つ、より強力な別のプログラミング言語を使用します。これはおそらくあなたのためのオプションではありませんが、しばらくの間はそうだと思います。再度、永続化レイヤーの上にユーザーインターフェイスの作成を開始すると、ボイラープレートコードを作成せずにGUIの作成をサポートするのに十分に強力な言語が再び必要になります。ほとんどの言語は、それぞれが独自のデータ表現を必要とするGUI構築のためにサードパーティのフレームワークに依存しているため、希望することを実行できるほど強力な言語があるとは考えられません。

解決策3：何らかの形式のコード生成を使用して、コードと設計の繰り返しを自動化します。繰り返しコード/デザインを手作業でコーディングするとDRYの原則に違反するため、パターンとデザインの繰り返しを手作業でコーディングする必要があります。現在、非常に強力なコード生成フレームワークが世に出ています。独自のプログラミング言語を作成し（経験のない半日）、その言語を使用してコード（PHP / Java / SQL-考えられるテキストファイル）を生成できる「言語ワークベンチ」もあります。私はXTextの経験がありますが、MetaEditとMPSも同様にうまくいくようです。これらの言語ワークベンチのいずれかを確認することを強くお勧めします。私にとって、それは私の職業人生で最も解放的な経験でした。

Xtextを使用すると、マシンに反復コードを生成させることができます。Xtextは、独自の言語仕様のコード補完機能を備えた構文強調エディターも生成します。その時点から、ゲートウェイとファクトリクラスを取得し、それらに穴を開けてコードテンプレートに変換します。それらをジェネレーター（Xtextによって完全に生成される言語のパーサーによって呼び出されます）にフィードすると、ジェネレーターがテンプレートの穴を埋めます。結果は生成されたコードです。その時点から、どこでもコードの繰り返しを取り出すことができます（GUIコード永続化コードなど）。

直面している問題は古いものです。永続オブジェクトのコードは、各クラスでよく似ていることが多く、単なる定型コードです。それが、一部の賢い人々がオブジェクトリレーショナルマッパーを発明した理由です。彼らはまさにその問題を解決します。PHPのORMのリストについては、この以前のSO投稿を参照してください。

既存のORMがニーズに合わない場合は、別の方法もあります。独自のコードジェネレーターを作成して、オブジェクトのメタ記述を保持し、そこからコードの繰り返し部分を生成できます。これは実際にはそれほど難しくありません。過去にいくつかの異なるプログラミング言語でこれを行ったことがあります。そのようなことをPHPでも実装することもできると確信しています。