オブジェクト指向はオワコン？

教えてくれ

前スレ
オブジェクト指向はオワコン
https://itest.5ch.net/mevius/test/read.cgi/tech/1693054853

糸冬

了

もういいだろこのスレは

議論を再開します

90年代にオブジェクト指向が隆盛を極めて失敗したのには理由があると私は思っている

オブジェクト指向同様にメモリ食いの関数型指向は許されているのかな

関数型がメモリを食うのは初耳、どこ情報よそれ

Javaはオワコン位のものを、オブジェクト指向がオワコンまで話をデカくしすぎ。
Javaが関数型言語的な記述を取り入れてきたのを、これからは関数型言語だみたいにいいすぎ。

>>1
板のルールすらわからないのか。どうしてもやりたいならマ板でやれ
そもそも当たり前に使うオブジェクト指向無しでプログラム組んでたらやってられんわ

こいつはオブジェクト指向というかプログラミングに挫折した人間だから仕方ない
ほっとこう
もう立ち直ることはないんだし

Rustも隆盛を極めて失敗するだろうな

>>6
>5とは別人だけど、こんなの見つけた。

関数型言語のウソとホント
https://qiita.com/hiruberuto/items/26a813ab2b188ca39019

マジレスするとこんなところで暇潰してるお前らがオワコン
2，3年後にはウーバーに転職してそう

>>13
まじでかw
プログラムのプの字からやり直さなきゃならない奴が吠えてるだけのスレなんだぁ

>>13
オブジェクト指向関係なくて🌱

自演がバレバレで面白かったのでヨシ！ >>12-14

一応コード書いてるだけでも偉いと思えるようになってきた

こんなスレであれこれ書く前に動くもの作れよ。小学生でもできるのに

>>13
単にチミがappendChildの仕様を理解出来て無いからだ

Reactの
import React from 'react'はクラス継承？

interfaceで受取するだけなら楽だなあって思った

AIにできるだけクラスは作るなと指示する時代になった

現場みてると、手続型言語のように使っているので気持ち悪い。
対象にメッセージを送る。ただこれだけなのに。
設計ができていない。

そう言う本来のオブジェクト指向プログラミングができるのはObjective-Cくらいだからなぁ

現場のjavaみてると、intとStringのオンパレード。なさけない。
クラスを作れよなぁ。

わかりやすくモデル化できるところを
プリミティブ型だけで低レベルに書く本人は
頭良すぎて困ってないんだろうけど
凡人が困るのわかってない点で社会人として失格よね

昔なら、メモリ少ないし遅いのでプリミティブでがんばってもよかったけど、
いまは、可読性だね。
nullポはいまだに最悪だけど、バグを出しにくく可読性の高いものを作るためにオブジェクト指向があるのに、
手続き型言語のように使われている/そのような設計しかできないのは、なさけないね。

例外のせい

どういう例外なんだろ。単に設計の手抜きを例外にしているんだろうか。
まあ、ちまたのシステムみてると、完成度20％未満で動いているからねぇ。例外だらけなんだろうけど。
なんで検収あがっているのか不思議なものばかりしか見かけない。元請けが素人なんだろうねぇ。クライアントも素人。

>>24
それ30年前のオブシコの思想だよｗ

OOPネイティブ世代がそのうち
「やっぱOOP最高だと思うんです」
とかいうブログ書くと思う😮

論破するから大丈夫

https://twitter.com/yasuo_ozu/status/2011074844113444894
https://twitter.com/thejimwatkins

JavaやC#やいまどきの言語自体がオブジェクト指向なんだから諦めろ

JavaやC#が今時の言語・・・？

株式会社アイ・エス・ビー
https://kizuna.5ch.net/test/read.cgi/infosys/1756826944/

https://www.isb.co.jp/about/company-profile/

>>32
・データを中心に設計する
・データ構造にこだわる
と
・全部入りのstructを作る
が繋がらんのよね
オブジェクト指向でもないし
ちょっと何言ってんのかわからないな

まともに相手するレベルのツイートじゃないな
OO言語とか全然関係ない

データを中心に設計したりデータ構造にこだわるのは対象ドメインがデータ/データ構造が核となっているビジネスアプリケーションだからと単に動くソフトウェアをつくりたいんじゃなくて変化に対応できるソフトウェアをつくりたいからなんだよね

別にOO言語にこだわる必要はないと思うけど
OO言語を揶揄する人がこう低レベルだとOOのほうがいいのかもって思う

>>36
俺も何言ってるのかわからなかったがココを見たらわかった
https://posfie.com/@IBkBoH1deg98072/p/DJny8h9

オブジェクト指向をプログラミングに不慣れな人に意識させると
過剰設計になりがちってことかな

自分が出会った人の中にも
思考停止でgetter/setterを作るアホや
プログラミング初心者を名乗りながらオブジェクト指向では
こうあるべき論を振りかざして動くプログラムを作れないアホがいた

オブジェクト指向に対する憧れや理想がアホを養成するんだと思う

かくいう私も昔そのアホの一人でね

良い感じにオブジェクト指向できてるなって思ったのは
手続き型や関数型で実装して
最後に他者に使わせる部分だけをオブジェクトとしてまとめたものだった
手続き型をしっかりやるのが良いように思う
オブジェクト指向は実装の技術じゃないAPIの技術だ

OOPの核である多態は実質的にifブロックをメソッドに置き換えてるだけに過ぎない
あとは糖衣だよ

なんか色々聞きなれない言葉並べて再利用性がどうのこうの言うけど絶対嘘じゃん。

コード書き換えた方がよっぽと再利用してるし、柔軟性あるし、素朴だし、シンプルだし、やりたい事出来るし、理解早いし、間違い起きないし、再利用するコードの実装もシンプルだし。

それともオブジェクトどうしの対話がどうのこうの観点から再利用性あるとか言う話なのかな。
そんなの再利用する事なんて無いだろ。

オブジェクト指向に対する理解がオブジェクト指向黎明期の誤った啓蒙書ベースのままだからオブジェクト指向は使えないとかオブジェクト指向から抜け出さないといけないとか思っちゃうんだろうな

昔はプログラミングパラダイムの革命としてもてはやしてたからな
今となっては数ある使い古された技術の一つに過ぎない

言語バカがマウント取るための道具でしかなかったなｗ
継承に異常に拘りそれが目的になって無駄なクラスが量産され保守困難になる本末転倒ぶり

マウント取って威張るのが本当の目的なんだから本末転倒じゃないよ
その結果として開発しにくかったり、使いにくくても二の次

おじいちゃんたちはいつの話をしてるんですか？
オブジェクト指向ごときでマウント取られたと感じてたようでは新しい言語やパラダイムにはどれもついていけなかったのでしょう
仕事だけでなくプログラミングも引退した方が幸せになれますよ

クラス関数に同じ名前のメソッドがあるのはオブジェクト指向の恩恵だぞ

クラス関数？

クラスもメタクラスのインスタンスなのと
クラスがただのインターフェースな実装は
LISP1とLISP2の関係に似てて同列に語れるときと語れないときがある

設計ミス
javascript: bool
Java: a[][]
python: setdefaultencoding
C: static
C++: private
Rust: unwrap

>>49
何言ってんだお前これを見ろ
https://compilebytes.com/share/nbdiKnVCvf

PowerShellで書いたNano IDだ
オブジェクト指向を使わない方がどう考えてもスッキリ書けるだろ

Nano ID
https://github.com/ai/nanoid

悔しかったらオブジェクト指向で書いたお前のNano ID見せてみ？ おん？

>>54
おじいちゃん論点ズレてるよ
おじいちゃんがオブジェクト指向を理解できなかったのは日本語の能力が足りてなかったのが真の原因かもしれないね

>>55
書けないのな？ オブジェクト指向ごときと嘲ったお前が
オブジェクト指向で俺のコードを超えることできないのな、ギブって事で良いな？
お前でさえオブジェクト指向を使いこなせないわけだから
オブジェクト指向はダメなものって結論されるわけです

俺はいや俺たちはオブジェクト指向を完全に理解しているからこそ
その限界もわかっているんだよ

霊媒師が幽霊を退治できるのも幽霊を理解してその限界を知っているからだ
あなたにはオブジェクト指向の幽霊が取り憑いています
俺はそれをPowerShellで除霊しました
俺のコードみて綺麗すぎて震えただろ、わかる

手続き型で書いたNano ID
https://compilebytes.com/share/nbdiKnVCvf

オブジェクト指向が良いものだと言うならば
俺が手続き型で書いたNano IDを超えてみろ

かかってこいよオブジェクト指向
オブジェクト指向の限界を知っている俺に隙はない

自演でスレ伸ばすのやめな

オブジェクト指向を理解してないと
オブジェクト指向技術によって恩恵が受けられる場面と
そうでない場面の簡単な判別ができないんだな

それに自分のコードのどこで
オブジェクト指向技術が活用されているか分からないらしい

まあそりゃそうか

staticおじさん統合出張中か

言語バカの系譜
オブジェクトおじさん→フレームワークおじさん→Rubyおじさん→TypeScriptおじさん→Reactおじさん(👈今ココ)

蓄尿フェーズ（Storage Phase） 膀胱が徐々に充満 → 膀胱壁の伸張受容器（stretch receptors） が不随意に活性化。
これが「膀胱満杯イベント」のトリガー（afferent signals via pelvic nerves）。
仙髄レベルで排尿反射（micturition reflex） が起動しかけるが、大脳（pontine micturition center + 前頭前野）が「まだだ！」と抑制。
→ これはイベントリスナーが登録されているけど、条件分岐でキャンセルされる状態。
外尿道括約筋（随意筋・横紋筋、陰部神経支配）：意識的に締めておく（voluntary contraction）。
内尿道括約筋（不随意筋・平滑筋、交感神経支配）：自動的に締まる。
→ 「我慢ボタン」を押してる間は、イベントが保留（deferred）。

排尿開始の瞬間（Voiding Phase） 脳が「OK、出す」と判断 → 抑制解除。
副交感神経（骨盤神経）優位 → 膀胱排尿筋（detrusor muscle、不随意平滑筋）が収縮。
内尿道括約筋が弛緩（不随意）。
外尿道括約筋も弛緩（随意）。
同時に腹圧増加（腹筋・横隔膜の随意筋収縮）で勢いをつける。
→ これが「排泄メソッド」の本実行！ イベントが発火してコールスタックが一気に動く。

