変更しやすく堅牢なプログラムを書くということについての覚書

表題のような偉そうなことを言える身分ではないですが、ちょっと気づいたので覚書。

「クラスは使う相手のことを信じない」の法則

似たようなコードを複数個所に書くとメンテナンスが大変
VS
一つのクラスを複数の処理に使いまわすと変更容易性が失われる

という問題に直面しました。
Photoshopスクリプトを作っていて、どう考えてもこれは「レイヤー」クラス（※自作したもの）にやらせたい処理だけど、「レイヤー」クラスは限りなく基底クラスに近いところにいるので、すでにいろいろな処理が詰め込まれており、これにさらに機能を足したら変更容易性が失われてしまいそう。（既にない、という説もある）
なら、レイヤークラスを継承した特殊なレイヤークラスを作ればいいのでは…？でも、AdobeExtendScriptは継承が使えない！！！！！！！
かといって、じゃあ全く新しく特殊なレイヤークラス作る？結局レイヤークラスを内部で呼ぶか、同じ処理を二度書きすることになるけど。
というダブルバインド。

で、結局はレイヤークラスに処理を足して乗り切ることにしたのですが、その時に「クラス側は使う側の事情を一切信用しない」という原則で作ることで、変更に対して用意かつ堅牢にすることができるらしいということを悟りました。（原則は知っていても、それを悟るのは難しいものです）

つまり、「ここには必ずレイヤーオブジェクトが入ってくる「はず」だ。使う側は必ずレイヤーオブジェクトを渡せばよい」という前提でクラスを作るのをやめ、必ずクラス内で「貴様本当にレイヤーオブジェクトだろうな？！」をチェックし、そうでない場合に適切な例外を返すようにします。
そうすれば、新しくそのクラスを使う処理を書いたとき、間違えて変なオブジェクトを渡してしまっていても、テスト一発で即座に気づけます。

人間は忘れます。「ここってデフォルトのレイヤー渡せば良いんだっけ、自作のレイヤー渡せば良いんだっけ」とか、絶対になります。
引き数名をわかりやすくしておく、コメントを入れておくのは勿論大事ですが、それでもやっぱり分からなくなります。人間を信用してはなりません、特に未来の自分のことは。

……でも、とはいえ、全部のクラスの全部の入力値にそうやってバリデーション掛けるの面倒くさい。

型があるって便利だなぁ……

プログラム初心者が「型」の概念を獲得するのは大変です。私も学生時代に初めてJavaのテキストを読んで「型」の概念に触れてから、10年以上よく分からないまま放置していました。多分、ちゃんと理解するのにはブランク込みで15年くらい、静的型付けのメリットを理解するのにはさらにそこから2年くらい掛かってます。

しかし、「この関数のこの引数は絶対Stringじゃなきゃダメだからね！受け取らないからね！」と決まっていれば、上記の「全部の入力値にバリデーションを掛ける」の部分の最低限のところを、プログラム言語側で自動でやってくれる訳です。
それって、めちゃめちゃ便利だし、プログラムがより安定に近づきます。

勿論、メモリの節約というメリットも大きいとは思うのですが、マシンが高性能になってきている昨今、メモリの操作をしてメモリを節約することが求められる場面は昔に比べれば限定的になってきていると思います。

それでも昨今のトレンドは「型、合った方がよさそう」に流れているのは、やはりプログラムの拡張性やメンテナンス性が大幅に上がるからなんだろうなぁと。

まあ、ExtendScriptには型が無いんですけどね！！！

ない、というか、静的型付けができないというか。型自体はあります。
というわけで、ExtendScriptを書く時は「使う相手を信じない」を基本にしていきたいと思った次第でした。