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

**デフォルトの名無しさん** · 2023/08/26(土) 22:00:53.85

最近の言語には採用されないことが増えている

**デフォルトの名無しさん** · 2023/09/09(土) 09:45:59.55

>>81
自治アスペ😂

**デフォルトの名無しさん** · 2023/09/09(土) 12:37:22.79

>>80
メリットもなにもコード書いてたら普通にオブジェクト指向型になるものじゃね
「Hello World」をわざわざオブジェクト指向にするようなバカならともかく
クラスや継承を作れとか強制するような宗教でもない

**デフォルトの名無しさん** · 2023/09/09(土) 13:35:46.45

>>80
オブジェクト指向のメリットはプログラムを管理しやすいことだと思う

たとえば

・DBからデータを取得する
・データを元にExcelファイルを作成する
・Excelファイルをメールで送信する
・作業完了のメッセージをSlackにPOSTする

という一連の処理がある場合に

・DBにアクセスするオブジェクト
・Excelファイルを作成するオブジェクト
・メールを送信するオブジェクト
・Slackにアクセスオブジェクト

があればそれらを組み合わせることでプログラムを作れるじゃん
そして世の中にはすでにたくさんのオブジェクトがライブラリという形で用意されている
プログラマはそれを利用することでさまざまなことが行えるようになるんだ
既存のライブラリで要件をみたせなければ自分で作ることもできる
便利だよね

**デフォルトの名無しさん** · 2023/09/09(土) 13:42:59.05

オブジェクト指向のデメリットはオブジェクトを自由に定義できるがゆえに
簡単な処理さえも抽象化してスパゲティになることがありがちってことかな
Hello World Enterprise Editionはきれいに設計されてはいるけど

System.out.println("Hello, World!");

でいいじゃんみたいな

Hello World Enterprise Edition
https://gist.github.com/lolzballs/2152bc0f31ee0286b722

そして世の中には簡単なの処理なのにオブジェクトがたくさんあって
きれいに設計されてるわけでもなくプログラマがそのときの思いつきだけで
作ったんじゃないかと思われるような正気を疑うようなオブジェクトがたくさんあるんだ
どうだい楽しいだろう

**デフォルトの名無しさん** · 2023/09/09(土) 13:54:42.10

Rustは面倒

**デフォルトの名無しさん** · 2023/09/09(土) 14:25:39.31

DBやExcelなどのようにドメインがはっきりとわかれている場合には
これはDBにしか関与しないデータだからDBオブジェクトの中に閉じ込めるみたいに
考えてオブジェクトを作ればいんだろうけどね

業務のドメインは流動的だからね

・この概念とこの概念は違っていてこのようにわけられる
・でもやっぱりこういう橋渡しは認めておいたがいいからこれは例外
・ユーザからこれができなくて困ってるといわれたからなんとかしてもらいたい
・あの概念とあの概念はじつはこういう切り口でみたときには繋がりがあってそれを計算してほしい

みたいなことが業務ドメインの日常だからね
どこが変わるかを予測して多少流動しても設計を変えなくてすむように作り込んだら
あっというまにHello World Enterprise Editionのできあがり

オブジェクトは固体だけれども業務は液体みたいなところがある
オブジェクトの前段階いわばスライムみたいな状態にあえてとどめておくことで
適応力を高められるんじゃないかと思う

計算によって人間の認知能力が生まれ
人間の認知能力によってオブジェクトが生まれるとするならば
関数はオブジェクトよりも次元の高い抽象化のように思われる

関数はスライムの可能性がある

**デフォルトの名無しさん** · 2023/09/09(土) 14:57:10.51