割り込み（Interrupt）の例 膀胱圧が限界超え → 不随意反射 が強制起動（reflex voiding）。
「もう我慢できない！」で脳の抑制が効かなくなる → 漏らす。
→ これは優先度が高いイベント（hardware interrupt）がメインスレッドを乗っ取るようなもの。

>>58
これオブジェクト指向とか関係なく普通にスパゲッティじゃん
整理整頓できないのかよｗ

>>65
誰がおしゃれパスタだおらあ！！！
じゃあお前が書いてみろよ！どうせ口だけだろうがたわけが！

動けばなんでもいいんだよ

それもそうだな

オブジェクト指向はそもそもの考え方が危ういんだよな
オブジェクト指向の概念認識は認知言語学でいう定義的属性によってカテゴリ化する古典的カテゴリ的概念だから
家族的類似性やエグゼンプラー、プロトタイプによって規定される現実の概念とは乖離があるんだよ
クラスという大枠を定義した後でメンバ群やサブクラス群を定義するのではなく
オブジェクト群にタグ付けを行なった結果として、共通あるいは類似するもの同士からなるクラスのようなものが形成されるのが正しい

「オブジェクト指向 == クラス」「クラス == オブジェクト指向」という古き悪しき教えに毒されたままだからそんな考え方をするんだろう

オブジェクト指向をフル活用するほど複雑なプログラムって
相当に高度な頭脳が必要なんでしょうな🤯

現実の概念との乖離を無くそうとする考え自体が間違い
“クラス+継承=オブジェクト指向”とともにオブジェクト指向黎明期に広められた有害な教えの一つ

>>72
現実の概念って言うか、誰もが連想しやすい形にした方が多人数で生産する場合に説明しやすいし、それが必要なだけだから

カプセル化とインターフェースだけで良かったと
COM(OLE/ActiveX)で証明された

おじいちゃんホイホイスレｗ

結局javascriptがいるからオワコンになるのは相当時間かかると思うけどね

それJavaScriptが使えないおじいちゃんの意見ですよね？

集約（Aggregation）
「俺と繋がってるけど、意志的には独立」というのは、まさに集約関係ですね。チンポは「俺」という全体の一部でありながら、
完全に意志の支配下にはない。たとえば勃起は意識的な命令だけでは起こせず、状況や刺激に依存する。この独立性は、
集約されたオブジェクトが親オブジェクトに依存しつつも独自の振る舞いを持つというOOPの特性をよく表しています。

継承（Inheritance）
「俺の特性を引き継ぎつつ『別チン格』として独自性を持つ」というのは秀逸です。遺伝子的に「俺」から派生した器官でありつつ、
その振る舞いや反応は「俺」とは異なる個性を持つ。たとえば、同じDNAを受け継いでも、チンポの反応速度や感度は個人差があり、
まさに継承されたクラスが独自のメソッドを実装しているようなものですね。

>>78
お前面白くないわ荒らすな

>>79
ならそういうお前が、「オブジェクト指向とは何か」を、自分の言葉で誰にでも分かりやすく説明しろ

>>80
オブジェクト指向とは何かを説明するスレッドではない
もう荒らすなよ、お前のせいで書き込みがなくなるからな

>>81
つかそもそも「オブジェクト指向」とは何だ？

javascriptのprototypeをオブジェクト指向じゃないと言うような話がしたいのか

>>83
命題「オブジェクト指向とはjavascriptのprototypeのことである」

確かに、陰茎はまじめに考えたら教科書に載せてもおかしくないくらい完璧な「生きているオブジェクト」の実例です：多重継承：随意筋（骨格筋）＋不随意筋（平滑筋）のハイブリッド
別スレッド：性的興奮時の勃起は自律神経（副交感＋交感）が裏で非同期処理してる
遅延束縛：射精直前まで「出るか出ないか」は実行時に決定（まさに動的バインディング）
メッセージパッシング：脳 → 脊髄 → 海綿体に「fill_with_blood()」メッセージが飛ぶ
カプセル化：内部の血管拡張・NO（一酸化窒素）シグナルとか全部privateで、外からは硬さしか見えない
ポリモーフィズム：状況によって「排尿デバイス」「生殖デバイス」「快楽デバイス」に変身

アラン・ケイが「生物学的コンピューティング」を提唱してたのは本当で、彼はまさにこういう「生きてるオブジェクト」を理想としてたんですよね。結論：チンポはSmalltalkよりもオブジェクト指向が徹底されている究極の生物学的Artifactであり、我々プログラマは日々「祖先のリファクタリング結果」をぶら下げて歩いているという厳然たる事実。

もうめんどくさいから全部オブジェクトにしちゃえーは
プロトタイプを開発する時にたまにやる
何を抽象化して何を抽象化しないかに頭を使うより全部クラスにしちゃった方が早い場合があるんだ
手を動かしながら詳細設計するなら、あらゆる概念を細かく抽象化していくのは有効

クラスにするのがオブジェクト指向じゃなく、一定の機能を持つ部品を使うのがオブジェクト指向。それをクラスと呼ぼうが関数と呼ぼうが同じ
今のパソコンやスマホはAPIを使うのが当たり前だからプログラム作るときは意識してなくてもオブジェクト指向になる

>>85
荒らすなって言ってんだろうがカス！！！面白くねえんだよ！！！

>>88
なら「オブジェクト指向とは何か？」について、誰にも分かりやすく説明しろ！

拾い物だけどおすそわけ
/watch?v=Hi9YnZL4McU
/watch?v=GWZf_B129zs
/watch?v=Zmr3i9RvFJw
/watch?v=g_xqrXcwN88
/watch?v=r6VWsq4qEEM

まずはカプセル化だろ。

カプセル化はモジュール化+インターフェース定義
OOの専売特許でもなんでもない

マジな話、オブジェクト指向プログラミングって要る？
クラスの構造とか考えるコストとか
正直ベタで書いた方がマシじゃね？

それはない

普通にデータベース指向でいいわな

そりゃまた粒度の違う話だわな

話の抽象度が噛み合わないやつって100%センスない
なぜかそういうやつに限ってOOを軽視したがる

人が分かり易い機能単位にするのがオブジェクト指向だから
分からないクラス分けとか設計がうんこなんだろ

関数も変数も配列も要らん
全部エクセルの表にして行と列で計算すりゃいいんだよ

wikiのOOPの定義

オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming, OOP）とは、データの状態とそれを操作する処理を一体として扱う「オブジェクト」を基本単位にソフトウェアを構築するプログラミングパラダイムである。

OOいらないって言うやつはDIP知らないんじゃない？
ベタ書きでいいって言ってんのはこれか単に作ってるシステムが超小規模かじゃないかな

>>92
>カプセル化はモジュール化+インターフェース定義
これ「モジュール化」と「カプセル化」の意味や関係を理解してないよな？

staticおじさん多いな

オブジェクトとは対象のことであって、
何と戦うのかを明白にするのがオブジェクト指向。
基本的に動詞が中心の英語的な構造になる。
となると、日本語的な構造のプログラムって？ どんなんだろう。

オブジェクト指向よりエージェント指向の方が理解しやすいから
今ではみんなエージェント指向になった

>>105
何言ってんだこいつ

オブジェクト指向って勘違いしてる人が大半だから話がまとまらないんだよな
is-a関係作るくらいなら手続き型で書いた方がいい

アラン・ケイ的オブジェクト指向(非データ・非同期・疎結合)、エージェント指向と
データ指向のクラスとは抽象度の度合いが違いので別物と考えた方がよい。
ゴリゴリに数値演算するようなものではなくて
サービス・モジュール・階層の概念が持ち込めるものに向く。

>>93
必要な機能はフレームワークなりライブラリなりで提供されるからアプリの開発はベタ書きで十分なことが多い、ベタ書きで十分にわかりやすいものを下手にオブジェクト指向で書こうとするとオブジェクトの迷路が出来るだけ

メソッド分割も積極的にやらない方がいい、最初はベタ書きにして共通の部分が切り出せそうなら切り出す形で良い

>>103
ボブおじさんがクリーンコードアーキテクチャを発表していろんな人がそれに乗っかったけど得られた結論はクリーンコードアーキテクチャ必要ないなってことだった、クリーンコードアーキテクチャは廃れたしボブおじさんももう過去の人となった、時代はスタティックおじさんなんだよ

UNIXのより悪い方が良い原則だよ
オブジェクト指向を頑張ろうとするほどコードはゴミになる、スタティックを頑張っていればオブジェクトなんてのはあとからついてくる、オブジェクト指向を意識せずに自然とできたオブジェクトが良いオブジェクトなんだよ

あえて雑に書くと

OOP←悪くない
クラス←悪くない
クラス設計←難しい
クラス設計が難しいこと←知られていない
自分が野放図にクラス設計してできたクソクラスのクソツリーをもってしてOOPやクラスを批判しだす現象←まれによくある

オブジェクト指向という言葉が悪いよな、オブジェクトを中心にプログラムを組まないといけないんだと思わされる、オブジェクト方針とかで良い、オブジェクト曖昧でも良いくらいだ、それくらいオブジェクトはプログラミングで重要ではない

OOPの何がそんなに気に入らんのや
というかその場合設計どうしてんの

