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

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

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

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

インターフェース楽しいな～
継承無しでコーディングできる～

**デフォルトの名無しさん** · 2024/02/04(日) 23:05:40.25

塊って言いたいだけ

**デフォルトの名無しさん** · 2024/02/04(日) 23:11:46.13

>ひと塊のルーチンを“関数”として入り口出口を決めましょう
これ現役引退してるような世代の方ですよね？

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

役割で固めるってのを忘れてる

**デフォルトの名無しさん** · 2024/02/05(月) 11:38:56.86

横断的関心事の意味が分からんと常々思っていたけど
役割で固めるのをやめるという意味なのかね
固めようと思ったことがない奴にとっては無意味なことだ

**デフォルトの名無しさん** · 2024/02/05(月) 12:31:22.93

横断的にシコシコする役割の塊がオブシコである

**デフォルトの名無しさん** · 2024/02/05(月) 17:30:42.79

オブジェクト指向はモジュラリティを高めるために考え出されたものだが「どの抽象化階層のモジュラリティを高めるものなのか」という大前提を理解していないと何を見てもオブジェクト指向だと感じるようになる

**デフォルトの名無しさん** · 2024/02/05(月) 23:45:04.18

そりゃオブシコするぐらいだからモジャラリティは高いだろ

**デフォルトの名無しさん** · 2024/02/07(水) 14:59:43.29

1. 簡単な言葉を使う
頭が良い人は、複雑なことや専門知識も「簡単な言葉」で説明することができます。
この能力は、深い理解があるからできること。相手が理解しやすいように情報を整理して伝えることは思いやりでもあります。
https://news.yahoo.co.jp/expert/articles/9bb7a62121796847a941127e3d5040008fedd464

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

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

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

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

世界一オブジェクト指向に忠実なメインクラスできたで

class Main():
def do():
pass

m=Main()
m.do()

**デフォルトの名無しさん** · 2024/02/13(火) 15:11:48.80

オブジェクト指向はオワコン
継承はよくない文化

**デフォルトの名無しさん** · 2024/02/13(火) 17:38:57.37

Template Methodパターン便利ですよ

**デフォルトの名無しさん** · 2024/02/13(火) 18:33:53.66

has a関係は抽象度の低いクラスを参照することはマナー違反ではない
is a関係は自分よりも抽象度低いクラスを継承したらマナー違反だよな

**デフォルトの名無しさん** · 2024/02/13(火) 19:00:08.50

継承を理解してれば問題無い
理解していないけどら問題無く使える道具は存在しない
つまり須く低レベルということ

**デフォルトの名無しさん** · 2024/02/13(火) 19:17:02.49

>>786
俺は使えるから問題ないんだが部下や上司に無能がいると困る
全ての言語で機能ごと消去するべき

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

C/C++でいいところを無能のためにRustでわざわざメモリ管理を強制的に縛るのと一緒やね

**デフォルトの名無しさん** · 2024/02/13(火) 19:54:20.90

オブジェクト指向って>>1みたいな頭の悪い人でもプログラミングできるようにするためにあるんだよ
難しいのは>>1みたいな馬鹿が>>1みたいな馬鹿のためにオブジェクト指向に則ってプログラミングする行為であり、>>1みたいな馬鹿がオブジェクト指向で設計されたコードを扱うのは難しくない
オブジェクト指向がオワコンな訳が無い

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

>>787
無能がいる限り何の解決にもなってない
リスクが下がったと勘違いしてるだけ

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

>>788
Rustを使えない無能がC/C++を使って穴を生み出し続けている現実を見ようぜ

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

>>791
その無能がrust使ったところでろくなものは生み出せない
包丁で怪我する人がいるから包丁は悪、と言ってるのと同じ。
別に主張するのは自由だがそれで包丁が消滅することはない

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

頭の悪い人がプログラミングできるためってたまに見るけど疑わしいわ
頭の悪い人がちゃんと設計して、多態性を活用してるのを見たことがない
ただメモリの自動解放とかライブラリに頼ってるだけで、
そういう利便性はオブジェクト指向とあんまり関係なくね？

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

知らないのか？今は転職ブームのせいで文系出身の頭悪いプログラマが大量発生してる
そいつらのせいで言語が変わらなくては生けない時代になった

**デフォルトの名無しさん** · 2024/02/14(水) 08:07:28.98

言語が変わっても頭悪かったらどうにもならないよw

**デフォルトの名無しさん** · 2024/02/14(水) 08:40:34.28

>>795
多少はマシになるやろ

