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

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

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

**デフォルトの名無しさん** · 2024/02/19(月) 02:37:07.20

↑2000年代で止まってるオッサン

**デフォルトの名無しさん** · 2024/02/19(月) 07:21:21.34

あの当時の人なら一度は、オレオレプロジェクトで継承を使いすぎた経験ってあると思うのね

**デフォルトの名無しさん** · 2024/02/19(月) 08:07:57.52

継承しまくって訳わからん事になるなら新しいクラスにした方がいいと思うけどなあ
File
-◯◯FileBase
--◯◯FileStructure
---◯◯FileModel
----◯◯FileInstance

みたいなのよりFile2を定義し直した方が遥かにマシ

**デフォルトの名無しさん** · 2024/02/19(月) 08:13:47.31

ファイル名なんかもそうだが
File_20240219
のようなユニークIDつけておくといくら被っても困らない

**デフォルトの名無しさん** · 2024/02/19(月) 09:09:06.20

重複(安易なコピペ)コードはちょっとでもいけませんってきつく言われて、
それを避けるように継承をテキトーに使いすぎた記憶はあるんだよね

is-a 原則を守って、責任者が正しく設計しましょう

**デフォルトの名無しさん** · 2024/02/19(月) 09:20:08.17

似たようなコードが出るなら、サブルーチンにすりゃよかったんだけどね
あの頃は名前空間をあんまり使いこなせてなくて、なんでもクラスに押し込みゃいいと思ってた

**デフォルトの名無しさん** · 2024/02/19(月) 09:26:15.27

>>855
と、継承すら理解できない素人が申しております

**デフォルトの名無しさん** · 2024/02/19(月) 10:20:44.59

Rustが重複コードは二度と書かないってポリシーだっけ
最初の一歩踏み出すのにとんでもなく時間かかりそう

**デフォルトの名無しさん** · 2024/02/19(月) 10:25:51.91

何をもって重複コードとみなすのかなぁ
たまたま別の機能で同じコードになったとかは
まとめると後で痛い目に遭うよな？

**デフォルトの名無しさん** · 2024/02/19(月) 10:35:06.92

>>864
Rustは書かなきゃいけないボイラープレートが多いから重複コードも多い
コピペ継承とマクロ継承がよく使われてる

**デフォルトの名無しさん** · 2024/02/19(月) 10:54:32.58

c++ コンセプトをそのまま変数のインターフェイスに使えればなぁ、と思う事はある。

**デフォルトの名無しさん** · 2024/02/19(月) 11:18:30.32

>>864
Rustも他の言語と同様に重複コードがあれば関数として切り出すだけだよ
その時に異なる型に対してもトレイト境界により安全にジェネリック化がしやすく多用されてるね

>>866
Rustは継承ではなく合成と移譲をするためその宣言は増えるけどそれらを重複コードとみなすのはありえないよ

**デフォルトの名無しさん** · 2024/02/19(月) 18:18:36.14

>>868
どういう構造で作られているかは重複コードとみなすかどうかには一切関係ない
変更をロックステップで適用しなければいけないのならどういうものであれそれらは重複コード

**デフォルトの名無しさん** · 2024/02/20(火) 00:04:11.84

スマポみたいな機能の重複回避には昔は継承を使った
今はジェネリクスを使う
昔の方法ではスタックのint型とヒープのInt型を統一できない

**デフォルトの名無しさん** · 2024/02/20(火) 02:06:05.00

すべての型に対して全て同じ実装でよければジェネリクスで良いが一部の型でカスタマイズが必要になるといろんな障害が出てくる

**デフォルトの名無しさん** · 2024/02/20(火) 05:49:02.76

>>871
それは普通によく起こることだが全く問題ない
その型ごとの差異の機能を合成するだけで対応できる
もちろんジェネリクスのままでよい

**デフォルトの名無しさん** · 2024/02/20(火) 06:10:00.38

