カプセル化は愚かな考え
■ このスレッドは過去ログ倉庫に格納されています
■危険性
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。
大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) Microsoftは世界最大規模の研究所を持ってるから、Windows Fを出してくる可能性がある。
すでに待機中かもしれん。 >>367
いつまでに？ｗ
お前にどれだけ自信があるかわかるね
短くすればすぐに外れたのがわかる、長くすれば自信がないｗ >>369
ほんとバカだな。
それは技術の話か？
Microsoftの戦略次第だろうが。
Maicrosoftに聞け。 このスレにいくつかのアイデアが埋まっている。
気づいたものが次世代ウィンドウシステムを作るのだろう。
それが関数型ウィンドウだ。 >>370
ほらな、かってな予想を立てて、自分の予想に自信がないｗ 全て不変にすれば、パフォーマンス以外の問題点は解決する >>318
だから言ってるように、オブジェクト指向は否定してない
オブジェクトの操作を、クラスで書くか、関数で書くかっていう記述方法の違いでしか言ってない
関数はスカラー関数に限ってない
流れがプロパティ保持の話ばかりだけど、その程度ではクラスにする必要ない
クラスの特徴はメソッドと継承
そのメソッドが外に出てるのがスタティック関数
書く場所が違うだけで、機能は同じ
Oｂｊ.Close
Close（ Oｂｊ ）
の違い
で、実は後者の方が生産性が高い、ということもあるかもしれんねと（体感）
かといってWinAPLみたいに長い名前の膨大なグローバル関数がずらーっとあると、生産性低い
そこは子クラスでなくても、名前空間で分類するだけでも整理が付くので、工夫次第
さらに外人の「動詞＋目的語」じゃなく、「主語＋動詞」という命名なら分類ごとに並ぶ
× OpenObj、CloseObj
〇 ObjOpn、ObjClose
（クラスのメソッドなら後者の並びになるが、なら関数名自体もそのセンスでいいじゃんていう）
継承は、いろんなイベントで共通の処理があるフォームのバージョン違いだと、ごっそりソースは減る
でもイベント関数自体を共通にして、中で条件分岐の方が見通しがいいかもしれない
（エクセルでシートイベントに対するブックイベントみたいな）
クラス継承は、継承の様子は掘って掘ってしないと調べがつかないので >>374
>書く場所が違うだけで、機能は同じ
ポリモーフィズムの実現方法が異なるというのが本質的な違い
変更要求に対してコードの修正範囲が変わるのでどちらがいいのかというのは状況による
obj.close()はobjがclosableであればいい
close(obj)はcloseがobjの型をサポートしている必要がある
len([0,1,2,3]), len(“foo”)と[0,1,2].length, “foo”.lengthの違い
namespaceやmoduleのサポートが貧弱な言語だと前者は名前空間を汚染しやすい >>375
“foo”.length はまたややこしい話で
実装はスタティック関数ってこともある（C#の拡張関数）
これは間違いなく生産性高い
むしろそこからスタティック関数の方が生産性高いのではという発想
改めてメソッドを実装しなくても無限に連鎖できる
“foo”.length.text.length
関数は元々無限にネストできるが
length( text( length("foo") ) )
ただし括弧が見にくい、起点が後ろの方にある、組の引数が遠いとこに分かれる、ので眼精疲労が起きる > これは間違いなく生産性高い
それはどうやって計測したのか言ってみ 実装がスタティック関数 → スタティック関数は生産性が高い
ならば
実装がスタティック関数ではない → スタティック関数は生産性が低い >>338
16年この業界にいる現役だよ。
むしろ、一般人ががプログラム言語なんかに興味持つ方が驚き。
現場で使えない派遣のプログラマーをアマグラマーって馬鹿にしてるけど、アマチュアさんいるんやね。プログラムは好き勝手に書いてた方が楽しいよ。
囲碁とか将棋のプロがアマを見る気持ちがこのスレで分かった気がする。 >>376
おまえ、それ、マルチスレッド処理でも同じこと言えんの？
GUIの話してんのかわからんけど、異なる複数の処理がスタティック関数にアクセスすること考えてないだろ？
なんか、Cでmalloc使わない！って豪語して、スタックオーバーフロー起こしてどうしていいかわからなくなってたPG思い出したわ。 >>380
そりゃ、自分より年寄りはいるだろう。
すごい人もいっぱいいて、日々勉強だわな。 そりゃ恥ずかしいと思わないと。
この板は文法やライブラリの使い方を取り扱う板。
プロが欲するのはお客様の情報で、ここにいるべきではないだろ。 >>381
某大手メーカー系が何年も直せなかったマルチスレッドで起こしてるバグを小一時間で直してあげたことあるよｗ
（マルチスレッドで確率的に起きる事故はステップ実行で探せないから、勘が必要）
関数がスタティックかどうかと、処理がぶつかるどうかは無関係
組み込み関数を想像すれば分かるだろｗ
各スレッドがその関数に渡すインスタンスが別ならぶつからない
同じインスタンスの必要があるならシリアル化するだけ
そっちこそマルチスレッドの扱いが曖昧っぽいなｗ >“foo”.length はまたややこしい話で
>実装はスタティック関数ってこともある（C#の拡張関数）
>これは間違いなく生産性高い
>むしろそこからスタティック関数の方が生産性高いのではという発想
このあたり失笑なんだけど
こんなちっちゃい部分にクローズアップして生産性を語られても しかも"foo".length()が実装はスタティック関数なのは
C#が提供してる拡張方法がそうなってるだけで
データと処理を紐づけてるのはオブジェクト指向そのものじゃないか オブジェクト指向とはオーバーロードである。
ってことも無いのでは？ オブジェクト指向＝○○ではなくて、
オブジェクト指向はいろんな課題を解決するための
テクニックを詰め込んだ言語
イコールで何かと結びつくものではない
結びついたらオブジェクト指向という必要がないだろ いや、そもそもオブジェクト指向だろうが関数型だろうが便利ならなんでもいいけど
関数型のほうがすべてにおいて優れてるって言いたいという動機ありきで
都合のいい話をでっち上げてるとしか思えない
全体的に根拠がふわふわしてるんだよ こんなふわふわした論理を積み重ねちゃう感じで
本当にプログラムがかけるのかも疑問 >>392
そのとおり
私は状態がない世界に住んでいる
私の世界では引数と戻り値だけで表現できる
状態がない世界では関数型が一番
こういう理屈
現実はたくさんの状態がある世界
たくさんの状態をどうやって管理するか？が難しい
そこに架空の世界を持ってきたって意味がない >>386
プログラミングの生産性は地味でちっちゃいことの積み重ね
管理職やアプリコンサルやその他ペテン師は大きいことを言いたがるから、
多大なコストをかけてマイナンバーカードを作っておいて、未だに当たり前のデータ連携ができておらず、相変わらず無駄な申請
もしくは、ついでに出てきたものに対するついでの返信でしかないものを、「クローズアップ」とする解釈の方が大げさ
>>387
その機能は、あるクラスオブジェクト指向言語、が持ってるのだが、コーディングはスタティックなコストで済む
どの言語を選ぶべきかという話ではなく、どんなコーディングをすべきか、という話
または、いい機能なので他の言語にも付けてね、っていう願望
メソッド風に出てくるのは書式の違いであって、本質的に括弧と違わない
スタティックだと言ってるんだから仕様的にも裏切っちゃいけないし
宣言は length( this string s ) で普通の関数と同じく括弧の中に呼び出し元がある（ちょっと気持ち悪いが） 馬鹿はオブジェクト指向にかぶれるくらいなら関数型にかぶれてる方がまだ扱いが楽。
モジュール分割へたくそなくせにオブジェクト指向にかぶれるとほんま手に負えんモンスターになるから。 >>396
人間の話なんてどうでもいいんですよ
技術の話をしなさい staticが技術的な話なのか。
C++をbetter Cとして使ってくれてればいいよ。
C++使ってんのにどうしてOOPじゃないんだ、とか言わないからさ^^ スタティック関数っていってるの多分javaのスタティックメソッドの方だと思うよ オブジェクト指向から関数型へは、ある程度発想の転換が必要なんだろな。
スレの子たちは転換できてないな。
オブジェクト指向で設計できないから関数型では出来ないというが、そもそもオブジェクト指向の必要が無いのだが。 C++をbetter Cとか言う奴は
C++もCも両方ニワカである >>400
> オブジェクト指向から関数型へは、ある程度発想の転換が必要なんだろな。
必要なのは発想の転換じゃなくて実装サンプルだよ
多数の状態を持つボタンのようなものをどうすればシンプルに実装できるか
その実装サンプルがどこにもないから関数型には無理なんだなってことになってる そもそもオブジェクト指向について、関数型について
きちんと説明できる人っているんだろうか
みんな、なんとなくこういうもの、というイメージしか
持てないでいるんじゃなかろうか >>403
関数型についてはごく小さな例だけをあげて、だから関数型は素晴らしい、といってるのしか見たことないな
自分が書いたのでなくてもいいからだいきぼなプログラムを関数型でうまく書いたという事例があれば見てみたい カプセル化だけではなくオブジェクト指向自体が時代遅れ
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 - Qiita
https://qiita.com/sonken625/items/d5d0f3b8d794e06489bd >>402
>多数の状態を持つボタン
もう少し要件が明確にしてくれる？ >カプセル化だけではなくオブジェクト指向自体が時代遅れ
といいながらScalaを例に出してるけど
「Scala（スカラ、SKAH-lah）はオブジェクト指向言語と関数型言語の特徴を統合した
マルチパラダイムのプログラミング言語である。」by wikipedia
オブジェクト指向も含んでるしもう何が言いたいのか HaskellではMonadで状態というか状態遷移を表現するらしいけど
関数型推しにはそれがどういう実装になるのか例を示してほしいね そんな頼み方で教えてもらえると思ってることに驚いた。 関数型の利点を主張する割にここまで具体的な情報が一つもでてきてない
それともエアプだからわからないとか・・・？！ >>406
要件？HTML（DOM）のボタンでいいよ
https://www.w3schools.com/jsref/dom_obj_button.asp
プロパティ一覧
autofocus
defaultValue
disabled
form
name
type
value
ボタンを作ったら、これだけの情報が初期化されて
作ったボタンからこれだけの情報を取得することも出来る
本当はスタイルもあるからもっと多いけどね ベクトル化の概念が抜け落ちてるんだろうけど。
説明しろと言われても、自分で勉強しろとしか。 関数型言語
button = CreateButton({name: "名前", type: "submit"})
// buttonは連想配列 {name: "名前", type: "submit"}
print(button["name"])
オブジェクト指向
button = CreateButton({name: "名前", type: "submit"})
// buttonはオブジェクト
print(button.name)
こんな感じっすかね？ｗ ボタンの「作成」と言ってるところにセンスの悪さを感じるというか。
きちんと説明してやろうという気力が失せるんだよな。
どうせコイツじゃわかんねーだろうっていう。 じゃあボタンの「作成」以外でもいいよ
お前が好きなように言いたいことを言え
お前はまだ何も言ってない 関数型言語派は、「はぁ〜お前らわかってないんだよな〜」って言うのが目的なので
説明しろといわれたら、説明できなんだよなｗ
そのパターンばかり そもそもの前提からして意味分かんない
何がどうなることを目指してるの？
お互いに プログラミング言語の目的なんて
目的は動くものを（できるだけ簡潔に）作ることに決まってるだろ 俺今丁度、環境変数を扱うコード書いてるんだけどさ、
1. 環境変数を設定する
2. （確認のために）設定した環境変数を表示する
3. 環境変数を残したまま他のプログラムを実行する
これを関数型言語で書いてみて これすごく簡単なことだと思うんだが、こういうのすら関数型言語では実装コードが出ないというねｗ このスレの流れは関数型狂信者がしつこくオブジェクト指向では駄目だと
根拠の薄い主張を繰り返し、具体的なことを聞くと煙に巻く
今の所、関数型推しはやべえ奴という印象しかない >>420
動くもの？
正しく動くものでしょう？
この「正しく」ってのが重要になると思うんだけど >>424
言葉遊びして言い訳はいらんよ
さっさとやれ ソフトウェアというのは多数の「状態」をどうやって管理するかってことに尽きるんだが
関数型言語は「状態」が少ない場合はこれでうまくいくという話しかしない
多数の「状態」を管理する方法ではなくて、少数の「状態」を管理する方法しかいわない
多数の「状態」という問題の解決方法ではなく、問題をすり替えてる 正しく動くこととオブジェクト指向になんの繋がりがあるの？ 関数型言語にとっては正しく動くことが課題なので・・・
バグばかり まじでろくなやついないな
関数型を嫌う理由として十分だわ >>432
お前もコード見て何がどうなってることを確認したいの？ >>433
どれくらいの複雑さになるかを確認したい 簡単なコードなんだからぐずぐずせず
さっと出したほうが早いのに
言い訳してるってことはエアプか 結局、何もかも前提がない
いいソースとはどういうソースを言うの？
っていう単純な前提がないから
全てにおいて結論が出せない
十年以上もコード組んでるくせに
こんなこともわからない時点で
そんなに能力高くないんだよお前ら いい悪いを議論する前に、まずコードを出さないと意味がない
動くコードを出しましょう >いいソースとはどういうソースを言うの？
初心者みたいな質問出たぞ もし、コードで判断をするなら全く同じ処理を記述した
方式Aと方式Bの両方が必要になるはずなのにそれも用意しようとせず
片方だけ集めたってしょうがねぇだろバーカ
お前のソースなんてみる必要すらない >>444
> 1. 環境変数を設定する
> 2. （確認のために）設定した環境変数を表示する
> 3. 環境変数を残したまま他のプログラムを実行する
>
> これを関数型言語で書いてみて
ENV["FOO"]=123
print(ENV["FOO"])
system("bar.exe") そもそもまともな思考ができてねーじゃん
本当にその程度でプログラム組めてるのかよ
恥を知れバーカ >>444
>>447で関数型ではない状態を変更するコードを書いた
関数型はまだでないのか？ >>413
それら全部状態って呼ぶのかぁ
とりあえず言いたいことは理解した
elmのチュートリアル1ページ目のサンプルコードで
HTMLのボタンも作ってるから見てみるといいよ
https://guide.elm-lang.org/ インスタンスの代わりに、連想配列を受け取って連想配列を返す
それが関数型
状態はメンバ変数の代わりに、連想配列に入っている
連想配列.メソッド(); これがオブジェクト指向で
関数(連想配列); これが関数型
ということでOK？ そもそも、時間の流れがある≒刻一刻と状態が変わる、というパラダイムがある
例えば3Dアクションの全てが四次元プログラミングになる
x,y,z,tの四変数が必要になる
GUIは三次元プログラミングで、x,y,tの三変数が必要になる
未来がどーなるかは分からん、ってのがダイナミック、
一度決めたら未来永劫変わらない、ってのがスタティック >>456
違いません。
という反論で十分やなぁ
理由も言わないお前に対してはｗ いちいち理由を説明してもらえるのは小学生までやろな
自分で学ばないやつは数十年前にオブジェクト指向理解できなくて既存のパラダイムに囚われてた老害たちと同じ道を辿る >>459
俺なんかそれ怪しいと思ってるんだよね
オブジェクト指向ってどこをどう探してもメリットねぇよコレ
何でこんなもん広めたんだ？
俺これのおかげでソフトウェア業界何十年停滞したかわかんねぇぞって思ってる 一つのコンピュータ内に複数のプロセッサがある状況になって、俄然関数型が注目されるわけです。
しかし関数型には、数学的思考力が無いと使い方がわかりづらいという欠点があります。
オブジェクト指向でさえパターンを提唱した人たちがいるのです。
世間を侮ってはいけません。
あなたが思うよりずっと低能です。 コンピュータは電子計算機なので、関数型は非常に素直なアプローチです。 ■ このスレッドは過去ログ倉庫に格納されています
