DRY

「Don't Repeat Your Self」の略で、「繰り返しをしない」という意味である。

つまりは、流用できるものは流用し、
ムダをなくそうというコーディングにおける原則である。

「Once and Only Once(OAOO)」と目的は似ているようだが、
OAOOはコード単位での重複を防ぎ、
「DRY」はオブジェクト単位での重複を防ぐものと考えるとよい。

しかし、この原則は正しく守れば有用であるが、
誤った認識で行えば、とんでもないものが出来上がることがある。

作業の重複は自動で防げない

DRYの原則を守れば、自動的にキレイなコードが出来上がるとは、思わないほうがいい。
この原則の目的を把握もせず、以下の行為を行うのであれば、
それはかえって、難解なコードを生み出す元となる。

ロジックの重複は抽象化で防げない

とにかく各クラスやメソッドを抽象クラス※1や抽象メソッド※2にして、
ありとあらゆるメソッドを継承させるような構造は、やめておいたほうがいい。

各クラスやメソッドを、継承させて連結していけば、
今までに作成した要素にもアクセスでき、流用可能になるかもしれないが、
単に継承させる事を強制しているだけでは、なんの意味もない。

むしろ、使わないコードやファイルも読み込む事になり、
コードを書く側からすれば、抽象化された要素が把握できなければ、
そもそも継承するべき要素を作れずに開発に着手できなくなるか、
空メソッドを用意して、回避されるだけである。

※1 抽象クラス:継承を前提とされたクラス。
このクラスを直にオブジェクト化する事はできず、
このクラスを継承したクラスをオブジェクト化して使用する必要がある。

※2 抽象メソッド:継承元のクラスに、このメソッドが存在しなければいけない
つまり、このメソッドと同名のメソッドが継承元に存在していなければ、エラーとなる。

だが処理の重複は行う

「コードの重複は行わない」というルールの元、
同じ要素を何度も使いまわすのは、たしかによいのだが・・・

もしそれが、1レコードを取得するSQL文であった場合、
もしそれを繰り返し処理を行うと、
データベースに多大な負荷を与える原因となる
そのような場合は、そのSQL文を複数レコード取得するよう改造し、
汎用性を上げるのが適切である。
それが難しければ、いっそ重複になってDRY原則を破る事になっても、
新たな要素を作るべき
である。

まとめ

DRYは、本来の目的を忘れ、定められたルールを守るだけでは、
とんでもない事になる危険性もはらんでいる。

DRYを含め、原則が目的とするのは、いかに効率のよいものを作れるかである。
DRYの場合は、「繰り返しを避ける」事に目的があり、
その過程である「抽象化」に目が行き、処理が重くなったり、
人が開発に着手できなくなる環境を作ってしまえば、本末転倒である。

大切な事は、原則のルールを守ることよりも、
原則が目的としている事を守るべきである。

また、本当に重複を避けるには、
作られた要素が、各開発者に正しく認識できるよう、
仕様書などを作成する事である

そもそも重複が発生するのは、既存要素が理解できず、
またはその要素に気づかず、同じ機能を持つ別要素を新たに作成される、
「車輪の再発明」が発生してしまうからである。

まずは「DRY」を考慮する前に、
「車輪の再発明」を考慮したほうがいいだろう。

なによりも、自動的に防ぐという考え方自体、捨てるべきだろう。
何事も、知らないうちに出来ていればいいというものではなく、
それぞれが意識を持って取り組まなければ、質の高い物は生まれない。