何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

システム設計におけるnullの扱い(覚書)

結論

結論からかいてしまうと、変数にnullを極力入れないようにしましょう!

ということです。

前提条件

  • 今回のシステムはC#ですが、JavaC++でもある程度当てはまると思います。*1

経緯

今まで、10年ほどシステム開発をやってきて、もやもやしていたnullの扱いについて、たまたまチームメンバーの実装をレビューしたり一緒にコードを見て話しながら多少整理がついた内容を覚書として残しておこうと思います。

 

具体的にどういうこと?

最初に断わっておくと、全然大した話ではありません。

世の中のオブジェクト指向を取り入れたJavaC#といった言語でアプリケーションの開発をやっている方々なら早い時期に学習して身に着けている内容かもしれませんが、自分には最近分かってきたことです。

我々プログラマーが長年戦ってきたあれ。

ガッ!!

ってされちゃう。

言葉にしてはいけない例のもの。

ぶっちゃけ、ぬるぽですね。

.NetだとNullReferenceExceptionかな。

それって、当たり前すぎて申し訳ないけど変数にnullを入れるから発生するわけです。

で、主に以下の原因で変数にnullが入るんじゃないかなぁと思うわけ。

  1. ライブラリ等のAPIからの戻り値がnull
  2. 自分で変数にnullを代入している。

その他にもあるかもしれませんが、大別すると上記の2台巨頭がnullの発生原因でしょう。

で、今回わたしが着目しているのは1の方。

2は気をつけろよって話だし。

そういうことはしないようなルールで作るべしで終わりなんだけど、1は自分たちの責任範囲じゃないというか利用する側としてはnullが返って来ないようにコントロールすることは基本的にはできないわけです。

で、その際になるべくAPIから帰ってきたnullは適切に処理して以降システム内でnullを扱わないように徹底しようぜ!という趣旨のもとアプリケーションを作っていきたいなぁという話。

nullにはnullとしか意味がないけど、アプリケーションとしてはAPIからnullが返ってきた場合には、それなりの意味を付与できるのでnullの代わりそういったオブジェクトで代替するなり例外処理に進むなりしたいものです。

広い意味でのNull Objectパターンなのかもしれない。

そういった、気づきがあったのが本日のハイライトでした。

 

以上。

*1:他の言語でも当てはまるかもしれませんがあまり詳しくないので…