OAOO信仰からの棄教
こんにちは、K.Hです。
かつて私は、OAOO原則を絶対的な真理として信じ、我々を美しいコードへと導いていただけると信じて疑いませんでした。
そんな私が研修を通してその信仰を見直すに至った経緯を記します。
OAOOとは
OAOOとは「Once And Only Once」の略称で、要約すると同じコードを書くなという意味になります。
同じ処理を関数やクラスとしてまとめる、定数や定義を外部ファイルにまとめるといった他、マジックナンバーを定数として定義することもOAOO原則に基づいています。
例: 税率を加算する処置
リファクタリング前
applePriceWithTax = applePrice * 1.1; orangePriceWithTax = applePrice * 1.1; grapePriceWithTax = applePrice * 1.1;
リファクタリング後(OAOO適用)
double calculatePriceTax(double price){
const double tax = 1.1;
return price * tax;
}
applePriceWithTax = calculatePriceTax(applePrice);
orangePriceWithTax = calculatePriceTax(orangePrice);
grapePriceWithTax = calculatePriceTax(grapePrice);
税金が15%に変更された場合、OAOO原則が考慮されていないコードでは税金の値を1.1から1.15に変更するといった同じ変更を何度も行う必要があるのに対し、リファクタリング後のコードは変更が1度で済みます。
メリット
- コードを変更する際、変更箇所が1か所になる
- コードの可読性が向上する
- 重複による記述ミスが発生しにくい
DRY原則
類似しているものにDRY原則があります。
DRY原則とは「Don't Repeat Yourself」の略称で、知識の重複を許さないという意味になります。
OAOO原則は主にコードの重複を避けることに焦点を当てているのに対し、DRY原則はコードに限らず作業全てにおける繰り返しを避けることを目的としています。
今回はコードに焦点を当てるため、DRY原則については割愛させていただきます。
棄教
抽象化をすればするほどコードが美しくなると考え、過度な抽象化を行った先にはOAOOを意識しすぎて柔軟性が欠如したコードがありました。
変更に弱く、無理やり抽象化したことで無駄な工程やコードが発生していると指摘を受け、OAOOに対する意識が変わりました。
抽象化によって変更箇所を減らすことも重要ですが、場合によっては多少の重複を許容してでも柔軟に変更できる設計の方が有効であることを学びました。
また、OAOOを過剰に適用することで、可読性が低下したり、再利用性を優先するあまり関数呼び出しが増えてパフォーマンスが悪化するなどのデメリットがあります。
再入信
しかし、OAOOは我々を正しいコードに導いてくれる絶対神ではないというだけで、ありがたい存在であることには変わりありません。
問題だったのは、それを適用すべきでない場面でも無理に従おうとした自分の姿勢です。
保守性や柔軟性を意識するあまり、必要以上にOAOOを避けてしまうのも本末転倒だと感じました。
大切なのは、いつ抽象化すべきか、いつ重複を許容するべきかを見極めること。
今後は原則に振り回されるのではなく、使うべきタイミングを自分で判断できるエンジニアを目指します。
