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: (スコア: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)
おじさんは例外を投げるほうが好きです。
例外を拾った側で好き勝手するほうが好きです。