**デフォルトの名無しさん** · 2024/02/14(水) 10:07:41.88

>>796
無能じゃコンパイル通せないから動かせない
つまり逆に悪くなってる

**デフォルトの名無しさん** · 2024/02/14(水) 10:15:13.33

>>797
無能が進捗管理で炙り出されるから全然マシ

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

>>797
本番段階でバグが出るよりマシ

**デフォルトの名無しさん** · 2024/02/14(水) 11:08:35.63

コンパイル通すのが難しいと無能はコンパイル通ったからOKという感覚になるので一長一短

何事も良い面悪い面があるのに無能は片面だけしか見ない

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

>>800
最低限コンパイラの通れば多少見れるコードになってるので、有能がコードをレビューしやすい

**デフォルトの名無しさん** · 2024/02/14(水) 12:27:44.94

>>798
それは言語の役割じゃない
全然マシでもなんでもなくて草

**デフォルトの名無しさん** · 2024/02/14(水) 12:31:09.06

>>799
どっちでも一緒
納品できないのに「本番でバグが出るよりは良い」と言い張るのはアタオカ

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

現実は納期というものがあるから効率重視でCC++使って適当に作れたほうがありがたいんだよなあ
バグなんてある程度は知らんぷりしていい
わざわざRustを使って完璧を求めるのは無駄

**デフォルトの名無しさん** · 2024/02/14(水) 13:03:09.87

長所も短所も両方知っている知識人を理想とするのは
商売とはあまり関係ない理想だ
商売を重視しないのであれば長所も短所もわりとどうでもいい

**デフォルトの名無しさん** · 2024/02/14(水) 13:18:52.38

>>801
コンパイルを通しやすいかどうかとコードが見やすくなるかどうかに正の相関関係は無い

加えてコンパイルを通しにくくなればなるほどコンパイルを通すための手助けが当然必要になる

「身の丈に合った言語を」 by 萩豚

**デフォルトの名無しさん** · 2024/02/14(水) 13:20:42.45

Rust習得できない馬鹿が書いたC++コードの保守、やりたくなさすぎる

**デフォルトの名無しさん** · 2024/02/14(水) 13:57:57.05

>>803
本番でバグとか酷い炎上案件。
クライアントにとっては悪夢ですなぁ。
納期遅れのほうがまだ見える分マシ。

**デフォルトの名無しさん** · 2024/02/14(水) 13:59:03.81

>>806
コンパイルできる人材を確保できるかどうかは中途採用ガチャしまくればいける
コンパイルできねえやつは捨てる、それだけだ

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

>>807
だれがあなたを頼るの？

**デフォルトの名無しさん** · 2024/02/14(水) 15:03:18.56

>>808
都合良く「納品はできる」妄想を前提として話を進められるならどうとでもなる
結局無能でもどうにかなるなんて全く現実的ではない、rust信者の詐欺的妄言なのでどっちでも一緒

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

>>809
技術者をまともに育成する術も評価する術も持たずガチャするしか脳の無い無能企業には有能なやつほど寄り付かない

そうなると渋いと評判の某ガチャUR排出確率並み(0.3%)になるから100回回しても有能1人雇える確率は3割にも満たない
運良く雇えてたとしても数年以内に転職して抜ける確率は逆に8割以上

身の丈に合わない選択は破滅への近道

**デフォルトの名無しさん** · 2024/02/14(水) 17:49:37.27

どこまでオブジェクト設計するべきかが良くわからん
例えばトランプゲームを作ろうとした時のカードについて
数字込みの絵柄と表示用の画像くらいしか必要ないと思うけど
わざわざCardクラスCardDeckクラスとかを用意する必要があるの？とか

**デフォルトの名無しさん** · 2024/02/14(水) 18:11:12.61

Deckが内包するデータはCardの配列のみだとしても
シャッフルやドローなんかの操作を配列として外から行うより
Deckとして備えてる方がシンプルに保てそう

**デフォルトの名無しさん** · 2024/02/14(水) 18:32:43.17

>>813
クラス以外のユーザー定義型がないならオブジェクト指向よりの作り方でなくてもCardクラスやCardDeckクラスくらいは作るんじゃない？

それらにメソッドを生やしてゲームルールを実装していくのか
それともそれらをデータとして扱う関数を別のところに書くことでゲームルールを実装していくのか
それぞれ良い点悪い点があるので一度両方で作ってみるといいと思う

**デフォルトの名無しさん** · 2024/02/14(水) 18:36:07.49