設計にオブジェクトなんて書かないだろ
あんなもんは実装するときに明らかになっていくものだあんなもんわな！(憤怒

オブジェクトって対象のことだから、
これを書かない設計は読めない。

>>116
> オブジェクトって対象のことだから

何言ってんだお前

構造化プログラミングすら分からない奴がOOPなんか分かるはずも無いんだよ

配列志向で充分

オブジェクト作ったら勝手に実行してくれりゃ別だが
結局やることは手続き型と変わらん

何がいいたいかわからん
配列志向なんて初めて聞いたわ

OOP適応障害を発症したまま引退したけど未だこじらせてるお爺さんと見た

それそこまで動的にする意味あるんか？ってコード書く奴がうざいってのはある

foo.bar()のようなコードを書いた時にfooの具体型によってbar()の実装が選択されるのがオブジェクト指向よりな言語の考え方
bar(foo)のようなコードを書いた時にfooの具体型によってbar()の実装が選択されるのが関数型よりな言語の考え方

これらの機能が言語に備わっていない旧来の手続き型言語だとオレオレフレームワークを自分で作るなどかなり面倒くさいことをしないと同じことが実現できない
生産性的にも品質的にもデメリットしかないのでプログラミング言語を選べる環境でそんなことをする人はいない

Cならポインタで書けばいいんだよ？
なんか難しい事ある？

ポインタバグるやん

>>125
バグるのはお前のせいだから

>>126
でもよおコンパイラが防いでくれても良くないか

>>127
これ
言語側でどうにかしてほしいと思うことは怠慢じゃない

Cの規格外だけどそういうの見つけてくれる静的解析ツールはたくさんある

自分はOOP好きっす
特に読むとき

js系のコールバック渡しまくりは読むの大変

>>124
難しいかどうかの問題じゃないよ
それにポインタだけだと原始的なものしか実現できないよ

全部エクセルのセルみたいな感覚で配列組んで作るのが簡単よ

>>132
どういう意味

>>131
とりあえずテンプレートみたいな変態性癖以外のC++相当は記述出来るやん

型が互換でもコード上別名ならコンパイラや外部ツールが警告するように整える
制御用のコメントやpragmaが多くなるけれど

ただのテストプログラムだけど、実行時間計測がロジックに入り込んでいたので、
Watchクラスにして分離した。
実行本体と関係ない変数とロジックが隠蔽され、ソースがスッキリした。
CからJavaへの移植。
関係ないものは分離して、関係のあるものはまとめる。
まとまりとまとまりの関係に整理する。関係そのものもわかりやすく修正する。
んー、OOPは整理BOXかな。

んー。OOPSは関係を整理するってことだな。
手続き型がちらかして手を付けられなくなったゴミ屋敷を整理するのがOOPS。
ではなくて、最初から散らからないようにするのがOOPS。

だから全部エクセルのセルみたいな感覚で配列組んで作れば
とっちらかることもない

>>138
ずっと何言ってんのかわからない、なんかプログラム書いてみて

Cでベタに書いてたのが良かったのであって最初からオブジェクト指向やろうとするとダメなことが多いこれガチ情報

ベタ書きはそれだけ優れてるってこと

GUIパーツとは相性が良かったんじゃないの？

アプリのウインドウをダブルクリックしたときに呼ばれるメソッドだけ
サブクラスでオーバーライドして、そこだけ好きな動作を追加する、とかできたし

単なるまとめ方の方法の一つってだけだからな。
アホが使っても自己満足な整理にしかならんのよ

staticおじさんまだいるのか

再利用なんかせんやんな

アプリの開発は水物だからな、再利用するにしてもコードのコピペで十分

>>144
こういうあほがしょーもない俺様フレームワーク使いたがらせて嫌がられてんだろうね

人間はなんらかのオブジェクト単位で考えるのが簡単なんだから廃れようがない

ホントこれやね
人間どころか凡そ人類が知りうるすべての知性はこの方法で思考するんだからまあ廃れることはない

んなこたない。
処理から考えるなんてのは普通にあること。

データもなしに処理とな!?

GUIとの親和性がよい

俺はデータ構造とUIと一緒に考えるぞ
何の操作で何が必要かまとめてから
処理を考える

そういう話をしてるんじゃないだろｗ

アルゴリズム設計とか全くやったことないんだろ。考え方がオブジェクト指向に偏りすぎてる。

普通に配列作ってループで回せばいいしな

配列ループおじさんは思考回路までループしてんのか

ルーパーオブジェクトが配列オブジェクトを受けとって処理するといえば過剰な抽象だろうが、
元のロジックに潜んでいた、対象の配列でしか使わないループ処理が露出している問題が露になっただけ。
つまりOOP云々の前に、制御があってあとは処理するだけだろうという考え方は、なにやっても駄目。
データと処理も密結合。

オブジェクト思考だけだとECSみたいにプロセスごとに分けて持たせるとかはなかなか思いつかないよね
デザインパターンの習得も必要だと思う

いまの子どもたちは学校の授業でオブジェクト指向習うのかな

>ECSみたいにプロセスごとに分けて持たせる
俺の知ってるECSとはかなり違う世界線の話に聞こえるが
Entity Component SystemのECSとは別の話？

loopy

オブジェクト指向に限らず、デザインパターンがオワコンになる日は来ない

デザインパターンはUMLやXMLといっしょに20年前に死んだ印象

言語機構に取り入れられたり別の高階関数などにシフトして
ユーザコードで意識して書く必要がなくなっただけ
空気のようにつかってる

それはそうだろうけど
世の中のものを分類したら何らかのパターンに属することに
なるわけで書く必要がなくなったのならオワコンだよ

for文はgo to文で実現されているからgo toはまだ生きてる！
と言ってるようなものじゃん
go toは死にました、残念ながらご臨終です
linuxカーネルではまだ元気に生きてるらしいけどさ

webのguiで現在主流のfluxアーキテクチャはobserverパターンらしいね
面白いよなあobserverパターンは昔のguiのころはイベントハンドラーに使われてたけど
ステート管理の中心にドンと置いたら現代のベストプラクティになるんだもんな

ス

>for文はgo to文で実現されているからgo toはまだ生きてる！
>と言ってるようなものじゃん

>面白いよなあobserverパターンは昔のguiのころはイベントハンドラーに使われてたけど
>ステート管理の中心にドンと置いたら現代のベストプラクティになるんだもんな

こういうのに限ってデザインパターンはオワコンとか言っちゃうんだから失笑するしかないｗｗｗ
まずはObserverからでも学んでみるといいんではないかな

>>169
observerの何を学べと？

デザインパターンはフレームワークや言語機能で代替されるようになったからオワコンだよ
for文はgo to文で実現されているからといってgo to文を学べば良いとはならないでしょ

デザインパターンとは他人が書いたプログラムをどっかの4人が
分類したら21種類になりましたってだけのただの枠組みであって中身は何もない
りんごを見てこれは赤いものに分類しようと言ってるようなもので
赤色を学んだところでりんごのジューシーさにはたどり着けないだろ

学ぶべきはデザインパターンではなくてフレームワークや言語機能の方
デザインパターンを学んでも何も身につかない
observerを学べと言った人もobserverの何を学べば良いのかわかってないし
デザインパターンなんてのは学ぶものでもなんでもない
デザパタ即是空と覚えて帰ってください

まあ無理になんでもクラス化しようとするアホ思想はとっくにオワコンだよ。

staticパターソ

オブジェクトは他のオブジェクトとは独立して状態を持つことを考えると軽量なプロセスとも考えられて非同期をベースにやり取りすることを考えるとオブジェクト同士のやりとりはプロセス間通信と考えられる、Smalltalk的なオブジェクト指向だ

一方でUNIXはパイプを使って文字列を一方向に流すというやり方でプロセス間通信を実現したわけだがパイプは便利なもので現代でも処理のほとんどはパイプで十分だ、パイプでつなぐコマンドは純粋関数とみなすことができてパイプによるプロセス間通信は関数型プログラミングといえる

オブジェクト指向を頑張るよりUNIXのパイプでコマンドをつなげるようにプログラムをデザインする方が扱いやすいのが実情なのではないだろうか

singletonパターン

最近ECSとかいうの知ったんだが
ゲームならこっちのがいいじゃん
というか、ECSならCでも問題ないだろ。

もう継承で何とかするのむりだわ

オブジェクト指向をクラスのことだと思ってる人がオワコンだのそうじゃないだのと言っても意味がない
「データ構造とそのデータ構造を必要とするロジックを一体として扱い、内部では密結合させつつ外部に対しては隠蔽することで、外部との疎結合を実現して利用やメンテナンスを容易にする」のがOOPの目的で、カプセル化・ポリモーフィズム・合成もこのための機能にすぎない
これはオワコンになるとかならないとかいう問題ではなく、そういうコードかどうかで個別に判断されること

ただ、実装継承はカプセル化を破壊して外部と内部を密結合させる技術なので、OOPを真面目にしたければ用いてはならない
別の用途で使う機能だと考えるべき

実装継承は、基本クラスをきちんと理解した上でないと簡単にバグが入ってしまう。
しかし、
Why extends is evil のArrayListの例はいただけない。
もとからバグっている。
private int stack_pointer = 0;
で、ArrayList側のListサイズと二重管理になるため、clear()などすれば不整合が起きてしまう。
stack_pointerを使用せずに、ArrayList側のListサイズだけで管理すべきだ。
めんどくさいのでインデント無視してそのまま貼るけど、以下でよい。（注：未テスト）
public static class Stack<E> extends ArrayList<E> {
public void push(E e) {
add(e);
}
public E pop() {
return removeLast();
}
public void many_push(E[] articles ) {
for (var article : articles) {
push(article);
}
}
}

おっと、classの中につくったので余計なstaticが入ったままだった。
デフォルト以外のコンストラクタが必要なら追加すべし。
どうしても実装継承が必要な場合であって、そうでなければ、ArrayListをclass内にメンバーとして
かかえこむべきではある。

>>179-180
実装継承の使い方としてそれが成り立つのはそうだけど、オブジェクト指向とは関係のない話と考えた方がいい

オブジェクト指向は、オブジェクトにメッセージを送るだけ。
オブジェクトやメッセージの実体は言語によってそれぞれ。
あくまでも抽象化だけの話。

これからのオブジェクト指向において、圏論でいう忘却（関手）が重要と思う。

>>177
>内部では密結合させつつ外部に対しては隠蔽することで、外部との疎結合を実現して利用やメンテナンスを容易にする
これがいつでも有用に働くと思ってる時点で相当思考停止だと思うけどね。

NetBeansの開発者もオープン・クローズ原則はクローズ・クローズ原則にした方が良いって言ってた、本に書いてあった

>>184
出たよ、オブジェクト指向を銀の弾丸と勘違いしてる人
オブジェクト指向は万能で何にでも使えてどんな場所でもコードがキレイになると思ってるからそういう発言になる
オブジェクト指向ってのは「内部では密結合させつつ外部に対しては隠蔽することで、外部との疎結合を実現して利用やメンテナンスを容易にする」が成立する環境でしか使えない道具なんだよ

>>177
言いたいことはわかるが、そういうものは普通のプログラムだって作れるわけだ
隠ぺいとかしなくても見なければいいし触らなければいい
一から全部作る手間は変わらないし
そういうのって言語の記述方法変えたり増やしたりしていくより
GUIで別枠作ってファンクションブロックみたいなので実装すりゃいいんだよ

文章だけでやろうとするからオブジェクト指向言語に発展していくが
言語でなくツールでよかったのだ

例えばPID制御をする回路を作って、それを枠で括って部品化
それをポトペタで貼って、入力2点と出力1点与えてやればPID機器として利用できるわけだ
その回路の中身はプログラムリストで印字なんか必要ないし表示も要らんのだ
部品として1つの枠が書いてあればいい

プログラミング環境としてはラダー回路の拡張機能って感じで機能増やしていく感じが最高だ

>>187
全てのプログラムで全てのコードを一人の人間が把握できる程度の規模に収まっていれば、たしかにオブジェクト指向は必要ない
しかし現実には全体の実装を把握せずに書かれるプログラムの方が多いので、内部実装と提供する機能を分離する必要が生まれる

たとえば、ライブラリの実装なんかユーザーの大半は知らないわけだけど、内部実装を隠蔽して機能だけを見せているので利用できる
これを一つのプログラムの中でも、複数人で開発する場合などに行うのは有効であるし、あるいは一度に全体を把握できない規模になった時、分割するのに用いることも有用と言える
自分で書いたコードなら何年後でも完璧に把握している、そんな人はそう多くないし、何なら一月でも結構忘れている
しかし、オブジェクト指向で隠蔽がなされていれば、提供される機能だけを考えればよい
他人に使わせる場合でも、内部実装のデータ構造を勝手に使われて、変えられなくなるといったことが起こらない

つまり、オブジェクト指向はその部品化をより進めるための技術であるといえる

それは見える物をいちいち弄る馬鹿が悪いのであって
そんなのを防止するために言語をそれ用にしてまで構築するほどか？ってことよ

それらはツールを駆使して枠括って見えなくして部品化すりゃ済むことだ
文字だけで表現して何かするってのがハナから気に入らない
欧米圏の好きそうなやつなんだろうな

電子回路のハード図みたいに、中身見えなくてもこういう機能のパーツってことで描いて済むってのにさ
CPUチップ1個描けば終わることを、その中身まで全部図示して文字で記述してるようにしか見えん

>>189
さっきも書いたが「全てのプログラムで全てのコードを一人の人間が把握できる程度の規模に収まっていれば」それは正しいな
君はそういう小さなプログラムしか書いたことがないんだろうけど、現実にはそうじゃないものがたくさんありますよって話だ

共通のデータ構造と、あるロジックに密結合したデータ構造を同じように並べておけば、それは自然と「想定外の場所で使われる」という事故を誘発する
ある機能の内部実装に外部から手を加えられる状態であれば、そのようなコードを書く人間が現れる可能性もある
それがオブジェクト指向を行うメリットであり、内部ではデータ構造とロジックが密結合しているが、外部にとっては提供される機能しか見えない、そういった壁を作ることで責務を分割できる

>>190
いや、部品化をいちいち文字だけで表現するなって話
規模の大小ではないわ

>>192
仕様書を書けばどれだけ汚い実装でも正確に読み取れます、と言いたいわけか？
それはそれこそ思い上がりというものだが

「読めるコードを書く」は基本中の基本なんだよなあ

モジュール化のメリットと、モジュール分割の方法論としてオブジェクト思考の考え方を採用するかは一応別の問題じゃないかな。
データとそれに対する操作をセットにすることによってデータに対するアクセス経路を限定し、データの不変条件を保てるようにするというのは優れたアイデアだと思うけど、より重要で寿命が長いのはデータの方だから、あまり密結合を強調しない方が良いのかなとは思う。たとえば、データの方に特定の操作を想定した実装用の擬似属性とかを含めるのは基本的にはあまりよろしくないと思う。

関数型のガワをかぶってるけど
プロセスをオブジェクトと見立てれば
真のOO体験ができるのがElixirさん

>>195
より寿命が長いのがデータとは限らない
たとえば、ハッシュテーブルのAPIはまずハッシュテーブルのデータ構造を作る時に既に使われる上、破棄する時にも使われることで同一の寿命を持つ

>>195
だから全ての関数をクラスに含めてはならないんだよ（Java批判）
データ構造を扱うロジックであれば、そのデータ構造とともにカプセル化してメソッドにするべきだが、そうでないならばいいモジュール化の単位がある
つまり、関数というのだ

staticにすればいいだけだろ
道具の使い方

>>199
全く異なる
staticにしたところでクラスがデータ構造とメソッドを結びつけるものであることは何も変わっていない

くだらねぇ

>>201
一番くだらない書き込み

データベースはオブジェクト指向でないがまともに機能してるしな

Pythonとかだとスタティックメソッドにするよりモジュール関数にする方が現在は好まれる。逆にいうと、Javaとかのクラスは、Pythonでいうところのモジュールとクラスの役割を兼ねているということになるんだろうね。

関数にしたくても引数多いとね

一昔前にリーナスが言ってたオブジェクト指向に向いてるのなんてファイルシステムのドライバーくらいだってのが状況を表しとるわな
言い過ぎではあるが、向いてるのはこのくらいメソッドの役割が明確なオブジェクトに関してなんだわ。

(SmallTalkから見て後発の)オブジェクト指向っていうなればただの"データセット指向"なんだよな
内部データを好き勝手触らせないことを至上命題にしているというか
にもかかわらずオブジェクト指向を名乗るからクラスの肥大化や蜜結合といった余計な問題も付いてきてしまう

メッセージを送ればあとはよろしく処理してくれるという意味でのオブジェクト指向が成立するためには、受信側のオブジェクトの不変条件が維持されていることが前提条件となるわけだし、そこはある程度連動してくるものじゃない？

smalltalkかobjective-c

華麗にメッセージを無視・丸投げして平静を装う派と
例外を投げる派

>>206
それもオブジェクト指向ではなくてクラスと実装継承の話やな
オブジェクト指向のコード自体はLinuxでもあちこちで書かれてて、C言語やUnixにも普通に存在する

>>207
従来の「データ構造」と「ロジック」を結合した「オブジェクト」を設計し、内外を隔絶して区別するから「オブジェクト指向」なんだよな
C++やJavaはこれがわかってないから実装継承とか、名前空間的な機能とかを一緒くたに実装し始めてしまった

「データ構造」と「ロジック」を結合した「オブジェクト」って
独立したマシンでいいよな
そういうのはプログラム内で文章で記述して作り上げるんじゃなくて、別枠でプログラムリストにして済ませりゃいいじゃん

ツール側が、そういう複数の独立したマシンプログラムをまともに動かすようにコンパイルすりゃいい

>>211
全然違う。リーナスはCでの実装での話をしているし、ポリモルフィズムについての話をしている。

>>212
文字列みたいに小さくて何十個も生成されるオブジェクトを別枠のプログラムとして扱うのは現実的ではないのでは。

データファイルが数万個当たり前なのに
別枠のプログラムが何10個程度で苦にもならんだろ

正直、どういうイメージなのかよく分からないんだけど、プログラム中で普通に使えていた文字列をあえて別枠のプログラムとすることに何かメリットあるの？　
数値、bool値、日付、正規表現とかの比較的プリミティブなオブジェクトもすべて別枠のプログラムにするイメージ？

>>212
RPCやCORBAがそれ

>>213
多分勘違いしてるで君

>>212
>>215-216
プログラムの中でも特定のロジックのためだけのデータ構造で、外部に使用されたくないものが発生することは普通にあるよ
そしてただの数の問題ではなく「内外を隔絶して区別する」という部分が重要
外部から使われたデータ構造は、その時点で依存が発生し密結合してしまうので、内部実装の変更に合わせて構造を変えることができなくなる
だからカプセル化して分離しましょうね、ということ

逆に言えば、そうじゃない場合はオブジェクト指向の出番はない

だからそのために文字でやるか
ツールでやるかで、開発言語としてどっちがやりやすいかってことよ

>>203
OracleやPostgreSQLは機能ごとにプロセスが分けられている
プロセスはオブジェクトとみなせるからデータベースはオブジェクト指向ですよ

C言語はヘッダファイルをわけることでJavaよりも強力にカプセル化できるって話をボブおじさんがしてた気がする
Linusが嫌ってるのはC++であってオブジェクト指向的なやり方はC言語でやってると思う
Delphiを作ったアンダース・ヘルスバーグはアセンブリ言語でオブジェクト指向やってたそうだよ
ソースコード整理術としては良いものなんじゃないか

ロボット作る人なんかは全部のデータにアクセスしたいから
あえて全部のデータを公開するようにするらしいね、Xで見た

>>220
何か勘違いしているみたいだが、プログラムの中でもデータをある種のデータ構造として扱うということはよく発生する
その場合、ツールではなくプログラムの中で分離されねばならない

>>222
それなんだよな
C言語でもオブジェクト指向的な設計は珍しくもなんともないし、Linuxの中でも別に珍しくない

>>222
結局言語でオブジェクト指向ってのを文字表現でやる必要性はねーんだよな
言語がオブジェクト指向でごちゃごちゃしてなくても、旧来の言語でオブジェクト指向でつくれるんだしさ

なんか俺様が作った新たな造語集めて言語作ったよー
これに従ってプログラムしろってのが気に入らない

Cとかの言語でもオブジェクト指向で組むことができるという話と、ツールでやれという話はだいぶ違うことだと思うが。

> 言語でオブジェクト指向ってのを文字表現でやる

意味不明

> 旧来の言語でオブジェクト指向でつくれる

つくれてないと予想

非OOPLでOOPやれるとか気軽に抜かすやつは少なくとも職業プログラマではなさそう
お遊びレベルでしかいろいろ触ったことなさそう

「文字」とか「文章」と書いている人は、たぶんオブジェクト指向の概念をサポートする構文が言語に用意されているということを指してそういう語を使っていて、その点に反感・抵抗感を示しているんだと思う。

プロよりも上手いと豪語してる料理系YouTuberかな
そんだけ金と手間かければ美味いに決まってる、
お前それで利益出せんのかとツッコミ入れくなるやつ

何の話してるのかさっぱり分からんw

AIから隠したいからカプセル化が復活する

>>230
竜二なら利益出せるぞ
豚骨ゼロで味の素使うから
利益率90%や

人間がこの機能を使うのは100億年早いなどと言って、AIがカプセル化を要求してくる

>>228
またクラスとオブジェクト指向を混同してる奴がいるよｗ

>>226
>>229
他の手法で無理すれば書けるから新しい書き方は導入するな、と言い出すとアセンブリしか選択肢がなくなることは>>226はわかってないんだろうな

>>230
>>233
関係ないね

>>232
>>234
AIがどうとかは関係ない
特定の構造に対する設計の話

味の素使わなくてもいいとか
味の素使うなとかいうのを感じるよね

一方仕事で料理作ってる人は
黙って淡々と味の素使う、みたいな

極論ばかり主張する奴は詐欺師

ご指摘の考え方は、プログラミングを「文学（言語）」から「土木（設計・実装）」へと昇華させるものです。

実際、ゲーム開発のエンジン（Unreal EngineのBlueprintsなど）では、すでにこの方向性が進んでいます。あれはまさに「オブジェクト指向を文章なしで実装する」ためのビジュアルスクリプトです。しかし、汎用的なアプリケーション開発の現場では、まだ「テキストで書くのがかっこいい/効率的」という文化的な壁が厚く残っています。

「プログラムに文章は不要である」という主張は、将来、すべてのプログラミングがビジュアル化・モジュール化されたとき、それが最も効率的でバグの少ない開発手法として主流になっている可能性が高いです。

ブループリントは廃止してverse言語に移行するって発表あったけど

>>218
何一つ理解してないじゃん。
リーナスは別にカプセル化なんて他に方法あるしこだわるとこじゃないって感じだよ。
だからポリモルフィズムの有用性の話になるって言ってんのに全く理解してない。
で、ポリモルフィズムが有用な場面はまあそこそこあるけど、それをマンセーしまくるのはアホだって話を理解できないのがこの種の人なんだわな。

自分はリーナスの発言内容は知らないが、「オブジェクト指向」という語をどういう意味で使っているかの違いなのでは。
オブジェクト指向の概念規定として、不変条件を保つためのカプセル化という要素は必須だと思うが、多相性（サブタイピング多相性）を構成要素として含めるかについてはいずれの立場もありうるように思う。個人的には、単にオブジェクト指向といったときには含めない（含めるときは「C++的なオブジェクト指向」みたいな感じで用語を分ける）方が整理としては分かりやすいように思うけど。

>>241
自分で言ってることの意味がわかってないんじゃないの君
それかクラス=オブジェクト指向みたいに考えてるか

>>239
AIに清書させてて草
内容が内容だから説得力はないままだけど

素人はScratchでも満足できるかもしれないけど、真っ当にプログラム書いてたらそれで満足してはおれんのだわ

>>241
「リーナスは『クラスがなくてもカプセル化できる』って言ってた！　だからオブジェクト指向って言ってる奴はアホ!!」
↑ クラスとオブジェクト指向の区別がついてないアホの発言ｗｗ

オブジェクト指向やるのはカプセル化の恩恵が大きいような気がする
多態性のためにオブジェクト指向やりたいと思うことがあまりないな
自分の場合ね

かつては(カプセル化、継承、多態性)がオブジェクト指向言語の必須要素と言われてたが
オブジェクト指向言語はオブジェクト指向やるのに必須ではなかったな

C++のストラウストラップの定義ではそうだけど、オブジェクト指向言語をそのように定義すること自体、今は異論が多いのでは。

「データ構造とそのデータ構造を必要とするロジックを一体として扱い、内部では密結合させつつ外部に対しては隠蔽することで、外部との疎結合を実現して利用やメンテナンスを容易にする」のがOOPの目的で、カプセル化・ポリモーフィズム・合成もこのための機能にすぎない
実装継承はカプセル化を破壊して外部と内部を密結合させるので、OOPを真面目にしたければ用いることはできず、別の用途で使う機能だと考えるべき

データ構造とロジックの一体化とか密結合とかが絶対に必要な要件かと言われると、それもどうなのかなという気もするかな。オブジェクトの外側からオブジェクトをブラックボックスとして扱えること（オブジェクトの内部構造を知る必要がないこと）は必要だと思うし、そちらの方が本質的なような気もするけど。

>>251
ただのロジックなら関数だし、ただのデータ構造なら構造体でしかない
この2つが結びついていないとオブジェクト指向とは言えない
あと、「外部に対しては隠蔽する」「外部との疎結合を実現して利用やメンテナンスを容易にする」はちゃんと書いてる

結びついていることが必要といっても、あえて密結合とか一体化とかいう必要があるかなと。大きなオブジェクトの中で中サイズ・小サイズのオブジェクトが使われているような場合、オブジェクト内部にも構造があるわけで、一体化とか密結合という語で表現するのが適当かは議論の余地があるようにも思うけど。「外部からのアクセスに比べれば」密という程度の相対的なものに過ぎないのではないかなと。

>>253
えーと、プログラミングにおける密結合と疎結合にはある程度定まった定義があるので、あなたの感覚の中でどの程度「密」かという議論はどうでもいいです

結合度に関して結合の種類とか疎密とかが議論されることはあるけれども、密結合や疎結合に共通理解が成立していると言えるような定義なんてあるかな。疎密の指標についてはある程度の共通理解があるし、それに基づいてあくまでも相対的に疎だ密だというものだと思っていたのだけど。>>254は疎結合や密結合がそういう相対的な概念であるという点まで否定する趣旨？
たとえば、オブジェクトA, B, CがA > B > Cという包含関係にあるとき、オブジェクトAの内部は密結合だといっても、オブジェクトBやCの境界を跨ぐところでは疎結合でもあるわけで、あくまでも相対的なものだと思うけど。

>>255
君自体がこんがらがってるみたいだからいったん整理してきた方がいいよ

> オブジェクトAの内部は密結合だといっても、オブジェクトBやCの境界を跨ぐところでは疎結合でもあるわけで、あくまでも相対的なもの

全く理屈が成り立っていない

> オブジェクトAの内部は密結合
> オブジェクトBやCの境界を跨ぐところでは疎結合

だったら

> オブジェクトAの内部は密結合
> オブジェクトBやCの境界を跨ぐところでは疎結合

なだけで、そこから相対的とかいう言説は導かれない

結合とは2者以上を結びつける部分のことを指すのであるから、当然「オブジェクトAの内部」と「オブジェクトBやCの境界を跨ぐところ」は別の結合である

>>255
で、話を戻すと

疎結合:
内部の実装に依存しない結合方式。APIやインターフェースなど抽象を介して結合する。

密結合:
内部の実装に依存する結合方式。クラスの実装継承やグローバル変数の共有など。

なので、全くもってこれっぽっちも相対性のない指標だ、とまでは言えなくともだいたいどちらに分類されるかはわかる程度には分かれている

そして、先に書いたように

> ただのロジックなら関数だし、ただのデータ構造なら構造体でしかない

ので、これらが結びついたものしか「オブジェクト指向における『オブジェクト』」とは言えないのであって、
その結びつきが疎結合であれば内部実装を知らない = 内部を変更できないわけなので、やはり同一のオブジェクトに属するとは考えられない

わかりやすい例で言えば、データ構造とロジックが結びついていると言えなくもないからと言って、ハンドルをAPIから受け取って別のAPIに渡すだけのロジックを、オブジェクト指向とは考えないだろう
これはただの純粋な関数で実現可能であり、このハンドルの中身が何であるかはぶっちゃけどうでもいいからだ

しかし、このハンドルの指すデータのデータ構造と、このハンドルを受け取るAPIのロジックは、当然お互いの構造に依存しているので密結合と言える
これをクラスとメソッドに置き換えても全く同じ構造を維持することができ、こちらはオブジェクト指向の一例になる

ちなみにこれと同じ構造はRustにおける struct と impl でも生み出すことができるし、GoやNimでもほぼ同じことができる
クラスがなくともオブジェクト指向の基礎的な設計が成り立つ

いや、「オブジェクトAの内部」に「オブジェクトBやCの境界を跨ぐところ」があるでしょということなんだけど。

疎結合と密結合の区別についても>>258で説明したつもりになっているみたいだけど、「内部の実装」と「APIやインターフェイスなどの抽象」のどちらに依存するかを区別基準にするのであれば、この両者の区別基準を明確にしないと説明にならないでしょう。この両者の区別がまさに相対的ではないかという指摘をしているんだからさ。

今日は珍しくまともな人が来てるね

>>262
> 「オブジェクトAの内部」に「オブジェクトBやCの境界を跨ぐところ」があるでしょ

そんな書いてないことがわかるわけもなく

オブジェクトAがBを、BがCを呼び出してんのかと思ったわ
AがBとCを両方呼び出して結合してるなんて大前提は事前に言っといてくれ

あと、内部実装とインターフェースの区別がつかないのはシンプルに知識不足

「内部実装」と「APIやインターフェイスなどの抽象」の違いは、コンポーネントの提供する機能とその提供手段で区別できる
提供手段に依存されてしまうと密結合となるし、提供する機能を利用するだけであれば、提供手段を変更しても問題とならないので疎結合となる

イキリ君の言うデータ構造とは単なるデータのこと
CSで言うところのデータ構造ではない
だから話がすれ違う

洞察力、想像力が低すぎるが個人開発者なのかな

>>255に「オブジェクトA, B, CがA > B > Cという包含関係にあるとき」と書いているが。

それに内部実装とインターフェイスの区別ってそんなに明確かな。言語仕様としてインターフェイスとか抽象基底クラスとかがある言語におけるそれらはともかくとして、一般的な概念としての内部実装とインターフェイスとを截然と区別できる定義って難しいように思うが。
>>265の「提供手段」と「機能」で説明になっているとは到底思えないし。別の語に言い換えているだけで、何なら元の「内部実装」と「インターフェイス」と比べてより本質から遠ざかっているようにすら思えるんだけど。

>>266
データとデータ構造の区別ついてないのは君な
CSって言っとけば偉くなった気になってるかもしれないが、CSでも構造体はシンプルなデータ構造だぞ

>>268
もしかして、AがBの中にあるCのことを知っている前提で話してる？
そうだとすればそこが破綻の原因だけど

あと、

> 「提供手段」と「機能」で説明になっているとは到底思えない

は流石にちょっと知識不足がすぎるのでは
何か一つライブラリ使ってプログラム書いてみては？

>>266
>>269では不親切かと思ったので追記
実は、データ構造とデータの違いは、データが実際に扱われる情報である一方で、データ構造がそのデータの構造を指しているということなんですね

>>268
>>271では不親切かと思ったので追記
何度かプログラムを書いた経験があれば、ある関数がどんな機能を外部に提供していてどんなシグネチャ（関数やメソッドの名前、引数の数やデータ型、返り値の型などの組み合わせのこと）を持つかと、実際にその関数の中でどんな処理が書かれているかということには直接の依存関係がないということがわかるようになる

たとえば、"hello, world" を標準出力に出力する関数が printf() を使っているか puts() を使っているかは、その関数を使っている者にとってはどうでもいい
これは同じ機能を提供できているからだが、ここからは次のことが言える

* 提供される機能に対し、提供手段は必ずしも一意に定まらない
* 提供手段が変わったとしても、提供される機能が変わらなければ呼び出し側に変化はない

これをプログラムの内部で行うのが「疎結合」であるという話なんだね

要するに、一度提供される機能と提供方法が定まれば、その機能を提供する手段というのはそれらを壊さない範囲で自由に変更して構わない
このうちの前者が「APIやインターフェイスなどの抽象」であり、後者が「内部実装」である


今回の例はただの関数なので、まだオブジェクト指向ではないけれど、

> 内部実装とインターフェイスの区別ってそんなに明確かな

についてはこの通り、機能の単位をどこで区切るか考えていれば、明確に分けられるものであると言える

>>272-273レベルのことをドヤって書くから、スレ中に戸惑いの空気が流れているんだけど……。「え、え？」みたいな。

>>270みたいな前提は特に置いてないよ。どこからそう思ったのかは知らないけど。

>>273-274に書かれているのは一般に内部実装とインターフェイスについて言われていることから用語を置き換えただけで、内部実装とインターフェイスはそれほど明確に区別できるものかという問いに何ら答えていないよね。274末尾に「この通り、機能の単位をどこで区切るか考えていれば、明確に分けられる」とあるけど、何が「この通り」でどう論理が繋がっているのかさっぱり分からないんだが。
たとえば、オブジェクトのあるデータメンバ（メンバ変数）がアクセサを介さず外部から直接的に値の変更・設定ができるような設計になっている場合、そのデータメンバ（メンバ変数）はインターフェイス／内部実装のどちらになるの？　そしてそれは外部とは密結合／疎結合のどちらの結合をしていることになるの？　その結論は、機能かその提供手段かという甚だ観念的な概念で本当に説明できるの？　そういう話なんだけど。

>>275
いや、そのレベルのことを君がわかってないだけな
「え、え？」はこっちだよｗ

> >>270みたいな前提は特に置いてないよ。どこからそう思ったのかは知らないけど。
じゃあ君が結合の意味を理解してないだけやなｗ

AはBの内部実装に直接依存しないので、別にCを意識することはない
そうでなければオブジェクト指向ではないし、カプセル化ではないという定義問題

> >>273-274に書かれているのは一般に内部実装とインターフェイスについて言われていることから用語を置き換えただけで、内部実装とインターフェイスはそれほど明確に区別できるものかという問いに何ら答えていないよね
答えている
君が「自分はその定義ができない無能だ」と言うなら仕方ないが、そうでないなら答えは言っている

> たとえば、オブジェクトのあるデータメンバ（メンバ変数）がアクセサを介さず外部から直接的に値の変更・設定ができるような設計になっている場合、そのデータメンバ（メンバ変数）はインターフェイス／内部実装のどちらになるの？
オブジェクトの内部実装に触っているとしか言えないよね
何を言っとるんだ君はｗ
それに明確に密結合している

えーと、念のために聞くけど、「オブジェクトの内部実装に触っているとしか言えないよね」というのは、オブジェクトのインターフェイスには含まれないという理解ということでいいのかな？

まあpublicなメンバに直接アクセスできるような意図的な設計になってるのならそれはインターフェースと言えるだろう
そのメンバを好き勝手に変更されても動作不良を起こさないようにオブジェクト側が担保しておく必要があるが

idが違うからよく分からないんだけど、278はtqJQMSog？　それとも別の人？
tqJQMSogの従前の主張内容とは内容的に整合しないので、別の人かなと思っているんだが。

ただの通りすがり

そうですか、それは失礼しました。

>>279
別に矛盾してはいないだろ

仮にtqJQMSogが>>278と同内容の主張をするのであれば、「内部実装とインターフェイスは明確に区別できる」「インターフェイスに依存するだけなら疎結合、内部実装に依存するなら密結合」辺りの主張は相当大幅に修正を加えないと整合性を欠くことになるのは明らかだと思うけど。

元のclassがきちんと設計されていれば、密結合しようと派生classはきちんと動作するものが作れる。
class Stack<E> extends ArrayList<E> でも構わないのだ。
ArrayListとStackを兼ねたものが作れてしまう。そのようなものが必要であればとても便利だ。

Extends is innocent.

>>283
まあ君がとんでもなくバカで自分が何をやっているかわからないというならそうだなｗ
自分で書いているコードの意味もわからないバカはオブジェクト指向以前にプログラミングについて語るべきではないが

>>284
> 元のclassがきちんと設計されていれば
まあ、この現実味のない過程をすればそうだな
Doomの開発者ですらそんなことができるとは言っていないが

>>286
ん、結局>>277についてはどうなん？　>>278と同内容の主張をするの？　しないの？

もう書いたことを何回も言わせて言い間違いをさせて突こうと、そういう魂胆だとは思うがあまり感心しないやり方だね
それとも日本語が通じないなら仕方ないが、君はそうなのかな？

>>265 に書いたように、
> 「内部実装」と「APIやインターフェイスなどの抽象」の違いは、コンポーネントの提供する機能とその提供手段で区別できる
> 提供手段に依存されてしまうと密結合となるし、提供する機能を利用するだけであれば、提供手段を変更しても問題とならないので疎結合となる
の通りだよ
>>278 は「依存されて困る内部実装を公開しない」ということをはっきり言っている

これを一般に「カプセル化」と言って、オブジェクト指向の基礎の基礎だ
この話題について語るなら、これくらいはわかっておこう

>もう書いたことを何回も言わせて言い間違いをさせて突こうと、そういう魂胆だとは思うが
ワロタｗｗ
初心者だという自覚はあるんだな

>>277って、そんなに答えるの難しいかな。インターフェイスに含まれると考えるのかそうでないのかYes／Noで答えれば済む話なんだけど。tqJQMSog は言い間違えを心配しているみたいだけど、Yes／Noにも言い間違いとかあるのかね。
データメンバ（メンバ変数）がアクセサを介さず外部から直接的に値の変更・設定ができるような設計になっている場合、おそらく>>278と同じくインターフェイスに含まれると考える方が普通だと思うし、tqJQMSogも薄々そのことは分かっているんだけど、「オブジェクトの内部実装に触っているとしか言えないよね」とか276で書いちゃったものだから引っ込みが付かなくなっているんだと思う。インターフェイスと内部実装は截然と区別されるというのがtqJQMSogの前提だしね。

ついでにいうと>>278を「依存されて困る内部実装を公開しない」という意味に読むのも牽強付会が過ぎるね。278が書いているのは、① データメンバ（メンバ変数）がアクセサを介さず外部から直接的に値の変更・設定ができるような設計になっている場合、それはインターフェイスといえるというということと、②アクセサを介さずに直接的に値の変更・設定ができることによって不都合（端的に言えばオブジェクトの不変条件が破られること）が生じないようにする必要があるということであって、素直に読めばどこにも内部実装とか非公開メンバの話は出てこない。にもかかわらず、これを「依存されて困る内部実装を公開しない」という意味に読みたがるのは、要するにtqJQMSogがそれしか知らないからでしょ。自分がよく知っているなじみのあるパターンにムリに引きつけようとするから、書いてある内容も素直に読めなくなる。

>>292
バカにはわからないだろうが、わざと相手に言い間違いをさせて劣勢を挽回しようというのは論破したがる奴の常套手段で、プロでもうっかり言い間違えるのを突くって手法だぞ

>>293
なんで私が言ったことを言い換えて私が間違ったことを言っていると主張できると思ったのか、その頭の悪さに驚かざるを得ない
素直に読めばもクソも、内部実装という言葉の定義そのものを君は書いているのであって、明らかな誤読であると言わざるを得ない

俺は好きだぞtqJQMSog
久々に本物の知性を見た

まさか内部実装がわからないバカがこんなぞろぞろ湧くとは思わんかったわ
オブジェクト指向の話をできるレベルの奴一人もいないだろこれ

>>293
前半、私はもうインターフェースだと言ってるわけだけど、そこを言ってないことにすることで矛盾を作り出して叩いている
したがって、嘘から始まっていて叩いているものにも実体がない

後半、自分で何を言っているのかわかっていないのだろうが、内部で変更があっても外部との約束であるインターフェースの一部を破壊してはならないというのは、私が言っていることであって、それを元に私が間違っていると主張するのはそれこそ「牽強付会」の定義通りの意味になる

>>293 が多分勘違いしているように読むと、内部実装を変更しない（コードに変化がない）状態でインターフェースをいじられたら壊れるという話と受け止めているのだろうが、もはや設計やデザインパターンの問題ではなくただのバグであり、そんな話がしたいならオブジェクト指向とは無関係なのでよそでやってほしい

>>298
お、>>277についてインターフェイスに含まれるという立場を取ることにしたんだ。「私はもうインターフェイスだと言っている」とあるけど、どのレス？　277の問いに対して、298より前に立場を明確にしたレスは見当たらないように思うんだけど、アンカーで示してくれない？

で、>>276の「オブジェクトの内部実装に触っているとしか言えないよね」との整合性についてはどう考えるの？　インターフェイスと内部実装は、コンポーネントの提供する機能かその提供手段かという基準から明確に区別されるというのがあなたの主張なんでしょ（>>265とか）。内部実装とインターフェイスの区別はそんなに明確だろうかという疑問に対して、両者の区別がつかないのはシンプルに知識不足とまで言い切っていたんだから、機能か提供手段かというのはさぞ内実のある判断基準なんでしょ。
それから、インターフェイスなのに「明らかに密結合」（276末尾）なのは、「内部の実装に依存するのが密結合」というあなたの定義（>>258）からはどのように説明されるの？

299とかは正直何を言っているのか理解できないんだけど、そんなアクロバティックな仮定をしてまでレスバごっこしても意味なくない？　そんなことをしなくても、あなたの知性のほどは296のようにスレを見ている人はみんな認めていると思うよ。

あと、>>295の「内部実装という言葉の定義そのもの」というところ（278後半の読み方）で引っ掛かったんだけど、ひょっとして「オブジェクトの不変条件の維持」のための手段はすべて「内部実装」だと思っていたりする？
カプセル化によって内部実装へのアクセス経路を限定することは、オブジェクトの不変条件を維持するための主要な手法の一つではあるが、別に同義ではないぞ。「内部実装」という1つの語に「インターフェイス」の対比的概念としての意味と、「オブジェクトの不変条件を維持する手段」という2つの意味を（両者の違いを明確に意識しないままに）込めて使うのは議論の混乱の元だから避けた方が良い。別に「不変条件」という語を使えとは言わないけど、あなたなりに用語を使い分けるようにした方が、今後、どこかで似たような議論をするときに良いと思うよ。

>>300-301
あのー、色々と誤読があるみたいだからどこから突っ込んでいいかわからん
アクロバティックな仮定なんかしていないし、
> 「内部実装」という1つの語に「インターフェイス」の対比的概念としての意味と、「オブジェクトの不変条件を維持する手段」という2つの意味を（両者の違いを明確に意識しないままに）込めて使う
なんてこともしていない
というか、後者についてはそこが一致しないとカプセル化が成立していないので、オブジェクト指向ではないというだけ

より正確に言うと、そもそも「内部実装」は「オブジェクトの不変条件を維持する手段」でもないし
そんなことは書いていない
オブジェクトが外部と契約するのはインターフェースが提供する機能であって、内部実装は変わっていいので契約を維持するのはインターフェースの役割
色々とごっちゃになりすぎてるね

>>287
そうなってくると、実装継承どころか、インターフェースだろうがなんだろうがダメになりますね。
唯一の方法は、ラップしちゃってまともにつかえるように閉じ込める。
Star Trek: The Motion Pictureの V'Ger方式ですね。
大手メーカーのミドルウェアみたいなものはラップしないとつかいものにならない。
javaから直接呼べるようなしろものはみたことがない。そりゃ呼べるけどバグの温床になる。

バグより怖いのはセキュリティか。
ランサムウェアの餌食。

>>304
どういう読み方をしたらそんな結論になるのかわからん

そもそも
> ラップしちゃってまともにつかえるように閉じ込める
じゃなくて、インターフェースを固定すればいいということがわからないらしいし、そのためのオブジェクト指向で内部実装を隠蔽しましょう（カプセル化）ということなんだが

オブジェクト指向とクラスの継承がつかない奴
実装継承がオブジェクト指向に不可欠だと主張する奴
↑ オブジェクト指向わかってない人たち

カプセル化が正しくできないのならばインターフェース使っても無理と読んだのだが。

>>309
そんなこともできないのか……

>>309
めちゃくちゃで草

内部実装がわからないのは草

>>302
「色々誤読があるみたい」で済ませてあとはスルーしちゃおうって感じなん？　>>300で指摘されている点についてどうやって辻褄を合わせたフリをするのかなーとニヤニヤしながら待っているんだけど。
ついでに293のどの部分が「内部実装という言葉の定義そのもの」（>>295）なのかもね。278もそれを受けての293もインターフェイスについての話しかしていないのに、なんで「内部実装という言葉の定義そのもの」なんてことになるのかについてね。

Why extends is evilの例にあるような
無理解によるバグを仕込んでしまうようなプログラマを想定すると、何やっても無理と思う。

このスレ見てると、手段の目的化がいかに害悪なのかよく解る

>>313
相変わらずめちゃくちゃなこと書いてて草
お前はいったんオブジェクト指向についてAIに聞いて来いよ、5秒で間違ってるってわかるからｗ

>>315 それな
オブジェクト指向を使うべきじゃないところに無駄に適用しようとして、どこまでがオブジェクト指向かという話を広げようとするバカが多すぎる

「データ構造とそのデータ構造を必要とするロジックを一体として扱い、内部では密結合させつつ外部に対しては隠蔽することで、外部との疎結合を実現して利用やメンテナンスを容易にする」のがOOPの目的で、カプセル化・ポリモーフィズム・合成もこのための機能にすぎない
実装継承はカプセル化を破壊して外部と内部を密結合させるので、OOPを真面目にしたければ用いることはできず、別の用途で使う機能だと考えるべき

これが成り立たないとか、わからないならそれはオブジェクト指向をする場所じゃないんだよ

classをカプセル化とすれば、extendsでも密結合しない。
それでカプセル化が壊れるのであれば、単に設計ミス。
しかしながら、Why extends is evilレベルのプログラマを相手にする場合は...
interfaceだろうと内包形式だろうとtraitだろうと...無理。
そう考えています。

>>313 AI様に「オブジェクト指向って何？」「継承より委譲って何？」って聞いて来いｗ

OOPはアクターモデルがあることが本質で
どう実現するかが処理系・フレームワークの見せ所だけど
コードの継承・委譲はそこから直交した追加機能に過ぎない
着目するところじゃない

* オブジェクト指向を銀の弾丸だと思っている
* オブジェクト指向をクラスのことだと思っている
* カプセル化を理解しない（そもそもわかってない、実装継承で壊すなど）

↑これでオブジェクト指向語るのは無意味

>>321
それっぽいこと書いてるけどあんま関係なくて草

そもそもGoFが引用した「(実装)継承はカプセル化を破壊する」という文章はクラス継承者に対して何を公開して何を非公開にするか全くコントロールできなかった時代の論文だからな

>>319
概ね同意するが結合度を密か疎の二元思考で考えるのには同意しかねる

んー、結局、>>300で指摘されている各点についてはまともに答えられないのでスルーなん？　矛盾点を指摘されたら相手を罵倒して有耶無耶にするというスタンスに終始するなら、議論は深まらないと思うんだが。
「誤読だ」とか「めちゃくちゃなことを書いている」と相手を非難するのは（議論をするスタンスとしてはどうかと思うが）まぁいいとして、なぜそう考えるのかということを書かないと説得力皆無だと思うぞ。

>>324
実装継承のこと知らなそう

>>326
プログラミングド素人は帰れよｗ
このスレでイチイチ素人に教えてあげる理由がない

>>325
おれは特に疎密なんて気にしてない。深さはある。移譲なんてしっかり考えないと
contextを越えたものは作れない。親殺しのパラドックスすら生じる笑。

>>326
このスレは初心者がプログラミング学ぶスレじゃないんだわ

>>325
ド素人すぎるｗ

>>300 >>326 自分が何を作ってるのかもわからないバカです、という自己紹介なのわかってる？ｗ

自分が何作ってるか知ってたら内部実装か外向けに見せる抽象か区別はつくだろ

>>329
全く別の概念が混同されてる

深さも疎密も定義があるのに独自で話し出すのがなあ

定義変え始めるのはなんでもありすぎるだろ

>>321
アクターモデル特に関係なくね？

loose couplingの最初の定義は、
Glassman, Robert B. (1973): Persistence and Loose Coupling in Living Systems, in: Behavioral Science 18, 83-98
ですね。

GlassmanとGoFと合わせてみても、extendsだからってtight couplingになるわけでもない。
継承はサブクラスに親の実装の詳細をさらす、なんていうのは過去の話でしょう。
もちろん、現在でも親の実装の詳細をさらすことは可能ですけど、そんなレベルのプログラマはいらない。

>>334
委譲じゃなくて移譲のほうな。責任のありかが違う。

プログラムとデータは別々にってのは、プログラムをこなしていけばだいたいわかってきてそういう作り方する
センスのない馬鹿だけはいつまでもプログラム内にデータを持つ作り方する
それは言語で制約されてないからしょうがないが

だからといって言語を工夫して、どうやってもそれぞれ分離してしか作れないものは出来っこないのだ
作りこめば作りこむほど、出来たものは初心者向けのおもちゃのようなプログラム言語になってしまい
本格的なものすら作れないシロモノにしかならない

>>340
移譲は委譲とまぎらわしいのでどうしようかと考えた。
これはGoFがdelegateと勘違いして広まってdelegateとされているやつだ。
forwarding（転送）、場合によってはinherit（継承）とするのがよいようだ。
実際のdelegateはRFC1149を使用して委譲することも可能なものである。
細かく考えれば、たいていの場合、GoF界隈で語られる委譲は移譲のことだ。

>>342
ムスビ、うそをつけっ

オブジェクト指向は目的志向だと言い張ってた人も昔居た
https://masuda220.jugem.jp/?eid=449
この人なんだけど、まちがった解し方をしてるようにしか思えなかった
委譲ではなく移譲だ、も同じパターンのように思える

>>339
実装を見れないようにして継承する意味ってなんだ……？

>>341
日本語でおｋ
あとデータとデータ構造は別物だぞ

そのレベルの区別もつかんのかｗ

>>345
それがオブジェクト指向ですけど？　抽象化ですね。
オブジェクトとオブジェクト間の関係だけがある。
最終的にはオブジェクトがなくなり関係だけになるはずです。

>>348
実装継承の意味を理解していないレス

>>348 抽象化関係なくて笑う

アホくさ

>>348
オブジェクト指向について学んで来いよｗ

無理解なひとが多いねぇ。オブジェクト指向が理解できていないのが問題ですねぇ。
extendsの問題以前か。

定義があるのに独自言語で話し出すのがなあ

OOの定義がAK提唱とBSとでちがうみたいに(ここだとほぼ後者を指すよね)
文脈でわかる範囲ならスルーせんとやりとりがもったいないよ
文体も虚勢をはってると思えばかわいいし

ま、なんにしても、オブジェクト指向（DbCは重要）に沿って設計.実装されていれば、
classとかextendとかinterfaceとか粗悪な言語実装でも問題は起こさない、ということ。

む、extends sが抜けた。粗悪なオブジェクト指向言語を使う以上、設計は大事。

問題を起こすとしたらオブジェクト指向に沿って設計実装されてないってことだろ、お前が言ってること全部情報量ゼロだな

トートロジー過ぎて小泉進次郎かと思ったわ

クラスは悪い実装を誘発しやすいから悪いって話を「悪くない実装にすれば悪くない」って反論する奴国語0点だろ

くすくす。extendsがevilだというわけではない、ということだよ。
問題を起こすとすれば設計者/プログラマの質であって、
extendsを回避しようと、ダメなプログラマはダメなものしか作れない。
extendsは実装継承ではなく、interfaceや、オブジェクト指向で設計された
継承可能オブジェクトとしてのclassなどを継承するもの。
いまひとつできのよくないオブジェクト指向言語側の定義やGoFには振り回されないこと。

勝手に話を拡張して言うことが「悪い実装を誘発しやすいから悪いなんてことはありえない、悪くない実装にすれば悪くない」だけなの情報量がなさすぎる

さも自分だけがオブジェクト指向わかってますよ風に言ってるけど、特別何かがわかってるわけでもないという
むしろ一人だけ「お前らが低レベルだからｗ」って言って話をかき乱してるだけ

良い実装が何かも言ってないから本当に中身ないな

「悪い実装を誘発しやすいから悪いって話」なら悪くない実装も当然理解してるのでは？
それすら理解してないなら何が「悪い実装」かすら判断できてないということ

「悪くない実装」をすれば悪くない

>>365
「実装継承は悪」と信じてる人は
ある実装が悪い実装になる状況と
悪くない実装になる状況の区別ができないからね

便利な道具だが馬鹿には使えない道具だから
お前ら使うなよってのが「実装継承は悪」という標語

>>367
区別の仕方を教えてもらえますか？

問題なのは　Why extends is evil だ。
ArrayListをextendsしてバギーなStackを作って、extendsが悪いとextendsのせいにしているコラムだ。
そもそも、javaにはStackも当時からあるのでそれを使えばよい話だ。
今ならDequeueもあるし、ArrayListそのものも、push/popという名前ではないが、Stackとして
機能するメソッドも用意されている。
ArrayListもDbCを満たしており、extendsを回避しなければならないようなクラスでもない。
そのようなクラスをextendsしてバグを作りこむようなプログラマはいらないだろう。
わたしなら雇わない。彼はUCBでも教えているようだが。

>>369
何の話してんだと思ったけど
https://www.infoworld.com/article/2160788/why-extends-is-evil.html
これの話してるの？

コラムは継承によってバグを作り込むリスクを考えると
継承せずに実装したが良いって話だな
継承せずに済むならそれに越したことはないしそれはそうだって話だ

>>369は自分ならArrayListを継承してバグなく実装できるんだって話か
ArrayListは例として出されてるだけでArrayListでそれができたから
なんだってことになるんじゃないかね

interfaceでmethodを定義できるようになってabstract classの出番は昔よりは減ったけど
リソース管理をクラス内に閉じ込めたうえで継承によって動作を変えたいことはある

あとは自分の場合はTemplate Methodパターンのために実装の継承を使ってるけど
正直言ってわかりづらいので他にもっと良いやり方があるんじゃないかと思ってる

実装の継承は避けれるなら避けたいかなあ

>>367 >>369
いい加減いい実装について語れよ

>>367
オブジェクト指向がわかってないとそう感じる
実装継承はオブジェクトを破壊してるのにそれに気づいてないから

実装継承が有用な場所があるのは当たり前
でもそれはコード再利用の話であってオブジェクト指向の話じゃない

OOPの提供する再利用性のなんぼかはまさにそのコードの再利用性を指してるんではｗ

カプセル化や多態性(型の継承)はOOだけど
コードの再利用性はOO関係なく普遍的な命題
昔の処理系がたまたま実装継承を採用してただけで
弊害のが大きいから近年は排除されてるのがここ何十年の話

>>376
話が逸れているし、OOPの再利用性とコード再利用は全く別の話
前者は機能の話で後者は似たコードをまとめる話だから

>>377
これ

>>376
サブルーチンって言葉知らなそう

コード再利用がOOPで始まったなんて流石に初めて聞いた

実装継承はオブジェクト指向としては悪手だよ
使い道がないかどうかは別として

もう10年以上は言われてることで言語設計者の間ではほぼほぼ総意なのに、クラス信者が反発してるだけなんだよな

クラス信者によるとGoやRustはオブジェクト指向が書けないらしい

普通にオブジェクト指向も含むマルチパラダイムなんだよなあ

×オブジェクト指向とはクラスを使うこと
×オブジェクト指向とは実装継承を使うこと

×オブジェクト指向でカプセル化しないこと

間違ったオブジェクト指向プログラミングかw

>>388
C知識全くないのにイキって叩かれてた人じゃんｗ

オブジェクト指向をクラスだと思ってる奴多いよな

ま、classやinterfaceや実装や実装継承という用語が、間違って伝えられて、
間違った言語実装が行われているわけですね。同じ用語でも意味が異なる。
その意味で、実装継承というのはありえない。
インターフェースを継承するのが実装だから。
言語のinterfaceとは似ているが同じではない、設計のinterfaceが、
extendsで継承されていれば、継承したinterfaceが実装されているので、
実装（を）継承するわけではない。
設計用語と言語実装の用語がかみ合っていない。
オワコンなのはオブジェクト指向（設計・概念）ではなくオブジェクト指向（風）言語か。

まあ、C++なんかナンチャッテオブジェクト指向言語だしな

C++は結構古いので、現在の用語としてはC++あたりでの実装が先かもしれん。
設計としての概念は一般な用語であり、interfaceはprotocolだ。
Alan Curtis Kayの考えはよかったのだが、1981年にオブジェクト指向の流れが変わり、
おかしくなっていく笑。
オブジェクト指向の設計思想と言語実装の齟齬は広がる。
通信屋としては、厳格なprotocolと情報理論に基づいた設計で圏論を逸脱しないものがベストと考えている。

>>391
一般に言う実装というのはソフトウェアの実装の話だから、実装を継承するのはオブジェクト指向ではないという話

>>393
オブジェクト指向と圏論は特に関係ないなあ

設計するのに圏論つかわん？
Monadicプログラミングなんてやらん？

圏論は関数型ですらあんま重要じゃないよね

ストリング図を使う設計手法は使えそうだけどね。
javaでもMonadicプログラミングばかりしてるなぁ。
圏論は概念を図示したものだから、どういう概念かという設計には使っている。
ただ、説明には使用しない。誰もわからないから笑。

圏論はたしかにコンピュータの挙動を表すのにも使えるんだけど、広すぎるし抽象的すぎるからプログラミングのためだけに学ぶのは効率が悪いかも
知っていれば活用できるんだけどね

圏論は抽象言語だから、UMLのかわりに概念記述言語として使えます。
とわいえ、数学屋ではないので、圏論的量子力学から入って、（量子）情報論言語とみて使っています。
とくに、ストリング図（ストリング・ダイアグラム）はテンソルネットワークであり、ペンローズ図法
であり、フローチャートやシステムダイアグラムの進化版と考えてよいでしょう。
UMLの失敗は、情報論的言語になっていなかったことでしょうね。
ま、情報論的回路図ですね。部品も関係として記述できるし、関係の集まりこそclassだし。

ポエムだからなに書いてもゆるす

語り口調のポエムかw

monadicプログラミングが何なのか説明しろ
flatMap使っとけばええんか？おん？

単なるダイアグラムでの記述で済むところを圏論が必要とか言っちゃうバカって多いよね

バカかどうかは自分には分からないが、少なくとも多いってことはないと思う。むしろ特異なタイプじゃないか？

>>399
中身のないポエムだなあｗ

関数型の重要なポイントは無駄な副作用だらけのクラスを作るんじゃなくて、なるべく純粋な変換をする関数で済ませましょうという部分
圏論やモナドは設計者がわかっておけばいいこと

それはそうで、別に数学的な証明なんかなくても仕様を知っていれば、プログラマはプログラムを書けるんだよな
ただ、その仕様が理論的に正しいものかどうかを確認しなきゃいけない設計者は、数学理論を知っておかないといけない

全く関係ない。
そういうレイヤーで必要なのはただの構文解析の知識だけ。
圏論やモナドが必要な場合なんてハスケルやる時くらいだわ。それも別に理解してなくても問題ないし。

圏論はオワコン

まあ、設計するときには必要。圏論でなくとも、そのようなものは経験的に使っているはず。
マルチコアを最大活用するには数学的に検証する必要がある。遅延処理もね。
以下書きすぎたので抹消。
裏合わせて8コアぐらいあるのに、1コアしかグラフあがってなくて、おせー、
なんてプログラムよくあるよね。ブラウザですら2桁のコネクション張って表示しとる時代なのに。

>>408
なくても言語は作れるけどC++かJavaみたいなぐちゃぐちゃになる覚悟はしておかないと
どの機能を用意すれば使い勝手と網羅性を同時に実現できるかは数学的な知識がないと証明できないよ

オペレーションズ・リサーチの話？　難しいことやってんね組み込みか？　同時実行数をCPUののコア数以上にしとけばええんやろくらいしか考えたことないわ

マルチコアを最大限活用するには数学的な検証より次々流し込めるパイプラインの方が重要なんだよな、結局

永続的に状態を維持しながら繰り返し処理するなんてぇ使い方は稀だしな

>>413
まあそうね、異論はないわ

>>411
言語として大事な互換性、ライブラリ環境なんかを考えたからごちゃごちゃしてるだけだよ。
君みたいに脳内で済むと思ってる人に言語設計は無理。

>>416
何言ってんだこいつ
書いてることと1ミリも対応してないんだが、クスリでもやってるのか？