- + JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
680 ：デフォルトの名無しさん[sage]：2016/10/31(月) 06:43:17.85 ID:xWfuY90D - >>677
POJOの意味をわかってないねｗ
https://ja.wikipedia.org/wiki/Plain_Old_Java_Object より
> POJOの概念は、明らかにPOJOという用語より前から存在する。なぜなら、
> オブジェクトクラスの自然なありさまとは、何ら特別なものではないからである。
> この用語の功績は、何らかのフレームワークを使う利点がその複雑さを補って
> あまりあるかどうかということを開発者に考えさせるという点にある。
> シンプルな設計の方が優れている場合もあるということを思い出させる明確な用語がなくては、
> 複雑なフレームワークが十分な理由のないままシステムアーキテクチャに含まれてしまいやすい。
> POJOによる設計が一般的になるにつれて、大規模フレームワークの機能の一部はPOJOでも
> 実現できることが明らかになってきており、実際に必要な機能領域に対する選択肢は増えている。
> HibernateとSpringがその例である。
意味わかる？ POJOっていうのは単なるクラス。フレームワークとかのクラスを継承しない
単なるクラス。それがシンプルで良いという考え方から生まれた用語。
JavaScriptでも同じ。単なるクラスがシンプルで良い。
wikipediaに書いてあるように、特別なものじゃないんだが？
永続化？ 補完？ そんなものPOJOの意義とは全く関係無い。
|
- + JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
685 ：デフォルトの名無しさん[sage]：2016/10/31(月) 21:26:05.75 ID:xWfuY90D - >>682
JavaScriptに限らず言語の文法っていうのは
可読性を上げるために作られているんだよ。
そして可読性を上げる方法の一つが、コードの中から読まなければ
いけないコードの量を減らすこと。
一定のパターンに対して名前をつけてその名前を覚えてしまうことで
読まなければいけない量を減らすことができる。デザインパターンもその一つだけど文法も同じ。
シンタックスシュガーも読まなければいけなかったコードを
短い言葉で置き換えてそれを覚えてしまうことで可読性を上げることにつながってる。
（とは言えなんでも覚えてしまうのは不可能だから、覚える価値があるものだけに絞るべき。
例えばプロジェクト固有の関数は覚える価値が少ない。言語仕様はどこでも使える知識だから覚える価値がある）
また文法っていうのは、汎用的な命令だたものを専用的な命令に置き換えることが
できるように進化してきている。例えばgotoはあちこちに飛ぶことができるものだが、
これをより専用化してbreakやretrunやthrowなどができた。
これはgotoだけでは色んな意味があるから何のために使っているのかわかりにくいが
専用的なbreakであればループを途中で抜けるんだろうなってことがわかるから。
JavaScriptはclassが無くても作れていたが、だが人間は関数とクラスを区別していた人が多かった。
だからその人間の感覚に近づけることが可読性向上につながるわけ。
可読性の問題なのだから無くてもできるのは当たり前。
var p = { }; これだとただのハッシュなのかクラスなのか、色んな使い方ができるから
これだけ見てもわかりづらいだろ？ 使っている箇所を読まなければ分からない。
class Personであればnewして使うんだろうなってことが明確になる。
読まなくて済むわけだよ。これが可読性という話。
|
- + JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
686 ：デフォルトの名無しさん[sage]：2016/10/31(月) 21:29:41.12 ID:xWfuY90D - それと可読性というのは全体のコード量にも依存する。
class Personの方がわかりやすいが、全体のコードが数十行程度なら
そこまでする必要はない。
だからコードが短いうちはvar p = {} で書いていても良い。
だけどコードが増えたときには必ずclass Personに変更しなければいけない。
これを放っておけば、犬小屋を作るやり方で一軒家を作るようなことになりかねない。
規模によって適切なやり方は違う。
|
- + JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
692 ：デフォルトの名無しさん[sage]：2016/10/31(月) 23:08:27.14 ID:xWfuY90D - >>688
永続化が問題なのか？クラスの話関係ないじゃん。
シリアライズっていうけどさ、やってるのはJSON文字列への変換だろ？
前提として関数等はJSON文字列に変換することはできない。
シリアライズされたデータの中に関数定義は含まれないので
関数定義とデータは別々に管理しなければならない。
ここまでは自明だよな？
あとはクラス定義（プロトタイプチェーン含む）をコードで作った上で
その中のデータのみをシリアライズ & デシリアライズする。
これがJSONオブジェクトを使った場合のやり方だろ？
|
- + JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
693 ：デフォルトの名無しさん[sage]：2016/10/31(月) 23:09:18.71 ID:xWfuY90D - つーかクラスと永続化の話を切り離して考えろ！
|
- + JavaScript(ECMAScript)質問用スレッド vol.122 + [無断転載禁止]©2ch.net
694 ：デフォルトの名無しさん[sage]：2016/10/31(月) 23:20:25.00 ID:xWfuY90D - そもそも永続化の話ということで考えると、
お前それ本当に永続化したいと思ってんのか？って言いたくなるんだが。
何のために永続化が必要なんだ？
永続化なんてしないだろ。永続化しないもののために
わざわざ永続化のためのコードなんて書く意味ねーぞ？
Javaの話でも同じ。永続化しないものにSerializableなんて
やる必要ないぞ。何も考えずに無駄にコピペしてねーか？
|