>>814
DeckモジュールとかGameモジュールにドローやシャッフルなどのDeckを操作する処理をまとめておくってのでも別に不都合ないよね？

**デフォルトの名無しさん** · 2024/02/14(水) 18:44:53.20

enumがオブジェクトではない言語では迷うが
すべてがオブジェクトだったらenum Cardでいいのでは

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

スートが切り札(トランプ)に変わるようなゲームでは
判定で「こいつはいまトランプだから」で例外処理するのか
カード側で「いまトランプです」したらいいのかの設計の話だわな

**デフォルトの名無しさん** · 2024/02/15(木) 12:39:33.69

>>793
>ライブラリに頼ってるだけで
そのライブラリに頼ってるだけを実現できるのがオブジェクト指向の功績だと思ってる
昔のWin32APIみたいなライブラリとインスタンス生成してからインスタンス.メソッド形式で利用するライブラリと比較したらライブラリの扱いに対するお手軽＆簡単度合いがぜんぜん違う

**デフォルトの名無しさん** · 2024/02/15(木) 19:49:13.54

いやwin32apiだろうがapiそのものがすでに「オブジェクト指向」だから
手軽とか簡単とかはオブジェクト指向とっくに通り越してそのように改良された結果ってだけ
このスレ見てると「オブジェクト指向」が特別なナニカだと思ってる人も多くてアランケイも困惑するよｗ

**デフォルトの名無しさん** · 2024/02/15(木) 20:05:57.93

「オブジェクト指向」が特別なナニカじゃないのであれば、「オブジェクト指向プログラミング言語」は「プログラミング言語」でよくなってしまう

これまで「オブジェクト指向プログラミング言語」という言葉を使った人間はとんでもないガイジということになる

**デフォルトの名無しさん** · 2024/02/15(木) 23:20:24.51

20年前のあれは何だった？どいつもこいつもオブジェクトだーと喚いてたくせに。屑どもが

**デフォルトの名無しさん** · 2024/02/16(金) 00:12:23.56

ここまでくると糖質っぽいな
オブジェクト指向はオワコンと言い続けて何年経過してんだよw

**デフォルトの名無しさん** · 2024/02/16(金) 06:40:28.27

オワコンにオワコンと言ってなにが悪い

**デフォルトの名無しさん** · 2024/02/16(金) 08:47:18.11

オブシコオ㍗ル

けど、脳汁が出るのは、なんでもアリなC++なんだよなあ

**デフォルトの名無しさん** · 2024/02/16(金) 08:49:55.02

これこれ
オウムみたいな感じ
はなから議論をする気が無い
オワコンオワコン繰り返して気持ちよくなるだけ

**デフォルトの名無しさん** · 2024/02/16(金) 17:46:12.70

非論理的＝気持ちよくなる
専門用語を回避する現象？

**デフォルトの名無しさん** · 2024/02/16(金) 23:46:53.13

自分がオブジェクト指向で挫折したから
あんなの一時の流行りでしかない！って喚いて溜飲を下げようとしてるけど
そもそも理解しないで挫折してるから「あんなの」が永久に
90年代のC++の時の“自動車の車輪を付け替える”からアップデートしない

**デフォルトの名無しさん** · 2024/02/17(土) 01:14:52.71

アップデートという目標は分かったが現時点では違う目標を持つ者にとって
ふつうに考えると目標を達成するためには目標を変更しないのが合理的
問題は、どうすれば永久に合理的であり続けるのをやめられるか

**デフォルトの名無しさん** · 2024/02/17(土) 11:49:08.21

オブシコで挫折してない人なんていません!!

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

俺がいる
中途半端ってぶっちゃけ怖いよね

>>826
議論っていうか、使えと言われた言語・ライブラリ(SDK)使うんだからね結局
好き・嫌い、とかって雑談してりゃいいんだよ

俺は、継承を使いこなせるいい漢になりたいぜ

**デフォルトの名無しさん** · 2024/02/17(土) 13:09:34.49

オブジェクト指向だろうがオブジェクト指向言語だろうが語りたいのならマ板でやれ
雑談どころかここで議論とか正気かよ。議論してもプログラム技術の役に立たないくらいわかるよな

**デフォルトの名無しさん** · 2024/02/17(土) 13:51:00.19

>>831
はっきり言う、お前はオブシコのことを何もわかってない

>>832
お前もだ

オブシコは挫折してからが始まりだ

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

intではなくてMoneyだ
Moneyを継承してYenを作れ

stringではなくてAddressだ
Addressを継承してPrefectureを作れ

