適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
