DRY（ドライ）原則

ソフトウェア開発における重要な設計原則の一つ。

DRY原則の考え方

「すべての知識はシステム内で単一、明確、信頼できる表現を持つべき」

同じコードや知識、ロジックをプログラム内で重複させない

ソースコード上で共通化できる部分はできるだけ共通化しましょう

同じことを複数の場所で表現すると、変更時にすべての場所を修正する必要が生じ、修正漏れやバグの原因になる。

なので、↓みたいな事をしてDRY原則を守りましょう。

「プログラム中で繰り返されるコード」はできるだけ関数・メソッドに抽出する

→ DRY原則を守ることで、コードの変更が楽になり、バグも減らせます。

みたいな話です

---

コードの具体例：

悪い例（DRYでない）：

code:python

# ユーザーの年齢確認を複数箇所で繰り返している

if user.age >= 20:

print("お酒を購入できます")

if user.age >= 20:

print("タバコを購入できます")

if user.age >= 20:

print("成人向けコンテンツにアクセスできます")

良い例（DRY）：

code:python

def is_adult(user):

return user.age >= 20

if is_adult(user):

print("お酒を購入できます")

if is_adult(user):

print("タバコを購入できます")

---

DRY原則は重要ですが、「DRYにする」ことを目的にしたりして過度に適用したりすると逆効果になることがあるので、

たまたま似ているだけで、本質的に異なるロジックを無理に共通化するとかえって複雑になってしまったりする

共通化したことの恩恵よりも、その後の「かえって複雑になった共通処理」のメンテナンスが厄介になったりする

共通化されているのでそもそも変更時のリスクが高め（共通箇所の変更は影響範囲が大なので）だったり、いろんな処理を共通化した結果「いろんな場合を想定して、動作を指定するための大量のスイッチを組み合わせて動作を表現して、、」みたいになると、複雑になりすぎてその共通関数のテストが困難になったりするので注意

---

（その他）

意味としては

DRYになっていない ..コードの重複が多いコードを指摘する皮肉的な表現としてよく使われる気がするので「WETなのでダメ」みたいなイメージがあるが、あえて「同じことが2度書いてあったほうが良い」場合もあるのではと思う（読みやすさ的な意味で）