オブジェクト指向ってクソじゃねぇかよPart3
■ このスレッドは過去ログ倉庫に格納されています
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/ >>82
C++やJavaについて言えば
OOP言語のクラスscopeや継承などのOOP言語固有の書き方以外は
すべて手続き型記述になるはずだが >>83
でも事実としてOOPのほうがずっと書きやすいんだ
実際に比べたのだから疑いようがない
不思議だね C言語でもこれとか使えば
オブジェクト指向は簡単なんだろう
C 言語によるオブジェクト記述法 COOL ver.2
http://www.sage-p.com/process/cool.htm >>83
ということはクラスなどOOP固有の機能がOOP言語の書きやすさに大きく影響しているのだろうね さてどれどれ
http://www.sage-p.com/process/cool.htm#6
6. 集約の記述、継承の記述
集約の記述
継承の記述
多重継承の記述
重複継承の記述
動的継承の記述
絶句（大爆笑） >>85
それは、言っては悪いけど、
あなたがまだ初心者で
ソフトウエアの基礎分かってなくて
手続き型だろうが関数型だろうがOOPだろうが
まだまとまった規模のソフトウエアを開発したことがなくて
とんど初心者の感触的な意見で物事を決め付けて
語っているから oopのが圧倒的に簡単というのはなんか危険な匂いがするな。。
確かにちょっとしてGUIを用意するっていうのならoop系統のフレームワーク使って
てきとうに組むってのが一番楽なのかも知れんが。 >>67
いや、継承するべきではないという明らからしい結論が出ているのだが、これに即答できないなら、設計に関する書籍の一つも読んだことが無いのだから、議論の前にサーベイが必要かも。 >>90
それは、言っては悪いけど、
あなたがまだ初心者で
OOPの基礎分かってなくて
動的型だろうがライブプログラミングだろうがイメージベースだろうが
まだまとまった規模のソフトウエアを開発したことがなくて
とんど初心者の感触的な意見で物事を決め付けて
語っているから つまり
雑魚でも業務システムを安全に組めるのがOOP
玄人にしか使えないのが手続き型
ということですね >>94
人の問題と、技術の問題を別々に考えると、
人は玄人の方が凄い（当たり前）
技術はOOPの方が凄い
ってことにならないか？ >>95
雑魚にも使えるからと言って、玄人にも使いやすいかというと、そうとも限らないと思う 玄人もみんなOOP使ってる
アンチOOPは一部の変な人しか居ない
組み込みなど仕方なく手続き型を使うことはあるけど
好んで使う人は滅多にない
統計が示す事実なので受け入れよう >>96
そうとは限らないけど、オブジェクト指向に限っては
玄人にとっても使いやすいね メソッドの呼び出し順番がわからないのは玄人仕様なのか？
単に欠陥品にしか見えんが >>102
だからメソッドの呼び出し順番ってなんですか？って
聞いてるんだが？OpenCLを例に教えてください オブジェクト指向以外でプログラム書けと言われてもどう書けばいいかわからない >>105
Linqやstream api、その他類似のライブラリを使うからループってあまり必要ない
ループ内で条件分岐してコンティニューだとか前N回のループで使ったデータにアクセス(例えば移動平均のような)的な複雑な処理だとループしたくなるけど
オブジェクト指向を正しく使うとそういった複雑なフローですら自然と綺麗に消えるから、結論としてループは不要になるんだね >>108
いやそうでもないよ
Linqは遅いなんて10年前の化石みたいな考え方をしてる人よりはよっぽどパフォーマンスについて理解してっからね
君の書くコードのほうが心配
ぐちゃぐちゃの手続き型じゃキャッシュ処理1つ書くのも大変でしょう？ >>109
いや、重いよ
必要のないループ何重にもかけてるでしょ？ 普通はワンループで終わるもの
何周もさせてるのに重くないわけないじゃん
脳みそイかれてるの？ >>110
必要性は状況次第だっての常識な
なので、なんの前提もなしにそれ必要？などと問う人はアマチュアだってバレバレなんだよね
それと何重にも無駄にループとかさ、お前の脳内で繰り広げられてる妄想を急に押し付けられても困るよ >>112
は？おっせぇのが言い訳こいてんじゃねーよｗｗｗ >>113
遅いの定義は？
俺の書いたコードを測定したか？
測定結果と遅いの定義を比較して確かに遅いと言えるのか？
この辺りが当たり前にできないようじゃねぇ
パフォーマンスを語るには10年はやい
5chだから俺が相手してやってっけどさ
お前がここと同じノリで業務中に遅い遅いって喚いても誰にも相手にされんぞ？
遅いと主張したいなら遅い速いの定義、測定法の妥当性の理論的証明、測定結果、分析、改善案をレポートにまとめて提出して
それがプロフェッショナルとして最低限の仕事でしょうよ はいはいコーダーさんたち少し落ち着きましょおねぇ〜w こいつ現実でもクソコード直さない言い訳めちゃくちゃしてそうだな。 俺はいつもOOPでエレガントかつハイパフォーマンスのコードを書くからクソコードを書きなおせなんて言われたことはないなぁ
強いて言うなら開発初期のプロトタイプをリファクタリングする時ぐらいか？
でもそれって人に言われることじゃなく自発的にやることだから言われたっていうのは違うか 自分が書いたコード張ればよいんじゃないの。
見てて痛々しすぎる。 言い返せなくなると悪口
君たちほんとワンパターンだね >>114
長文乙
お前のプログラムもそんなんｗｗｗｗ 昔、「プログラミング言語C++」
を読んでオブジェクト指向をマスター
しようとしたが挫折した
笑ってやってくださいw もうマスターとかいう次元じゃないんだよ
オフショアに発注するのにUMLでも何でもいいけど書いて設計わたさなきゃいけないんだから
自称玄人の単価高いだけのオッサンは要らないぞ？ 「誰も文句を言わない」って状況に少しは疑問を覚えたほうがいい。
その状況は相当ヤバイ。 高スキル人材でも同じ単価だから
逆にレベル下げれば差額で利ざや稼げる コ ー ド 書 く の は 簡 単 だ け ど 、 コ ー ド 直 す の は 難 し い ん だ よ ！ 僕たち地球人〜今日も明日もあさっても〜チンポがシコシコ〜するんだよー！
バ バ ア が 潮 吹 い た ぁ ！
http://egg.5ch.net/test/read.cgi/welfare/1539337979/ >>127
さっさとExcel方眼紙の仕様書通りにコードを書くんだ 876 その名前は774人います (JPWW 0Hc7-PNEt) 2018/11/27(火) 01:56:44.19 ID:DNZYahFJH
『スループット』を測定して、ラグ率を公開しろ！
プログラミング言語の性能差
主な言語とスループット
言語 スループット 特性
C/C++ 100 静的言語ネイティブコード
Java 1〜10 静的言語VMバイトコード
Ruby/Python 0.1〜1 動的言語
オンラインゲームのサーバではC/C++が最も使われ
る
http://www.wata-lab.meijo-u.ac.jp/file/seminar/2013/2013-Semi1-Atsushi_Somekawa.pdf
そう思う 0
そう思わない 200 オブジェクト指向は、Ruby で学ぶのがベスト
Duck Typing・動的クラス定義、
メタプログラミングで、DSL も作れる >>9
間違えたにしちゃなかなかいいな
全ての誤りの原動機、か。 何人かNG登録して前々スレ見てみなよ
日本人には答は出せなさそうだぞ
一般人はヲタや信者にに振り回されず、
言語的進化を享受すればよい もうメリデメフクメテ浸透してるし今更語る事なんてないだろ
所詮道具でしかないんだし適材適所で使っていけ OLEオートメーションサーバにしたって、サーバ側は欧米人が用意するから
日本人は黙ってVBからOLEクライアントのコードをコピペして業務要件をまっとうすればよかっただろ
OOPだって同じこと
ゆめゆめライブラリ提供者になったつもりになって語るなよ
身の程知らずも甚だしくて、おこがましいわ 人間の理解力や把握できる範囲の限界を認めることから出発してるから正直で現実的な考え方だったと思う
で、いろいろ作っていったら複雑になっちゃった
うんちく垂れ流して人を煙に巻く奴まで出て来た
継承の段数が深すぎるなら、コピーして横並びの改造版でもいいじゃん
格好つけるためにやるんなら無意味だよ
俺たちバカで忘れっぽいうっかりさんだからわかりやすくしておこう指向でいいじゃん >>143
チンポ「を」だろ
はいコンパイルエラー
やり直し 611 名無し三等兵 (ﾜｯﾁｮｲ 7fe7-t9Bb) sage 2018/11/22(木) 12:46:59.97 ID:vFEoyYoC0
>>587
「ちんちん」の語源の1つの説に、
支那の娼婦が幼児語で「入れて入れて」と言った言葉を
当時の出羽守が有難がって日本に広めたという
かなり眉唾物な故事がある。
その説に依るなら「チンポかシコシコする。」は
当然のように入れた側の所感とその転用じゃな。
591 名無し三等兵 (ｽｯｯﾌﾟ Sd1f-hEn1) sage 2018/11/22(木) 12:26:55.61 ID:9IvK1JXqd
>>587
シコシコするは他動詞なので、所有者の意思とは無関係にチンポが自立行動するのであれば「イライラする」「ムラムラする」という自動詞を用いるのが正しい
644 名無し三等兵 (ｱｳｱｳｶｰ Sa87-dVyK) sage 2018/11/22(木) 13:18:34.11 ID:UNLN7beIa
>>587
「胸がドキドキする」
胸は心臓の意味で、行為者として心臓が使われているので｢心臓が拍動する｣は日本語としておかしくない。
「チンポがシコシコする」
チンポはそのままの意味で、受け手側としてチンポが使われているので｢チンポはシコシコされる｣又は｢チンポをシコシコする｣が正しい。(50字) >>1
そのとおりじゃ！
というか、おれはオブジェクト指向のC++が現れてすぐに
クソだウンコだと言ってきた。
オブジェクト指向が素晴らしい？はあ？何言ってんの馬鹿なの？
オブジェクト指向の特徴は、カプセル化と継承じゃ！
そんなもの他の言語ではもっと簡単な方法で実現してる！
それが理解できないバカはさっさと死ね！ >>146
＞オブジェクト指向が素晴らしい？はあ？何言ってんの馬鹿なの？
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 特定の言語の話なんか誰もしてないのに本当に馬鹿だな
指向とそれを言語仕様に組み込むかどうかは別の話なのに本当に馬鹿だな 無理やりOOPしなくていいと思うよ、ソフトが見やすくメンテしやすい事か重要なんだから。
無理しても余計へんちくりんなコードになるしね、ただちゃんと設計されたOOPはマジでわかりやすいので勉強はした方がいいと思う
OOP否定派はどうせ手続き型でもまともに設計できない。出来るのは自分流の設計だけ、自分では気づかないけどめちゃくちゃわかりにくいコードだよ、それ オブジェクト指向で良い設計ができるのっていつ？ってことと、
もし筋の悪い設計だったとき、オブジェクト指向で作ってれば変更が楽なの？って観点が欲しい 手続き型(imperative)の対立用語は宣言型(decrative)
ずーっとOOPの対立概念として手続き型を使ってる低脳クソ間抜けがいるな。
C++もJavaも今のメインストリームは大体オブジェクト指向“かつ”手続き型。
分かったかクソ間抜けｗｗｗ>>150 まあ宣言するだけで、低レイヤーではしこしこ手続き書くんだけどな Javaは中途半端。プリミティブとオブジェクトを無駄に分けるし、後からジェネリクス入れたせいでダサいライブラリが残存してる
何よりもユーザーが作れるもの全てがオブジェクトになるんで「ここだけオブジェクト指向の考えを入れよう」っていうアプローチがとれない > 何よりもユーザーが作れるもの全てがオブジェクトになるんで
それのどこが中途半端？原理主義だというなら分からんでもないが… 155じゃないけど
原理主義はどっちかって言うと
smalltalk
とかなんじゃないだろうか?
javaは全部がオブシェクトじゃなくて
プリミティブ型
が混じっているから
中途半端
と判断しているのではないかな?
javaは所謂手続き型的に書きにくい(書けない?)
クラスを作ってオブジェクト指向しないといけないのに
オブジェクトじゃないプリミティブ型が混じっているから中途半端見えるのでは?
javaは登場当初の時期が古い頃でもあるから
処理性能的にプリミティブ型が必要だったのかも?
c++は手続き型的に書ける感じだけど
javaはそういうのがし難い印象
だからstaticおじさんとかが登場したとかじゃないのかなぁ?
良く知らないけど >>158
> 何よりもユーザーが作れるもの全てがオブジェクトになるんで「ここだけオブジェクト指向の考えを入れよう」っていうアプローチがとれない
と言っているのにその擁護はおかしい。 >>159
ユーザーがプリミティブ型を作れると思ってる？ >>160
分かった。けど>>155の文章力はちょっと酷すぎないか… >>153
OOPも元は宣言的を目指してるし、smalltalkや最近の関数型機能も取り込んだOOPな言語もある程度宣言的なんだよね。
じゃあ宣言的ってなんぞやってなるんだけど、HaskellもPrologも結局ループを再帰とかmapとかfoldlとかに置き換えて、if/switch文がガードやパターンマッチになっただけって言う。
(実際、Haskellのパターンマッチはcase(C言語系のswitch)の構文糖衣)
OOPもそう言う制御構造をメソッドに押し込んじゃえって感じだけど(少なくともmainとかの中身は宣言的に書きやすい)、メソッドの中身は相変わらず手続き的と言う。
(この辺、最近の言語だとクロージャ(ラムダ式含む)やらLinqやらで比較的、制御構造を隠蔽し易くなってると思う。あとはif/switch文だけだ。がんばれ！)
でも逆にそう言う目で見ると、関数型言語も手続き型言語も大差無い。
(関数型言語も事実上の再代入は可能だし)
強いて言えば関数型言語の方が関数に分割し易かったり、ガードやパターンマッチで分岐のネストが減る分、見やすいってだけ。
(どっちかと言えばアルゴリズムと相性が良いリストが基本か、効率重視の配列が基本かの違いの方が大きいので、リスト使う限り文法以上の違いは感じない)
GoとRust入門サイト読んでみたけど、どっちもOOPじゃ無いんだね。
Go=手続き型言語に最近トレンドの機能入れました。(ただしOOPは除く)
Rust=手続き型言語でも関数プログラミングな書き方出来ますが、関数型言語は言語レベルでサポートしてますー>なら、手続き型言語でも言語レベルで関数プログラミングをサポートしようじゃ無いか。
Goは依存関係に苦しんでた結果生まれたとか(dllとか基本的に作らない方針)、OOPへの問題提起な印象。
RustはOCamlとかSMLで良くね？と思ったけど、関数型言語のままだと普及しないから、手続き型言語に寄せました的な印象。 OOPのすべてを表現できるOOPLが無いから
こうなるんだよ。たぶん不可能だし、その場しのぎ
で作って、文法ごと捨ててしまうのが正しい。 死んだのはJavaだけやろ
そらインタプリタやらサブセットやら自由な実装を認めないし
フレームワークをゴミ箱に捨て続けるようでは
そらうんざりだわ くそはJavaだから、限定すると
Cとかと結合出来にくいから、ダメなんよ
逆に呼ぶのもメンドイし、バインディングが
最大の欠点よ。自分の殻に閉じ籠って
独自の世界観作っちゃってるのよ。 >>162
ちゃうぞ、パターンマッチはオーバーロードの機能もあるから >>170
OOPとの比較だとそうだけど、if/switchは手続き的と宣言的(OOP含む)の比較だから。 >>169
その言い方だと、他の言語はC言語と結合できやすいといってるように思えるけど、
ソースレベルで結合できるC/C++以外で、
C言語は他の言語と結合できるの？
くそなのはむしろC言語では？ Hello World!!
ello World!!
llo World!!
lo World!!
o World!!
World!!
World!!
orld!!
rld!!
ld!!
d!!
!!
!
を無限に繰り返すプログラムをCで宣言的？に書いてみた。 #include <stdio.h>
#include <string.h>
void hello(char[],int);
int main()
{
char s[] = "Hello World!! ";
int sl = strlen(s);
while(1) for(int i = 0; i < sl; i++) hello(s,i);
return 0;
}
void hello(char str[], int i)
{
puts(&str[i]);
for(int j = 0; j < 50000; j++){}
} こっちはHaskell
main = do
mapM_ (\_ -> hello str) [1..]
hello [] = return ()
hello (s:ss) = do
putStrLn (s:ss)
mapM_ (\_ -> putStr "") [1..50000]
hello ss
str = "Hello World!! " こっちはシェルスクリプト
#!/bin/sh
while :; do
s="Hello World!!"
while [ "$s" ]; do
echo "$s"
s=${s#?}
done
done シェルスクリプト版改良
#!/bin/sh
while [ "${s:=Hello World!!}" ]; do
echo "$s"
s=${s#?}
done do-doneが宣言的じゃ無いぬ(´-ω-`)
Cのはwhileやforが一つの文か式は{}を省略できるから宣言的であって。。。
てか、OOPどうした。 てか、手続きやOOPの本当に厄介なのはポインタとか参照とか使う場面なんで、これは良い例であってだな。。。
しかし、手続き型言語の良い点もまたそこを効率的に使える点なんだよね。。。
(安全性とトレードオフ) 正直どうせフォンノイマン型計算機なんだから手続きベースでいいじゃんっていう気もする
そんなことより問題領域を表現するデータ構造（演算の定義域）をきちんと構造化してですね...
いわゆる巷で言われるOOPだと、何というか分散処理の匂いがしてあまり好みではない
OS上のプロセス自体を巨大なFSMとして見ることができて、そのモデルはかなり役に立つけど、どうしてその実装までそのモデルを強いられるんだ、という
別にメモリ上の構造化されたデータ群に対して演算を加えていく形式でもいいじゃんっていう
そっちの方が順序回路っぽいし
ミクロの視点かマクロの視点か、という違いな気もするけど > Cのはwhileやforが一つの文か式は{}を省略できるから宣言的
> Cのはwhileやforが一つの文か式は{}を省略できるから宣言的
> Cのはwhileやforが一つの文か式は{}を省略できるから宣言的
> Cのはwhileやforが一つの文か式は{}を省略できるから宣言的
なんでバカは知ったかが他人にバレないと思い込むんだろう？
浮気男が「自分がこんなに楽しんでいるのだから妻も同じようなことをしてるに違いない」と決めつけるように、
「自分がよく分からないのだから適当なこと言っても他人も分からないに違いない（からイキっておこう）」という精神なのだろうか。 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) >>173 GNU Smalltalk
| str |
str := 'Hello World!!'.
0 to: FloatD infinity do: [:idx | (str allButFirst: idx \\ (str size + 1)) displayNl]
https://ideone.com/4QgJwe ■ このスレッドは過去ログ倉庫に格納されています
