17/04/02 16:34:54.03 T05HwBIb.net
なるほど
土俵の下からヤジ飛ばしているだけの自覚なあるわけか
俺からするとオブジェクトのカプセル化という思想自体が根拠そのものなのだが経験が浅いから具体的なケースが思い浮かばないのだろうか
せっかくだから最後に簡単に具体例をあげてやろうかとも思ったがおまえは前スレでも具体的な話すると読むの無駄だといって逃げるから時間の無駄だな
議論することで己の知見が広がるということすら理解していないからやはりおまえは間違いなく頭の中は子供だよ
その独りよがりでせいぜい頑張りたまえ
967:デフォルトの名無しさん
17/04/02 16:36:29.28 n7h/bBRg.net
なるほど
土俵の下からヤジ飛ばしているだけの自覚なあるわけか
俺からすると○○○○が根拠そのものなのだが経験が浅いから具体的なケースが思い浮かばないのだろうか
せっかくだから最後に簡単に具体例をあげてやろうかとも思ったがおまえは前スレでも具体的な話すると読むの無駄だといって逃げるから時間の無駄だな
議論することで己の知見が広がるということすら理解していないからやはりおまえは間違いなく頭の中は子供だよ
その独りよがりでせいぜい頑張りたまえ
汎用化してテンプレ化完了。
いろんなところで使いまわそう！
968:デフォルトの名無しさん
17/04/02 16:42:36.02 8k5jx1PC.net
おいおいreadメソッドしか公開されてないから行単位の経過出力ができねぇよ
やっぱりクラスは駄目だな
969:デフォルトの名無しさん
17/04/02 16:43:40.28 n7h/bBRg.net
はい>>950取ったので、責任持って次スレ立てましたよ。
オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(tech板)
970:デフォルトの名無しさん
17/04/02 17:05:52.30 KLExlLIQ.net
>>950
2017/03/31(金)のID:FcWj0OtHだけど質問させてくれ。
質問１：
君は2017/03/31(金)のID:OV1cbLT2か？
質問２：
>>714以降、cat.door()でなくdoor.open(cat)かdoor.push(weight)がよい
という主張にID:OV1cbLT2は反論していないが君も納得したのか?
971:デフォルトの名無しさん
17/04/02 17:09:12.02 n7h/bBRg.net
>>951
> 君は2017/03/31(金)のID:OV1cbLT2か？
違う。俺は>>720だ
972:デフォルトの名無しさん
17/04/02 17:09:55.53 T05HwBIb.net
>>946
オブジェクト指向の目指すところは弱い結合度と強い凝集度なのはわかるな
つまり噛み砕くと極力他のオブジェクトとの依存を減らしオブジェクトの機能の純粋性高めるように設計するわけだ
その結果例えばゲッタ、セッタのような厳密なスコープ管理が生まれるわけだがある管理オブジェクトAがいくつかの状態を持っているとする
そしてエンハンスによりその状態に大きく依存した処理入れることになった
この時選択肢はいくつかあるが厳密なスコープ管理されたクラスへ複雑な状態の判定を入れる場合最も簡単なのはAにコードを書くことであり多くのプログラマーがそれを選択する
そしてそ�
973:ﾌようなエンハンスの繰り返しにより結果としてクラスは確実に肥大化する それを解決しようと何かを他のオブジェクトに分離しようなもprivateなものへのアクセスが大量に必要になり容易く分離ができない そこで必要なるのはクラスの凝集性の見直しと大量のinterfaceの作成だ しかしこれは大きなデグレリスクとコストを伴うもので実業務で行うのは容易くないのだよ これを関数型で考えてみようか 関数型は原則的に副作用の持たない第一級関数の集合と考えていい 言うまでもなくオブジェクト指向のようなジレンマを持たないのはわかるだろう
974:デフォルトの名無しさん
17/04/02 17:11:54.22 n7h/bBRg.net
>>946
ということでエンハンスの意味はわかったかね？
975:デフォルトの名無しさん
17/04/02 17:14:43.81 n7h/bBRg.net
関数型のことを詳しく知りたければこの本を読むと良い
関数型プログラミングに目覚めた-IQ145の女子高校生の先輩から受けた特訓5日間-岡部-健
URLﾘﾝｸ(www.amazon.co.jp)
976:デフォルトの名無しさん
17/04/02 17:19:13.99 KLExlLIQ.net
>>952
回答ありがとう。
ID:dseKSPuYはバカで済ませずに
きちんと説明していたから同一人物とわからなかった。
>>955
待て待て待て
Qiitaでポエムを書いて除名された人の本を紹介するとはどういうつもりだ。
977:デフォルトの名無しさん
17/04/02 17:19:15.06 n7h/bBRg.net
オブジェクト指向に関してはペラペラと説明できるが、
関数型に関しては、一言しか言えていない。
ニワカという言葉を知っているか？
978:デフォルトの名無しさん
17/04/02 17:20:34.35 n7h/bBRg.net
> Qiitaでポエムを書いて除名された人の本を紹介するとはどういうつもりだ。
だってそっくりじゃん？ｗ
979:デフォルトの名無しさん
17/04/02 17:20:56.57 W6VXUIjv.net
毛の壁おすすめってマジ？
980:デフォルトの名無しさん
17/04/02 17:39:20.16 equ9Ou77.net
単芝滅ぶべし
981:デフォルトの名無しさん
17/04/02 17:43:01.53 G74Dkm4+.net
>>953
> 最も簡単なのはAにコードを書くことであり多くのプログラマーがそれを選択する
その選択が既に非OOP的としか言いようがない
後々の保守性を考慮する必要が無いのなら勿論ベストの選択肢だけど
982:デフォルトの名無しさん
17/04/02 17:45:29.33 KLExlLIQ.net
>>955
この著者を知らない人もいるだろうから、
関数型ポエム騒動に関するツィートまとめとレビュー記事と本人のブログを貼る。
レビュー記事のDay1では同一人物と思われる複数のアカウントが
著者の特殊な主張を擁護する300件近いコメントをつけている。
関数型プログラミングコミュニティにおける災害
URLﾘﾝｸ(togetter.com)
何やら「関数型プログラミング」と「IQ145の女子高生」を絡めた技術系の新刊が出るようですが。
URLﾘﾝｸ(togetter.com)
『関数型プログラミングに目覚めた！』のレビュー
URLﾘﾝｸ(qiita.com)
岡部 健の技術記事 Ken Okabe's tech writing
URLﾘﾝｸ(kenokabe-techwriting.blogspot.jp)
983:デフォルトの名無しさん
17/04/02 18:19:16.04 /blBHN/F.net
ID:n7h/bBRg が毛の壁オススメしててワロタw
頭すっからかんで何も理解してない事が証明されたな
984:デフォルトの名無しさん
17/04/02 18:22:39.33 T05HwBIb.net
>>961
だが現実として多くの開発現場でそうなっていることから目を背けてはいけない
人にとって現時点では最も直感的でわかりやすいパラダイムがオブジェクト指向なのはその通りでありだからこそ主流になってるわけだが、オブジェクト指向の理想に対して大多数の名も無きプログラマーにはそこが限界点だ
985:った またその原因の一つがおまえ自身が言っている通り、その理想が必ずしも局所的には最良かつ効率的ではなかったというだけのことだろ
986:デフォルトの名無しさん
17/04/02 18:45:02.56 DzpU0i7z.net
>>917
このゴミ本ありがたがってる奴いるの
仲介者クラスを作るべきというトピックのあとに、仲介者クラスをいたずらに作るべきでないとかかいてあるクソ本だぞ
じゃあいつ仲介者クラスを作るべきで、いつ不要なんですかってことに何の数理的論理的根拠もない
なおのこといらつかせるのは、この本がリファクタリングの意味するところ、つまりデータ構造の再構築、文学的にいえば推敲に失敗していることだ、端的にいえば読みづらい、コンテクストがそこらじゅうの章にちりばめられており一貫した考えがないから読みづらい
この本がどの程度リファクタリングされていずに不明瞭で、何ら設計指針が得られるものでないってことから、こういうアジャイルだとかオブジェクト指向にたいする欺瞞が膨れ上がった、そういった意味では良書だわ
この本としての体裁すら成り立ってないゴミ本は読書家として絶対に許せんわ、こんな恥さらしな本出してくれたファウラーとかいう文才ない自称プログラマはほんま消えてほしい
987:デフォルトの名無しさん
17/04/02 18:48:03.77 KLExlLIQ.net
>>953
この文章で説明している事はカプセル化があだになる例だから、
対比としては関数型でなく構造化プログラミングで十分だろう。
実例としては将棋ソフトウェアの思考アルゴリズム改良の話を聞いた事がある。
構造化プログラミングではデータを構造体で定義しグローバル変数にした。
思考アルゴリズムを変えると必要なデータが変わるが、
グローバル変数だからどの関数も必要なデータを自由に読み書きできる。
オブジェクト指向で将棋ソフトウェアを作ってデータをカプセル化したら、
アルゴリズムを変えるたびにクラスを再設計するはめになったそうだ。
カプセル化によって理解しやすいコードになるのは間違いないが、
データと処理の対応がよく変わる所は強い凝集度を最初から諦めて
データクラスと状態を持たないロジッククラスに分離する方が変更に強い。
仕様がよく変わるビジネスロジックはトランザクションスクリプトで書こう。
988:デフォルトの名無しさん
17/04/02 19:00:15.50 TvISwdcG.net
>>953
>>961と同じ意見だけど結局作る人の問題でカプセル化とは関係ないよね
何重にもネストしたif文にエンハンスで条件分岐に依存した処理を入れることになった場合に
最も簡単なのは既存の分岐の中にコードを書くことっていうのを同じレベルに聞こえる
どういう単位で分割するかはトレードオフの判断だと思うけどな
例えば格闘ゲームで今まで使ってなかった複数ボタンの同時押しで
状態に依存した新しい動作を追加する場合なんかだと
把握する必要のある状態が多くて十分複雑だと思うけど
カプセル化の制約があるからクラスが肥大化するとか
関数型なら破綻しにくくなるっていうのは想像できない
989:デフォルトの名無しさん
17/04/02 19:02:10.18 DzpU0i7z.net
クラス設計とはつまり、適切なデータ構造の選択だと言うことです、それができない人間は未来がない
我々がプログラムをかく以上、例えオブジェクト指向を採用したところで、チューリングマシンあるいはFSMあるいはチャーチモデル的な制約に縛られる
すなわちプログラムとは、メモリに格納された状態とそれにたいする手続きによって意味あるメモリ状態を構築し解釈すると言うことだ
クラスとは、クラス内部に状態を格納しているものであるべきであり、グローバル変数は確かにクラスに押し込めれば減る
もしクラスが状態を格納しないのであれば、それはただのデータにすぎない
データはプログラマの操作対象であっても、管理対象で�
990:ﾍない しかしクラスに格納された変更しうる状態はプログラマが管理することになる クラスはその状態数を最低とすることをアシストするような文法機構を持っていない 状態数を減らすことができるのは、関数だけなのである そしてプログラマは管理すべき状態を一元管理できるパラダイムか、各所にちらばった状態を個別に管理するパラダイムかを選択している このことをよく理解しているプログラマはオブジェクト指向でも関数指向でも大きくは間違えない
991:デフォルトの名無しさん
17/04/02 19:07:25.41 TvISwdcG.net
>>966
釣り師乙
キャットドアの出題者と同じ臭いがする
992:デフォルトの名無しさん
17/04/02 19:09:57.18 DzpU0i7z.net
確かにオブジェクト自身がオブジェクトの状態を保持するのは、"自然な"文法なのだろう
だが、そういう人間はその状態が究極的にはプログラマによって管理し、操作されるということを見過ごしている
誰かがそのオブジェクトにけしかけたのだとしたら、それは結局のところプログラマがそうせよと命じたからにすぎない
オブジェクトが自発的に思考してメッセージを出しているのではなく、プログラマ、ないしはユーザーがけしかけたからにすぎない
我々はオブジェクト指向ライブラリをみるたびにうんざりするのはそういうことだ
ライブラリの中にどれだけの状態数があり、何をどう操作すれば我々が欲するセマンティクスが得られるのか、ということに対して
文法的拘束もなければ意味論的な制約もかからないことだ
993:デフォルトの名無しさん
17/04/02 19:20:16.62 VFzZvOnH.net
>>968
誤りがあるトンデモ文だけ抜き出してアンカしようと思ったら全行言ってることがめちゃくちゃだった
>もしクラスが状態を格納しないのであれば、それはただのデータにすぎない
なんでやねん
994:デフォルトの名無しさん
17/04/02 19:21:29.46 nqLhFkBF.net
>>839
「C++のfriendがオブジェクト指向を破綻させている」
↑
単独にここだけ反論したい。
friendはむしろカプセル性を促進するものであって破綻させるものじゃないよ。
995:デフォルトの名無しさん
17/04/02 19:27:54.49 DzpU0i7z.net
>>971
クラスが状態を保持しないのであれば、インスタンスメソッドは何の役に立つのか説明してみて
996:デフォルトの名無しさん
17/04/02 19:33:57.36 VFzZvOnH.net
>>973
list2 = list.sort()
swiftなんかだと、listは値を持つが状態はもたん
配列が役にたたんと言う気か
997:デフォルトの名無しさん
17/04/02 19:35:49.63 equ9Ou77.net
ここまで熱く語れるのはなんか色々通り越してうらやましいわ
998:デフォルトの名無しさん
17/04/02 20:00:30.00 DzpU0i7z.net
リストなの?配列なの？
オブジェクト指向の文脈において、不変性はパフォーマンス低下以外の何のメリットがあるの?
listに参照型は格納できないの?
最大の疑問は
なんで状態を持たないのに、list.sort()をlist2変数に格納してるの？
letしたってこと？、
varだとまるっきり意味ない宣言だよね？
そのコードだとパフォーマンス低下以外の何のメリットがあるの？
その短文でここまでツッコミ所あるとか何もわかってねえわ
り
リストと配列の区別もつかないやつがオブジェクト指向にたいして何か言えると思ってる時点でキチガイだろ、レベル低すぎなんだが
999:デフォルトの名無しさん
17/04/02 20:10:24.77 T05HwBIb.net
>>966
おおよそおっしゃる通り
オブジェクト指向言語だからとオブジェクト指向でしか書けないわけではないからな
必要なのは指向への固執ではなく選択すること
1000:デフォルトの名無しさん
17/04/02 20:10:31.32 l1VJjSJU.net
何？新しいお題あるの？
1001:デフォルトの名無しさん
17/04/02 20:12:40.21 T05HwBIb.net
>>967
パラダイムが異なれば破綻の定義が変わってくる
それはスパゲッティになることとはイコールではない
1002:デフォルトの名無しさん
17/04/02 20:16:26.26 l1VJjSJU.net
配列とかのソートは関数型が強過ぎてオブジェクト指向で語る気にもならんな
1003:デフォルトの名無しさん
17/04/02 20:18:16.49 T05HwBIb.net
>>972
friendは諸刃の剣だからな
正しく使えば強い剣にはなるのは同意
C+は良くも悪くも開発者のスキルに依存しすぎるのがアンチが多い理由
1004:デフォルトの名無しさん
17/04/02 20:54:50.53 VFzZvOnH.net
>>976 まくしたてて煙に巻くタイプだな >オブジェクト指向の文脈において、不変性はパフォーマンス低下以外の何のメリットがあるの? >不変性 まさにお前の懸念してた保守性がよくなる。 どう変わるかわからん隠ぺいされた内部状態にびくびくしないでよくなる。 自分で言っといて１レスで忘れるなよ…
1006:デフォルトの名無しさん
17/04/02 21:02:37.18 cWX073Y/.net
お前ら英語のweとか分かんなそうだよな
1007:デフォルトの名無しさん
17/04/02 21:10:36.70 DzpU0i7z.net
>>982
じゃあこうきこうか
immutableList<mutableClass>
は不変か?
1008:デフォルトの名無しさん
17/04/02 21:17:24.87 VFzZvOnH.net
何がいいたいのかわからんが
名前通りのクラスなら個々の参照先は不変だけど参照先の内容は可変
1009:デフォルトの名無しさん
17/04/02 21:19:07.44 n7h/bBRg.net
構造はオブジェクト指向、
関数の中身は関数型
それが今の時代のトレンドだよ。
1010:デフォルトの名無しさん
17/04/02 21:19:43.59 n7h/bBRg.net
なぜオブジェクト指向言語がこぞって関数型言語の
機能を取り入れているのかを考えてみたほうが良い
1011:デフォルトの名無しさん
17/04/02 21:30:47.41 DzpU0i7z.net
>>985
じゃあ
immutableList<mutableClass>という設計は実装上のどのような利得があるの？
immutableList<Value>は有益だけどこれ関数型そのものだ
なぜ有益なのかはまだ答を出さない
問題はmutableClassを前提としているオブジェクト指向において、言い換えれば参照透過性をみたさないものに対してimmutableなクラスを使うことにどのような実装上の便益があるのか興味があるからだ
1012:デフォルトの名無しさん
17/04/03 08:00:03.70 qOfWhjuM.net
>>972
クラス化は、散逸を呼び排他的になる結果、ほぼ同じ、働きが一緒、意味が似ているものを重複させ、それを増長させる。
風穴を開けるのがフレンド。
所謂、シェア
1013:デフォルトの名無しさん
17/04/03 08:19:13.93 nXV6xz2a.net
>>965
オブジェクト指向を原理主義、杓子定規に当て嵌めるには、
メソッドは動詞か名詞か？
クラス名は固有名詞か代名詞か現象を表す集合か？
媒介クラスとは、物(オブジェクト)であるのか？
つまり、言語仕様にそんな規定がないのだから、その議論はオブジェクト指向の議論でなく、命名規則の原理原則を押し付けているだけ。
識別子に属性つけて、その属性からコンパイラに機械的な検査とコード展開を促すのがオブジェクト指向と言われる言語を指す。
「オブジェクト」ってのが「Googleエコシステム(利権)」と同じバズワード。
エヴァみたいなエポック文学にハマる愚か者なんだよ。
1014:デフォルトの名無しさん
17/04/03 08:25:43.76 nXV6xz2a.net
言いたいことは
オブジェクト指向を学んでも設計技術は磨けない。
設計とは分けること。分ける指標が設計技術の力。
分けた結果をクラスに当てはめて制約する。
クラスをみても設計の指標は書いていない。
1015:デフォルトの名無しさん
17/04/03 09:16:40.43 DYsJriQe.net
それでも他のパラダイムよりは圧倒的に設計指針が明確なのがオブジェクト指向なのだよ
良い言語とは学習コストが小さくかつ凡人が書いてもそれなりに体をなしてしまう言語
pythonやjavaが席巻しているのもそれが理由
関数型の台頭を妨げる理由もそれ
javascript、お前だけは絶対に許さない
1016:デフォルトの名無しさん
17/04/03 09:45:54.68 VDwG6zpG.net
>>991
設計技術ある人間がクラス設計すべきなのはその通りだろうが
オブジェクト指向を学んだら設計力が身につくべきなんてこともないだろ
プログラミング言語の読み方を覚えたら
コードが書けるようになるのかい？
1017:デフォルトの名無しさん
17/04/03 09:47:57.14 MrxLrKt6.net
>>991が言いたいのは
設計で分けた結果を表現するのにクラス（オブジェクト指向）が
必須ということだよ。
1018:デフォルトの名無しさん
17/04/03 09:50:04.72 MrxLrKt6.net
赤い車、青い車。
こういうのを関数型ではうまく表現できない
1019:デフォルトの名無しさん
17/04/03 09:53:24.49 28dsjWMc.net
>>992
学習コストの大きいプログラミング言語なんてあるの？
（日本語の情報が少ないとかの固有の条件は除いて）
1020:デフォルトの名無しさん
17/04/03 09:55:23.85 DYsJriQe.net
>>996
むしろ全ての言語の学習コストが同じだと思っているの！？
1021:デフォルトの名無しさん
17/04/03 11:06:38.65 28dsjWMc.net
>>997
「大きいものはない→全部同じ」
が成り立つ世界で生きてるの？
1022:デフォルトの名無しさん
17/04/03 11:36:04.05 Gsk36gq9.net
設計とか表面だけで実装の部分を知らない者がオブジェクトを万能薬と思って推し進める
プログラムを書いた事無い者が口を挟んで炎上みたいなものか
オブジェクト指向はいいんだけど
1023:デフォルトの名無しさん
17/04/03 11:58:12.00 e66yg0jR.net
end
1024:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています