すごいんだよ？
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前スレ オブジェクト指向ってクソじゃね？
http://2chb.net/r/tech/1535085129/ 前ｽﾚの終盤、へっぽこのOOP厨が湧いて出て
レベルの低いﾚｽで埋まったな…
>>1
オブジェクト指向ってクソじゃねぇよ？ Part2
「ぇよ」は余計。
乙は張ってやらない。
ボーっと生きてんじゃねーYO!! 前スレの続き？
993 デフォルトの名無しさん[sage] 2018/10/18(木) 23:33:25.51 ID:/ofNkRJS
>>988
Personのような業務クラスは使いまわしできるわけがないのは常識で
どうせ作る力ないんだから作るな。使え。
オープンソースなんかの汎用クラスを使え
見事にオブジェクト指向で世界中使い回し出来てるんだから。
ここからレス。
自分で矛盾してると思わないか？
使い回しできるわけがないって言いながら使えって。 スレ立て乙です
意外に活況で自分は参考になる処が有る
オブジェクト指向プログラミングスレって
意外と少ないからここに集まっているかのね?
タイトルが少し変わっているのがw
守秘義務あるから、肝心な所って案外無いのも現実。
精々OSSやただロジック書いてるのを参考に書き下すだけ。
>>4
次の行までちゃんと読みましょう
> どうせ作る力ないんだから作るな。使え。
> オープンソースなんかの汎用クラスを使え >>7
そこで >>6 に至るわけですよ。
コピペに夢見んな。 >>8
なんでOSSで作られた汎用クラス使えって言ってるのに
守秘義務が関係あるわけ？ >>9
ちゃんと読めよ。
普通は守秘義務で守られてるから、参考にする先がOSSくらいしか無いって書いてるの。
それで、ジャスト俺の使ってる言語のコードなんて無い。
ロジックだけ参考にする。 >>11
ちゃんと読めよはこっちのセリフで
Personクラスのようなどう考えても業務クラスを
汎用的に使えるようにしようとか考えるな
そもそもお前にそれができる力はないだろって
話をしてるんだが？ 下手なやつの特徴なんだが、なぜか100行とかなるような長い
業務ロジックをまるまる再利用しようとするんだよな
正しいやり方は業務ロジックを読み解いてその中に含まれる
業務ロジックではない部分を抜き出して汎用化することで
業務ロジックを減らすんだよ
>>12
ん？
矛盾して無いか？って書いた時点で、汎用的に使えないってのに同意してたつもりなんだが。。。 >>15
俺はあんたが関係ない話をし始めたら
話を戻しただけ >>16
その通り。
実装上似たコードがあれば再利するかどうかは物理的・実装ﾚｲﾔの話。
そんなものどうでもいいここと。
汎用化ってのもインチキ臭くて、ある業務ソフトの中にそんなに汎用コードがあるのかと。 OOPは多分ソフトウエアアーキテクチャ・構造設計・構築の
基礎すら分かっていない
実装上、似たコードがあったからと言って
(後出しで)便宜上スーパークラスを設けて
継承してサブクラスとして再実装とか
もうソフトウエア構造ぐっちゃんぐっちゃんのスパゲティー
しかも、クロスファイル
あっち飛びこっち飛び
もう涙目通り越してデスマ状態
ほんとは弱小案件のはずだったのに
>>23
それは単一責務を破った悪いOOPだからだ
単一責務を守った良いOOPはクリーンなものになる ここら辺で半角さんが
学歴問題に論点をすり替えるため登場してきそうな希ガス
ご自身の無能は棚に上げてｗ
最近は継承自体がなるべく使わない様にってなってる。
継承の代わりにフィールドとして、インスタンス持つ移譲ってのが最近のセオリー。
オブジェクト指向の成功と失敗の歴史の成果。
結局はね、答えを言っちゃうと
論理的機能のモジュラリティー・独立性に
どう役立つか、あるいは
害があるかの問題だったと思うのよ。
大規模で複雑怪奇となるソフトウェア構造、システムを
人間が理解可能な範囲の設計に収められるかとか
静的なソースコードとして(動的なオブジェクトや状態を)
メタファーとしてどう表現し管理すればいいか、
管理し維持しやすいか
でも近年流布していたOOPS論はその
ま逆な方向になてしまった
ま、いいや、
774があんたらになに言っても
世の中何も変わらない
よくならない
百年くらい経って文明が滅んでなければ
なんか理解が進捗してるかもね
最近のスパゲティーは関数跨ぐわ、クラス跨ぐわ、ディレクトリ跨ぐわで、スコープ広すぎですわ。
自分がマイクロソフトに基本部分の改修やられてみろって話だよね
いやーやっぱり重複コードがあると汚いじゃない？
だから既存の部分もいじっちゃったｗ
動かなくなったらごめんちゃいｗテヘｗ
↑カワイイ!ｗ(*ﾟ∀ﾟ)ｂ
どんな業界だって知的労働者と肉体労働者で成り立ってて、日本のIT業界に知的労働者はいない
欧米人がサプライヤとしてOOしやすいフレームワークを提供するから日本の労働者はクライアントとしておとなしくnewしてろよ
知的労働者目線で語る前に、ライブラリを公開してみろよ
おまいらのクラスなんぞVB6の標準モジュールから外出しした常駐クラスモジュール程度のものだから、業務別にクラス切って、その中に構造化プログラミングしてろよ
OOPできないなら構造化プログラミングもできないと思うよ
この板にいるような低学歴にｵﾌﾞｼﾞｪｸﾄ指向は
ｷﾁｶﾞｲに刃物
ｺﾚは間違いない
>>37
作って遊べるunityVRアプリ開発入門 An Introduction to Object-Oriented Programming 3rd Edition, EDITION by Timothy Budd
オブジェクト指向プログラミング入門 ティモシイ・A. バッド (著), Timothy A. Budd (原著), 羽部 正義 (翻訳)
ＭＦＣといいＬＩＮＱといいマイクロスフトのオブジェクト思考？はバランス感覚が素晴らしい気がする。
rubyのグダグダみてればオブジェクト指向言語つっても保守性が上がるわけじゃないってのはよくわかると思う。
半角は実践的なソフトウエア開発のさまざまな現場で
一体OOPがどのくらい有効だって考えてるんだ？ｗ
聞くだけ無駄かもしれんが
オブジェクト指向は
学歴の高さで解決する問題との御託宣でございます
一般の方はソフトウエア開発は無理なので
関わらないでください。
以上。
オブジェクト指向とは
実はソフトウエア設計のように何か目的を持って指向してきたものではなく
選別試験指向、受験による選民指向的話にすりかわって
しまいましたぁー
すまんが今夜はちょっと機嫌が悪い
> すまんが今夜はちょっと機嫌が悪い
ざまぁｗｗｗ
ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
＞例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
当然ながら起きているときも、チンポがシコシコする！
風呂から出て体一杯に水を浴びながら竜哉は、この時始めて英子に対する心を決めた。裸の上半身にタオルをかけ、
離れに上ると彼は障子の外から声を掛けた。
「英子さん」
部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。
その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。
●これが衝撃の「障子破り」シーンだ！ （石原慎太郎 『太陽の季節』 （新潮文庫） より）
http://www.geocities.co.jp/Bookend-Soseki/3578/2003/shoujiyaburi.htm
チンポがシコシコする≠勃起、つまりそれはただチンポが勃起するのではなくて、
「体中が引き締まるような快感を感じた」ということなのである！！
またチンポがシコシコするのは、物理的な刺激に限ったことではない。
https://imgur.com/R4D8yyk
https://imgur.com/Fjw9t3F
「アクトレス」（山田謙二）より。
夏目くんのチンポは何にも触れていないのにシコシコしている！
ここで、『俺の陰茎がスポコラバギーン！』というのはどうだろうか？
『スポコラバギーン』の意味がわからなくても、前後の文脈からどうなったかを推測する。
陰茎がどうなるかについては、尿結石で痛むのか失禁して恥ずかしいのか、あるいは他に何かを推測する。 >>33
＞どんな業界だって知的労働者と肉体労働者で成り立ってて、日本のIT業界に知的労働者はいない
米国で上位1%が富の独占をしている大きな理由は、労働者をスキルや成果で大きく選別しているからだ。
しかしながらそうでもしないと、ドラクエ10の下請けのように、コードの質が大きく落ちてしまう。
俺はドラクエ一筋なんてのはむしろゴミなコードを入れてしまう『有害な』働き者なのだ。
それは中小企業のデスクワークによくありがちな、要らない書類ばかり作って俺は仕事ができるみたいなものだ。
提案広場でよく『そう思わない』される理由
http://dragon-quest.me/dq10/27646/
このゲームすぐ持ち物いっぱいになるな
http://dragon-quest.me/dq10/28435/
【ドルボードGP】おいｗデスルーラ作戦晒すなやｗｗｗｗｗ
http://dragon-quest.me/dq10/28002/
でも月額千円では、下請けプログラマーの選別なんて出来っこないだろう？
＞このゲームすぐ持ち物いっぱいになるな
ゲームの仕様について意見を出すと、必ずといっていいほどに『そう思わない』で真っ青。
つまり準廃プレイヤー＝下請けプログラマーには、ゲームの仕様を変える能力が欠如しているのだ。
アルバイトの賃金が低いのはスキルを必要としない単純作業だからで、労働者にスキルを求めるのであれば、
アルバイトよりも高い賃金を上乗せして払わなければならず、更に成果に応じた報酬も必要となる。 風俗の話ならpink板あたりかな
知らないが。
病気 気を受けた方がいいかもね
前、人間は間違うと言う話をﾚｽしてきた椰子がいたけど
人間はそういう生き物
メソッド飛びに飛びまくって最後returnだけとかブチギレそうになる
リターンだけのコールはバイナリでパッチ当てるときに使える
包丁は
便利な道具だが使いようによっては
人をｺﾛｽこともできる
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向は
ｷﾁｶﾞｲに刃物
それぐらい危険
この板にいるような低学歴知恵遅れでは
ｵﾌﾞｼﾞｪｸﾄ指向なんかまずﾑﾘ
包丁で切り分けられたりんごを食べることはできると思うの
>>60
あんたの学歴がそろそろ気になってきたんだがｗ
ウソでもいいから言ってみてくれ 何このレベルの低い議論。
今でも思うがオブジェクト指向よりはテンプレートとか、ジェネリックとか言われる機能の方がコードの短縮に一役買ってる気がする。
オブジェクト指向はGUIと相性が良かっただけで、それもどっちかと言うとイベントドリブンとかイベントループとの相性。
だったら、そこだけ抜き出せばあんまりオブジェクト指向に価値は無いんじゃないかと。
ただ、大人数で責任分担ってのにはオブジェクト指向が向いてる。
コードの再利用性ってより、コードの責任の所在特定の為って気がする。
>>65
お前が考えるレベルの高い議論ってこのスレの場合何？ 半角って人を低学歴やバカ呼ばわりするだけで
内容のあるﾚｽを書くことが出来ない
何回も、自分のほうが馬鹿だと晒してるしなw
可哀想な子なんだよ。
>>65
> 今でも思うがオブジェクト指向よりはテンプレートとか、ジェネリックとか言われる機能の方がコードの短縮に一役買ってる気がする。
オブジェクト指向は構造を定義するもので
コードを減らすものじゃないからな。
そもそも短縮すべきコードというのはステップ（処理を実行する行、主にメソッド内部）であって
実行されない行（例えばクラス定義部分）が増えようが困らないし
逆に人間にとっては情報量が増えるので可読性が上がる
オブジェクト指向は定義情報が増えるからコードの行数が増えるように思えるが、
ステップ数は増えていない 前ｽﾚにすべてｵﾚは書いたからな
ｵﾌﾞｼﾞｪｸﾄ指向の用法と問題が発生しないようにする対策をすべて書いた
低学歴知恵遅れが読み取れないだけといっていい
読み取れない原因は著しい低学歴知恵遅れであることが問題といっていい
頭悪いのは不治のやまい
頭悪い自覚がないからな
>>69
本来の処理に本質的には関係のない
オブジェクト指向のための管理みたいなコードが増えして
S/N比下がるじゃない。Javaとか とくに。 >>70
あれっぽっちですべてか…
引き出し少なすぎるよあんた >>71
Javaの問題であってオブジェクト指向の問題じゃないでしょ 確かに学歴聞いてみたいわw
業務についてもご高説ありそうだし、どのぐらいの規模の会社にお勤めかもw
>>69
ステップ数は増えてないのは分かる。
行数が増えてるだけで、考える内容がカプセル化されるかとかなのは。
補完機能のお陰であまりに気にするものでもない。
だから本質は責任の所在特定、バグの特定、バグ作った奴の犯人特定がオブジェクト指向の主な目的だと思ってる。 >>76
それは一理ｱﾙかな。Javaは助長だ名のコードを書いているか分からんて結構みんなげんなりしてる
でもCの構造体から発展していった系列のオブジェクト指向言語は
多かれ少なかれその傾向はあるといえるんじゃない？ テンプレートやジェネリックを搭載している言語は
オブジェクト指向ぐらいしか無いと思うが
テンプレートやジェネリックでコードが減ることはないな
変数宣言部分が冗長になるだけ
（ここも実行部分ではないのでステップは増えない）
ｵﾚは間違ったことなんか書いたことなんかない
低学歴知恵遅れが精神的勝利してるだけだからな
この板では阿Q正伝の物語がそのまま再現されてる
>>78
きっぱり壁を設けるためにはひとつの手段かもな、
だがそれでソフトウエアは記述・表現しやすくなるものなの？ >>81
だから内容のないﾚｽばっかりだったらそもそも間違いようすらないでしょ
何言ってんのこの人は STL（テンプレート "ライブラリ"）を使うことで
コードが減るだろうが、それはテンプレートだから減るわけじゃなく
ライブラリを使ったから減る。
テンプレートやジェネリックがなくとも
ライブラリはあるので、ライブラリを使えば同じように減る
半角さんって何かカリフォルニア工科大学出てそうだわ
んでgoogle本社で働いてそう
>>83
Qiitaに書いたがいんじゃないかな、そのブログは古臭くて見難いよ
業務を想定して使い途を解説して欲しいな
コードの詳細はどうでも良い オブジェクト指向を分かりやすく例えて教えてくれ 2
ｽﾚのミラーアフィーじゃないの？cacheしか見てないけど
引き出しとかいってる時点で頭悪いﾜｹ
はっきりいってな
ｵﾚは低学歴知恵遅れといちいちﾑﾀﾞ話するために
ﾚｽなんかしてない
ｵﾚは有益な情報をｽﾚに書いてるだけだからな
大事なのは
核心にせまる要点を
要約して書くことだからな
低学歴知恵遅れのﾚｽはまずな
中身ｽｶｽｶの情報価値ｾﾞﾛのﾚｽという自覚がまずない
ｵﾚはしっかり有益で情報価値の高いﾚｽをしてる
ｵﾚは前ｽﾚの前半ですべて書いたからな
あとで低学歴知恵遅れがﾜﾗﾜﾗよってきて
ﾃｷﾄｰなこと書いてるｽﾚになった
>>82
だから、俺は思ってないし。
GUIには多少の効果はあった。
ただ、それは別にライブラリに押し込めれば良いだけで、関数型言語でも関数型言語っぽく無いだけで、出来てる。
だから、責任追求したい雇う側の都合言語って側面もあるって指摘したんだが。
(出来ないプログラマーに足を引っ張られるプログラマーも含んで良い) ハイ、無駄
まずはオブジェクト指向のメリットを定義してください
責任追及し易い以外のオブジェクト指向そのものの利点感じてない。
継承。publicが継承したらprotectedになったり、publicのままとか指定出来るならまだしも、勝手に変わる。今じゃなるべく継承するなってのはこの辺が原因じゃ無いかと思ってる。
最近のトレンドは委譲。これはオブジェクト指向特有じゃ無い。
カプセル化。関数型言語ほど依存性を無くせてない。(まあ手続き型言語にしては無くせてるし、主流は手続き型言語だから仕方ない)
多態性。テンプレートやジェネリックのが多態性を実現出来てる。(オブジェクト指向の一部っぽいがオブジェクト指向特有では無い)
強いて挙げればオブジェクト指向設計が責任分担しやすくて使えるぐらい。
OS側の言語がサポートしてるからライブラリが揃ってて楽。程度で、OS側が関数型言語に行けばそれに従うまでってだけ。
長いものに巻かれた結果。
>>94
おまいがそうやって煽るから低学歴ちゃんが必死にレスしちゃうんだよ
自重してね オブジェクト指向が出来ない人って数値や日付を格納するのに文字列を使うことに強い違和感を感じないタイプって気がする
新人の様子とそいつの数年後を見ると傾向がある
ドカタのクセになに責任分担とか甘いこと言ってんだ。
お前が全部責任取れよ。
俺は命令するだけ。
お前が作業するの。
問題出たらお前の責任。
逆よ？
お前が全部責任とれって言うためのオブジェクト指向。
有耶無耶になったら責任者の自分が責任取らされる。
>>96
＞まずはオブジェクト指向のメリットを定義してください
ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ 風呂から出て体一杯に水を浴びながら竜哉は、この時始めて英子に対する心を決めた。裸の上半身にタオルをかけ、
離れに上ると彼は障子の外から声を掛けた。
「英子さん」
部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。
その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。
●これが衝撃の「障子破り」シーンだ！ （石原慎太郎 『太陽の季節』 （新潮文庫） より）
http://www.geocities.co.jp/Bookend-Soseki/3578/2003/shoujiyaburi.htm
チンポがシコシコする≠勃起、つまりそれはただチンポが勃起するのではなくて、
「体中が引き締まるような快感を感じた」ということなのである！！
チンポがシコシコするのは、物理的な刺激に限ったことではない。形態は様々で伏魔殿のように奥深い。
https://imgur.com/R4D8yyk
https://imgur.com/Fjw9t3F
「アクトレス」（山田謙二）より。
夏目くんのチンポは何にも触れていないのにシコシコしている！
ここで、『俺の陰茎がスポコラバギーン！』というのはどうだろうか？
『スポコラバギーン』の意味がわからなくても、前後の文脈からどうなったかを推測する。
陰茎がどうなるかについては、尿結石で痛むのか失禁して恥ずかしいのか、あるいは他に何かを推測する。 触れてもいないのに勃起する、何と不思議な生き物なのだろう！
人工知能について議論する場合は、難しい数式は後回しにして、まず身近でわかりやすいエピソードから。
この著作もそういうふうに書いている。
（第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル
次スレは
オブジェクト指向ってクソじゃねぇかよ
で決まりだな
>>100
それ、逆じゃないか。型を曖昧にするのがオブジェクト思考だろ？ メリットが明確でないのがオブジェクト指向だぞ
現にメリットを誰も定義できない
>>113
横からだが、汎用化(貴方の言い方では曖昧に)も特化(明確化)もどっちもオブジェクト指向の役割かと。
大事なのは責任の明確化なんだが、継承(is-a)はそう言う点で明確化し難い面があって、移譲(has-a)を推進する流れになったんだと思う。
(親子関係(子は親と同じ扱い(is)になれる)関係よりも移譲(部品化(has(持っている))の徹底)の方がオブジェクト指向らしい)
継承も上手に使えば汎用的で有効だが、下手に使うと親クラスの肥大化を招く。 わかってないな
オブジェクト指向の時点ですでに失敗している
それは移譲が主流になった時点で薄々気付き始めてるかと。
そもそも初期のC++にテンプレートは無かった。
テンプレート(ジェネリック)の登場も、当初は未熟でも静的型言語で動的型言語のいいところを少しでも取り入れようとした結果のように思う。
決定打はクロージャ(機能)の登場で、主流の言語はオブジェクト指向型言語と言うより、「関数型要素を取り入れたオブジェクト指向」のハイブリッド言語ばかり。
純粋オブジェクト指向言語も、純粋関数型言語もメジャーでは無い。
個人的に
1、テンプレート(ジェネリック)=型情報を維持しつつも少しでも動的型言語のいいところを取り入れるための機能。
2、C#のダイナミック型=動的型言語やSQLなどと連携、または完全に動的型言語のエミュレートする機能。(Javaにも似た機能はあった気がする)
3、クロージャ=動的型言語に続いた結果の関数型言語の機能。
と言う印象で、純粋なオブジェクト指向が語られる事自体が減っているし、これからも減ると思う。
>>117
そもそもテンプレートやジェネリックはオブジェクト指向じゃないから、
最早純粋なオブジェクト指向を語れる言語が主流では無いって言う。。。
(純粋オブジェクト指向言語はsmalltalkくらい) > (純粋オブジェクト指向言語はsmalltalkくらい)
smalltalkのブロックはまんまクロージャだから、
>>118の定義だとsmalltalkも純粋オブジェクト指向言語とは呼べないのでは 低学歴の何が悲しいかと言うと
自分がアホで物を知らないと言う自覚が無いこと
だからこんになにも自由奔放に
大人の前で九九を暗誦し続けるのである
あ、Rubyもか。
Pythonも一応そう謳ってたような？
メタプログラミング的にはsmalltalkとRubyか。
純粋オブジェクト指向は動的型言語が前提。
記憶にある限りじゃ静的型言語で純粋オブジェクト指向言語は無い。
>>120
あ、それは思った。
ブロックもクロージャになる。
純粋オブジェクト指向は関数型に近付いって思った。 > 型を曖昧にするのがオブジェクト思考だろ？
なんかじわる〜
>>118
それはオブジェクト指向の話じゃない
C++の話だ
そもそもテンプレートやジェネリックは、型を明確にすることでバグを少なくしたり
速度を速くするためのもので、オブジェクト指向における問題点を解決するための追加機能
テンプレートやジェネリックを使うことでオブジェクト指向が不要になるのではなく
オブジェクト指向と組み合わせて使うことで問題点が改善される
テンプレートはオブジェクト指向と組み合わせずに使えたと思うが、
テンプレートの殆ど（ジェネリックは全て）はオブジェクト指向なしに使うことはできない ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
> テンプレートの殆ど（ジェネリックは全て）はオブジェクト指向なしに使うことはできない
>>110 >>128
wikipediaよんだ？
> Haskell言語にはパラメータ化された型 (parameterized types)、パラメータ的多態 (parametric polymorphism)、
> そしてJavaのジェネリクスやC++のテンプレートの両方に似たプログラミングのスタイルをサポートする
> 型クラス (type classes) がある。
型クラス >>125
そうだな
クソレスも良レスも全部文字列 >>126
悪かった。
解りにくかっただろうが同じ事言ってる。
テンプレート(ジェネリック)はオブジェクト指向じゃ無いが、その欠点を補う為に生まれたのは同意。
オブジェクト指向は万能じゃ無いって言いたかった。 どっちだっていいからさっさと
オブジェクト指向のメリット出せよ無能
何でカンケーねー話ばっかりしてんだザッコ
>>133
基本的に自分のスタンスは >>116
責任の明確化をしたかったけど、一定の成果を上げつつ未だ試行錯誤中って印象。 >>134
お前はメリットも見えない技術にどうこう言ってアホなの？
そもそも初見で見えたメリットについて精査するならわかるけど
そもそも見えないメリットをわざわざ探してやるって頭おかしいの？ 弁護するつもりはないがモジュラリティーか何かのために
良かれと思って使っていたんｊないの？
オブジェクトの単にプロパティとメソッドをまとめる性質はオブジェクト指向のメリットとまで言っていいんだろうか
これだけだと構造体のような
>>137
まぁ、それはオブジェクトscopeってやつなんだけれそも、それは特性であって
じゃあ、それがどのようなメリットがあるかについてなんだよね
ﾆﾔﾆﾔ ﾌｧｲﾙﾎﾟｲﾝﾀは構造体だが
ﾌｧｲﾙﾎﾟｲﾝﾀの構造体をじかにおさわりするﾔﾂはいない
ﾌｧｲﾙﾎﾟｲﾝﾀの構造体はさわれても
当然おさわり禁止だ
さわれることと、さわっていいことは違う
人を殺せても、人を殺してはいけないのと同じだ
わかった？
管理が面倒なのをオブジェクトに押し付けれるのはどう？
ﾒﾘｯﾄをきいてきたから
ｵﾚをちゃんとﾒﾘｯﾄを答えたからな
低学歴知恵遅れがくだらないと思うかどうかは関係ない
なに切れてんだよｗ
そもそもFILE構造体はオブジェクトじゃねだろ
scope切らないだろ
なんでscope切らない構造体のポインタごときがだな
オブジェクトスコープのメリットとして挙げられるんだよ
寝言は寝て言え
つか起きてても寝てるようなものかｵﾏｴﾊ
ｲﾝｽﾀﾝｽはｵﾌﾞｼﾞｪｸﾄだ
当然をﾎﾟｲﾝﾀはｲﾝｽﾀﾝｽのｱﾄﾞﾚｽをさしてる
ｸﾗｽｲﾝｽﾀﾝｽのﾎﾟｲﾝﾀも同じだ
うちの新人にもお前みたいな能無しの癖に
明後日の方向いた能書きだけたれる低学歴が
他人を見下したくて毎日必死で
プロジェクトはいい迷惑してる
とても残念なことに
どんどんｵﾏｴが低学歴なのがﾊﾞﾚちゃうな
リンケージでぐぐれ
あとオブジェクトスコープでグぐれ
基本情報処理の範囲だ
>>150
いわゆるscopeのメリットだな。
ではオブジェクトにあえてscopeをもたせたら
どのようなメリットがあると思う？ 低学歴知恵遅れは
ｱｸｾｽ修飾子のｽｺｰﾌﾟも知らないらしいからな
>>152
レベルが低いので
場外でご観戦ください ﾚﾍﾞﾙが低いとな？
いやあ
こんな基本的なことすら分かってない低学歴が大量にﾚｽしてるとか
ﾏｼﾞでﾚｽしてて恥ずかしくないのか。。。
>>151
思考範囲を少なくできるのがメリットと言ってるじゃん・・・
グローバル変数をいじるような事をしない限り、オブジェクトの範囲（引数も含めて）だけ考えて書ける。 >>143
そっか、お前らサルってメリットがどういうものか知らないんだな
メリットってのはお金を産まなきゃ意味がないんだぞ
具体的には工数削減と品質向上だ
工数削減はわかると思うが、さらに品質向上には基準が必要だ
これらの数字を具体的に変更して初めてメリット足りうる
おｋ？ >>155
意図が伝わらなくて残念だったけれども、scopeの切り方にはいろいろある。
そのうちオブジェクトスコープならではの長所と短所をあなたなりに聞きたかったんだよ
>>155はscopeの一般論でオブジェクトスコープならではのものではないんだよ さわれないようにすることで
未然に事故を逓減できるからな
事故がおきてもしょうがないですむようなｼﾛﾓﾉなら
事故がおきてもしょうがないですむ
で、そういうとこは低学歴しかいない
低学歴だからしょうがないですむ
>>154
何であなたはここにいるの？
あなたはこのｽﾚの趣旨に対して議論するレベルの資質を
残念ながら見受けられないよ
かわいそうだけども >>155
できないよね？
c言語時代のやり方で組んだら関数の引数で受け取って終わりだけど
メンバに内包するクラスのインスタンスは影響範囲を広げる上にprivateは見えない いくら低学歴が強がってもﾑﾀﾞだからな
もうな低学歴なのはばれてる
>>159
このスレにいるのは
俺にはサルしか見えない
メリットも見えない技術を使って悦にいってるような雑魚は
そもそも技術者でもプログラマでもなくてサルだろ ﾎﾝﾄなかわいそうなぐらい頭ﾜﾙｲ
こんな頭ﾜﾙｲのが現実にいるわけだからな
生きていくのが困難と考えられるぐらい頭ﾜﾙｲ
>>157
メンバ変数の管理の責任をオブジェクトに押し付ける。
privateなメンバ変数はsetで変な値は弾くべきだし、フォーマットしてもいい。
publicなメンバ変数はどういじられようが構わない（責任の放棄） >>163
俺はサルではなく技術者でありソフトウエア開発者でありプログラマだよ >>166
だったら自分が使ってる技術のメリットぐらいは説明できるようにしとけサル >>165
それはobject/instanceというものにあえてscopeをもたす、メリットとは違うのでは？
言葉足らずのコミュニケーｼｮﾝいれ違いなのかもしれないけど
>>167
sttaic scope、extent、階層化、と再帰とか局所化とか組み合わせとか
さんざ書いてもポエムとかこ馬鹿になれてきた俺にそれを言うかあんたは >>160
メンバに内包するクラスのインスタンスは影響範囲を広げる上にprivateは見えない
低学歴な俺に影響範囲を広げる例を示していただけないだろうか？
出来ればc++で。 >>168
だからテメーのは全部工数削減と品質向上に結びつけての説明ができてねーんだよ
今のままだと全部お前の思い込みじゃん 低学歴知恵遅れは
ﾌｧｲﾙﾎﾟｲﾝﾀの現在の状態を気にしながら
ﾌｧｲﾙﾎﾟｲﾝﾀ使ってるのか
とりあえず頭悪すぎるわ
ま、いいんだよオレが5chでばかにされようがどうしようが。
問題はオブジェクト指向を使ったソフトウエアの表現手段が
実は幻想でみんなだまされていたんじゃないかってことに対する
有効性を示す科学的工学的根拠がいまだかつて
まったく提示されていないこと
>>169
は？
c言語の関数と比較した話をしてやったよな？
あれで何でわかんねーの？
サルは違うな ちなみに
ﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀもその先に構造体もってるからな
低学歴知恵遅れにとってはそれはただの整数だからな
ただの整数に見えることを
低学歴知恵遅れは幸せに思わないとな
>>174
便所の落書きはチラシの裏にお願いします >>172
ん？メリットがねーんだから
一旦オブジェクト単位に直す工程が必要になる
オブジェクト指向なんてやる意味全くねーだろ
何でオブジェクト単位に直すの？
つまりオブジェクト指向のメリットがないなら無駄な工数を浪費してるだけ
ハイ、説明終了 ﾌｧｲﾙﾎﾟｲﾝﾀすら分かってない低学歴に
ﾚﾍﾞﾙが高すぎるのは分かるわ
そのﾌｧｲﾙﾎﾟｲﾝﾀはﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀも内包してるからな
ところがオブジェクト指向を使ったプログラミングでも
頑張ればソフトウエアは作れちゃうんだよ
gotoを乱用しても頑張れば出来ちゃう
でも規模に応じた複雑度が急に増大する
似てるんだよ
>>178
くだｽﾚ、入門ｽﾚにこもっていてください オブジェクト指向のメリットを享受するは非常にムヅカしい
というか非常に応用に限定的
かつ人によってでたらめ
10行程度のコードを書いているやつは
オブジェクト指向のメリットを理解できない
なぜか？
それでも、ものすごく頑張れば
それを使ってソフトウエアを書くこと
「も」できる。「も」だ。
でもたいがい汚くなる
なぜなら…
続かないかもｗ
つーか単に長年浪費してしまったから
今更オブジェクト指向を否定されちゃうのが怖いんだろ？
そういうのサンクコストって言ってすでにどうしようもないんだぜ
今わかって良かったじゃねーか
俺はかまわないよ
結構迷惑したけれどもね
でも日本のIT産業は悪い影響受けたんじゃないかな
低学歴知恵遅れがいくらわめいても
FILEﾎﾟｲﾝﾀは普通に使えるからな
>>173
サルでも理解出来ないから例を出してと言った。
privateな値はgetterで見ればいい。
publicでメンバ変数持ってるの？ >>189
いや、そもそもそんなこと無意味だよね？
普通にc言語の関数じゃダメなの？ この部分でｵﾌﾞｼﾞｪｸﾄ指向が破たんするなら
ﾌｧｲﾙﾎﾟｲﾝﾀでも破たんするからな
ぜんぜん極論じゃない
むしろﾌｧｲﾙﾎﾟｲﾝﾀをより安全に使える可能性があることを
示唆している
低学歴知恵遅れはﾎﾝﾄ頭ﾜﾙｲわ
>>189
お前はこのスレの中でもひときわレベルが低いから
お願いだからもうこれ以上、何一つ発言しないでくれ
言わなきゃ分からんみたいだから一度だけ言う >>194
そりゃまﾌｧｲﾙﾎﾟｲﾝﾀより安全だけれども
そりゃscopeとかリンケージでまもっているからで
オブジェクトにscopeがひもつくことによるメリットとはちがうて
議論してきたつもりだなんだがな
あんた、言っちゃー悪いが池沼かよ
俺は相手しているほどひまわないぜよ 低学歴知恵遅れはﾘﾝｹｰｼﾞの意味が分かってて書いてるのか
あやしくなってきてるわ
とりあえず、救いようがないぐらい頭ﾜﾙｲのだけは分かったわ
今後こて張っておお願い
将軍様とか
池沼乙とか
好きなのでいいから
逆に、古典的なｗｗ オブジェクト指向プログラミング手法を使ったら
ややこしく込み入った大規模ソフトウエアの開発が
あーら不思議、こんなにスムーズに成し遂げられちしゃいましたー ﾃﾍﾍﾟﾛ
みたいないい話は話はないものかね…
オブジェクトscopeの有効性すら確認できないとなると
1983年Stroustrup,のC++ cfrot以降から現代までの
ＯＯＰの流行とは、一旦壇だ他のであろうぁという振り返りの
話になってしまう
オブジェクトscopeの有効性すらだ
オブジェクト指向は人間のメンタルモデルと一致しているから
人間が理解しやすいっていうのがオブジェクト指向の一番のメリット
つかメンタルモデルって何だよｗ
生暖かくスルーしようと思ったが
突っ込みどころ満載じゃないか。
感覚でソフトウエア開発の仕事上受けて
周りに迷惑かけるなよ
一時期はやった意識高い系かよ
>>205
3歳児がパパ、ママ、ワンワン、ニャンニャン言うのは分かる。
がしかし、それとC++などの言語によるオブジェクト指向プログラミング手法で
大規模ソフトウエアシステムを構築する工学的な手法と何の関係があるというのか…
いろんな人の意見を聞くのは嫌いじゃないが、
多分この辺が1つの、1つのだよ、
日本のいわゆるオブジェクト指向論者の
ほんと限界なんだと思うわ
しかたない、しかたない、2000ﾝ3ﾝ前まで弥生縄文で争っていたのが
ここまで発展してきたともいえる、
が、しかし、臨界点の低さにげんなりするがこともあるが… なんでこんなにレベル低いのかというと、まとまった規模のソフトウエアを作成できない
人でも一家言 くちをはさみやすいからなんじゃないだろうかと常々思っているわけよ
米国で上位1%が富の独占をしている大きな理由は、労働者をスキルや成果で大きく選別しているからだ。
しかしながらそうでもしないと、ドラクエ10の下請けのように、コードの質が大きく落ちてしまう。
俺はドラクエ一筋なんてのはむしろゴミなコードを入れてしまう『有害な』働き者なのだ。
それは中小企業のデスクワークによくありがちな、要らない書類ばかり作って俺は仕事ができるみたいなものだ。
提案広場でよく『そう思わない』される理由
http://dragon-quest.me/dq10/27646/
このゲームすぐ持ち物いっぱいになるな
http://dragon-quest.me/dq10/28435/
【ドルボードGP】おいｗデスルーラ作戦晒すなやｗｗｗｗｗ
http://dragon-quest.me/dq10/28002/
でも月額千円では、下請けプログラマーの選別なんて出来っこないだろう？
＞このゲームすぐ持ち物いっぱいになるな
ゲームの仕様について意見を出すと、必ずといっていいほどに『そう思わない』で真っ青。
つまり準廃プレイヤー＝下請けプログラマーには、ゲームの仕様を変える能力が欠如しているのだ。
アルバイトの賃金が低いのはスキルを必要としない単純作業だからで、労働者にスキルを求めるのであれば、
アルバイトよりも高い賃金を上乗せして払わなければならず、更に成果に応じた報酬も必要となる。 いわゆる、間口が広くて奥行きが浅いって奴か…
まぁそういうものもこの世には必要だわな
居酒屋みたいに
>>207
だから、
オブジェクト指向をベースに、言語システムを組み上げていくか
構造化をベースに、言語システムを組み上げていくかの違い
別に構造化でも、頑張れば今のオブジェクト指向に匹敵する言語システムを組み上げるのは不可能じゃないよ
その一つがファイルハンドルなんかだよ。でも途中で頑張るのをやめた。
なぜか？オブジェクト指向の方がわかりやすい（人間のメンタルモデルに一致してる）から 人間のメンタルモデルとか実体のないものを持ち出すことだけはめなよ
オブジェクト指向や構造化に実体なんかあったのか？
考え方だよなぁ
>>213
ｱﾙに決まってﾝじゃん。ないと思うなら学会でそう発表してみなよ
今までの歴史を否定したとパッシングのみならず学会から抹殺されるぞ >>213
付け加えるならばあんたのひとことは
歴史のみならず現在のソフトウエアの存在
構築してきたあまたの努力にたいする否定だな
それはもはや ﾊｯ、、ということは
オブジェクト指向論者は、
実はソフトウエアの開発を
冒涜していたという結論かよ…
なんてこった
どうりでＩＴ産業が劣化の一途をたどるわけだ
>>214
> ｱﾙに決まってﾝじゃん。ないと思うなら学会でそう発表してみなよ
あると思うなら学会でそう発表してみなよ。
お前が発表できないってことは、どういう意味かわかるよな？ｗ
ほんとなぁ、こうやって別の努力が必要なものを持ち出してきて
批判したつもりになって恥ずかしくないの？ｗ >>215
オブジェクト指向言語と
オブジェクト指向をごっちゃにしないように
オブジェクト指向は考え方。
アセンブラを含めどんな言語でもできる
つまり実体のない物 言語が少しずつ進化していることと、
オブジェクト指向のメリットを端的に説明することを分けて議論するのは
便所の落書きでは無理でしょ
議論にも訓練が必要だし、
学会で発表するくらいの論理だった説明が不可欠
俺も可読性以外でこれと言ったメリットは
マルチインスタンスくらいしか理解していないけど
オブジェクト指向言語は○○が可能な言語ではなくて
○○がやりやすい、わかりやすい言語
メリットは○○とか言ってしまうと、オブジェクト指向じゃなくてもできますー
とかいうやつが出てくる。実際にできる。やりづらいだけで。
結局の所、同じことをするのにどっちがやりやすいか？わかりやすいか？という
主観の問題になってしまう。実際のコードをみると明らかに
オブジェクト指向言語の方がわかりやすいのだが、
そう思わない人もいるから話がまとまらない
結局、メリットの意味がわからないからわかりやすい（は？誰が？）とかいうくだらないモノをメリットだと主張してしまうサルばかり
正直、お前らは農業でもやってるべきであってプログラマになるべきではなかった
>>223
どこに工数削減と品質向上に結びつけてオブジェクト指向のメリットを説明できた奴がいるの？ とはいえ、頭でっかちの論文より、現場の声は聞きたいね
JavaのSwingを見たとき、GUIの可読性は純粋に気持ちよかったけど、
いかんせんネイティブのGUIにはかなわず死亡したな
自分の主張する技術のメリットもわからない奴はサルだろ
恥ずかしくないのか？
>>225
こうやって説明もなく関係ない話をし始めるバカもいい加減死ねよ
オブジェクト指向と何か関係あるんですか？ メリットはカッコイイからかな。それっぽく複雑にすればするほどいい。文系の低能共を一発で黙らせる効果がある。
>>227
オブジェクト指向言語でGCもあるJavaでGUIをプログラミングするとわかりやすいよ、では？ >>230
なにそれ？
オブジェクト指向のメリットを説明するのに必要なの？ 手続きこそが中心である！
いやいやデータを処理するための手続きっしょ？
つーかそれセットでいいんじゃね？
オブジェクト指向誕生の瞬間である
オブジェクト指向のメリットは
可読性だろ 作ったやつがバカだろうと
バカなりの考え方が追える
>>231
話題も面白くもない、
馬鹿すぎて皆の勉強にもならない、
Goをスクリプト言語と言ったり知識も少ない、
知識レベルが少なすぎて回答(質問スレ)やサンプルコードに嘘が入ってる、
煽りマシンとしても無能で煽りで誤字する、
困ったら精神崩壊。
ホント無益かつ有害だよね。 なんでもクラスに突っ込んで、それほとんどstatic変数使ってんのと一緒じゃん
ってコードになる。
図星低学歴知恵遅れが発狂してんのか
ｵﾚの正確無比なﾜﾙｸﾁに耐えられないのはわかる
ｵﾚは正確無比なﾚｽしかしてないからな
オブジェクト指向のメリットを知りたかったら
侍エンジニア塾がいいゾ
ちらっと見たけど
良くある入門書とそんなに変わらないような感じ
記事が多いみたいだから殆ど見てはいないけど
何か決め手になる記事ページとか有るのかね?
良い解説サイトが出現するのを
結構期待している
それにしてもなかなかそういうのが出てこない
設計ろくにできないやつは何指向だろうがくそなものしか作れないよ
普通に書いていれば、c言語よりc++の方が可読性は上だけど、インターフェースが〜、細分化が〜、とかなってきたら途端に複雑怪奇なデスマコードが出来上がる。
>>250
インターフェースが〜細分化が〜をC言語でやったも
複雑怪奇なデスマコードになるんだろ？
お前が作った場合は >>251
別人だが、
お前が作れば大丈夫なの？
本質的に抱える問題を
お前だけは回避できるというの？ >>252
同じものを作るという前提なら何を使おうが一緒
むしろC言語でオブジェクト指向するほうが大変 >>253
しなきゃいいだろそんなMotifみたいな変なこと Motifと同じことをMotifみたいなことをしないで実現するって話？
どうぞどうぞｗ
誰もそんなこと言っていないのに、
釣り針も付けて無いのになぜか変な魚がつれたよ
？ 単に一方では数行で終わるCLIツール
もう一方はGUIアプリで比べてオブジェクト指向は大変と
いうような間抜けを排除してるだけですよｗ
OOPがそんなにもクソで
諸悪の根源だと言うんなら
お前らはどんな環境で
どんな幸せを享受してんだ
OOPLを捨てたらそんなに幸せになれるのか？
>>260
チックじゃなくてCそのもので書けば良いんだよな？
だってOOPはクソでOOPLなんて不要なんだから オブジェクト指向は諸悪の根源
ちけえねぇやっぱり関数型がナンバーワン
相対性理論や進化論と同じで一見簡単そうに見えるからアホが寄ってくる
構造化プログラミングからのオブジェクト指向が理想的
そもそもこの板はｱﾎしかおらんやん
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向なんかﾑﾘだからな
>>266
『チンポ』を、チンコと呼ぶかチンボと呼ぶかについて。
チンコ→チンポは俺の『ムスコ』だ！
チンボ→チンポが棒のように硬くなった！
実に奥深いだろう？ >>105
＞夏目くんのチンポは何にも触れていないのにシコシコしている！
ムスコがボーになってしまった！ このつまらんチンポネタいつまで続くんかね
どーせやるなら笑わしてくれや
なぜ荒らすのか、荒らしなりに理由はあるんだろうな
オブジェクト指向を標的にしてるとか、
病的な信者のなれの果てか
・独立性が高い
・独立性が高い
・独立性が高い
１）影響範囲を局所化する
プログラムの世界で「独立性を高める」というのはどういう意味があるかと言うと、
例えばバグが発生した場合に「その処理はこのクラスで行っている処理なのでこのクラスだけ修正すればいい」とか、
仕様変更が発生した場合に「その機能をまとめているクラスはこのクラスなので、
このクラスのインタフェースを修正すればいい」というように、何らかの変更が発生した場合に、
すでに作成した特定のクラスのみ修正すれば対応できるようにうまく設計されていることを、オブジェクト指向では
・独立性が高い
という。
https://simizuna.exblog.jp/1603061/ でもオシッコを我慢する時は、チンポに力を入れて小便が出ないようにコマンドするけどな。
俺にとっての『オナニー』は、するしないではなくて気がついたらしていたのであり、
オナニーはそこにあったのだ。それはチンポがそこに付いていたのと全く同じだ。
真性の基地外ならそれはそれで面白いけどただの無能だからつまらんな
>>281
俺はただパソコンに向かって独り言ブツブツ言って、チンポがシコシコしてるだけだが？ >>287
オブジェクトの独立性が大事だってことだよな。 >>288
せやね、いらん時にもシコシコするけどな >>105
＞夏目くんのチンポは何にも触れていないのにシコシコしている！
チンポがシコシコしてしまったら、
>>277
＞その処理はこのクラスで行っている処理なのでこのクラスだけ修正すればいい
急いでトイレに駆け込め！！！ あるいは学校へ行く前にズリネタを探してチンポがシコシコしてからオナニーしておくとか。
チンポは独立した生き物なので勝手にシコシコしてしまうが、素早く検知してトイレに駆け込めばセーフ！
口座残高管理や在庫管理のようなイベント主体のドメインはOOPではどう実装しますか?
一般的な方法だと↓のようにDBにドメインロジックを書くと思います
追記型のテーブル(入金テーブル, 出金テーブル)に行を挿入→トリガでスナップショット(口座テーブル.残高)を更新
アプリケーションは単にテーブルへの挿入とスナップショットの取得を行うだけです
これは非常にクリーンな構造だと思います
OOPの場合はDBにドメインロジックを置かないので必然的にトリガを使わない実装になりますが
その場合にクリーンな実装が想像つきません
>>293
違うレイヤーの話がごっちゃになってるね
ぶっちゃけDBにドメインロジックなんか普通は置かないんだがｗ
まずドメインロジックをDBに置くかどうかって話はOOPかどうかとは無関係
前提としてDBは（オブジェクト指向ではない）RDBと
（オブジェクト指向の）OODBとがある
RDBしかないと思いこんじゃってるだろうけど
ドメインロジックをDBに置くかどうかの話は、前提として使ってるDBに
ドメインロジックを置く機能が存在しているかどうかそれを使うかどうかで決まる。
そしてDBがOODBであればドメインロジックはオブジェクト指向になるだろう
つまりだ、キミが言っている
> 一般的な方法だと↓のようにDBにドメインロジックを書くと思います
というのは、
（オブジェクト指向でない）RDBに以下のようにドメインロジックを置けば
（オブジェクト指向でないものとして）クリーンな構造だ
と言ってるに過ぎないんだよ。キミがクリーンな構造だと思ってるのはRDBだから
逆にOODBを使ってドメインロジックをDBに置けば
これは非常にクリーンなオブジェクト指向の構造になるわけだ
まあ、ここまでは理想論的な話。それをクリーンな構造だと思うのは
単にRDBを使ったからだろというツッコミ 現実的な話としては、OOPを使ってDBはRDBを使って、ドメインロジックをDBに
置かないってことはよくあるね。
その場合、言語はOOPなのにDBはオブジェクト指向でない。
これはOOPとRDBのインピーダンスミスマッチと言われている有名な話
それを解決する一般的な方法はO/Rマッパーを使うということだよ
ほぼすべてのフレームワークにあるからO/Rマッパーは自作する必要はないぞ。
O/Rマッパーを使うことで、オブジェクト指向でないRDBの詳細を隠して
オブジェクト指向として使うことができる。背後のRDBの存在は忘れていい。
Bにドメインロジックを置かないとか、トリガを使わないとか関係ないんだよ
だから別のレイヤーの話
OOPの場合はO/Rマッパーを使うことで、データをオブジェクト指向で扱える。
すべてオブジェクト指向でプログラミングできるクリーンな実装なわけだ
Hibernateを使おうが、何使おうが、業務ロジックでオブジェクト指向が銀の弾になることはないぞ
あと、DBMSのトリガーと整合性制約でDB更新なんて保守性が落ちるからやめた方がいい
バッチだと普通に対象レコードでカーソル回すしかないんじゃないの？
オンラインのイベントはそもそもキー指定できるだろ？
オブジェクト指向でなくても、銀の弾なんてないからなぁ
より良いものが、オブジェクト指向ってだけで。
なにを言ってるのかよくわかりません
イベントが主体となるドメインをOOPで実装する場合の最適解を模索してます
ORMの利用は当たり前のはなしであって今はそんなレベルの話はしてません
>>297
オブジェクト指向でどのへんが助かった？
俺の回り(メガバンク案件)ではメインフレーム以外ではPL/SQLでやってた頃のほうがよかったねって
ファイナルアンサーになってるんだけど、たの業種はどうなんだろ？ >>298
> イベントが主体となるドメインをOOPで実装する場合の最適解を模索してます
だからOODBを使えばイベントが主体となるドメインをOOPで実装できる
それともイベントが主体となるものをDBの機能を使わないで
実装するにはどうすればいいのですかって話ですか？
手続き型ならどうやるのよ？これ重要なところだから
考えてみなさい（できれば答えてみなさい。）
質問のレイヤーが違ってるのよ
オブジェクト指向の話とDBの機能の話はレイヤーが違う話 >>299
> オブジェクト指向でどのへんが助かった？
バッチ処理以外全般 オンラインはServret一辺倒で必然的にJavaで書くけど、
業務ロジックなんてバリエーションくらいで後はホストに投げるだけだし、
Javaだから楽ってこともないな
ただのﾃﾞｰﾀの永続化の問題
しかも永続化の方法をなんらかのDBに限定してる話だからな
ｺﾚが低学歴知恵遅れのｵﾌﾞｼﾞｪｸﾄ思考
>>301
バッチ処理以外って例えばWebだとして、
JavaのほうがCよりはずっと書きやすい読みやすいけど、
オブジェクト指向だから書きやすいのではなくて、
単にメモリ管理や文字列などが分かりやすいだけだわ、俺の場合 >>300に自己レス
どうせ消え去りそうだからｗ
> 手続き型ならどうやるのよ？これ重要なところだから
> 考えてみなさい（できれば答えてみなさい。）
これどういう意味かというと、
イベント（トリガー）が主体となる処理をDBでやる場合
RDBの機能で行う・・・手続き型
OODBの機能で行う・・・オブジェクト指向
ってことで、手続きもオブジェクト指向もどちらもあり得るんだよ
で、トリガーが主体となる処理を、アプリ側で行う場合、
手続き型・・・どうやるの？（できません）
オブジェクト指向・・・どうやるの？（できません）
ってことで、手続き型でもできないってことなんだよ。
手続き型でもクリーンな実装は思いつかない
ようするに>>293が卑怯（あえて卑怯という言葉を使うｗ）なのは
アプリ側でできない処理を手続き型ならDBで実装して
オブジェクト指向では、DBで実装してはいけないと言ってること
オブジェクト指向でも、DBで実装すりゃいいじゃん。
どうせそこでしかできない処理なんでしょ？
それがアプリ側でオブジェクト指向使うのと何の関係があるの？
レイヤーが違うでしょという話 >>304
> 単にメモリ管理や文字列などが分かりやすいだけだわ、俺の場合
俺の場合、フレームワークが使いやすいだけ
だけどそのフレームワークでオブジェクト指向が使われてる
なぜか？オブジェクト指向が作りやすいからだろう
オブジェクト指向っていうのはフレームワークを
作るためのものと言っても過言じゃないよ
直接オブジェクト指向を使ってなくても、
その使いやすい環境（フレームワーク）が作れるのは
オブジェクト指向だから 低学歴知恵遅れが設計するようなﾃﾞｰﾀ構造では
なにを使おうがｺﾞﾐにしかならない
透明なｺﾞﾐ袋になるか中身がみえないｺﾞﾐ袋になるかの違いしかない
詰まってるものは同じｺﾞﾐ
結局のところ
OOPは万能ではなく苦手な分野もある
業務の多くはOOPの苦手な分野とかぶっている
ということなんでしょうか
OOPはリソースの扱いと相性がいいですが
業務はOOPと相性が悪いイベントのほうが圧倒的に多いんですよね
そりゃ、万能なものはなにもないんだから、
手続き型もオブジェクト指向も苦手な分野はある
> 業務の多くはOOPの苦手な分野とかぶっている
そんなことは一言も言ってない
> 業務はOOPと相性が悪いイベントのほうが圧倒的に多いんですよね
全然そんなことはない。
単にお前の「業務」がそうってだけだろう
イベント駆動に相性がいいからGUIに多様されてるんだろ？
DBMSのイベント駆動ならOracleに閉じた世界でもできるけど、流行らないだけ
イベントドリブンとオブジェクト指向は相性良いじゃん
>>312
今の話は、DB側への操作によるトリガーを
どうやってアプリ側に伝えるかという話で
それは手続き型でも難しい事で全く関係ない話だけどねｗ >>310
事実ですよ
業務システムの大部分は事実の正確な記録を重視します
つまり何がおこったのかという記録==イベントの記録ですね そんなもんｲﾍﾞﾝﾄが発生するたびに
DBなら特定のﾛｸﾞ（履歴）ﾃｰﾌﾞﾙに書き込む（記録する）だけでおしまい
しょうもない
さすが低学歴知恵遅れ。。。
もしかして低学歴知恵遅れが作ったｼｽﾃﾑでは
あちこちのﾃｰﾌﾞﾙにﾕｰｻﾞｰの客の行動履歴みたいなもん保存してんの？
あったまわるう。。。
>>314
ようするに「データの保存」のことを
語ってるだけですよねｗ
> つまり何がおこったのかという記録==イベントの記録ですね
DBのトリガーのことをイベントといっていたかと思えば
今度はデータの保存のことをイベントというのですか
そうやっていろんなことをごちゃまぜにして考えるから
お前はいつになっても理解できないんやで まずそんな作りになってたら
ﾃﾞｰﾀ分析にすらまともに使えない
低学歴知恵遅れがｼｽﾃﾑ作ると
ﾃﾞｰﾀを分析するﾃﾞｰﾀを作るのも大変になるのがよく分かったわ
半角さん、いよいよレスも返してもらえなくなったんだw
半角さんは職歴の事語らないけど、多分ド底辺四次受けとかなんだろうな。
それぐらいの知識も無いんだけど。
この板にいるような低学歴知恵遅れが作ったOODBなんかで保存された日には
まずﾃﾞｰﾀ分析で使えるｼﾛﾓﾉになってないことは断言できる
つまり業務ｼｽﾃﾑとして動いてるようにみえてれば
なんでもいいという世界で間違いない
RDBなら致命傷にならずにまだなんとかなる
なぜオブジェクト指向で作るのかって本ではジャンケンゲームの例があったな。
CPUvsユーザーの2人(？)版を作って、それを3人4人と増やしたい時、オブジェクト指向の方がコード修正しやすいみたいな。
その時はそうかと思ったけど、後から考えたら別に構造化プログラミングでもそんなに修正しないで済んだ。
パッと浮かびにくいとか、そういう問題だったのかも？とは思いもするが、オブジェクト指向の例を先に見せられたからかもだし、うーん。。。
>>323
マルチインスタンスのメリット説ね。
実は全然ありがたくないというのに気づくのけっこうかかったわ まずｵﾌﾞｼﾞｪｸﾄ指向も構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞも
どっちもまともに理解できてないのが
知ったかでﾃｷﾄｰに書いてんのがﾊﾞﾚﾊﾞﾚなﾜｹ
>>318
私は最初からイベントをデータとして認識してレスしてますよ
リソースとイベントを意識してテーブルを構成するのは基本中の基本なのであえて説明してから議論するまでもないと思っていましたが
まさかこの文脈でイベントドリブンのイベントと勘違いする人がいるとは予想外でした 低学歴知恵遅れは目の前の作業しかみえないからな
その作業でなにをしてるかという感覚すらないからな
動けばいい
それだけだ
>>328
レコードの更新をハンドリングすることと同じじゃね？
イベントドリブンBeanとDAOを連携させる試みは流行らなかったけど それぜんぜん違う
やばいわ
DBﾄﾘｶﾞｰの意味すら分かってない
ﾏｼﾞで低学歴知恵遅れしかいない
頭の悪い人が何か勘違いしてオブジェクト指向を使った
変なコードを書いていることがよくあるという意味では
半角と同意だな
この板では
基本的なことが分かってないようなのがﾄﾞﾔ顔でﾚｽしてるﾜｹ
珍妙なｺｰﾄﾞができあがるのも必然
>>334
にわかオブジェクト指向厨は
べつにこの板に限らず世に広く
ナンセンスなことを言う人が多いよ
半角様も含めてね むしろｵﾚﾚﾍﾞﾙでないとｵﾌﾞｼﾞｪｸﾄ指向はﾑﾘ
なんどもいうが
低学歴知恵遅れとｵﾌﾞｼﾞｪｸﾄ指向は
ｷﾁｶﾞｲに刃物
残念なことにまともな教育を受けてれば
低学歴かどうかなんかﾚｽからすぐに分かってしまう
低学歴なうえに著しく知能が低い
その自覚がない
そして自己評価だけは高い
つまりこの板の低学歴知恵遅れは救いようがない
>>328
> 私は最初からイベントをデータとして認識してレスしてますよ
誰も「お前がイベントをデータとして認識してない」なんて
言ってないんだが？ あたま大丈夫か？文章読めるか？
お前は、
DBのトリガーのことを "イベント" といってたのに
データの保存のことを "イベント" と言い出した
そういうことを俺は言った
なんで俺が言ってないことに、話すりかえてんの？ >>39
って良書？
もしかしたら昔原書を買ったまま本棚に積読してあるかもだけど、
良書なら暇があったらめくってみようかなって気になった。
やっぱオブジェクト指向を使ったソフトウエアの表現て、
実践の場では意外と難しい局面があって煩わされることもしばしばで、
方法の模索が続いて終らない ID:ZWpnR1MN ってまともに話しているふりして
ただのアンチだろうなｗ
でなければ、こうも関係ない話にすり替えたりしない
>>328
で結局何の話したいの？
そのクリーンな実装とやらのアーキテクチャの話？ 何かをトリガーに何かしたいなら関数オブジェクトなりデリゲートなりなんなりぶちこんで何か起きたら呼べ
そんなんオブジェクト指向だろうが関数型だろうか変わらん
>>340
本棚の奥から
蒼い表紙に眼鏡をかけたカモノハシが見得のポーズを切って卵を守っている絵の
An Introduction to Object-Oriented Programming
Timothy Budd
が発掘できたぜよ。でも1991年のfirst editionだた…orz
羽部さんの訳ってどうよ？
良ければ3rd Editionの訳を書店で眺めてみるけど。 >>343
でもなぁ、こいつが言っていたイベントはRDBのトリガーで
（途中でイベントの意味を変えてきやがったがｗ）
RDBのトリガーの内容をアプリ側から知るのは（オブジェクト指向じゃなくても）
手続き型言語で知るのは難しいぜ。RDBにそういう機能はないからな ｵﾚは書籍の内容について批評はしない
確かなことは書籍は読む人間を選ぶとことになる
頭ﾜﾙｲのがいくら本読んでもﾑﾀﾞだからな
なにが書いてあるかを理解するのは自分自身だからな
T字型ERデータベース知らん人って思ったより居るんだね
オブジェクト指向の最大の弱点は学んだ人がオブジェクト指向は銀の弾丸だと勘違いして他のテクノロジをおろそかにしてしまうことだな
>>346
訳は上手いか聞いたんだよ。日本語OK?
first editionをぱらぱらめくってみたけどほとんど基本的な内容だった。
Chapter 15のVisibiility and dependenmcyは80年代後半の
ソフトウエア工学の話題とOOPの関連性が書いてあって多少面白そう 正直でよろしい。
3rd ed訳を立ち読みしてみようかと思ったが
そのへんの店舗では扱っているところが少なそうだな…
訳は2002年の2nd edまでなんだな、しかも￥4,723 て
ぼるなあ
ハイ、ここまでオブジェクト指向のメリットなしのクズ男
半角さんの言うことは正しいよ
> 低学歴なうえに著しく知能が低い
> その自覚がない
> そして自己評価だけは高い
その場にいるほかのメンツの力量判断できないから
一人だけ調子に乗ってしょーもないことを得意げに演説
一人だけ周回遅れの子ってのは滑稽であり悲しくもある
自分が賢いかのような口調で演説するからいたたまれない
>>357
「頭の悪い人はバカ」って、何の話してんだよ、
オブジェクト指向がクソか どうかだろ
そういうのを頭が悪いと言うんだよ ここまでオブジェクト指向のメリットも挙げられないクズ
早く死んで欲しい
バグコードを内包するクラスを多重継承させてたりしたら結局何のためのカプセル化なんですかって話になるんだよね
>>362
それバグを内包するクラスが悪いって話ですか？多重継承は関係なく まぁ一人で作ってるわけじゃなくて何十人も絡むプロジェクトだと「どのモジュールが悪いのか」って
切り分けは必要だから仕方ないんだけど効率悪いよね
>>364
継承を通じてバグコードの影響が複雑に伝染することや、多重継承によってクラス間の依存度が高まることでデバッグが難しくなってしまうのが問題の本質なんだから、純粋に多重継承の問題だよ >>366
でもバグがなければ、何も問題ないですよね？
えと、バグが無いという前提で、
何が問題かを語ってくれませんか？
どうもバグに話をすり替えているようにしか見えませんから >>367
そもそもバグコード生成や不具合発生が避けられないものであるという前提で話が出来ないのかな？ デバッグが困難になる（特に>>366みたいなアホには）って言うのはまあわかるとして
> 結局何のためのカプセル化なんですか
にどうやって繋げるつもりなんだ？ w >>242
今ニュース系サイトで見たんだけど
そこ炎上してたんだwww どっちもどっち。
大元のクラスライブラリにバグがある事もあるし、100%バグの無いコードは事実上不可能だから、バグが無い前提は流石にあかん。
然りとてバグコード含んだクラスを継承というのも行き過ぎで、十分なデバッグやテストを通してから継承するもの。
理想と現実の狭間で最善尽くすだけ。
上でも何度も言われてるが、オブジェクト指向は銀の弾丸では無い。
>>371
みたいなしょーもないシッタカ意見を排除することからはじめたい >十分なデバッグやテストを通してから継承するもの
?????????????????????????????
そもそも関数で組んでれば依存がないものを
メソッドにすることでメソッド同士でメンバ変数を共有することになるのだが
これはいいことなのか？
>>368
> そもそもバグコード生成や不具合発生が避けられないものであるという前提で話が出来ないのかな？
はい。だから問題はバグってことですね >>371
> 上でも何度も言われてるが、オブジェクト指向は銀の弾丸では無い。
それどころか、手続き型も構造化も関数型も銀の弾丸ではない
なぜオブジェクト指向だけを違うと主張するのか？ >>376
あふぉか、
なんらかの弱点があるから、どの方法も無意味だとでも言いたいのか
オブジェクト指向には、
特に問題があったのではないだろうかって
いままでさんざ議論してきて
何だそのﾚｽは それはオブジェクト指向の有効性の議論は
中身はなかったと同義だぞ
>>376
誰もオブジェクト指向だけがなんて言ってないし。
そういうのは、それぞれのスレでお願いします。
もしくは異種格闘技的なスレ建てて下さい。 >>376
誰もオブジェクト指向だけがなんて言ってないし。
そういうのは、それぞれのスレでお願いします。
もしくは異種格闘技的なスレ建てて下さい。 >>377
> あふぉか、
> なんらかの弱点があるから、どの方法も無意味だとでも言いたいのか
無意味なわけ無いじゃんｗ
あぁ、もちろんオブジェクト指向がってことだよ。 >>374
そこに疑問を持たないチンカスばっかりなんだよね 共有できるメソッドが制限できているので・・・カプセル化全否定？
副作用副作用言うならimmutableにでもすれば？
>>374
フィールドの共有がなかったら全てのフィールドを引数でバケツリレーするようなプログラムになる
引数の数が大爆発して意味不明になるぜ
そもそもフィールドを共有してるから依存があるというのは正しくない
片方のメソッドを消去してももう片方のメソッドは独立に使用し続けられる
なのでそこには依存はないんだぜ オブジェクトに対しての作用としてメソッドが存在するのに、メソッドが同じ変数を共有するって発想自体が意味不明だよな。
フィールドの共有で依存が発生すると主張するのは
引数の共有で依存が発生すると主張するようなものだな
相手のメソッド記述するって結合度気にするなら、全部メッセージでやりとりすれば良い。
宛先と送受信の共通の関数さえあれば結合度気にする必要が無いぞ。
案外、難しく考えない方がいいのかもしれないね
なんか同じこと何度も書いとるなー👉関数
同じ組み合わせの引数ばかりわたしとるなー👉構造体
構造体と関数の組み合わせっていつも同じだなー👉クラス
フィールド直接弄るとバグ出やすいなー👉カプセル化
これでも十分なメリットを享受できる
まずは体感としてこれらのメリットを感じれるまでコードを書く
それから本格的な議論に参加すればいい
逆にこれらのメリットに体感的にすら気付いてないレベルで議論しても時間の無駄だろう
>>390
そっか、お前らサルってメリットがどういうものか知らないんだな
メリットってのはお金を産まなきゃ意味がないんだぞ
具体的には工数削減と品質向上だ
工数削減はわかると思うが、さらに品質向上には基準が必要だ
これらの数字を具体的に変更して初めてメリット足りうる
おｋ？ このスレにいるのは
俺にはサルしか見えない
メリットも見えない技術を使って悦にいってるような雑魚は
そもそも技術者でもプログラマでもなくてサルだろ
>>391
> 工数削減はわかると思うが、さらに品質向上には基準が必要だ
> これらの数字を具体的に変更して初めてメリット足りうる
> おｋ？
結論を言ってしまうと、コードメトリクスだね。
ツールを使って客観的に計測できる >>391
計測すればわかるけど俺が書いたことをやればスコア普通に良くなるよ
誰とは言わないけど感情が全てのサルには理解できないかもしれない
けど計測手段を持ってる人間にとってはオブジェクト指向のメリットは明白なんだよね >>394
じゃあ、具体的に何がどういう理由でそうなるの？ >>395
コードの重複が減る
変数や引数が減る
分岐やループが減る
不正な操作が減る
危険な操作が減る
したがってスコアが良くなる >>396
具体的にどうして？
関数と比べて増える要素はあっても減る要素ないよ 局所的なグローバル変数を使ってるに過ぎないのにメリットなんかねーよ
バカって結論を俺は持ってるけどね
オブジェクト指向のデメリットはグローバル変数のデメリットと同じなんだよ
>>398
お前が言ってるのは、グローバル関数のデメリットのことだろ？ グローバル変数が悪だからって
グローバルクラスも、同じグローバルがついてる
悪に違いない！って考えるのは単なる短絡思考
グローバル変数は丸出しでかつ一個じゃん？
メンバ変数は隠すこともできてかつ複数じゃん？
あと、まとめて隠しとくメリットもでかくね？
int cap = 32, size = 0, data[cap]; // こーいうのより
vector<int> v; // こっちがスッキリじゃね
局所的なグローバル変数で爆笑した
コメディアンの才能あるんじゃないか？
というよりもよく考えたら
> 局所的なグローバル変数
というのが単に誤解なんだよな
struct data {int value;}
void method(struct data *this) {}
っていう単なるパラメータなんだから
おまえら、オブジェクトの意味を知ってて言ってるのか？
知ってりゃグローバル変数なんて意味不明な話しないかw
ここだけ30年前かよ
ぽっくんの業務では当てはまりませんでしたー
ってCOBOLでも書いていたらいいよ
別に困ってないだろ？
>>396
で、なっぜJavaやC++でたコード書くと
あんなことになるんだｗ >>386
それで爆発するならメンバ変数の把握できない状態爆発のが問題
状態を複数持つオブジェクトをクラス内に内包すると単純に乗算でその数が増えていく
状態を10個持つクラスと状態を5個持つクラスがあるだけで取りうる状態数は
50個
ウォーズマンの超人パワー波に状態が増えていく
グローバル変数のまずさはこの把握できない状態爆発が本当の問題
問題の本質もわからないサルがオブジェクト指向なんてありがたがってるだけ >>386
それは別に構造体定義して引数で渡せばいいだけだね。
>片方のメソッドを消去してももう片方のメソッドは独立に使用し続けられる
>なのでそこには依存はないんだぜ
メソッドを消去したらみたいな静的なことは問題にしていない。
メソッドの呼び出し順で動作が異なる点について言及している。
つまり状態を共有しているってことについて。
コードベースで見れば確かに構造体の型とそれにひもづく関数を結びつけとくのは
管理しやすいってのはそうだが上記のデメリットをどれだけ上回っているか。 >>409
そうそう
第一段階: 構造体にして渡せばいいだけじゃん(クラス的発想のスタート地点)
第二段階: っていうか構造体と関数っていつもセットだから一緒に管理しよ(メソッド)
第三段界: 管理されたメソッド以外から弄るとバグでやすいから禁止しよ(カプセル化)
キミが言うように「〜すればいいだけだよね」ってのを素直に実践するとOOPに到達するんだよ
キミも後少しで議論のスタート地点にたてるかもね
キミの考え方だと
funcA(pState);
funcB(pState);
これはfuncAとfuncBが状態を共有しているということになるネ >>410
funcAに特定のpStateを入れて必ず同じ結果が返るならそれはいいコード
異なる結果が返るならさいっこうにクソ
ボディブロー100連発 >キミの考え方だと
>funcA(pState);
>funcB(pState);
>これはfuncAとfuncBが状態を共有しているということになるネ
ならねーよ。
普通に見ればpStateが状態を共有してるってことになるだろ。
どんな馬鹿な見方をするとこんな考え方になるんだろうか。。
補足すると
funcB(pState);
funcA(pState);
にかえると動作が異なるからキミの言い分だと常態を共有しているということだね
さらに最悪なことにカプセル化されてない場合
funcB(pState);
pState->x = 10;
funcA(pState);
みたいなアドホックなコードから状態を変更されるリスクがあるから
事実上プログラム全体で状態を共有しているようなものだね
>>412
>>413でも補足したけどキミが言ったことをそのまま引用したんだよ
呼び出し順で動作が変わるなら状態を共有してるってね >>413
だからいいんだって
テメーのコードは
pState.funcA()
ってやっても
pStateの中身が見えないのが問題なんだよ funcA(pState)「僕が変更したのはpStateだけです、グローバル変数なんて使ってませんよ」
pState.funcA()「あああああ！！！！！！！！
（ﾌﾞﾘﾌﾞﾘﾌﾞﾘﾌﾞﾘｭﾘｭﾘｭﾘｭﾘｭﾘｭ！！！！！！ﾌﾞﾂﾁﾁﾌﾞﾌﾞﾌﾞﾁﾁﾁﾁﾌﾞﾘﾘｲﾘﾌﾞﾌﾞﾌﾞﾌﾞｩｩｩｩｯｯｯ！！！！！！！）」
オブジェクト指向でも副作用って無くすべきだよなぁ
こういうのって手続きかオブジェクト指向しか触ってこなかった人は気づかないもんかな
pState.func()、funcA(pState)
どちらもpStateを渡して呼び出しているし、pStateを変更しただけです！と言えるのでは
副作用が嫌ならimmutable objectにすれば？
もうしっちゃかめっちゃかだな
ホント都市伝説なオブジェクト指向
>>421
privateはデータに直接アクセスできる関数を制限するだけなのに
それを無くしたいは何で？ >>417
ValueObjectからAggregate Rootまで全部イミュータブルにする派閥もあるよ あるメソッドがどのスーパークラスで定義されてて、
それがどのスーパークラスでオーバーライドされてて、
結果的にいま自クラスで呼んでるこのメソッドはどこで定義されたものなのかが
わかりにくいのが非常にイライラすることがあるけどお前らどうしてんの？
真面目にクラスライブラリのリファレンスを愚直に辿ってんの？
>>424
どれが呼ばれて何をやってるかを気にしなくていいように作るのが正解 >>425
そもそも一つ上のスーパークラスで定義されてないメソッドを呼んでるコードを見た時
そのメソッドってどのクラスで定義されてるのかがわからないと、どういう機能のメソッド
なのかわからなくね？
スーパークラスから継承したメソッドはオーバーライドしていなくても全て下位のサブクラスの
リファレンスマニュアルに書いてくれるならいいんだがそうなってないのがイラつくって話 オブジェクト指向と関係あるか不明だけど、一時期関数型言語に嵌って、オブジェクト指向よりも依存性を抑えられて保守性が上がって良いとは思ったんだが、そればかりだとCPUパワーが発揮出来ないんだよね。
(ほぼキャッシュに収まらず、メモリアクセスが増える)
んで、対極のCやアセンブラに手を出した。
今度はグローバル変数が多くなる。
(逆に如何に変数(メモリアドレス)へのアクセス減らしてレジスタ使い回すかで速さが違ってくるから、それはそれで楽しい。ただし8/16ビットに限る。それ以上はハードが複雑になり過ぎる)
結局オブジェクト指向って、その間をとったんじゃ無いかと思うんだよね。(メモリアクセス減らしつつグローバル変数減らす苦肉の策+責任分担)
実際、CからC++への移行期はまだCPUも遅くて、オブジェクト指向にすると遅くなると言う意見が多かった。
(C++やJava、C#、Delphiで一応オブジェクト指向も勉強したけど、効率と言うより保守性や多人数での開発が前提な気がする。コードは全体じゃ増えるけど、このクラスはお前ね。みたいに割り振り易い)
(特にC#は1つのクラスを複数ファイルに分けられるので、メソッド単位で人に任せ易い。個人では逆に分かりにくくて迷惑な機能)
tcl/tkとかある通り、必ずしもGUIはオブジェクト指向じゃ無いと使い難いって事はない。
Haskellだって(関数的じゃないから気持ち悪いだけで)向いてないとは思わなかった。
ただ既にIDEの整っているのがオブジェクト指向ってだけだが、それだけで十分オブジェクト指向を勧める価値はあるんじゃないかな。
C#のpatialは分業のためじゃない
コード生成のためだ
>>427
スピードをとても重視するなら不便でも強い最適化のかかる言語を選ぶしかないだろ
突き詰めればCかFortranかアセンブラしかなくなる
逆にvm上やインタプリタでもスピード敵に問題なければ生産性、保守性、可読性、
依存抑制、独立性、局所性、階層化構造、拡張性を重視していいだろ
ほとんどは後者 そうやってwebみたいにくもの巣状態になるんだよな
>>429
いあ、だから。。。
その中間を目指したんじゃないかと。
関数型言語ほど目指すと遅くなる。
最適化目指し過ぎると大規模開発に対応出来ない。
オブジェクト指向は現実解だったんじゃないかと。 >>435
結果として性能的にそういう位置づけに当たることがあるかもしれないが
スピードのための折衷案を目指して作り出された物ではなく
あくまでソフトウエアの構造を表現する新しいパラダイムを目指していたと思うよ。
少なくとも1990年代初期ころまでは。
あとhaskelやMLの生成するnativeコードは結構早い（といわれている >>433
何処からでも変更できるようにしたいのか
それって… ネットワークとデータアクセスがあるからパフォーマンス上げるなら水平スケールするように設計する
スケール前提だと細かい最適化は非効率的だし最適化のためにメンテナンス性が悪くなって設計ミスってスケールしなくなったら最悪
>>437
うい。
折衷案を目指したのではなく、悪魔で手続き型言語(構造化プログラミング)の延長として保守性を高めた結果だと思う。
代入が(殆ど)無い関数型言語と違って、代入前提で保守性高めた結果。
因みにMLとOcamlはC並みだと言われるが、少なくともHaskellはLL並みよ？
(C並みにするには先行評価しまくるしか無いので、遅延評価のHaskellは「速くできるけど面倒臭い」)
それでも大規模開発に強いから良いんだろうけど、結局どこぞの銀行にはOcamlが採用されてたね。
Haskell好きだけど、現実はそうだよねーって思うよ。
割と前から言ってるけど、関数型言語はアルゴリズムを読むだけで分かる言語なので学習には向く。
アルゴリズムが分からなかったら関数型言語で理解して、オブジェクト指向言語で書くのが現実的じゃ無いかな。 >>440
haskelの生成コードの性能については俺の記憶違いかな。
そうなんだよねC++やjavaは基本的には構造化の延長でstructの
instanceのscopeにmethodを結びつけるscopeingで
ソフトウエアを表現しようとして、非階層的extent, scopeの依存の
ネットワークのわなにはまるんだよ >>441
いあ、記憶違いでは無いと思う。
Haskellも実行速度ランキングで一時期一位取ってた。
ただ、それはソースを読むとゴリゴリに最適化したもので、一般には普通に書くとLL並み。
ランキングは言語の速さだけでなく、信者の意地も含めての結果だと思った。 ｸｷﾞと板がある
ｸｷﾞをうち込んで板と板をくっつける
板と板をくっつけるだけの単純なｵﾌﾞｼﾞｪｸﾄの依存関係でも
それが増えるにつれ、その単純な依存関係ですら低学歴知恵遅れの手にかかると
だれも手に負えないｼﾛﾓﾉになってる
ｵﾌﾞｼﾞｪｸﾄ指向でも構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞでも、低学歴知恵遅れの手にかかれば結果は同じ
ありえないﾃﾞｰﾀ構造になってるというより規格化された構造の痕跡すらない状態になってる
構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞでも要求されるまともなﾃﾞｰﾀ構造の設計ができるという前提条件がなければ
当然ｵﾌﾞｼﾞｪｸﾄ指向でｸﾗｽの設計なんかそもそもﾑﾘだからな
ﾍﾟﾝｷﾞﾝが空飛ぶとか飛ばないとかまずどうでもいいﾜｹ
それ以前の問題だからな
半角ちゃん、たとえ話がくどいよ
人のことをどうこうじゃなく
オブジェクト指向がどうか なぜそういう話をできないんだあんたは
いやペンギンが空飛んだら大事件だろ。
世界中でトップニュースになるぞ。
ｵﾚは明確なｺﾀｴを一貫して書き込んでる
ｵﾚの言説の正しさを補強したﾚｽにちゃんとなってるからな
一切ﾑﾀﾞがない
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向は
ｷﾁｶﾞｲに刃物
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はﾑﾘ
当然、この板にいるような低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はﾑﾘ
わかった？
低学歴知恵遅れには分かんないか、やっぱり
>>446
半分合ってて半分間違い。
知恵遅れに刃物は合ってるけど、だからこそオブジェクト指向でその影響を局所化してる。
構造化プログラミングとかだとグローバル変数が多い分、全体まで影響しかねない。
オブジェクト指向でも構造化プログラミングでも知恵遅れにまともなプログラミングは出来ないのは同意。
だが、周りにかける迷惑の範囲が違う。 低学歴知恵遅れの理解では
構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞはｸﾞﾛｰﾊﾞﾙ変数を使うことになるのか
ｵﾌﾞｼﾞｪｸﾄ指向なら使わないですむと
やっぱり低学歴知恵遅れがいうことは
一味違うわ
>>448
程度問題だよ。
特にGUIでは顕著に違う。
初期化関数とイベントの関数で共通の変数とかね。
イベント関数内で初期化する訳にはいかないって場面は意外と多いよ。 こんどは程度とな。。。。
ｸﾗｽを全部構造体にかえてみ
なにが違うわけ？
構造体にデータと関数ポインタを持たせてOOPってのはC言語でも昔から知ってる人はやってた
言語でサポートしてミスできないようにしただけで中身は同じなんだよな
ということはアンチOOPの人たちも実質OOPを使っていたと言えなくもないな
でも俺はパソコンに向かって独り言ブツブツ言って、チンポがシコシコしてるだけだ！！！
>>450
馬鹿なの？
全部構造体にしたらどこからでも参照し放題でしょ？
全部じゃないが、ある程度の変数がクラス内のメソッドでしか使われないから影響が構造化プログラミングよりはマシなんだよ。
自分の作った構造体を知恵遅れに弄られたいの？
次関数呼んだら、弄られてて予定してた値と違うとかあるんだよ？
(そして、それが自分のせいじゃないとか)
関数型言語は代入が基本的に無いから、同じグローバル変数を使っても、そっちはそっちで勝手にバグ作っててもこっちに影響が無いってだけ。
変数を書き換えることが基本だからオブジェクト指向は生まれたんじゃないかと思うし、それはそれで一つの正解だとは思うよ。 と言うか最初から関数型言語ほど徹底するとメモリアクセスが増えて遅くなるし、最適化目指すと大規模開発に対応出来ないって書いてる通り、
最初から程度問題の話しかしてないよ。
いじられたくないなら
構造体のﾎﾟｲﾝﾀにconstつけて入力の引数でわたせばおしまい
いじられたくないのに
なんでｸﾞﾛｰﾊﾞﾙｽｺｰﾌﾟでなんでもありでわたそうとすんの？
どうしてそんなに低学歴知恵遅れは頭ﾜﾙｲの？
もしかして低学歴知恵遅れは
引数の入力となる状態が変更されないｸﾗｽのｲﾝｽﾀﾝｽにconstつけたり
ｸﾗｽのｲﾝｽﾀﾝｽが変更されないﾒｿｯﾄﾞにconstをちゃんとつけたりもしないの？
どうしてもｸﾞﾛｰﾊﾞﾙｽｺｰﾌﾟにおきたいなら
最低でもconstの構造体ﾎﾟｲﾝﾀでｱｸｾｽできるようにでもしとけば
知恵遅れが想定外の記述をしないかぎり変更されることはないからな
やっぱりな低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はﾑﾘ
>>456
お前、Win32APIでプログラミングしたこと無いだろ。 こんどはwin32APIとな。。。
win32APIってmicrosoftがmicrosoft windowsで提供するただのｱﾌﾟﾘｹｰｼｮﾝｲﾝﾀｰﾌｪｰｽのことだが
それがどうかしたのか。。。
ﾎﾝﾄなこんなのがｵﾌﾞｼﾞｪｸﾄ指向（）とかなんとかいっちゃってるﾜｹだからな
どういう問題を示唆されてるかわからなければ半角は黙ったほうが良いよ。
また恥晒すの？
低スペだから？
また低学歴知恵遅れがしゃしゃりでてきてるわ
大体分かるwindowsでｲﾍﾞﾝﾄの処理でﾃﾞｰﾀをうまく渡すことが
低学歴知恵遅れのｵﾂﾑではまともにできない
こんなのが偉そうに講釈たれてんのがこの板だからな
相当に低学歴で
相当に知能が低い
まずｺｲﾂﾗをこの板から排除しないと板が正常化しない
米国で上位1%が富の独占をしている大きな理由は、労働者をスキルや成果で大きく選別しているからだ。
しかしながらそうでもしないと、ドラクエ10の下請けのように、コードの質が大きく落ちてしまう。
俺はドラクエ一筋なんてのはむしろゴミなコードを入れてしまう『有害な』働き者なのだ。
それは中小企業のデスクワークによくありがちな、要らない書類ばかり作って俺は仕事ができるみたいなものだ。
提案広場でよく『そう思わない』される理由
http://dragon-quest.me/dq10/27646/
このゲームすぐ持ち物いっぱいになるな
http://dragon-quest.me/dq10/28435/
【ドルボードGP】おいｗデスルーラ作戦晒すなやｗｗｗｗｗ
http://dragon-quest.me/dq10/28002/
でも月額千円では、下請けプログラマーの選別なんて出来っこないだろう？
＞このゲームすぐ持ち物いっぱいになるな
ゲームの仕様について意見を出すと、必ずといっていいほどに『そう思わない』で真っ青。
つまり準廃プレイヤー＝下請けプログラマーには、ゲームの仕様を変える能力が欠如しているのだ。
アルバイトの賃金が低いのはスキルを必要としない単純作業だからで、労働者にスキルを求めるのであれば、
アルバイトよりも高い賃金を上乗せして払わなければならず、更に成果に応じた報酬も必要となる。 constとか書いてるからさ。
作ってみりゃわかるけど、const付けて〜とか事実上無理。
子Windowの値を親Windowに反映させる時点でグローバル変数が出て来るし、代入不可避。
(別々のコールバック関数が必要)
const〜で済んでりゃMFCや.netは出てない。
他人に対してバカしか言えないやつって頭が悪い可能性が高い
しっかり低学歴知恵遅れの理由を書いてあるからな
残念なことに
登り棒してたらチンポがシコシコしてきた、小学生時代にそういう経験したか？
>>446
>一切ﾑﾀﾞがない
ほとんど無駄話ばっかしやがって
なに言ってやがるｗ >>472
＞ほとんど無駄話ばっかしやがって
＞なに言ってやがるｗ
俺はもとよりパソコンに向かって独り言ブツブツ言って、チンポがシコシコしてるだけだが？ 局面が変わると融通が効かない複合型データ構造を元にscopeを持たせるから
データ構造のinstanceが依存ネットワークのhubみたいな役割を果たしてしまう。
private/protectedでメンバごとのscopeを人間が制御しようとしても、
一旦中に隠したものを、別の場面では外に見せなきゃいけなくなったりして
少し規模が大きくなると急激に複雑さをます。
また内部scopeからは幅広くすべてがglobal変数みたいに丸見え
局面に応じたscopeやextentの管理がしにくい
カプセル化1つとってもこれだけ欠点があるよ
でもカプセル化の一番の弱点というか欠点は
人間が把握しやすい階層的で入れ子なextent, scope管理としにくく
非階層的でランダムグラフ的な依存ネットワークを形成して
かつ本来状態が不要なところまでもinstanceを状態変数みたいにして
getter/setterで頑張って状態管理しちゃおうとしてカオスに向かうこと
何言ってるのかさっぱりわからんかった
オブジェクト指向のメリットの説明はできたん？
a.foo()
foo(a)
どちらもaを渡してfooを呼んでいるのに
a.fooの方はグローバル変数と言うらしい
継承にいたっては目も当てられない
コードの実装レベルの類似性に基づく共有のための手段として利用されがちで
論理的な構造、モジュラリティーを破壊し
クロスファイルで静的依存ネットワークを形成する。
その静的コードから動的にどのような依存を持ったインスタンスネットワークが
形成されるのかもはやカオスとなる
あフォトしか言いようがない
>>477
とりあえずそのfooの実装においてaがどんなふうにアクセスされるのか意識して
プログラムしてみたら？
少しはコードがマシになると思うよ。 >>476
とりあえず、インポートで名前がぶつかりにくい
ぶつかるのクラス名ぐらいだから >>478
継承元のクラスのコードだけを見てもコード変更の影響が推測できないのが本当に邪悪だよな >>464の意見は正しい
アホなやつほどシッタカレスに努力する
知ってることだけ言うんじゃなくて
知ってることを総動員して精一杯背伸びしたフワフワ文書を書き込むよね
初心者の子はカキコまんでいい
半年ROMれ グローバル変数との区別もできないようなので
話すだけ無駄かと
リファレンスのドキュメントを継承元スーパークラスから継承したメンバ（フィールド、メソッド）を含めて全部書いてもらえればもうおれはそれ以上は望まない
それだけでいい。。
そもそもオブジェクト指向のメリットだけ説明すればいい
自分が使ってる技術のメリットも説明できんやつはサルだろ
キーボード折って便所掃除でもしてろ
>>484
inheritedで一覧出てくるのはあるよね ｵﾚの正確無比でﾑﾀﾞのないﾜﾙｸﾁに耐えられないのは分かる
低学歴知恵遅れが射精できる今の板の状態はゆゆしき問題
まずｺｲﾂﾗに射精させないようにしないといけない
著しい低学歴知恵遅れのｵﾏｴ含めてな
低学歴知恵遅れに強いｽﾄﾚｽを与え続けて排除することが板の正常化につながるということは
もうだれもが気付き始めてる
もう後戻りはない
射精くらいさせてやれよ、基本的人権にかかわるぞ
つかお前の書くﾚｽもチンポちゃんレベルのゴミだな
継承は、サブタイピングの目的では使わないけど
差分プログラミングの目的では使うっしょ
ケースバイケースだよ
299 その名前は774人います (ﾜｯﾁｮｲ db8e-7PZ0) sage 2018/10/24(水) 06:21:12.94 ID:U7GhzgwH0
ドラゴンクエストテン
〜目覚めし５つの倉庫整理〜
俺にとっての『オナニー』はするしないではなくて気がついたらしていた、オナニーはそこにあったのだ！
328 その名前は774人います (ﾊﾞｯﾄﾝｷﾝ MMe3-9smq) 2018/10/28(日) 21:03:44.64 ID:+SX2t0AiM
>>327
＞桁直しは直すのは簡単。直ったか確認するのがすげーめんどくさい（金かかる）。
オブジェクト指向によるアプリケーション開発は、変更されない箇所を軸に、
頻繁に変更されるであろう箇所をクラスに抽出するプログラミングスタイルです。
例えば、店舗がどんどん増えていくファーストフードのシステムを開発することになったとしましょう。
店舗が増えていくということは、そこは「頻繁に変更される箇所」なのでクラスに抽出して設計する必要があります。
そうすると近い将来起こる「店舗が増える変更」に対して柔軟に対応できるようになります。
https://qiita.com/tutinoco/items/6952b01e5fc38914ec4e 半角さん、いろんなところで論破されて、ついには相手に低学歴と言う機能しか無くなってたんだな
win32apiでは無理なんだーというのは論破なんですかね
>>474
＞private/protectedでメンバごとのscopeを人間が制御しようとしても
集約と汎化、制御と独立の使い分けが大切なんだよな。 >>475
＞でもカプセル化の一番の弱点というか欠点は
チンポは独立した生き物、とは考えられないか？ >>366
＞多重継承によってクラス間の依存度が高まることでデバッグが難しくなってしまうのが問題の本質なんだから
シコシコするチンポは不随意筋だが、オシッコをするときのチンポは随意筋だろ？ >>498
単に同じ種類のデータが増えるのは変更とは呼ばんだろ DBがカオスなのでオブジェクト指向でいくら頑張っても無駄
「りっきーのなんでもおコタえしまショー！」 当日のプレイバック
http://hiroba.dqx.jp/sc/topics/detail/286674e3082feb7e5afb92777e48821f/
質問 11
アイテム・装備欄がキツキツなのに
春イベでナスの衣装券５ワクをくれたり しかも人に渡せなかったり。
この件に関して 開発は何を考えているのか 教えてください。
【回答】 齋藤力
アイテム枠の軽減についてはできる限りのことをしたいと思い
日々スタッフが総力戦で取り組んでいるというのが正直な現状です。
一方で 新しいアイテムが まったく増えないようなゲームにもするわけにはいかない思っております。
↑これに対するありがたいお言葉
いま目の前にあるもんをちゃんと使ってそれを面白くするほうが先
宮本
いま、若いデザイナーがゲームをつくってる時、
面白くないから、ついつい新しい材料を追加して
面白くしようとするんですよ。
実は、いま目の前にあるもんをちゃんと使って
それを面白くするほうが先やのに、
新しいものを持ってくるという。
岩田
新しい材料をどんどん増やして
面白さを導き出そうとするんですね。 >>366
＞多重継承によってクラス間の依存度が高まることでデバッグが難しくなってしまうのが問題の本質なんだから
随意筋 不随意筋
↘ ↙
チンポ 随意筋←implements─チンポ─implements→不随意筋
関数型言語のやり方がそれなりに普及しちゃったんで、全てオブジェクト指向でプログラムを書くメリットはそんなに残ってないんだよ
オブジェクト指向が唯一の抽象化の手段になってる言語ばっかりだった時代はもう過ぎ去ったんだよ
オブジェクト指向に対比するものは関数型なんだろうか?
オブジェクト指向や関数型は「抽象化」なんていうすごいことを
本当にしているんだろうか？
オブジェクト指向の「抽象化」は似たメソッドがあったら
スーパークラスを設けて継承、
「抽象化」とはそんなものなんだろうか?
何かswiftでpostする時クッキーオブジェクトなるものを複数使って
ただデータ投げたいだけなのにクソ面倒臭い段取り組んだけど
関数型というかクロージャ使うというもう1つの別案が出来てからこういうのでいいんだよ感はかなりあった
スーパークラスとか、何でもかんでも詰め込まれた四次元ポケットみたいになってるだけの場合もあるからな
抽象化はスーパークラス生成の必要条件ではない
ビジターパターンとか考えると糞だと思うーん！！
パターンマッチグーあればこんな紛らわしいパターンはいらなくてグーなのにな
パターンマッチングがなければ？
悪いのはパターンではなくて、言語だろう？
ああ、>>517はビジターパターンの利点をまるでわかっていないな。
ばーか 横からでスマンがビジターパターンの利点って何？ExpressionProblemに対処できるってのはもう利点にならないよ
「助けてー！ドラえもーん！！」
それはのび太ーパターン。
>>485
大規模開発で構造化プログラミングよりは責任分担し易いってだけ。
でも給料払う側にも貰う側にも、コレが最重要。
Linux作者や関数型言語や論理型言語信者はオブジェクト指向なぞ不要と言ってる。(のは、その個々が開発力あるから？)
>>500
コールバック関数が引数固定な以上論破は無理だろ。
他の事例なら関数型言語みたく引数増やせば良いじゃない戦法もあるが。
それだって限界ある。
(関数型言語もマルチスレッドにオブジェクト指向より向いてるだけで、銀の弾丸では無い)
>>492
そう。
ケースバイケース。
ただ、それが分からないまま使う奴も多いのがね。
案外複雑だから。
親クラスのprotectedが子クラスのprivateとか。代数重ねると新入社員には無理。
そういう言う人間の限界も含めた譲位。
クラスライブラリからの継承とか、本当一部だけが継承で有効。 継承した時点で密結合になるので特に外部作成のクラスは継承せず包含しましょうは基本
ほとんどのケースはパブリックインターフェースを使用して事が済むので
>>522
リーナスはC++を嫌ってるだけで、オブジェクト指向については否定してないぞ >>524
いや相当否定してるぞ。
ただlinuxのファイルシステム回りはオブジェクト指向的だし、
その辺りについてはlinusも必要性を言ってた気はする。 >>525
実際は抽象馬鹿で具体的なテスト内容を思いつかない馬鹿のが問題だけどな。 抽象化を理解してるレベル帯ならSOLIDも理解してるだろう
これができてる人はテストが非常にエレガントだ(何故なら設計がエレガントだから)
抽象化が出来ない人の方がテストよくわからんと嘆いてるね
話を聞いてみると組み合わせ爆発を起こしてパンクしてしまうんだと
>>526
明確にオブジェクト指向を否定してるコメントなんかあったか？ オブジェクト指向を理解してないやつはSOLIDも理解してない
>>530
C++を否定するってことは、オブジェクト指向を否定してるってことなんですよ？ c++はマルチパラダイム云々なので
何でもアリ言語やぞ
>>532
お前の母ちゃんを否定するってことは、女を否定するってことなんですよ >>530
https://srad.jp/~taro-nishino/journal/509450/
ほとんどの部分はc++に対するヘイトだけど
OO言語について語ってる部分がオブジェクト指向の否定と思う。
だいたい言ってることは一理あるわ。
少なくともここでの議論よりかは意味がある。 Linusがオブジェクト指向を否定する理由の一つがまさに>>536
C++やオブジェクト指向の否定とも読めるが
それはKernelというコンテキストの中での話だ
egrep "オブジェクト|C++" としたときに
Kernelというコンテキストを隠蔽しているのだ
C++は本気で嫌ってるのかもしれんが
オブジェクト指向に関してはどこまで否定的なのか読めん ということで結論はLinusはオブジェクト指向を
否定してないってことでいいかな
>実際の問題が特別なデータ記述で関連付けられるとは私は考えない。
>貴殿はその類のデータのためのライブラリルーチンを欲しくない。
>つまり、貴殿はデータとその他の種類のデータ両間で相互作用するコードを欲しいのだ。
オブジェクト指向の欺瞞の心臓
初心者から上級者までおそらく全員が思ってること
すばらしい
>>539
私見だが6割程度は否定してると思う
コンテキストが一つのオブジェクトに依存している範囲のみ
オブジェクト指向は使える、と考えているのでは？
> だが、OO言語は、オブジェクトが重要であり、オブジェクトに関連付けられたメソッドを持つべきだという手段を考える傾向にある。まさに馬鹿げた話だ。一つのオブジェクト（又は、ある型のオブジェクトの当り前なコレクション）が本当の関心事ではない。
> 関心すべきは、異なる型の異なるオブジェクトが相互作用し、ロッキングルールを持つ等々の時なのである。その時点で、重要なのは一つのオブジェクトではもうないのだから、"オブジェクトインターフェイス"を隠蔽しようとするのは絶対に間違っている。
> だから、私はデータの記述が重要であることに賛成であるが、同時に、最も記述が本当に重要である事柄は、いかにデータが矛盾無いか、一貫性の必要条件があること、ロッキングルールがあること（そして、一つのデータオブジェクトのためでないことも）等々である。 なんか分かりにくい日本語だな、もっとﾏｼな言い方はできなかったものか
実際に言ってることがおかしい気がする
>重要なのは一つのオブジェクトではもうないのだから、"オブジェクトインターフェイス"を隠蔽しようとするのは絶対に間違っている。
ようするにまだるっこしいインターフェース介さずに
手順をすっとばして中直接いじらせろって言ってるんだろ？
遅いから。
コンパイラがバグるから。
基地外
あんまりOOPの欠点の核心を突いていない
ような文書も散見される希ガス
複数のオブジェクトが相互にかかわる煩雑なメソッドを
そのうちの一つのオブジェクト内に押し込めようとしているのは間違っている
それによって矛盾や一貫性やロッキングルールが失われるのはよくねえよ
ぴったり産業の意訳で結構分かりやすくなったが
行間あいてるし
デモなんかやっぱOOPの極端に目立つ欠点の一側面を述べてるだけじゃん感があるな
>だから、私はデータの記述が重要であることに賛成であるが、同時に、最も記述が本当に重要である事柄は、
>いかにデータが矛盾無いか、一貫性の必要条件があること、ロッキングルールがあること（そして、一つのデータオブジェクトのためでないことも）等々である。
>私は、それらを本当に容易にコンパイラへは書けないと思う。結局、どうしても自分でそのコードを書かざるを得ない。
それを達成してくれるのが隠ぺいだろ
メンバ変数間の整合性は公開メソッド使ってる限り保たれるはず
最終的にはマシン語自分で見ないと安心できないような世界の人のいうこと
複数のオブジェクトを隠蔽したオブジェクト内でどこかで不具合があったらどういう状況で起こってるのかわかりづらいし
どこで誤作動が起こってるか見当がつけにくい
中のオブジェクトが他のオブジェクトでも隠蔽されていたらまあ悲惨
関数だとシグネチャーでどのオブジェクトを使ってるかややわかりやすいんじゃないかな
私が心配する最も大きな問題はコードではなく、コードと開発の"フロー"だ。
いいね
やっぱり超頭いい人って違うね
一つのオブジェクト（又は、ある型のオブジェクトの当り前なコレクション）が本当の関心事ではない。
関心すべきは、異なる型の異なるオブジェクトが相互作用し、ロッキングルールを持つ等々の時なのである。その時点で、重要なのは一つのオブジェクトではもうないのだから、"オブジェクトインターフェイス"を隠蔽しようとするのは絶対に間違っている。
これだよ
オブジェクト同士の相互作用が複雑なんだろ？
金まき上げる層にとってはそうかもしれないが
OOPに苦しめられている開発者のことも忘れないでください
AというｵﾌﾞｼﾞｪｸﾄからBというｵﾌﾞｼﾞｪｸﾄにｱｸｾｽする場合
よほどの理由がないかぎりBからAにｱｸｾｽすることは避けないといけない
できるだけｺﾝﾎﾟｼﾞｼｮﾝにするべき
この場合、AがBを内包するようにする
A<->B 相互参照は避けろって
どうした、熱でもあるのか当然のことなぞ書いたりして
いい子だから射精して早めに寝なさい
AとBを内包するCを作り中ではAとBに殴り合いの喧嘩をさせる
生き残った方も潰す
そしてカオスすら残らないと
やめちゃえOOPなんか
オブジェクト指向で以下をモデル化せよ
> いい子だから射精して早めに寝なさい
class cneat {
public:
void erodouga_miru(void);
void erohon_miru(void);
void mousou(void);
void shikoshiko(void);
bool is_dopyu();
void fukifuki(void);
void poi(void);
void neru();
};
int main() {
cneat neat;
while (neat.is_dopyu()) {
neat.shikoshio();
}
neat.neru();
return 0;
}
>>564
ｽﾚの趣旨は
オブジェクト指向は「クソ」か否かなので
オブジェクト指向のノウハウ・イロハ的ﾚｽは
すれ違いだな、ご愁傷様 ｵﾌﾞｼﾞｪｸﾄ指向では
ﾆｰﾄが射精しそうかどうかなんかに
いちいち関心もつ必要はない
射精するまでｼｺらせればいい
>>569
半角さんは
オブジェクト指向のメリット・デメリットは何だと思う？ ｺﾚは何度もいってる
ｵﾌﾞｼﾞｪｸﾄ指向は適切に扱えば道具にすばらしいﾒｿｯﾄﾞを与える
ｵﾌﾞｼﾞｪｸﾄ指向は道具自体ではないが
この板にいるような低学歴知恵遅れが使えば
ｷﾁｶﾞｲに刃物になる
まず、プログラム言語の前に日本語なんとかしろよ定期
適切に扱えばという前提条件が満たされうる確率を考慮すると、オブジェクト指向にはメリットがないと相当の確信を持って言える
>>572
これ手続き型と関数型とオブジェクト指向のメリットやんけ それを言っちゃぁ、おしまいよ。
でもなんか有効活用する規範みたいなものの登場は無理なんだろうかね
これだけ広まっちゃって、みんなだまされ続けてきてもう今から後戻りは難しいんだし
たとえば局所的なクロージャーのような使い方に限るとか
ITの分野ってのはさ、
AIだの第五世代だのΣだのGRIDだのDNNだの機械学習だのイジングだのファジだの大航海だの
バズワードを伴うインチキがどうやら流行しやすい分野らしく、
また、それによって国プロを初め一時的に投資を引き出して
短期間に市場が出来て消えてを繰りかえしながらも
長期的視野で見ると日本のITは凋落傾向を続けている。
でもそういった中でC++やJavaを中心としたオブジェクト指向は、
奇しくも20年以上の流行と社会的普及を経ていまだ跋扈している
このように都市伝説のような非科学・工学的インチキノウハウは
ホント歴史に残る珍しい社会現象だと思う
>>538
＞C++やオブジェクト指向の否定とも読めるが
『チンポ』は随意筋なのか不随意筋なのか、独立生物なのかそうではないか、 Linus博士の見解を聞きたい。 チンポは独立した生き物なんだって、ビートたけしもそう言ってたろう？
>>578
文章うまいね
俺も同じ感覚だけどうまく表現できないよ
オブジェクト指向のメリットより、
言語の敷居を低くしたJava、C#やベターCとしてのC++他の言語にとって代わられることはないだけだと思う
オブジェクト指向言語であろうがなかろうが、
エレガントなデザインパターンというのはあって、
平均的な日本のプログラマには創造できないし、使うだけなら便利だろう 最近のバズワードはRPAかな
マクロ以上に負の資産になりかねないのに、日本のお偉方には輝いて見えるらしい
俺はインスタンスハンソル、ウィンドウハンソル、デバイスコンテキストハンドルを
上手に隠蔽できなかったMFCを見たとき、
クラスモデリングのハードルの高さを感じた
マイクロソフトさえ四苦八苦するデザインを
日本の一般プログラマができるわけがない
>>578
は？
ハンセン病とか
ロボトミーとか
魔女裁判とか
オイルショック→トイレットペーパーとか
マジでやっちゃった系なんていくらでもありげなこんな世界 そもそも完全にオブジェクト指向だとしても、メソッドという存在は必ずしも必要では無いと思うが、素晴らしいメソッドってなんだろう？
素晴らしいメリットの打ち間違いなら、またポンコツ煽りマシンですらないって事？
>>583
まずいのは、そのウィンドウハンドルすらも隠そうとする輩がいること。
オブジェクト指向うんぬん言ってる奴は大抵そんな連中しかいないだろ。 >>587
MFCがやりたかったのは、
キーとなるハンドルでグループ化して、
そのハンドルをメンバ変数にして引数からなくすっていう作業ゲーのノリではないの？
長らくさわってないので間違ってるかもしれんけど どっちにしてもドキュメントビューアーキテクチャと相まって、ちっとも生産性は上がらなかった
マイクロソフトの独壇場だからどうしようもないけど、今でもMFCの縛りはあるのかね？>現役の開発者
win32api直接叩いた方が遥かに楽だとは誰も思うまいｗ
20年前は、オブジェクト指向がうんたらっていう輩はいなかったな
実際に手を動かして、マイクロソフトでさえこんなゴミを作るんだーって
冷めた目で自動生成されたメッセージマップを見てた
いろいろメリットを説明したがる人って、
本当に職業としてプログラミングに関わってるの？
メッセージループだって、最後にdefaultのdispatcher呼べばいいだけだろ？
それだけの制約を守らせたいだけで実装継承なんかしなくていいよ
純粋仮想関数？可読性落とすなよ
>>583
あれはWin32APIにドップリ浸かってると逆に使い易いらしい。(使いたい機能毎にAPI纏めた感じらしい)
ライブラリ設計の違いだが一般受けしなかったのに、企業で強制されて嫌われ者になった感じ。(VC6時代が最盛期)
あの頃が一番(個人用途で)Delphiが輝いてた。 >>593
そうだよDelphiのクラスライブラリのほうがはるかにいけてた
MFCが勝つんだから、プログラミング言語すら政治の世界なんだなってみんな言ってた mfcでooを語るとか勘弁してくれよ
あれはただのapiラッパー
apiラッパーを超越してるからしまつが悪い
ドキュメントビューのウィーザードから始まるフレームワークだよ
ダイアログベース程度なら被害は少ない
>>595
言いたくは無いよ？
言いたくは無いけど、デスクトップアプリで保守でOSやランタイムのバージョン気にしないで作れる環境って、事実上それしか残ってない。(最早スタティックリンクでファイルサイズが〜何て気にする必要ない時代)
もう辞めたけど、大学(海洋系)のシュミレータとかデスクトップで実現出来るパフォーマンスは当時MFCしか無理だった。
今なら他の手段もあるだろうけど、すでに作っちゃった以上はそれで保守される。
(本当に、何であの当時Delphiが業務で広がらなかったのかと)
まあいいじゃん、最近のトレンドはAndroidやiOSだ。事実上のHTML5で、オブジェクト指向と言ってもプロトタイプがメインだ。
最早古きゆかしきオブジェクト指向は虫の息だよ。
まともなオブジェクト指向話題にするならTypeScriptかも知れんね。
Javaもそうだよ。
作っちゃった以上は長い目で見れば新規だけど、当面の保守費の方が中小には楽というか、また新規開発する体力無いのが殆ど。
(オラクルも、そういうのを見越してると思う。若干馬鹿な気はするが) 何を考えて学園をつくろうと思ったのか？
りっきーさんコメント：
「アスフェルド学園」は 冒険者のみんなにこれまでのアストルティアでは実現できなかった
新しい体験を味わってほしいという気持ちから開発をスタートしたものなんだ。魅力的な仲間を育てて共に
成長していく体験やあらゆるとくぎを使いこなせるオールマイティなキャラクターを作り上げていく体験だね。
今あげた2つの例をはじめとして、遊びとしては楽しいけれど数多くの人が同時に遊べる世界として実現が難しい。
そういった遊びを実現するために別の切り離された世界をつくったというのが学園を作った大きな理由なんだ。
http://www.tentama.net/2016/10/blog-post_28.html >>591
オレのところで一番のOOP伝道者は、ほとんどソフトウエアを作成できなかった
サンプルプログラム程度のものでもデバッグにえらく時間がかっていて足手まといだった。
でも結構な数のOOP信者を調教するのに成功し、一時職場では大OOPブームとなった。
J2EEの失敗がまだ表面化する前の、みんなOOPに夢見ていた頃の話。
OOPブームがピークを過ぎた頃、ISO9000やCMMIの伝道者に鞍替えしたので
開発部門から品証部門に移されて、いまは他人の書いたドキュメントの抜けチェックとかやってる
後出しじゃんけん的揚げ足取りやインチキが上手いので、表面的には何か品証の仕事を
しているように一見みえているよ ま、マジか、、、
「前向き」に開発に集中してと取り組んでいると
脇が甘くんるのはしょうがねーだろうに
うるせえエビフライぶつけるぞ！
,.、,､,,､､..,_／i
'､;: ...: ,,:.:'.‐'ﾞ' ┘
ヽ(´･ω･)ﾉ 「・・・・」
| /
UU
l;:;:;:;:;:;:;:;:l;:;:;:;:;:;:;:;:｀丶､;:;:;:;l
,l;ｨ'----┴――--､、;:丶､!
,ﾉ7 '"＾ ^`' ,ｨ'三ミ､_〉
{:/, ﾆ丶 ,r,=-、 ヾ:::::::ﾐヾ
〃ｨ'｡｀>ｿ { ィ'｡｀'ｧ::.. !::::::ミ:l
l:! ｀~´/ ,l、 ￣´ ,. }:::::三<
. ll (､ っ） : ,l::::ｼ久'l
.i＼ _,..､､,､,.､､,._､ ,:' f::/ﾝ ﾉ/
i‐- ｀.',:'''´:ﾞ:. :.,: ,: ,.:. . ,.:､ ﾐｧ ,） {,ﾂ>-‐'′
￣ ￣ ﾞ'‐..: ;..;;.;_ ::. :.,':.､.: .: ' : ヽ ,_ｿ/
丶､＿＿, -―''"/,/
,} ヽﾆニ =彡ｼ,ンヽ,
,/(`＝- r‐ ''" ／ ,／丶、
.ノヽヽ、＿;＿_,∠..ィ"-――ｭ、
>>600
linusがもっとも排除しようとしてた連中の性質だな。
結局そういう連中は
object->run()
と書いときゃごまかせると思ってんだよ。
そのrunの実装をどうするかが本質だっつーのに。 あまりまっとうなことを書くと、
信者もアンチも近寄れず、荒らしに会うという罠
なんか日本のITの構造が良くないよね
学はあるけどITのセンスがないstaticおじさんが元請けのプロパーとして君臨し、
その配下で中途半端にオブジェクト指向をこじらせた派遣が
好き勝手に作ってるんだもの
ときどき降臨するベテっぽいカキコ摩る人たちの意見が正しいなあと
ちょっと思えるくらいにはなった気がするけど、
外国で流行ってると言われると思考停止する自分もいやだわ
他のOOP厨の例では、30代前半くらいのJavaとC#好きな
ソフトウエアの研究者が数名いる。
彼らは人にOOPを広めるような活動はしなかったが、
学生時代から親しんできて慣れているのか、あるいは地頭がいいのか、
ある程度まとまった量の研究目的の実験的プログラムを
OOPで作っていた。
集中して新規に作っているときは、入り組んだ関連性でも
一断面に集中できるのか、OOPで結構コード書いていた。
他人が見返したら分かりやすいプログラムであったかは、なんともいえない。
(研究のコードはあまり見せたがらないから)
金のハンマーで料理とか釣りしてるバカがいるだけの話よ
他には、、、
若い研究者がpythonのkerasで強化学習の研究コードを書いた事例がある。
kerasは継承でカスタマイズして強化学習アプリを作るFWだけど、その継承を
上位レイヤまでｽﾞｯﾄ引きずって、ｱﾙ程度規模のあるアプリを力ずくで書いて
研究のため継ぎ接ぎしていったもんだから、
他のFWの継承や複合的big instance、instance間の関連性、継承による
深い依存の嵐でぐちゃぐちゃになり、もう何がなんだか分からないコードの
山になっていた。
頭のいい研究者なんだけど、ソフトウエアの方法を選択するセンスは
いまいちだったかもしれない
>>614
えぇ！？大卒なのに！？って言ってやれｗ
やっぱ関係ないよなぁ。学歴は OOPとuml流行期にそれを煩った(ソフトウエアのセンスがいまいちない)PMの率いた
ネットワークアプリケーション開発、C++で約45000stepの事例も
どちらかというとOOPの適用失敗例だったかな。
PM自ら薀蓄をたれてC++の持つOOPの機能を駆使して実装することに
血道をあるよう指示し、似たmethodがあればどんどんスーパークラスを
設けて差分プログラミングを実践し、そのためにC++にはjavaのinterfaceが
ないからといって完全仮想関数を多用し、、、、、、、
privateメンバが後で外から参照必要だと分かればgetter/setter追加し、、、、
singletonで実質最外部変数を設けてやり取り継ぎ接ぎし、、、、
そのうちプロジェクトが遅れぎみになり手が足りないというので、人が注入されたが
もう他人があとから見てもそのコードが何をする働きのものか、どのような構造のものか
もはや俯瞰できず、こういう状態に陥るとドキュメント化しにくいのでドキュメントは省かれ、
分からないことがあれば聞いてくれれば教えるよ、と開き直られ、かけた人数の割には
全然はかどらなかった。
できたソフトウエアはかなりひどい代物だったが、
まぁ、報告書書けば検収上がる○プロだったので、一回実験したあとは特にソフトが
使われることもなく何とか丸め込んでいたようだ。
あんまり書くと特定されかねないから
ほどほどにしとくわ
結局、オブジェクト指向が有効なのは
ある程度扱うオブジェクトの粒度が粗いレイヤーでの話だと思う。
複数のオブジェクトが複雑に相互に絡み合ってるところはlinusの話にあるような状況になるということじゃないか。
んでもってその粒度の閾値をメンバーでうまく共有するのが難しいからソフトウェア開発ってのは難しいんだろう。
>>567
誰もあえて指摘しなかったんだろうけど、判定が逆じゃないか？ >>617
Doctorとってるなら、自己組織化プログラミングのアルゴリズムでも開発してくれ
入力ソースコードは人間の自然言語でお願いします 複雑に相互にからみあったままだと作れないから
プログラマーは問題を分割して作るようになるだろうという期待も含めての
オブジェクト押しだったのではないか
>>622
あるまとまりのある複合型データ構造⇔分割細分化 >>218
＞オブジェクト指向言語と
＞オブジェクト指向をごっちゃにしないように
オブジェクト指向言語つーとRubyを思い浮かべるけど、あれはオブジェクト指向を意識しなくても、
簡単にプログラミングができるように設計されたということだろう？
511 デフォルトの名無しさん 2018/10/29(月) 23:32:40.68 ID:LL+W6ENh
随意筋←implements─チンポ─implements→不随意筋 一回こっきりの家庭用ソロゲーを作成するなら、オブジェクト指向がチンポがうんたらは必要無い。
──オブジェクト指向の言語を書こうというのに、オブジェクト指向でないCで書かれているというのは意外な気もします。
まつもと「CでRubyのオブジェクト指向を作ってて、その機能はCからも使えるんですよ。
だからRubyのC実装って、Cで書かれているんだけどRubyのオブジェクト指向で書ける。
僕はこれが好みなんですが、違う人も多いみたいですね」
http://ascii.jp/elem/000/001/228/1228027/
しかしながら将来的に改変したり削除したり拡張したりする場合、『チンポ』のような多態性が不可欠。 Ruby はオブジェクト指向で、jQuery のように関数型で、
ダックタイピング・メタプログラミングもできる
instance_eval などで、文脈によって、self を変えたりできる
webページのテストでは、Page Object のように、
ページのヘッダー・フッター・サイドバーなどの各部分を、オブジェクトにできる
なぜDelphiへのエネルギーをC++Builderに向けなかったのだろう
Pascalじゃ人が増えないよね、いくら優れていても
>>628
汚いキメラ言語。
関数型を好む人間が文脈によってself を変えたりできることを有りがたがるとでも思ってんのか >>628
関数型が何かわかって話してるの？ Rubyのアンチみたいだよ。一周回って。 まつもとゆきひろみたいな神でなくてもいいから、
実際にgithubとかにソースを公開してる人の意見が聞きたい
日曜プログラマーの御託なんかどうでもいい
githubに公開されている素晴らしいオブジェクト指向なプロジェクトがあればぐうのなも出ない
ダメなプログラマーの典型だと思う。人の話を聞かずに延々とコードを書き続けるタイプ。
↓
859 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ﾜｯﾁｮｲ 6e12-bDJh [111.216.20.232]) sage 2018/11/01(木) 05:47:53.61 ID:eX17QnR50
何この流れwﾜﾛﾀw
ここの住人なら提案広場に投稿する=無制限でマイペ公開→凸されてキレる奴がアホって認識だろ？
めんどくさくなってBL=勝てないから逃走、つまり負け犬
凸した側の自板で相手にBLされた報告は勝利宣言じゃん
わざわざスレまで来て何レスもローシュ君の逃走報告しなくても良いんやで？
リドリーの拗らせたファンか何かなの？w
真面目な話、正論でもって凸してる側のスタンスを理解できないくせに
上から目線で論破してやろうなんて無駄な努力だし馬脚を現すだけだからな
ヲチ物件としては面白いがヲチ対象の擁護レスは興醒めするわ
ダメなプログラマーwww
↓
内容読まずにそう思わない入れましたが、
内容読まずにそう思わない入れましたが、
内容読まずにそう思わない入れましたが、
744 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ｱｳｱｳｶｰ Sa31-mOlN [182.250.242.73]) sage 2018/10/25(木) 19:22:09.86 ID:EkmAOjZ/a
https://hiroba.dqx.jp/sc/forum/prethread/408912/
内容読まずにそう思わない入れましたが、内容読んでらますます、そう思わないでした。 >>597
古きゆかしきオブジェクト指向ってのは
カプセル化、継承、多態性のこと？
今でこそ悪手と疑念を持たれてるけど、
当時はこれぞオブジェクト指向！みたいな入門書が出ては消えてた なんかmfcとかdelphiの話がよく引合いに出されるけど、
今どきの言語でメリデメが説明しづらいってこと？
MFCは当時のC++の言語仕様の範囲で作られたライブラリ
STLとかテンプレートが使われていない
純粋なC++クラスライブラリと言えるがC#のデリゲート相当が
なくて（当時のC++の言語仕様では作れないから）使いづらい
Delphiはそれを解決している。そのDelphiで作られたライブラリが使える
C++Builder でも解決しているが、独自の言語仕様が追加されていた
（__closure と __property）
オブジェクト指向ではなくて、C++の問題の話だな
今どきのオブジェクト指向言語ではそこらへんの問題が
解決しちゃってるのでディスるのが難しいｗ
>>642
オブジェクト指向って言うと親クラスがAnimalで子クラスがDogとかCatで〜みたいな例えが多いけど、
実際には違う場面もあると言う例えとしてもクラスライブラリの設計思想の違いがよく出てて例え易いってのもあるし、
今時の言語はオブジェクト指向と言うより関数型言語も混じったハイブリッド言語だからってのもある。
(使って天国作って地獄と言われたWin32APIとの比較にも丁度いい)
結局ハイブリッド言語最強と言われればそれまでだが。
そう言う意味じゃ今時の言語はオブジェクト指向言語のデザパタを手本にしつつも、新しいで座パタを作ってる最中なんだろうな。
(特にマルチスレッド系は関数型言語の考え取り入れて大改造中なんじゃなかろうか) >>644
良貨が悪貨を駆逐するの典型だったね。
C++Builderの方がSTL対応早かったのに、為すすべもなくMFCに飲み込まれた。 >>644−646
ありがとう
mfcとか書いてる人が同じ人の自作自演には見えないし、普遍的な意見みたいね
俺は経験が浅いから、mfcとかの話はすぐにはわからなくて、ネットで調べていこうと思うけど、
ベテランから見れば同じような見解なのかしら
今現在ではオブジェクト指向言語もハイブリッドに進化してて、
ピンポイントではメリデメは説明しづらいとか もっとくれくれ君的に聞きたいけど、
何から勉強するのが早道なのかしら
巷のオブジェクト指向の本を読んでもピンと来ないし
>>648
c言語でグローバル変数を一切使わないで組む練習をしろ >>646
それは間違った慣用句の使い方だなw
普通使う時は「悪貨は良貨を駆逐する」だから。 MFCがダメだったのはオブジェクト指向だからではなくて、
単に当時のMSのAPI設計の品質が滅茶苦茶だったから。
「悪貨は良貨を駆逐する」ってさ、負け犬の遠吠えだよねｗ
お前が応援している○○が勝った時、
「悪貨は良貨を駆逐した結果だ」って言えんの？って
聞いてみたいねｗ
>>650
ごめん、そう書いたつもりだったけど間違ってたw
寝ぼけてたかも知れんw 「実践テスト駆動開発」を勧める。
オブジェクト指向の良さも悪さも実感することになる。
MFCが出た当時は誰もオブジェクト指向について分かって無かったから
わざとオブジェクト指向度を下げて成功したらしいよ
逆にボーランドのライブラリーはオブジェクト指向度が高かったから失敗した
>>651
> 単に当時のMSのAPI設計の品質が滅茶苦茶だったから。
何と比較して？
具体的にどういう点が？
自分ならもっと良いAPI設計が出来た？
俺もかつてwin32で色々つくったこともあり
当時はイライラさせられたことも確かにあるが
だからといってあれが滅茶苦茶な設計だとは思えない
だいたいああいう感じに基本なっちゃうんじゃないの？と思ってる msはWindowsの設定とかのguiが破天荒なのにソースは綺麗という方が無理があると思うの
正直テンプレートの無い当時のc++は糞だったから仕方ない部分はある
正直テンプレート来てからは何でもテンプレート使ってカオス状態になったからc++がくそなのは仕方ない部分がある。
テンプレートって名前やめて
コードジェネレータって名前にしたほうが良かった
コンパイル時にコード生成するとか
ｸｿはなにを使ってもｸｿにする能力がある
それが低学歴知恵遅れ
オンラインゲームってのはコードの質が低いねぇw
237 Anonymous (ｽｯｯﾌﾟ Sda2-qcg+ [49.98.169.30]) 2018/11/02(金) 19:35:46.52 ID:4GQBlPFjd
「こうなって欲しくはない」
🐸「その要望にお答えします！」 同じ苦労を知っている齊藤氏は、開発初期から大事にしていることが1つあった。
「一番口酸っぱく言っていたのは『属人的な開発の仕方をするな』ということですね。
長いこと開発していけばお客さんの入れ替わりと同様に開発スタッフも変わっていくわけなので、
属人的なスキルに依存した開発をしていると、その人がいなくなったタイミングでアップデートがで
きなくなります。それをまたサルベージしてやりましょうというのはとてつもない作業量になります。
『ドラクエX』で100％属人的じゃない体制を作れたかというと決してそんなことはないんですけど、
意識してそれをやるようにというのは開発初期からやりました」
https://jp.ign.com/dragon-quest-10/28251/news/xpso2 言われたことをきちんとこなせる能力も大事ですが、自分の意見もしっかり伝え、相手の意見を突っぱねずに、
柔軟に聞き入れるのも重要です。何かを思ったり考えついたりしても、それを内に秘めたまま発信しないこと
には何も考えていないことと一緒であり、そう思われかねません。事態が悪い方向に進んでから、だから
こうした方がよかったのに、と後悔するよりも、思いついたことがあるのならば、率先して口に出していきましょう。
互いに納得が出来る道を探るにはコミュニケーションをとるしかありません。プログラミングの分から
ない人が理解できるように説明する能力も重要で、論理的思考スキルと合わせて手にしておきたいスキルです。
加えてコミュニケーションが不足していると、あまり話した事がないからどんな人かわからない、
声をかけづらいなどと相手にマイナスなイメージを与えてしまい、新しい仕事を得るチャンスを、
知らず知らずのうちに失ってしまうかもしれません。そう言われてもコミュニケーションはやっぱり苦手だという方は、
まずは挨拶からはじめてみてはいかがでしょうか？それだけで自分の中でも相手の中でも、印象が変わってくるはずです。
https://mynavi-creator.jp/blog/article/skills-necessary-to-game-programmer >>663
正しいと思うがVCのビルド環境を見る限り、msはできる限りビルド環境を隠蔽したがってることは明白。
あいつらにビルドを明確にした方が良いって発想はない。 顧客の主張を聞かず、逆に顧客を罵倒する脳筋プログラマーwww
↓
904 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ﾜｯﾁｮｲ 7f9b-J3xm [14.132.225.33]) sage 2018/11/03(土) 08:15:09.88 ID:e3rghfI10
ろひすや、飴、飴、豚、ゴミ
私有地のように毎日のさばってんな
そんなに思い通りになるまでやめないの？
思い通りになったらますますやめないの？
こいつら俺はドラクエXの運命を変える力があるとでも勘違いしてね？
こいつをみんなで無視しようなってのもwww
↓
174 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ｽﾌｯ Sd33-wjEJ [49.104.38.82]) sage 2018/09/30(日) 03:22:02.03 ID:3/yN7cf3d
>>173
クソに安価付けてレスしないで
JPとﾊﾞｯﾄﾝｷﾝはNGName推奨です オブジェクト指向というデザインが何を指してるのか曖昧だけど、
C#のデリケートやSwingのイベントリスナーによってコードがスッキリするのは言語の進歩。
それが『オブジェクト指向』によるなのかというと全然違う。Publish/subscribeモデルという言語を越えたデザイン。
少なくともカプセル化、継承、多態性などがメリットに直結する説明の本は糞だと思う。
91 その名前は774人います (ﾜｯﾁｮｲ c93e-d2wE) sage 2018/10/30(火) 14:22:34.62 ID:MV4WqrjP0
まあ「学園だけ本気だった」って揶揄されてるけど
実際は学園すら本気じゃなかったと思うよこのカスは
順番に鍵開けるだけのワンパターン手抜きストーリーはもちろん
初期の不具合でコケたクラス形成のまともなテコ入れは一切なく最初から死んだままだし
フェスはクソくだらないモンスター先生（）退治ばかりで盛り上げようって気は一切見えなかったし
不評と失敗が明らかになってからはDQXTVでは箝口令
辞める前の運営だよりで学園総括しろという真っ黄色の提案があったにもかかわらず「学園」の二文字すら一切なし
例の「アレルギー」以外に総括や反省どころか振り返りすらせずにぶん投げておしまい
学園ですら、カスにとっては作り終わって飽きたいつものポイ捨てコンテンツの一つに過ぎなかった
リソースの浪費とゲームへのダメージは甚大だったけど、サイコパスにはそんなこと関係ないんだね
＞辞める前の運営だよりで学園総括しろという真っ黄色の提案があったにもかかわらず「学園」の二文字すら一切なし
242 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ﾜｯﾁｮｲ d1bd-BIB0 [220.22.170.198]) sage 2018/10/03(水) 22:47:59.97 ID:qPQMVAOd0
このスレにも致命的なバカが迷い込んでるがw
どう考えたってそう思うが押されるわけないじゃんw
押されたい提案をすりゃいいのに揃いも揃って基地外だもんなw
自慢じゃないが、あっちのスレで俺は煙たがられているんだ！
915 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ﾜｯﾁｮｲ bb33-PRUr [106.160.151.234]) sage 2018/11/03(土) 13:56:13.48 ID:MJll2UhP0
>>911
スルーしましょう
それよりも、ねころのネコと足跡来てる魚子さんとの間にさざ波が…
口論って程じゃないけど ＞凸されてキレる奴がアホって認識だろ？
5ちゃんねるの俺からの追求は『スルー』www
>656
確かにそんな感じだった
当時は何をどうしたらいいのかすらよく解らなかった
>>672
＞オブジェクト指向というデザインが何を指してるのか曖昧だけど、
ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
511 デフォルトの名無しさん 2018/10/29(月) 23:32:40.68 ID:LL+W6ENh
随意筋←implements─チンポ─implements→不随意筋
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ cat.pushObject(door)
引数の状態が変化する場合には主語
完全解決
オブジェクトが主語としてふるまうばあいは三人称とか定着すればよかったのに
英語の活用がいい加減なせいで区別つかない場合があるから普及しなかったのだろうか
そういう、どのオブジェクトが主体なのかってのはプログラミングして解決したい問題では些末
オブジェクト間の関係性、つまり実際の処理が解決したい問題になる
foo(X,Y)とX.foo(Y)とY.foo(X)のどれが良い？ってのはfooの中身から明確に答えが出ることもあるし、どれでもいいよってなることもある
OO以外じゃどうでもいい話を、さもプログラミングする上で問題になるように持ち上げるやり方をマッチポンプパターンとして提唱しよう
チンポくんもこじらせてるねえ
何を主体にしたいかとか、プログラミング言語じゃなくて言語学の話だから
まーたそのゴミみたいなblogか
そういうゴミ情報はさっさと潰れてほしい
検索結果に出てくるだけ社会の害悪じゃん
>>693
お前が素晴らしいブログを書かないからな >>686
なんとnimではfoo(X,Y)とX.foo(Y)が同じ意味 javaのstringのequalsと
pythonのjoin
"abcde".equals(str)
','.join(list)
「文字列をequalsで判定する時」なんかは21ページまで行ってて会議室の中で一番長いんじゃねえのコレ
そういえばc++の発展の歴史は文字列をどれだけプリミティブ型のように扱えるようにするかの
歴史だと言ってる人がいたね。
VB6のコンポーネント指向でよかったけどな
マルチスレッドディスパッチャとかデリケートを言語で強化していくとか
Javaに追い付け追い越せはC#に任せてさ
マシンパワーの進歩で.NETのもっさりも気にならなくなって、
結果論では正解だったのかもしれないけど
>>698
vb6にもイベントデリゲート機能は既に有ったよ
プロパティセッターゲッターとかも有ったし
何時のバージョンから搭載されていたかは知らないけど >>698
VB6はVB6で使いやすかったんだけどな
言語としての機能性がプアなのは仕方ないが
労を惜しまなければなかなかのものができたんだよ
Javaと変わらず遅いけどw このソフトの動作にはvbランタイムのインストールが必要ですからのそっ閉じ
>Javaに追い付け追い越せはC#に任せてさ
は？？？
vbランタイムは付けても良いし
ベクターから落としても良いし
javaみたいに金は取られないよ
ランタイムとかありえねー
1バイナリで配布に決まってるだろ
dllとか意味わかんないｗ
15年前とか、オブジェクト指向宣教師にVB厨とかいってバカにされてたけど、
その宣教師達の見る影もないな
>>672
カプセル化、継承、多態性は、オブジェクト指向密教の念仏、お題目だからな
信じるものは救われるw 密教はマジモンのオカルトで、
肝心なことは密にされてる、つまりは秘密にしてる、というか伝えられない、言語化できない、っていう方面の宗派だ
オカルト＝秘されたもの、だからな
その対義語？がサイエンスだ
だもんで密教はオカルト中のオカルトだ
顕教はその名の通りに教えの中核を明文化して伝える宗派
宗教やオカルトにもいろいろあるが基本的には「隠す技法」だ
隠せば隠すほど有難味が増す
カプセル化と多態は普通に使うけど
ここで必死に否定してる連中は何使ってんの？
>>716
c言語方式
極めるとグローバル変数を一切使用しない関数に行き着く イミュータブル性、スコープに合わせた資源管理、関数の長さ、ビルドの構成
この辺りを気にした方がマシ。
>>717
関数がファーストクラスじゃないから制限が多いかな カプセル化なんかをメリットとして力説するのが痛いんじゃない？
変数のスコープや寿命なんて、オブジェクト指向言語以前の命題でさ
とはいえ、ポリモルフィズムが有効な場合というのは見極めが難しいからな。
そのコードの流れと直交するような動作ならいいけど、
そんなのコードに慣れてない奴には絶対判断できん。
もう少しソリッドな技術から学ぶ方が重要。
>>722
いや、リーナスさんも言ってるけど
曖昧さってのはガンにしかならない >>723
個人的に同意だが、しかしある機能においてはどうしても動的に変えられるように
作らなきゃならんこともあると思う。
例えばUSBドライバのロードとか。 Cで作るにしてもデータ隠蔽や関数ポインタ使って動的に動作変えるとかやるからな
workingset みたいなもん定義して
ws->pre_fn(ws), ws->work_fn(ws), ws->post_fn(ws)
とかはCでもやる
なんだただの無能かよ
お前は一生switch文書いてろ
CがゴミってんならC++なんてクソだろ？それもゲリクソ
あっちこっちで食あたりコードを生み出すゲリクソ生産機
オブジェクト指向とかいうブラックボックス礼賛思想
こんなんに付き合ってたら頭おかしなるで
オブジェクトはどういう操作してもバグらないのが前提
常に整合性を保てるクラスを作るのはとてもテスト工数がかかる
わりに合わないと思うこともある
でも問題を分離することが人間の進歩だ
オブジェクト指向はとても遠大で高邁な理想なんだ
Cの関数ポインタはよく使ったなー
今でも別な言語で似た使い方するけど楽の一言に尽きる
>>732
オブジェクト指向そのものはブラックボックス思想ではないんだよ
オブジェクト指向でプログラムを組む人がブラックボックスを作りたがるだけなんだよ ソースコード見れるのにブラックボックスってどういうこと？
ライブラリの関数、中身見ないから
ブラックボックスっていうのなら、
それは手続き型でも同じだし
>>736
グローバル変数のデメリットを理解してる？ >>738
手続き型はグローバル変数になるから、
オブジェクト指向で隠蔽化するってこと？
手続き型でもローカル変数にして
隠蔽化＝ブラックボックス化するのは同じでしょうって
言ってるんだが？ >>717
極めるw
何を極めたんだよ
関数ポインタを諦める事か？ >>729
OS無しの組込にはアセンブラかCしか選択肢がないけどね。(良い悪いはともかく)
C++も最近増えたみたいだけど、書き込む領域がそれなりに無いと。 逆にC以外の言語で使えるのと言ったらhaskell位しか思いつかない。
>>739
＞隠蔽化＝ブラックボックス化するのは同じでしょうって
511 デフォルトの名無しさん 2018/10/29(月) 23:32:40.68 ID:LL+W6ENh
随意筋←implements─チンポ─implements→不随意筋 >>717
変数をすべてローカルで作って、
関数に引数10個ぐらい使って引き渡してるソースなら見たことがある。
たしかに極まってるわ。 >>744
それ、構造体にしてポインタ渡しにしねえか普通。 ついでに構造体のメンバに関数へのポインタをセットするのは気持ち悪いから、構造体に実装埋め込みたいよね？
構造体という名前の特殊な関数だと思い込めばいい
それでクロージャみたく解決だ
>>744
実際やると10個じゃ済まない
50個ぐらい行くかも
でもやってみればわかる
それでもソースは読みやすい んなわけあるかあほか
設計能力がないだけじゃねぇか
>50個ぐらい行くかも
>
>でもやってみればわかる
>それでもソースは読みやすい
読みずれーよ馬鹿w
関数のさらにネストしたところでしか使わん変数を引数で引回すコードの
メンテをしたことあるがめちゃくちゃ大変だぞ。
>>750
エアプ乙
でも引数からしかアクセスないじゃない？
これがメンバ変数だったりグローバル変数だったりするから滅茶苦茶になるんよ
引数オンリーは絶対に問題起きない
やってみろ
レベル上がるぞ 本当の馬鹿か。。
さすがに構造体否定する奴は初めて見たわ。
みんなthisポインターにズルズル引きずってしまえば楽さw
>>752
やってみりゃわかるよ
引数に書いてた一覧を
構造体に移植するだけよ
つまり関数と似た名前の構造体ができるだけ
意味があると思うなら用意すればいい
俺も最初はやっていた
完全に同じもんが必要になることなんて
まずないから放置 お前ら今までのﾚｽでさんざ書かれてきた問題点を
何も学んでないな
>>754
巨大な構造体を引回す関数群か
ポインタ渡しにすることになるから、もはやグローバル変数と変わりはないな >>756
巨大な構造体で、どうやってグローバル変数のように
どこからでも参照できちゃう状態にできるの？
どこからでも参照できないなら、ローカル変数と変わりないな >>754
> 引数に書いてた一覧を
> 構造体に移植するだけよ
> つまり関数と似た名前の構造体ができるだけ
> 意味があると思うなら用意すればいい
えとな、引数に書いていた一覧を構造体に移植するだけだから、
関数と似た名前の構造体ができるだけなんだぞ。
意味がないのは、お前が「引数に書いていた一覧を構造体に移植するだけ」
という変なことをやってるからだ。全てお前自身の問題なんだよ。
構造体にする基準は、リファクタリングの「引数オブジェクトの導入」の基準と同じだ
https://ja.wikipedia.org/?curid=93818
> 引数オブジェクトの導入
> たびたび一緒に受け渡しされる複数の値は、オブジェクトとしてまとめたほうが分かりやすい。
「一緒に受け渡しされる複数の値」を構造体にするんだよ
全部を一つの構造体にするバカはお前だけだ 追加するのは簡単だけど、削除したり改変したりするのが大変だねー。
メモリ管理がポインタがうんたらなんてややこしい話はJavaやRubyでは関係無いけど、
ネットワーク通信だとC/C++の一択でポインタをいじくり回してメモリ管理するしか無い。
この認識で、違うか？
プログラミング言語
1 C/C++
2 その他
・・・だと思う。
>>757
全ての関数の引数にその巨大な構造体のポインタを入れるとそうなるね >>751
void main()
{
struct {
int x,y,z,foo,bar,everything;
} global;
func(&global);
} >>764
> 全ての関数の引数にその巨大な構造体のポインタを入れるとそうなるね
グローバルってことは、ポインタを渡された関数以外からアクセスできるわけだけど、
それでどうやって渡された関数以外からアクセスするの？
渡された関数だけからしか参照できないなら、ローカル変数と変わりないな てか、ポインタもグローバル変数と同じくらいバグの温床だろ。。。
寿命とスコープの話がごっちゃになってね？
常駐もののブートストラップルーチンのローカル変数の寿命はプログラム終了までだろうし、
それが引数のポインタからたどれたとして、スコープはチェーンしている関数内だろ？
>>766
全ての関数に巨大な構造体のポインタを渡してる前提だから、
「ポインタを渡された関数以外から」なコードは存在しないよ >>769
存在しないとまで言われると書きたくなるな。実装依存だが自動変数をスタックに取るなら、こんなコードでたどり着けるかな？
void main()
{
int x;
foo();
}
void foo()
{
int y;
*(&y+2)=65535;
} >>771
foo関数の引数にポインタがないよ
巨大な構造体のポインタを全ての関数に渡す前提を忘れてる
>>765が具体的なコードを上げてくれてるね >>772
すまん、765=771だ。
fooにグローバルもどきな構造体のポインタを渡せば十分変態なコードはかけるし、
渡さなければ絶対到達できないというわけでもないと言いたかった。 >>773
まあ、お前のコードクソだからそういうのが日常って常識を主張したいわけだろ カプセル化が下手だとやりたいことが出来ないとかありうるんだよなぁ。
逆にやりたいことが全部用意されてるライブラリとかは、ほほうとなる。
>>775
おまえらが無能だとゆうことはずっと前から分かっとった ホントにこういう頭のおかしいやつたまにいるからな
引数10個越える関数とか平気で書いてくるから
勿論レビューで突き返すけど
>>771
その理屈なら、すべてのローカル変数は
グローバル変数と言ってるのと同じ
意味がない >>782
いくつだったらおｋなの？
何か引数の数について書いてある文献あるんですか？ 比較にwin32api出されてこれ駄目なんですか？
あなたが参考にしてるソースってなんですか？
そのソフト売れてるんですか？
ぐらいの質問には答えられたほうがいいな
>>787
クラスとか言ってるってことは俺よりレベル低いじゃんそいつ >>788
こいつも同じ
グローバル変数を使っては行けない理由が薄すぎる
多分わかってないな
名著？は所詮メディアが作ったもんだし信用しないほうがいいよ
実際おそらく何十冊も読んできたであろう君がオブジェクト指向のメリットを一つも説明できないだろ？
ビジネスにおけるメリットの説明とは数字と結びつけてするものってのは理解してるよな？ ﾊﾞｶは構造体に構造体をいれることができることすら
分かってないからな
ずっとでかい構造体をひきわたしまくってるﾊﾞｶもいるからな
関数でなんの変数を変化させたか分からないようなｼﾛﾓﾉを作る
頭おかしいほどめちゃくちゃでかいｸﾗｽ作るﾔﾂとにてる
この板にいるような低学歴知恵遅れにありがち
>>790
> 名著？は所詮メディアが作ったもんだし信用しないほうがいいよ
いや、ふつうに、かんがえて、
おまえのほうを、しんようしない >>792
それは自分で考えた結果なの？
それともネームバリューにやられちゃった？ 各所で信頼できると言われてる実績 >>>>>>>> おまえ
どのプレイヤーとも共有されるだけに、サーバー側でいじるとプレイヤーの画面表示が狂ってしまう！
postdって
記事同士の内容が反している様な時も有るから
本当の意味で正解とゆうのが無いか
未だ見出されていない
とゆう事なんだと思う
>>784
「普通の方法じゃ無理」ってのならわかる。
「存在しない」ってのなら同意できないわ、C言語がわかってない。 >>799
グローバル変数も変数なんだから、
変数としての性質を持っていなければいけない
例えばポインタ変数は変数だが、
それは「ポインタを入れてる変数」が変数なのであって
ポインタが先示す先は変数ではない
変数は、型と名前によって定義されるものだ
アドレス指定でメモリを直接読み書きした所で、
それは変数ではない >>795
でもそれを頼りにした結果がこれじゃん
オブジェクト指向のメリットを数字をあげて一つも説明できないわけでしょ？
もういい加減気づいても良くない？
サルじゃないんだから >>801
> オブジェクト指向のメリットを数字をあげて一つも説明できないわけでしょ？
数字？ オブジェクト指向が使われてる
プロジェクト数とかでいい？
なんの数字がでればいいかいってみて >>802
はぁ？
使用プロジェクトが多いってのがオブジェクト指向の1番のメリットってことでいいの？
ってかお前オブジェクト指向の良し悪し云々の前にそもそもある技術を評価することそのものが
できないじゃん >>803
だからそうやって文句言い出しそうだから、
どんな数字を出せばいいか聞いたのに
どんな数字ならお前は納得するんだよ？ 無能が頑張ってるな
お前がやってる単純な処理ならOOは要らんから一生懸命手続きを並べていけ
>>804
そりゃ、お前がオブジェクト指向のメリットだと思うことを金銭的にいくら儲けることができるのか
そのロジックを説明するんだよ 20年以上前から語られてるパラダイムが理解できないなら諦めろ
if文の羅列とgrep置換がお前の武器だ
がんばれ
オブジェクト指向はともかく、
関数、構造体、グローバル変数の問題、
この辺りのことでここまで話が通じないとは思わんかったわ。
OOPは設計と相性がいいと思う
手続き型で実装する前提で設計書を書くと
設計書まで手続き型のコードみたいになってしまう
そらそうだ。
言語のプラットフォームに思考も引きずられるからね。
だから何か一つ言語を身につけたら、色々なプラットフォームの言語触っておいた方がいい。
(身に付かないうちは全部中途半端になるから避けるべきだが)
数字を出せと言ってる割に、
どんな数字が出れば納得するかも言わない。
責任者出せと言ってるようなもんだなｗ
ただ文句を言いたいだけ
構造化プログラミングって
数値じゃなくて理論で広まったように思えたけど?
そんな犬のウンコ見たいなもの
鋏で切りとって、捨てﾁｬｲなyo
128 その名前は774人います (ﾜｯﾁｮｲ f967-5nD1) sage 2018/11/08(木) 17:26:52.47 ID:6MGMdNjp0
>>125
メインストーリーはライブラリ使ってツクール感覚だから
手間掛かるのは新規マップ／ムービー／新モンスタープラン
学園で手間が掛かってるのはプログラムだからメインストーリーとは違う
プログラム的にも既存コンテンツ改修するよりは本編と関わらない場所で新しく作った方が楽 オブジェクト指向で設計製造するってだけで単価が倍に出来ました。
ちょっとした設定やinterfaceだけ書いたらクラスを自動実装してくれるやつ最近多いけど
オブジェクト指向のカプセル化とインターフェース分離がうまく機能してるとこういうことができるんだね
自動実装するメタプログラミングの箇所が相当に優秀なんじゃねえの
その箇所のソースは見たこと無いからあんまりヤボなことは言えないけど
自我 チンポ
↓ ↓
チンポ 自我
両方正しい！！！
21 デフォルトの名無しさん 2018/10/19(金) 01:35:00.55 ID:fC+zpJue
オブジェクト指向を漫画で理解しよう！
＞その瞬間、竜哉は体中が引き締まるような快感を感じた
チンポがシコシコするのは、物理的な刺激に限ったことではない。
https://imgur.com/R4D8yyk
https://imgur.com/Fjw9t3F
「アクトレス」（山田謙二）より。
夏目くんのチンポは何にも触れていないのにシコシコしている！ （第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル
＞CycはFredがひげをそっている間、Fredはそれでも人間なのかと尋ねた
チンポがシコシコしている間、俺はそれでも人間なのか？
たとえば、CycはFredという名前の男がドナルドダックのモノマネをするという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には羽がないことは知っているが、
アヒルのように歩き、アヒルのように鳴くものはアヒルに違いないと考えた。
したがって、CycはFredがドナルドダックのモノマネしている間、
Fredはそれでも人間なのかと尋ねた。
>>828
見たくない単語をNGワード登録しやさんせ。 NGワード登録できないやつもNGにするから問題ない
staticおじさん vs constおじさんの地獄絵図
こんな平穏なスレのどこが地獄やねんw
おまえのオトンとオカンに比べたら極楽浄土やわw
外にでろひきこもりw
>>845
こんなことを聞くようなやつがこのスレにレスしてたのか ニートのゴミレスのせいで気まぐれに降臨するベテラン達も寄り付かなくなったな
残念
なんというかもう教養レベルの知識なんだから今更大して議論するところもないし
>>845
え、若い頃はmainでよくvoid main(void)ってしてたが。。。
本当は失敗成功ぐらいは分かるように返り値はあった方が良いんだろうが、別に文法的にはおk。 引数と返り値の区別のついてない奴は無視していいよ、馬鹿に合わせる必要ないから。
>引数 void って初めて見た
これがガンなんだよなぁ・・・
戻り値voidなら見慣れている奴、つまりJavaやってる奴だろコレ
プログラムを職としてる人が返り値っていう？
戻り値だろ？
返り値なんて、新人プログラミング研修のときに、講師のお姉さんが言ってたくらいだわ
お姉さんは美人だったから許す
おまいらは、、
>>851
文法的にはってわざわざ書いたやろ。。。
実際動く。
セオリー的には駄目だろうけど。 >>851
2006年出版の入門書には、返り値って書いてる。
2011年出版の入門書には戻り値って書いてる。
これがジェネレーションギャップという奴か。。。 >>857
どちらも使うなぁ
リターン値って呼ぶこともあった 生理中の女を犯したら、返り血を浴びせられた。
みたいな用法？
509 その名前は774人います (ﾊﾞｯﾄﾝｷﾝ MM5a-fW3D) 2018/11/16(金) 21:30:34.79 ID:LED0s8bKM
>>329
＞何十年も前からあるオブジェクト指向をいまさら教えたい馬鹿は何なんだ。
207 その名前は774人います (ﾜｯﾁｮｲWW 8f08-fW3D [49.128.130.98]) 2018/11/16(金) 21:21:25.27 ID:U3NlEEpg0
>>203
＞夜もビンビンなの？
『オブジェクト指向』と『オブジェクト指向言語』は別だと、プログラマーには叩き込んでやりたくてね。
Rubyとかの高級プログラミング言語は、逆にオブジェクト指向を意識しないでプログラミングできる仕組み。
チ ン ポ が シ コ シ コ す る ！
俺はオブジェクト指向言語を使っているからオブジェクト指向プログラマーだという勘違いを直させてやる！
174 その名前は774人います (ﾊﾞｯﾄﾝｷﾝ MM5a-fW3D) 2018/11/16(金) 07:04:12.40 ID:N77Q/1ZeM
＞ドラゴンクエストの世界観が全く反映されていないような印象
ド ラ ゴ ン ク エ ス ト と は 何 か ？
ドラゴンクエストとは何かを問い続けるのが、終わらないドラゴンクエストだろう？ 違うか？
2 その名前は774人います (ﾊﾞｯﾄﾝｷﾝ MM5a-fW3D) 2018/11/16(金) 07:42:40.97 ID:N77Q/1ZeM
再帰関数を理解するにあたり先輩社員に教えていただいたのですが、その時の再帰関数の例がとてもわかりやすかったので共有させていただきます。
この例のおかげもあり、はじめは再帰関数なにそれ状態から、最後はしっかりと実装できるようになりました。再帰関数はPythonで実装しています。
https://qiita.com/jumpyoshim/items/20e6b5e70efa466699b4 ずっとルビィストがゴミだと言い続けてPHPにはとうとう勝てなかったんだな。
ルビィストは俺らはエリート、PHPは雑魚が多いだけだと思ってる
PHPは脆弱性作成ツールだし、Rubyは言語仕様はともかく宗教家がうざいので嫌です
言語仕様などありません。気まぐれで書いたコードが仕様です！
「言語仕様などありません。気まぐれで書いたコードが仕様です！」
俺の脳内の言語先生はこう言ってるんだが、
どう思う？
枕詞に「純粋な」と付くと危険度が上がるな
過去の純文学／大衆文学／私小説論争や
純喫茶の僭称や
21世紀の現代ではピュアオーディオや純オブジェクト指向がその志を受け継いでる
もちろん賤民思想で、ピュアであればあるほど尊いと考えてるアホが少なからずいる
オブジェクト指向は分かりづらくなるから基本的には害しかないな。
>>878
なんちゃってオブジェクト指向が多過ぎ。 その中で、沿道にいた一人の小さな子供が、
「だけど、なんにも着てないよ！」と叫び、群衆はざわめいた。
「なんにも着ていらっしゃらないのか?」と、ざわめきは広がり、
ついに皆が「なんにも着ていらっしゃらない！」と叫びだすなか、
皇帝のパレードは続くのだった。
皇帝はうろたえるが、家来たちにはオブジェクト指向がわからないとは言えず、
オブジェクト指向のメリットを大声で賞賛し、
周囲のプログラマも調子を合わせてオブジェクト指向を褒める
まんまお前らだなw
staticおじさんと五十歩百歩w
じゃあ上でOOPの弱点を指摘するﾚｽをかいてたオレは
差し詰めその小さな子供見たいに無垢で正直なんだな
流れを読まずに持論を書く
オブジェクト指向とはデータ構造と それに作用するメソッドを結びつけること
逆に言えば、そのデータに結びつかない作用や参照を排除するアクセス機構を持つ
つまりはカプセル化こそが本質
実際、これはオブジェクト指向という言葉がメジャーになる前から使われていて
Cの標準ライブラリにあるFILE構造体はその典型と言える
FILE構造体にはアクセス制限はかけられていない、というかCではかけられないけど
直接アクセスしなくてもファイル操作には困らない
FILE構造体というデータ構造に対する必要十分なメソッドは用意されてる
継承や多態性などはオブジェクト指向を便利に使うためのユーティリティに過ぎない
これらは節度ある使い方をすれば便利だけど、やり過ぎると確かに副作用はある
>>889
それと構造体のインスタンスとの違いは何だと思う？ >>890
質問の意味を取り違えてるかも知れないけど
構造体が使えるならオブジェクト指向は要らないのでは、という意味かな
問題は使い方にある
オブジェクト指向言語とはオブジェクト指向的な作りをサポートする言語 >>891
違いはあります。それは何だと思うのか聞いたのが>>890
使い方は書き方次第なんだけど…
それはさておき
「オブジェクト指向的な作りをサポート」
って何 ま、今夜は寝るわ。
あう機会があったら
またねﾉｼ
>>892
すまんね
>>890 の文の先頭にある「それ」が何を指してるのか不明確だったので
Cの構造体とC++のクラスの違いという意味かな
それは >>889 に書いた通りカプセル化されているかどうかということだろ
Cの構造体ではデータにアクセスするメソッドを制限できないが
オブジェクト指向言語なら出来る
サポートとはそういうこと 「スマンがお前らがガタガタ抜かすよか遥か昔に『オブジェクト』っつう計算機科学用語生み出したの俺なんだわｗ
黙ってようと思ったけどさ、あんまりお前らが的外れなこと偉そうにグダグダ言ってるもんで。しかも枝葉ｗｗ
一番大切なことは何か教えといてやろうか？
それは『メッセージング』だよ」
──アラン・ケイ（俺私訳）
「俺様にとってOOPとは、メッセージング、状態プロセスを隠蔽しローカルに保持・保護すること（薬中：カプセル化のこと）、そしてすべてに対する遅延バインディングの徹底、これに尽きる」
──アラン・ケイ（俺私訳）
アラン・ケイの言うOOPに必須の要素：
・カプセル化
・メッセージパッシング
・動的バインディング（実行時に於けるプログラムの進化・適応能力）
必須ではない要素：
・クラス
・クラス継承
・オブジェクト・関数・データの特別扱い
・newキーワード
・多態（ポリモーフィズム）
・静的型
・クラスを「型」として認識すること
「『オブジェクト指向』っつう用語は俺が造ったが、C++とやらにはそれについて語ることがなんにもない」
──アラン・ケイ（俺私訳）（C++が引き合いに出されてるがこの発言は97年。もっと遅ければJavaになったのだろうか…？）
>>898
こういうこと言うから初心者は混乱するのでは
ケイにしたって先行するSimulaがなければオブジェクト指向を発想出来なかったし
Smalltakも作れなかったと思う >>898
そんなやり方でで
大規模で複雑化するソフトウエアが表現できないから
問題が顕在化してるのに
まぁ寝るわ >>901
何だその言い訳
ラーメンの出前頼んだ人に「ラーメンだと冷めるし伸びちゃうでしょ？だから寿司を持ってきたよ。君にはラーメンじゃなくてコレが必要なんだ！だからコレを今日からラーメンではなくて寿司と呼ぶよ！」と言ってるようなもん。意味不明。
ラーメンの冷める、伸びるといった問題が顕在化してきて、寿司がそれを解決できるからといって、寿司こそが真のラーメンであるということにはならない。 議論してる奴等は全員使ってる技術のメリットもあげられないサル
>>904
だから早く答えて
>>801
> オブジェクト指向のメリットを数字をあげて一つも説明できないわけでしょ？
数字？ オブジェクト指向が使われてる
プロジェクト数とかでいい？
なんの数字がでればいいかいってみて >>906
それは君が思うオブジェクト指向のメリット次第じゃない？
その説明に必要な数字を出せばいい メリットくん、半角くん、チンポくん
ウォッチしてんなーw
nodeやり始めたときに関数型やイベントでどうやってプログラムを組み上げていいかわからず
結局オブジェクト指向の書き方になってしまった
jsは関数型でも非同期が最大のメリットだからまた一味違うんだよな
Goやれ
メリットくんも言語の素養がないしな
まず自分から定量化のための指標を提示しなさいよ
>>907
> それは君が思うオブジェクト指向のメリット次第じゃない？
> その説明に必要な数字を出せばいい
どんな数字を出しても納得しないっていうのだから
聞くしか無いでしょう？ - Simulaはクラスとオブジェクトという言語機能は与えたけど「オブジェクト指向」は（当初は）考えられていない
- （ごく初期の）Smalltalkはメッセージングによる「決定の遅延」の徹底とそのサポートをもって「オブジェクト指向」と呼んだ
- C++は、ユーザーによるデータ型定義（抽象データ型、データ抽象）をSimulaのクラスを使ってやるアイデアを「オブジェクト指向」と呼んだ
だから、「オブジェクト指向」のメリットというのは
- Smalltalk（ケイの主張）の「オブジェクト指向」なら、実装中、実装完了後、必要なら実行中も決定を変えられる柔軟性。
- C++（ストラウストラップの主張）では継承を活用した差分プログラミングと自在に定義可能な型を用いた安全なプログラミング
ということになる。ただし、
前者のメッセージングは主に効率の面からスケールしないことが早々に分かって、Smalltalkを含め
単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
後者も「差分プログラミング」については、「型安全なプログラミング」が保証できない場合があることが早々に指摘され
その用途でのクラスの欠点を補うことを目的に「インターフェース」が考案され現在はこちらが広く用いられている。
とまあ紆余曲折はあったが、前述のメリット（目指す先）はその後も大きくは変わっていない
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
ナンチャッテメッセージングスタイルになることによってプログラミング言語が失ってしまったものは何だったのでしょうか？ >>913
それは君がメリットを明確にしないからじゃん >>916
単純に並行並列・分散というような処理におけるスケーラビリティでしょうね
ヒューイットのアクターはSmalltalk-72（初期のSmalltalk処理系で、非同期ではないながらも
トークン列をメッセージとして一応処理していました）をヒントに、ケイのメッセージングのアイデアを並列処理に応用し
定式化を試みた理論で、今、このアクター理論に基づく言語機能やライブラリを備えた言語が各所で重宝されています
アクター理論こそ真の（ケイの目指した）「オブジェクト指向」だと言う人もいますが、これはちょっと言い過ぎですね
両者はメッセージングという共通項は持ちますが、かたや並列並行処理、かたや決定の遅延と、問題にしている領域が違うので… > - Smalltalk（ケイの主張）の「オブジェクト指向」なら、実装中、実装完了後、必要なら実行中も決定を変えられる柔軟性。
この「実行中」の定義が今と常識とぜんぜん違うんでしょ？
Smalltalkは実行環境でOSみたいなもんだから、
「実行中も決定を変えられる」っていうのは
今で言うOS起動中にプロセスを再起動できる程度の意味でしょう
今はプロセスは通常は複数のオブジェクトの集まりでできているけど
アランケイの時代は1プロセスが1オブジェクトレベル程度の小さなものだった
そういう想定だから1オブジェクトを入れ替えるという発想も理解できるが、
今だと複数のオブジェクトを同時に入れ替えないと正しく動作しないので
そんな1オブジェクトずつちまちまと動作を変えていくなんてありえない
そもそもアランケイの言う「実行中」は「起動中」であって
「使用中」じゃないんだろう。マルチユーザーで誰かが使用している最中に
入れ替えるとか怖くてできない。入れ替えるにしても保存したら即反映じゃなくて
ユーザーが誰も使用してない状態にして入れ替えないとだめだろうしな。
つまりアランケイが求めていた柔軟性は、OSとプロセスの概念によって
もっと実用的な形で実現されてしまった。だから誰も言語にそんな物を求めていない
>>919
なんでこの流れでそこまで徹底的に否定しないと気が済まないのか分からないけど（Smalltalkに親でも殺された？）
「オブジェクト指向」とは何かを説明したまでで、それに対する批判や感想は勝手にやってもらったらいいと思うよ
ただ
> 今で言うOS起動中にプロセスを再起動できる程度の意味
というのはちょっと現状の制約に合わせて矮小化しすぎのような気がする
アラン・ケイが目指したのはたぶん通常は手を入れない（（セキュリティや安全面から当然だが）枠組みそれ自体
（たとえば言語処理系）における決定事項も変更可能なほどの柔軟性（メタ機能）なので
http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf
関連して、（繰り返しになるけどその善し悪しは別にして）自身の枠組みに手を入れられること以外にも
デフォで永続化可能っていうのも今のOS（における仮想化したそれ自体やプロセスの再起動）には考慮されないファクターだよね >>919
いや、今も昔も、Smalltalkではメソッドを実行中のオブジェクトについてもクラス定義やメソッドを変更することができる。
Smalltalk-80が失ったのは、メッセージ自体が持つオブジェクトらしさ。メッセージセレクタはオブジェクトではあるが、ソースコード上はあまりオブジェクトらしい扱いになっていない。 >>921
細かいことで恐縮ですが
> Smalltalk-80が失ったのは
ナンチャッテメッセージングスタイルになったのはSmalltalk-76からなので正確には「Smalltalkが-76以後失ったのは」かと…
> ソースコード上はあまりオブジェクトらしい扱いになっていない。
「ソースコード上でのオブジェクトらしい扱い」って具体的にはどういった感じでしょうか？
メッセージセレクタはメッセージを構成するトークンとして現れていますし、オブジェクトらしい扱いは一応受けているとおもうのですが
「（メソッドコールの）処理上、（セレクタではなく）メッセージが」
（既存メソッドのコールであればVM内で完結することもあって、メッセージっぽい扱いをされていない）、ではなく？ >>921
> いや、今も昔も、Smalltalkではメソッドを実行中のオブジェクトについてもクラス定義やメソッドを変更することができる。
「変更することが出来る」っていうことはわかってるんだよ
そこは重要じゃない。重要なのは変更してもシステムは
エラーなく続行し続けられるか？でしょ？
関数型言語なら状態を持たないからわかるけど
Smalltalkはオブジェクト指向なんだから状態を持っている
状態を持っているまま処理内容だけを変更したら
（データに互換性がない場合）エラー出るでしょ？
クラス定義を変えるならば、インターフェースが変わることだってある
その場合、クラス定義だけじゃなくて、クラスを使っている方も
同時に変更しなければいけない。
もちろんリファクタリングとデータのマイグレーション（変換）を駆使すれば
プログラムを走らせながら、変更するのは可能かもしれないけど、
そんなアクロバットプログラミングなんて誰も求めてない
サービスの一時停止やプロセスの再起動で許されることのほうが多いでしょって話 オブジェクト指向とオブジェクト指向プログラミング言語とは、方向性が真逆。
むしろオブジェクト指向を意識しなくてもオブジェクト指向プログラミングできるのが、
Rubyのような『いわゆる』オブジェクト指向プログラミング言語。
627 デフォルトの名無しさん 2018/11/01(木) 04:32:24.08 ID:PmS8KjrS
一回こっきりの家庭用ソロゲーを作成するなら、オブジェクト指向がチンポがうんたらは必要無い。
──オブジェクト指向の言語を書こうというのに、オブジェクト指向でないCで書かれているというのは意外な気もします。
まつもと「CでRubyのオブジェクト指向を作ってて、その機能はCからも使えるんですよ。
だからRubyのC実装って、Cで書かれているんだけどRubyのオブジェクト指向で書ける。
僕はこれが好みなんですが、違う人も多いみたいですね」
http://ascii.jp/elem/000/001/228/1228027/
しかしながら将来的に改変したり削除したり拡張したりする場合、『チンポ』のような多態性が不可欠。 >>919
＞そもそもアランケイの言う「実行中」は「起動中」であって
＞「使用中」じゃないんだろう。マルチユーザーで誰かが使用している最中に
チンポがシコシコしている間、俺はそれでも俺なのかと尋ねた。
829 デフォルトの名無しさん 2018/11/11(日) 09:52:59.70 ID:y84pWKv0
（第1章 はじめに 2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル >>925
たとえば、CycはFredという名前の男がドナルドダックのモノマネをするという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には羽がないことは知っているが、
アヒルのように歩き、アヒルのように鳴くものはアヒルに違いないと考えた。
したがって、CycはFredがドナルドダックのモノマネしている間、
Fredはそれでも人間なのかと尋ねた。 >>919
＞この「実行中」の定義が今と常識とぜんぜん違うんでしょ？
『オブジェクト指向』なる『概念』そのものはずっと前から俺の股間に付いているんだけど、
『オブジェクト指向プログラミング言語』はごく最近、これまでに無かった『機能』が追加されたんだろう？ >>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。 >>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>922
レシーバ セレクタ 引数
これらのうちレシーバと引数は表現式(オブジェクト)ですが、セレクタはそれ単独では表現式(オブジェクト)ではないですね。もちろんメソッド内のリテラルにセレクタがシンボルオブジェクトとして格納されているので実体としてはオブジェクトですが。 オブジェクト指向のメリット
型を持ってる変数が最初にくるから
書くときIDEのインテリセンスが使いやすくて便利
でも大抵型ついてるし変数が最初にくるからそれが使いやすいんだ
オブジェクト指向以外でそんなのあるか？
オブジェクト指向言語のメリット
オブジェクト指向がやりやすい
>>938
つまりオブジェクト指向にもメリットがないと言いたいのかstaticおじさん ﾊヽ／::::ヽ.ヘ===ｧ
{::{/≧=＝=≦V:/､
／ >:´:::::::::::::::::::::::::｀ヽ＼_
|iγ:::::::::::::::::::::::::::::::::::::::::ヽi| カ
〈/::::::::::::::::::::::::::::::::::::::::::::::ﾊ_》 バ
!:::::::l::::/|ハ::::::::∧::::i:::::::::::i デ
|::::::i∨ ト-:::::/ ,X:j:::/:::::l ィ
r⌒ ヽ ヽ::::| ≧ｚ !Ｖ ｚ≦ i/:::::/ ./'⌒ゝ
. ヽと ヽ ゝ:} “ “ {:::::／ っ丿
＼ ＼::ゝ､ _ ( ) _ イ::／ ／｀
＼ ／::::＼
/::::/｀ヽ r'´ ＼:::＼
/::::/ | _ _」 }ノﾉ
{:::/ | " ヽ
ヽ | 丿
| /'⌒ } " }
| { ゝ,,ノ
| {
| i
ゝ__,,ﾉ
>>945
staticおじさんではないので黙らないｗ >>946
でもオブジェクト指向しらんのやろwそれstaticおじさんやからw >>947
オブジェクト指向知ってるのでstaticおじさんでないことは証明された >>923
> Smalltalkはオブジェクト指向なんだから状態を持っている
> 状態を持っているまま処理内容だけを変更したら
（データに互換性がない場合）エラー出るでしょ？
そのエラーが出てからの対処が容易であることがすなわちケイのOOPの肝たる「決定の遅延」（のサポート）なんですよ
おそらくとうてい許容できない行為だろうとは思いますが、Smalltalkでは日常のこちらを参考まで
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く
＞俺.オシッコを止める
『指でチンポをつまんでオシッコを止める』
＞俺.オシッコを出す
『尿モレ』『尿シッキン』どうする？
>>941
でもこの場合
オブジェクト単位に分ける工程が完全に削除できるんだからメリットってわかるでしょ？
オブジェクト単位に分ける工程が0より大きいので
それが削除できる以上メリットとなる
証明完了 >>951
＞オブジェクト単位に分ける工程
人工知能は『物の意味』を『区別』することから始まるのでは？
776 Mr.Moto sage 2018/09/08(土) 08:57:47.30 ID:Hj3WpMqo
「もの」という言葉が出たついでに言っておくと、
ここでいう「もの」は“individual”、すなわち「不可分なもの。
個人、個体、個物」を意味する。れっきとした哲学用語だ。
ただし、これは「物理的な存在」ではなく、「概念」を
指していて、しかも「具体的な意味」「内包的な意味」を
持たない。その意味で、individual は「意味を引っ掛ける釘」の
ようなもので、「こっちの釘とあっちの釘は、どこがどう違うと
言われても説明できない。ただ、引っかかっている意味が違うし、
比較によって区別できる」ものである。
同じような性質をもった存在として、Codd のデータベース理論における
データベース・キーというものがある。 >>953
違うという理由を人に聞く前に
そうだという理由を述べるのが筋だろ >>955
科学とか工学にはるかに至らない
迷信とか思い込みのレベルだな >>935
そんな風に、セレクタ（的なシンボル）とオブジェクトが一緒くたにして扱われるところが、Smalltalk-72の良いところだと思っていて、76や80のメッセージセレクタはちょっと味付けが違っていて、オブジェクトと一線を画しているというのが、私の個人の感想です。 >>949
> そのエラーが出てからの対処が容易であることがすなわちケイのOOPの肝たる「決定の遅延」（のサポート）なんですよ
エラーが出る時点で駄目でしょ？
> おそらくとうてい許容できない行為だろうとは思いますが、Smalltalkでは日常のこちらを参考まで
許容してはいけないことだね。
エラーが出て止まるならまだいいけど、間違った結果で実行されてしまったら取り返しがつかないもの
アクロバットプログラミングはやめよう Smalltalkの実行しながら修正できるっていうのは、
「最初から再実行しなくても修正できるよ」程度のものなんだろう
最初から再実行すればいいじゃん？
それが今の時代の感覚。
テストコードはあるしプロセスを終了して最初から再実行すればいい
無の状態から再実行するから同じ状態が何度でも作れる
ユニットテストはSmalltalkで一番最初に実装されたが、
これにによって「最初から再実行しなくても修正できるよ」の
価値が大きく下がったのだろう
もちろんSmalltalk開発の初期はコンピュータの性能が低く
Smalltalkの場合、実行環境そのものという設計だったから
再実行できたとしても、再実行するのに時間がかかった
それも今はプロセス単位で再実行できるし、コンピュータの性能の
向上で再実行すれば十分になってしまった。
昔はデバッガを使って実行中にブレークポイントで止めて実行しつつ状態を
確認していたのだが、今はそんなことをすることは殆どなくなった。
なぜなら関数レベルで単体で実行することが簡単になったからだ。
>>957
おっしゃるとおり、今のキーワードに相当するトークンをメッセージ内に適当に混ぜられる自由度は失われていますね
感覚はわかりましたありがとうございます >>951
頭からダラダラ書くことしかできないお前にはそうなんだろうな w >>959
> ユニットテストはSmalltalkで一番最初に実装されたが、
> これにによって「最初から再実行しなくても修正できるよ」の
> 価値が大きく下がった
注目する部分の粒度というかタイミング（あるいはリズム感）みたいなものが互いに食い違っているんだよね
動画にもあるように、たとえTDDであっても再実行せずに直せるのは別にアクロバティックでも何でもなく
むしろ（TDDとしても）自然な流れなんだけどなぁ
決定の遅延派と早期結合派とは一生わかりあえないんだろうねきっと >>962
TDDではまず実行してテストが失敗する状態にしないといけない
実行し終わって結果が出てるんだよ
つまり二回目以降の実行っていうのは「再実行」
この再実行が簡単に行えるわけだが、それに対する
Smalltalkのメリットは未実装の直前まで実行できるってことでしかない
それで一体どんな価値があるというのか？
> 決定の遅延派と早期結合派とは一生わかりあえないんだろうねきっと
価値の話をしてないからな。
決定を遅延できるから素晴らしいんだ！（何が？）
そう、何が素晴らしいのかが書かれていない
過去においては素晴らしいなにかがあったかもしれないが、
それは今は別の技術によって解決されてしまってるということ
別の技術というのは早期結合のことじゃない
別の技術による決定の遅延という意味。決定の遅延自体は行っている。
Smalltalkの言語機能を使っていないだけ
それとも今の時代においても、何か価値があるのか？
なくなってしまってるから書けないはずだ >>963
> Smalltalkのメリットは未実装の直前まで実行できるってことでしかない
> それで一体どんな価値があるというのか？
未実装の直前まで他の準備に煩わされることなく作業をスムーズに進められるのはあきらかに価値あることだろう
未実装でエラーを出した後、仮実装のためのメソッドを追加し１回目のテスト実行を終えられる
この流れを妨げないスピード感はとにかくコンパイルを通すためにいろいろ手続きを踏まないといけない早期決定畑の人には分からないと思う
あと、レッド（→イエロー）→グリーン→リファクタリング→…のサイクルを回すのはたしかにそれぞれは再実行だけど
レッド、イエロー、グリーン、リファクタリングそれぞれの工程で実行中に書き換えられることのメリットは生きてくる
なんか、批判的に指摘してくることの粒度というかレイヤーというかがいちいち外れているんだよね
当たり前なことをしたり顔で主張されても「そうですね。で？」ってなるだけ
たとえばこれもそう↓
> 決定を遅延できるから素晴らしいんだ！（何が？）
アラン・ケイも書いているとおり（念のため再掲）→http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf
使い捨てではない長期運用を想定したソフトウエアの開発において、知見というのはあとからついてくることは誰もが経験済みだろうし
それを開発中、運用中のシステムに適用しようと思ったとき（まあ早期決定脳では思いもよらないことだが…）に役立つのは明らかだよ
たぶん思慮の及ぶダイナミックレンジがずれていてすごく狭い範囲のことしか頭にないんじゃないかな
繰り返し指摘されているような限定された局面での問題であれば今の技術で十分対応できているしそれを否定する気はさらさらないよ
あと、あくまで暫定実装に過ぎないSmalltalkの実装やその欠陥にとらわれすぎでは？
本来であればアラン・ケイの「オブジェクト指向」とそれが目指す「決定の遅延」のために必要な要素は何かや
ストラウストラップらの型をクラス様エンティティでやるアイデアの「オブジェクト指向」との違いが何かが論じられるべきだろう
なんでそんなにSmalltalk（をやっつけること）にこだわるのかね（ほんと親でも殺されたか？） >>964
> 未実装の直前まで他の準備に煩わされることなく作業をスムーズに進められるのはあきらかに価値あることだろう
再実行しても0.1ミリ秒ぐらいの差しかないけど？ >>964
> アラン・ケイも書いている 〜略 〜 親でも殺されたか？）
そいう長文言い訳はいらないんで、
どんな価値があるか書いてよｗ
ホント言い訳だけだな。長いのは 15行以上のカキコはたいていクソなので無条件にNGにしてる。
(.*\n){15}でNG word登録。
>>961
＞頭からダラダラ書くことしかできないお前にはそうなんだろうな w
チンポがシコシコするぜ！！ >>965
> 再実行しても0.1ミリ秒ぐらいの差
未実装メソッドを実装するときににコンテキストが分かれば（つまり実行中なら）実装もしやすいだろうとそういうメリットだよ
再実行する前の話
>>966
> どんな価値があるか書いてよｗ
書いたけど読んでないの？
> 使い捨てではない長期運用を想定したソフトウエアの開発において、知見というのはあとからついてくることは誰もが経験済みだろうし
> それを開発中、運用中のシステムに適用しようと思ったとき（まあ早期決定脳では思いもよらないことだが…）に役立つのは明らか 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
シコシコするは他動詞なので、所有者の意思とは無関係にチンポが自立行動するのであれば「イライラする」「ムラムラする」という自動詞を用いるのが正しい >>969
> 未実装メソッドを実装するときににコンテキストが分かれば（つまり実行中なら）実装もしやすいだろうとそういうメリットだよ
それは実行しなくてもコンテキストがわかるなら
もっとメリットが有るってことかな？ >>966
＞そいう長文言い訳はいらないんで、
チンポがシコシコするぜ！！ 結局Smalltalkの実行中に編集ができるっていうのは単なる
未実装メソッドを実装するときににコンテキストが分かれば
（つまり実行中なら）実装もしやすいだろう程度のことでしかなかったということだ
要するに、テキストエディタの補完機能でなんとかなるし、
型があればもっと実行しなくてももっと正確にコンテキストがわかるということ
大したメリットじゃないんだよね
>>973
> それは実行しなくてもコンテキストがわかるなら
> もっとメリットが有るってことかな？
もとより、コンテキストの関係ない関数型ならいらない機能だけどそれはさておき
それなりの深さを持つコールスタックと状態を持つオブジェクト指向を使い続けるならそういうことになるだろうね
でもホットスワップだとかインクリメンタルコンパイルとか無茶しやがって…って技術をこれまでも早期結合派は編み出してきたわけだから
（君は無理っぽいが）その便利さが分かる人がいれば、いつかコンテキストを実行せずに知る技術もひねり出されるんじゃないかな >>976
そんなにコンテキスト（＝型情報）を知ること重要？ｗ >>977
コンテキストは実行時情報で型情報ではないよ？ OOPのメリットと言う上記全てがCommonLispでも可能だが、別にCommonLispがオブジェクト指向だからというわけではないぞ
実行時の環境がどれだけ豊かかという点はオブジェクト指向に関係は無いよ。smalltalkの特徴と混同し過ぎではないか？
>>978
「じゃないよ」じゃなくて
何かを言えって >>979
> OOPのメリットと言う上記全てがCommonLispでも可能
アラン・ケイは彼のOOPで目指した「決定の遅延」がLispでも（というかSmalltalkとLispのみで）可能と述べていますから当然ですね
「決定の遅延」を「メッセージング」というメタファー（まあ実際に送るのでもいいのですが）を使って目指すのがケイのOOPなので
「メッセージング」を使わずとも「決定の遅延」は実践可能だからこれは（ケイの）OOPの本質ではないという指摘は
主客を取り違えています。
同様のことはビョーン・ストラウストラップらの「ユーザー定義型をクラス（様エンティティ）でやる」アイデアのOOPについても言えて
ユーザー定義型（データ抽象、抽象データ型）はクラスのない××言語でもできるから、これはOOPの本質じゃない！という指摘も
やはり的を外しています ほんとなぁ「決定の遅延」を言語でやることが目的になってるよなｗ
なんのためにやるのか？それは言語以外のレイヤーで実現できないのか？
それが抜けてる
>>980
書いてあるじゃんｗ
実行時のもろもろの情報だよ
コールスタックだったり、インスタンス変数情報だったり、テンポラリー変数情報だったりとにかく様々だよ
もちろん型情報も含まれるけど「イコール」ではない > コールスタックだったり、インスタンス変数情報だったり、テンポラリー変数情報だったりとにかく様々だよ
つまりデバッガとブレークポイントによって実現できることって話か
決定の遅延となんの関係もないｗ
>>983
別に言語のみにこだわる必要はないと思うよ？どうしてそんなふうに思う？
とにかくSmalltalkを気にしすぎだよ
他のレイヤーでできているならそれでいいと思うよ
Smalltalkについては学習コストを鑑みて
全てをオブジェクトとそれへのメッセージングというシンプルなドグマで解決できるならベターだし
言語（というかOSモドキ）ならそういう世界を比較的簡単に実現し、そこでの実践を通じて実用性の検証ができるというだけの話だろう 結局の所、決定の遅延で何が出来るか？というとデバッグ時にソースコードを
編集する機能が作りやすくなるというメリットだったって話で良いかね？
↓つまりこれ
コードを編集し、(c#、VB、C++)、Visual Studio でデバッグを続行
https://docs.microsoft.com/ja-jp/visualstudio/debugger/edit-and-continue?view=vs-2017
> エディット コンティニュを使用すると、プログラムが中断モードのときに
> ソース コードを変更できるため、時間を節約できます。 などの実行コマンドを選択して、
> プログラムの実行を再開すると続行または手順、エディット コンティニュに
> 自動的にいくつかの制限でコード変更を適用します。 このため、デバッグ セッション中に
> コードを変更できます。デバッグ セッションをいったん停止し、プログラム全体を
> 再コンパイルしてからデバッグ セッションを再開する必要がありません。 >>985
> つまりデバッガとブレークポイントによって実現できること
そこからまたエディタに戻って定義して再実行して…って手間は俺はいやだなって話をずっとしている >>987
これはかなり近いかなと思って試してみたことあるけど、変更が反映されないんだよね
結局再実行は必要 >>986
> とにかくSmalltalkを気にしすぎだよ
それはSmalltalkぐらいだからだよ
「決定の遅延」という言葉が独り歩きして
それで何が出来るのか？が語られないのは。
でもはっきりしたじゃないか。デバッグ時にソースコード編集機能を
実現しやすくなるのが「決定の遅延」
そして別に決定の遅延をしなくても、デバッグ時にソースコードを編集する機能は実現できる。
言語のメリットとして上げるほどのことでもなかった。 >>988
> そこからまたエディタに戻って定義して再実行して…って手間は俺はいやだなって話をずっとしている
え？バグ無しで一発で作れるの？すごいね（笑）
結局再実行するでしょ >>990
> それはSmalltalkぐらいだからだよ
そりゃそうだよ
今のところLispとSmalltalkくらいしかできないことのさらに高みを目指そうっていう話なんだから…
早期結合派は誰か目先の利く人が無茶をして実現された技術が導入されて普及しないかぎり永久に理解できない話だと思うよ もう早期結合派とか言わんでくれる？
コードを編集してデバッグを続行する機能でしかないんだから
昔はホットスワップなんてアクロバチックな機能はいらない
インクリメンタルコンパイルなんてコンパイル速度が速ければいらないだろとか言ってたクチじゃないの？
図星かｗ
Smalltalkが「決定の遅延」を実践し難なく実現したアクロバチックな便利機能を
早期結合派の有志が無茶をしつつも実現し普及させ、君みたいな想像力に乏しい人でもしたり顔でその恩恵にあずかれる
いい話じゃないか
>>965
>0.1ミリ秒
そうか、MSは0.1ミリ秒のために多大なリソースを投入してデバッグ中のメソッドのホットパッチ＆継続実行を可能にしたんだな。www >>997
時系列が逆ですね
多大なリソースを投入してデバッグ中のメソッドのホットパッチ＆継続実行を可能
にしたので、0.1ミリ秒ぐらいのメリットしかなくなったんですよｗ SmalltalkのOSモドキはLinuxやWindowsといった本物のOSと比べて
あまりにも出来損ないのゴミなのが問題なんだよ
決定の遅延？大変結構だと思うよ？本物のOSの上で出来るならね
でもゴミOSモドキの上でOSゴッコするくらいなら決定の遅延なんて要らない
だから最初から言ってるように、Smalltalk初期の時代はメリットが
あったかもしれないけど、今となっては言語機能に含めなくても
別の方法で本来の目的が達成できるようになったと言ってる
mmp
lud20191013170010ca
このスレへの固定リンク： http://5chb.net/r/tech/1539872441/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「オブジェクト指向ってクソじゃねぇよ？ Part2 YouTube動画>3本 ->画像>8枚 」を見た人も見ています：
・オブジェクト指向ってクソじゃねぇかよPart3
・オブジェクト指向ってクソじゃねぇかよPart4
・オブジェクト指向ってクソじゃね？
・オブジェクト指向ってクソかよPart5
・プログラマに聞きたいんだけどオブジェクト指向ってクソじゃね？
・オブジェクト指向はクソじゃなかったよ Part3
・実は「オブジェクト指向」ってクソじゃね？これデスマーチの原因じゃね？
・すまん、プログラミングのオブジェクト指向ってなんなん？PGモメン頼む
・オブジェクト指向って自然な文法だな 3
・Perlのオブジェクト指向って無理やり実装だなｗ
・Perlのオブジェクト指向って無理やり実装だなｗ
・C++はクソだがオブジェクト指向がクソなのではない
・オブジェクト指向 って結局のところなんだったの？
・関数型プログラミングが人気に おまえらオブジェクト指向が最高って言ってたよな？ あれ嘘だったんだな
・ オブジェクト指向を今すぐやってください
・オブジェクト指向システムの設計 172
・オブジェクト指向が無かった頃って
・関数型言語とオブジェクト指向型言語って
・オブジェクト指向とはモノに着目した考え方です←は？
・オブジェクト指向システムの設計 174
・オブジェクト指向システムの設計 173
・オブジェクト指向以外のメリットを書くスレ
・LinuxカーネルはC言語なのにオブジェクト指向
・状態管理技術★オブジェクト指向 VS モナド(関数型)
・デスマーチの原因は「オブジェクト指向おじさん」だった…
・オブジェクト指向とは 分かりやすく教えてくれ
・オブジェクト指向はオワコン？
・オブジェクト指向は愚かな考え。この世は計算式 ★3
・プログラミングを学ぶ上で苦戦する用語 「オブジェクト指向」「配列変数」「タプル」あとは？
・オブジェクト指向は愚かな考え。
・オブジェクト指向は愚かな考え
・「オブジェクト指向」は愚かな考え
・オブジェクト指向を教えてくれ！
・オブジェクト指向を教えてくれ！★２
・オブジェクト指向はガラケー
・Webでオブジェクト指向プログラミング
・【隔離】オブジェクト指向アンチスレ
・OODB - オブジェクト指向データベース
・オブジェクト指向の活用方法を教えて下さい
・「オブジェクト指向」の難しさは異常 [無断転載禁止]
・オブジェクト指向を完全に理解した者しか開けないスレ
・オブジェクト指向でアルゴリズムとデータ構造はどう
・BootStrap自体がもうオブジェクト指向なんだよね
・Smalltalkとオブジェクト指向議論スレ [無断転載禁止]
・オブジェクト指向プログラミングがなんたるかを理解した
・カプセル化の有害性、オブジェクト指向は愚かな考え
・「オブジェクト指向」についてわかりやすく語れ！
・オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
・【嫌儲プログラミング部】オブジェクト指向は愚かな考え 排便メソッドを実装した人間クラスから美少女クラスが作れない
・WindowsNT互換指向 - ReactOS Part10
・【ドラプロ】ドラゴンプロジェクト part226【クソ絞りガチャ】
・関東って観光クソすぎじゃね？ Part3
・プログラミング詐欺？情報商材屋マナブ（ねずみ男・アル中）ってどうよ？ Part2
・【ドラプロ】ドラゴンプロジェクト part227【クソ絞りガチャ】 [無断転載禁止]
・トイレなんて行ってんじゃねーよ Part2
・未だに新台動画公開してるYouTuberの『桜鷹虎』ってヤバすぎじゃね？ part2
・New！泉佐野市ってどうよ？ Part2
・白猫プロジェクト 初心者スレ Part2
・最近のゲームってオブジェクトが多過ぎて視認性が悪くないか？
・成蹊大学ってクソ以下なの part2
16:45:45 up 21 days, 17:49, 0 users, load average: 9.57, 9.78, 9.99
in 0.025084018707275 sec
@0.025084018707275@0b7 on 020406
|
