オブジェクト指向ってクソじゃねぇかよPart4
レス数が1000を超えています。これ以上書き込みはできません。
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：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/
前スレ
オブジェクト指向ってクソじゃねぇかよPart3
https://mevius.5ch.net/test/read.cgi/tech/1542884872/ だから言ったじゃん
ピュアオーディオとか純喫茶とか純文学の話になってるだろ
それに連なる『純オブジェクト指向』だ
ここで純オブジェクト指向と目されるSmalltalkを持ち出してピュア談義してるだけだ
オブジェクト指向≒Javaと見做されてる昨今では「Javaはクソ」≒「オブジェクト指向はクソ」となるのが普通だ
そこにわざわざ純オブジェクト指向なる概念を持ち出すから話がややこしくなる
平たく言うと、Javaの開発案件がたちまちクソの山になるのはそれがオブジェクト指向だから、っていう話だ
それも、数値にしがたい負の感情を産み出す母体になってる
オブジェクト指向にメリットはなく、代わりに数値化できないデメリットが業界で拡大再生産されてる
その根幹原因がJava≒オブジェクト指向にある
クソなんだからメリットが生産されるわけじゃない
デメリットが生産されてんだよ
「現状のオブジェクト指向が上手く行かないのは、それが純オブジェクト指向じゃないから」
それを延々話してるんだよ
その「純オブジェクト指向」なる状態が、あり得ないものか、未だに存在してないものか、そもそも存在出来ないものかは知らないが、
現状の実態たるJavaの話から乖離して、延々と架空の話を続けてるだけだろ
現実を見たくないからわざわざSmalltalkなんて引っ張り出して来てるんだよ
それだけクソってことだろ 【訃報】プログラミング言語「Erlang」を生んだジョー・アームストロング氏死去
https://gigazine.net/news/20190422-joe-armstrong-passed-away/
> 関数型プログラミング言語「Erlang」の生みの親として知られるコンピューター科学者・プログラマーのジョー・アームストロング(ジョセフ・レスリー・アームストロング)氏が2019年4月20日(土)に亡くなったことがわかりました。68歳でした。
RIP Joe Armstrong, the author of Erlang
https://freethoughtblogs.com/kriswager/2019/04/20/rip-joe-armstrong-the-author-of-erlang/
なお、アームストロング氏は「なぜオブジェクト指向はクソなのか」という名文を残しています。
Why OO Sucks
http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
訳文がいくつか存在するので参考にしてください。
連続体仮説: なぜオブジェクト指向はクソなのか by Joe Armstrong - 勝手に翻訳
http://chypot.blogspot.com/2012/08/by-joe-armstrong.html
オブジェクト指向はクソか？ - tokoma1's blog
http://tokoma1.hatenablog.com/entry/2015/06/07/083347
Why OO Sucks by Joe Armstrong · GitHub
https://gist.github.com/posaunehm/4087971 「モノ、コンテキスト、役割」の関係は、「モノ、照明、影」で例えられます。
モノに照明を当てると、影が出来上がります。影は、照明を当てる角度により形が異なります。
つまり、照明＝コンテキスト、影＝役割とすると、
仕事コンテキストでは従業員
家庭コンテキストではお父さん
趣味コンテキストではゲーム制作者
https://qiita.com/MinoDriven/items/2a378a09638e234d8614
＞ものではなく役割を中心に分析した方がいいよって話
＞ペンギンでいうと捕食者とも取れるし被食者とも取れるし
＞料理の材料とも取れるし動物園の鑑賞動物とも取れるし
なるほどね！ >>1
オブジェクト指向が良いって
言ってるの低知能の馬鹿だから。
相手にすることさえ汚れる行為なのだから
無視するだけで良い ところでだ。「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！ オブジェクト指向がうんぬんという話はわかるが、
それ以前に、オブジェクト指向しか選択肢がないっていうのが現状
選択肢っていうのは言語があるとかないとかじゃなくて
何かのアプリやシステムをつくる環境レベルのものまで整っているという意味での選択肢 >>9
頭がズキズキするは
主語 + 副詞
で主語がどういう状態かを表す
チンボがシコシコするは
主語 + 動詞
で主語が何をするかを表す
シコシコするは自慰することを表す動詞で
自慰は生物が自らの生殖器官を弄ることによって
快感を得る行為のためその主語に生殖器官を置くことはできない
よってチンボがシコシコするはダメである 部屋の壁面に溢れんばかりのアダルトビデオに、腰の位置ほども積み重なったエロ雑誌の切り抜き――。
かつては大手自動車メーカーに勤めていたという神奈川県の50代の男性は、このエロ雑誌の切り抜きに埋もれ、
腐乱した状態で息絶えていた。死因は心筋梗塞。死後1か月以上が経過していた。
「孤独死とひと言で言っても、亡くなられた方のお部屋にはいろんなパターンはあるんです。
男性の一人暮らしの方は、このように自分の世界観に浸っている場合が多いんです。
2DKのマンションだったのですが、アダルト雑誌だけでも6t分もあったんですよ」
そう淡々と語るのは、特殊清掃・遺品整理業のマインドカンパニーの鷹田了氏。孤独死する人は、
何らかの趣味や性癖に傾倒しているオタク系が多いそうで、大量のアイドルグッズが溢れた部屋に驚くことも。
「故人の恥部にならないよう、部屋の大人のおもちゃなどは、遺族に存在が知れないように処分するように心がけています」（鷹田氏）
https://nikkan-spa.jp/1294401 👀
Rock54: Caution(BBR-MD5:847cfeaf6f31691a42c25abc56bd4433) >>1
そのとおり。
Javaは工数が増えるから
客から金をふんだくれる。
客が改修できないから
再び発注しなければならない。
よってソフト業界が潤う。
低辺プログラマが
デスマで死んでも関係ないね。
俺が儲かればいい。
ジャッププログラマが死んで
俺が儲かる言語。
それはJava！ オブジェクト指向批判してるのはオブジェクト指向を理解できないバカだと明らかになったことが
悔しいからって糞スレ立てんな 前スレの最後に捨てゼリフはいててワロタ
デメリットが一切ないやり方なんてないだろう
チンポみたいに鳥ができることを全て詰め込んだクラス作ってそう >>17
チンポみたいに鳥ができたら面白いだろう？ オブジェクト指向批判してるのはオブジェクト指向を理解できないバカが怒りの連投して発狂しててワロタ
「んで、オブジェクト指向が解決した問題をオブジェクト指向を使わずにどうやって解決するんだ？」
これから逃げ回ってばかりで発狂かよｗｗｗｗｗｗｗｗｗ >>19
その回答がないのってオブジェクト指向が解決した問題が
提示されてなくて曖昧だから質問の意味が伝わらないから
だと思うよ >>20
オブジェクト指向が解決した問題を知らない時点で
まともに議論できる知見がなしに批判してるだけのバカだというのは明らかなんだが オブジェクト指向プログラミングに疎い奴が開発したプログラムってオブジェクト指向の利点を生かせてないことが多いよな
名前空間の延長としてしか使ってなくて似たようなクラスと実装が大量にあった時は殺意を覚えた >>17
お前は神クラス作って使えねえと文句言ってるだけかもね。
まあそこまで言うなら、前スレに貼ってあったものだけどお前ならどう設計するんだ？
https://qiita.com/MinoDriven/items/2a378a09638e234d8614 >>21
質問が曖昧すぎて答えられないのを良いことに
偉そうに振る舞ってるだけじゃん
それで答えられない人をバカだとは思わないし
君のことをバカだと思うよ
こういう問題があってオブジェクト指向は
こういうふうに解決したんだけれども
他のパラダイムではどのように解決できるだろうか
みたいに質問を具体化しないと
この質問者はそういう分析のできない木偶の坊かな？って思うよ
主婦を代表して言わせてもらうけど 回答が付きやすい的確な質問をできるというのもエンジニアとしての素養の一つだと思うけどね 分からないことは分からないと言うだけでいいだろ
回答は付かなくてもいい
回答が付かないとダメと思ってるやつは
回答が付くまで同じ質問を書き込み続けるモンスターになりかねない >>24
また出たよ…
オブジェクト指向のまともな本だったら
目的が書かれていることすら知らないバカ >>25
翻訳「バカのレベルに合わせろ」
お前は俺に一円も払ってないし、
俺はお前の母親じゃねえぞ >>23
この設計はどうかと思うが…。
受取人、支払者、購入者が同じだったとして
例えば住所を変更したときの処理が不自然になる。 >>29
じゃあ具体的にどう設計すれば良いの？
本読んでオブジェクト指向をマスターしたのなら
そこまで具体的に教えてください >>31
当然関連性を明確にしろということだが。
言われないでも分かるだろ。
設計の欠点を指摘されて逆切れはみっともねえぞ。
「不自然」じゃなくて
「この箇所がこういう理由で不自然」と具体的に明確に指摘してるんだから。
っつうか、お前宛のレスじゃないのにしゃしゃり出て来るな。
馬鹿と話しても時間の無駄。 もうそろそろオブジェクト指向を使わないで
やってみたやつ出てきた？
無理っしょ？ >>34
だから具体的にどう設計するのかを言えよ
不自然だと言ってるだけじゃないか
こう設計するのがベターとUMLで示せる？ ID:XdsvjhCGが言ってるのは、あなたは良い人と巡り合い自分を見つめ直すことで
より良い人間関係を築いて行けるでしょうと言ってる占いババアと変わらない
でっかい水晶見せて雰囲気で誤魔化してるだけ
オブジェクト指向は曖昧な言葉を駆使して顧客を煙に巻き金を巻き上げて
本を売る悪質な商売だとこのスレを見る人はお前のレスを見てそう思うわけ
お前が本を読んで学んだオブジェクト指向の知識、技術を駆使して
具体的な設計を示してオブジェクト指向はこんなに素晴らしいものだということを証明して欲しい ちなみに僕なら住所が変わることは気にならない
なぜならクラスが別れてるだけで元となるデータは同じかもしれないからね
購入者の住所を変更して保存したら受取人の住所も変更されるように
データをもっておけばよいだけだからね
オブジェクトと永続化されるデータは異なるものだからね ならオブジェクト指向を使わなくても素晴らしい設計ってのも示す必要があるのでは？
お互いに出し合ってどちらがより優れているか決めればいい
批判するだけならいくらでもできるわけだし >>36
お前と話しても俺が得るものが何もないからさあ >>37
なんでもいいよ。
オブジェクト指向ならこう書く所を
別の何かならこう書けるからすごい！
オブジェクト指向より優れてる！って結論を出してくれればいい >>40
賛成
言葉の応酬を繰り返すよりよっぽど建設的 >>41
問題の具体化が必要かな
処理が不自然になるという問題認識が曖昧なので
解決策もふんわりした占いババアになる
不自然な処理とはこういう処理のことで
これは凝集性が損なわれるからあるいは密結合にならざるを得ないから
結果的にシステムとしてのロバストネスが失われる
スケーラビリティが低いメンテナビリティがやばいというところまで
掘り下げないと解決策も具体的には考えられないよ
お前いまのままだとふんわりババアで人生終えることになるよ？
それで言いわけ？ お前のお母さんもお前にふんわりババアになって欲しいと
思ってお腹を痛めて産んだわけじゃないだろ、この親不孝者が！ >>40
>>43
よしよし、それではまずは君たちの設計書を見せてもらおうか >>45
まずは。じゃなくて同時進行でお前もやれやｗ >>47
僕はペンディングということで
すでに賛成されたお二人から設計書をご提示いただければと思いますよ >>48
だめだろ。逃げるなや。
そうやってオブジェクト指向に対抗できる何かが
あるって示せないからダメなんやで >>41 オブジェクト指向を使わなくても素晴らしい設計ってのも示す必要があるんだ！
>>43 そうだそうだそれが建設的だ！
僕、じゃあお願いします！ オブジェクト指向を使わなくても素晴らしい設計ってのも示す必要のは当然だけど
それが示せないから、やっぱりオブジェクト指向じゃなきゃだめなんだよな 自分ができないことをまず相手に要求するってのはダメだよな
だからお互いに出し合って決着つけろと言ってるんだけど
まずお前が出せじゃ話にならんでしょ
明日のこの時間にお互いに出すってことでいいんじゃない？
出せなかったら負けってことで
では両者頑張ってｗ >>53
君がそうするべきだと思ってるんだよね
じゃあ君がやったら良いじゃないか
どうして君はやらないんだい？
君がやらないから僕らもやれないんだよ
全部君のせい、君が悪い 僕は君のようになんでもかんでも他人のせいにする人が大嫌いだ ID:XdsvjhCGと僕の共同声明として僕が代表して発表させてもらうけど
ID:DWIECac3よ、お前がやれ >>54
だって俺が始めた言い争いじゃないしな
言い訳はいいから逃げずに頑張って
明日楽しみにしとくわｗ >>51
え？どこをどう読めば俺がオブジェクト指向がいらないと主張してることになるんだ？
こういうバカだから相手するのが面倒。
レスすんなよ。お前に教える気はないから。 >>58
アンカーを間違えた、そこはすまなかったが、君も僕に謝ってほしい
紛らわしいレス番号で投稿してて申し訳ないの一言が欲しい >>53
いや、オブジェクト指向の場合はすでに何度も出てるから >>57
そんなことはない逃げてるのは君だよ
いいかい、>>40で君が、間違いなく君が設計をだすべきだと
いう高尚なお考えをお示しになったわけだよ
君が>>40で言い出したことだ、君が当事者であり発起人であり被告人なんだよ
それを自覚して頂いて言い出しっぺなんだから設計書出してもらえますね？ >>60
どれよ？ どれがオブジェクト指向の設計よ？ >>60
ならそれを改めて出してくれたらいいよ
オブジェクト指向じゃない場合の素晴らしい設計ってのが出てこなかったらそちらの勝ちってことよいし >>63
じゃあお前がオブジェクト指向じゃない場合の素晴らしい設計だせよな もしかして前スレで拙者が徳川吉宗～とか言って笑いを提供してくれた奴？w >>63
例えばコレだな。これに対する反論は「その設計はだめだろー」っていうのはダメ
これをオブジェクト指向以外で、もっといいやり方をするってのが主題だから。
23 名前：デフォルトの名無しさん[sage] 投稿日：2019/04/29(月) 15:36:05.83 ID:YPlfmP4Z
>>17
お前は神クラス作って使えねえと文句言ってるだけかもね。
まあそこまで言うなら、前スレに貼ってあったものだけどお前ならどう設計するんだ？
https://qiita.com/MinoDriven/items/2a378a09638e234d8614 設計って勝ち負けじゃないと思う
君たちのその争いに意味はあるんだろうか
争って荒野にして汚染された不毛の土地でおいしいじゃがいもが育つとは
僕は思えない、僕らはおいしいじゃがいもが食べたくてここにいるんじゃないのか？
君たちには一旦冷静になってほしい そもそもOOPと何を比較してんの？
・OOP（OOPLで例えばクラス、カプセル化、クラスライブラリを使う？）
・非OOP（OOPLでOOP機能とクラスライブラリをいっさい使わない？
手続き型言語で書く？ 関数型言語？ 宣言型言語？ 論理型言語？）
OOPがクソっていう人は何を使って幸せになってんの？ >>66
これってモデリングの話だから
関数型言語でも同じデータモデル作ればいいだけのような >>64
なんで俺が出すんだよｗ
オブジェクト指向を否定してグダグダ言ってる連中が出せばいいんだよ
無理ってんならオブジェクト指向は素晴らしいものだって結論が出るわけだし >>69
うん。だからそれをオブジェクト指向以外でやらないから
オブジェクト指向しか選択しないですよねって結論になってる >>71
やらないっていうのは誰が？君が？
関数型でプログラムを書く人が少ないって話？
マクドナルドのハンバーガーを食べてる人が多いから
マクドナルドのハンバーガーは世界一おいしいのだ理論の応用かな、なるほどね >>70
オブジェクト指向を否定してる人なんて君くらいしかいないだろ
で、オブジェクト指向の否定云々とは全く関係なく君がやればいいだろ
なんでやらないんだ 人それぞれ好き嫌いはあると思うよ
でもそういった感情とは別に技術的なことに目を向けることができるから
僕らはエンジニアだと思うんだよね
オブジェクト指向がすばらしいと思ってる人もいる
オブジェクト指向は大したものじゃないと思ってる人もいる
オブジェクト指向に旦那を殺されて3年が経ちましたと言ってる欲求不満な未亡人もいる
でも技術ってそういうの関係ないじゃん まったく不毛な争いをしてるなｗ
世の中にはオブジェクト指向に向いたものもあればそうじゃないものもあるし
それに合わせて設計するだけのことなのに何を争う必要がある？ >>73
> マクドナルドのハンバーガーは世界一おいしいのだ理論の応用かな、なるほどね
それとは違うよ。マクドナルドのハンバーガーは世界一おいしいわけじゃない！
と主張している人が、他のハンバーガーを出さない理論
他のハンバーガーを出さない理論 ないよオブジェクト指向に向いたものなんて。
労働需要創出のための詭弁だってC++の作者自身が白状してたじゃん。 >>78
ハンバーガーはいま関係ないでしょうが！！ >>80
俺に言うなや
今の話は、オブジェクト指向以外が優れてると主張している人が
他のやり方を出さない理論 シラフで書いてんのなら深刻なユーモア不足だから
レスの回数と文字列の長さを半分以下に調整してね
誰とは言わないがおとなしく自覚してほしい >>79
そりはオブジェクト指向がダメなんじゃなくてC++がダメなんじゃ・・・
C++がダメと言ってもWindowsのソースコードはC++だし
KDEのソースコードもC++
戦闘機のF-35のソースコードもC++
そんなにダメではなさそうだけど >>83
やっぱり、ダメダメでしか語れないのか
オブジェクト指向以外の○○が優れてるって
例は出せないのな >>82
僕に言え
アンカーつけて堂々と僕に言え
コソコソと隠れながら自己主張しようとするなこの卑怯者
ぶち殺すぞ >>84
君に向けた発言ではないし
その例を出そうとしたわけではないので
申し訳ないけれども黙ってろぶち殺すぞ オブジェクト指向以外の○○が優れてるって
例は出せないのな ガッテン、ガッテン、ガッテンｗｗｗｗｗ
一人ガッテンｗｗｗｗｗこれ一人焼き肉に続いてブーム来るんじゃねｗｗｗｗｗ >>87
そこで元気良く「それこそが関数型や！！」という意見が出ればね
そういう展開にでもなれば、このスレも見応えが出てくるんだけど
OOPを置き換える何かを主張する人が出るまで待機中 否定してる奴にならもっと素晴らしいものとやらを出せと言ったら
先にお前が出せとか意味不明な反論してくる状況だろ
どうしようもないやんｗ >>91
どう考えても僕のことを言っておられるんだと思いましたけど
僕はオブジェクト指向を否定してないですよ
そこのところはわかっておいていただいて
それはそれとしてオブジェクト指向を否定する人しかオブジェクト指向以外の
例を出しちゃいけないルールはないと思うんですよ
オブジェクト指向が大事だと思ってる人の中にも関数型プログラミングを
嗜んでいる人もいるでしょうし
技術ってそういうものですよね個人的な好き嫌い社会的な軽重とは独立してます
心が伴ったらそれはもう宗教なので技術とは違ってくるかと
宗教によって戦争が起きるのは心の存在があるからなんでしょうね 我ながら良いこと言ってるわー
君たち今頃しんみりしてるでしょう
心に沁み入ったでしょう >>79
それはいわゆるネタですよ…
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html こういう事例ではオブジェクト指向より関数型のほうがいいって具体例を出してあげればいいやん
それを拒否する理由なんて無いと思うけどな >>95
それを出せば良いと君が思ってるなら
君が出すべきかと
僕は関数型プログラミングはエアプなので無理ですけど >>97
そうやって拒否するってことはつまりそういうことやな 理由なんて無くても自由があるから拒否はできる
自由とはつまり人間やルールが疎結合になっている状態 >>98
そういうことの意味がわかんないんだけど
僕は具体例を出してあげれば良いとは言ってないですよ
それを言ったのは君ですよ、君が主張したことです
どうして僕が拒否したことになってるのかわかりません
僕に責任をなすりつけるのやめて欲しいです不愉快です
君が主張したことなんだから君がやるべきだと思います 道具を使いこなせないからって、悪く言う必要は無いんだぞ。 ID:PGFlN+PIはなんら具体的なことは言えないけど否定はしたいってことらしいな
それじゃ宙に浮いた話に終始されて議論にもならんから終わりやな >>103
なにの否定なのかな？
本当に意味がわからない
火事の例で言うと僕は火事は江戸の華だと思ってるから
消防車を呼ばなくて良いと思ってる
君は消防車を呼ぶべきだと思ってる
だけれども消防車を呼ばずに僕にどうして消防車を呼ばないんだと言っている
そういう状況なんですよ 拙者は徳川吉宗君のお相手を慈悲でしてあげてるなんてことなら皆優しすぎて涙が出るよw 拙者は徳川吉宗君は感謝して頭を垂れるべきだねw
僕に生きる糧を与えくれてありがとうってねw >>95 こういう事例ではオブジェクト指向より関数型のほうがいいって具体例を出してあげればいいやん
ID:nTNh+kbPはこう主張したんですよ
具体例を出してあげれば良いと言ったんです
自分ではっきりとこう言ったんです
だから僕はID:nTNh+kbPがその具体例を出すんだろうなくらいに思ってたんです
ところがID:nTNh+kbPはなんで具体例を出さないんだと僕に文句言ってくるんです
僕は具体例を出してあげれば良いとは一言も言ってないただの通りすがりの一般人なのにです
ID:nTNh+kbPは自分が言った言葉の責任を何の関わりもない僕になすりつけようとしてるんです
これではあまりに僕がかわいそうです、通り魔にあった気分です
>>95の文体をよくみてください、関西弁です
関西弁は関西人が使う言葉です
関西人は通り魔です 拙者は徳川吉宗君は寂しいんだねw
皆に相手してほしいから頑張ってるんだねw
でも相手してくれる人はもういないようだよ？w 拙者は徳川吉宗君は皆に匙投げられちゃったんだw
かわいそうな拙者は徳川吉宗君w そして俺も匙投げちゃおうw
さようなら拙者は徳川吉宗君w >>95はこうも言ってます、それを拒否する理由なんて無い
>>95には拒否する理由なんて無いんです
自分で言ってるんだから間違いありません
ここまで言っておきながら>>95はまだ具体例を出していません
僕に責任をなすりつけようとした謝罪の言葉もありません
みなさんこれが関西人のやり方ですよ 関西人バカすぎワロスｗｗｗｗｗｗｗｗｗｗｗ
消防車漫画を再現しすぎだろｗｗｗｗｗｗｗｗ 威勢の良いこと言って僕に頼るなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗすまんなｗｗｗｗｗ僕は何もできないｗｗｗｗｗｗｗｗｗｗｗ
僕のことはオブジェと思ってくれｗｗｗｗｗｗこれが僕のオブジェクト指向だってかｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗ大爆笑ｗｗｗｗｗｗｗｗｗｗｗｗ でもやっぱ関西人は笑いの才能はすごいよね
わざと消防車漫画を再現してみせたんじゃないかと
僕は疑っててそれが本当なら関西人はあなどれない 消防車を呼ぶべきだ
それを拒否する理由なんてないと高らかに宣言して
消防車呼ばないんだもん
僕は街で関西人を見かけたら子供に見てごらん
消防車おじさんだよと教えることにするよ 上の例なら、複合型のクラス1つで何とかしようとする良くあるオブジェクト指向以外なら、
何で書いても大差ないでしょに、ﾊｰﾄ。 『オブジェクト指向』などという専門用語を使わずに、それらしい概念を語ってみないか？
例えば『ビッグデータ』というのは、図書館に本が沢山有るよみたいな。 では、手段指向なんてどうよ。
目的は、ない、やり方を探求する指向、とか。 >>11
＞シコシコするは自慰することを表す動詞で
『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↓ ↓ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/j3uTk1K.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 んまぁ、たくましい…
筆卸がまだならオバちゃんに言ってねﾊｰﾄ >>66
その際との例ならclosure使うのがイチバン楽そうだな オブジェクト指向はX Window Systemをシンプルで整然とした生産性高いモノにできたかどうか
考えてみるといいんじゃないかなぁ Motifの時代はひどかったな
いまだと、GTK, QT, wxWidget, fktk, tkx ｲﾛｲﾛあるけど当時より進化した
ただし、X固有のものではない。
オブジェクト指向ウンヌンではなく、純粋に進化した。
ゆっくりとだが。
SWING見るとオブジェクト指向といってもどうなんだろうと首を傾げたくなるが…
でもそれよりnodeのうえのElectronのような方向の進化のほうが面白いしなんだか革新的だ Xは文字通りの意味でネットにメッセージ送信してる
Erlangもな 送ってねーってｗ
UNIX domain socketしらねーのかよ
それにメッセージ パッシングとクラスペースオブジェクト指向は別物だし
申そう猛々しぞ とまあこんな感じで揚げ足を取られる問題をどうやって解決するか >>130
揚げ足取りというなら、X Window Systemと
メッセージ パッシングオブジェクト指向
の関連性を示してみろよ ここまでオブジェクト指向を使わないメリット一切なし Cは馬鹿が使うとぐちゃぐちゃになる。
馬鹿にはオブジェクト指向言語がおススメ。 オブジェクト指向のメリットは
馬鹿でも使えること。 c言語でもオブジェクト指向できますし
高級言語だと色々面倒見てくれて楽チンだよと言ってくんろ。オブジェクト指向で書く必要はないし >>138
C言語にものすごく詳しいけどオブジェクト指向には興味ない奴
に邪魔されるからC言語でオブジェクト指向はできない
っていう問題意識があるみたいなんだよ 学習用プログラミングはC/C++あるのみ。
オブジェクト指向についてはオブジェクト指向プログラミングをせずとも、俺の股間に付いているのだから！ そのｴﾉｷﾀｹみたいなちんけな物がオブジェクト指向だったのか、
道理で役に立たないわけだわ、納得。
はい解散解散。 >>138
C にできることをわざわざオブジェクトオリエンティド、とはいわないと思いますよ
たとえば継承は C で書けますか？書いてみてください https://ideone.com >>143
それがでてきませんね…
URL 例を挙げてみてください ググればすぐに出てくるやん
これとか
ttps://qiita.com/qiita_kuru/items/8f3441bce9b2f53d1d62 >>145
これは継承というより委譲という気がしました…この方法では、基底クラスA, とそのメソッド f() ・A の派生クラスB において B.f() が何のてらいもなく実行できることを説明できていないのではありませんか？
私は C で継承を記述するのは不可能だと思います >>147
>>146 で示した懸念を >>147 の本はどう回避しているのですか？ >>148
お前のような人に調べさせるくれくれ君に教えることは何もない >>149
あなたこそフェイクニュースを振りまく毒人ではないのでしょうか？
私の立場は「C で委譲と区別することのできる継承は実装できない」です
C がなんでもできる、とか勘違いもはなはだしいので、叩けるときに叩いておこうと思っています もはや継承できることを誇るのはGOTOが書けることを誇るのに等しい >>152
>>147 を見て発注したばかりで、まださすがに届きませんので、概要くらいは知りたいと思ったのですが、ID:IpLGLbh6 は、どうも具体的な話ができない人のようですね >>153
ググって何も出てこないなんて嘘をつくお前がよく言うねw
フェイクニュースだの毒人だの酷い奴だ。
お前それ本の著者にも言えるのか？
本の内容は書かないよ。お金払って読んでくれ。 >>153
自分の考えにあってるか判断するのは読んでからでも遅くないと思うし
議論って相手を叩いたら成立しないと思うんよね
具体的な話ができない人だっていうのは人に対する文句だから
そういう事言うとなおさらかなと
自らの見識を広げられると良いよねっていうのが議論だから
反論することよりも理解することを重視したが良いと思うの 自分の考えと違うことを言ってるから叩くんだじゃなくて
自分と違う考えを吸収するんだっていうのが技術的な議論には
必要なスタンスかなと >>154
>>146 の内容を整理します
基底クラスA とそのメソッド f() があり、かつ A の派生クラスBを導出したところで、B.f() が特に困難なく記述できますか、これを C で書く方法はありますか？ >>155-156
なるほど、確かに私の側にも狭量なところがありましたね、ご指摘感謝いたします >>138
ボブおじさんも似たようなこと言ってた
C言語はJavaより厳密にカプセル化できるよーみたいな話 できるできないの話になってる時点でダメだろ
大規模でも把握しやすいかどうかが重要なのに C++だかJavaだか忘れたが、オブジェクト指向プログラミングの本に昔アセンブリ言語で
オブジェクト指向プログラミングっぽいコード見たって記述があったな。
オブジェクト指向だろうが何だろうが、最終的に機械語になるし、アセンブリ言語は機械語と
一対一なんだから出来ない事はないんだろうが。。。
上でも言われてる通り、オブジェクト指向プログラミングはオブジェクト指向言語じゃなくても出来るが、
オブジェクト指向プログラミングをし易いのがオブジェクト指向言語な訳で。 オブジェクト指向は俺が生まれた時から俺の股間に付いている！ 一言に継承と言っても言語によってその概念もできる範囲も様々だったりするし オブジェクト指向は考え方だからなー
実現方法はいろいろあるますよねー 随意筋 不随意筋
↘ ↙
チンポ
これぞ、多重継承！ >>162
だからそれはｴﾉｷだって。早くしまえよｿﾁﾝが >>163
>>159 じゃないが継承は実現出来ると思うぞ。
superとかポインタやん？
(そう言う意味じゃ、C的には継承は変数固定の移譲ともとれる)
ただ面倒臭そう。
そこを面倒臭くなくしたのがオブジェクト指向言語でそ。 >>163
>>159 じゃないが継承は実現出来ると思うぞ。
superとかポインタやん？
(そう言う意味じゃ、C的には継承は変数固定の移譲ともとれる)
ただ面倒臭そう。
そこを面倒臭くなくしたのがオブジェクト指向言語でそ。 >>167
『多重継承』ってさ、どっちの属性なのか良くわからんっていう場合に必須だろう？
北方四島は日本領かロシア領か、光は波動なのか粒子なのかとか。 >>170
>>157 を少し改変しました。
基底クラスA, にはメソッドf() が、 基底クラスB にはメソッドg() があるものとします
今そのの両方の派生クラスである C があった場合、C.f(), Cg() を C ではどう記述するのか、具体例で示してください
https://ideone.com/vAp2Sj
すなわち、私の見解は「C では委譲と区別された継承を記述できない、したがってCはオブジェクト指向的な記述はできない―継承の記述はオブジェクト指向には不可欠であり、それができないのは致命的―」であります >>172
ポインタの配列作って、super[0]にクラスA、super[1]にクラスBとかすれば良い。
要はオブジェクト指向言語(処理系)が裏でやってる事を自前でやる訳で。
てか、Cでオブジェクト指向プログラミング出来たら何か都合が悪いん？
出来ようがオブジェクト指向プログラミングし易いのはオブジェクト指向言語なんだし、
優位性が失われるもんじゃないと思うんだが。 今更思い出した。
使った事ないけど、初期のC++は一回Cに変換するC++ー>Cのトランスレーターだったらしい。
直でコンパイル出来るようになったのは、その後。 >>172
いつからオブジェクト指向に多重継承が必須になったの？ Objective-C もプリプロセッサでCに変換してただけだったね。 >>175
＞いつからオブジェクト指向に多重継承が必須になったの？
随意筋 不随意筋
↘ ↙
チンポ >>175
痛いところを突かれました…
単一継承ならば C で書ける（かもしれない）ことを暗に認めた、と解釈ください… >>173
＞Cでオブジェクト指向プログラミング出来たら何か都合が悪いん？
私はもともと C 使い、だから C で OO をカバーできるのならウェルカムです、でも、そうじゃないと思うのはまた別の話なのです >>175
＞いつからオブジェクト指向に多重継承が必須になったの？
随意筋 不随意筋
↖ ↗
チンポ
『継承』は、子クラス➡親クラス。
多重継承を否定できないのは、この現実世界においては、状況によって相反する属性が現れるから。
特に機械翻訳においては、文脈によってコトバの属性を選択しなければならない。 不随意筋なんて無いけどな。動かし方忘れたりしてるだけで。 >>175
＞いつからオブジェクト指向に多重継承が必須になったの？
オブジェクト『気体』の状態方程式は、高校物理とそれ以外では明確に区別しなければならない！
実在気体 理想気体
↖ ↗
気体
実在気体を理想気体に近づけるためには「高温・低圧」にすることが大切である。
【高温にする理由】
高温にすると、その分気体の運動エネルギーが大きくなり、相対的に分子間力が無視で切るようになるから。
【低圧にする理由】
気体分子自体の大きさ（体積）が相対的に小さくなるから。また、容器の体積が大きくなるのに伴い
気体分子間の距離が離れ分子間力が無視できるようになるから。
https://kimika.net/rr3risouzitsuzai.html
『高校物理』なるオモチャは、シミュレーションプログラミングにさえ全く役に立たない！ 不随意筋やら気体やら語り合ってる連中がオブジェクト指向を批判してるなあ。
やっぱり、何も分かってない馬鹿が悔しくて批判してるだけかｗ これに限らず批判する対象をまともに理解してる奴なんて極少数
ほとんどの連中は自分が理解できないものは悪というだたそれだけの理由で叩いてるだけ 正直、自分の主張で一体どれだけ人より利益が出るのか数字で説明する能力が大事
それが嘘っぱちの論理だとしても
ここの奴らにはそれがない 仕様書におこした機能区分をそのまま実装に落とし込めて可読性も上がるってだけでも十二分に有用なんだけどな >>192
だったらオブジェクト単位にする意味がわからない
機能一覧から処理一覧作って処理一覧に対応するメソッド一覧があればいいだけ
余計なことするな >>193
それじゃ問題があったからオブジェクト指向が登場した訳で。
このバカはオブジェクト指向じゃない方法でもまともなシステムを開発したことないだけ。
業務で使われるような規模のシステムの開発、改修の経験がないと
オブジェクト指向を真の意味で理解することは不可能。
だから学生には無理。
そして、JAP大学の無能教授はシステム開発の経験なんてないから
JAP教授はオブジェクト指向を理解できない。
JAP大学にIT教育は無理よ。 数百万ステップあるシステムをそれで作ってみろって話だな
恐ろしいことになるぞ >>194
は？
そこの工程で問題なんて出ねぇだろ
サルかよ
要件からまともな機能一覧が出せないことが全てだろ 要件定義の段階でブロック図まで頭に浮かんで無いと、とんでもない仕様を上げてプログラマを何人も屍にするんだよな。 >>196
まともな機能一覧が出ても問題が起きるんだが。
システム開発の経験がないんだなあお前。 マジレスだとしたらこんなに痛い発言は無いぞ？
>>194
＞業務で使われるような規模のシステムの開発、改修の経験がないと
＞オブジェクト指向を真の意味で理解することは不可能。
＞だから学生には無理。
新卒来ないのね、かわいそうにw 導入事例
富士通がお客様と共に取り組む共創事例や、製品・サービス・ソリューションの事例を紹介します。
https://www.fujitsu.com/jp/about/resources/case-studies/
>>198
＞システム開発の経験がないんだなあお前。
ならお前の会社のシステム開発の具体例を紹介してみろよ？ >>198
＞システム開発の経験がないんだなあお前。
ソフトウェア開発の属人性の誤解
属人性の排除が狙うところってのは「その人しかやり方を知らないよ、秘密だよ」って作業
をなくす話で、技能的にその人しかできる人がいないって話題じゃないんだ。ソフトウェア開発の
属人性を語るときにここを勘違いしていると議論にならない。
僕は属技能性という造語を使っているけど、ある技能をもっていないと出来ない仕事というのがあって、
技能を理由に代われないというのと、仕事の内容を把握しているのがその人だけで代われないという
のを明確に区別しようよと言っているんだ。
また、その技能を持つ人を募集しても集まらない、っていうのは人材不足であってこれもまた属人性や
属技能性とは別の話題だ。さらに、その人ひとりしか技能を持った人がいないってのは
トラックナンバーの話題で、どちらかと言えばリスク管理の話題。
http://d.hatena.ne.jp/Nagise/touch/20090302/1235997646 >>198
そりゃ、まともな機能一覧じゃなかったんだろ
機能一覧さえ完璧にできていればその後の工程でミスる奴なんて
この日本にはいねぇんだよ
わかったか？サル >>190
逆に理解した途端、その価値を盲目に信じる馬鹿がかなりいて
そちらが問題になっている様子。
まあサンクコストを無駄にしたくないってのはわかるけど無理に使うのはどうかしてる。 >>198
＞システム開発の経験がないんだなあお前。
中小ソフトハウスの下請けテスター業務なんて自慢になるのか？
DQXの敗因はまともなDがいなかった事
https://egg.2ch.net/test/read.cgi/dqo/1553655304/
135 その名前は774人います (ﾜｯﾁｮｲ ab55-r4m/) sage 2019/03/30(土) 22:02:49.50 ID:s9M0K5iF0
ドラ10の敗因は、運営がFF11やり込んで自分で経験しなかった事
これに尽きる なんで、そんなに意地になって嫌ったのか
運営自身がネトゲやり込んだ経験あれば、もっとちゃんとした物が提供できたはず
コンテンツ参加するのに耐性装備に何千万使って
毎度報酬ゴミじゃ盛り上がる訳が無い
オフゲストーリーなんてオフゲでやってろ
全員初心者スタートのFF11、自分も10年見てたけど
誰一人ストーリーやりたいなんて聞いた事無い
みんなでPT組んで色んなエリア行ってワイワイ遊ぶのがネトゲ
それで報酬もらってキャラ強化、その強化キャラで遊ぶのが楽しいネトゲ
長年育てたキャラだから引退者が少なく続くのも一因としてあるでしょ 中小ソフトハウスの中小下請けテスター業務なんて何の自慢になるんだ？
>>198
＞システム開発の経験がないんだなあお前。
同じ苦労を知っている齊藤氏は、開発初期から大事にしていることが1つあった。
「一番口酸っぱく言っていたのは『属人的な開発の仕方をするな』ということですね。長いこと開発して
いけばお客さんの入れ替わりと同様に開発スタッフも変わっていくわけなので、属人的なスキルに依存
した開発をしていると、その人がいなくなったタイミングでアップデートができなくなります。
それをまたサルベージしてやりましょうというのはとてつもない作業量になります。
『ドラクエX』で100％属人的じゃない体制を作れたかというと決してそんなことはないんですけど、
意識してそれをやるようにというのは開発初期からやりました」
https://jp.ign.com/m/dragon-quest-10/28251/news/xpso2 ああ。業界から離れて10年もしたら、UMLの形式スッカリ忘れてたわぁ！
随意筋 不随意筋
↖ ↗
チンポ
『継承』は、子クラス➡親クラス！
167 デフォルトの名無しさん 2019/04/30(火) 22:15:15.20 ID:c2yp3V/O
>>166
どうでもいいがUML勉強しろよ… 特にネットワーク関連は、C/C++の一択な！！
プログラミング言語の性能差
主な言語とスループット
言語 スループット 特性 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
83 デフォルトの名無しさん 2019/04/29(月) 20:29:17.12 ID:PGFlN+PI
>>79
そりはオブジェクト指向がダメなんじゃなくてC++がダメなんじゃ・・・
C++がダメと言ってもWindowsのソースコードはC++だし
KDEのソースコードもC++
戦闘機のF-35のソースコードもC++
そんなにダメではなさそうだけど >>207
オブジェクト指向とやらは俺が生まれた時からその股間に付いているので、
『オブジェクト指向プログラミング言語』なんて要らないよ。 928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く JavaだのRubyだのといった『オブジェクト指向プログラミング言語』とやらは、
オフラインの動画を作成するには良い。
しかしながらネットワークはC/C++の一択だし、多重継承抜きでは人工知能開発はおぼつかない。 ＞Fredが電気カミソリを持っていたので
人間という生き物は、『道具』を使って何かをすることが出来る！
485 デフォルトの名無しさん 2018/03/24(土) 22:53:15.70 ID:6mZ6T11K
（第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル ＞例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
当然ながら起きているときも、チンポがシコシコする！
風呂から出て体一杯に水を浴びながら竜哉は、この時始めて英子に対する心を決めた。裸の上半身にタオルをかけ、
離れに上ると彼は障子の外から声を掛けた。
「英子さん」
部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。
その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。
●これが衝撃の「障子破り」シーンだ！ （石原慎太郎 『太陽の季節』 （新潮文庫） より）
http://www.geocities.co.jp/Bookend-Soseki/3578/2003/shoujiyaburi.htm
＞その瞬間、竜哉は体中が引き締まるような快感を感じた
チンポがシコシコする≠勃起、つまりそれはただチンポが勃起するのではなくて、
「体中が引き締まるような快感を感じた」ということなのである！！ オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
https://blog.mah-lab.com/2014/03/18/object-oriented/
チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650
＜俺＞
「 部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
＜チンポ＞
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」
まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！
【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp >>210
おトイレドメインにおいてお前はユーザーであり
チンポは排泄器官として抽象化されるべきだと思うの
排泄するという動作によって便を排出するわけであるから
お前は美少女ではない >>216
＞チンポは排泄器官として抽象化されるべきだと思うの
すると会員登録のインターフェイスは『チンポ』なのか？
ヒカリエの例でいうと、ヒカリエにも有料のブースがあります。有料で会員制の特別なトイレには…
フットマッサージャー、置くだけで端末を充電できるテーブル、女優ライトのある化粧台、酸素バー、
などなど信じられないようなものが続々とあるのです！！
https://sirabee.com/2015/02/17/18652/ >>211
オブジェクト指向プログラミングなんて要らない、オブジェクト指向なら俺の股間に付いているから！ >>218
会員登録はプライバシー保護のために、顔写真ではなくてチンポ写真で！ >>175
＞いつからオブジェクト指向に多重継承が必須になったの？
同一オブジェクトであっても、状況によって『属性』が変わる場合もあるから。
シミュレーションなんかを作った時も、現実との不一致を常に考慮しなければならない。
システムのアップデート時も、同一オブジェクトであってもその『属性』が変わってしまう。
実在気体 理想気体
↖ ↗
気体
随意筋 不随意筋
↖ ↗
チンポ
波動 粒子
↖ ↗
光
① どうして多重継承が必要か？
多重継承というのは、1つのクラスに2つの親クラスのメソッドを引き継ぎたい時に使います。例えば、
ゲームで使用するオブジェクトは大抵アップデート（状態の更新）する必要があります。
また画面に表示させるには描画メソッドが必須でしょう。ゲーム内で使用されるクラスの多くは、このどちらか、
もしくは両方の機能を持つことになるはずなので、その動作定義を親クラスでしておくと便利になります。
ただ、親クラスでUpdateメソッドとDrawメソッド（共に純粋仮想関数）を定義してしまうと、
描画の必要の無い派生クラスではDrawメソッドが不必要になってしまいます。
必要無いメソッドを空実装しなければならないというのは、クラスの設計として間違っています。
もちろんアップデートの必要が無い描画クラスについてもUpdateメソッドの空実装をしなければいけません。
http://marupeke296.com/CPP_No8_MultiClass.html >>175
＞いつからオブジェクト指向に多重継承が必須になったの？
シミュレーションには不可欠だが、同一オブジェクトであっても、『状況』により『属性』が変わる！
北極に近いフィンランドのヘルシンキの重力加速度(物体を自由落下させたとき、重力によって生じる
加速度。)は9.819m/s2、赤道に近いシンがポールの重力加速度は9.781m/s2となります。
100kgのもので計算すると9.781(赤道)÷9.819(極地)= 0.996=99.61％となり、
極地で100kgのものが赤道では99.61kgとなり差が390gということになります。
https://www.aandd.co.jp/adhome/products/keiryo_kiki/tech_info_8.html
↑
自由落下シミュレーションにしても、同一物体であっても状況によってその動きは違う！ >>175
＞いつからオブジェクト指向に多重継承が必須になったの？
『一人で二役』なんて当たり前だろう？
ベロニカ セーニャ
↖ ↗
芝井美香
ベロニカ役もセーニャ役も同じ人だよ！
ドラクエ11はキャラクターモーションがよく出来てるなぁと感心した人も多いのでは？
ベロニカとセーニャのモーションキャプチャーを担当している方は実は同一人物なのです。
その人とは芝井美香（しばいはるか）さん。
http://dragon-quest.me/dq10/6677/ >>199
え？
事実を言われて悔しかったのか？
ｗｗ
オブジェクト指向は実務経験者向けの思想だよ。
キッズには高等過ぎるんだなあｗ >>200
富士通とお前の関係は？
Fで心の病になって新卒1年で退職か？
んーー？ >>202
キッズ「まともな機能一覧さえあればシステムの構築も改修も問題ない」
キッズの妄想ってｗｗ んでその『オブジェクト指向の実務経験者』とやらが、このスレの俺らに何の用？
226 デフォルトの名無しさん 2019/05/03(金) 22:07:47.89 ID:H4kt2X4Y
>>199
え？
事実を言われて悔しかったのか？
ｗｗ
オブジェクト指向は実務経験者向けの思想だよ。
キッズには高等過ぎるんだなあｗ 俺はただパソコンに向かって独り言ブツブツ言って、チンポがシコシコしてるだけだが？
227 デフォルトの名無しさん 2019/05/03(金) 22:09:08.64 ID:H4kt2X4Y
>>200
富士通とお前の関係は？
Fで心の病になって新卒1年で退職か？
んーー？ >>230
パソコン使ってるんだったらCPUの型番を言えよ！ >>226
＞オブジェクト指向は実務経験者向けの思想だよ。
＞キッズには高等過ぎるんだなあｗ
この車、タイヤがパンクしてるぜ！
この俺、チンポがシコシコしてるぜ！
どちらもオブジェクト指向で言う 注目は、選択肢イです。この上向きが集約で、下向きが分解です。
自動車は、アクセルやブレーキ、ハンドルなどに分解されるからです。
http://sm.seeeko.com/archives/65913086.html
浮気に激怒の妻、眠る夫の局部を切断しトイレに流す（印）
TechinsightJapan 2018年02月25日 04:00
https://www.excite.co.jp/News/world_clm/20180225/Techinsight_20180225_477828.html >>230
これは本当だろうなあ。
お前の現状が何なのか知らんが、システム開発の経験がないとオブジェクト指向を理解できないのは事実。
サイト立ち上げるとか、システム構築しろ。
こんだけ粘着してるくらいだからオブジェクト指向に興味はあるんだろうから。 >>234
＞システム開発の経験がないとオブジェクト指向を理解できないのは事実。
システム開発の経験の有無に関わらず、オブジェクト指向は俺の股間に付いている！
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！ >>235
陰茎が勃起するのは生理現象で
本体の生命活動の一部ですよん
独立してないっすはい論破 バリカン持って虎視眈々な連中ばかりだからフサフサな話題を振ったところでｗ >>236
＞陰茎が勃起するのは生理現象で
＞本体の生命活動の一部ですよん
陰茎にいくら力を入れても勃起なんかしないぞ？ >>236
＞陰茎が勃起するのは生理現象で
＞本体の生命活動の一部ですよん
トイレでオシッコを出したり止めたりするときは、本体の生命活動ではなくて手や足と同じ随意筋だよ？
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く お前ちんぽの事本気で考えてないだろ
だからそんなに論理展開が甘いんだよ 技術的な話題についていけなくなるとチンコレスをするキッズ >>248
オブジェクト指向は俺の股間に付いているから、技術なんて必要無いよ？ チンポ君とチンポレス
まじつまんねーよ
社会不適合者かもしれないけど、ネットだからってねぇ 他人の話にはつまらないとケチを付けるが
自分では話を提供できない話を広げられない話を拾えない
斜に構えてカッコつけてるだけの頭の悪いコミュ障 ちんぽの話を続けます
ID:lOcfPmLB 先生お願いします チンポ体操
チンポを手に持ち しごく運動から
1 2 シコシコ
2 2 シコシコ
チンポを振り回す運動
1 2 ブルンブルン
2 2 ブルンブルン 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↓ ↓ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/j3uTk1K.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 >>234
＞システム開発の経験がないとオブジェクト指向を理解できないのは事実。
『オブジェクト指向プログラミング実務経験○年』なんてのは、今では全然役に立たないよ？
プログラミングは学習用C/C++の一択で、その他オブジェクト指向プログラミングとやらは、
最新のシミュレーション人工知能システムに対応できていないのだから。
ゲームCG技術の進歩はまさに日進月歩です。例えば、「物理ベースレンダリング（※1）」は今や
「フォトリアル」な3D表現に必須の技術になりました。より効果を上げるため、物理ベースのマテリアル
やライトのライブラリ強化を進めています。オブジェクトの配置を効率化したり植物や布などを
アニメーションさせたりする「プロシージャル（※2）」なワークフローもすでに当たり前の技術
になりました。写真からリアルなオブジェクトを生成する「フォトグラメトリ（※3）」技術、
「Simplygon（※4）」や「A.I.Gigapixel（※5）」などゲーム制作の効率を向上させるツール
もたくさん導入しています。アニメーション関係ではニューラルネットワーク（※6）
を利用してモーションを自動生成する技術が有望です。
最近発表された、4足歩行する動物のモーションをニューラルネットワークで学習させる技術は、
高いところへの上り下りや、ジャンプや着地までとても自然につなげてやってのけます。
多くの計算リソースが必要な「モーションマッチング（※7）」よりもエレガントな手法だと思いますね。
様々な技術をゲーム制作へ応用させるため、技術支援部やTAチームで研究しています。
https://www.koeitecmo.co.jp/recruit/graduate/2020/member/vol-07/ IDコロコロ変えたり、フォント変えたりして必死だけど
そんなアホな話題について話してるのはお前一人だろｗｗｗ そういうのが面白いと思っている人ってまだいるんだね
普段口にできないことを書いて、それで爽快感を得ているのかな？それって単なる「自慰」にしかみえませんが… >>194
＞このバカはオブジェクト指向じゃない方法でもまともなシステムを開発したことないだけ。
オブジェクト指向は俺の股間に付いているから、オブジェクト指向システム開発なんて全然要らないよ？
随意筋 不随意筋
↖ ↗
チンポ
『継承』は、サブクラス➡スーパークラス！
オブジェクトの『属性』とは、そこのお前は一体何者なのかという問いかけであり、
オブジェクト間メッセージングとはまさに自我とチンポの二人称対話に他ならない。
ペンギンは鳥なのか？ 鳥なのに空を飛べないのか？
空を飛ばない鳥も鳥なのか？ そうだとすれば鳥の定義は何なんだ？
ズワイガニはカニなのに、タラバガニはヤドカリなのか？
アンパンにアンコ入ってるのに、ウグイスパンにウグイス入ってないな？
嘉門達夫はテレビ放送でも『ラジオでごめん』？ >>262
まだです、どうも連休が明けないと発送処理してくれないみたいですね、達人出版社は >>264
何を買おうとしてんだ？
出版社から買うと送料かかるだろ？ >>265
>>153
>>147
送料こみで振込みしたつもりなんですが… >>266
Cでオブジェクト指向を実装する方法みたいな話が載ってんのか？
実用性はまったくないが、疑問を解消する姿勢は評価する。
送料無料の本の通販サイトじゃ売ってないのか？
どこで買おうとお前の自由だけど、今どき送料払って買うなんて珍しい。 >>267
私は >>172 で示したとおり C で（委譲とは区別できる形での）継承は実装できない（ただしこれに対しては >>175 の突っ込みあり）、
という持論ですが、でも、C で OO を全部記述してやる、という心意気を本の紹介文から感じてしまったので思わずポチってしまった… >>268
しばらく前までC++はCに変換してCのコンパイラでコンパイルしていたらしいから
C++でできることならできるんじゃね。
C++で使われていたテクニックを解説してるような本なんじゃね。
勝手な想像だけど。 継承は型に関係がある
委譲は関係ない
なんでいつも型が出てくるのか
オブジェクト指向そっちのけで型の疑問を解消したいんだが 継承も委譲も型とは関係ない
型はプログラミングの論理的不整合を
コンパイラに見つけてもらうための追加機能であって
コンピュータに人間の仕事を肩代わりさせたいなら
型を使って、人間が頑張りたいなら型を使わないだけの話 普通はクラスも型に含めるだろ。
そしてクラスと継承は関連する。 型って集合のことじゃん
bool型は{true,false}の集合
int型は{0,1,2...}の集合
抽象データ型は関数をその集合に入れられますよってもの
オブジェクト指向言語では抽象データ型を定義できる
実装の継承は値や関数を引き継げる
型の継承は抽象関数を引き継げる
オブジェクト指向における型は値、関数の実装、抽象関数の集合
オブジェクトの定義は型の定義と同義
コンパイル時に型チェックを行うのは静的型付けの説明かな >>273
プログラムを数学に関連付けて誤解するバカって多いよね。 >>275
オブジェクトを生成するとき、
そのオブジェクトは集合からやってきたとでも思ってるの？
あるクラスのオブジェクトを保持する集合がどこにあると意識してんの？
そもそもお前の中じゃどういうときに集合の存在を意識してんの？ >>276
質問の意味がわからない
僕が言いたいのは>>273に書いたとおりですよ
型って集合だよねってことです
質問ばかりで僕の負担が半端ないので
論理を展開していただけると助かります
オブジェクトが集合からやってきたとするならばうんぬんかんぬん
あるクラスのオブジェクトを保持する集合がどこそこにあると意識するならうんぬんかんぬん
自分は集合をこう意識するんだうんぬんかんぬん
てな具合で >>277
アスペかよ。
集合の存在なんてプログラムする際にはまったく現れないのに
集合として説明するお前は愚かだなあ
と言ってんだよ。 >>275に書いた「そうなの？」は
単純に「プログラムを数学に関連付けて誤解するバカって多い」
この事実を僕が知らないから聞いてみただけですよ
アンケート取ったわけじゃないだろうし
ベイズ推定的な直感で言っておられるんだろうとは思ったけど
何か具体的なエピーソードトークがあれば披露していただいて >>281
集合の存在に気づく僕と
それに気付かない君とでは
僕がバカすぎるの？
ダニング＝クルーガー効果で
君は自分が賢いと思い込んでるだけじゃないの？ >>276
横だがSmalltalkにはallInstancesというメッセージがあってだな…
とはいえSmalltalkのクラスはSimula同様に型ではないけどね 自分の知ってることに無理やり結びつけて「理解できちゃう俺すげー」
言うのはやっぱり愚かだと思いますよ。 >>284
君は自分が知らないことがあったら
それを知ってる人を愚かだと思うん？
はたしてそれは賢いことなんかね >>270が型とはなんぞや的なことを言ってたから
型は集合でオブジェクトと密接な関係があることを僕なりに説明したつもり
ちなみに型は集合って考えは少数派ではないとも僕は思ってる
ググったらたくさんでてくる
たとえばこれとか
プログラム言語論
http://www.cs.tsukuba.ac.jp/~kam/lecture/plm2017/6.pdf >>282
だから、集合の存在をいつ意識するのか聞いたんだが。
答えられないお前…。 違う考えをお持ちならそれをご披露いただければ
自分が思う型はこういうものだ的なご意見を拝読したいです >>287
うん・・・なんかごめん。
意識するの意味がわからなくて・・・。
僕には答えられないからこういうときに自分は意識するんだ！的なことをお述べいただければ
あるいは自分は意識しないんだなぜならば型とはこういうものだからやー！的なことをお述べになって
いただければ僕は正座して読むよ >>286
「プログラムを数学に関連付けて誤解するバカって多いよね。」
を自分で肯定してくれてご苦労ｗ >>289
「型は集合である」と主張してるのはお前なんだから
お前がプログラムのどういうときに「型は集合である」と意識するのか言えよｗｗｗ。
俺は意識しない。
それ以上俺から言う必要がなさ過ぎて。
頭悪いなあ。 >>285
知ってることを周回遅れでさも真実かのように語られた時、
やっぱ愚かだなって思うもんだよ。
どうせhaskellとかあの辺の抽象的な関数型言語からの受け売りでしょ。
自分が偏ってることに少しは気付く努力をしましょうね。 >>290
僕が肯定したら「プログラムを数学に関連付けて誤解するバカって多いよね。」
この命題は真になるん？ 僕の意見が参考になったら僕も嬉しいです >>289
つうかお前も集合だと意識することはないのなｗｗｗ。
型を集合として意識することがないのに
「型は集合である」と主張するお前って一体…。 >>293
反論してる奴なんてお前しかいなくて
お前が同意しているんだから
問題は解消したよ。
みっともない反論はやめような。 >>291
君は型は集合であるを意識しないんだ
僕もプログラミングしてるときには考えないかな
君はプログラミングしてるときに意識することを大事だと思ってるわけでしょ
それはどうして？ そこんとこ詳しくお聞きしたいな
自分は意識しないんだ、なぜならば型とはこういうものだからなんやー！ていう
力強い君の意見がお聞きしたいな
>>292
じゃあ君は型とはなんぞやの質問に対してどう答えるん？ >>296
プログラミングしてるときに意識しないのに
なんでプログラムにおける「型は集合である」と主張するんだ？
バカの考えは謎。 >>294
僕はプログラミングしてるときに「型は集合である」ことを意識する
必要があるとは思ってなくて型とはなんぞやということを
考えたときに集合かなーて思っただけだよ
君はプログラミングしてるときにどう意識してるかが大事だと
思っているわけでしょ、それはわかった
それでは君は型をどう意識してるん？ >>298
型は型である。
型の定義は教科書読んで勉強しような。
集合なんてかかれていないからｗ。 >>299
それは何の説明にもなってないです
辞典でちんぽを調べてちんぽはちんぽであるって載ってたらブチ切れでしょ？
ベンチプレスで鍛えた自慢の鉄腕で分厚い辞典を真っ二つに破り捨てて
発行元に即クレームの電話入れてTwitterで拡散して炎上させるでしょう
あなたが今言ってるのはまさにそういうことで完全に鉄腕ちんぽですよ
>>286の大学の講義資料は読みました？書かれてますよ
自分が勉強した内容や経験や知識をもとに
自分の意見を言えば建設的な議論ができるのかなって思うんですよ
意見交換という形でコミュニティとしては健全かなと >>300
頭悪い奴だと思っていたらちんぽマンかよ。
相手して損した。
その資料の「型はデータの集合である」という記述を言ってる？
お前の言う「集合」の意味じゃねえだろｗｗｗｗ。 >>301
大学の講義資料は僕の言う集合ですよ
君の言う集合は違うん？
君は型は集合ではないんだって立場なんですよね
では君は型をどう説明しますか？
この質問だけだと漠然としてて答えにくいかもしれないので
オブジェクト指向における型とは～
プログラミングにおける型とは～
と言ったふうに説明しやすい前提を置いていただいていいですよ
教えてください >>302
ちんぽマンは数学における「集合」の意味も理解してないのかよ。
ちんぽマンはバカ過ぎて会話にならん。 >>303
北海道大学でも同様に型を集合と説明してますよ
理解してないのは君の方かと
抽象データ型
http://kussharo.complex.eng.hokudai.ac.jp/~kurihara/classes/SE/04-abstdatatype.pdf
それはさておき僕の理解とは関係なく君の説明が聞きたいな
君は型というものをどう説明しますか？ 具体的に説明できないなら
自分がプログラミングするときに型をどう意識してるかを教えていただけると
なんかこうふんわりしてて生意気そうなやわらかさみたいな感覚的なものでも良いですよ
それに対して僕がつまりちんぽということですねと返すから
そこからあと一言いただければ >>304
「データの集合」と書かれているんだが。
あのさあ…。
馬鹿のためにわざわざチェックしたのが時間の無駄だった。 読んでいただいたのはありがたいけど
僕が聞きたいのは君の「型は集合じゃない」という意見だよ
ググればわかるようなまともな考えをここで知りたいとは思ってなくて
君のイカれた意見に興味があるんだよね、君の鉄腕を見せてくれ >>308
もう読まなくて良いですよ
僕の考えは十分に示しましたし君がそれをわかろうとしないのは仕方ないことかなと
僕は今夜君の型の説明が聞きたいです
僕は全力で君の意見をわかろうとするんでどうぞよろしくお願いします おい鉄腕説明はまだか？
僕は正座して待ってる、足がしびれてきた
これ以上待たせたら虐待で訴える >>291
> お前がプログラムのどういうときに「型は集合である」と意識するのか言えよｗｗｗ。
型→完全な円
（円の方程式）
集合→円形をした物
（円形の灰皿、円形の十円玉、円形のルーレット・・・その他身近なイロイロ）
『近似する実在物』を、ある一定の『実在しないひな形』にまとめるのが、オブジェクト指向！
イデアとは最高度に抽象的な完全不滅の真実の実在的存在であり、感覚的事物はその影であるとする。
イデアが存在しているのがイデア界（本質界）で、その陰が投影されているのがわれわれ人間の住む現実界となる。
例えば、現実の世界に、円形をした物はたくさん存在するが、いずれも完全な円ではないし円そのものでもない。
しかし、これらの円の背後には永遠不変で、完璧、かつ抽象的な円のひな型であるイデアがあるとする。
この考え方ってどっかで聞いたことある・・・そうだ！オブジェクト指向の考え方にそっくりなんだ。
オブジェクト指向はクラスという雛形（設計図）があり、クラスを元にして実体を持つオブジェクト
（インスタンス）がポコポコ作られるようなイメージである。
http://aidiary.hatenablog.com/entry/20050430/1114871993 ＞01000001011000000000000000000000
コンテキスト（時と場合）によって、チンポが随意筋なのか不随意筋なのかを使い分けような！
「モノ、コンテキスト、役割」の関係は、「モノ、照明、影」で例えられます。
モノに照明を当てると、影が出来上がります。影は、照明を当てる角度により形が異なります。
つまり、照明＝コンテキスト、影＝役割とすると、
仕事コンテキストでは従業員
家庭コンテキストではお父さん
趣味コンテキストではゲーム制作者
https://qiita.com/MinoDriven/items/2a378a09638e234d8614
＞現代的な考え方： データ型＝データの集合＋演算・処理の集合
＞01000001011000000000000000000000
＞• int CPUが整数演算に使うなら 1,097,072,640
＞• float CPUが実数演算に使うなら 14.25
＞• String CPUが文字列処理に使うなら ”槍” とNULL文字
＞• その他 CPUが画像処理に使うなら 白黒画像の一部
304 デフォルトの名無しさん 2019/05/05(日) 00:45:53.25 ID:0ZGoSt+d
>>303
北海道大学でも同様に型を集合と説明してますよ
理解してないのは君の方かと
抽象データ型
http://kussharo.complex.eng.hokudai.ac.jp/~kurihara/classes/SE/04-abstdatatype.pdf
それはさておき僕の理解とは関係なく君の説明が聞きたいな
君は型というものをどう説明しますか？ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) >>314
今日もまた発狂して一人チンポ芝居かよ。 >>269
それは同じ動きのCのコードを作るというだけで、できた C コードはすでに OO ではない可能性があるかと >>316
C++のプログラマはオブジェクト指向のコードとしてかいてるんだから
その主張は違う。 >>317
C++ の時点では OO であっても、それをトランスパイラに通して出てきた C コードは OO ではない、という可能性はあるのでは？
例えば C++ の時点では OO であっても、コンパイラに通して出てきた機械語は OO とは言いがたいでしょう？ 少なくとも数学的な集合の性質として
「順番は問わない」集まり
というのがある。これと型との関係は? >>318
最終的には機械語として実行されるから
どんな言語のオブジェクト指向ではないと言ってるようなもんだ。
どんな言語もオブジェクト指向ではない主張したいのか？ >>320
私の主張は、コンパイル／トランスパイルする前の記述言語において、オブジェクトオリエンティッドが達成されればいいだけです
トランスパイル／コンパイル語の記述体がオブジェクトオリエンティッドでなくてもいい
ただし、C 言語は、最初の記述時点において、すでに、オブジェクトオリエンティッドにおける継承が記述できないと考えています
それを示すのが >>172 のといかけで、この内容を C で書けない、したがって OO を C で実現できない、ということになります >>292
一般論として周回遅れマンが紛れ込んだときのベストな対応はスルー
周回遅れを自覚できていないという時点で
そいつの知力にはもはや期待が持てないので
そいつに対して一つのレスも費やしてはならない
この点を見誤ると、周回遅れマンに居座られてしまう >>321
だからそれに対して、昔のC++の実体はCだったと言った。
この意味を理解できてない様だなあ。
ついでにC++についても勉強したら。 >>323
C++ をトランスパイルして出てきた C は継承を表現できていなかったのでは？
>>172 で私は C++ コードを書いていますが、これをトランスパイルして得られるはずの C コードはどのようなものと推察されますか？ >>324
実際にC++をCに変換して確認しりゃいいだろ。 >>325
すでに私は確認しており、C にトランスパイルされた時点で OO ではなかったと記憶しています
あなたは C でも OO できる、という立場であれば、>>172 の C++ コードに対して対応する C のコードを記述できるでしょうから、それを見せてください
C で OO の継承を記述できない、という立場であれば、私と同じです >>326
C++はオブジェクト指向だと認めるんだよな？
で、C++はCの機能だけで作られていた。
Cの機能だけでオブジェクト指向が実現できる、以外の結論を主張するのが意味不明過ぎて。 >>327
＞C++はCの機能だけで作られていた。
機能、という言葉の使い方があいまいですね
・「C++ をトランスパイルした結果が C のコードが出力される」という事実だけでは、C が（委譲とは区別された）継承を記述できるかどうかを示すことはできないのではないでしょうか？ >>328
お前も理解力が低過ぎるから説明するのが面倒になった。
ま、お勉強しような。 アップキャストできるから移譲と区別とはならないの？ >>329
私は >>172 の C++ に対応する C コードを示していただければ満足します
>>330
多重継承のときは、そのアップキャストはどうなりますか？ >>332
そのとおり！
そういうのを手でちまちまと書く、というのを「OO できている」とはいわないという主観です マシン語に変換された瞬間にOOできてないに変化するってこと？ そう言われるだろうと思って自分でルールを作らなくなるんだろう
自分ではない誰かが作った教科書を読めとしか言わなくなる >>335
基底クラスA, B とそのメソッド A.f(), B.g()
A, B を多重継承する派生クラス C とメソッド C.h()があったとして
（コード例は >>172)
今 C のインスタンス c に対して
c.f() と c.h() の両方を実行したいとき c の this から
c 内の A のために this を作り c.f() を呼ぶ…①
c 内の B のために this を作り c.h() を呼ぶ…②
①②のどちらかあるいは両方について、c の this をずらして基底クラスの this を作らないといけません
>>172 の C++ では c->f() や c->h() とお気楽にかけるのに、C では、チマチマと this にオフセットを「人間が数えて」足し込むコードを書かなくっちゃいけない
そんな体たらくじゃ C では多重継承は書けないのと同等ですね >>339
それはC言語がオブジェクト指向プログラミング言語ではないと
言ってるに過ぎないと思うの
手でちまちまと書く、というのを「OO できている」とはいわないのはどうしてなん？
オブジェクト指向プログラミング言語でプログラミングすることだけを
オブジェクト指向と言うん？ それはどうしてなん？
オブジェクト指向は考え方であって手段として手書きするのか
言語の機能を使うのかはどちらでも良いと思うのだけれども
どうして多重継承を言語としてサポートすることが大事だと思うん？ >>340
＞それはC言語がオブジェクト指向プログラミング言語ではないと
＞言ってるに過ぎないと思うの
であれば、それが私の言いたいことそのものですね、問題ないのではないでしょうか？
＞手でちまちまと書く、というのを「OO できている」とはいわないのはどうしてなん？
手でちまちまと、すなわち手動で this を作らないといけないようではオブジェクト指向はできてないでしょうね…
＞オブジェクト指向プログラミング言語でプログラミングすることだけをオブジェクト指向と言うん？ それはどうしてなん？
そうはいってませんよ、単に C でオブジェクト指向にのっとったプログラミングはできない（なぜならばオブジェクト指向の重要な要素である継承が実現できないから）、といっているだけです
＞オブジェクト指向は考え方であって手段として手書きするのか言語の機能を使うのかはどちらでも良いと思うのだけれども
＞どうして多重継承を言語としてサポートすることが大事だと思うん？
多重継承を例にするのがわかりやすいから、多重継承を例にしただけです。 >>342
君はオブジェクト指向プログラミング言語でプログラミングすることを
オブジェクト指向ができていると表現してるわけだね
C言語は多重継承をサポートしていないという事実から
C言語はオブジェクト指向プログラミング言語ではないを導き
C言語ではオブジェクト指向できてないを導出したわけですね
自明ですが、論理とは自明の積み重ねですからね
そういうの大事だと思います 僕の考えるオブジェクト指向はこうです
オブジェクト指向とはオブジェクトを主要なものとしてシステムを作ることです
オブジェクトとは状態と振る舞いのセットです
分析や設計の段階でオブジェクト指向で考えることができますし
C言語や継承の機能を持たない古いVBでもオブジェクト指向を適用可能です
要件を満たすにはこういうオブジェクトが必要だ
この状態はこのオブジェクトが持つべきだ
この振る舞いはこのオブジェクトが持つべきだと
考えるのがオブジェクト指向なのです 大事MANブラザーズバンドが昔
負けない事・投げ出さない事・逃げ出さない事・信じ抜く事 それが一番大事と歌いましたが
それを歌った本人は後年どれも大事じゃなかったと言いました
良い話です
オブジェクト指向プログラミング言語がもつ機能として
・カプセル化
・多態性
・継承
これらが提唱されてはいますが
オブジェクト指向にとってどれも大事じゃないです
良い話ですね オブジェクト指向ってなんなのかもわからない人だらけで、クラスこととだと思ってる奴が未だに大勢いるからな
最近じゃクラスを持たないオブジェクト指向言語が使われ出してきていて誤解も減ってきてる気はするけど クラスを持たないオブジェクト指向言語って具体的にはどれ？ >>343
＞君はオブジェクト指向プログラミング言語でプログラミングすることを
＞オブジェクト指向ができていると表現してるわけだね
いいえ、OO な言語でなくても OO で記述できる範囲を代替できれば、それも「オブジェクト指向ができている」とします。
ただし C 言語は単一であっても継承を委譲と区別して記述できない…①
継承は OO では基本的な考え方、枠組みである…②
①②より C 言語では OO 的な記述はできない
となります
＞C言語は多重継承をサポートしていないという事実から
＞C言語はオブジェクト指向プログラミング言語ではないを導き
＞C言語ではオブジェクト指向できてないを導出したわけですね
多重継承だけではなく、単一継承も C では不可能、とします。
なぜならば、
構造体の第一メンバのアドレスと、構造体そのもののアドレスが一致するとは限らない…③
構造体の各メンバの物理的な順序はプログラマから指定することはできない、構造体テンプレートごとにシャッフルされても文句はいえない…④ >>344
＞要件を満たすにはこういうオブジェクトが必要だ
＞この状態はこのオブジェクトが持つべきだ
＞この振る舞いはこのオブジェクトが持つべきだと
＞考えるのがオブジェクト指向なのです
これを①とします
①は
オブジェクト指向「的」に記述する
というなら許容できますが、オブジェクト指向そのものではないと思いますね 人とか動物、鉛筆やボールペンならよく分かるんだが、実際のプログラムになると何がオブジェクトなのか途端に分からなくなる。 >>340
＞どうして多重継承を言語としてサポートすることが大事だと思うん？
随意筋 不随意筋
↖ ↗
チンポ
『継承』は、子クラス➡親クラス。
多重継承を否定できないのは、この現実世界においては、状況によって相反する属性が現れるから。
特に機械翻訳においては、文脈によってコトバの属性を選択しなければならない。 >>352
実際のプログラムではそういったビジネス要件のクラスと
メモリ、データベース、ネットワークアクセスを上手くマッピングするレイヤーが
必要になるからな。
オブジェクト指向が役に立つ場面もあるが邪魔になる場面もある。 多重継承をサポートしてる言語って
C++以外だと何がある？ >>350
つまり結論はC言語はオブジェクト指向プログラミング言語じゃないってことですよねわかります
>>351
僕のオブジェクト指向と君のオブジェクト指向は異なることを言ってますね
それはそうです >>355
型の継承ならインターフェースって形でJavaはサポートしてますよん
Javaはインターフェースでのデフォルト実装ができるようになったので
実装の継承もできちゃう >>357
Javaで言うとクラスの多重継承の意味で聞きたかった >>352
プログラムで何をやるのかによって
変わってくるんじゃないかと
ソフトウェアが処理の対象にする分野はドメインと呼ばれるけれども
オブジェクトはドメインによって変わってくるかと
たとえば表計算というドメインでは「行」という概念があり「列」という
概念があり「セル」という概念があってそれぞれ状態や振る舞いを持つじゃん
ファイルはデータを読んで分析するというドメインでは「データソース」になるし
処理したデータを永続化するというドメインでは「データストア」になるし
データを連携するというドメインでは「連携データ」になる
てな具合で
ソフトウェアが解決しようとしてるドメインを考えることによって
こういう概念があるとシステムがわかりやすいよね
処理しやすいよねって考えるのがいんじゃないかなと思いました >>360
Javaで言うとextendsで複数クラスを指定という意味
インターフェースはimplementsだから継承といよりは実装のほうが良いような
もちろんデフォルト実装があるのは知ってるけど >>358
＞Javaで言うとクラスの多重継承の意味で聞きたかった
随意筋 不随意筋
↖ ↗
チンポ
『継承』は、子クラス➡親クラス。
多重継承を否定できないのは、この現実世界においては、状況によって相反する属性が現れるから。
特に機械翻訳においては、文脈によってコトバの属性を選択しなければならない。 >>361
クラスにあってインターフェースにないものそれは状態
状態の多重継承ってことね
たしかにJavaではむりっすねー >>352
その疑問は的を得ている。
そこで設計指針が必要になる。 肉眼で見れば『空っぽ』のサンプル容器だが・・・
2010年6月に小惑星探査機「はやぶさ」が帰還しました。11月になって持ち帰った岩石質の微粒子が
小惑星イトカワ由来と分かり、大変に注目され、また意気も上がりました。これはサンプルキャッチャー
と呼ばれる帰還したサンプル容器の内側を特殊なヘラで触って集めた約3300個のうち、
人工物（主としてアルミ片）を除いた約1500個の岩石質極微小粒子（大部分が10μm
［マイクロメートル、1μm＝1mmの1000分の1］以下）の組成を調べて
分かったことです（図1におおよその鉱物組成比を示す）。
http://www.isas.jaxa.jp/j/forefront/2011/fujimura/
観測の仕方について、同じオブジェクトでも全く違う物になりうる！
＞現代的な考え方： データ型＝データの集合＋演算・処理の集合
＞01000001011000000000000000000000
＞• int CPUが整数演算に使うなら 1,097,072,640
＞• float CPUが実数演算に使うなら 14.25
＞• String CPUが文字列処理に使うなら ”槍” とNULL文字
＞• その他 CPUが画像処理に使うなら 白黒画像の一部 >>363
＞状態の多重継承ってことね
＞たしかにJavaではむりっすねー
サンプル容器に『イトカワの砂』は入っていたのか？ >>366
おいお前、知らない
すまない力になれなくて >>340
＞どうして多重継承を言語としてサポートすることが大事だと思うん？
同一オブジェクトであっても、『視点』が変わると全然違う『属性』が表れてくるから。
新幹線の座席で寝ている人は、時速200キロで移動しながら寝ているのだぞ？ >>368
新幹線の話はよくわからないんだけど
属性が全然違うなら全然違うオブジェクトにすればいいと思うの >>369
＞属性が全然違うなら全然違うオブジェクトにすればいいと思うの
同一オブジェクトとして扱うが、『視点』は別々にしようってことなんだが？
＞現代的な考え方： データ型＝データの集合＋演算・処理の集合
＞01000001011000000000000000000000
＞• int CPUが整数演算に使うなら 1,097,072,640
＞• float CPUが実数演算に使うなら 14.25
＞• String CPUが文字列処理に使うなら ”槍” とNULL文字
＞• その他 CPUが画像処理に使うなら 白黒画像の一部 >>370
同一オブジェクトにしなければ良いと思うの
Decimalオブジェクトもお金を扱うときはMoneyオブジェクトにするし
税金扱うときはTaxオブジェクトにするじゃん
同一オブジェクトという前提がおかしいんだよ
継承は設計が悪い兆候と心得よ 視点が変われば属性が変わる属性が変わればオブジェクトを変えるべきですよ >>372
＞視点が変われば属性が変わる属性が変わればオブジェクトを変えるべきですよ
同一の光であっても、波と粒子とで別々のオブジェクトにするのか？
新たに開発した電力変換装置は、太陽光発電システムと水電解装置のシステム構成上の制約を解消するものであり、
太陽光由来水素製造の規模拡大を加速するものである。太陽光発電システムと、それらから得られた
電気エネルギーによる水素製造のさらなる普及のため、システムを構成する集光型太陽電池、電力変換装置、
水電解装置の一層の効率向上と低コスト化はもとより、さらには急激な日照の変動による入力電力の
変動に対応したシステムの耐久性向上が求められる。
https://pr.fujitsu.com/jp/news/2018/07/19.html >>372
＞視点が変われば属性が変わる属性が変わればオブジェクトを変えるべきですよ
勃起するときのチンポは随意筋だけど、オシッコを出すときのチンポは随意筋だな。 >>375
光という基底クラスがあって、波動を表現する波光クラスと粒子を表現する粒光クラスという派生クラスを作るんじゃね。 勃起するときのチンポは『不随意筋』ね。
オシッコ出すときのチンポと、勃起するときのチンポは、別々のオブジェクトってことだな！
376 デフォルトの名無しさん 2019/05/06(月) 08:54:09.49 ID:CTjazNaS
>>372
＞視点が変われば属性が変わる属性が変わればオブジェクトを変えるべきですよ
勃起するときのチンポは随意筋だけど、オシッコを出すときのチンポは随意筋だな。 >>377
＞光という基底クラスがあって、波動を表現する波光クラスと粒子を表現する粒光クラスという派生クラスを作るんじゃね。
チンポという基底クラスがあって、勃起するときの不随意チンポと、オシッコするときの随意チンポと、
別々の派生クラスを作るんじゃね？ 粒子と波の性質を持つなら、それぞれのinterfaceを定義して、その両方を実装するのがいまどきのオブジェクト指向でしょ。 チンコは性器と泌尿器のinterfaceを実装するのが筋。
あと、陰茎は海面体だから、随意筋でも不随意筋でもないぞ。 >>377
＞光という基底クラスがあって、波動を表現する波光クラスと粒子を表現する粒光クラスという派生クラスを作るんじゃね。
リスコフの置換原則
この原則は「基本クラスを使っている場所で基本クラスの代わりにサブクラスを使っても
問題なく動かなけらばならない」というものです。
https://qiita.com/UWControl/items/98671f53120ae47ff93a >>382
リスコフの置換原則は型の継承の原則だから
実装の継承を使った差分プログラミングが目的なら
リスコフの置換原則にこだわる必要はないかと
君が大好きな多重継承は差分プログラミングが目的なんじゃないかな？ 君はちんぽと本気で向き合ってない
ちんぽを舐めるな！ >>383
＞リスコフの置換原則にこだわる必要はないかと
複数のサブクラスから共通の『属性』を抽出するのがスーパークラスということなのに、
もしもリスコフの置換法則を無視するならば、スーパークラスとサブクラスの関係は成り立たなくなるのでは？ >>223
＞必要無いメソッドを空実装しなければならないというのは、クラスの設計として間違っています。
大学入試物理を自動回答するのに、高校物理の履修範囲から逸脱した公式（メソッド）を出してはいけない！ >>372
＞視点が変われば属性が変わる属性が変わればオブジェクトを変えるべきですよ
コンテキスト視点でということで、同一人物であっても別オブジェクトに指定したほうが良いということだな。
まあ確かに、そのほうがシンプルでわかりやすいシステムが出来るだろう。
「モノ、コンテキスト、役割」の関係は、「モノ、照明、影」で例えられます。
モノに照明を当てると、影が出来上がります。影は、照明を当てる角度により形が異なります。
つまり、照明＝コンテキスト、影＝役割とすると、
仕事コンテキストでは従業員
家庭コンテキストではお父さん
趣味コンテキストではゲーム制作者
https://qiita.com/MinoDriven/items/2a378a09638e234d8614
↑
けれどもこれは業務用のデータベース管理システムにしかならない！ >>259
>>225
近年はデータベースよりも実写モデルが重視されつつある。
データベース管理だけなら、多重継承抜きの『オブジェクト指向プログラミング言語』で十分。
しかしながら人工知能やシミュレーションともなると、『水』をどういうオブジェクトとして扱うか、
オブジェクトの多様性と流転性と属性変化を常に意識しなければならなくなる。
210 デフォルトの名無しさん 2018/09/24(月) 07:12:53.20 ID:61Bjkcq4
>>208
＞「水」
1化合物
2容器に入った液体
3噴水
4漏水
5水滴
6溶媒
7水溶液
これくらいの使い分けは出来るようにしたい。
211 デフォルトの名無しさん 2018/09/24(月) 07:18:18.60 ID:61Bjkcq4
おっと。
8流水
10蒸発水
11結合水
12貯水
高校物理化学だけでもこうした訳し分けが重要。 ＞必要無いメソッドを空実装しなければならないというのは、クラスの設計として間違っています。
ゲームもまたシミュレーションの一形態だ。
オンラインゲームくらいなら、勃起するチンポとオシッコするチンポは別オブジェクトに指定すれば良いだろう。
しかしながら最新の医療シミュレーションについては、チンポは同じチンポとして多重継承するしかない。 >>381
＞陰茎は海面体だから、随意筋でも不随意筋でもないぞ。
オシッコを出す・オシッコを止める（随意筋）、そんなことも出来ないのか？
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 30にもなってチンポとか・・・
小学生じゃあるまいし、歳を考えろと・・・ 気になったのが太陽が東から昇り西に沈むという問題
これは便宜上そう見えるから一般常識化しているけど
正確には地球が動いている。そこまでいわないと。天動説は覆ったんだから。
https://ameblo.jp/cinnamon-rilakkuma/entry-12459204488.html
気になったのは、チンポ『を』シコシコするという問題。
これは便宜上そう見えるから一般常識化しているけど、
正確にはチンポは自らシコシコしてる。そこまでいわないと。チンポは独立した生き物なのだから。 >>400
シコシコするは他動詞だから目的語がないと
言葉として成立しない
ちんぽがシコシコするはNG
ちんぽが人間をシコシコするが正しい
そういう理解でいいですね？ ちんぽと人間が独立してると仮定する場合
ちんぽが死亡したとしても人間が死亡するとは限らない
よってちんぽと人間のライフサイクルが同じになる継承や
コンポジションは使えない
ちんぽと人間は集約によって結びつくのが妥当
つまりちんぽコンストラクタは引数として人間を受け取り
状態として保持する
ではちんぽオブジェクトを作成する責務はどのオブジェクトが
持つべきであろうか 朝気がつくとチンボがシコシコする。
何事かと目を開けると下半身を黒い何かが覆っていた。
いや、それは人の頭部であり裸の女が俺のイチモツを咥え込んで荒々しく上下していたのだ。
「おい、おこすならもっと普通にやれ。」
つい最近同棲し出した彼女…と言うかそもそも女か？に声を掛けると、怪しい笑顔で俺を見て、
「 答えは太陽である
ちんぽは時として人間から俺の息子と呼ばれるわけだが
これはちんぽの創造主がザ・サンであることの名残である
そのことを言いたかったわけですね？ 幼稚園児「ちんぽー、うんこー。ぎゃははは」
30歳男児「ちんぽー、うんこー。ぎゃははは」 >>408
＞30歳男児「ちんぽー、うんこー。ぎゃははは」
1975年5月生まれ。 >>236
＞陰茎が勃起するのは生理現象で
俺って立派に科学者してるだろう？ インタフェースってオブジェクト指向なの？
オブジェクトが手続きを所有すんの？
それとも手続きが必要なオブジェクトを所有すんの？ >>404
＞ちんぽが人間をシコシコするが正しい
＜チンポ＞
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」
まさにチンポが竜哉くんをシコシコさせて、 竜哉は体中が引き締まるような快感を感じたのだ！
違うか？ >>303
＞数学における「集合」の意味
データベース型の統計的機械翻訳なんて、もはや10年前のIBMワトソンを最後に全てが終わっている！
学校でならう『数学』はユークリッド幾何学であり、例えば複素数平面なんてゲームの世界でしかない！
ロボマインド・プロジェクトでも、同じ問題に直面しました。
我々、人間は、「ドアの外の廊下の上には天井がある」などと覚えているわけではありません。
それでは、どうやって、認識しているのでしょう？
頭の中で、部屋からドアを開けて廊下に出たところを想像するだけです。
廊下に出れば、上には天井がありますよね。
それでは、これを、コンピュータで実現するにはどうすればいいでしょうか？
それには、家の３ＤＣＧモデルを作れば実現できます。
データベースを使うのでなく、実際に見えるままの姿を３Ｄモデルで作成するのです。
https://robomind.co.jp/symbolgroundingproblem/
実在気体 理想気体
↖ ↗
気体
随意筋 不随意筋
↖ ↗
チンポ
波動 粒子
↖ ↗
光
データベース検索なら別オブジェクト扱いで良いが、自動翻訳やシミュレーションなどは多重継承しかない！ 多重継承を使うと多重継承を使わないときより
こういうところがこんなに素晴らしくなりました的な
ご知見を教えていただけると オブジェクト指向は理解できても、実際に使って有用性を感じられない
オブジェクトの有用性を感じられるかは、規模の違いによってですか？ >>415
＞多重継承を使うと多重継承を使わないときより
＞こういうところがこんなに素晴らしくなりました的な
＞ご知見を教えていただけると
俺の股間に付いているのが、そんなに羨ましいか？
随意筋 不随意筋
↖ ↗
チンポ >>416
＞机上の空論では意味がないので
机上の空論では意味がないので、トイレに行って、チンポに力を入れたりチンポから力を抜いたりしてみよう！
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>419
シミュレーションソフト作ったことあるん？ >>420
シミュレーションソフト開発などしなくても、オブジェクト指向は俺の股間に付いているぞ？ >>418
いろんな処理のあるプログラム書くと有り難みがわかるかも
# 仕様1
・DBからテーブルAのデータを取得する
・取得したデータをExcelに出力する
・Excelは行が1000行を超えたらシートを変える
・Excelのシート名はデータ1,データ2・・・のようにする
・出力したExcelをZIPで圧縮する
・ZIPを添付したメールを文面Aの内容で送信する
# 仕様2
・DBからテーブルBのデータを取得する
・取得したデータをExcelに出力する
・Excelは行が1万行を超えたらシートを変える
・Excelのシート名はデータ1～10000,データ10001～20000のようにする
・出力したExcelをZIPで圧縮する
・ZIPを添付したメールを文面Bの内容で送信する
同様の仕様が追加される予定ありみたいな
状況を想定して作ってみると良いよ >>421
シミュレーションでは多重継承がいるんだ
多重継承のためにちんぽがあるんだってことだと思うんですが
ちんぽはあなたの股間に付いてるからシミュレーションはいらないと
本末が転倒しておられる
あなたのちんぽはねじれてます >>424
＞ちんぽはあなたの股間に付いてるからシミュレーションはいらないと
スマン、間違いだった。
シミュレーションの研究は『多重継承』も含めて、まだまだこれから。
下のリンク先にも、実世界のモデル化には『多重継承』が不可欠とのこと。
第1章 実世界のモデル化と形式化
https://slidesplayer.net/slide/11406478/
但しオブジェクト指向についての議論は、システム開発の業務経験は要らないということ。
むしろそうした中小ソフトハウスの中途半端かつ時代遅れのデータベース至上主義は、百害あって一理なし。
↓
198 デフォルトの名無しさん 2019/05/03(金) 18:01:44.10 ID:H4kt2X4Y
>>196
まともな機能一覧が出ても問題が起きるんだが。
システム開発の経験がないんだなあお前。 >>424
＞あなたのちんぽはねじれてます
参った、参った！
俺も10年ぶりにC/C++と基本情報技術者試験をやり直そうかなぁ。 >>413
つまり継承によって構造を柔軟に
保持できるといいたいのかな？
おれはCとC++を使ってるけど
全く流儀が異なるから、どちらが
良いとはいえないと思ってる。
どんな言語で作っても
良いドキュメント作れないと無意味。
分かりやすいソース作れない奴はいらない。 自分では面白いと思ってるのかな
どっちにしてもイタい人なんだろうな >>422
仕様１を作ったのと同水準の額をを仕様２や将来必要となるであろう仕様３ではもらえないってこと？
それとも行数は似たような感じになるから納入まで作業をしてるフリをすれば、ほぼコピペでも同じような額もらえるって事？ >>417
記載通り規模によるもの
そもそも成功事例を体験していない
の２パタンがあると思う。 >>428
おれんのでよろしければ、
ご活用くだしい 役割ごとメソッドやクラスを分ける、という考え方自体は必要だと思います。
異様に長いクラスがズドーンとあるより、
整理されていた方が絶対メンテナンスしやすいので。
ただ、完璧にまでオブジェクト思考で構成されたプロジェクトを途中から渡されると、
こんなもん作った人しかわからなくね？
解説もしくは読み解く時間くらい与えてくれ、と思ってしまう
それともやはりプロはどんなプロジェクト構成でも
短時間で理解できなきゃいけないのですかね
たとえ底辺単価の使い捨てだとしても。 × ただ、完璧にまでオブジェクト思考で構成されたプロジェクトを途中から渡されると、
○ クソコードなだけ 正直、私の読解能力が低すぎるのは確かですが、
あの時はきつかった…
あらゆる機能がひたすら色んなクラスに分かれてて
ああこれがオブジェクト指向なのかと滅入りました。
ルール決めて最初から関わってたら印象ちがつたかも。 その滅入った率直な乾燥が
オブジェクト指向の問題そのものだよ。
自分の感じた疑問に自信を持ちなよ 全部1ファイルで作ればいいのに
って言ってみれば？ まあ俺にはオブジェクト指向プログラミングなんて必要無いな。
オブジェクト指向は俺の股間に付いているのだから！ クラスが沢山有るタイプなら
クラス関連図とかが必要だと思うけど
無かったのか?
コードだけで読み解くのは厳しいだろうな 性格に影響してる遺伝子の解明を早くしろ
そして問題がある奴は生まれる前に処分しろ すべての機能をmainメソッドに実装すればあちこち移動しなくていいから読みやすい。
変数を最初に全宣言してくれてたらなおいい。 誰かのやった機能分けは他の人には理解に苦しむってのは良くあるからな。
物事を捉える観点や物事に対する概念が格個人で違うから
個人が細部まで分割したクラスは人によっては拒絶反応すら示す様になるよ。 オブジェクト化はAPI化やフレームワーク化と似ているように思う。
いずれもカプセル化。 VBでいう標準モジュールで事足りてて、どうしても個別状態が必要なところだけクラスモジュールで作る
中途半端なヲタが入り込まないようにフレームワークはMSが隠蔽する
これでよかったんだよね >>453
性格のいいやつが感染する病気で一気に全滅しそう
悪い奴も残ってないと耐性情報が作られない
生物ってのは多様性が重要 >>457
あらゆる機能がひたすら色んな標準モジュールに分かれてて
ああこれがVBなのかと滅入りました。
ルール決めて最初から関わってたら印象ちがつたかも。 >>459
そのプロジェクトの長によるだろうね
formモジュールには業務ロジックは書くな、とかローカルルールがあったり
標準モジュールで整頓できない規模だったら、ライブラリ化するとか、構造化の手段はあるでしょう とにかく、語りたがりのバカの話は半分聞いておけばいいよね >>456
＞オブジェクト化はAPI化やフレームワーク化と似ているように思う。
チンポはそれ自体が独立した生命体だからな！ オブジェクト指向がクソだと言い張るものは思い出せ
Ｃの配列ですら実装メモリサイズという隠蔽された状態を持っていたことを クラス構造図が無い
というのは
配管や配線の図が無い状態で壁や床天井にいきなり穴開けたりするのと同じなのよね
ほぼ必須の物だと思う
逆に言うと
図さえ有れば理解し易い
改修する時もやり易い
設計図を描いてから作る
って感じになる
コーディングする時はただの作業になる
だから
図が無い方がどうかしていると
自分は思う いきすぎてなければ、考え方は必要だと思います
そんなもんオブジェクト指向ではないと言われたら言い返せませんが >>440
オブジェクト指向言語で
作られたアプリは全てクソコードだよ。
作った人しか分からん。
レべルの低いのが
オブジェクト指向言語使うと
ホント迷惑だ。
だがレべルの低い奴しかいない。 つまりお前の言いたいことはこうか
オブジェクト指向言語使うと
ホント迷惑だ。 >>469
俺の股間に付いてるが、本物のオブジェクト指向だよ？ >>470
そんな小さなオブジェクトは
珍しいそうな >>470
オブジェクトじゃなくて（単なる）オブジェと言ったほうが良さそうだなｗｗスペル一緒だけどｗｗｗ チンポはそれ自体が独立した生物体であり独立した人格を有する！ >>475
＞テメーのチンポはただの置物、
チンポは自らの意志で勃起してシコシコする独立生命体だが？ 池沼を装って荒らしてるんだろうけど
粘着ぶりからして闇が深いんだろうね 896 その名前は774人います (ﾜｯﾁｮｲWW 7fad-Vw6X) 2019/05/15(水) 10:20:20.32 ID:nOEC7nyk0
とあるピンクサロンで、
チンポがシコシコするしぐさを考えろ！
チンポがシコシコする踊りを踊れ！
チンポがシコシコする唄を歌え！
チンポがシコシコする言葉を吐け！
チンポがシコシコするマッサージをしてくれ！
チンポがシコシコする眼差しで俺を見つめろ！
・・・店追い出された＞涙 968 名無し三等兵 sage 2019/05/20(月) 18:01:12.00 ID:NPC01aPg
「無生物AがBする」のとき、Bは状態を表す形容詞句に限られる
「頭がズキズキする」の「ズキズキする」は形容詞句
「店に服が売っていた」も、「売っていた」を状態の形容詞句と考えれば成立しなくもないが、「シコシコする」は明らかに動詞句なので成立しない なるほど、ちんちんがしこしこするのは、口に含むと分かるんだな。 噛み千切って、喉越しも楽しんでください
胃酸で先っぽが解け落ちちゃっても、かまいません >>12
＞故人の恥部にならないよう、部屋の大人のおもちゃなどは、
ある日、チンポがシコシコしすぎて、俺はチンポに殺されてしまった！
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ 【速報】金券五百円分とすかいらーく優侍券をすぐもらえる
https://pbs.twimg.com/media/D8I_j6eVsAAJToi.jpg
① スマホでたいむばんくを入手
② 会員登録を済ませる
③ マイページへ移動する
④ 招待コード→招待コードを入力する [Rirz Tu]（スペース抜き）
今なら更に4日18時までの登録で2倍の600円の紹介金を入手
クオカードとすかいらーく優待券を両方ゲットできます。
数分でできますのでご利用下さい。 クラス機能はストップウオッチを書くためにできたに違いない・・・。（名推理
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ 言語が提供するリソースはオブジェクト指向でいいよ
僕が組むプログラムは非オブジェクト指向だよ まぁそうだね
どんな手法でも採り得るのが一番良い
プログラムスレ全体に
兎に角制限を掛けろ
みたいなのが多い
自分が得意か使える方法が使えるのが一番だ
押し付けてくるのが一番駄目
押し付けてくる奴は解っているつもりなんだろうけど
実際には解っていない様なのが多い まあオブジェクト指向は俺の股間に付いているからなあ。 なるほど、オブジェクト指向は僕の股間についています そうですか、オブジェクト指向は僕の股間についていますか つまり「チンポ」こそが、オブジェクト指向の全てを表現しているのだから！ それはオブジェ
かざりもの
小便のほかに使ったためしなし >>236
>陰茎が勃起するのは生理現象で
>本体の生命活動の一部ですよん
>独立してないっす
チンポにいくら力を入れても勃起しない、けれどもチンポに力を入れてオシッコを我慢できる。
「本体の生命活動」といっても、前者と後者では正反対である。
随意筋 不随意筋
↖ ↗
チンポ
>>123
またチンポは「本体の生命活動」とは無関係に、自分の意思で勃起してシコシコする。
チンポがシコシコすると、シコシコしたチンポが「本体の生命活動」を支配することになる。
>>12
チンポがシコシコしすぎて、チンポが「本体の生命活動」を停止させてしまうこともある。 オナニーをするからチンポがシコシコするのではなくて、チンポがシコシコするからオナニーをする！
その証拠に、
>故人の恥部にならないよう、部屋の大人のおもちゃなどは、遺族に存在が知れないように処分するように心がけています
チンポがシコシコしてきたのでオナニーをしようと思って「大人のおもちゃ」をチンポにあてたが、
チンポがシコシコしすぎてチンポが「本体の生命活動」を止めてしまった。 >>514
俺の股間に付いているのがオブジェクト指向だからな。 ちんぽがしこしこ、そんな言語表現あるのか？
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。 ワン・ツー・ワン・ツー
チンポが シコシコ
チンポが シコシコ
チンポがしっこしっこ
しっこしっこしっこしっこジョジョのジョーーーーー！
あしたのジョーーーー！ ちくわよちくわ、どうしてお穴が空いてるの～♪
チンポよチンポ、どうしてお股に付いてるの～♪
べ、べ、べ、べ、ベントマン！
チ、チ、チ、チ、チンポマン！ オナニーをしてチンポをシコシコするのではなく、チンポがシコシコするからオナニーをするのだ。
エロいことを思いついて、チンポがシコシコしてきてオナニーがしたくなって、チンポを握りしめるのだ。 チンポがシコシコするのは、チンポ自身が独立した生き物であり、チンポ自身の意思であり自己決定である。 . , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ オブジェクト指向システム開発なんてやらなくても、オブジェクト指向は俺の股間に付いているからな！ クソだから関数型の話題がちょくちょく上がってるんじゃない？ その股間に付いていた物を良く見たら、
クソだった、ってことだろJK
オブジェクト指向も、良く見たら、(ry… ﾊﾞｸﾞ率を許容するかわりに、開発速度を上げたと
そんな話は聞いた気がする
それは言語仕様というより、扱い方の問題というか
Ｗｉｎ３２ＡＰＩみたいなﾒｯｾｰｼﾞ型ｵﾌﾞｼﾞｪｸﾄ指向含んだ話
「呼ぶ人」と「呼ばれる人」がそれぞれ自分の都合で勝手に動くという考え方
それで開発効率は上がるが、全体がどうなるか把握してる人がいないという弊害
「階層」、「隠蔽」
でもやっぱりｸﾗｽ型ｵﾌﾞｼﾞｪｸﾄ指向の話みたいだな
階層と隠蔽の何が問題なんだろ
でも現代では「ｵﾌﾞｼﾞｪｸﾄ指向言語」と言う場合、事実上「継承」機能があるかどうかだよね むしろ継承機能がﾒｯｾｰｼﾞ型に近いのかな
違うものに同じ命令を出せるが、ものによって動作が違う 外国のOOP批判記事を上手に訳してくれる人もあんまりいないよね
なんか機械翻訳みたいなのはいらないわ
どっちにしてもアーリーアダプタに引っかかってOOPを盲信する社会人はもういないだろう まあ、レビューの中身がデザインパターンの選択の妥当性とかに終始して時間無くなるくらいなら、動くコード書いてた方がよっぽど完成が見えるからなぁ 綺麗にオブジェクトの振る舞いを定義できたらそりゃ有用だろうね。
それが一番難しいってのに。 >>538
デザパタとかの議論好きな人達っているよね
ネットとか業務外でやるのはおおいに結構なんだけれども、
そんな抽象化いるのかって感じで、生産性や保守性が上がっているとも思えない
事実、可読性が低くなっただけのオナニーコードには辟易する デザパタ自体の価値については言及を避けるけど
デザパタへの接し方については面白いものがある
・必要も無い人が批判する
・理解出来てもいないのに批判する
・学習過程で乱用する
・さらには本番コードを使って練習する
・（学習過程で）独自解釈して定義を拡大する
・（学習過程で）抽象化の要点を見誤る
・デザパタの目的はカタログ化と言って見せる割には
そこまでカタログとして使えてる気がしない
パターンの名前を挙げるだけでそこまでできてる気がしない
・忘れた頃に誰かがデザパタの是非を問い出す global変数の代わりにアクセサとしてのssigltonは便利だとかそういうレベルの議論ではなく
実践でデザパタって本当に有効なの？ >>534
10年後の未来にこんなブログ記事を見つけたとしても、何ら驚きはない
> 関数型プログラミング -- 10兆ドル規模の大失敗
>
> なぜ、FPから移行する時なのか
>
> FPは、多くの人にコンピューターサイエンスの重要資産と考えられています。
> コード構成(code organization)に対する究極のソリューション。
> すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。
> 自分自身をプログラムするという真なる唯一神から私たちに授けられました…
こういった人たちは「銀の弾丸」と言う古典を知らないんでしょうね >>542
ＧＯＦはイカサマ
Ｊａｖａだとクラス１つしか継承できないのにデザパタ用のクラスが親になっちゃって使い物にならない
標準ＪＲＥのObserverだかObservableだとかですらそのありさま FizzBuzzEnterpriseEditionがアップを始めたようです レプティリアンによる陰謀だったのか
さすが人間の飼い主だな >>544
継承が一つなのは当然として、そういう物はクラス内にオブジェクト取り込めばいいのだよ。 オブジェクト指向を批判してる人って、代替コードを出さないよね（笑）
関数型プログラミングなら、関数型プログラミングなら！
って言ってるだけで、代替コードは出さない。
関数型プログラミングのコードを出せって言ってるんじゃないんだ
「オブジェクト指向で書かれたコード」の代替コードだよ
同じことをする関数型プログラミングのコード >>542
> 実践でデザパタって本当に有効なの？
有効だな。例えばWindowsは、
すべてのGUI部品をウインドウとして扱ってる。
それによって柔軟な拡張性を得ている >>549
Rustが出てきた
関数型っぽくないからノーカンみたいなくだらないルールは批判されて当然 「関数型っぽくないからノーカン」ではなくて
「オブジェクト指向プログラミングを含んでいるからノーカン」
https://ja.wikipedia.org/wiki/Rust_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E)
> パラダイム
> コンパイラ型言語、システムプログラミング言語、
> マルチパラダイムプログラミング、関数型言語、
> オブジェクト指向プログラミング
> Rustはマルチパラダイムプログラミング言語であり、手続き型プログラミング、
> オブジェクト指向プログラミング、関数型プログラミングなどの実装手法をサポートしている。
オブジェクト指向プログラミングは重要ってことの証明だし
そもそも関数型プログラミングのメリットを言えばいいわけで、
それにはどのオブジェクト指向言語も理解していて、オブジェクト指向に関数型を取り入れてる。
つまりは、オブジェクト指向推進はの意見は、オブジェクト指向＋関数型推奨であり、
関数型プログラミングのメリットをいわず
オブジェクト指向のデメリットのみを言って、
じゃあ関数型では「同じ問題」をどう解決するのかを言わない輩よりも
何歩も先を進んでいる。 どう解決するのかを言う人はパラダイムではなく言語を定義するだろう
言語を定義してしまえばパラダイムの定義を言う必要はない
言語をどれにするのかを言わない輩は信用できない >>555
パターンの数なんてたかが知れてるんだから
思いついた名前を言ってみな。
これも勉強だ。 お前ら何と闘ってるんだ…
現実問題としてオブジェクト指向だけだとコードが複雑化しがちだから関数型の要素を各言語が取り込んで行ってるのが現状だろ
それぞれの良いところを利用すればええんや オブジェクト指向を標榜して
コード構造をぐちゃぐちゃにするのを止めれさえすれば
それが関数型であろうが別のパラダイムであろうが良いのであって、
オブジェクト指向 対 関数型の対立軸に論点を移してしまうと、
工学的根拠のない都市伝説みたいな屁理屈の応酬に陥ってしまうので、
オブジェクト指向の問題点を議論する際には関数型の話を前面に出さない方が良い ただ淡々とオブジェクト指向はクソなんだと
問題点を指摘してさえすればよい オブジェクト指向が向いてるモジュールとそうでないモジュールがあるだけだろ
何でもかんでもオブジェクト指向で設計する、とか
オブジェクト指向を全面否定するから、話がおかしくなる >>558
そうなんだよ。
時代は、オブジェクト指向 + 関数型 で、
オブジェクト指向言語は関数型の考えを取り入れていってるんだが、
時代錯誤な人間が、未だに、オブジェクト指向 VS 関数型だと思っていて、
オブジェクト指向はだめだ、これからは関数型プログラミングだ！なんて言ってるんだよ。
で、そういう輩は決まって、オブジェクト指向の問題点を指摘するが、
その指摘した部分を関数型プログラミングでどうやるのか？という答えを言わない。
解決すべき問題そのものを関数型プログラミングではなかったことにしている。 クラスベースオブジェクト指向３本柱のうち継承についてだけはオブジェクト指向を標榜するモダン言語でも軒並み冷飯喰らわせてるな 関数型言語でフレームワークなしにウェブアプリやゲームやシステム作れたりするものあったっけ？
結局実用的な何かを作るためにはフレームワークは必須で、オブジェクト指向ではない
（例えば継承が使われていない）フレームワークなんてあるの？ つまりバッドプラクティスとしてクラスベースオブジェクト指向としての継承を制限している言語にフレームワークは無いと言うことだねｗ
バカ「goにフレームワークは無い！！」 頭が悪い人は黙っていて。ここでいう継承というのはオブジェクト指向の考え方でいう継承のこと
言語で継承が実装されなくても、結局「オブジェクト指向のやり方」を使うわけじゃんっていうのが
言いたいことだから。 オブジェクト指向デザインパターン原則
変わるものを変わらないものから分離する
インターフェイスに対してプログラミングし、実装に対して行わない
継承より集約
委譲、委譲、委譲
必要になるまで作るな
フレームワーク（）はアンチパターンだった？！
（いや>>564が継承が使われてないフレームワークなんてないって言うから…） 継承が一つだけって、当たり前な話だよな。
同じ動詞に違う意味が被ってしまったらどっちだよってなるじゃん。 >>569
インターフェースの場合、複数あるけど、
どっちのインターフェースだよってならないの？ >>570
インターフェースを継承するならそりゃあ同じ問題が起こるだろ。 複数の親クラス（またはインターフェース）を継承したときに名前がかぶる可能性があるという
問題を優れた発想でうまく解決していたのがVB6で、
同じ動詞がどのインターフェースのメソッドなのか判別するために、
継承した場合は、継承元のクラス名をプリフィックスとしてつけるようにしたんだよ。
例えば、fooインターフェースのメソッドを実装するときは、foo_methodという名前で
barインターフェースのメソッドを実装するときは、bar_methodという名前で実装する。
こうすることで意味がかぶることがなくなるというわけ
また呼び出すときは、foo_methodを呼び出すんじゃなくて、fooクラスにキャストする
キャストと言っても、fooインターフェース型の変数に入れるだけだけど
fooとして扱いたいのだから、foo型の変数に入れるのは自然な発想
巧妙な手段で名前がかぶる問題を解決していたんだがこの発想に追いつける言語はまだ現れてないね >>572
それって集約であって継承じゃ無いんじゃね？ >>573
不思議なことを言うな。
集約のうち（ほぼ）すべての処理を親に委譲するパターンが継承だろう
集約と継承は別々のものではなく、集約の形の特殊なパターンを継承と呼ぶだけの話だよ >>574
継承は文字通り親から全て継承するから継承だろ？
集約は内包するだけだからな。
むしろ内包してるクラスのオブジェクト名を省略するのが言語仕様として許されてるだけなんじゃね？ 内包するだけで、内包したものを使わないわけ無いだろ？
多かれ少なかれ、内包したオブジェクトを使用する
その時、内包したオブジェクトのほぼ全てをそのまま使用する
特殊なパターンが継承と呼ばれるだけの話 SQLみたいにオブジェクト指向を取り入れないので継承ができないものはある
その継承できないものをそのまま使用するオブジェクトもある
継承で解決していた問題を謎のブラックボックスで解決
ブラックボックスの中身はどうなっているのか？という答えは言わない MFCは基本的な継承の親は１つだけど、シリアライズは多重継承してて、
それによってどんなクラスのインスタンスもバイト列で渡せただろ？
要はデザインセンスの問題で、凡人が手を出すところじゃないんだよ
凡人には凡人の仕事があるだろ？
背伸びすんなよ アホな言語固有の話をされても噛み合わないのは当然だよな。 固有のバグを発見する固有のテストコードを出すのは実用的だよ
代替パラダイムの代替コードを出すよりよっぽど役に立つ 言語特性を踏まえてのデザインと汎用的なデザインがあっても、継承は言語によって仕様が違うんだから、ある言語で例えなきゃ意味ないだろ？
Javaだったらクラスは単一の継承だけどインタフェースは多重継承だし ならどの言語での話か、きっちり明確にして語らないとな。 最近のオブジェクト指向では継承は冷遇されてるな。
管理がなってない機能だから、ホワイト除外だｗｗ 正方形が長方形の一種という現実のオブジェクト指向との矛盾を解消できずに発狂しそうになった過去
オブジェクトを更新できるから話がおかしくなる 長方形を継承するコストが高いだけだから
富豪的スクリプト言語なら問題ない
ゼロコスト抽象化言語も正解
どっちも否定するネガティブで中途半端なやつだけがおかしくなる 確かにrustでも継承ないな。
trait、impl組み合わせて頑張ればそれっぽいことできるけどアンチパターンだろうな。 インターフェイスをそんなに気にするならユニットテストももちろん書くよね。
それでほとんど解決だよ。
机上で考えてる奴はわからんだろうが。 ユニットテスト書くから解決ってなにが？
下手なやつのユニットテストはひどい。
ユニットテストじゃなくて、取りあえず動くコードを書く
何をテストしてるのかわからない。とりあえず動けばOKというテストコードを書くから
レビュー不可能なものになる。
それを解決するのが、適切なインターフェースなんだが >とりあえず動けばOKというテストコードを書くからレビュー不可能なものになる。
こんな奴がまともにインターフェイスを使えるわけねーだろ。
レビュー不可能になる前に一言言えや。
それでダメならプログラムかかせる方が間違ってる。 >>591
それ皮肉記事？どっちかよくわからんし、面倒くさいから要点だけ書いて 関数型をやらない自由があったから関数型の損失は出なかった
対案を出す義務を植えつけようとしても対案が全然出てこないのも自由だからだな FP is great! Invest some time into learning functional programming,
and you will be ahead of most of your peers. リンク先見たけど
関数型なら直ぐに大丈夫みたいに
最初に思わせる様に書いて有るけど
結局どうすればいいのか?
という点に全く答えてない
ただオブジェクト指向プログラミングの現在の問題点は上手く突いているとは思う
動物の例えも
本来知らなければいけない要素とは関係無い物を持ち出して来て
混乱している
というのは確かにそうだ
オブジェクト指向プログラミングは
上手く使えるとかなり効果的だけど
その効果的を得る為に必要な
手法
方法論
教育教科課程
これ等が無いのが現状一番問題でそれを
生涯学習だ
等と言っている様だね
オブジェクト指向プログラミングを活用する説明が何らかの形でそのうち出てくるだろう
と思っていたけど
現状ですら出てこないのが一番の問題で
各種言語がオブジェクト指向プログラミングから離れていっている
関数プログラミングについては知らないけど
感覚的には多くの人(プログラムする人の8割くらい)にはオブジェクト指向プログラミングより更に
使う事は出来ない
と思うな
オブジェクト思考プログラミングは活用方法の習得方法が開発されれば多くの人が使えるようになると思う
関数型とオブジェクト指向型の差はそこにあると自分は見ている ダメなヤツはmainだけで書かれたコードを関数に分割することもできない
C言語でそれすら出来ないヤツは思った以上にいる
構造体の使いどころも分からんやつもいる
ベースの脳みそがそんなのなんだから教育方法の有無は幻想だ オブジェクト指向って作りやすいクラス設計と使いやすいクラス設計が対立しない？
両立させようとすると泥沼にはまる 作りやすいが何を意味して言ってるのか分からないよな。
コピペで乱立出来るから作りやすいのか、コード量が少なくて済むから作りやすいのか。はたまた 作りやすいクラスは、抽象クラスのことを言っているのかな？
他人が作ったものをあれこれ言っても仕方ない。 作りやすいクラスなんかくそくらえ
使いやすいクラスを作ってこそのオブジェクト指向
そのためのコストは安くない オブジェクト指向はユーザーに機能の実現以上のことを提供する
データを保護し抽象依存を押し付け
ユーザー、つまりオブジェクト利用者の誤りを防ぐんだ
だが一度きりの使い捨てプログラムや時間に追われた日々の開発で
そんなこと考えてる暇が、テストしてる暇があるか？ オブジェクト指向が防ぐのはプログラマの誤りだ
悪意からシステムを守る力はそんなにない 配列と一緒に長さを別引数で渡さなきゃいけなかった時代のことを忘れない 今思えば0ターミネートよりマシだったのかもしれない そら、配列に0入れることもあるんだから
0ターミネートなんてできるわけないやろ ゼロに意味があるバイナリデータが正しく扱えない仕様はいかがなものかと。 クライアントサーバの業務アプリをよく受託するけど、
15年前にVB6で作っていた頃の生産性と
今のVB.NETの生産性を比べても
実際よくなってはないというかむしろ生産性落ちてる気がする
優秀な人がたくさん集まれば生産性上がるのかねえ？ >>616
マイクロソフトの.NET Frameworkはクラスを継承して作るというより、ライブラリを使用して作るものになっているからね。 >>616
生産性が上がらないって…どんな環境で作ってるわけ？ >>610
そりゃ単なるqueueとかstackなら使い方間違うことないだろうが、
オブジェクト指向マンセー厨がやると変に恣意的かつ複雑なインターフェイスを
やり始める。
オブジェクト指向の問題ってのはそういう詰め込みすぎなクラスを作る傾向が強くなる点だな。 >>618
どちらもやりなれていれば同じということだと思うよ。VB6.0は止まっているからやりやすい部分もある。 > オブジェクト指向マンセー厨がやると変に恣意的かつ複雑なインターフェイスを
> やり始める。
そうか？ちょっとRubyかJavaScriptで例を見せてよ >>621
一般に出回ってる枯れたコードはそういう部分は少ない。
まあそれでもpythonのpandasとかでも十分インターフェイスの統一感はないし、
結果が副作用なのか戻り値なのかわかりにくい。
オブジェクト指向信者が考えるほどこの辺のAPI設計てのは楽じゃない。 業務アプリ屋さんにとっては、同じことをやるにしても
VB.NETになってコードが膨らんだだけだもんな
.NET Frameworkが出たころはセンセーショナルに宣伝されたり、
したり顔の人がマンセー記事書いたり、そんなに凄いのかと思ったよ
でも、VB6.0の参照設定やポトペタで十分だったよ、平均的な開発者にとっては
あくまでもライブラリ「利用者側」の意見だけど >>618
今も昔もVisual Studioでしょ？違うの？ 優秀じゃない人にかぎって、オブジェクト指向言語を変に持ち上げるんだよね
職業でやってるんだから、同じことが簡単にできればそれでいいんだよ
できないのに、さもエレガントに開発できるよ、できないのは勉強不足だとか
いいだすバカがたくさん沸いて困るよな
そいつが有名なライブラリでも開発してるんならともかく >>622
オブジェクト指向は素晴らしい。
作る時間がない人は、使うだけでもいい。
使うだけなら作る問題は一切関係ない。
使うだけでオブジェクト指向はのすばらしさが分かるだろう。 >>625
> 優秀じゃない人にかぎって、オブジェクト指向言語を変に持ち上げるんだよね
罠かな？ｗ
（優秀な人 + 優秀じゃない人）＝すべての人がオブジェクト指向言語を持ち上げてる
っていうのが正解だろ？ >>616
> 実際よくなってはないというかむしろ生産性落ちてる気がする
生産性が上がらないっていうのはこういうことだよ。
例えば、パソコンを使えば電卓よりも遥かに生産性が上がるだろ？
だがパソコンを使えない人にとってはどうか？電卓のほうが速いだろう？
生産性っていうのは単に道具を入れたら、それだけであがるってものじゃない。
生産性を上げるには使う側の能力もあげなければいけない。
電卓でもなんとか検定があるように使う側が能力を上げれば生産性はあがるが
限界ってのが存在する。どんなに頑張っても限界以上あがらない。
優れた道具はその限界を引き上げる。ただし限界を引き上げるだけなので
使ってる人間が頑張らなければ、今と変わらない。
だから能力があるプロ集団の生産性は著しく向上し、
能力がない素人集団は道具を使えずに生産性が落ちることになる。
出来るところと出来ない所で差がどんどん広がってるんだよ。 責任を人が無能なせいしにして
生産性が上がらないという事実に目をつぶろうとする究極無能
この手の無能は本当に厄介
自分だけ破綻すればいいのに周囲を道連れにする 生産性を上げるにはどうするかの話やで？
道具を入れたら生産性が上がると勘違いしてるのは誰や？ どんだけVSに良い機能が追加されたとしても、
それを使わないなら、なんの生産性も上がらないのは当たり前だな 具体的にどの機能が良いの？
個人的には非接続型のADO.NETとか、メリットがよくわからないわ
昔のADOでも非接続が必要なら手段はあったし
日本の平均的なプログラマーには高度でメリットが享受できないんじゃね？
欧米は知らんけど
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ チンポがシコシコするのは、チンポ自身が独立した生き物であり、チンポ自身の意思であり自己決定である。 機械語やアセンブリ言語から副作用はあれど式を導入して(x = x + 1)手続き型言語が誕生したと考えると、
手続き型言語も機械語から数学に寄ってきた言語で、関数型言語はそれを推し進めた言語とも言える。
(手続き型言語やOOP言語は式と命令が混ざっていると考えれば、純粋手続き型言語はアセンブリ言語？)
ただ、無限ループに関しては遅延評価を取り入れた言語(Haskellなど)がさらに数学に寄った極端な例で、
OCamlやSMLみたいな先行評価な関数型言語は無限ループに関しては手続き型言語と大差無い。
以下のHaskellコードはcycleのみが無限ループの構造だが、他のコードは線形。
(先行評価では無限ループの局所化は無理)
import Data.List
import System
main = mapM_ put $ zip hellos marks
hellos = (cycle.tails) "Hello World!!"
marks = cycle ["/","|","\\","--"]
put (x,y) = do putStrLn (x ++ "\n" ++ y)
mapM_ (\_ -> putStr "") [1..50000]
system "clear"
cyycleは組込だが、定義はこんな感じ。
cycle xs = xs ++ mycycle xs そして関数型言語に足りないのは構造の記述力
手続き的なものはかけるが、それを分割構成するための
構造の記述力が欠けている。
だから大型アプリには適さない。
そして構造の技術力に強いオブジェクト指向言語は
その内部の手続の記述に矛盾なく関数型言語を
取り入れることが出来ている。 Haskellが基にした圏論はまさしく構造を記述する為に生まれた数学だが。。。
大規模開発とかはimportとかのパッケージの話じゃ無いかな？
だったら、別に言語に差異は感じないが。。。 推し進めたんじゃあなくて関数型のラムダ計算が一番最初に出来上がったんじゃあないの？
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ haskellのようなオブジェクト指向じゃない言語でも結局オブジェクト指向と同等のことをできるようにするために四苦八苦してる >>644
>haskellのようなオブジェクト指向じゃない言語でも
オブジェクト指向は俺の股間に付いているのだからな！！！ 最近クラス名で悩むことが増えた
仕事や責務でクラス分けするとうまい名前がなかなか出てこない
単なるデータクラスならこんなに悩まないのに
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ >>627
いや優秀な人は「ｵﾌﾞｼﾞｪｸﾄ指向を変に持ち上げない」ねたしかにｗ
ｷｰﾜｰﾄﾞを妙に大事する時点で文系脳というか (+) 1 2
だけどこれって、むしろｱｾﾝﾌﾞﾗっぽいような
でもｶﾗﾑが整然と並ぶ形式の方がすっきりしていい気もする
ｶﾗﾑが整然と並んでると、式をﾃﾞｰﾀ化できる
式をﾏｽﾀ登録してＳＱＬを動的発行するｼｽﾃﾑを作ったことがある
当然、演算子は全部同じ列に記述
（ 表１ 項目１
＋ 表１ 項目２
）
みたいな
こうすると、項目を仕様変更する際に、影響先を瞬時に抽出できる 業務用語が膨大にある場合は業務用語をそのまま使うな
言語開発者は膨大な業務要件と格闘する立場にないからね
さっきの式のﾃﾞｰﾀ化みたいに、実装と要件を分離する言語がほんとは必要
ＯＳも要件が膨大で、管理しきれてない様子… オブジェクト指向は好きだけどプリミティブ型禁止ルールだけは受け入れられない >>647
適切に命名して適切に分類したら設計の大半は終わりじゃないの
>最近クラス名で悩むことが増えた
ってのは難しい仕事を任されるようになったんでしょ
むしろそうじゃないとプログラマの価値が減衰してることになる
要するに分析するのが難しい複雑な仕事を任されてんだよ
書くのが仕事じゃなくて分析するのが仕事、そこが「変数名が難しい」として現れてるだけ 子供の頃に
読み聞かせや
余り親に話し掛けてもらえなかったりすると
長文を読むのが苦痛になるそうだ
弱育児放棄みたいな感じ 長文嫌悪は職業病でしょｗ
なんでこんな糞の山になってんの、っていうコード見たこと無い？
そういうのはじっくり眺めるともっと単純に素朴に表現できて
コードの行数も半分以下になったりするんだよね つまり、弱育児放棄された人間＝オブジェクト指向を使いこなせない、と
恵まれた生育環境にあるとオブジェクト指向を使いこなせる、っていうわけか
育ちの良さを測るのにも使えるな C++なんだが、必要なクラスだけ
追加で作って
使わないと思われるクラスは放置しておいて
直すという方法が手っ取り早いので、
外人さん(英国のチーム)が直すと、
あいつらドキュメント絶対に一文字も
書いてくれないでどんどん追加するから、
すぐに数十万ステップのグロテスクな
ソースになる。
今見ているのはデバッガーのソースだが、
おそらく整理すればせいぜい1万ステップ。
なのに20万ステップもある。
ソースいくら追いかけても不明だが
ひと月で直さないといかん。
首吊ろうか退職しようか
どちらかになると思ってたが、
仮病使って当分休むことにした。
懇意にしてる主治医に事情話して
診断書書いてもらった。
外人はダメ。
覚えておいて！ 仕様書があるならコメントなんて書かなくてもいいじゃん
作業指示書が曖昧でゴミなのを相手のせいにしてるだけじゃねえの
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ >>658
外人がどうのとかそういう問題じゃなくて
単に金払いが悪いからそれなりの奴しか入ってこないってだけだろ。 安直に外注に○投げてりゃ、仕事の質もそれなりだって。
単純に払った金額に応じた仕事してもらえりゃ、そりゃ苦労ないわ
それにオブジェクト指向とかAIとかバズワードふんだんに営業かけてくる口は
なおさら、それなり ところでだ。「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！ 文法的には正しいだろ
意味的にはおかしいが
俺あるいは手がちんぽをシコシコするのであって、ちんぽがシコシコするわけではない
ちんぽ.シコシコしろ()
ではなく
手.シコシコしろ(俺のちんぽ)
とするのが意味的に正しい
集約云々は前者でモデリングするべき
即ち俺とちんぽが繋がってる
ちんぽが自立して動き回ったりしない
主人が死ねばちんぽも死ぬ、即ちライフサイクルが一致する
そういった集約は特にコンポジションと呼ばれる 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
シコシコするは他動詞なので、所有者の意思とは無関係にチンポが自立行動するのであれば「イライラする」「ムラムラする」という自動詞を用いるのが正しい 555デフォルトの名無しさん2019/06/14(金) 18:40:23.68ID:at4G39ge
ちんぽがしこしこ、そんな言語表現あるのか？
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ ジンジンするやヒリヒリするは痛みを表現する言葉として、
ちんぽがジンジンするとか、ちんぽがヒリヒリするとか使うだろ？
多分シコシコも何らかの刺激を形容した言葉と捉えれば、
別に何の不都合も無い。
ではシコシコするとはどういう感覚を言うのか、そこが問題だ。 ジンジンヒリヒリは擬音語？
シコシコパコパコは擬態語？ このうどん、シコシコしてますね？
みたいな感じだろ？
きっとまんこ側の挿入感覚なんだ。 >>660
チームでやってるとレビューとかメンテの際にコメントないとまじで面倒
いらないとかいうやつはチーム開発をしたことないか、糞優秀なメンバーしかいないところなんだろうな オブジェクト指向を否定する人って普段、どんなフレームワークを使って開発しているのか知りたい。てか、フレームワークという概念すらなさそう。 >>674
オブジェクト指向とフレームワークに何の関係が？ >>675
最近のスマホアプリにせよ、組み込みにせよ、web開発にせよ、今時のフレームワークはオブジェクト思考を意識して設計がされているからね。まぁ、フレームワークに限った話でもないけど。 それはおまえの使うフレームワークがオブジェクト指向になっているだけの話で、フレームワーク自体は何らオブジェクト指向の制約は課されて無いんだがなぁ
まるで自己中な独りよがりな奴だって事だけは理解した。 オブジェクト指向ぶっ壊したDSL持ってるフレームワークとか結構あると思う >>677
何が言いたいのかさっぱりだが、
「フレームワークの設計がオブジェクト指向」ってことは
オブジェクト指向の有用性の実例の一つって話なんだが
「俺が使ってないからオブジェクト指向は使われてない！」は
間違いだって理解できるよね？ >>678
いやいや、DSLが云々じゃなくて、
フレームワークの設計の話だから >>679
俺が言おうとしたことを言ってくれてありがとう。察しが良くて助かります。
>>677
ちょっと煽られたくらいで発狂しないでくれよ...。別板だったら更にからかってやりたい気分だが、ム板民同士、仲良くしよーぜ。
オブジェクト指向ってここの人達が思っている以上に世の中のソフト開発に貢献している技術なんだよって言いたかっただけ。 >>670
>ではシコシコするとはどういう感覚を言うのか、そこが問題だ。
では質問するが、チンポは随意筋なのか不随意筋なのかどっちなんだ？ オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
https://blog.mah-lab.com/2014/03/18/object-oriented/
チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650
＜俺＞
「 部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
＜チンポ＞
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」
まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！
【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp >>683
ちんぽは俺の意思に逆らって、勃ったりり勃たなかったりするから、不随意だろ？ オブジェクト指向って構造体なんだって
ふーんなるほどね 新入社員の胸に丸いおっぱいが2つ付いてた
俺は「お、オブジェクト指向だね」そう言って乳首の先に両手の人差し指を当てた
するとその娘は「もっと手続き的にしてください」と言った
俺はC++をやめてCを書くことにした >>685
>ちんぽは俺の意思に逆らって、勃ったりり勃たなかったりするから、不随意だろ？
トイレでオシッコを出すのとオシッコを止めるのはどうなんだ？
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く おしっこのコントロールはちんぽ関係ないだろ？
女だっておしっこのコントロール出来るんだからさ。 C++のオブジェクトは、構造体と関数の集まりだけどな。
これって実装依存になるのか？ >>690
オシッコをするときのチンポは随意筋、勃起するときのチンポは不随意筋。
これがオブジェクトの多重継承というものだ。 https://ideone.com/pMPcFp
自分の知識フル活用して、こういうテストモック作ってみたよ。
これの欠点を指摘せよ。 ベースコードで80行もかかってるんだ。
俺の思ってるOOは俺には重過ぎるわ！！！ 英語が変
なにもかも変
なにがしたいのかわからない
何を目的にしているのか
確かめたいことは何なのか ちんこより一般な議論が見たかったから、物故んでみたのだ～。
まぁ、ノイズだ。 あ、確かめたいことは、俺が十数年2chで見てきた議論は合っているかということもあるな。 なんか横着な無能を上げ足とってひたすら罵りたい要求が沸き上がってきた
自分も大概だから職場でやるとやばい
あなたを罵っていいですか >>692
海綿体が充血して膨張するのは筋肉関係ないだろうにw >>703
>海綿体が充血して膨張するのは筋肉関係ない
つまりチンポはそれ自体が独立した生き物であり、チンポはチンポ自身が
独立した自らの意思で勃起するということだな。 英語的に少し疑問はあるけど、それはいいとして...
>>693
SetMessagerとGetMessagerはMessageオブジェクトを受け渡しするものなんだよね？
どっちもMessageという名前で実装した方が覚えることが少なくてオブジェクトを使う人にとって分かりやすい気がする。
引数あり→Get,引数なし→Set
あなたは違うかもしれないけど、オブジェクト指向を理解したての人は何でもかんでもGetXXX,SetXXXというメソッドを用意しようとする傾向があるので注意。
絶対だめとは言えないけど、乱用すると変数をprivate化する意味が薄れるケースがある。
...といっても、このコードだけだと自分のアドバイスが的を射ているかは微妙で、なんとも言えぬ。 >>707
普通にtipoしたのと、オブジェクトのとらえ方の問題かも。 >>708
構造的には、Podderはシェアードオブジェクトになっていて、橋渡し。
HighPodderはメッセージの書き込み権限を持っていて、主観に一つ持つ。
会話の発話者のような感じ。
とあるときに、OOは通信が必要なのだ。
と、熱弁していた人がいたのを思い出したので、
通信オブジェクトで自分の例では全二重通信になってる。 >>712
>HighPodderはメッセージの書き込み権限を持っていて、主観に一つ持つ。
会話の発話者のような感じ。
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>703
>海綿体が充血して膨張するのは筋肉関係ない
頭に血が登るというが、チンポに血が下るとはいわないのか？ おしっこ止める筋肉にちんぽ関係ないだろ？
括約筋どこにあるか調べてから書けよ。 >>715
>括約筋どこにあるか
チンポの一部だろう？ >>715
>括約筋どこにあるか
おしっこをするときのちんぽは、括約筋と尿道を通じて、本体と繋がっている。
勃起するときのちんぽは本体とは離れて、チンポ自身の意思でチンポに血が下る。 だから、おしっこを止める為の筋肉は、ちんぽとは切り離して考える方が合理的なんだが、
…が、しかしおしっこを排出する末端機関の種別によって許容範囲…即ちパラメータの上限値に違いが出て来るんだが、これは末端機関自身にパラメータを持たせるべきか否か。
まあ、基本クラスから継承されたそれぞれのオス型メス型のクラスを作るのが無難だな。
あと、入出力処理機能としてクライアントかサーバーかの設定も同時に継承されたオス型メス型で一意に決定する…と。 >>720
>おしっこを止める為の筋肉は、ちんぽとは切り離して考える方が合理的なんだが、
おしっこが出るのはチンポなんだが？ チンポが尿を止めたり出したりするのは、『尿道括約筋』を通じて本体と繋がっているためである。
しかしながら勃起するときのチンポはチンポ自身が本体と切り離された自分の意思で充血して勃起する。 >>721
だから、何で男限定なんだよ。
もっとオブジェクト指向しろよw 例えが卑猥すぎて断片的にしか読んでないけど...
階層構造やカプセル化の考え方も取り入れた方がいいと思うよ。
君はトイレで糞したり放尿する際にチンXを操作するわけだが、いちいち筋肉の働きとか意識しないでしょ？ この際、放尿機能にのみ着目して、エスイーばつに関する機能の話は除外しようず。 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↓ ↓ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/j3uTk1K.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 ちんぽがしこしこして、ちんぽがしこしこしすぎて『帰らぬ人』となってしまった！
「大阪にいる愛人とラブホテルでコトに及んでいる最中に、体調を崩して、そのまま帰らぬ人になったんです」
いわゆる「腹上死」である。しかもこの事実が週刊誌の記事で大々的に報じられてしまったのだ。
明るく気さくな性格で、人望も厚かった音羽山親方だけに、その死因は世間に大きな衝撃を与えた。
https://gendai.ismedia.jp/articles/-/66956
これがハッピーエンドというものだ！ 引数を使わず
ローカル変数を使わず
戻り値を使わず
すべてをインスタンス変数に設定して
メソッドを分割しまくってるソースコードを眺めてる
これが君たちの言うオブジェクト指向かね！？ >>571
>そんなくだらない事にコスト費やす前に広場BANした方がマシだわw
でもこっちではBANにならないぞ？
！
ぜ
る
す
コ
シ
コ
シ
が
ポ
ン
チ ン ポ が シ コ シ コ す る ぜ ！
ン
ポ
が
シ
コ
シ
コ
す
る
ぜ
！
他人のことはとやかく言っても野暮なんで、俺は俺のやりたいようにやるだけだ！ >>732
>これが君たちの言うオブジェクト指向かね！？
オブジェクト指向は俺の股間に付いているが？
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′ 批判する人の方が詳しかったりするから聞くんだけど、
オブジェクト指向って簡単に教えてくれない？
利点と短所も。
思想は良くても実際はうまく機能してないことって多いから オブジェクト指向はフレームワークやライブラリを作るのが楽
フレームワークやライブラリを使わない人にとっては使うのが楽 >>741
>オブジェクト指向って簡単に教えてくれない？
では聞くが、「チンポがシコシコする」という日本語表現は、文法的に正しいのだろうか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ >>743
自動詞と他動詞の違いでしょ
中学校で習うじゃんwww >>741 批判的な視点で見ている者ですが、簡単に述べます。
「オブジェクト指向」の本質は、オブジェクトまたはインスタンスに紐づくようにした
スコープを持つプロパティー(インスタンス変数)やメソッドを使い、継承や多態などを
組み合わせてプログラムを構築していく方法だと捕らえています。
利点は、オブジェクトに関連し必要な機能やインタフェースがオブジェクト自身に
関連付けられているため、データ（オブジェクト、プロパティー）と処理の一体化が図られ、
見通しのようソフトウエアの構築などの面に色々と役立つ筈だった(あえて過去形)と思います。
欠点は、特に型クラスと継承を使うスタイルのオブジェクトでは、複合型したデータ構造において
メンバに対するアクセス制御とアクセサによる穴あけが局面によって融通が効かず、
階層的でシンプルなスコープ管理に劣ること、複合型したデータ構造の継承が
入り組んだ依存構造を作り出し見通しが悪く解読やデバッグのしにくいプログラム構造を
形成しがちなこと。動的に生成したオブジェクトが広範なスコープ・extentを持つ
データの集合体のような役目を持って一人歩きし、アクセサや多数のメソッドcallを繰り返して
各階層を行ったりきたり、本来シンプルになるはずだのプログラムが、なにやってんだがわからなくなることなど
欠点多数です >>748
それは一般化過ぎて一言で言える解にいたるのは非常にムヅカしいと思います。
オブジェクト指向が有効な場面もあります。レイヤや応用、場面によって変わってきますし…
私としてはレイヤと用途によって向いたパラダイムを分けて考えていますす
・最内・最下位レイヤはオブジェクト指向の出番はまずない。手続き的な記述
あるいはリストや再帰を使うならfunctionalで宣言的な記述が適している
･中間レイヤ；特定のコンパクトなデータ構造に対するまとまりのある処理を表現する場合は
オブジェクト指向が有効な場合もありますが、従来からある静的・階層的な
スコープとextent管理および、機能をパッケージまたはモジュール化する機能階層分割による構造構築
・上位・アプリレイヤ：複合型化オブジェクト指向は記述に適さず、従来からある静的・階層的な
スコープとextent管理および、機能をパッケージまたはモジュール化
以上は個人的な考えです >>749
非常に論理的な否定派ですね
ありがとうございます オブジェクトの多態性って言うだろ？
>>746
>途中からちんぽがちんぼになってる
チンポが棒になってしまった、これは肉棒だ！
(チンボ)
チンポは俺のムスコだ！
(チンコ) >>749
>スコープとextent管理および、機能をパッケージまたはモジュール化
抽象論では意味がないので、トイレに行って、チンポに力を入れたりチンポから力を抜いたりしてみよう！
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>751-752
そうすると女性はオブジェクト指向できませんね… >>744
>自動詞と他動詞の違いでしょ
では聞くが、チンポは随意筋なのか不随意筋なのか？
随意筋 不随意筋
↖ ↗
チンポ
『継承』は、サブクラス➡スーパークラス！
オブジェクトの『属性』とは、そこのお前は一体何者なのかという問いかけであり、
オブジェクト間メッセージングとはまさに自我とチンポの二人称対話に他ならない。 >>754
チンポの大部分は海綿体という組織でできてて興奮することによって血液が流れ込んで勃起するっていうのは中学校の保健体育で習うじゃん 国語でも保健体育でもそうなんだけどドメインに関する基礎知識が不足してて適切なオブジェクトを設計できないだけなんじゃないかな
プログラミングの手法を語るのはまだ早いよ >>755
>チンポの大部分は海綿体という組織でできてて興奮することによって血液が流れ込んで勃起する
チンポは『独立した生き物』であり、従ってチンポは自らの意思で血液を吸い込んで勃起する。 チンポの話してる奴、オブジェクト指向とかちゃんと理解した上で、頭良いこと言ってれば面白いのに、言ってることがクソ馬鹿だからつまらん >>761
頭良くても、同じことを何度も繰り返してるだけだと
クソレスでしか無いよｗ >>760
チンポはオシッコを止めたり出したり出来るが、心臓は血液を止めたり出したり出来ない！ >>761
>オブジェクト指向とかちゃんと理解した上で
オシッコのチンポと勃起のチンポ、これがオブジェクトの多態性である！ だらだらっとプログラムを書くと大体1000行ぐらいで
訳が分からなくなる。言語は問わない。
ある方法論の下でプログラムを書いた方が破綻することが少ない
その方法論の一つがオブジェクト指向だ。
だが、オブジェクト指向ですべての問題が解決するわけではない。
使わないよりはましというだけ。現在のところオブジェクト指向よりも
ましな方法論がない。それだけの話だ。
巨大 and/or 複雑なプログラムはどういう方法論を使っても
しょせん無駄だが。いわゆる天才待ち。 >>760
心臓にはメッセージング出来ないが、チンポにはメッセージング出来る！ >>766
>ある方法論の下でプログラムを書いた方が破綻することが少ない
>その方法論の一つがオブジェクト指向だ。
オブジェクト指向は常に独立指向であり、メッセージングとはオブジェクト間の二人称対話である！
心臓とは対話出来ないが、チンポとは対話できる。それでいてチンポは独立性を失わない！ つまりオブジェクト指向とは、俺の股間に付いているモノなのである！
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′
チンポは独立した生き物であり、本人の意思とは無関係に、自らの意思で勃起してシコシコする！ >>770
まぶたがまばたきするのは条件反射だけど、チンポが勃起するのはチンポ自身の意思決定である。 >>770
>>772
まぶたは条件反射でまばたきするだけなので、オブジェクト指向のような知能回路は必要無い。
対するチンポはもう一人の自分であり、自ら考える知能回路が不可欠。
>>745
>欠点は、特に型クラスと継承を使うスタイルのオブジェクトでは、複合型したデータ構造において
>メンバに対するアクセス制御とアクセサによる穴あけが局面によって融通が効かず、 >オブジェクト指向ってクソじゃねぇかよ
チンポには知能回路が不可欠だが、まぶたには必要無いな。 オブジェクトは自立して動くものというのが理想だったからな
現実は自立して動かないから指示系統が複雑化してヤブヘビに
という訳で切り離すべきはモノじゃなくて処理という観点から軽量プロセスや関数型が注目されると >>777
全部違う
wikipedia見たがいい >>745
肯定派に発言権があるかはわからないけど、オブジェクト指向の利点はもっとシンプルだと思います。
そういえば、スレタイは オブジェクト指向はクソ でしたね。では、糞で例えます。
非オブジェクト指向
kusoDasu1();
kusoDasu2();
kusoDasu3();
※一見、短いコードに見えるが...3つの糞を生むために、3つのkusoDasu関数を定義する必要がある。
オブジェクト指向
Kuso kuso1 = new Kuso();
Kuso kuso2 = new Kuso();
Kuso kuso3 = new Kuso();
kuso1.Dasu()
kuso2.Dasu()
kuso3.Dasu()
※3つの糞を生成するために、1つのKusoクラス一つ定義だけで済む。
一つの関数を使い回すのでブレークポイントを張っても馴れないと分かりにくいのはあると思います。でも、可読性やコーディングのしやすさという観点ではどうでしょうか？
一つのクラスを定義しただけで糞を簡単に量産できるんですよ？
3つの糞なんてケチ臭い制約はいりません。メモリが許す限り、アンリミテッド・糞・ワークスができるんですよ？
しかも、継承を使えば...
Kuso kuso1 = new Poo();
Kuso kuso2 = new BananaKuso();
Kuso kuso3 = Ore.Dappun();
kuso1.Dasu()
kuso2.Dasu()
kuso3.Dasu()
このように様々な糞を様々な方法で生成できます。どうでしょう？オブジェクト指向の良さを理解していただけましたか？ む...なんか、糞が糞を出しているみたいで微妙な例だった...。
糞が出来ることは臭いを放つくらいなのに...。 >>779
なんでデータごとに別名で同じ内容の手続き用意するんだよ
共有関数って概念を欠いてるのか。
別名で同じ内容の手続きを展開することに対する継承の利点を主張しても
この例だと委譲に対する継承の利点はなんら現れてこないし。
オブジェクト指向以前に、プログラミングの入門のｲﾛﾊﾉｲから勉強すべきだよ
肯定派ってこのレベルでオブジェクトが良いだの何だの言っているのか… >>781
え？何いってるの？
非オブジェクト指向のプログラムってこんなレベルのプログラムのことでしょ？
是非、オブジェクト指向ではないプログラムで君の書いた素晴らしいコードを公開してくれ。 共有関数がーとか言うけどさ、関数を共有化させたところで、内部的にはグローバルstatic変数を使って実装することになるのでは？
非オブジェクト指向で必要なモジュールの数を可変させるのが面倒であるという事実は変わらないと思うよ。
もちろん、static変数を使わずに
struct X;
InitX(X);
UpdateX(X);
みたいな記述もできるけどさ、それってC++言語が選択できなかった時代のC言語組み込み開発におけるオブジェクト指向の実現手段になってしまうよね。かなり原始的だけど。 なんや？また言い返せないからって
ばーかばーかって言って勝ったつもりになってんのか？ｗ いやだからfacytory関数とオブジェクト指向を同一視し過ぎだって
池沼かよ それ以前に、lexical scopeとextentがどうしても非同期にせざるを得ない場合を除き、
動的・非階層的にデータ構造を生成してややこしい状態を一生懸命管理するのは避けて、
なるたけextentとlexical scopeを対応させ
階層的、静的、組合せ回路的構造でプログラムを構築すれば
大規模で複雑な構造も表現できるというのが
現代computer scieneの基本セオリの1つだろうに
この愚か者が なんか、ごめんなさい。
夜も遅いので池沼お兄さんは寝ます。 >>789
ﾁｿﾁｿこすって、すっきりして
グッスリお休み。ﾉｼ
いい子だからこれからはよく勉強するんだよ。 >>788
言ってることが意味不明だ。
どれくらい意味不明かというと、歴史教師が歴史の授業で長篠の戦いについて説明をしていたら生徒が突然、机を叩きながら席を立って
「先生！織田信長と火縄銃は別物です！(キリッ」
とか唐突に言い出すくらいに意味不明。
当たり前過ぎて何が言いたいのかわからん。
>>789
staticおじさん乙。いつの時代の話だよ。
>>791
staticおじさんかと思ったけど、言動が幼すぎる。 訂正。
当たり前と言うのは、factory関数とOOJが別だと言う話な。
というか、同一視って何？どこからそんな話が出た。 でもオブジェクト指向は俺の股間に付いているからな！ ぼくの両乳首はオブジェクト指向
それぞれ独立していて小気味よく動作する
一方をつねるとその入力は脳に伝わる
そして口から嗚咽を出力するのさ
年を取ったらピンクの乳首を継承して黒乳首になる
実装によっては乳液だって出るのさ ちんぽはちんぽそのものが独自の知能回路を有しているのだからな。 896 その名前は774人います (ﾜｯﾁｮｲWW 7fad-Vw6X) 2019/05/15(水) 10:20:20.32 ID:nOEC7nyk0
とあるピンクサロンで、
チンポがシコシコするしぐさを考えろ！
チンポがシコシコする踊りを踊れ！
チンポがシコシコする唄を歌え！
チンポがシコシコする言葉を吐け！
チンポがシコシコするマッサージをしてくれ！
チンポがシコシコする眼差しで俺を見つめろ！
・・・店追い出された＞涙 >>792
意味が不明なら黙ってりゃいいじゃん
オブジェクト指向の利点を解くならいざしらず
揚げ足とってけちつけてるだけ >>789
staticおじさんこんなこと言ってたっけ… staticおじさんの要旨はこれかな?
ttps://ryoasai.hatenadiary.org/entry/20110702/1309600182
>・コードを共有化すると、共有しているプログラムを修正した場合の修正の影響範囲が広がってしまう。
>・機能ごとに似たようなコードをコピーし、独立したプログラムとして開発すれば、それぞれ独立して変更できるからメンテナンスが楽。
>・コピペを中心とした開発であれば開発担当のPGのスキルも低くてすみ、外注コストも削減できる。
>・ホストからのダウンサイジングもある程度進んでおり、今時フルスクラッチで新規開発する案件は少なく、2次開発案件では部分的なコピペで機能を追加できれば十分。
>・だから、小難しい理屈を使いこなすような達人プログラマーなどは不要であり、若いうちにSEやPMになることを考えた方がよい。 あるいはこっちかな…?
ttps://qiita.com/minebreaker/items/45ffaaa5e8729e16cfb4
このサイトを見るとオブジェクト指向厨がstaticおじさんの発言を
無理と悪く受け止めてミスリードを誘うような批判は行き過ぎととらえ
>この記事で言いたかったこと
> 複雑さはそれ自体害悪である。単純なのはよいことだ。
> 「なんか新しくてすごいテクノロジー2.0」を知らないからといって、劣等感を感じる必要はない。シンプルで簡単で使いやすいツールを選べ。
> プログラミング業界の「常識」「あたりまえ」「みんな使ってるよ」を鵜呑みにするな。自分で考え、最適な技術を選べ。
> 誰かを馬鹿にするよりも、他山の石として研鑽に励もう。
大人だな。
必要もないのに動的インスタンスの生成をするのではなく
ネスしたスコープやエクステントに任せてスマートポインタを使うなどの良いのは
ま、真理だわな >>800
なんでここまで話がまがってこじれたんだろうね
売り言葉に買い言葉で論点が暴走したときの話を
面白おかしくみえる角度の切り口でネタ化したんだろうか
しらんけど ttps://video.twimg.com/ext_tw_video/1172343538832379904/pu/vid/640x480/HpRdIcr00S8_pdXC.mp4 >>806の書き込み見て>>800を
読んでみたら俺も笑えたw
まさしくそんな感じの
「おれさまはC++のプロだからな」
と自慢しまくってた旧エニコムの
臭いブタを思い出したよw
そのブタのコードが>>800そのままwww >>800に同意している人も反対している人も
現場でやってることに大差はないんだろうね まあ、似た様な仕様をまとめてひとつの処理にしておいて、やっぱ機能違うってなってから分ければいいだけやん。
メンテナンス考えたら至る所に似た様なコードがあって、仕様改定したら全部直して回るなんて方が大変だしな。
中には同じ機能なのに実装が微妙に違うから更に面倒とかあるしな。 ちんぽはちんぽそのものが独自の知能回路を有しているのだからな。
他の臓器とは全く違う！ このスレってオブジェクト指向・肯定する人と否定する人の割合ってどれくらいなんだろう。
あと、普段は何の開発を何言語で開発しているのかも気になる。 >>810
そこだよ
後から分割できる文化がありますか？
っていうのがこの問題に対するスタンスがわかれた理由だと思うよ
で、共通部分を修正した場合の影響範囲を考えたらやっぱ共通にするのはリスクだよねって話になる
つまり、共通化した部分って絶対変更しちゃダメなんだよ
変更する場合は別関数つくってhoge_exって関数にして修正が必要だったところだけ新関数を呼び出すようにする
そんなことを繰り返している間に>>800になる 規模が多けりゃオブジェクトが断然だが、そもそもそのレベルの規模に合わないからな日本のプログラマは ある意味、>>800 staticおじさんの「コードはコピペで何とかしろや、共通部分増やすと変更時の影響がでかいだろ」は素直な意見なんだなーって思う。
そして、この現象(共通部分が増えると変更時の影響がでかくなる...というか、大変になる)が起きるのは共通部分の仕様が不透明だからだと思う。
コードを見て使われているstatic変数の真の意味をプログラムから察する必要があるわけだし。
オブジェクト指向であれば、オブジェクトが要求するオブジェクトの仕様を明確にする仕組みがある(しかも言語レベルでサポート)のだが、非オブジェクト指向だとこれと言った方法がないからね。
staticおじさんの困りごとは本当に、素直な意見だなーとは思うのだが、なぜ、そこまで課題に気がついているのにオブジェクト指向を採用しないのか、とは思うね。 >>816
いや、すまん。まぁ、あなたの言うとおりstaticおじさんのやり方だと、とある問題を解決するために別の問題を発生させているわけだ。 >>815
>オブジェクト指向であれば、オブジェクトが要求するオブジェクトの仕様を明確にする仕組みがある
オブジェクト指向は俺の股間に付いているからな！ なんでＤＲＹとオブジェクト指向の話がごっちゃになっとん >>819
誰もお前のオブジェクトなんて要求してねぇから(辛辣)
まぁ、オブジェクト指向なら、「私は太いチンコを要求する！」「私は何でもいいからチンコを要求する！」「私は君のチンコを要求する」といった感じで人間にも分かりやすい仕様を明確にすることができるけど...
もし、ソフトウェアモジュールの分割の単位を考えないで設計をすると...「酸素原子n個、炭素原子n個、水素原子n個...のチンコを要求する！」みたいな感じで細か過ぎて要求するものが何なのか人間の感覚では分かりにくくなることはあるね。
分割の仕方は他にも色々あるんだけど、自分が知る中ではオブジェクト指向の責務分割が一番、人間にとって理解しやすいと思う。 信頼性の高いソフトウェアを開発して、開発そのものを簡単に理解したりメンテナンスできる
ようにする唯一の方法は、DRY原則に従うことです。
すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。
https://qiita.com/yatmsu/items/b4a84c4ae78fd67a364c >>821
>要求するものが何なのか
オブジェクト指向とは、『独立した知能回路』のことであり、チンポはまさにその最たるものである！ >>821
>人間の感覚では分かりにくくなることはあるね
チンポは人間の感覚では分かりにくい不思議な生き物だから。 >>812
批判派です
最近は主にpython, C/C++, Perl、VBA
たまに MATLAB, Skill(Lispの一種）, Javascript, VB, R, かつてFortran、javascript
趣味でかじった程度が Haskell, SM/L, Racket, OpenDylan
ほか
そいや最近Javaの案件もやった。 >>822
つまり知識が別なら別でいいから
つまりだ
設計書が別なら共通化する必要はないんだ！ MATLABで金もらえる仕事ってどこで何やってんだ？！ >>822
>開発そのものを簡単に理解
つまりオブジェクト指向は、俺の股間に付いているということだな。 >>825
javascript二回書いちゃった。
あとPHP, assembler, 一部CPUの機械語などもやってた
開発対象はかいつまむと
主にエンプラの統計解析DB、機械学習、製造工程管理、
並列シミュレーション(非線形構造、原始・分子軌道、プロセス)、CAGD, モデルベース、
組み込みも少々、R関係、ロボット関係、IoT、Edge など 今までかかわった開発で規模の大きかったソフトは一千万行のLispプログラムの拡張
二番目が35万行のFortranで書いた数値シミュレーション×二件、20万stepC/C++/FortanのCADソフト
最近プロﾏﾈやっている案件がJava10万行＋サービス部がC16万stepの移植、検証
他の案件の規模は高々数万～10万stepくらいだったかな。
自分自身で沢山CDした言語はCが40万step以上もっとかも、Fortranが10万step以上かもっと、
python, perl, C++ がそれぞれ2～3万step程度、Javaなど他の言語は1万step未満だと思う >>825
Java,javascript,python,VB
ここら辺はガッツリ、オブジェクト指向のパラダイムを取り込んでいると思うけど...どういう経緯で批判するに至ったのか気になる。 >>821
>人間の感覚では分かりにくくなることはあるね
チンポがシコシコするのはチンポが独立した知能回路を有しているからであり、
人間の感覚では分かりにくくなることはあるね。 >>830
このJava10万stepがオブジェクト指向の悪い面が思いっきり出ていて最悪のコードで、
移植拡張しようにもJava勉強してきた若い人の手におえなくて、仕方ない
俺はjavaやらないんだけれど、なくなく自分でじきじきにプログラム構造解析して移植、拡張した。 >>831
SmalltalkやC++などはストラウプの1.2の出たかなり昔から断続的に勉強してきたし、
自分自身プログラミングは若い頃から得意で(息をするようにというのは誇張だけど)自然にすらすら書ける方だと思っていたけど
そういう言語のオブジェクト指向の機能を使って開発したときに、プログラムを構成する手段として
表現しにくいなーという実感が拭い去れなくて、疑問視するようになっていた違和感がまず下地にある。
そこにネットバブルのときにJavaのオブジェクト指向が流行して、だんだん工学的な視点から外れ話が広がり、
アクセス制限してgetter/setterカプセル化だ、継承で抽象化だｗ、デザパタのレビューだシングルトンで
グローバルインスタンスはべんりだｗ、ダイナミックにnew/deleteして動的だ、機能強度の弱い
SN比の低いmetod calｌを各階層上から下まで行ったりきたりしてに状態管理やってんだかなんだかわかりにくいから
シケンス図だ、UMLの資格取得だ、CMMIだって、もう都市伝説みたいな科学的根拠のない話に
どんどんずれて行って、それだけならまぁ笑い話で勝手にやってくれりゃ良かったんだけれど、
それに触発されたアホがソフトウエア開発の基礎も勉強せずに、都市伝説の宣教師みたいになって
長久にプログラムすら組めないのに開発者の方法論にクチ挟んで屁理屈見たいな批判言ったり、
免疫のない若いエンジニアをたぶらかして結構流行してしまって、その結果ソフト工学的観点からみて
まずいつくりのグチャグチャのコードが量産されてしまい、実害があると実感にいたった
一見理解しやすく説明され一度はやってしまったものは、もう一人歩きが停まらなくなって
軌道修正できない段階にはいっているんだと思う >>835
>一見理解しやすく説明され一度はやってしまったものは、もう一人歩きが停まらなくなって
>軌道修正できない段階にはいっているんだと思う
では聞くが、「チンポがシコシコする」という日本語表現は、文法的に正しいのだろうか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ 手メコっていうくらいだから日本語としての主語は手である。
お前のチンポは皮で窒息して既に死んでいる。
以上 だめだ
頭と認識がぐちゃぐちゃで話にならんタイプだ
かかわったプロジェクトの行数以外のこともちっとは整理しる >>827
トヨタとか系列のデンソーとかその辺りかな
ガチガチで入り込む余地は無いから諦めな 関係が強固で一見さんが付け入る隙のないさま
言われなきゃ分からないのかよ >>846
松坂慶子
このｽﾚとは関係のない個人的なメモ
似たようなことやってたことがあって懐かしくて
検索でたまたま見つけたURをメモ代わりにここに貼っただけ
ああそうさ2chは俺のメモ帳さｗ >>835
オブジェクト指向以前に、階層化の考え方があったと思うが...
オブジェクト指向は階層化と組み合わせると下位階層のデバイスドライバやハードアウェアとの責務分割が明確になる。
そして、上位階層の開発をする人は、それらの内部的な振る舞いを全く意識しないで開発できるようになるのだから、工学的な話が無くなるのは当然と言えば当然だと思うよ。
コンピューターの仕組みに翻弄されて本当に実現したいものを実現できませんでした。を避けたい人がオブジェクト指向を採用するわけだし。
ただ単に、分割するだけなら階層化の考え方だけで充分だが、 ぎゃー！書いてる途中に送ってしまった...休み時間が... オブジェクト指向がクソに見えるのは、ただ単にサンプルにするコードや書き方の問題だと思う。
Githubにアップロードされているコードや、GoogleやMicrosoftの社員が書いたコードとか見てみた方がいいと思う。
日本だと、SONYやSEGAの社員が書いたコードも見たことがあるが、流石プロって思える実装の仕方がされている。
まぁ、実際に様々な企業と仕事していると信じられないくらいクソ設計がされているプログラムを目にすることはあるんだけどね。
グローバルデータクラスとか言う有象無象のグローバル変数をオブジェクト化した謎設計を見たときは「あっ、こいつオブジェクト指向を誤解してる」って思ったよ。
まぁ、それでもオブジェクトと言い張ればオブジェクトなんだけどさ。 ・・・というわけで、
>>851
>「あっ、こいつオブジェクト指向を誤解してる」
オブジェクト指向は俺の股間に付いているのだ！ 時代のトレンドがオブジェクトからモジュールになりつつある >>851
難しいところをただ単にと言い捨てて簡単なことように摩り替えるのはごまかしの詭弁だよ。
企業の業績だってただ単に収益を上げさえすればいいわけだし >>848
工学的なというのはデバイスとかハードアウェアの「物」ではなく
ソフトウエア工学の扱う「事柄」の管理工学だろ誤解を抜きにしても
書いていることが机上の空論にみえてしまう ID:tIcrQX1Y は会社でも「ただ単に」が口癖で
日ごろから詭弁こいて紛糾を招き、
無駄に会議長引かせたり、まわににめいわくかけてそう
ディベートごっこなら別の板でやれば？ >>851
SONYやSEGAとかの公開用に練り上げられたサンプルは
担任のふんどし、一般性はない。
ましてや、あんた自身がオブジェクト指向によって
大規模複雑なシステムを
常に速やかに設計、開発 出来ていますよと、
そして>>835のような苦しみはオブジェクト指向によって解消されますよと
責任を持って言わないと説得力０
責任を持って。
そうじゃないなら、茶多入れ不要なので半永久的にROM化どうぞ いやだからそこは単にオブジェクト指向をやればわけだし。
士ねって感じ >>858
え？そんなことないでしょ。
SEGAやSONYは知らんけど、MicrosoftやGoogleは普通にオープンソース公開しているよ？
お前こそ恥ずかしいから一生ROMれば？ そして>>835の苦しみって何？
ソフト屋なら、もう少し具体的な質問をしたら？
それ以前に、>>835は質問するつもりで書いたのか疑問だが。 オブジェクト指向プログラムを読み解こうなんて無茶だよ
何のためにUMLがあると思ってるの >>867
何のためにUMLがあるのか、と聞いているのですが あ？
読み解け無い様な複雑なコードとか、逆にオブジェクト指向になってるか疑うわ。
単一部位の独立機能をひとつのオブジェクトにするんだから、たいていのオブジェクト指向のソースコードは読み解くのは容易なはずなんだけどな。
他のオブジェクトとの絡みとか協調動作し出すと途端に理解不能になるのは人間関係と同じで沢山のオブジェクトが色々絡み出すと読み解け無くなるのは、読み方を間違えてるからさ。 >>867
少なくとも、staticマンの書いたプログラムよりは読める。 せっかくオブジェクト指向使ってんのに静的クラスやメソッドのオンパレードな作りにする奴ってなんなんだろうな クラスは常に静的だろ。まさかクラス定義そのものが動的に変わる様なシステムなんか人工知能でもないと扱えないわ。
多分動的オブジェクトの話だと思うが… >>868
静的構造と動作を記述するため
>>869
クラス単位なら単一責務なんだから読みやすいよ
ただクラス間は抽象化で依存が断ち切られるから追えなくなるから、その為にクラス図を描く
逆にサクサク読めるコードの方が抽象化甘くて怖いわ >>869
>単一部位の独立機能をひとつのオブジェクトにするんだから、
俺の股間に付いているな！ >>871
職場にシングルトンパターンを乱用する人とかがいて困った事がある。
オブジェクト指向がクソというより、経験の浅いプログラマーがプログラムを書くからそうなるんだろうけどな。
自分も昔、似たようなコードを書いたことがあるし。
まぁ、誰もが最初は初心者だし、仕方がないとは思うけどね。
静的クラスマン、シングルトンマン、どっちも学生の頃に経験済みさ。 治りかけたリファクタ病の古傷を無理やり引っ張ってこじ開けるようなコード見てしまった
いままでも見てたけど意味考えてなかった
わかったらひどい
オブジェクトのメンバをグローバル変数代わりに使ってるすごくよくある勘違い志向のアレ 一箇所で管理してる分には些細な使い方の間違いは気にしないでいいよ。 >>875
やっぱり只の静的オブジェクトの話じゃん。
反対語を当てはめたら全く意味が分からない様な造語はやめて欲しいよな。マイクロソフトさんよ。 ふざけんな
おまえ自身は自分のオブジェクト指向もどきが読めないの
人のせいにしてるじゃねーか
現実逃避するな
おまえのコードは読みづらいんだ >>876
>オブジェクト指向がクソというより、
オブジェクト指向は俺の股間に付いているということだなw >>865
いちいちつられて朝から顔真っ赤
ご苦労さん >>883
privateちんこは誰にもアクセスされずに腐る運命 オブジェクト指向の間違いを学んだだけで正しいオブジェクト指向を理解した気になってる人多いよな
シングルトンクラスの多用は良くない
↓
シングルトンクラスはプロジェクトで1つだけにしよう
↓
神クラス誕生
こういうこと平気でする それはフン
よってもって
オブジェクト指向は
フン
クソ以下フンのパラダイムでソフトウエアの開発に
だまされて
日々不毛ななデバッグという名の限りないExcel梅梅作業に取り組む
非正規市民乙
詰んどるな日本のIT企業
おまえら、だまされるなよ、そいつらの吹聴するオブジェクト指向とやらに
そうじゃないと人生棒に振るぞ じゃスレタイ変えないとな
「オブジェクト指向って糞(フン)じゃねえかよPart4」 >>879
>>870や>>871に対してクラスは常に静的とか言い出しませんでしたか？
あとMicrosoft関係ないから。グローバル変数ってMicrosoftが考えた仕組みだよね並みに間違ってるから。 >>889
お前が使ったことある言語と開発内容を晒してみ？
開発内容は、PCソフト開発なのか、スマホ開発なのか、WEB開発なのかレベルでいいよ。 >>886
実質グローバル変数のstatic邪神クラスですねわかります。
こういう勘違いオブジェクト指向コードを渡されて開発させられる人達って可哀想。人権無さすぎ。
>>835の長文もよく見ると、似たようなことを言ってるし、>>851も同じこといってる。
static邪神による被害者とstatic邪神を生み出すstatic教団のstatic教祖様に苦しめられている人は少なくないのかもね。
あと、関係ないけど...>>891はスルーして頂戴。揚げ足とってるだけな気がしてきた。 フン族のアッティラは最強
あまりにも強すぎて「堕落した人に神が下した罰」と言われていた
つまり、オブジェクト指向は堕落したプログラマに神が下した罰なんだよ >>891
静的なオブジェクトしか生成出来ないクラスであってクラスそのものは常に静的な存在なんだよ？
つうか、クラス≡コードで実行時のワーク≡オブジェクトだから、クラスは常に単一な存在。
わかった？ >>885
チンポは自分の意思で勃起する、チンポは誰の指図も受けない。 >>896
うそだ！
Ｊａｖａでよくstatic classって書いてるから
staticじゃないクラスもあるはずだ！ ぼくも性的なクラスに入って性的なメソッドを勉強したいです 再利用できるようにと、何もかもグローバル変数に詰め込んだり。
複数人が同じファイルにコードを追加する形になる共通化？とかもうウンザリ。 昔staticメソッド禁止の開発やったことあるけど
そのうちコンストラクタに処理を書くやつが現れて
int hoge = new Hoge(1, 2, 3).getResult();
こんなコードまみれになってしまった オブジェクト指向で重要なのは、『独立した知能回路』であり、俺の股間に付いているのだ！ 処理に関係するパラメータが一か所にまとまっててすごく見やすい
入力に対して出力がいつも一定
基本状態がないからデバッグがすごく簡単
呼ばれる処理が１種類なのが確実
変な依存関係ができないように別クラスとかに定義できる
メリットしかない
むしろクラスメソッドの利点がわからんわ >>901
うわぁ...御愁傷様。
間違ったオブジェクト指向事例集とか言う記事があったら是非、紹介したくなる内容ですね。
>>905
スレタイがスレタイなので、ごめんなさい、失礼承知で質問させてください...。
それ、本気ですか？それとも、staticおじさんみたいなネタですか？ >>905
ごめん、やっぱりストップ！
全てstaticクラスにすればいいじゃないと主張しているように勝手に思い込んでしまったのだが...もう少し詳しく！
こっちが早とちりしただけかも >>907
煽るって、どこの部分のこと？
突っ込みとは、誰のどれに対して？対象が色々あってわからん。 つか、体も子供のまま
老いて何も残すこともなく
土に返っていくんだろうな…
ﾅﾑｱﾐﾀﾞﾌﾞﾂ（-人-） 嗚呼、
あはれ、秋風よ
こころあらば 伝へてよ
あるところに、男ありて… 質問に答えられないって、反論できない証拠。
論破された人は「池沼」「発達障害」という言葉を使って威嚇することしかできなくなる。
まさに、論破された人の良い例だな。 池沼は自分の考えを持たず他人の考えを受け入れないことによって最強となるが後に残るのは不毛の地である。あたり一帯を焼け野原にして文明を破壊する。 なんかスルーされてるけど、>>905の主張の方が気になる件について。
staticおじさんの主張、ほぼそのまんまじゃん。
お前はstaticおじさんのコメント欄見てこい。 口八丁、手八丁
口ではなんとでも言える
ってやつだろJK オブジェクト指向を正しく使えてる人ってどれくらいいるのだろうか >>923
オブジェクト指向は俺の股間で生きているぞ？ >>925
>>905
> 処理に関係するパラメータが一か所にまとまっててすごく見やすい
> 入力に対して出力がいつも一定
> 基本状態がないからデバッグがすごく簡単
> 呼ばれる処理が１種類なのが確実
> 変な依存関係ができないように別クラスとかに定義できる
スタメソのメリットの説明は、まぁ、いい。
インスタンスを生成しなくても使用できるがメリットという大きな理由に触れていないのは気になるが、そこはスルーしてやる。
> メリットしかない
ここが致命的に間違ってるわ。
インスタンスが持つ変数に直接アクセスできないのはオブジェクト指向を台無しにしかねないレベルの最大のデメリットだろ。
わからないことがあれば、質問、どうぞ。 870あたりからの会話の流れを読んでれば、905の解説をする必要性なんてないと思うのだが。 >>926
インスタンス変数にアクセスできないことによってスレッドセーフであることを保証できるわけだからロジックを共通化する手段としてインスタンス変数を持たないクラスには存在価値があるわけですよお！？ 入力に対して出力が一定って本当？
基本状態って何？ 可変な状態を持つオブジェクトはドメインには必要ない
可変な状態が必要なのはデータ構造
データ構造は標準ライブラリやフレームワーク由来のものを使用するのが基本
オブジェクトにインスタンス変数が必要になったときは設計を見直すしかない
ドメインとデータ構造をごっちゃにするから暗黙の依存関係でぐちゃぐちゃになってオブジェクト指向使わない方がマシという事態を招く スタティックおじさんの感覚は概ね正しい
業務システムのコンサルタントやってる立場から言わせてもらった オブジェクト指向とは俺の股間で生きているそれだけで十分だ！ >>929
staticメソッドの使用はオブジェクト指向の基本中の基本、オブジェクトの生成と消滅の概念を壊してしまいます。
オブジェクト指向の基本的な考え方を破壊してまで、スレッドセーフの実現手法にstatic化が適切なのかはと言われると、そうは思いません。
第一、そのような方法によるスレッドセーフ実現がありなら、「インスタンスの生成は１つまで」というルールをつくるのもありだと思います。
まぁ、私はそんな方法でスレッドセーフは実現しませんが。
スレッド間を跨ぐオブジェクトはスレッドセーフ対応コレクションやmutexオブジェクトを使って実現しますけどね。 >>932
931はちょっとスルーして、先に932について尋ねますが、あなたはオブジェクト指向を否定する立場なのですか？肯定する立場なのですか？
それによって私の言うことが少し変わります。
まぁ、「実はオブジェクト指向って、しっくりこないんです｣のstaticおじさん側ということは、否定だと思いますが。
それだったら、先程、オブジェクト指向の考えを破壊しかねないstaticメソッド使用は危険が伴うという指摘は、あなたにとってどうでもよかったということになりますね。
どうなのでしょう？
ちなみに、私は肯定している側です。 >>934
> >>929
> オブジェクト指向の基本的な考え
オブジェクト指向は俺の股間に付いている！ オブジェクト指向肯定の理由。
>>935
>あなたはオブジェクト指向を否定する立場なのですか？肯定する立場なのですか？
俺の股間に付いているのが、オブジェクト指向で無ければ何だというのか？
オブジェクト同士は常に二人称であり、オブジェクト指向では独立した知能回路が実装される。 時間が時間なので、最後に...
別に、非オブジェクト指向のプログラムでstaticメソッドを使いまくるのは結構です。
ただ、そのプログラムを指差して「オブジェクト指向はクソ」と言われないようにだけしてください。
オブジェクト指向として解釈すると駄目だけど、別のプログラミング手法として解釈すると問題ないというのなら、それはそれでいいです。
>>937
あと、ちんこ哲学者さん、理由はどうであれ肯定ありがとうございます。
このスレで肯定一人は心細かったです。
ちんこ哲学については深すぎて理解が追いつきませんが。 うるせえ大人が現実のプログラムの話してんだお前は学級委員でもやってろ >インスタンスが持つ変数に直接アクセスできないのはオブジェクト指向を台無しにしかねないレベルの最大のデメリットだろ。
>staticメソッドの使用はオブジェクト指向の基本中の基本、オブジェクトの生成と消滅の概念を壊してしまいます。
>オブジェクト指向の基本的な考え方を破壊してまで、スレッドセーフの実現手法にstatic化が適切なのかはと言われると、そうは思いません。
オブジェクト指向押してる連中のこのあたりの
教科書丸写ししただけみたいな感想に寒気をおぼえた
お前は何を言ってるんだ感がすごい >>934
オブジェクトは動的に生成され、そして動的に消滅するのが
ブジェクト指向の基本中の基本だというのは勘違いだぞ。 オブジェクト指向がどうという次元の問題ではない
実際にどんな局面でそれがどう問題になったのか全く想像がつかないんだ
根本的にあたまおかしい
好意的に考えてもふだんからよっぽど酷いオブジェクトの使い方してたとしかおもえん
メンバをグローバル変数代わりにしてるとか
１年生がよくやる オブジェクト指向厨に基本が出来ていない奴が多いのは
確かだな これヤバイなw
こんなめちゃくちゃなモデリングを1000人以上がいいね!しちゃうんだね
役割駆動設計で巨大クラスを爆殺する
https://qiita.com/MinoDriven/items/2a378a09638e234d8614 多分悪い奴ではないんだよ、
でも自分で考え物事を見極める力が足りなかったんじゃないかな
よくいる。
それがオブジェクト指向宣教師にだまされ、迷信にどっぷりつかってしまったんだろ
アーメン >>946
一番ヤバイのは何のためにモデリングをするのか全く理解してないところ
次にヤバイのはユーザーロールとクラスの責務を区別できてないところ >>947
レスが下手だなｗ 否定するだけで案を書いてない。
俺がテンプレ書いてやるから○○に当てはめてみな
× 一番ヤバイのは何のためにモデリングをするのか全く理解してないところ
○ ○○のためにモデリングということを理解しなければいけない
× 次にヤバイのはユーザーロールとクラスの責務を区別できてないところ
○ ユーザーロールとクラスの責務を区別するために○○をしなければいけない ふつうは番号で管理してる紐づきを直接クラスにぶち込んだらこうなる
EntityFrameworkとか使ってたらありそう
各機能の出力画面に１対１に対応してそうだし
ＤＢ設計じゃないからいいのかもしれない >>934
インスタンスが一つでもスレッドセーフにはならんでしょ 938の書き込みを見たとき、絶対、火病起こす人が現れると思いきや案の定だった。 >>945
staticおじさんに洗脳されている人の方がヤバイ。
まさか、staticメソッドだけで書いたJavaコードをオブジェクト指向に則ってつくられたコードだと主張する気か？ >>935
staticおじさんの方が君よりもまともだと思ってる staticおじさんは状態が必要ないところではstaticメソッドを使うんだという当たり前のことを言ってるだけだよ
.NETフレームワークがオブジェクトを用意してるからビジネスロジックではそれを操作するのが主で自ずとstaticメソッドでロジックを組み上げるってこと
当時はASP.NET Web Formsを使ってた、フレームワークに従って作ればそうなるよ、ややこしいことやらんでいいよって文脈だった
staticおじさんエアプか？ >>953
なんでやねん。
だったら質問に答えろや。
お前は全部staticメソッドで作られたコードをオブジェクト指向のコードと言い張るんか？
元の925の主張はそうだっただろ。
お前はどうなんだ？ オブジェクトおじさん「これはオブジェクト指向なのか！？」 >>955
クラスオブジェクトに属してるから立派なオブジェクト指向です Mathクラスは数学に関するロジックを集約したオブジェクトですよね 危惧してるのは状態を作ればオブジェクト指向になるんだって思いがちなところ
ビジネスロジックでオブジェクトを作り出したら危険信号、データ構造とロジックの分離ができてない証拠
昨今流行りの関数型がデータ構造に処理を丸投げすることで複雑さに対処するようにオブジェクト指向でもビジネスロジックとデータ構造の見極め大事
staticメソッドは悪いものじゃない >>957
staticメソッドはデメリットがない、全部staticにすれば？ってのが奴の主張
オブジェクト指向プログラマーにとってstaticにするべきではない部分までstaticにしようとするから、こんな話になったんだろ？
必要のない と見なす部分が広すぎ >>957
それはクラスを名前空間として利用してるだけでオブジェクト指向とは言わんだろ >>961
クラスオブジェクトに属してる
名前空間ではないよ >>962
>>905な。上の925も間違い。
>>963
そういう言語仕様レベルの話じゃなくて、実質、名前空間のようにしか扱われていないと言いたいのだろう。
正直、アレをオブジェクト指向扱いするのはどうかと思う。オブジェクト指向向け言語で書いたオブジェクト指向モドキだろ、あれ。 もしかして...staticおじさんをただ単にstaticを使う人への煽りと解釈している人と、「実はオブジェクト指向ってしっくりこないんです！」の記事で大炎上した人という意味で解釈している人がいるんじゃないかな？ >>965
クラスオブジェクトに属してるんだからオブジェクトだよ
newは省略されてるだけ
名前空間とは明らかに違う
継承、ポリモー、カプセル化を使わないとオブジェクト指向じゃないとでも思ってるのかな？
クラスの存在そのものがオブジェクト指向だよ >>967
世の中にはC言語でオブジェクト指向なプログラムを書いている人もいるから、その理屈は少し怪しいな。 アランケイ「オブジェクト指向発明したけどC++がやりだしたクラスなんか知らないよ」 ストラウストラップのハゲは列挙体使うときにクラスを名前空間代わりにして使ってたな >>967
>クラスの存在そのものがオブジェクト指向だよ
チンポは独立した知能回路を有しているからオブジェクト指向だよな！ まずは純粋にCだけで書かれたWindowsプログラムを読んでみることをおすすめする
言語がオブジェクト指向に対応してるにこしたことはないけど、
一般人には無縁のパラダイムだよ >>972
あれのメッセージループの記述が、どんな教科書でも switch～case なのは、そろそろいい加減にやめないといけない、と、強く感じているのですが…
一方、私は無駄に継承を重ねることにしました…薄い層にスライスしてメッセージループと、それ以外の関数との関係を強調する試みです >>967
JavaでMath.sqrt(36)って書くとMathがクラスだからオブジェクト指向で
他言語でMath.sqrt(36)って書いてもMathがクラスじゃなくモジュールだったらオブジェクト指向じゃないってことになるね
型クラスが存在してるHaskellはオブジェクト指向そのものw >>949
EFとか画面単位とか関係ない
↓こういう思考ロジック
[機能概要]
出品側として、商品を出品する。
購入側として、商品を選択し購入手続きをする。
↓
[関数シグニチャを想像]
出品する(出品者ID, 出品リスト)
購入手続きをする(購入者ID, 受け取り住所, 購入品リスト)
↓
[クラス化]
出品者クラス: [識別ID, 出品リスト], 出品する()
購入者クラス: [識別ID, 受け取り住所, 購入品リスト], 購入手続きをする()
リレーショナルモデリングでもオブジェクトモデリングでも
エンディティやオブジェクト間の関連を無視してまともなものはできないよ >>968
クラス的なものを使ってたらオブジェクト指向的なことができます怪しくないよ全然怪しくないよ >>974
そのモジュールとやらをクラスとみなすことでオブジェクト指向とみなすことは可能だよ全然余裕だよ >>969
ケイちゃんのオブジェクト指向は今のWebサービスだかんな >>971
TI（ちんぽうちのう）ってかwwwやかましいわwww Webサービスがstaticメソッドで実装されてようがインスタンスメソッドで実装されてようがWebサービスの外からはWebサービスというオブジェクトしか見えない
ケイちゃんのオブジェクト指向はそういうでっかい視点でリモートでオブジェクトが協調する姿を画いてる
ケイちゃんにとってはクラスさえ瑣末なもの やっぱり人間は構造化できてないものは理解できない
関係の理解も２つが限度
メッセージパッシングによるオブジェクト指向は構造化をめちゃくちゃにする
シミュレーションぐらいしか使い道がない
構造化万歳ダイクストラ万歳 お風呂に入ってｱﾙｷﾒﾃﾞｽの原理を発見したポルトガル人ですよ >>954
staticおじさん、こんなこと言ってない...。
それ、staticおじさんに突っ込みを入れた人のコメントでしょ。
>理由があってstaticを使うのではなく、理由が無いからstaticを使う。
>理由が無い場合は、素直な方法を選ぶものだが、何が標準かというのが違う人なのですね。
>そこがオブジェクト指向が身についている人と、身についていない人との違いなのでしょう。
>>954はQiitaのstaticおじさんを無理して弁護してみた系の記事しか読んでいないのでは？ 状態が必要ないならstaticを使うべし
状態に依存しないクリーンなメソッドであることを表すことができる
あるメソッドは状態に依存していて、あるメソッドは状態に依存してないそれらのメソッドは別のオブジェクトにするのが良いかもしれない
staticを使用することでこのような分析も可能になる 貧血ドメインも悪いもののように言われているが間違ってる
データ構造を工夫すればビジネスロジックは状態を持たずシンプルかつクリーンになる ドメインオブジェクトは状態を持たないといけないという思い込み呪いバイアスがこんにちのオブジェクト指向クソじゃないか旋風を巻き起こしてる
オブジェクト指向の本質は状態管理じゃないオブジェクトを分類することこそがオブジェクト指向 >>994
どこ？引用してくれないかな？
しかも、記事本文で共有変数もpublic staticするとか言ってるぞ。 >>994
どこ？引用してくれないかな？
しかも、記事本文で共有変数もpublic staticするとか言ってるぞ。 悪名高いsingletonパターンの代替となるmonostateパターンでは全ての変数をstaticにする １つのクラスから複数のインスタンスを同時に生成して同時にアクセスするような場面ってそんなないでしょ？
繰り返し同じ関数をパラメータ変えて呼べば済むことが多いだけ
俺も信者に騙された一人だけど、やっぱ評論家はまず学歴見なきゃダメだと痛感した 結論
オブジェクト指向がクソなのではなく、プログラマーがクソだった。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 162日 13時間 17分 22秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