インタプリタならそれでいいんだけどね。。(個人の感想です

**デフォルトの名無しさん** · 2024/02/20(火) 10:28:59.91

一部の型でカスタマイズが必要な場合にジェネリクスを使おうとすると将来を見通したカスタマイズポイントを最初に確定しておく必要があって多くの場合現実的ではない
要はOCPを満たせないので変更に対して弱く保守性の低いプログラムになる

加えてRustではcoherenceの制限だったりspecializationやHKTが未サポートだったりで使える状況がかなり限定されている

**デフォルトの名無しさん** · 2024/02/20(火) 10:53:42.40

>>873
Rustでも>>872の「その型ごとの差異の機能を合成するだけでジェネリクスのまま対応」できるよ
Rustは必要な機能のトレイト境界を指定することでコンパイル時点で静的にジェネリクスでも安全に呼び出すことが保証されるよ
呼び出し方法は静的ディスパッチによる単相化またはvtable利用の動的ディスパッチどちらも選択できるよ

**デフォルトの名無しさん** · 2024/02/20(火) 10:57:44.32

そもそもRustが大規模開発にゃ向いて無い件

**デフォルトの名無しさん** · 2024/02/20(火) 11:08:20.16

>>876
大規模開発もできるように作られたRustについて真逆のウソはよくないよ
既に大規模開発で採用しているGoogle Microsoft Amazonといった大手IT企業たちが
共同でRust Foundationを設立して資金を出して安定した環境でさらなる開発が進められているよ

**デフォルトの名無しさん** · 2024/02/20(火) 11:10:21.09

それってまだ到達して無いって事じゃね？

**デフォルトの名無しさん** · 2024/02/20(火) 12:20:44.40

既にクラウドやCDNなどネットインフラは次々とRust製へ変わった

ソース
＞【クラウド世界トップシェアAWS】
＞https://japan.zdnet.com/article/35183866/
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazоn Simple Storage Service（S3）」、
＞「Аmazоn Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Аmazоn CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。

＞【CDN世界トップシェアClоudflare】
＞https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。

**デフォルトの名無しさん** · 2024/02/20(火) 13:22:34.01

大規模開発以外はオワコンゆえに構造化プログラミングはオワコン
というのがオブジェクト指向の原点なのでオワコン論法を今更やめられない

**デフォルトの名無しさん** · 2024/02/20(火) 13:26:48.23

>>877
そのどれもが大規模開発じゃ無いぞ

使われてるがチームは数名だぞ

**デフォルトの名無しさん** · 2024/02/20(火) 13:36:25.43

数名で各ネットインフラをRustで開発できるなら今後はRustでいいな

**デフォルトの名無しさん** · 2024/02/20(火) 16:28:18.46

「うちは大規模開発でやってる」という発言が出ないで、他人の情報に反応してそういう結論に切り替えるってことは
つまり自分らでは使ってないってことかいな

**デフォルトの名無しさん** · 2024/02/20(火) 16:45:43.34

できるできる詐欺が横行してるな

**デフォルトの名無しさん** · 2024/02/20(火) 18:35:02.11

大規模開発は人数揃えるのが何より大切だからな
COBOLかJava以外ありえない

**デフォルトの名無しさん** · 2024/02/20(火) 20:51:51.45

全部できるよ

**デフォルトの名無しさん** · 2024/02/21(水) 14:43:22.45

MVCで入力処理ってどこにおくべき？
AIとかに聞くとCに置けって言ってくるけど
移植（ライブラリ変更等）時に描画系入力系を
まとめてVに置いておくと楽だと思うんだけど

**デフォルトの名無しさん** · 2024/02/21(水) 14:46:34.08

いまだにMVCとかやってるから海外のアプリに勝てないんだよな

**デフォルトの名無しさん** · 2024/02/21(水) 15:34:28.90

M: 変数
V: public関数
C: private関数

**デフォルトの名無しさん** · 2024/02/21(水) 16:02:41.28

>>887
MVCといってもクライアントサイドのMVCとサーバーサイドのMVCで考え方が違う
また入力処理と言っても人によって指すものが違うので具体的にどういう処理を入力処理とみなしているか書かないとわからない
さらに移植とライブラリ変更は一般的に違うものなので想定状況が伝わらない

**デフォルトの名無しさん** · 2024/02/21(水) 17:11:10.76

M: member
V: virtual
C: constexpr

// 空目

**デフォルトの名無しさん** · 2024/02/21(水) 18:43:28.52

Mutable
Virtual
C++

**デフォルトの名無しさん** · 2024/02/21(水) 20:19:29.17

用語や形にこだわるより先に仕様通り動くもの作れ。くだらないこだわりで何も始められないのはただのアホ

**デフォルトの名無しさん** · 2024/02/21(水) 21:53:18.35

唐突なストローマン論法で草
雑魚味が濃すぎる

**デフォルトの名無しさん** · 2024/02/21(水) 21:58:52.64

>>887
元々は移植性のためにモデルはそのまんま環境と切り離した処理そのものを
ヴューは人間の目に触れる画面レイアウト周り、そしてコントローラーは
それらを繋ぐインターフェイスとして実装という考え方なので
ゲームをPC、コンシュマー、モバイルと移植します画面周りはVです
操作されるゲームの中身はMです、つなぐ部分はCです
…ん？マウスと十字キーとタッチパネル対応はどこまでがCだ？ってなるけど
AIに聞けばテンプレどおりそら「Cに分けなさい」言われるわな

**デフォルトの名無しさん** · 2024/02/21(水) 22:04:57.80

ゲームとビジネスアプリとでは違って来るよな
ゲームなら🎮や⌨はCだが、ビジネスアプリでは単にVの付属物だったりする

**デフォルトの名無しさん** · 2024/02/21(水) 22:11:27.33

うそやん
マウス対応やタッチパネル対応はViewやぞ
AIに聞いてもそう答えるぞ

**デフォルトの名無しさん** · 2024/02/21(水) 23:59:03.36

「入力」の抽象度の違い
ビューに依存した入力とそこから一段階抽象度が上がったビューに依存しない入力がある
それを認識できてればどこに含めるか迷わない

**デフォルトの名無しさん** · 2024/02/23(金) 11:08:19.40

https://twitter.com/mayappy0627/status/1725074809883898273

M a y a ♡🏳‍⚧ヽ(๑╹◡╹)v🏳‍🌈
@mayappy0627
「シスヘテロ男性が女湯に入りたい目的で嘘をついて診断書を取得し性別適合手術を受ける可能性がある」
という言説がいまだに流れている様だが
女湯入ってオカズ目に焼き付けてもチン◯ないからシコれませんのでね。つまり男性的快楽は得られないという結末の一つさえ想定できないんでしょうかね？
午後5:54 · 2023年11月16日
·
https://twitter.com/thejimwatkins

**デフォルトの名無しさん** · 2024/02/23(金) 11:14:17.40

きんたま切り落とした時点で男性ホルモンは著しく減衰して性欲は無くなるよ🥲

**デフォルトの名無しさん** · 2024/02/23(金) 11:34:54.51

class Man(Human):
...
def do_chinko():
if (chinko is None): return None
return finish()
...

**デフォルトの名無しさん** · 2024/02/28(水) 21:12:31.15

>女湯入ってオカズ目に焼き付けてもチン◯ないからシコれませんのでね

人間に独立した人格が有るように、チンポにも独立したチン格が有る
これは親クラスと子クラスの継承関係である
チン格とはつまり「愚息」であり、自分にも他人にも成り得る
これがオブジェクトの多態性と表現される
オシッコするときのチンポは随意筋、勃起するときのチンポは不随意筋
このように時と場合によって真逆の性質を併せ持つことができる

随意筋　不随意筋
　　↖　↗
　　チンポ

自然言語処理において語の意味は文脈によって変わるので、Pythonのような多重継承が不可欠ね！

**デフォルトの名無しさん** · 2024/02/28(水) 21:59:59.89

機能するかどうかだけが問題で、欲求があるかどうかはあんまり関係無いよな

**デフォルトの名無しさん** · 2024/02/29(木) 17:11:51.40

オブジェクト指向では、オブジェクトの「機能」を意識することが大切ね！

>>903
>機能するかどうかだけが問題で

オブジェクト指向（OOP）は、データとそれに関連するメソッドを「クラス」という単位でまとめて管理する開発手法です。
このアプローチにより、開発者は複雑な機能も再利用可能なモジュールとして効率的に構築できます。例えば、
新しい機能を開発する際、既存のクラスから必要なデータを取得し、必要に応じて新しい機能を追加することが可能です。
https://zenn.dev/cloud_ace/articles/29748ac0537c7f

**デフォルトの名無しさん** · 2024/02/29(木) 17:34:03.72

モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている

**デフォルトの名無しさん** · 2024/02/29(木) 18:33:41.13

むしろ、何段も継承されてわけわからん事になるのが嫌われてるだけなので
swiftなんかはfinalつけてサブサブクラス禁止できるようにしてるな

**デフォルトの名無しさん** · 2024/02/29(木) 18:44:02.92

こんなスレで御託長文書くのはプログラム作れない人

**デフォルトの名無しさん** · 2024/02/29(木) 18:55:21.40

悪手と言われると、極めたくなるんだよなあ

**デフォルトの名無しさん** · 2024/02/29(木) 21:12:27.90

>>905
クラスと呼ばれるものがないだけで
メソッドを生やせる構造体も継承も
Elixir以外のすべての言語に存在する
君が無知なだけ

**デフォルトの名無しさん** · 2024/02/29(木) 21:41:50.06

クラスが存在しないことが最重要だからクラスを採用しない言語が増えてるんだよ
クラスは間違った手法『具象型から具象型への継承』となる禁忌のクラス継承を伴うからね

オブジェクト指向に必要なカプセル化は構造体などでもちろん可能だから
オブジェクト指向にはクラスは不要だよ
そしてインターフェイスや型クラスなどによる正しい手法『抽象型から具象型への継承』が代わりにあればよい
モダンな各プログラミング言語はそれらの方針をとっている

だからクラスが採用されてないんだよ
クラスは悪

**デフォルトの名無しさん** · 2024/02/29(木) 22:35:54.39

継承に親兄弟を殺された人がいるようだが世界は残酷なのだ

**デフォルトの名無しさん** · 2024/02/29(木) 22:42:52.64

悪い→『具象型から具象型への継承』←クラス
良い→『抽象型から具象型への継承』←インターフェース・型クラスなど

**デフォルトの名無しさん** · 2024/02/29(木) 22:58:22.40

要は個人開発レベル小規模webサイトレベルなら継承の類不要？つうかDIだけでは駄目なん？

**デフォルトの名無しさん** · 2024/02/29(木) 23:10:15.09

規模にかかわらず同じ
抽象型からの継承は問題ない
クラス継承はダメ

**デフォルトの名無しさん** · 2024/03/01(金) 08:38:11.92

>>914
「抽象型の仕様が安定している限り」な。

抽象型の改変が入ったらインパクトが大きい。

**デフォルトの名無しさん** · 2024/03/01(金) 08:59:14.79

そこでダックタイピング(の併用)だな

うん、継承一本ってのは、人類には早かった

**デフォルトの名無しさん** · 2024/03/01(金) 09:08:35.51

クラス継承は具象型からの継承なので多重継承の問題が発生する悪い方法だが
抽象型からの継承は多数あっても合成となり良い方法

>>915
抽象型は各機能毎に細かく多数用意されて合成して使うためそのような問題が起きない
抽象型の改変とは機能を変えることになるため別の抽象型として並行して扱える

**デフォルトの名無しさん** · 2024/03/01(金) 10:31:31.13

>>917
なら設計の初期に細かく多数の抽象型を決めなきゃいけない、ということになるわな。
未来を予測できる天才でもなければ厳しいな。

**デフォルトの名無しさん** · 2024/03/01(金) 10:32:36.36

まあ、たいていのクラス設計は
製造終盤になると跡形も無いんだがな

**デフォルトの名無しさん** · 2024/03/01(金) 10:56:06.21

>>918
クラスはピラミッド型の階層構造となり改変で他へ影響が大きく出る問題があり
クラスは具象型なのでそれ自体がメンバ変数(フィールド変数)を持ち途中階層のクラスも持つため改変が非常に大変もしくは崩壊となりがち

抽象型でメンバ変数(フィールド変数)を持たないインタフェイスや型クラスではその問題が起きない
それら抽象型による各機能の合成をとるため改変する場合も他機能への影響が限定的となり問題を分離することができる

**デフォルトの名無しさん** · 2024/03/01(金) 12:34:53.51

人間が理解しやすくなればなんでもいいシコ

**デフォルトの名無しさん** · 2024/03/01(金) 12:45:52.70

>>920
メンバ変数の無い抽象型であっても、分離できるのは実装部分でしかなくて、「機能ではなく型の種類＆名前で縛られる」という設計の初期の困難さは回避できていないよ。

まぁ、インターフェイスとかトレイル(Rustの偽物は論外)とかでもモジュール境界とモジュール間連携の問題は解決できていないからなぁ。何かいいアイディア無い？

**デフォルトの名無しさん** · 2024/03/01(金) 12:51:44.04

IDEのリファクタリング機能があれば何でもいいよ

**デフォルトの名無しさん** · 2024/03/01(金) 16:38:06.02

>>905
バカの一つ覚え

**デフォルトの名無しさん** · 2024/03/01(金) 17:27:04.12

それが>>911 の人、何人かいるっぽい

**デフォルトの名無しさん** · 2024/03/01(金) 20:56:33.23

継承には感謝しかないです

**デフォルトの名無しさん** · 2024/03/01(金) 21:29:01.44

クラス継承さえ使わなければ
継承は便利だからね

**デフォルトの名無しさん** · 2024/03/01(金) 22:31:08.80

メソッドだけ継承できればいいよ

**デフォルトの名無しさん** · 2024/03/02(土) 07:16:17.19

クラスとかメソッド集合としての機能だけあればいい。
その代わりに外延性と集合演算をサポートしてくれ。そうすりゃ継承みたいなクソツールは要らなくなる。

**デフォルトの名無しさん** · 2024/03/02(土) 11:56:05.36

クラスとか継承とかに不満持つのは不思議なんだが、他人の作ったコードやライブラリをうまく流用出来ずに文句言ってるのか？
自分で作る分には言語の機能にあっても使わなきゃいいだけだろうに
他の人が理解できないからだ、ってのならその「他の人」に言え

**デフォルトの名無しさん** · 2024/03/02(土) 12:17:52.47

人間が理解しやすくしなよ

**デフォルトの名無しさん** · 2024/03/02(土) 13:55:18.96

>>930
他の人になんて言えば良い？

**デフォルトの名無しさん** · 2024/03/02(土) 13:56:06.21

>>930
クラス継承については全員が問題視している
Javaの生みの親ですらJavaを作り直せるならクラスを除外すると明言している
そして現実にモダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなど全てがクラスを除外している

＞Javaのユーザグループミーティングに出席した際、
＞James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
＞すばらしいQ&Aセッションの途中に、こんな質問が出ました。
＞「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
＞答えは「クラスを除外するでしょうね」というものでした。
＞彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
＞インターフェースによる継承（implementsの関係）のほうが望ましいのです。
＞できる限り実装継承は避けたほうがよいでしょう。

**デフォルトの名無しさん** · 2024/03/02(土) 13:58:52.73

ねえ！他の人になんて言えばいいの！？

**デフォルトの名無しさん** · 2024/03/02(土) 14:38:32.67

「俺は継承に親を殺された。絶対赦さない。絶対にだ」

**デフォルトの名無しさん** · 2024/03/02(土) 14:43:33.20

｡°(´∩ω∩`)°｡

**デフォルトの名無しさん** · 2024/03/02(土) 14:47:09.39

>>933
どこからの引用なのかちゃんと書こうよ
https://postd.cc/is-go-object-oriented/

**デフォルトの名無しさん** · 2024/03/02(土) 15:01:00.73

>>933
バカの一つ覚え乙

**デフォルトの名無しさん** · 2024/03/02(土) 15:26:08.25

>>937
丁寧な説明あって助かったありがとう
実装継承は問題があるためクラス継承を使うのは辞めた方がよさそうね
そうするとクラス自体が不要なので今どきの言語にはクラスが無いわけなのね

**デフォルトの名無しさん** · 2024/03/02(土) 17:53:44.47

継承すると結合度が高くなり、基底クラスがいじりにくくなるから
implements で名前だけ基底クラスで宣言した方がよい
という経験則なわけね

**デフォルトの名無しさん** · 2024/03/02(土) 18:23:50.25

>>940
違うよ
基底クラスは一切使わずにインターフェース等を使う
インターフェース等を備えていない言語ではやむをえないため抽象クラスで代替する

**デフォルトの名無しさん** · 2024/03/02(土) 21:21:19.79

15年ぐらい前はstaticおじさんが馬鹿にされてたけど今じゃオブジェクト指向がオワコン呼ばわりかぁ

Lisp使おう（）

**デフォルトの名無しさん** · 2024/03/03(日) 00:19:19.60

処理系も書かずに使おう(笑)

**デフォルトの名無しさん** · 2024/03/03(日) 12:51:43.47

オブジェクト指向に毒されてるpowershwll,python,ruby等も終わりかな
F#に興味出てきたな

**デフォルトの名無しさん** · 2024/03/03(日) 13:22:58.46

あたりまえにオブジェクト指向使ってる現代でオブジェクト指向がオワコンって言うのはプログラム作らない人
ここの板のローカルルールくらい見ましょうね

**デフォルトの名無しさん** · 2024/03/03(日) 13:49:21.97

やたらとオブシコしてたのからの回帰ってならわかるそういう意味なんだろうなと思う

**デフォルトの名無しさん** · 2024/03/03(日) 14:11:44.50

>>940
何でそんなこと言うん？

**デフォルトの名無しさん** · 2024/03/03(日) 17:32:00.15

https://twitter.com/i/status/1763848620204544172

オブジェクト指向にも同じことが言えます
https://twitter.com/thejimwatkins

**デフォルトの名無しさん** · 2024/03/03(日) 17:33:19.72

オブジェクト指向を実践してない人ほど継承はダメだといっておられる
現実をまったく見ていない理論でしかないわけです

**デフォルトの名無しさん** · 2024/03/03(日) 17:33:33.79

40年前に構造化プログラミング(いまあたりまえのプログラムをブロックモジュールに分ける概念)についてけなかった人とかも
理解しないまま「構造化プログラミングはオワコン！これからはオブジェクト指向！」ってそもそも構造化プログラミングの
発展系がオブジェクト指向だってわからずこのアホウみたいにウキャウキャしてたのかしら

**デフォルトの名無しさん** · 2024/03/03(日) 18:10:26.26

>>949
正しく理解しようよ
ダメなのはクラス継承
抽象型の継承はOK
オブジェクト指向もOK

**デフォルトの名無しさん** · 2024/03/03(日) 18:26:34.56

>>951
Pythonは文脈によって意味が変わる多重継承ね！

随意筋　不随意筋
　　↖　↗
　　チンポ

**デフォルトの名無しさん** · 2024/03/03(日) 20:11:50.76

ついていけない人間がたくさん出てしまうパラダイムは多くの人間が使えないので自明にオワコン

**デフォルトの名無しさん** · 2024/03/03(日) 21:12:52.05

>>950
ありそうな話だなあ

**デフォルトの名無しさん** · 2024/03/03(日) 21:35:56.29

>>933
Cの生みの親が作ったGoはともかく、Rustにクラスがなかったのはマジびびった。

Haskell覚えたときに、オブジェクト指向プログラミングの再利用性に疑問持って、
（実際にはしないけど）C++でクラス使わずテンプレートだけ使った方が再利用しやすいんじゃ…？とか思った。

そして最近、「スッキリわかるC言語」立ち読みしたら、C言語に（テンプレートとは違ってマクロっぽいが）ジェネリックっぽい機能が取り入れられてるみたい。
（使えないコンパイラがまだ多いのでLinuxのカーネル開発では禁止されてるみたいだけど）

あと、デザインパターンも、関数型言語で普通にしてる事がいくつか書いてて、オブジェクト指向言語だと意識しないと出来ないんだと気づいた。
（例：イテレータ、テンプレート・メソッド、シングルトン、アブストラクト・ファクトリ、ストラテジなど）

**デフォルトの名無しさん** · 2024/03/03(日) 22:06:17.23

広い意味のオブジェクト指向は今でも有用であって
クラスを使ったオブジェクト指向が間違っていただけなので
GoやRustなど新しい言語にはクラスが無いけど(クラスを使わない)オブジェクト指向ですよ

**デフォルトの名無しさん** · 2024/03/03(日) 22:11:46.53

>>953
おまえがオワコンなだけ。お前自身がついていけなくても、ついていけない人がたくさんいると思っていても
実際には多くの人がすでに実行してる。今やその辺の小学生でも
https://www.nhk.or.jp/school/sougou/programming/