Given a binary tree, with this node structure: class node {
node left
node right }
One may implement a tree size procedure recursively: function tree_size(node) {
return 1 + tree_size(node.left) + tree_size(node.right) }
Since the child nodes may not exist, one must modify the procedure by adding non-existence or null checks: function tree_size(node) {
set sum = 1
if node.left exists {
sum = sum + tree_size(node.left)
}
if node.right exists {
sum = sum + tree_size(node.right)
}
return sum }
This however makes the procedure more complicated by mixing boundary checks with normal logic, and it becomes harder to read. Using the null object pattern, one can create a special version of the procedure but only for null nodes: function tree_size(node) {
return 1 + tree_size(node.left) + tree_size(node.right) } function tree_size(null_node) {
return 0 }
This separates normal logic from special case handling, and makes the code easier to understand.
つまり (スコア:1)
ヽ( ･∀･)ﾉ┌┛ｶﾞｯΣ(ﾉ`Д´)ﾉぬるぽ
だったのが
ヽ( ･∀･)ﾉ┌┛ｶﾞｯΣ(´∇｀) ぬるホッ
という
安全になったからって糞コードおｋって訳じゃねぇ
となるわけですね
# 糞コードは世に尽きまじ
Re: (スコア:0)
初期化漏れとかメモリリークとか。
オブジェクトを使用しなくなったときにnullを代入して参照外すのはどう変わるんだろう。
Re:つまり (スコア:1)
NULLを入れたいときは、NULL許容型(従来通りの型)を使うだけですよ。
NULL安全って、NULLチェックの漏れをコンパイラが検出できるようにする仕組みでしかなくて、設計とかロジックに何か影響するわけじゃない。
昔から静的解析ツールとかで、NULLになる可能性があるとかチェックはできたけど、関数の呼び出し元を延々とたどる必要があって、コンパイル時にやるには負荷が高すぎた。NULL安全をサポートする言語では、NULL非許容の型を用意することで、スコープ内だけでチェックを閉じられるようにしたというだけの話。
新規に設計すると言語側のNULLでないことを保証する機能にたよれるのでNULL非許容の型を主に使うようにして、NULLを使わないコードの範囲を広げれば、その間はNULLチェックのコードが不要なので無駄がなくなるところがメリット
NULLが必要なときは、今までどおりNULL許容型使えばいいです。
Re: (スコア:0)
初期化強制なのかもね、コンパイラがチェックということは。
しかし、空を意味するために0とか "" を単に突っ込むだけになって、null参照で落ちないだけで挙動不審なプログラムになるだけな気がする…。
参照外す方法なぁ。NullObjectとかいう空っぽのクラス作って、それをnewして突っ込んだりしてなｗ
Re: (スコア:0)
型安全な言語でnullが入る型に0を入れる意味はないでしょう。
まあ初期化強制ですね。
メモリ開放はnullの代入ではなくスコープで管理しようねって話かと。
Re: (スコア:0)
null許容型があるみたいよ
Re: (スコア:0)
参照を外すためだけにnull許容型にしてnull安全性をなくすのもなあと。
Re: (スコア:0)
参照を外したいのに、NULL安全を維持するなんてのは本末転倒
百害あって一利なし。
NULL安全な処理とNULL安全でない処理は、分離できてないとコンパイルも通らないですから、NULLが必要な箇所は普通にNULLを使えばいいんです。
普通に書くだけで、どちら側の処理か明確に区別きますし、そもそも区別つかないように書くことが出来ません。
Re: (スコア:0)
null がターミネーターとして優秀すぎるので仕方ない。
Re: (スコア:0)
「この変数(引数)の取扱いはnullを考慮してないコードですよ」という型が増えて、
「nullが入っているかもしれない変数」をその処理に渡す時は事前にnullかどうかチェックしないとコンパイルエラーになる。
というのがnull安全のあらましです。
Re: (スコア:0)
Dartはよく知らんけど、Kotlinの思想は、
スコープを超えて存在するようなオブジェクトはNewしない。
どうしても永続化したい場合、静的なオブジェクトにする。
戻り値の参照は作らない。
なんでしょう。
参照を作らなければ消す必要はないですから。
Re: (スコア:0)
Null Object パターン [wikipedia.org]がわりと大活躍
Re: (スコア:0)
null saftyとnullObjectは真逆の考え方だろ。
Re: (スコア:0)
応用力よ。
nullを許容したくないが、初期化は後回しにしたい場合
NullObjectで初期化しておけばよろしい。
あえて参照を外したい場合も、NullObjectにすればよろしい。
基本的には相反するからといって、一生応用を考えないようじゃダメだ。
Re: (スコア:0)
https://nullsafety.dartpad.dev/3d9c1769de7912c654bc5d132aff60ac [dartpad.dev]
初期化の後回しの為だけにNullObjectなんて使わなくていい
Re: (スコア:0)
NULL安全で、null object 導入って、どんな気違いだよ。
null object のメリット全否定じゃん。
# そもそも null object pattern を止めましょうってのが、NULL安全の基本中の基本だぞ。
Re: (スコア:0)
nullとnull objectは無関係
nullはnullだしnull objectはobjet
頭の悪いやつは「無関係」というのが理解できない
おおかたrubyで全クラス階層共通ののnull objectを作ってんだろ
Re: (スコア:0)
それは応用力じゃなくて、理解力の欠如あるいは思考力の欠如っていうんだよ。
NULLが使いたい箇所にはNULL共用型を使いましょう。
NULLObjectを作って、NULL非許容型に設定すると、NULl非許容型は存在価値がなくなります。メリットが減るではなく、完全に無くなります。
Re: (スコア:0)
何となくわかった。
NULL安全に書くことが可能な処理では、本質的にNULL値が不要だから、Null Objectの出番は無い。
設計的にNULL値を必要とする処理では、そもそもNULL安全にはならないから、Null Objectによる実装が選択肢に現れる。
NULL安全に書けるなら、その方が良い。
Re: (スコア:0)
初期化漏れはコンパイルが通らないので起こりえません。
Re: (スコア:0)
クソコードの話をしているのだから、この場合の初期化漏れは初期化されないのではなく初期値の変更忘れ。
基底クラスのプロパティを変え忘れたとか。
Re: (スコア:0)
こういうコメント見ると、NULL安全はまったく理解されてないのだなぁと思うな。
NULL安全なコードで、後で変更することを想定してる初期値なんてものは実装としても概念としても存在しない。
NULL安全なフィールドや変数は、つねに意味のある値になっていなければならないし、実際そうなるように書く。
常に意味がある値を持てないフィールドに、NULL安全な型をつかってはいけない。
Re: (スコア:0)
上で、nullObjectパターンとかの話も出てるのも、そのへんが理解されてないからだろうな。
常に意味のある値であることを保証するための枠組みだと理解してたら、nullObjectパターンを持ってくるなんていう頓珍漢な発想が出てくる余地もないからな。
Re: (スコア:0)
オブジェクトの生成時にどうしても初期値を設定できない場合はあるが、そういうときはプロパティやgetterを使うなり遅延初期化なりするしな
面倒だと思うかもしれないが、本質的に制約が大きくて面倒なんだよ
(#3836212)は関数型言語の経験はないんだろうか
あれこそNULL安全の代表選手なのだが
あとnull objectはちゃんと意味がある値だぞ馬鹿
Re: (スコア:0)
どこでnullナシ処理を担保するかって話なだけなのにオマエらカッカしすぎ
nullobjectで進んでも表示や保存する動的コードの前段階でナニカをしなきゃならんわけで
素晴らしい解決法思いつかない現状ユーザーコード側に責任押し付ける安全のほうが低コストだから皆が拝んでんだよ
Re: (スコア:0)
null objectにはきちんとした名前をつける必要がある
https://en.wikipedia.org/wiki/Null_object_pattern [wikipedia.org]
Given a binary tree, with this node structure:
class node {
node left
node right
}
One may implement a tree size procedure recursively:
function tree_size(node) {
return 1 + tree_size(node.left) + tree_size(node.right)
}
Since the child nodes may not exist, one must modify the procedure by adding non-existence or null checks:
function tree_size(node) {
set sum = 1
if node.left exists {
sum = sum + tree_size(node.left)
}
if node.right exists {
sum = sum + tree_size(node.right)
}
return sum
}
This however makes the procedure more complicated by mixing boundary checks with normal logic, and it becomes harder to read. Using the null object pattern, one can create a special version of the procedure but only for null nodes:
function tree_size(node) {
return 1 + tree_size(node.left) + tree_size(node.right)
}
function tree_size(null_node) {
return 0
}
This separates normal logic from special case handling, and makes the code easier to understand.
このnull_nodeは普通はleafと呼ばれているので、実際のプログラムではそう名付けなければならないし、他のプログラムでnull objectを使う場合には、同様に適した名前をつ
Re: (スコア:0)
> オブジェクトの生成時にどうしても初期値を設定できない場合はあるが、そういうときはプロパティやgetterを使うなり遅延初期化なりするしな
そのために、NULL許容型があるのですから、それをつかいましょうね。
NULLでなくなったことを確認した処理からは、その値を保持したNULL非許容の型に値を保持してそれを使いましょう。
NULL非許容型に、nullObjectの考えをもってくると、NULL(でないとしても)非許容ではなく、NULL許容と同じく、最後までつかえる値なのかわからない型となり、NULL非許容にする意味がなくなります。
> (#3836212)は関数型言語の経験はないんだ
Re: (スコア:0)
おお、ここまで堂々とした無知は気持ちがいいな
kotlinのlateinitとか、代数データ型とか、キーワードは教えてやるから自分で調べな
無知と馬鹿は違うから、自分で調べれば望みがあるぞ
Re: (スコア:0)
おじさんは例外を投げるほうが好きです。
例外を拾った側で好き勝手するほうが好きです。
Re: (スコア:0)
それはNullかんけいないよね。
なんかのクラスのインスタンス変数の初期値を設計上長さゼロの文字列からNullに変えた。
ソースコードの修正を忘れた。
バグったってことだよね？