失敗を表現する手法としてNullObjectパターンが不適切でEitherが適切だと思う理由 - Qiita

真面目な気分出して書いていたらすごい長くて堅苦しくてもったいぶった感じになってしまった... この記事の9割は壮大な前置きですw なにこれ 失敗の表現としてNullObjectパターン（以下楽なので勝手にNOPとします）を使うべきか議論をした際に論理立てて話せなかったので、 持論整理をしてついでにこの場を借りて晒してみようと言う記事です。 全ての状況において必ずEitherだ！と言うよりは、議論になったら僕はこう考えてますって言うためのポエムです。 DDD的な考えも少し この記事は実装都合のみに閉じていますが、DDD的な観点からも考えてみたことがあるのでこんな記事も書いてみました。 先に結論 前置きではない1割の部分だけ先出します。 それで「あ、そうか」とか「は？」とか思える人は以下の長大な前置きは不要ですw NOPは成功と失敗を区別しようとすると破綻する、けど区別したい事が珍しくない。

[sawat]

NOPは失敗を表すためのパターンじゃなくて、何もしなくていい場合という、State or Strategy パターンの変種でしょ。あと、この例ではsaveとwriteLogをFooインタフェースに含めればいいだけになっている

[yojik]

NullObjectの目的は、Nullのとき何にもしない事を呼び出し側に意識させずに実現する事だから、失敗ケース表現に不向きなの当然だす（例のログ吐きはNullオブジェクトのメソッドに書けば良いじゃんとも思うけど）

[kknsd]

振る舞いの変化する部分を個々のクラスに押し込めるのが原則なんやで

[pmint]

このNullObjectパターンの例は実在するんだろうか。実装でのトラブルが後を絶たなくなること受けあい。/ 呼び出し側で扱うクラス数が変わらない点で、別段違わない気がする。悪例をましにする代替策といった感じ。

[hylom]

例外処理で良いんじゃない派

[masaru_b_cl]

自分なりに考えて答えを出せたことは素晴らしいので、先人たちがいろいろ言うかもしれないけど気にしないでください

[donkeyhole]

ちゃんと読んでないからかも知れないけど、nullチェックでいいやんけ、って思った

[komutan1]

NullObjectってバリューのゼロ値とかステートレスなサービス的なやつに限定したほうが。ライフサイクルの長いコアエンティエィに適用するといろんなとこで使われすぎて破綻した経験ある。

[letsspeak]

れ、例外は..

[teracy_junk]

NOPはもう一枚外のレイヤーから見た話だったような

[bouzuya]

成否の区別をなくすためのものだから

[efcl]

nullオブジェクトパターンについて

[S64]

🤔