nullに対する好悪
「JavaScriptが大変 ３」で書きました通り、私にとって、
でした。
ですので、「nullが無い方が普通の記述となるコンテキスト」で、最終的に置き換えようとする事に対して、べつに特段の好悪感情は持ちません。
年柄年中、「nullかどうか」最初に判定しないと行けないというのは、確かに不合理です。
ユニットテストやJUnitは？
こちらに関しては、
ので、好きでは無いです。
何が引っ掛かるのか？
ユニットテストやJUnitは、「開放閉鎖の原則（開放/閉鎖原則 Wikipedia 日本語版）」と密接な関係にあると思います。
「開放閉鎖の原則」を成り立たせる様な仕組みが作れる状況で、「ユニットテストが有る方が普通の記述となるコンテキスト」を使えるのです。
（今度、Copilot Proを止めて、Cursor Pro（有料版では一番安価なプラン）にしたのですが）Cursor Proに、
- 計算に必要な入力値の個数、種類が変わる際に、開放閉鎖の原則を維持することは可能ですか？
と聞いた所、
- 計算機アプリを例題として、
- （ソフトウエアの大きい方の枠組みである）「戦略パターン」を使った実例
が回答されました。
拡張性、柔軟性、保守性、テスタビリティのいずれにも秀でたやり方だというのです。
しかし惜しむらくは、anyの多様だと思います。もちろん、それを回避し、型をきちんとする手段も有るのは存じていますが、かなりの手間となります。
これではまるで、
- 年柄年中、「nullかどうか」最初に判定しないと行けない
のと同等か、それより酷い状況となります。
「ユニットテストが無い方が普通の記述となるコンテキスト」で、最終的に置き換えたくなる状況だと思います。
ユニットテストやJUnit、ひいては開放閉鎖の原則
そもそも「開放閉鎖の原則」など、継承の濫用となり、もはやモダンと言うに値しないやり方かも知れません。
そうなると、ユニットテストやJUnitも、それと同じ運命となり、まだ在来のテストの方がまし、となっているのが現状かも知れません。
それが有効な、特定の状況は有るかも知れませんが、
圧倒的大多数の場合、nullと同等かそれ以上の理由で、
- 「一回限りの」の状況に対処するには、在来のテストの方が適していた
のかも知れません。
結論
これからも「一回限りの」事象に対する「技術的焚書」でプログラミングが嫌いになる人は存在し続けることでしょう。