オブジェクト指向もモジュール化の1つの（かなり優秀な）手法だと思うよ。オブジェクトの内部はブラックボックス化され、外部からはオブジェクトのインターフェイスだけを相手にすればよいので、同時に考えなければいけないことが減り、プログラムの見通しが良くなる。
問題は、モジュールとしてのオブジェクトを機能させるためには、「これをオブジェクトとして扱う」というモジュール境界の決定が必要になるところ、オブジェクトの粒度が大きくなると、コードを書いた人の恣意的な決定の要素が増えるために、コードを読む人の理解・把握が難しくなっていくことかな。文字列オブジェクの方がcsv_readerオブジェクトよりできることを把握・イメージするのは簡単だし、より抽象度の高いオブジェクトになると、さらに理解は難しくなる。
オブジェクト指向によって得られる見通しの良さは、ゴチャっとしたコードをブラックボックスの中に閉じ込めることによって得られるものなので、オブジェクトの中に取り込まれないコード（オブジェクト同士の相互関係）の複雑性はそのまま残る。これがオブジェクトの海と呼ばれる問題。
オブジェクト指向は重要な進歩だし、今さらそのメリットを捨てることは難しいと思うけど、オブジェクトの「外」の問題については別の手法による対処が必要になる。

**デフォルトの名無しさん** · 2023/09/09(土) 15:55:43.01

コード書けない奴が抽象的な御託つらつら並べるのはどこのスレでも出てくるんだよな
バカをさらして何が楽しいのやら

**デフォルトの名無しさん** · 2023/09/09(土) 16:36:21.41

俺は抽象化自体はどうでもよくてifを減らすために使ってるわ
いくらわかりやすい名前をつけても結局全部読むなら大差ないからな

**デフォルトの名無しさん** · 2023/09/09(土) 18:04:29.66

> Hello World Enterprise Edition

全部は読んでないけどニヤニヤしながら読んだわ
ただし

