Adaptive Codeの感想その3

はいどーもこんにちは、ニートに適応しつつある無職です。
本日は『Adaptive Code』の感想の続きを書いていこうと思いますよ。
パート1
パート2

リファクタリングの方法

注*この項目はパート2とちょっとかぶります。

既存のコードを整理するとき、いわゆるリファクタリングという作業をするかなと思います。
当たり前ですが、コードを綺麗にするには既存のコードを改変する必要があります。
改変したとき、どうやって改変したコードが壊れていないことを保証すればよいのでしょうか?
シンプルなのは自分で一つ一つ動作が壊れていないことをチェックすることですが、ぶっちゃけこんなの面倒ですし、リファクタリングしたくなくなります。
さらに言うなら、テスト漏れも十分考えられます。
そこで先にテストを作っておくわけです。
テストさえ作っておけば、リファクタリング後の動作が破壊されていないことがテストによって保証されます。
テスト駆動開発はリファクタリングにも強い方法でもあるわけなんですねえ。
むしろテストがない状態でのリファクタリングという作業はちょっと嫌かなーと思う人も多い気がしました。
だって動作を保証できるものが何もないですもん。

マジックナンバー

本書は具体的なリファクタリングの手法にも触れられています。
その手法を全て書くことはしませんが「マジックナンバー」についての項目はプログラミング全体を通じて参考になるんじゃないかなと思ったので紹介しておきます。
プログラミングの勉強をしていると「マジックナンバーは避けろ」ということをよく聞くかなと思います。
ですがこれは単に「マジックナンバーを使わなければいい」ということではなく、変数の目的がはっきりする名前をつけろ、ということなのですね。
本書でも「マジックナンバーをA,B,Xといった名前の変数に置き換えただけでは、何も改善されません」と指摘されています。
たまに変数にaやらbやらと名前をつけたまま放置されているコードも見かけますので、注意したいですね。

抽象クラスの名前

インターフェイスのプレフィクスとして「I」をつけるのと同様に、抽象クラスであることを示すためにサフィックスとして「Base」をつけることが本書では勧められています。
これはツクールMVのコアスクリプトでも使われている手法ですね。
もちろんツクールMVはC#ではなくJavaScriptなので抽象クラスなんてものはありませんし、例外も特に投げられていないので単に「基底クラスですよ」くらいの意味合いが強い気がしますが。

デコレーター

本書はデコレーターの利用をめちゃんこ推しています。
正直僕はデコレーターのよさがまだあんまりわかっていないのですが、単一責務の原則(SRP)を達成するのにデコレーターパターンやアダプターパターンが非常に役立つらしいです。
本書では「SRPを達成する主な方法は、コードをインターフェイスとして抽出し、無関係な機能に対する責務を、そのインターフェイスを実装しているオブジェクトに実行時に委譲する、というものです」と書かれていました。
ちょっと意識したいと思いましたよ。

デコレーターの中では遅延デコレーターが面白いなと思いました。
というかLazy型という存在を初めて知りましたw
どういうときにコレ使えばいいんでしょうかねえ。

適応力とは

グサッと来た言葉があったので、それを全文引用したいと思います。
「プログラマーになりたての頃は、C#のようなオブジェクト指向言語であっても、きわめて手続き的なコードを書いてしまうことが多いようです。そうしたプログラマーは――それらのメソッドを同じクラスにまとめるのが妥当化どうかはさておき――クラスをメソッドのストレージメカニズムとして使用する傾向にあります」
まさに僕がこれでした。
一応クラスは作るし、メソッドとして機能ごとに分割もするのですが、結局のところ「ストレージメカニズム」を脱していなかったのですね。
最近はデザインパターンを学んだり、SOLID原則を勉強したりして多少はマシになっていると思いますが(むしろマシになっていると思いたい)、意識して勉強しないと「ストレージメカニズム」以外の使い方を習得するのは難しいんじゃないかなあと感じます。
実際『実戦で役立つ C#プログラミングのイディオム/定石&パターン』でも「ある程度経験のあるプログラマでも、インターフェイスに対してプログラミングするということができない人が多い」的なことが書かれていました。
これは意識的に勉強しなかった結果なのだろうなあと思いました。
あるいは会社に入ったら教えてもらえるかもしれませんが、一人で勉強しているなら、何らかの情報源から「こういう風にプログラミングするのが定石だ」みたいなのを仕入れないといけない気がします。
僕はたまたま情報源を得られたのでラッキーだった感じですかね。

リスコフの置換原則

有名なアレですね。
この原則を守ったコードは適応力が上がるらしいです。
この辺は情報が腐るほど出回っているので、ググったらいいんじゃないでしょーか。
僕もまだもう少し勉強した方がよさそうな雰囲気プンプンしてます。
コラムの「カプセル化とコントラクト」は参考になりました。今度から「独自の型にカプセル化する」ということを意識したいと思いますよ。

インターフェイス分離の原則

「一つの大きなインターフェイスを作るよりも、インターフェイスは細かく作っていくほうがよい」というのは僕も音に聞いていました。
ですが依存性を注入する際に、同じインスタンスを何度も渡す必要があったりして「本当にこれで正しいのか? 僕のやり方が間違っているのではないか?」という不安がありました。
ところがどっこい。
『Adaptive Code』は僕の不安を以下のような言葉で振り払ってくれました。
「同じインスタンスを3回も渡すのは異常に思えるかも知れませんが、これらのパラメーターがそれぞれCrudクラスの異なる側面を要求することを考えると、これは理にかなっています。これはインターフェイス分離の原則における一般的な副作用です」
いやあ、素晴らしい!

依存性反転の原則

依存性反転の原則については別の記事としていろいろと書きました。
依存性反転の原則について勉強してみる
抽象化は詳細に依存すべきではないとは

終わりに

まだ本当は色々とメモしていることがあるのですが、うまくまとめられないのでこの辺で切り上げます。
全体を通して、かなり具体的なサンプルが用意されているため、言語仕様を中心に何かを知っていくというよりは、すでにC#での開発経験が豊富であり、色々なフレームワークを使いこなしている方が対象なのかなあと思いました。
つまり僕では本書の内容を全て理解するのは難しかったですw
とは言え得られたものも大きいですので、プログラミング一年目あたりの方は実力試しがてら一度読んでみるのもよいんじゃないかなーと思いました(僕がちょうどそうです)。

時間をあけて再読もすると思いますので、そのときどれくらい理解できる項目が増えているのか楽しみですねえ。
ほなそんな感じでまた。

あ、お仕事も募集中です!

フォローする