本物のオブジェクト指向を経験しろ
ぜったい挫折するから

**デフォルトの名無しさん** · 2024/02/17(土) 14:31:27.57

>intではなくてMoneyだ
当たり前
>Moneyを継承してYenを作れ
意味不明
オブジェクト指向で作るならYenはMoneyの一属性

>stringではなくてAddressだ
当たり前
>Addressを継承してPrefectureを作れ
意味不明

オブジェクト指向だから挫折したのではなく間違ったオブジェクト指向を学ぼうとしたから挫折したんだな

**デフォルトの名無しさん** · 2024/02/17(土) 16:18:56.35

↑ オブシコ厨ってこんなシロートばかりなんですよ

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

>>832
ムに置いときゃ、ムに資するネタがまじるけどね
俺は後から来たけど

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

>>835
MoneyにbaseCurrency問い合わせると“Yen”って返すように作るよなぁオブジェクトなんだから

**デフォルトの名無しさん** · 2024/02/17(土) 19:30:44.83

>>832
迷惑だからマに技術ネタ誘導すんな。

**デフォルトの名無しさん** · 2024/02/17(土) 23:59:55.91

>>824
本当にオワコン化したものは話題にすらならんよ
今どきポケベルはオワコンなんてスレ建てる奴なんていないだろ？
つまり、そういうこと

**デフォルトの名無しさん** · 2024/02/18(日) 02:06:18.29

ポケベルを話題にした自分自身を否定するより
オブジェクト指向にファイティングポーズする方がよっぽどポジティブじゃないか

**デフォルトの名無しさん** · 2024/02/18(日) 06:52:31.86

ＡＰＩやライブラリを一切使わず、自分自身で「処理をしてオブジェクトを返す部分」も作らずにどんなプログラムが作れるんだよ
現代でプログラム書いてるやつは意識しなくても使うしか無い手法じゃないか
使わずにHelloWorldすら書くのは超難しい

**デフォルトの名無しさん** · 2024/02/18(日) 07:05:06.57

システムコールだけでHello Worldやるの無茶大変だった思い出

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

API使ってればオブジェクト指向とか頭になんか湧いてるだろ

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

>>844
そんなこと言われてなくね？

**デフォルトの名無しさん** · 2024/02/18(日) 11:06:51.79

「APIそのものがオブジェクト指向」だと主張してるやつはいるね>>820

**デフォルトの名無しさん** · 2024/02/18(日) 12:13:41.03

とりあえず1000行くらいベタ打ちでプログラム書いて
書いたのをリファクタリングついでにクラス分けして
またダーッと書いてって繰り返せばいいよね？

**デフォルトの名無しさん** · 2024/02/18(日) 12:17:44.83

>>847
今世紀に出てきた様々なプログラミング言語はほとんどがクラスをサポートしていない
クラスは役に立たず害が大きいとの共通認識があるため

**デフォルトの名無しさん** · 2024/02/18(日) 13:06:18.47

>>848
バカの一つ覚え

**デフォルトの名無しさん** · 2024/02/18(日) 14:18:51.57

APIは今でも関数とグローバル変数
stdinとかstdoutとか
グローバル変数が一番最初にオワコン化し、オブジェクト指向は二番目以降と想定された

**デフォルトの名無しさん** · 2024/02/18(日) 16:50:37.61

オブシコで書かれたAPIとかライブラリってのならある。ってなら書いた
COMとかね原理的には、ラッパがあれば、避けることはできる

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

これで動くOSあるなら分からんでもない
OS.boot()

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

低レベルはまた違うでしょ

ってだけではなんなので、ちょっとだけ手を動かしたよ
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Library/UefiBootManagerLib

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

>>848
事実認識ができてない
JavaScript、C#、Python、Ruby、C++、Java、Kotlin
クラス扱える言語はいくらでもあるし、そもそもクラスや継承を使えない=オブジェクト指向じゃないって訳では無い
クラスはお前みたいな馬鹿には使いこなせないからクラス以外でオブジェクト指向な書ける方法が模索されたんだよw

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

どの言語かに関係なく
クラス継承でプログラミングするやつはバカしかいない

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

特定のルートクラスに縛られる継承はだいぶむかしにオブジェクト指向のあまり良くない実装として
仕様を残しながら使わない方がベターになってるわな
使うクラスをオブジェクトとして別個にクラスに組み込むコンポジションの方が主流
「継承というのがオブジェクト指向！」とかいつの時代のおじいちゃんだよ

**デフォルトの名無しさん** · 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

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