> if(code.getStatusCode() != 0){

は

> if(code.getStatusCode() != IStatusCode.OK) {

とかしてインタフェース側に定義された定数使うほうがオツやと思ったわ

**デフォルトの名無しさん** · 2023/09/09(土) 18:21:08.83

OOPのメリットとして感じてるのは結局は
モジュール化のメリットなんよね
これはOOPのメリットを矮小化させるものじゃないけど

適度に分割して整理して
それらを適度に組み合わせて使うってことは

まぁそこにOOPLならではのことに焦点を当てるなら
継承っていう軸が発生することにより
クラスライブラリや自前のクラス群を説明するとき
継承関係っていうものでもって説明できる場面が出てくる

**デフォルトの名無しさん** · 2023/09/09(土) 18:40:22.54

OOPでは演算子を型と関数の間の関係として自然に定義できるけど、Cみたいな手続き型とか関数型ではどうやってるんですか？

**デフォルトの名無しさん** · 2023/09/09(土) 21:58:47.70

おうおうPの良いところだけを継承したモダンな仕組みを作ればいいんじゃないかな

**デフォルトの名無しさん** · 2023/09/09(土) 22:52:32.96

>>92
>OOPのメリットとして感じてるのは結局はモジュール化のメリットなんよね
8割方同意する
>>84に列挙されてる「～するオブジェクト」も「～するモジュール」にすべて置き換えてもなんら支障がないから

>まぁそこにOOPLならではのことに焦点を当てるなら継承っていう軸が発生する
これには同意しない
オブジェクト指向の根幹は継承じゃなくて
データと振る舞いをオブジェクトという基本構成単位にまとめることにある
関数型のモジュールでは代替できない
また継承のうちインターフェース定義とその実装のような関係は
Haskellのtypeclassをはじめ関数型言語でも広く存在するものなのでOOPLならではのことではない

つまりデータと振る舞いをオブジェクトという基本構成単位にまとめられていることによるメリットというのがOOPLならではのメリットということになる
じゃそれは何なのか？

**デフォルトの名無しさん** · 2023/09/09(土) 22:55:57.73

ずばりオワコン

**デフォルトの名無しさん** · 2023/09/09(土) 23:03:34.74

>>95
> オブジェクト指向の根幹は継承じゃなくて

根幹とまでは言ってないし思ってもないよｗ

> また継承のうちインターフェース定義とその実装のような関係は

インタフェースと実装の関係を継承とは言ってないつもり
あくまで
インタフェース間の継承であったり
もっと広義には単に型の継承

ごめんね今相当酒飲んでるから取りこぼしてたり誤解してたりするかもだけど

> つまりデータと振る舞いをオブジェクトという基本構成単位にまとめられていることによる
> メリットというのがOOPLならではのメリットということになる

このへんについてはなんとなく同意
カプセル化だの継承だのお題目色々あるけども
結局はオブジェクトって単位だよね
ってとこに着目すんのはわりと同意できる

要点を外してるレスになっちゃってたらすまぬ

**デフォルトの名無しさん** · 2023/09/09(土) 23:19:27.60

>>95
> つまりデータと振る舞いをオブジェクトという基本構成単位にまとめられていることによるメリットというのがOOPLならではのメリットということになる
じゃそれは何なのか？

状態だと思う

**デフォルトの名無しさん** · 2023/09/09(土) 23:31:29.55

ほどよいフィット感だと思う
データと関数まとめる？
まとめたい？
まとめましたけどどうですか？

↓

ええやんええやん　の感

**デフォルトの名無しさん** · 2023/09/09(土) 23:46:40.67

ミュータブルなオブジェクトを簡単に作れるっていうのがオブジェクト指向言語の利点な気がする
Haskellだとモナドを使わないといけないからね

**デフォルトの名無しさん** · 2023/09/10(日) 08:52:36.11

オブジェクト指向は何かってのはWikipediaでも見ればいい。読んで理解してもプログラム技術は変わらないが
オブジェクト指向のメリットは何かって言うのは「どの部分もオブジェクト指向とは言えない」形に自分のコード書きなおしてみればわかる。逆にすべての部分をオブジェクト指向の形にするのはアホな上にキチガイだが
これだけのことを技術板でグダグダ語ってるのはアホ

**デフォルトの名無しさん** · 2023/09/10(日) 09:38:36.81

>逆にすべての部分をオブジェクト指向の形にするのはアホな上にキチガイ
Rustですね判ります

**デフォルトの名無しさん** · 2023/09/10(日) 13:05:53.86

よく知らないが、Smalltalkとか？　「アホな上にキチガイ」かどうかは意見が分かれそうだが。

**デフォルトの名無しさん** · 2023/09/10(日) 15:45:22.64

1バイトのデータを1バイトのオブジェクトとして表現でない
スタック上に確保できない

そんな言語は全部ゴミ

**デフォルトの名無しさん** · 2023/09/12(火) 19:43:42.93

クリントン大統領にどんな強大な権限が有っても、自らのチンポがしこしこしてしまうのは止められない！

class チンポ extends クリントン{
　　　　　super.不適切な関係;
}

クリントンの再定義、クリントンの拡張された人格ということだ！

**デフォルトの名無しさん** · 2023/09/14(木) 02:27:32.48

またお前か
https://th.bing.com/th?id=ORMS.90df8de52f3a781560cc2be44612929c&pid=Wdp&w=240&h=129&qlt=90&c=1&rs=1&dpr=1&p=0

**デフォルトの名無しさん** · 2023/09/14(木) 22:02:34.97

関数型より遥かに便利だわ

**デフォルトの名無しさん** · 2023/09/14(木) 23:23:53.05

オワコン

**デフォルトの名無しさん** · 2023/09/15(金) 03:29:59.91

>>107
あれは知性が要るからな…

つまりこの仕事向いていないってことだよ

**デフォルトの名無しさん** · 2023/09/15(金) 08:47:47.02

>>107
パイプライン演算子は取り入れてほしいかな
setXXXX系メソッドをそのままつなげられたらと思う

**デフォルトの名無しさん** · 2023/09/15(金) 09:35:06.90

そりゃAPI設計が悪い

**デフォルトの名無しさん** · 2023/09/15(金) 10:30:38.51

>>109
それはただのエンジニアの自己満オナニーだよしょうもないw

**デフォルトの名無しさん** · 2023/09/15(金) 11:40:09.91

そりゃ君の頭が悪い

**デフォルトの名無しさん** · 2023/09/15(金) 12:15:45.69

いくら頭良くても5chでくだまいてたら意味無いですよね
目糞鼻糞ですよね

**デフォルトの名無しさん** · 2023/09/15(金) 22:35:34.78

本物の糞が何えらそうに

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2023/09/16(土) 09:57:06.22

>>115
とクソが申しております

**デフォルトの名無しさん** · 2023/09/16(土) 10:28:53.10

>>116
もう1.5万入手してる

**デフォルトの名無しさん** · 2023/09/16(土) 12:06:46.11

>>114
こんなところで自己紹介してる暇があったらハロワ行けばいいのに

**デフォルトの名無しさん** · 2023/09/16(土) 12:13:33.72

>>119
とハロワおじさんが申しております

**デフォルトの名無しさん** · 2023/09/16(土) 12:20:55.48

おじ同士チンポを舐め合うスレ

**デフォルトの名無しさん** · 2023/09/16(土) 12:28:42.66

>>121
毎日5chでチンポ舐め書き込み続けるゴミ人生でした
オブジェクト指向興味無いやつ来んなよ
暇かよ

**デフォルトの名無しさん** · 2023/09/16(土) 14:55:49.89

>>116
これ他のタスクだけで1000円くらい簡単に稼げるよな。

**デフォルトの名無しさん** · 2023/09/16(土) 15:59:01.04

決定的にオワコン

**デフォルトの名無しさん** · 2023/09/16(土) 15:59:49.73

でも便利

**デフォルトの名無しさん** · 2023/09/16(土) 23:51:17.00

そしてあちこち依存が絡んだスパゲティーコードを量産
他人が解読するは難しく
時間がたつと自分でもメンテできない

**デフォルトの名無しさん** · 2023/09/16(土) 23:52:08.95

ID:ZJLR+eYH
顔真っ赤ｗ

**デフォルトの名無しさん** · 2023/09/17(日) 06:56:06.28

>>127
と顔真っ赤おじさんが申しております

**デフォルトの名無しさん** · 2023/09/17(日) 07:02:54.80

必死にスレ何度も上げてるけどそんな構ってほしいのかよ

**デフォルトの名無しさん** · 2023/09/17(日) 07:04:57.07

関数型ならスパゲッティコードにならないというのはどういう理屈？

**デフォルトの名無しさん** · 2023/09/17(日) 09:36:51.67

ここまでのまとめ

オワコンとなったのは「クラス」
オワコンとなった理由は「クラスは継承に基づくため」
オワコンとなった証拠は「最近のプログラミング言語Go、Rust、Nimなどは全てクラスを持たない」

以上
つまりオワコンとなったのは「クラスとその継承」
もっと広い意味の「オブジェクト指向」は有効

**デフォルトの名無しさん** · 2023/09/17(日) 10:48:22.09

新手のクソが現れた

**デフォルトの名無しさん** · 2023/09/17(日) 11:27:29.99

>>131
いや、クラスもオワコンじゃない
以上

**デフォルトの名無しさん** · 2023/09/17(日) 11:48:42.16

GoにしろRustにしろNimにしろ継承が不要になったわけじゃない
言語機能として直接サポートされないためにより面倒でより暗黙的な方法で継承が行われている
上辺だけ見てる人にはそれがわからない

**デフォルトの名無しさん** · 2023/09/17(日) 11:56:48.45

>>131
概ね同意

**デフォルトの名無しさん** · 2023/09/17(日) 12:10:38.80

クラスや継承は高水準な機能だから
低水準を目的とする言語には向いてない

**デフォルトの名無しさん** · 2023/09/17(日) 12:19:05.22

>>133
クラスの本質は継承にあり
クラスは不要

クラスを必要だと思い込んでいる人はクラスと関係ない部分を必要としている
例えばクラスのメンバー変数はGo、Rust、Nimなどでは構造体のメンバー変数
クラスのメソッドはGo、Rust、Nimなどでは構造体のメソッド
つまりそれらはクラスとは関係なくクラスより小さい概念である構造体でも持っている
一方でクラスの本質は継承である

>>134
継承は害悪であり不要
継承しか知らない人だけが継承に固執している

**デフォルトの名無しさん** · 2023/09/17(日) 12:28:37.74

>>137
クラスを使ってもいい。
以上
害悪ではない
以上

**デフォルトの名無しさん** · 2023/09/17(日) 12:32:35.53

ID:gR/F5lVJ
プログラム書けない上にどこに行っても相手してもらえないから板違いのスレで吠えるしかないんだな

**デフォルトの名無しさん** · 2023/09/17(日) 13:01:40.88

何故自分は相手してもらえると思うんや
おまえの相手して誰が得するんや
オブジェクト指向興味無いなら来んなよ暇人

**デフォルトの名無しさん** · 2023/09/17(日) 13:05:43.12

オブジェクト指向は非常に重要
しかしクラスは不要
これはプログラミング言語界で結論が出ている
だから最近のプログラミング言語Go、Rust、Nimなどはいずれもクラスを持たない

**デフォルトの名無しさん** · 2023/09/17(日) 13:21:52.64

これまでオブジェクト指向分析に触れているコメント0

**デフォルトの名無しさん** · 2023/09/17(日) 13:30:45.41

オブジェクト指向は非常に重要
クラスも重要
これはプログラミング言語界で結論が出ている
だから最近のプログラミング言語Swift、kotlinなどはいずれもクラスを持っている

**デフォルトの名無しさん** · 2023/09/17(日) 13:47:21.55

JavaScriptのclass構文はよく使われてる印象だな
オブジェクト指向言語でもないのにわざわざclass名乗るって、よほど需要ありと見えるが

**デフォルトの名無しさん** · 2023/09/17(日) 13:48:32.84

javascript ω の object で class less 設計に目覚めた

**デフォルトの名無しさん** · 2023/09/17(日) 13:48:58.94

SwiftはObjC、KotlinはJavaの代替だから外れるわけないわな

**デフォルトの名無しさん** · 2023/09/17(日) 13:49:35.71

>>144
あれは prototype が理解出来なかった人が多かったから class が後付けされたんだろ

**デフォルトの名無しさん** · 2023/09/17(日) 13:50:12.29

俺は継承よりもカプセル化が重要だと思う
だがカプセル化はクラスの専売特許ではない

**デフォルトの名無しさん** · 2023/09/17(日) 13:57:14.58

>>143
自ら敗北を認めたようだな
SwiftはAppleがObjective-Cの後継と位置付けた訳ありでクラスを採用
KotlinもJavaの後継と位置付けた訳ありでクラスを採用
つまり二つとも例として出してないけない過去のしがらみのある訳あり言語

一方で過去のしがらみのないGoやRustやNimなどの新たな言語では当然クラスは採用されなかった
いずれも全く異なる方向性の言語であるがクラスは不要なものであるという共通認識がプログラミング言語界にあるためだ

**デフォルトの名無しさん** · 2023/09/17(日) 14:24:30.92

まあ構造体も継承出来るんですけどね

**デフォルトの名無しさん** · 2023/09/17(日) 14:54:07.42

>>149
そんな共通認識は無い
おまえが勝手に言ってるだけ
新しい、なんてのは何の根拠にもなってない
残念、論破、さよなら

**デフォルトの名無しさん** · 2023/09/17(日) 15:11:21.73

元々「クラス」という言葉は義務教育の頃から皆馴染みがあり下位層で育った奴には嫌な思い出しかないだろう
クラスという言葉に忌避感を持つ人間は日本だけでなく恐らく世界中にいると推測できる
だからクラスは不要だとかオワコンとか言ってクラスの概念自体を排除した新しい物を模索しようとする
一方、過去にトラウマの無い上位層は特にクラスに忌避感を持たずに有力な1手段として使い続けるだろう
これが悲しい真相ではないかと仮説を立ててみる

**デフォルトの名無しさん** · 2023/09/17(日) 15:42:41.52

>>150
いわゆるクラス継承は害悪という共通認識が広まり
Go, Nim, Rustなどの新しい言語では排除されている

**デフォルトの名無しさん** · 2023/09/17(日) 16:13:46.24

複オジこんなところでも自演してまで珍説唱えてんのかよw

>>137,149,153はRustスレ出禁扱いになってる珍説を強弁するだけの複製オジさんなる人物なので相手にするだけ時間の無駄

**デフォルトの名無しさん** · 2023/09/17(日) 16:39:47.21

>>138
http://asahi.5ch.net/test/read.cgi/newsplus/1694055825/

**デフォルトの名無しさん** · 2023/09/17(日) 16:42:40.76

ID:gR/F5lVJ はちょっと煽ってからかえばﾎﾟﾝﾎﾟﾝ反応してﾜﾛｽｗ
沸点低すぎ

**デフォルトの名無しさん** · 2023/09/17(日) 17:05:40.99

今頃また顔真っ赤にして怒り狂ってそう
( *´艸`)ｸｽｸｽ

**デフォルトの名無しさん** · 2023/09/17(日) 17:17:54.06

まあ顔真っ赤おじさんとかどうでもいいんすけど、どう考えてもオブジェクト指向の優勝、圧勝なんすよ、もー話になんないす

**デフォルトの名無しさん** · 2023/09/17(日) 17:24:05.04

また釣れたｗ

**デフォルトの名無しさん** · 2023/09/17(日) 17:25:30.93

オブジェクト指向はプログラム方法の一つの「説明」でしかないのに勝ち負けって頭悪すぎる

**デフォルトの名無しさん** · 2023/09/17(日) 17:50:31.52

>>159
と、また釣れたおじさんが申しておりますw

**デフォルトの名無しさん** · 2023/09/17(日) 18:28:12.30

ﾎﾟﾝﾎﾟﾝダボハゼみたいにすぐ釣れて釣りとしては面白くないな。
入門で目にしたオブジェクト志向以外知らない頭の悪い初心者だということはよくわかった

**デフォルトの名無しさん** · 2023/09/17(日) 19:25:51.35

>>162
と素人が申しております

**デフォルトの名無しさん** · 2023/09/17(日) 19:48:48.58

はい論破とオウム返しばっか、池沼かよ
┐(´д｀)┌ﾔﾚﾔﾚﾀﾞﾜ

**デフォルトの名無しさん** · 2023/09/17(日) 20:37:36.54

>>164
と池沼が申しております

おまえには十分だろw

**デフォルトの名無しさん** · 2023/09/18(月) 04:03:20.68

いまだオブジェクト指向、継承とか言っているのはこんなやつ

**デフォルトの名無しさん** · 2023/09/18(月) 07:00:18.19

朝の4時にそのレスできて良かったじゃん

**デフォルトの名無しさん** · 2023/09/18(月) 07:55:33.59

書き込み下’時間でマウントｗ

**デフォルトの名無しさん** · 2023/09/18(月) 09:12:53.00

マ板でやれやバカども

**デフォルトの名無しさん** · 2023/09/18(月) 09:43:43.01

非表示にしとけよ拘りつよつよアスペくん😅
>>169

**デフォルトの名無しさん** · 2023/09/20(水) 23:29:17.31

モジュール化の手法として関数がまず考えられた。
共通するまとまったルーチンを実行するにあたって関数は便利であったが、
呼び出しをしてメモリ上に展開されても処理が完了するとメモリ上から消滅してしまう
（それまでの履歴がパァ）という性質のものだった。

simulaの開発者の一人であるダールは、そのせっかくメモリ上に展開したデータであるのに、呼び出しが完了してしまうと制御もメモリ展開ももとに戻ってしまう関数（正確にはブロック）に代わるものとして、
呼び出したとしても制御もメモリ展開も消滅しない、つまり状態をもつ関数（局所変数を持つ関数）を「オブジェクト（object）」と呼んだ。

アラン・ケイは、その関数とは性質が異なる「オブジェクト」を多用するプログラミングを安直にオブジェクト指向と呼んだ（ようだ）。

歴史的に整理すると
構造化プログラミングは、関数を多用するプログラミング（基本３構造は前提）。
オブジェクト指向プログラミングは、ダールのオブジェクトを多用するプログラミング。

と言える。嘘だと思うならダールの論文を読んで見ればいい（と言いつつ本当に読んだら細かい重要なところをバッサリと切り落としているのがバレる）。

**デフォルトの名無しさん** · 2023/09/20(水) 23:35:39.69

オブジェクト指向がわかりにくいのは
ダールの論文がいろんな画期的なアイディアてんこ盛りなせいだ。
オブジェクト（object）という概念が画期的なのに、オブジェクトを生成するクラスやオブジェクトの型概念にも触れていて、何がポイントかわかりにくい。

でも何回か読んでるとダールのいうオブジェクト（object）という概念が画期的なのだと分かる。

要するに関数に代わるモジュール化の手法が（ダールの）オブジェクト。

**デフォルトの名無しさん** · 2023/09/21(木) 00:10:08.07

今年から流行りだした生成AIはオブジェクト指向と関係ない
数式のように誰にとっても明解でないところが終わってるオブジェクト指向は愚かな人間どもの間違ったアプローチ
その先には何も無さそうな事だけは誰の目にも明解

**デフォルトの名無しさん** · 2023/09/21(木) 00:20:33.81

状態が可変のオブジェクトはデバッグが難しい
どこで状態が変わるのかわからんようになるわ
業務要件とは独立したデータ構造でさえ多少複雑なことするとそういうことおこる
ミュータブルは最小にしたが良い、マジで

**デフォルトの名無しさん** · 2023/09/21(木) 00:22:34.55

>>102
あれはオブジェクト指向ではなくて抽象データ型。
インスタンスが状態持たないでしょ？

**デフォルトの名無しさん** · 2023/09/21(木) 00:25:05.90

オブジェクトは状態持ってるからオブジェクトなんだよ!と強く言いたい。
持ってないならそれはそれは単なる抽象データ型のインスタンス。

**デフォルトの名無しさん** · 2023/09/21(木) 00:28:54.33

>>172
それはクロージャ
オブジェクト指向に限らず関数型でも使える
つまりオブジェクト指向の本質ではない

**デフォルトの名無しさん** · 2023/09/21(木) 00:30:07.90

>>175
Rustでももちろんインスタンスが状態を持つよ

**デフォルトの名無しさん** · 2023/09/21(木) 00:31:45.48

Cで書いた抽象データ型のインスタンスでも状態持つものはいくらでもある

**デフォルトの名無しさん** · 2023/09/21(木) 00:37:01.04

>>177
クロージャからオブジェクトを生成する事もできるから似ていることは認めるが、オブジェクトを生成できるのは関数型でも破壊的変更ができるcommon lispとかschemeだけ。sicpにも書いてある。
純粋関数型のhaskellはクロージャからオブジェクトを生成するのは無理。破壊的変更ができないから。

schemeをもとにしたというjavascriptは実際クラスを使わない場合、クロージャでオブジェクトを生成する。真似するとオブジェクト指向でクラスは本質ではない。

**デフォルトの名無しさん** · 2023/09/21(木) 00:39:36.94

>>178,179
そら状態じゃなくて値
多分そういうのrustだとlet mutと宣言してるだろ？