オブジェクト指向を教えてくれ！
レス数が1000を超えています。これ以上書き込みはできません。
オブジェクト指向について、調べれば調べるほど疑問が募ります。低レベルで粗末な疑問かも知れませんが、ご教授願いたいです。
・データと振る舞いをまとめる？
まとめると何か良いことあるの？
ファイルあるいはモジュールにはまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
(Javaには1ファイル1クラスという文化あるらしいけど)
・カプセル化？
モジュールのimport, exportでも実現出来るよね？
(構造体などへのアクセスを制限できれば)
・ポリモーフィズム？
別にデータと振る舞いをまとめなくても実現出来るよね？
・モノのように扱いたい？
モノとして扱いたいときに扱えば良くない？ なんでわざわざ全てをオブジェクトにするの？ オブジェクトはクラスのことだとわかるけど
モジュールはなんだろ、パッケージのこと？ > ・データと振る舞いをまとめる？
> まとめると何か良いことあるの？
データが複数ある場合に、データごと振る舞いが
決まっているということが明確になります。
> ファイルあるいはモジュールにはまとまってるよね？
データと振る舞いがまとまっていません
> (構造体などへのアクセスを制限できれば)
それができないから、オブジェクト指向があります
> 別にデータと振る舞いをまとめなくても実現出来るよね？
データごとに振る舞いが変わるということが明確に表現できます。
> モノとして扱いたいときに扱えば良くない？ なんでわざわざ全てをオブジェクトにするの？
関数もモノとして扱えば、モノに対して関数を割り当てることが出来ます。 用語に振り回されてプログラムできなくなるアホの典型例 たとえば 4980012345678901 という値は VISAのクレジットカード番号ですが、
これがただの文字列であれば、クレジットカード番号とした正しいかをチェックする
validate() メソッドがあるわけがないことがわかります。
4980012345678901 という値に対してクレジットカード番号というクラスを割り当てると
この値に対する validate() メソッド が存在することが容易に推測できます。 >>2
オブジェクトとクラスごっちゃにして説明してすみません。
モジュールは大雑把にいうとファイルのことを指して言いました。Pythonでいうとfile, Rustでいうとmod module_name { }のことです。node.jsではfileです >> 3
回答ありがとうございます。
> データと振る舞いがまとまっていません
では、何をまとめたものなのでしょうか？
> それができないから、オブジェクト指向があります
構造体へのアクセスを制限する機能があれば、メソッドをまとめなくとも十分なのでは？という意味です
> 関数もモノとして扱えば、モノに対して関数を割り当てることが出来ます。
曖昧な表現で申し訳ないです。モノというのは値のことではなく、メソッドを生やしたオブジェクトである必要があるのか？という意味です。
この疑問の答えは「データが複数ある場合に、データごと振る舞いが決まっているということが明確になります。」という回答に含まれると思いますが。 > では、何をまとめたものなのでしょうか？
データと振る舞い
> 構造体へのアクセスを制限する機能があれば、メソッドをまとめなくとも十分なのでは？という意味です
構造体へのアクセスを制限するには、データと振る舞いをまとめないと無理
> 曖昧な表現で申し訳ないです。モノというのは値のことではなく、メソッドを生やしたオブジェクトである必要があるのか？という意味です。
関数には名前という属性があります。どのような引数を渡せるかという情報を持っています。
明らかに関数以外の情報を持ったモノです >>5
回答ありがとうございます。
データに対して、「クレジットカード番号」という型を割り当て、
クレジットカード番号に対して処理できる関数を用意すれば解決なように思えるですが、
わざわざオブジェクトに付属するメソッドという概念を用いるメリットがわかりません。 >>9
文字列はクレジット番号として使えるから～みたいに
文字列に対する操作を追加していったら
文字列に対してできることが膨大になりすぎて
管理できなくなるだろ オブジェクト指向はグループ分け
グループに分けないと管理が大変になる
オブジェクト指向はクラスを多数定義できるとも言いかえられるな >>8
> 構造体へのアクセスを制限するには、データと振る舞いをまとめないと無理
たしかRustではプロパティにpubを修飾で制御できたような気がするんですが。
> 関数には名前という属性があります。どのような引数を渡せるかという情報を持っています。
明らかに関数以外の情報を持ったモノです
なるほど。確かにそのような情報をもってますね。失念してました。
しかし例に挙げられた名前や引数などはプロパティであってメソッドが必要ということにはならないような気がします。
>> では、何をまとめたものなのでしょうか？
>データと振る舞い
クラスにデータと振る舞いがまとまっているということでしょうか？私が聞きたいのは、ファイルやモジュールには何がまとまっているのかです。 >>10
だから「クレジット番号という型を割り当てる」って言ってるんやで
文字列型のまま扱うとは言ってない。 >>11
確かに、それはメリットfile単位に対するメリットになりそうですね。
ただ思ったのは、モジュールとか名前空間を定義した方がシンプルな仕様な気がします >>1
>・カプセル化？
クラスや構造体の内部要素へのアクセス制御のことを指してカプセル化と言ってるなら
そういう機能があればいいだけなのでオブジェクト指向じゃなくてもできる
>・ポリモーフィズム？
これもオブジェクト指向である必然性はないよ
他のやり方でも実現できる
>・モノのように扱いたい？
オブジェクト指向を使うのにモノのように扱いたいという動機はない >>15
> クラスや構造体の内部要素へのアクセス制御のことを指してカプセル化と言ってるなら
そういう機能があればいいだけなのでオブジェクト指向じゃなくてもできる
なるほど。カプセル化は「クラスや構造体の内部要素へのアクセス制御」を行い、
それらにはメソッドを介して制限するのがカプセル化と思っていたんですが、そうではないのでしょうか？
(この文脈ではメソッドではなくモジュールから提供される関数を指していますが)
> これもオブジェクト指向である必然性はないよ
他のやり方でも実現できる
オブジェクト指向では、ついでにやってるという感じで良いでしょうか？
> オブジェクト指向を使うのにモノのように扱いたいという動機はない
良くネットにある解説記事ではそのように説明していたので、
何かそういう動機もあるのかと思ってました。少なくともそう考えてない方もいるのですね。 オブジェクト指向じゃなくても他のやり方で出来る
→他のやり方でやってる言語は？
→ない、なぜなら他のやり方でできるが、それは冗長で使いにくいから
→つまりやりたいことをやる場合に、オブジェクト指向言語が一番スマートな構文を持っている C言語を使う理由は？アセンブラでも出来るのでは？
みたいな話
頑張るぐらいなら、オブジェクト指向を使う 全部スタティックなメソッドで作ることを考えてみると少しは分かるかな？ >>17
Lisp系の言語やML系の関数型言語は、オブジェクト指向ではない言語の一例かと。(lispはカッコに問題あると言われてもしょうがないかも知れませんが)
なるほど、オブジェクト指向をすることで、>>1で質問したようなことが実現できるのがメリットなのではなく、それらを最もスマートに実装できることがメリットという主張なのですね。
オブジェクト指向が最もスマートであるという理由, 根拠が気になりますね。よろしければ教えて下さい。 >>19
メソッドにすることで名前空間を汚染しないよね？ということですか？ >>21
あ、staticメソッドなら全然違うか。 "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." - Alan J. Perlis >>16
内部要素へのアクセス制御を指してカプセル化という人もいれば
データと振る舞いをオブジェクト等の1つの言語要素にまとめることをカプセル化という人もいる
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
ポリモーフィズム自体はオブジェクト指向で書く場合でもそうでない場合でもほぼ必須の機能
オブジェクト指向の場合はいろいろあるポリモーフィズムのやり方のうちSubtypingを多く使うというだけ データとそのデータの処理をひとまとめにしたのがオブジェクト指向
この方法論を使うと大規模プログラミングがよりよくなるという強い信仰がある
宗教に近いかもな
他に変わる方法もないし
なんとなく大規模プログラミングを書くと破綻することはよく知られている
万能ではないけど
いくらでもうまくいかない例は挙げられている データを振る舞いをまとめたオブジェクトを中心的な単位要素としてソフトウェアを作る/捉えるのがオブジェクト指向
ソフトウェアの要素をまとめる方法の一つなので他の方法に比べたアドバンテージもあればディスアドバンテージもある
例えば画面上のボタンもテキストもリンクもタイトルバーもみんなクリック可能で
クリック時にはそれぞれ別の動きをするとした場合に下記のようなAPIに整理するのがオブジェクト指向的
button.click()
text.click()
link.click()
titilebar.click()
clickableならそれぞれの型がclickメソッドを持ってる(clickメッセージに応答できる)
新しくタブをクリックできるようにする場合に他の要素に影響を与えずtab.click()を実装できる
逆にtouch()にも反応するようにするためにはそれぞれの型にtouchメソッドの実装が必要 click(button)
click(text)
click(link)
click(titlebar)
オブジェクト指向的じゃなく上記のように実装した場合は
受け取る型によってclick関数を多重定義したりclick関数内部で分岐が必要
それにclick関数がどの名前空間・どのモジュールに属するかを別途検討してそれを覚えておかないといけない クラスやオブジェクトの1箇所(1つの型)にデータと振る舞いをまとめるんじゃなく
Traitとか型クラスと呼ばれるもの(HaskellのType Class, RustやGoのTrait, ClojureやElixirのProtocol等)を使う方法もある
Traitは振る舞いの型をデータの型とは分けて定義して、特定のデータ型に対する振る舞いの実装を書いて紐付けることで
関数の多重定義や関数内部で分岐を不要にできる(Subtypingとは別の形のポリモーフィズム) >>26
初耳でした。カプセル化と言っても意味に２つの流儀があるのですね。
> オブジェクト指向の場合はいろいろあるポリモーフィズムのやり方のうちSubtypingを多く使うというだけ
本筋からそれるかもしれませんが、なぜオブジェクト指向ではSubtypingを多く使うのでしょうか？ >>27
オブジェクト指向は信仰的な要素も強いのですね Ｃの時代
mallocしたメモリのサイズにユーザーが直接アクセスすることはできなかった
それはンパイラによって実装が秘匿されつねに整合性が保たれた
名前すらなかった昔からオブジェクトはモノリスのごとく存在したのだ >>28
GUIやゲームを作る場合、オブジェクト指向が感覚的にですがしっくりくる感じがしますね。(ゲームは作ったことないですが)
なるほど、オブジェクト指向的アプローチと関数型アプローチには1例には過ぎませんが、そのような違いがあるのですね。 >>30
パラメータ多相性ですよね。
個人的にはトレイトと型クラスのような多相性の方が自然に思えたので、
なあなあにしていたオブジェクト指向にはどんなメリットがあるのだろう、
オブジェクト指向の方が綺麗なプログラムが書ける場合があるのか？と思い調べ始めました。 難しく考えすぎじゃね？
例えばC言語時代ならファイル操作はFILE構造体がファイル操作の中身だった訳だが
C++でクラスに設計しなおすとFileクラスでファイル操作の実装等はブラックボックスで良くなる
これだけだと簡単でそんなに恩恵無いとなるが
次にCSVファイルをもっと簡単に扱いたいなとなるとすると、Fileクラスにgetcsvやputcsvみたいな
csvの1行の操作メソッドを追加してもいいけどあくまでFileクラスなので
CsvFileクラスを新設し、Fileクラスから継承または内包しgetcsvやputcsvを実装した方が
スマートだと思うが、この辺の話が理解出来ないと中々難しいような気がする オブジェクト指向だと
「ファイル」を「開く」
手続き型だと
「ファイルオープン」で「ファイル」を開く
頭痛が痛いみたいに冗長な表現になる >>36
たしかに継承はオブジェクト指向独自の機能な気がしますね。オブジェクト指向でないとFileに対する関数を同じ実装でもCsvFileに再度実装する必要があるので。
内包(合成, コンポジション)の場合は、ほぼ同等ですが。
ただ最近は継承の機能が無い言語も出てくるくらいには, なかなか扱いづらい機能なので、そこら辺はどうなんでしょうか？ >>37
なるほど確かに名前が衝突しやすいので冗長になりがちな所はありますね。
データと振る舞いをまとめるメリットの1つに思えます。
(ただこの場合はopen(file)でもそこまで問題ない気がします。getとかは冗長になりやすそうです) むかしは組み込み関数や簡単なライブラリレベルみたいなものまで
いちいちプログラマが毎回書いてて
「めんどくせえから再利用したい…っつかできないと大規模プログラムできねぇ」と
「中の変数類をどっかわけのわからないとこからアクセスして弄るのは
プログラムの修正方法として手軽だけど、これやってるとわけがわからなくなるわ！」
がどんどん出てきたので
・入口出口を決めてブロック化しようぜ
・ブロック単位で再利用する言語的なしくみを取り入れようぜ
から、さらに
・「ブロックにAを入れてBが出る」じゃやっぱりなんだかわかんなくなるじゃねーか
ここにも人間が読んでわかるクッション入れて
「ファイルを読み込むクラス.読み込む(ファイル名)」とか出入り口書こうぜ
ってなった…あたりがまだ現行かなぁ…
とにかく「俺がわかればいいんだよめんどくせえ！」ってプログラマの思惑と
「それじゃわかんなくなんだよ！」がずっとせめぎあって常に中途半端なとこに仕様がある感じ。
30年以上前のObjctive-Cの「で、おまえはなにができるオブジェクトなんだっけ？」って
動的問い合わせとか「そんなの“実用”じゃ要らん！」ってモダン言語()じゃ削られるしw 20年ぐらい前に学生の頃に聞いたエージェント指向
初めて聞いた時に、オブジェクト指向にメタ情報つけただけじゃん
メタ情報つけた所で、問題解決できるオブジェクトが存在してなきゃ意味ないじゃん
とか思っていたが、やっぱり流行らなかったな open(file) と file.open() は書き順が違うだけで意味は同じ。
文法的にはopenは動詞、fileは対象語。
対象語は英語でいうとオブジェクト。
file.open() は対象語が先に来るからオブジェクト指向で良いかと だがopenという名前をグローバルに定義しないといけなくなる
open(database)という使い方ができない >>40
クッションというのは
・ファイルを読み込むクラス
・読み込む
のどちらですか？ ファイルを読み込むクラスに関して、モジュールと解決する問題の領域が被っている感じしますね。(当時は無かったということでしょうか？)
Objective-Cは詳しくないのでよく分かりませんが、今は静的解析によってエディタが補完してくれるので関数(データ)よりもデータ.関数の方が便利には感じます。 >>41
私が言っているものがそのエージェント指向というものに近いということですか？ >>42
open(file), file.open()の意味が同じなのは理解しています。(機能としてメソッドにはオブジェクトへのアクセスができるという点は異なりますが)
つまり、オブジェクト指向かどうかは記法で決まると言うことでしょうか？ >>43
名前空間を汚染しないというのは、オブジェクト指向のメリットだと思います。
たしかに、異なるデータに対して使いたいときはオーバーロードするか、fs.open(file)とか書く必要あるので、やはり名前空間の解決のメリットは大きいですね。 現在、オブジェクト指向を使う主な利点は、
・データが名前空間になる
・継承で記述量が減る
の2点で、他の機能については様々な実現方法はあるものの、言語の一貫性、統一性のために、独自の機能が備わっている。
といった認識で良いでしょうか？ >>48
「いや、他にもあるわ」
って方いたら教えて下さい カプセル化の意義が理解出来ないアホに何言っても無駄だし
それだけでも分かればスレタイのようなことをいちいち聞かない
ポリモーフィズムの意義について理解したければ
ローカルファイルシステムも
ネットワークファイルシステムも
似たように操作できる利点と
その実現方法に想いを馳せれば充分
下らないスレを建てたことを自覚しろ
目の前の言語の機能をまともに使え
ライブラリのインターフェースから常識を学べ
机上の空論をダラダラ並べるな >>51
カプセル化, ポリモーフィズムの意義がわからないとか一言も言ってないんだがw >>52
おう、>>1 を読んでなかったわ
適当にスレタイと直近のレスの雰囲気だけ見て
タイトルの疑問に答えてやった
obj.method()ではなくmethod(obj)みたいな記法なら
オブジェクト指向ではないみたいな
しょうもない戯言はとっくの昔に頭から追い出してるから
あんな下らないことが >>1 にダラダラ書いてるとは思わなかったわ
そういう扱いが妥当な疑問だってことだよ
それぞれの記法のメリット、デメリットぐらい
見れば分かるだろうが
いい加減にレスして悪かったな >>52
スレタイが悪い
名前の重要性が分かったろう
こんなガバガバなセンスでネーミングされた
モジュールやメソッドが山ほどあるシステムを想像してみろボケナス >>54
確かに、スレタイと>>1の質問の仕方は悪かったなとは反省してる。聞きたいことそんまま書いたら誰も反応しなくて埋もれると思ったんや。
メソッドが山ほどあるのはきついが、モジュールは構造化されてれば問題ないし
、そういう言語が大半だろ クラス指向の言語はなんだかんだでヘルプが見やすい
Microsoftが膨大なライブラリを公開する上で
他の選択肢なんかあり得るのか具体的に細かいところまで想像してみろ >>53
記法に関して言うと、>>42の回答の意味, 主張を確認しただけであって、別にそうだと思ってない。そして記法にメリットとデメリットが存在するのは自明だし、どっちもどっちだと思ってる。
あくまで疑問としては、オブジェクト指向のメリットとして挙げられるものに、他にシンプルな実現方法があるのに、それでもなおオブジェクト指向であるメリットは何なのか、だった。 >>57
ローカルで無駄なくシンプルにするならすればいい
プログラムで世界の発展を目指していったらオブジェクト指向が
効果的ってこと >>57
お前の言うのオブジェクト指向では無いものって何のことだよ
せいぜいクラス指向じゃ無いもの程度の意味じゃないのか
カプセル化とポリモーフィズムがあれば
記法や語順がどうであろうとオブジェクト指向と呼んで良い
何が知りたいのかハッキリしろ 優劣で考えるからわからなくなるので
プログラム界の政治的な方針と考えればいいんじゃ
作る側としては０と１をコントロールできたほうが
無駄のないものができる >>59
クラス指向あるいはプロトタイプ指向を指して、オブジェクト指向と呼んでる。
ちなみに俺の言うカプセル化は「直接アクセスを制限するための言語機能」という意味。 >>61
要はデータと振る舞いをバンドルすることをオブジェクト指向と呼んでる。 ポリモーフィングとか知らんけど
オブジェクトを継承しすぎてわけがわからなくなる
から上の方でまとめるってことだろ >>58
>>60
歴史的な経緯でオブジェクト指向良いよねという政治的方針が固まった。
そのときのプログラム界の方針に合わせて、一貫性や統一性を重視したほうが良いプログラムになるってことでしょうか？ >>64
「歴史的な経緯」だけでなく、歴史的経緯及び世界的情勢 >>64
歴史とか政治とか比喩だし
上流から見たらオブジェクトを作れば下々も扱える
ようになるという
一種のプログラミングだね 別に手続き型でも変わらないという意見は分かるけど
細かい事だがVSCodeなどでインテリセンスで表示されるパブリックなメソッドやプロパティの候補が
全てが分かるのは効率良いかと思う
これが手続き型では、どういう関数があるかを覚えてないといけない点は何気に違うかなと
クラスにまとまっている方が何かと美しいし、メソッド名も冗長にしなくて良いという点も価値があると思う
fopen()とFileクラスのopen()ではオブジェクト指向の方が個人的にはすっきりすると思う
DIでモックとか作ったりする場合もinterfaceでメソッドだけ宣言して実際のクラスの実装が切り替えられるような
使い方が出来るのも何気に便利だと思うし、一度使いだしたら今更手続き型の方法で機能を提供する意味が無いかなと >>66
それはメソッドというインターフェイスがあることによって、オブジェクトの使用者も余計なことを考えずに使えるという意味でしょうか？ メジャーな多くの言語に生き残っている記法のメリットが本気で分からないなんてのは頭おかしいレベルだからな
大抵のケースで最適解なんだよ
単なるメンバアクセスと計算を伴うプロパティ取得を
同じインターフェースに統一可能で
それが最小限の記述で出来る文法が前提で…
というだけでも、もう色んな選択肢が限られてくる >>67
補完機能に関しては、単純に文法の問題であって、型推論に完全性があれば機能すると思うのですが。もしかして私が何か勘違いしているでしょうか？
メソッド名に関するメリットには>>48等に書いたとおり同意できます。
interface等については、データと振る舞いのバンドルという概念を用いずとも、ポリモーフィズムを実現する方法があるので、そちらのほうが良いのでは？というのが私の疑問です。
ちなみに、私は手続き型派というよりどちらかというと関数型派です。 オブジェクト指向言語というのは「オブジェクト指向ができる言語」ではなく
オブジェクト指向をするための構文が備わってて「オブジェクト指向がしやすい言語」という意味 >>71
それは理解していますが、そのオブジェクト指向をする目的はなんですか？
オブジェクト指向のメリットに挙げられるものが、よりシンプルに実装可能なのになぜオブジェクト指向する必要があるの？という質問, 疑問です >>72
LINEとかいろいろなもの
ホームページすらできないよ
個人的なクレーム言ってるだけなんじゃ >>73
できますよ。LINEを作ったことはないですが。
クレームですか。それでもなおオブジェクト指向である理由があるなら、納得しますよ？というかそれが知りたくて聞いてるんです。 >>69
記法のメリットには同意してます。一つのオブジェクト指向のメリットであると思います。
「単なるメンバアクセスと計算を伴うプロパティ取得を
同じインターフェースに統一可能」このようにする利点を教えてくれないですか？
モジュールによるカプセル化ではなにかデメリットがあるんでしょうか？ モジュールとカプセル化は知らんけど
好きにすればいいんじゃ
知らんけど >>72
>よりシンプルに実装可能
その例をコードで示してくれれば議論が進むんでないの？ >>77
まぁそうですね。でも面倒くさい気持ちあるんで(不毛な議論続けるよりマシか？)、ポリモーフィズムは継承やinterface以外の方法もあるんやぞで納得できないかな？いやどっちも見せた方早いでしょうか？ >>72
オブジェクト指向は人間のメンタルモデルに一致してるからわかりやすい
俺の机の横には卓上時計というモノがある。
卓上時計には、いろんな機能がある。
それらの機能は、そのモノ特有の機能である。
という文章をモノを排除して説明してみ >>79
>>1の最後の「モノとして扱いたい」という考え方したいということで間違ってないですか？ カプセル化についてはこんな感じです。
mod hello {
type NameString = String;
pub struct User {
pub name: NameString,
age: usize,
}
pub fn the_user() -> User {
User { name: String::from("Alex"), age: 10 }
}
pub fn get_age(user: &User) -> usize {
user.age
}
}
fn main() {
use hello;
let user = hello::the_user();
let age = hello::get_age(&user);
println!("name: {}", &user.name);
println!("age: {:?}", age);
println!("age: {:?}", &user.age); // private field!
} >>78
>不毛な議論続けるよりマシか？)
当たり前だ
話に具体性がないせいで全ての議論が空転して
結論も出ようが無いのに
その程度のこともなかなか察しない奴だから
ハッキリ言って馬鹿だと思われてると思うよ
大体、モダンな言語は関数型言語の機能も大体持ってて
あからさまに関数型インターフェースの方が良い類のライブラリは普通にそのように書かれるようになっている
一体、既存のどんな例を、お前のどんな案で置き換えて
どのように良くなると言いたいのか
具体的な例を出せや
どうせデメリットの指摘が普通に来るから
具体的にやってみろ
クソみたいに単純な処理が山ほどあって
一部だけ異様に複雑でコロコロ仕様が変わったりする業務プログラムを
HaskellでC#より簡潔に書けるもんなら書いてみろと言いたい >>81
UserだけじゃなくPCやスマホ、DogやCatも含まれてるコレクションからそれぞれの名前のリストを出力出来るようにしてよ >>84
この言語だと継承できないんですけど、ポリモーフィズムだけ実現できればいい？ >>81
これこそ関数型で書くメリットが何一つアピール出来ない例じゃないか
少しは多数派より優れた点を示せ
既存の慣習に挑戦しようとしてんじゃねーのかよ
例えばC#でどれだけ簡潔にプロパティ書けるか知ってたらこんな例は出さないだろ
プロパティだってポリモーフィックに出来るんだぞ
これが30個の項目のアクセサを持つ報告書だったらどうなるか想像しろ
しかも一部のプロパティはネストしたプロパティを持つ別のオブジェクトのリストだったりとかザラだぞ
get_ageがそんなアクセサの一つだったら
使う側が探すだけでもダルいだろう 簡単に言うと片付けの方法だよオーディオ関係のクラスには音を司る物をビデオ関係のクラスには絵を司る物を入れとけ混ぜるなよってこと
それらの自前ライブラリを設計できる上級者に向けた指針なわけよ読んで理解できない初心者には完全理解なんて不要
まずは全部入れたカタマリで好きなもの作れるようになれリサイクルしたくなって分別始めたらそれがオブジェクト指向の始まり >>86
コードが上手くかけてないのはすまん。オブジェクト指向のメリットを知らないくらいには経験がないんだ。あとカプセル化が可能であることを示すのが目的だったんだよ。関数型言語の優位性を示したかった訳ではない。
なんで、オブジェクト指向に挑戦してると思い込んでるのか？
別に挑戦してるわけではなくメリットを知らないから、このスレ立てて聞いてるんよ。
C#だとプロパティもポリモーフィズムができるのか知らなかった。現状それもオブジェクト指向するメリットですね。 >>87
質問なんですが、
○○するためのモジュールはこれ。
○○を操作するためのモジュールはこれ。
これだとダメなんでしょうか？
「まずは全部入れたカタマリで好きなもの作れるようになれリサイクルしたくなって分別始めたらそれがオブジェクト指向の始まり」分かりました。これ試しながらプログラム書いてみます。 >>80
>>1の最後の「モノとして扱いたい」という考え方したいということで間違ってないですか？
プログラマーが「モノとして扱いたい」 ではなくて
人間が「モノとして扱いたい」ということ
https://www2.nhk.or.jp/archives/tv60bin/detail/index.cgi?das_id=D0009050226_00000
> 科学者たちは「あらゆる自然現象は、最終的には一つの数式で説明できるはずだ」と信じてきたのだ。
↑このように「専門家」は、どうにか頑張って数式で表したいと考えるが
専門家じゃない人にとってはそうじゃないんだよ
プログラミングは最初から専門家が使う道具として登場したから
非オブジェクト指向の方が先に作られたが、
本来オブジェクト指向 と 非オブジェクト指向であれば
人としてわかりやすいのはオブジェクト指向の方で
専門家が頑張って表現しようとしてるのは逆に手続き型や関数型の方なんだよ >>90
「プログラマーがモノとして扱いたい」なら扱いたいときだけ扱えばいいが、「人間としてデータをモノとして扱いたい」のだから、常にモノとして扱いたいのだ。ということでしょうか？ >>91
「あらゆる自然現象は、最終的には一つの数式で説明できるはずだ」と考えてる科学者でも
話をする時は自然言語を使うのと同じこと >>87
playメソッドなどコマンドいっしょなのでオーディオファイル再生クラスから
ビデオ再生クラス作る例がオブジェクト指向として挙げられてたの見た記憶あるが… オーディオファイル再生クラスからビデオ再生クラス作るだと
継承して作るみたいに思えてしまうな
実際はオーディオファイル再生クラスから共通のメディア再生のインターフェースや共通機能を
独立させて、オーディオとビデオの共通クラスからの継承として作るのが正しいだろう
そして直接オーディオやビデオを再生するのではなく
コンテナクラスを作って、そこに複数のメディアを入れられるようにするだろうな 一番大きい恩恵は、モデル化によるメモリ空間を管理を丸投げできる 1が何をしたいのかさっぱり不明
どうにかしろ
大方、具体的な言語から離れてオブジェクト指向について
抽象的な戯言ばかり書いてる本や記事ばかり読んでるから
いくら調べても分からないんだろ
それぞれの言語の設計思想に則った
まともな書き方があるだけだ
なんでオブジェクト指向でないといけないのか？
なんて戯言はC#の入門書(オライリーの分厚いやつ)でも
ガッツリ読んでから言え
スタティックメソッドとして実装するのが適切な処理なら普通にそうしろ
普通にまともにやれ >>96
なんか君だけ空回ってるよ、肩の力抜きなよ オブジェクト指向で作りやすいと思うのはデータ構造かな
リストとかスタックとか、手続き型でもオブジェクト指向のように
記述することはできるので、手続き型でも良いといえば良いけど
データと処理をセットにしてオブジェクトとして抽象化するとデータ構造を
うまく表現できて、そのデータ構造を使ってプログラム書くのが僕は好き >>94
たしかObjective-Cのドキュメントで「継承じゃなくてコンポジット大事。」な例で扱われてたかな。
基礎クラスNSObjectベースにオーディオ再生クラス乗せて、外に再生関係のインターフェイス出して
中で動画ファイル来た場合の処理書いて…はい！マルチメディアクラスができました！これがオブジェクト指向です。
って感じの。 >>97
お前も不毛なこと書いてる癖に
手続き型言語…というより単なる旧式言語で
結局オブジェクト指向と同じことする方法を今更話して何になるんだよ
せめて関数型言語でのやり方と比較しろよ
1が目的不明だからみんな思い思いに目的不明な議論してるだけだろ
不毛だな Cで充分です
・データと振る舞いをまとめる？
まとめると何か良いことあるの？
構造体にまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
・カプセル化？
ファイルとstatic, externで実現出来るよね？
・ポリモーフィズム？
別にデータと振る舞いをまとめなくても実現出来るよね？
・モノのように扱いたい？
FILE * で出来てるやん？ Object Oriented Programming is an expensive disaster which must end
https://medium.com/@jacobfriedman/object-oriented-programming-is-an-expensive-disaster-which-must-end-2cbf3ea4f89d#:~:text=Object%20Oriented%20Programming%20is%20an%20expensive%20disaster%20which%20must%20end,-Jacob%20Bernard%20Friedman&text=And%20this%20is%20my%20experience,it%20is%20dismissed%20as%20irrelevant.
「オブジェクト指向プログラミングは費用のかかる災害であり、終わらせなければなりません」
長いけどよみごたえあるOOP批判 そら「別に電気製品をプラグアンドプレイにしなくても
毎回電源落として各自が自分で電線を半田付けすればできるよね！」って言われりゃそうだが
まあ、あたまおかしいだろおまえ。としか >>100
不毛だと思って書き込んでるあなたの心はハゲてるよ >>101
オブジェクトという概念によってデータと処理をひとまとめにして整理できますよ
構造体にまとまってるのはデータだけですよね、構造体のデータを操作する
関数があるでしょうけどデータと関数をセットにするととても便利ですね、つまりオブジェクト指向爆誕なわけです djbのqmailのソースコードとか
linusのgitのソースコードとか
C言語だけれどもオブジェクト指向だよね データと関数を整理してオブジェクトにまとめる、オブジェクト指向とはソースコードの整理術 モジュールもモジュールオブジェクトという一つのオブジェクトなんですよ モノとして扱いたいって言ってる人は
何をモノとして扱いたいの？
主語も目的語もなくちょっと意味が分かんない 関数ポインタよりも関数を無理なく渡せるってだけだぞ。
まあ最近はクロージャーのが使われる傾向にあるけど。 そーいや、c++は昔。
classはstructで定義した時代があったね。 ところで「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
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 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↑ ↑ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/4XhBmP3.jpg
https://i.imgur.com/PPFJZqI.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
チンポ≫自我
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 >>110
> 主語も目的語もなくちょっと意味が分かんない
「私は」オブジェクトを「モノ」として扱いたい
でいい？
主語とか目的語とか何を聞きたいのかわからん 928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>115
おしっこの時のチンポは随意筋、勃起の時のチンポは不随意筋、これが「オブジェクトの独立性」。 チンポが勃起したり射精したりする自然現象は、「数式」ではどうにもならんぞ？
92 デフォルトの名無しさん [sage] 2021/03/18(木) 01:43:22.24 ID:Ao1KNBsY
>>91
「あらゆる自然現象は、最終的には一つの数式で説明できるはずだ」と考えてる科学者でも
話をする時は自然言語を使うのと同じこと クリントン大統領の「不適切」というのは、チンポが独立して主体意思でシコシコしてしまったから。
チンポは独立した生き物であり、アメリカ大統領の権限をもってしても、制御することは不可能だ。
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ >>116
え、そうなの？
なぜオブジェクト指向を使うのか？の理由の一つとしてあげた
「モノとして扱いたい」というのはオブジェクトをモノとして扱いたいからなの？
トートロジーに感じるんだけど >>120
あわしろ氏は、オブジェクトとチンポは無関係と言ってるぞ。 いろんな起源があるけどsmalltalk系のベースの考え方は
プログラムモジュールを「独立したロボットのようなもの」として考える考え方で
これは大型コンピュータがネットワークで繋がって動いてる背景想定で
この場合、どの順番で結果が出るかは非同期的だし予想はできないから
モジュールに「これ頼むよ、はい」って命令と素材渡してあとは勝手にできてくるのを待つ
モジュールそのものに自分をコピーする命令があって
例えば「画面上にウィンドウを開く」モジュールがあったら
それを雛形に「おいおまえのこういう亜種を作れ」と命令すると
命令に従って新ウィンドウが開く。
いいじゃんそれ！とコンピュータサイエンス側では大絶賛だったけど
そこまでは要らないかな…ってエンジニアリング側の思想や技術的制約で
思想仕様をつまみ食いしていろんな言語コネ上げて現在に至る。 データ構造とデータフローがしっかり設計されていると
プロセスフローが適切に動き出す >>122
チンポが勃起したり射精したりするメカニズムは、いかなるオブジェクト指向言語をもってしても不可能。 いや？
チンコに別スレッドでイベントループ回して性的刺激イベントが来たら勃てば良いだけだが >>89
自分で作ったものがモジュール化してリサイクルする価値のあるものになってきたら
カタマリから切り出す事が出来る好きにやればいいさ
何本か作ればここをモジュール化したら便利だなとか見えてくる
オブジェクト指向が思考の中心に有っちゃだめなんだよ頭の片隅にある程度でいい >>85
目的と手段を履き違えてる
別にポリモーフィズムで実現しなくてもいい
その場合は変更に対して弱くなるというだけ
ポリモーフィズムでやりたいならジェネリクスでもTraitオブジェクトでもimpl Traitでも構わないがそれぞれメリットとデメリットがある
継承もそれらと同じでメリット・デメリットがある
まずはそれを理解すること
次に状況に応じて適切な選択ができる力を身につけること >>93
AVクラスにまとめて便利ならいいんじゃない 結局のところ、目的は関数の呼び出し側と呼ばれる側の依存関係を逆にしたいってところなんだよ。
それをバカがどこまでも無駄に適用範囲を広げてわかりにくくしたっていうところ。 >>132
それは関数の受け渡しができればいいだけなのでオブジェクト指向とは関係ないやろ staticおじさんという用語あるやん
あれってさ
議論に負けそうになった側の人間がよくやるやつに見えてきたな
論点じゃなくて相手の人格ごとケチつけようとレッテル張り始めるやつ
つまりstaticおじさんと言う用語に頼った時点でもう負けてんだね staticを理由も無く多用する奴って実際理解していないという意味だしねｗ 議論を勝ち負けで判断してる時点でstaticおじさんの素質あり 勝ち負けに拘らないなんて奴は
こんなクソスレに何しにしてるんだ？
バトルをしに来てんじゃねーのかよ オブジェクト指向が本当に「自然な」モデリング手法であったならこんな疑問は出てこず誰でも「自然に」理解して使えているはず。
結局オブジェクト指向が解決する問題とやらはオブジェクト指向を使うことによって産み出される問題なのだ。
とんだマッチポンプである。 人間は自然に言葉を話し、自然に考えるが
言語学や哲学があるのと一緒
人間は自然に物事を考えてるがそれを曖昧さが許されない
コンピュータ上で表現しようとすると体系化が必要になる >>1
オブジェクト指向とは元々アラン・ケイが提案したようにオブジェクトが他のオブジェクトにメッセージングをすることに本質があるわけよ
その実装のために各オブジェクトがどういうメッセージングを受け取るか発するかを定義する方法としてクラスベースやプロトタイプベースがあるわけ
そこを間違えて最初にクラスを出発点にしちゃったりクラスを唯一の必須事項だと勘違いしてしまうと本質を見失う
つまりオブジェクト間はメッセージングによってのみ相互作用が可能であり
オブジェクト内部がどうなっているかは見えないし知る必要もないのがオブジェクト指向
それを実現するために各プログラミング言語によって表現方法や実装方法が様々に異なるだけ
この最初に提案されたオブジェクト指向の考えをきちんと理解できれば
あなたが疑問は解けるはず
実装方法の一つに過ぎないクラスとかに囚われるダメな人にはならないように アラン・ケイはコロンブスと同じで、誰もやったことがない頃に
やったからすごいと言われてる。0から1を生み出すのは誰にでも出来ることではない
それに比べれば1から2、2から3にするのは簡単
だがゆっくりと技術は進化する。技術だけを見ればアラン・ケイの
オブジェクト指向よりも今のオブジェクト指向の方が実用的
一人の天才よりも多数の人の手によって改善された今のほうが優れてるんだ
いつまでも原始的な初期のオブジェクト指向にとらわれていては駄目だぞ それぞれのプログラムでデータを纏めたりしてそれが結果的にオブジェクトになったりするわけで
オブジェクト指向って聞いてこういうものだってって事ではないような
古いとか新しいとかオブジェクト指向が目的となってるのかな カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>141
チンポ【を】しこしこするのではなくて、チンポ【が】しこしこする！ >>145
アラン・ケイのオブジェクトはネットワーク越しに稼働するんだから
データが隠蔽されるのは当たり前すぎてprivateがなかっただけだと思う
現代のWeb Serviceが一番近い >>1
わかりやすい文章を書くときに主語を書けって言われるだろ？
あれだよ
オブジェクトはプログラムに主語を書くためのアイデア サルでもわかるみたいな解説サイト見ると一般人向けに曖昧に書いてあるから余計イミフなんだよな >>133
その渡した関数が引数で使うデータをどう渡すかって話だよ。
cで書いてみろ。型の部分で変なキャストしなきゃならなくなるから。 >>42 オブジェクトは対象語
>>148 オブジェクトは主語
どっちなの!? >>153
チンポ【が】しこしこする、チンポは主語であり独立した主体存在である。 >>152
はい？
>目的は関数の呼び出し側と呼ばれる側の依存関係を逆にしたいってところなんだよ。
これがオブジェクト指向の目的だと主張してるんだよね？
型のキャストの有無に何の関係があるのかわからんが
ある型を引数として受け取る関数を
別の関数の引数や戻り値として受け渡しできればキャスト不要だよね？
オブジェクト指向関係ある？
オブジェク指向じゃなければCって前提なのかな？ kindle unlimitedにある「オブジェクト指向でなぜつくるのか」を読めスッキリするから >>142
「オブジェクト指向を使うメリットって何？」って聞いてる相手に対して
>つまりオブジェクト間はメッセージングによってのみ相互作用が可能であり
>オブジェクト内部がどうなっているかは見えないし知る必要もないのがオブジェクト指向
こういう説明しかできないならオブジェクト指向を理解してないか
オブジェクト指向そのものにメリットないと言われても仕方がないなと思うぞ >>142
>つまりオブジェクト間はメッセージングによってのみ相互作用が可能であり
>オブジェクト内部がどうなっているかは見えないし知る必要もないのがオブジェクト指向
そして、トイレへ行き尿を出そうと思うと、脳が「出してよい」という信号を送ります。ここで副交感神経が
主にはたらき、尿道の筋肉がゆるみ、反対に膀胱の筋肉は締まって尿を押し出し、尿が排出されるのです。
健康な成人では、1回の排尿量は300ミリリットルほどで、約30秒で膀胱が空っぽになるのが普通です。
https://www.hainyou.com/sp/m/mechanism/ >>157
第2版で「関数型言語でなぜつくるのか」という章が追加されて
オブジェクト指向の「次」の開発技術として紹介されてる
次の開発技術が実用化されているのに「オブジェクト指向でなぜつくるのか」？ 教本丸暗記してるか初心者相手に言葉遊びしてるのかどのみち害悪だよな
リサイクルしたり拡張したり切った貼ったしやすくするためにある >つまりオブジェクト間はメッセージングによってのみ相互作用が可能であり
>オブジェクト内部がどうなっているかは見えないし知る必要もないのがオブジェクト指向
つまり関数間は関数呼び出しによってのみ相互作用が可能であり
関数内部がどうなっているかは見えないし知る必要もないのが関数型？
んなわけないしそんな説明されても意味ないよね
呼び出し側が知るべき要素と知る必要がない要素を分けられるのは
オブジェクト指向特有の機能じゃないんだから >>147
ネットワーク越しか否かを区別したり意識しなくてよいことが本質
そして全てはメッセージングで行なうのだから現在で言うところのメンバー変数はオブジェクト内部のものとなりゲッターやセッターとなるメッセージングを用意することで初めて外部からアクセス可能
>>145
だからprivate指定がない、というか、必要ないわけ >>155
そういう動的で型の弱い言語なら全く問題ないし、
オブジェクト指向を無理にやる必要もないって話だわ。
cの不便さとオブジェクト指向が流行ったことにはかなり関係がある。
まああんまり話を理解できてなさげだから言っても理解できるとは思えんけど。 >>162
それは概念のレイヤーが異なることをあなたが理解できていないだけ
例えばオブジェクト指向でのメッセージングとは関数呼び出しではないです
さらに言えばローカルとリモートを区別するRPCでもないです
メッセージングはオブジェクトから別のオブジェクトへの一方向の通信であり
もし何らか返事が必要となる場合は逆向きのメッセージングを行いますがその二つのメッセージングは非同期です
概念だけではわかりにくいから具体的な実現例をで言うと
例えば皆がよくわかる例としてJavaScriptでは
ネット通信やファイルアクセスは各オブジェクトの非同期関数になっていて
1つ目のメッセージングはその非同期関数の呼び出しとして
2つ目のメッセージングはその非同期関数のコールバックとしてこの言語では実現しているようですが
概念としてのオブジェクト指向のメッセージングとその各言語における様々な実現例にはもちろん乖離があります
そしてこのスレで混乱しているのは各言語における実現例だけを取り上げて話すからであって
元々の概念を理解してそれと共に話せばわらりやすいです
各言語の様々な記法なんていうのは単なる実現例側の話ですからそこに囚われていてはダメ Ruby on Rails 6 の本を出している人の、入門書が出た。
Erlang/OTP 上で動く、Ruby風の関数型言語
Elixir実践ガイド、黒田努、2021/2/5
Ubuntu 20.04, Docker CE 19.03, Elixir 1.11 >>165
非同期であることはそんなに大事なことではないのではないかな
smalltalkは九州大学病院のプロジェクトで大爆死してVBが
生き残ったわけなのでプログラミングにおいては同期の方が
わかりやすく使いやすかったことを歴史が証明してるんじゃなかろうかと 非同期のメッセージングは普通のプログラミングではあまり必要とされない
非同期の処理が必要なときはPromiseオブジェクトを使うように
非同期のメッセージングさえも併呑して現代のオブジェクト指向は成り立ってると思う
アラン・ケイのオブジェクトは、オブジェクトの一形態なんだよ >クリントンの「不適切な関係」
class チンポ｛
super.不適切な関係;
｝
クリントン
↑
チンポ そうして考えた場合にオブジェクトは何かと言われると
データと操作をガッチャンコしたプログラムということになろうかと オブジェクト指向の設計論でよく言われる貧血ドメインはダメだという
考え方は僕は嫌いで、データと操作を分けた方が良いこともある
JavaはRecordやパターンマッチなど関数型言語の機能を取り込んでいってる
オブジェクト指向+関数型がベストプラクティスだと思う >>170
>そうして考えた場合にオブジェクトは何かと言われると
チンポは繋がっているけれども独立した主体存在である！ >>167
ネットワークアクセスもファイルアクセスもユーザーアクセス(インターフェース)も全て本質的に同期ではなく非同期ですよ
それを無理やりに同期で書こうとすると
例えば低レイヤーではブロッキングのシステムコールとなってしまい時間のかかる相手に対してブロックされ待つ間は何も出来なくなってしまう
もちろんマルチスレッドという別の概念＆実現例を使って誤魔化すことはできますがそれでもそのスレッドがブロックされて何も出来なくなってリソースを無駄にするのは事実です
実際にこの問題はいわゆる有名な『C10K問題』として無数のスレッドがリソースを無駄に消費してサーバーが破綻する現実問題を引き起こしました
そこでも解決方法として取られたプログラミング方法は通信などで無駄にブロックされるスレッドを生じさせないこと
すなわちノンブロッキングなシステムコールにより非同期なプログラミングを行なうことでC10K問題も解決されて現在我々が使う多くの通信サーバーはこの非同期な実装方法です
このように相手がいるオブジェクト指向においてはオブジェクト間での非同期なメッセージングが基本
計算だけするならともかく多くのアプリ／ソフトでは人間UIやファイルI/Oやネット通信といった同期では非常に待たされる処理が重要ですから >>174
元々のオブジェクト指向のメッセージングは非同期という一番基本的なところ
もしこの話がオブジェクト指向と無関係と思える人はオブジェクト指向を理解していない >>175
現在の実装ではまるで関係ないのにそんなどうでもいい話してもな
逆に笑いものにされるわ（笑）
objectiveCでもやっとけよ（笑） >>173
それはIOの話ですよね
ドメインオブジェクトの関数を呼び出したりとか
メモリ上で行われる処理まで非同期にする必要はないので
オブジェクト指向にとって非同期はオブジェクトが持つことができる機能の一部だと思いました アラン・ケイは非同期なオブジェクトだけの世界を夢見てたんでしょうね
一方で同期的に処理するオブジェクトもあるので
アラン・ケイのオブジェクトはオブジェクト指向の一部でしかないと思うんですよね
同様に非同期なメッセージングもメッセージングの一部でしかなくて
同期的なメソッドコールもメッセージングとして良いと思います そのように考えるとJavaなどの言語がオブジェクト指向言語と
言われることとも整合します 非同期IOでC10K問題が解決したのはそうでしょうけど
プログラミング言語のライブラリには非同期IOも同期IOもありますから
非同期がオブジェクトの本質だとは思わないです
オブジェクトは非同期に処理するものもあるし同期に処理するものもあるという
ことだと思います
アラン・ケイがオブジェクト指向という言葉を作って
そこから抽象化されていって今に至るんじゃないかと思います >>177
それは逆です
別の話ですが例えで出すとインターネットの基本であるIPパケットは非同期で一方向ですが
それを利用したTCP上のHTTPなどは戻り値がある両方向で(時間はかかれど)同期に見えるよう作られてます
このように基本は非同期でその上に同期を実現はできます
逆は無理です
ここが一番重要なところです
オブジェクト指向のメッセージングも本質的には非同期で一方向です
その上に擬似的にRPCもしくは関数といった同期呼び出しは可能です
それらの概念があった上で実装としてはプログラミング言語によっては関数呼び出しとして実現してるといった状況です >>181
同期を実現してるというところが大事なところなんじゃないかと
必要もないのにそうしてるわけではないでしょう
同期な方がわかりやすくて使いやすいから同期にしてるわけで
同期が基本で非同期にしたいところは非同期の処理を書いてというのが
プログラミング言語の主流なわけですから、非同期にした方が効率が良いところもあるでしょうけど
そういうケースがあるからといって非同期がオブジェクト指向の本質ではないと思います 通信を同期に行うか非同期に行うかは通信の詳細なので
オブジェクトという高次の概念にそういった詳細を入れるのは抽象度が合わないと思うんですよね
オブジェクトに同期、非同期の縛りがないならばIPパケットが非同期で流れてることとも
矛盾は生じないわけだから、問題ないと思うんですよね >>164
>そういう動的で型の弱い言語なら全く問題ないし、
そういう動的で型の弱い言語？
“そういう”て言われても何のこと言ってるの？
ある型を引数として受け取る関数を別の関数の引数や戻り値として受け渡しするのに
型が動的か静的かも関係ないければ型付けが弱いか強いかも関係なやろ >>182
話の流れを勘違いしてるようだが
「オブジェクト指向の本質はメッセージング」という流れだよ
その話と「そのメッセージングの基本は一方向非同期であり両方向同期はその上に作られる」という話をごっちゃにしてる
もちろんどちらも正しい
反論があるならば上記のどちらかの話なついて書いてほしい
一方で「オブジェクト指向の本質は非同期」という主張は誰もしていない >>184
とりあえずcでpthreadをお前の思うように実装してみれば？まず無理だから。 >>174
オブジェクト指向は生まれた時から俺の股間に付いているが？ >>165
>それは概念のレイヤーが異なることをあなたが理解できていないだけ
>例えばオブジェクト指向でのメッセージングとは関数呼び出しではないです
レイヤーが異なるかどうかは捉え方によるんだよ
オブジェクト指向の観点だけから関数呼び出しとは違うと言っても意味がないよ
「オブジェクト指向を使うメリットは何？」 トイレでオシッコを出したり止めたりだな！
>>185
>「オブジェクト指向の本質はメッセージング」という流れだよ
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>185
実装の話をしてたんですね
オブジェクト指向の概念の話をしてると思ってました メッセージングを実装するときの話ですね、非同期の処理があれば同期の処理は実装できるぜってことですね
つまりオブジェクト指向と非同期は関係ないという僕の考えと同じですね 831 デフォルトの名無しさん sage 2018/11/11(日) 10:00:59.18 ID:Tyd11AGx
たとえば、CycはFredという名前の男がドナルドダックのモノマネをするという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には羽がないことは知っているが、
アヒルのように歩き、アヒルのように鳴くものはアヒルに違いないと考えた。
したがって、CycはFredがドナルドダックのモノマネしている間、
Fredはそれでも人間なのかと尋ねた。
925 デフォルトの名無しさん 2018/11/21(水) 18:36:07.42 ID:8Yc2p7H1
>>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, アーロンカービル >>191
元々のオブジェクト指向のメッセージングは一方向だから相手から返事があるとしてもそれは非同期であっている
基本が非同期だからこそ同期も実現できる
基本が同期だったら非同期は実現できない 785 名無し三等兵 sage 2019/12/03(火) 08:03:27.78 ID:sujZBpWD
>>762
＞「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
チンポにチンポ自身を扱く機能が備わっていないので自動詞は不適切だから（34文字）
胸（心臓）には鼓動する機能があるため自動詞の適用対象だが
チンポには勃起する機能はあっても自身を扱く機能はないので「チンポ『が』勃起する」は成立しても「チンポ『が』シコシコする」は成立しない
夢精した状況を「チンポ『が』シコシコした」と称したければ「チンポがエロい夢を見させ夢精した」＝「脳ではなくチンポが思考を司りエロい夢を見させて夢精させた」という状況で可となる
脳でなくチンポで物を考える生物についてなら「チンポ『が』シコシコする」は成り立つ
如何にもだつお的じゃないか >>193
元々のというのはアラン・ケイのオブジェクト指向ではってことですね
アラン・ケイのオブジェクトが非同期にやりとりするのはわかりましたが
アラン・ケイのオブジェクト指向は現代のオブジェクト指向の概念からすると
特殊例の一つだと思っています
オブジェクト指向 -> (詳細化) -> アラン・ケイのオブジェクト指向 -> (詳細化) -> メッセージングは非同期
という話だと思っていて、あなたがいう本質とは実装のことを指してるんだと思ってます
僕は現代のプログラミング言語でも通用するより抽象的なオブジェクト指向という概念に興味があります オブジェクト指向が一時的な流行語ではなく、ソフトウェア開発の世界に自然に浸透していったのは
それが人間の自然本来の考え方であり、根源的なものであり、普遍性がある考え方だからなのです。
河合 昭男 『オブジェクト指向と哲学』
https://www.sociomedia.co.jp/8740
チンポは自分とは繋がっているけれども独立している、それがオブジェクト指向なのである！ 657 仕様書無しさん [sage] 2020/08/12(水) 11:11:53.67 ID:
>>655
ちんぽをシコシコするというのは主体が別に存在する（おそらく右手であろう）
しかし、ちんぼがシコシコするというのはちんぽさんが主体となって別の輪状、もしくは固定された箇所に向かって
往復運動をすることを言う
そしてそれはシコシコと形容される範囲内におけるような物体や部位である必要がある
つまり、日本語でいうところのチンポがシコシコするというのは文法上は正しい
しかしである
ちんぽは主語になってよいものかという問題が残る
ちんぽは思考できるのか、主体的な存在であるのかという疑問んである
我々はちんぽを自由自在に動かす事はできない
「勃つんだ！ジョー！！」などと呼びかけた人もいるであろう
ちんぽは人の付属物であると同時に1本の主体的な存在でもある
思考や意識といったものはないかもしれないし他動的な刺激により、また体調により変化を兆す。
つまり、チンポがシコシコするというのはチンポが主体的な存在かどうかが問われているのであり
勃起に至る過程からそれはまさに肯定されるべきなのである >>195
君はウェブブラウザを使ってる？
ブラウザ上で動いており現代に最も使われているプログラミング言語の一つであるJavaScriptはオブジェクト指向で非同期プログラミング
君はJavaScriptでプログラミングすらしたことがないですか？ 美しい女優のパンツにウン筋がついてたから、ウンコは美味みたいな論法だな。 >>198
普段はJavaScriptは書かないですけどPromiseオブジェクトを使って非同期の処理ができることは知ってます
論点がよくわかりませんけど、何の話をしようとしてますか？ var a = 1;
var b = a + 2;
のようなプログラムを書いたら同期的に処理されるので基本は同期ですよね
DOMのイベントなどは非同期に処理されますけど
処理が同期か非同期かはオブジェクト指向の本質ではないと僕は思っていて
僕がいう本質はそれがなければある物事が成り立たないことで
オブジェクト指向という概念に処理が同期か非同期かは必要ないですよね
オブジェクトという概念がまずあって
それの実装として非同期的な処理を行えるということだと思うんですよ
オブジェクトは、データと操作をガッチャンコしたもので
データと操作をガッチャンコすると何が嬉しいのっていうのがオブジェクト指向を
理解する上で最も重要なことだと思います >>1の感覚はバランスが取れてて
オブジェクトは使えるところで使えば良くて何でもかんでもオブジェクトにする必要がないのは
そのとおりだと思う
オブジェクト指向の本によっては何でもかんでもオブジェクトにするのが成功の秘訣ですと
書いてあるんだよね、僕もいろいろ本は読んだけどこればかりはウソだと思ったし
今でもその恨みは忘れていない
こういう住所が与えられたときに
京都府京都市山科区御陵天徳町
愛媛県伊予市市場
秋田県由利本荘市岩城勝手
『都道府県』と『市郡区』と『町村地区』に分けて処理しなければいけないことがあったんだけど
Prefectureオブジェクト、Cityオブジェクト、Townオブジェクトを作って大失敗した
全部文字列型で処理する方が速く正確に処理できた >>200
Promiseは全く関係ないです
Promiseはデザインパターンの一つなのでどの言語でも自分でプログラミングできます
ただし様々な仕様になりうるので最近は各言語が公式サポートするようになりブラウザ上のJavaScriptでも6年前にようやくPromiseオブジェクトが導入され始めました
したがって更新のないIEブラウザにはPromiseオブジェクトはありません
そしてJavaScriptは登場した25年前からオブジェクト指向かつ非同期プログラミングです >>202
おまえが>>1じゃなかったんかい！
Prefectureオブジェクト、Cityオブジェクト、Townオブジェクトみたいのを作ったほうがいいかどうかは状況次第
結局のところデータと振る舞いを1つの単位の中にまとめたほうがいいかどうか >>203
関係ない話をふっておいて、レスにはまともに答えず、さらに関係ない話を掘り下げる
めちゃくちゃタチが悪い >>204
僕は>>1じゃないですね、見返してみるとたしかに似てますけど
成りすますつもりもなく、たまたま似てしまっただけです
シンパシーは感じます
Prefectureオブジェクト、Cityオブジェクト、Townオブジェクトを作った方が良い状況は一生ないです、マジです >>205
こういう流れ
「オブジェクト指向を産み出したアラン・ケイによるオブジェクト指向は非同期なメッセージング」
↓
「現代のメジャーなオブジェクト指向の言語では全て同期プログラミングでしょ？」
↓
「現代のメジャーなオブジェクト指向の言語の一つであるJavaScriptは非同期プログラミング」 「JavaScriptは非同期プログラミング」
クリスマスは七面鳥をこんがりみたいな、なかなか味のある表現だなって思いました >オブジェクト内部がどうなっているかは見えないし知る必要もないのがオブジェクト指向
と主張してるにも関わらず
オブジェクト指向を使うメリットを理解するためには
アラン・ケイの主張や実装手段の非同期メッセージングなど
内部がどうなっているかを知る必要があるみたいな話をされても困るよね
オブジェクト指向の価値を理解して実践できてるなら
相手が知る必要がない実装の詳細とインターフェースを分けて話せばいいのに >>203
非同期プログラミングは、非同期のプログラムを書くことだと思いますけど
25年前のJavaScriptの非同期のプログラムってDOMのイベントですか？
言語の機能ではなくてDOMの機能のような気がしますけどそもそもあれって非同期なんでしたっけ？ >>209
非同期メッセージングは実装手段ではないよ
オブジェクト指向の本質的な概念であり様々な実装手段の上位にある
だから実装は各言語の特色に応じて実装しても構わないので各プログラミングスタイルは異なってくる
例えばJavaScriptではクロージャーによる継続渡しの非同期コールバックで帰りのメッセージングを受けているね ここにいる人達に同じ要望書を渡しても、全員がバラバラなクラス書きそうだな WindowオブジェクトのsetTimeoutとかかな？
非同期に処理するオブジェクトもあるよってだけな気がします
オブジェクトという概念があってWindowオブジェクトはその実装の一つでしかないので
非同期メッセージングがオブジェクト指向の本質とは言えないと思います Windowsで動くJScriptはWindowオブジェクト使えないですから
非同期がJavaScriptに必須というわけでもないですよね
JavaScriptはプロトタイプベースのオブジェクト指向言語でしかなくて
非同期の処理も書けるよってだけな気がします
アラン・ケイのオブジェクト指向と繋げるのは筋悪だと思います >>213
JavaScriptはブラウザ上で全て非同期プログラミングで動いている
例えばマウスをクリックしたりスマホでタップしたりなどあらゆるヒューマンインターフェースは非同期イベント
AJAXのAがAsynchronousであるように通信も非同期で行われる Javaのオブジェクト指向は非同期メッセージングがなくても成り立ちますが
アラン・ケイのオブジェクト指向は非同期メッセージングがなければ成り立ちません
アラン・ケイのオブジェクト指向はより多くの条件が付随するという意味で
オブジェクト指向の概念を特化したものと捉えるべきだと思います
現代のプログラミング言語は非同期に処理を行うプログラムを書くこともできますが
それは言語による実装の機能の一部でしかないです >>215
プログラミングはプログラムを書くことなので、非同期で動いているで良いと思います
たとえばボタン押したときのリスナーの処理って非同期ではないんじゃないですか？
処理を非同期に実装しないとたぶん同期的に処理されると思います
AJAXはそれはそうでしょうね
XMLHttpRequestオブジェクトが非同期の処理を行えるよってだけですね
オブジェクト指向という概念があって、同期の処理も非同期の処理も書けますよってことですね
だから処理を同期で行うか非同期で行うかはオブジェクト指向とは関わりがないと思うんですよ ブラウザ上で動くJavaScriptでなぜ非同期の処理が多いかというと
GUIがあるからだと思います、GUIの描画を止めてしまうとユーザビリティが悪いので
時間がかかる処理は非同期に行ってGUIの描画が止まらないようにしましょうということだと思うんですよ
オブジェクト指向という高次の概念から導かれることではなくて
GUIを見るユーザにとって使いやすいという現実的な理由によるものです >>211
>オブジェクト指向の本質的な概念であり様々な実装手段の上位にある
「オブジェクト指向を使うメリット」を説明した上で
その内容を理解するために非同期メッセージングの理解が必要というならまだ理解できるが
どちらも説明してないのに「非同期メッセージングはオブジェクト指向の本質的な概念だから～」と言っても意味ないよ
インターフェースと実装の詳細を分けろって意味が分からないのかな？ 全部非同期でいいんだよただ
メッセージボックスとかは同期じゃないと困る
ファイルを削除して上書きとかが非同期じゃ問題になる
言語や志向と関係ない 僕は普段Javaでシングルスレッド+同期の処理ばかり書いてますけど
オブジェクト指向のありがたみは感じます
ハッシュテーブルやリストなどのオブジェクトは使いまくりです >>220
例えばJavaScriptはそのファイルを削除して上書きも非同期プログラミングで行なわれるが問題が起きたことはない
そもそもOSレベルからしてファイルアクセスなどのI/Oのノンブロッキングシステムコールは非同期で行なうことを前提として存在している
もちろん同期にブロッキングでシステムコールを呼ぶことも可能だが無駄にI/O待ちさせられるだけになる あわしろ氏によると、これからはダブルスレッドの時代らしい。 >>218
その通りでGUIやI/Oアクセスやネットワーク通信などの単なる計算以外のプログラミングでは非同期で書くほうが有利
そして非同期プログラミング自体も最近はメジャーな言語が次々とasync/awaitをサポートするようになったことで構文的にも同期と同様の記述が出来るようになり唯一の欠点も無くなった
これでオブジェクト指向におけるメッセージング(メソッド呼び出し)も同期だけでなく本来の非同期も使いやすくなるだろう
>>221
そのシングルスレッド＋同期のみだと相手のオブジェクトでの処理がUI、I/O、通信などで時間待ちとなる場合に自分もブロックされて何も出来なくなってしまう
つまりそうなっても構わないようなソフトウェアしか書いていないということになる Ruby, Haskell, アラン・ケイ
ム板のごく一部のやつのせいで不必要に評判を落としてる三大被害者 >>226
非同期プログラミングしたことない出来ない下層プログラマーなんて山ほどいるからしょうがない
たとえ非効率であろうが彼らは同期プログラミングで組むしかないのだ
通信待ちするオブジェクトに対しても I/O待ちするオブジェクトに対しても
GUI待ちするオブジェクトに対しても
彼らは同期呼び出しをして律儀に無駄待ちするか無駄にスレッドを増やして非効率に煩雑化させる >>230
君は非同期プログラミングしたことあるの？ JavaScriptは非同期プログラミングで、JavaScriptを書いたことがあるから
非同期プログラミングしたことある、とはいわないでしょうね、まさかそんなことはないでしょうね
絶対そんなことないでしょうね オブジェクト指向でなくても、例えばcでもasync/await相当はルーチンワークで書けるけどセンスが必要
オブジェクト指向におけるasync/awaitというメタファーを通して万人がまともな非同期処理を実装できるようになった意味合いは大きい もともとが「ネットワークで繋がった(大型)コンピュータ上で
それぞれの処理をするプログラムが個別に動いてる」という前提で始まってるから
相手の特定アドレスをリアルタイムで弄る的なことは
相手のステータスからしてわからないので“いずれできなくなる”
ならば相互コマンド制御にしてある程度自律的にコマンドにモジュールが
対応するシステムになっていくだろう。こうすることにより～(以下利点
って話を、スタティックじじいはいつまで経っても
1CPUで自分でリニアな1アドレス見れるマイコンdeプログラムレベルしか想像できないので
「そんなものは要らん！」って延々とほざいてるだけだよ。
ぶっちゃけ大前提がインターネットのサーバクライアントレベルで
別に家電の組み込み基盤みたいなのはアセンブラでもなんでも速くて使い慣れたのやっとけ
『でも外のオブジェクト指向界からのコマンドメッセージには自律的に対応するように作れ』って話。 関数型ネイティブの世代から見たら同じように見られてることにそろそろ気づけたらいいね スタティックじじいとかいうワードに頼ってる時点で読む気失せるわ 関係ないネタで一人で勝手にヒートアップしてさぁ付ける薬がねえよなまったく 小泉進次郎wのレスで非同期かどうかはオブジェクト指向の本質には全く関係ないことがハッキリしただろ
関係ない話ですぐ自分語りを始めるのは老害おっさんの悪い癖やぞ ああいうのをオブジェクト指向と呼んでも混乱するだけだし
今更そう呼ぶ必要もねえよ
今の言葉の用法と違うし
そんなに大した意味ねえし
馬鹿かな？ インターフェース使えばそこの非同期バカでも楽に作れたとかそういうネタでドヤってんじゃねーの
オブジェクト指向は無関係とまでは言い切れんな この手のスレでオブジェクト指向を語りたがるやつは
オブジェクト指向と原始的な手続き指向しか知らないから
その2つの比較以上のことを知りたいなら質問する場所を変えることやな
おっさん談義に花を咲かせたいだけならいいんだろうけど >>234
前半は何の話だろ、アラン・ケイのオブジェクト指向の話？
アドレスを弄るってところでOSのプロセスの話かとも思ったけど
やっぱりわからない
真ん中はただの妄想だけど、マイコンという発想は興味深い
後半は組み込みのプログラムはアセンブラで書いたが良いってことね
そりゃそうだろうけど、オブジェクト指向界という言葉がわからなかった
全体通して組み込みの開発をやってる人なのかなって思った オブジェクトによって並行処理が書きやすくなったのは事実としてあるよね ブロックによる構造化だけではできないことがあって
データや処理を複数の構造化されたブロック内で共有して一元的に管理する方法として
いまのところオブジェクトがベストなんじゃないかと思う
たとえばこういうふうに、複数のメソッドの中でカウントアップしたいときとか
Counter counter = new Counter();
void methodA()
{
……
counter.countup();
}
void methodB()
{
……
counter.countup();
}
プログラムによる構造を越えて処理しなければいけないときにオブジェクトは有用 そう考えると構造化プログラムの発展としてオブジェクト指向ができたのはうなずける
継承やポリモーフィズムがオブジェクト指向に必要なのかはよくわからない 寝言ばかりのスレだな
取り敢えず馬鹿みたいな本や記事を書き散らして
初心者を混乱させるような仕事だけはするなよな >>239
>ああいうのをオブジェクト指向と呼んでも混乱するだけだし
多重継承は曖昧だというが、自然言語処理はその曖昧さが大切になる。チンポは随意筋であり不随意筋である。
最終的に，クラス階層は最上位クラスを含めた
最大8 階層から構成され，「伝統的な日本の絵画」
に属する用語に対応する 55 クラスと解説文中か
ら抽出した139 クラスが配置された。ただし，そ
のうち 32 クラスが複数の上位クラスをもつとい
う多重継承が示された。例えば，「ngyc:絵巻物」
は「ngyc:伝統的な日本の絵画」と，「ngyc:表具の
形式」の下位クラスである「ngyc:巻子」の 2 つの
クラスを継承する（図 2）。こうした多重継承は，
本質属性をもつ基本概念と機能を表すロール概念
を分離することで，基本概念による属性継承に限
った階層関係に変更するという考え方もあり 10)，
「ngyc:伝統的な日本の絵画」がロール概念で，
「ngyc:表具の形式」が基本概念と捉えることもで
きる。しかし，本研究ではテキストからの情報抽
出に即して配置し，多重継承を許容した階層を導
き出した。
http://www.mslis.jp/am2019yoko/05_kobayashi.pdf
随意筋 不随意筋
↖ ↗
チンポ 状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質 哺乳類クラスから犬を派生させると、あわしろ氏が言ってたな。 カモノハシはどうするの？
哺乳類クラスを修正したら、
そのままでは犬も卵を産むことに。
生成時に決めるように修正しても、
結局既存の犬生成コード部分を書き換える必要が発生ｗ >>250
デザインパターンの一つにステートパターンがあるから
ケースバイケースだと思う
モノはオブジェクトの日本語訳だと思うよ >>253
胎生は哺乳類の定義に含まれないから哺乳類クラスを修正するわけがないでしょう
字の通りおっぱいで子どもを育てるから哺乳類 生物に例える事自体プログラムから離れるんだよなゲームキャラクラスから色々派生させるなら実感湧くけどな
クソみたいな喩え嫌いだわ そもそも共通項でないものを親クラスに書くなっていう、そんな基礎から説明しなきゃいけないやつがいることに頭が痛い オブジェクト指向がどうというより、その辺はDDDの話なわけでそっちでやれや >>257
哺乳類とカモノハシはたとえだろ。
設計時犬、猫、馬のみがあって、
胎生は共通だからクラスに書く、
その後カモノハシ追加という流れ。
こんなことすら分からんとはｗ >>256
現実のモノ（オブジェクト）に例える事自体プログラムから離れるんだよなオブジェクト指向の喩え嫌いだわ >>261
チンポ【を】しこしこするのではなくて、チンポ【が】しこしこする。これがオブジェクト指向。 (不適切な関係,クリントン,ルインスキー) -> ｛return フェラチオ｝
クリントン元大統領が真実を告白「モニカと口淫行為を…」
https://www.nikkan-gendai.com/articles/view/geinox/277220 オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられるが、
>>99
>たしかObjective-Cのドキュメントで「継承じゃなくてコンポジット大事。」な例で扱われてたかな。
チンポはそれ自体が独立した主体生物とは考えられないのか？？？
自我ーーーーーーーーーーーーー
┃ ┃
┃ ┃
┃ ┃
┃ ┃
┃ ┃
ーーーーーーーーーーーーーーー
┃ﾁﾝﾎﾟ┃
￣￣￣￣
ﾁﾝﾎﾟは自我の拡張クラスね！ 哺乳類クラスを継承した犬クラスと猫クラスがあるんですよ。
これが理解できなくてオブジェクト指向に躓く人が多いんですね。 241 伝説の名無しさん sage 2020/10/13(火) 15:00:15.08
「胸がドキドキする」というのはいわば生理現象であり、抑えることはほぼ不可能だ。
月末のクレジットカードの支払額に、想像以上に可愛かったデリヘル嬢のおマンコにと胸を
突かれるのは悪いことではない。
翻って「チンポがシコシコする」というのは能動的な衝動であり、極めて不埒な責任転嫁である。
シコシコはチンポが勝手にやったことであり、決してチンポの持ち主の意向ではないという、どこぞの
政治家の「秘書が勝手にやったこと」のような言い逃れがしばしば聞かれ、あまつさえそれがまかり
通ってきたことは周知の事実である。
チンポからシコシコを奪取し、各人の掌に戻る日は果たしてやってくるのだろうか……。 いつものように理解できないから荒らし始めたなー
この板の「オブジェクト指向」ってついたクソスレすべてに共通する流れだ。
10年以上それやってるだろうにまだオブジェクト指向わかんないってのがすげぇよ。 >>260
お前、本当に頭悪いな
カモノハシだけ例外なら、カモノハシの胎生メソッドをオーバーライドすれば済む話だろ
なんで共通項でもないものを親クラスにぶち込んだり、問題なく動いている兄弟クラスにテコ入れするんだよ 中学の時、女子のブルマ姿に欲情しながら、子供が欲しい訳でも無いのに、
何でチンポが勝手にしこしこするのかと、これは何と非合理なのかと思ってた。 自然言語では、どんどん新しい単語が生まれるし、単語の定義は変わることがある。
それはもちろん流行り言葉もそうだが、より基幹的な単語についてもそれは当てはまる。
例えばWikipediaを見ると、ペニスはオスの持つ生殖器とされている。
しかし近年、ペニスを持つメスが発見された。
https://qiita.com/dorarep/items/803b874858a961ce2a5a 実際は哺乳類ってなんだと考えるのがオブジェクト指向
いい哺乳類を定義するプログラミングが肝心 ここでは、筋肉の構造力学から得られる情報を基に、全身のモデルとその制御システムを作製し、
実際の人体の動きを再現することを目的とします。人体の動きを再現するために、深層強化学習を用いて
人体の特徴やその制御方法について再現可能かつ確かなシミュレーションを入念に行いました。
このモデルを用いて、弱まった筋肉や、補装具をつけた部位など、身体的に負担のある人体の動きの予測も
可能です。加えて、モデルの活用例として、外科手術の3 Dモデリングによるシュミレーションも行っています。
https://ai-scholar.tech/articles/treatise/deep-3d-ai-118
>>261
>現実のモノ（オブジェクト）に例える事自体プログラムから離れるんだよな
人工知能とはオブジェクト指向への果て無き追求のことだ！ クリスマスって日本の文化で例えると正月みたいなもんだ。っていう説明を聞いて、
正月に例えるとクリスマスから離れるだよな
とかいう感想を言うやつってアホだと思うわ
例えというのは、相手が知ってるであろう”別のモノ"を
使って説明するから、離れるのは当たり前だろ
知らない人に説明するという目的を果たそうとしてる所に現れて
その説明は正確じゃないから完璧な説明を「知らない人」に言って
相手が理解できいないのを見て自己満足したいだけだろ >>274
チンポは古今東西共通で、チンポはチンポで何も変わらないぞ？ どうせチンポはお前自身のことであるっていったら
俺はチンポじゃねーぞっていうんだろ？ コンピューターで例を出すと
入力装置: キーボード、マイク、カメラ
出力装置: ディスプレイ、スピーカー
でもタッチパネルはどうする? >>277
入力 -> 何らかのアクション -> 出力
と繋がるのであって、入力と出力が同一である必要はない
入力装置のタッチパネルと出力装置のタッチパネルで済む
その為の名前空間 unityでは全てをゲームオブジェクトとして扱います。 泥ではタッチパネルは触ると現れる複数のマウスみたいに取得できる既存のHIDとは別物よね >>232
無駄待ちしない非同期プログラミングは特定の言語に依存しない一般的なプログラミング手法。
どの言語でもそれが直接見えるか否かに関わらず一番下では当然コールバックになっている。
例えばそれを遅延してコールバック指定できるタイプのfutureやpromiseを返り値としてもらうのはデザインパターンの問題。
こうすることでターゲットのオブジェクトに直接コールバックを渡すのではなくfutureやpromiseを介することで自分側で制御できる。
更にそれを表記上はコールバックをしているように見せないためにco-routineやgeneratorを使って見た目だけ同期っぽく書くことも可能。
つまり表記上は無駄待ちでブロックされる同期呼び出しとほぼ同じ形でコーディングが出来る。
そしてそれら上記を全て意識せずに簡潔に書けるようにしたものがいわゆるasync/awaitとなる。
この正しいawaitを用いれば見た目は同期呼び出しなコードなのに実態は非同期呼び出しかつ無駄待ちせずそのスレッド自体がその間も他のコードを実行可能となる。
これにより例えばシングルスレッドのみ使用であっても多数の通信やファイルアクセスなどを一切無駄待ちせずに非同期に並行して効率よく処理することが可能となる。
具体的に複数の最終的にコールバックされるペンディング状態を管理するのは多くの場合にメインのイベントループオブジェクトである。
これは言語によっては言語に内在するケースもあれば標準モジュール/ライブラリとして提供される場合もあれば自作する場合もある。
抽象化された上位のものを用いていてもその内部では結局select()やpoll()などのシステムコールが中核に位置することになる。
このオブジェクトで多数のファイルディスクリプタ(通信も結局ソケットなのでこれになる)管理とタイマー管理などを集中管理する。
全てのコールバックはここから直接もしくはfutureやpromiseなどを介して行われることになる。
これらの機構が直接見えるかどうかは各言語およびどこまで抽象化されたライブラリを用いるのかに依存する。
例えば貴方が言及しているJavaScriptではブラウザとNode.jsどちらも実行環境に内在されているため利用者は自分で準備や構築をする必要はない。 >>281
僕は彼の人が非同期のプログラムを書いたことがあるのか知りたかったのですが、あなたは仕組みを教えてくれてるんですね、ありがとうございます、物知りですね >>281
IOが関わらない非同期はJavaScriptではどのように実現されてるのですか？ ググって見たんですけどselectやpollは効率が悪いからepollを使うのがいいらしいです、ファイルIOはどれもまともに動かないのでスレッドで処理するのが良いらしいですけど、JavaScriptは実際どうやってるんですか？ node.jsで良いです、教えて下さい 僕は教えてもらうことで成長し、君は僕に教えることで認識を深めるwinwinの関係ですね >>286
一緒に学んで心も技術も一回り大きな自分になりましょう、挫けそうになったら助け合ってともに頑張りましょう、仲間がいるから僕たちはもっと成長できる！！ c10kが問題になったのは20年前
asyncで何でも非同期にすれば効率良いと思われたのが10年前
基本同期で処理して局所的に非同期にしたが効率良いことが実証されたのが今
だと僕は思ってます ソースコードの表現論の問題だ
逐次実行の数学的な表現方法が今のテキストベースのコードだ
時間を無視して一瞬で終わることを念頭に作られている
今は時間や状態の関与が著しい
だから50～60年代に確立された学術的・数学的なコード表現と乖離している 50～60年代に確立されたと思われていた技術は
現代の需要の前にはやくたたずという話 >>292
テキストベースでないコードがあるんですかね
CPUは進化してるので時間を気にしなくてよくなってると思うんですがね >>285
>>287
そういうのは教える側が言うなら分かるが、一方的に教わるだけの側が言っても身勝手で虫がいいと思われるだけだぞ Unixのパクリのlinuxが未だにサーバー側では使われているのに古い技術は役立たずとか
時間を無視してうんぬんは言っている事が無茶苦茶ｗ
今の方が早くなっているからちょっとした処理の時間なんか無視出来るのになｗ >>295
身勝手に仕組みを説明される身にもなってくださいよ
それこそ都合の良いときだけ身勝手な説明して
聞き手である僕に何の配慮もないじゃないですか
だから僕は教えて欲しいことを提示したんです
知ってるなら教えてください、知らないなら調べて教えてください
それが義務です >>276
>チンポはお前自身のことであるっていったら
寝ている間にも勃起して射精するんだが？ >>276
>チンポはお前自身のことであるっていったら
自分の体内にあっても、独立して自らの意思で勃起する不思議な生き物なんだが？ 動物に例える 初心者を煙に巻くクソ講釈
チンコ 論外
通信処理実装の良し悪し 専用スレでやれ
んなとこですかね 犬 is a 哺乳類。
犬 has a チンポ。
と、あわしろ氏に教わったけどな。 クラスの中にメソッドとプロパティを用意してなんとなく動きそうなコードを入れたらオブジェクト指向の完成 オブジェクト指向が理解できなくて挫折した恨みで
これまたよくわかってない関数型とか持ち上げて
掲示板で“こっちが最新だから俺が偉い”なんて朝鮮人みたいなことやるのは勝手だが
オブジェクト指向はリアルタイム同期とれない処理の分離のための手法だから
プロセス同士の通信はオブジェクト指向で中身関数型になるだけで
おまえは結局永久にどこにも属さない頭わるいクズのままやぞ。 >>306
ガラケーのメリット・デメリットを理解した上で状況に応じて技術を選択できるようになることが一番重要
特にオブジェクト指向に対する理解は古いから必要がないと言って捨てられるような段階にはまだ至ってない
オブジェクト指向は不要と考えるのはオブジェクト指向が全てと考えるのと同程度に危険 正直、不要かなと思ってる。
アーキテクチャやテストの文脈でオブジェクト指向を語るのは意味あるが
設計に持ち込んだ話はロクでもない比喩表現で現場を混乱させるだけで何のメリットもなかったというところ。
バカがこれはオブジェクト指向だ、いや違うみたいなクソ議論で時間が際限なく減っていくという
生産性のかけらもない状況になる。 オブジェクト指向もDDDもTDDも同じ
二元思考や教条主義的思考をしてるうちは技術者としては未熟 TDDに対してはそこまで嫌悪感薄いかな。
確かにやりすぎだとは思うが、あれくらいやらないと全くテスト書かなかったってのが
この業界の状態だったし。 >>307
>オブジェクト指向はリアルタイム同期とれない処理の分離のための手法だから
だからこれがお前だけの勝手な定義だっていい加減気づけよ
釣りなのか？
赤の他人相手にマイ言語喋ってんじゃねーよ
一般的な意味をググってこいカス >>314
>だからこれがお前だけの勝手な定義だっていい加減気づけよ
ならば「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ 24 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (JP 0H82-LX7o [153.145.207.163]) 2019/11/23(土) 16:54:55.03 ID:l9637O/lH
https://i.imgur.com/1VuRIrP.jpg ＿w 、... ｮ ┌┐ ｨ ′
￣＋ ﾍe、 j｢. .￢气￢''..~''~ ,．ﾙw、.ｰu、す
^^"~~l|~~^''' ｫ′ .,. l| ┐ .√ j| _~+,.、.
. .,/. ょ＿／ ､j｢ ｛ `￢.. 〃 .、l| ､
.. ~＾. ~ ` ~＾
. ；. ｮ ＿_
. j| ~ラ￢￢+ |. ￣. ￣..
. ｵ ｜.. ｫ ,､
k、 ,j〃. Ｌ＿. _ｪ ~'――'~. ^^^^^^￣´
￣′ ￣￣ Smalltalkなんてカーネルまでリアルタイム環境でしょ 胸がドキドキはI have Heart.の関係
my->heart->dokidoki();で表現できる
しかしチンポがシコシコは私のチンポ、私の手が並列な存在として登場している
my->hand->shikoshiko(my->chimpo()) あわしろ氏によると、チンポの多態性って事らしいぞ。 あわしろ氏によると、発生学的には男性のペニスと女性のクリトリスは相同器官ってことらしい。 >>320
オシッコの時のチンポと射精の時のチンポは、全く別なんだが？ オシッコは公開型(自我で制御可能)、射精は非公開型(自我で制御不能)、非カプセル型とカプセル型の使い分け。 ttps://banners-cdn77.trafficfactory.biz/banners/97/86/44/9c6bd11708de8f89770062384253e134.gif Laravel使ってるんだけどDIとか言うのがわからん
interfaceを使って疎結合って何？
今のコードの書き方は依存しすぎててダメだと言うことは気づいたけど
それを治すための理屈が頭に入ってこない
interfaceとやらを使う利点がよくわからん
抽象的に依存するとか、もう意味のわからない単語が並んでる
誰か教えてくれ！ >>325
たとえば、こういうクラスがあったとして
https://paiza.io/projects/EmYovJbLF2HVGHjC0SMeRA
ペットを犬から猫に変えたいときはCatクラスを作って
Personクラスを修正しないといけないっしょ
あるオブジェクトを変えるときにそれを使うオブジェクトにまで
変更を波及させないのがインターフェイスのメリット こういうふうに、動物インターフェイスを作って
犬や猫のオブジェクトがそのインターフェイスを実装する
ようにすれば犬を猫に差し替えてもPersonクラスを修正する必要はないってこと
https://dotup.org/uploda/dotup.org2424520.png
あるオブジェクトを使うとき、そのオブジェクトを直接参照すると、使う方が使われる方に依存してしまう
電球取り替えようとしたら本体まで取り替えないといけないみたいな状況になるんよ
インターフェイスを使うと使われる方が使うほうに依存するようにできる
図を見るとインターフェイスを使うことで人から犬の矢印が、逆向きになってるのがわかるっしょ
インターフェイスを使うと依存性を逆転させることができます >>325
たぶんあんたの場合DI以前の問題
DIを導入した所で何も解決しない
そもそもDIは依存をなくしましょうパターンじゃない
（実装に依存するのではなくて）インターフェースの方に依存しましょうというパターン
インターフェースがわからないなら、それは実装とインターフェースが一体化してるということ
一体化してるということは、実装が一つに対してインターフェースも一つあるということ
そういう設計が駄目と言ってるわけじゃないし、実際実装が一つしかいらないならそうなる。
そういう状態で「依存しすぎて駄目だ」って気づいたんでしょ？
現在はコードが分類分けされてないどっかのコードに意味不明に
依存しまくっていてごちゃごちゃしてるだけだろう
それならDIで解決する問題じゃない。あんたがやらないといけないのは
コードを責務に合わせてちゃんとファイルに分離すること
そうやって分離して依存関係がスッキリしてきて、なおかつ単体テストをする時に
外部の依存をモックなどに入れ替えてテストしたいって時にDIがでてくる
モック以外でも設定ファイルで使用するモジュールを切り替える仕組みとかでDIは使えるんだが
そういう仕組にしたいときはDIを使わないでもDIに近い仕組みを自分で作るので
DIはほぼ単体テストをしやすくするためのものだと思っていい >>297
役に立たない単発質問スレ立てといてこんなこと書くとかどこまでもクズ
自分で調べて自分で解決してクソスレ立てんな タイヤ が パンク してしまつまた！
チンポ が シコシコ してしまった！ >>331
あわしろ氏による分類では、どちらもオブジェクトになってるね。 >>330
役に立つかどうかは君が決めることじゃない（大正論）
僕はスレを立ててない（大事実）
君が調べて教えて欲しい、それが君の勉強です、君のためです（大説教） あわしろ氏って、いくやくんのこと？ かわいいよねいくやくん もしかして、イクヤきゅんのチンポ、舐めたいですか？ >>326
読んでみる
わからなかったらPHPスレいくわ！
>>327
インターフェイス使えば、Personクラスを修正しなくていいっていうのが利点か
依存性を逆転させて、使うクラスの方は一生変えなくていいから楽ってことか
とりあえず、インターフェイスを注入しとけばいいって事だな
完全に理解した！
>>329
ちょっと何を言ってるのか理解できなかった・・・
実装が一つじゃなくて、増えてきたらインターフェイスを使わないといけないという事で
とりあえずインターフェイス注入しとけばいいという話ではない？ ttps://banners-cdn77.trafficfactory.biz/banners/ca/19/4d/9b26c92ef6ee4caeaf2ff48736b7feea.gif >>339
同じインターフェースを持つクラスが複数あるか？ほとんどないだろ？
そうすると、クラスファイルのメソッド定義部分を取り出した
インターフェースファイルが出来上がるだけなんだよ
そしてどうせ後からクラスのメソッドが増えたり消したりだろ？
そうするとインターフェースもメソッド増やしたり消したりすることになるんだよ
つまりこれは単なる二度手間というわけだ
最低限、ここまではわかってないといけない
その上でやっと、それなのになぜDIを使うんだ？
DIのメリットはなんなんだ？という話ができる。
そしてこの話↑ができるレベルに達していれば
> 今のコードの書き方は依存しすぎててダメだと言うことは気づいたけど
「依存しすぎててダメ」という発言はしないんだよ
なぜなら、そんなに依存してないコードを書ける力があるから
力がない人が、とりあえずインターフェースを使ってれば～いいってことだな！
みたいに言うと、本当に単なる二度手間で終わる。お前やるべきことだけ理解していて
やるべき理由を理解してないだろ。使うクラスを一生変えなくていいなんてことはないんだよ。
DIを使う理由は
1. （コードでやろうと思えば出来るけど）設定ファイルで使うクラスを変えられるようにしたい
2. 依存してるクラスをテストクラスに置き換えて、単体テストをしたい
この２つなんで、その話が出てないのに「依存しすぎててダメ」という話をしたのであれば
DIを使ったとしても「依存しすぎててダメ」＋「二度手間」にしかならない
DIうんぬんの前に「依存しすぎててダメ」と言う状態を
「頑張ったけどどうやってもここの依存を解消できない」と言うところまで持っていけ ○ 2. 依存してるクラスをテスト用の（ダミーの）クラスに置き換えて、単体テストをしたい >>339
理解力といい考え方といい、君センスあるわ >>345
なんでそんなレスしちゃったの？
友達とかでない限り、そんな褒める必要ないよねｗ 嫉妬の意味がわからん。>>339のどのを読んで理解力やセンスがあると思ったのか？
下線だけでいいから引いてみて なんで自分がほめられないんだと思ってるんでしょはいはい 僕で良ければよしよししてあげても良いけどどうする？ >>351
少しでもプログラミングの話をする気がある。出来る力があるなら
>343になにか言い返してみてくれよ >>339と>>343の文章を比べて何も感じないのかな？ >>355
君は何を感じたの？ 僕は君の曖昧で思わせぶりな問いかけにイライラしてるんだ
簡潔に言ってくれないかね はっきりと言語化して他人を説得できないのなら口をつぐんで貝になりなさい
海の底でアワビとして生きて高級食材として素潜り漁師に捕獲され
ヒルトンホテルの料理長に調理されてそれを口にした人を幸福にさせてれば良い
僕はそう思います >>356
問いは相手に考えを促すことに存在価値があるからね
イライラするのは問いを発した相手が何らかの正答を想定してると思い込み、
その正答が自分では分からないから
自分の考えが相手と違っていたら減点評価されるかもという恐怖が刷り込まれてる
そういう考え方は学生のうちに早く捨てたほうがいいよ >>357
言語化して他人を説得する必要なんてないからね
分からない相手を説得して無理に分からせようとするのは時間の無駄だから >>357
>はっきりと言語化して他人を説得できないのなら
ならば「チンポがシコシコする」という言語化表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ なんだできないのか、やっぱり君はアワビがお似合いだよ！ 僕は君が説明できない理由を説明できるよ、君のそれは嫉妬です
なぜ他人が評価されて自分が評価されないのかという思いが君の意識の根底にあって
それと同時に嫉妬していることを認めなたくない思いもあるから本心は意識の底に
封じ込められてもやもや感となって意識の表層に現れているわけ、それを掘り下げられると困るから
問という形で誰かに説明責任を投げようとしたのだけれども、もやもや感を
きちんと説明できずに見破られたってこと、アワビ、君の心はすべてお見通しだ！ アワビ君のキメ台詞「時間の無駄だから」
かっこいいいい！！！！スコールでもこんなクールなこと言えないっしょおおおお！！！！！ひゅーひゅー！！！！
オブジェクト指向業界のスコールことアワビ君をこれからもよろしくお願いします アワビ君を見出すためにこのスレは立てられたと言っても良いのでは!? オブジェクト指向については、オブジェクト指向言語という「形式」を踏まえつつ、
オブジェクト指向とは何かを常に論じていきたい。
https://i.imgur.com/fJK38Be.jpg
チンポは繋がっているが独立しており、チンポ自身の主体意思で勃起する！ >>343
デメリットが二度手間しかないのなら使うわ
使ってるうちにわかってくると思うし
使わないと意識できないから使う
やっぱり、とりあえずインターフェイス注入しとけばいい >>371
二度手間というデメリット＋メリットがない
理解する前に使っても、コストがかかるだけで
何も解決しないと言ってる
使うことが目的になってる
そしてあとで全部書きなすことになる 疑うことが科学の基本、ドクターストーンで千空が言ってた >>371
どういうクラスに対してDIを使うべきで
どういうクラスにはDIを使うべきではないか
それ言える？
どうせ全部やろうとしてるでしょ？ 全部やったら必要なところもそうでもないところもわかるっしょ 責任感と親切心あふれるおっさんほど迷惑なものはない >>378
使うメリットとデメリットが区別つかない人なのに
なんで全部やったらメリットとそうでないものの区別ができると思うの？ >>380
君にわかったのなら他の人にもわかるよ、君を基準とします 他人は自分より賢いと考える、それが論理的思考というものだよ金田一くん それのどこが論理なんだ？
他人が自分より賢いと導ける前提が何もないのにどう演繹してその結論になった？ >>377
今は全部やるね
使うべきではないとわかったら、全部やる必要はないから
とりあえず、犬しかいないのに動物に依存させても意味ないって事でいいの？
確かにそうなんだけれど、今の時点ではわからない
というか、抽象的に依存させるの難しくないか
他の動物が出てきた時点で、やればいいのかと想像してるけれども
どうしたらいい？ 実装フェーズになってから
ＤＤＤとか言い出しても遅いです
馬鹿正直な手続きＣＲＵＤで全部設計したじゃん！
仕様書に出てこない中間の業務分割とか
テーブルのグループ分けなんてなんにも整理してないじゃん！
資料も時間も経験者もないのに
いまからできるわけないだろ！！
機械的に形だけ以上のことできないよ >>386
意味があるかどうかじゃなくて、
"お前が" ここは依存させるべきではない＝ここは単体で
テストできるように設計すべきだ。って思ったところにDIを使うの
お前が意味があるかどうかは判断しなきゃダメなの
まあ大抵、犬とかは動物といった値型と捉えられるようなものは
DIを使うものではない。それはらDIを使わなくても単体でテストできるものだし
やってみればわかるだろうがDIはそんなものに対応してない（すごくやりづらくなるはず）
そうだな。もう一つヒントをやるとDIを使うのは多くの場合シングルトンタイプのオブジェクトだ
一つしか生成できないように工夫されてるかどうかは関係なく
システムの中で一つしか生成しないようなものにDIを使う
そういう設計の話ができるレベルじゃないとDI使っても意味ないんだよ DIもまた、
「全ての問題はもう一段階、
間接参照を導入すると解決する」
という古代の格言の応用に過ぎない >>388
中途半端な知識で変な嘘ばっか教えるなよ >>391
嘘だと思うなら、どこが嘘で何が正しいかを書けばいいじゃん
自分が何が正しいかを理解してないから
何も言い返さず、ただ嘘だ、嘘に違いないんだ。としか言えないんでしょ > お前が意味があるかどうかは判断しなきゃダメなの
ここが嘘だと思った、だってすごく文句言ってるのに自分で考えろなんて絶対嘘でしょ パワハラだよ、お前って言い方は威圧的だし、すごくパワハラだよ VBAやってる俺は余裕で適当なこと書くけど
普通、Has a 関係にあるものをストラテジーパターンで書いて
Is a 関係にあるものを継承やテンプレートメソッドパターンで書くんじゃないの？
知らんけど >>393
実際のコード出してもないのに他人が判断できるわけ無いだろ
そして全部意味がある or 全部意味がない と決められるわけないんだから
本人が判断するしかないだろ
お前 DI の設定ファイルとか見たことある？
すべてのクラス（例えばカレンダークラス）を
インジェクトするなんてやるわけないぞ
そういうのは直接newする >>397
僕はDIの設定ファイルは見たことないです
DIしたこともないです
自動テストも書かないです 既存のインターフェイスを使用することはありますが
インターフェイスを自分で作ることはめったに無いです >>397
君いままでコード見てないのにメリットがないって大騒ぎしてたじゃん
なんでいまになって日和ってるのさ、DIにはメリットないんでしょ？ >>400
> 君いままでコード見てないのにメリットがないって大騒ぎしてたじゃん
どこの部分をみて、そう勘違いしたんですか？
引用してみてください >>401
>>343とか
>>373とか
大騒ぎしてたじゃん >>402
勘違いした部分を、引用してみてと書いたのにそれを無視したのは
それみて間違いだって気づいたから？ｗ >>404
全部引用した、行数が声の大きさを表してるという
僕の説明はすごく筋が通っている、君は大騒ぎしていた それなのにいまは日和って、コードみないとわからないよと言ってる
僕はそんな君を情けないと思う、だったら最初から騒ぐなと言いたい
平穏なスレを返して欲しい、君が>>1だね、逮捕します >>405
該当する箇所がなかったから、引用できなかったってことねｗ >>407
全部該当してたから全部引用したってことに決まってるじゃん それよりも君が>>1だと言った僕のドラマチックな推理にゾクゾクしたでしょ
本当に>>1かどうかはどうでもよくてこの流れで>>1に行くという急展開にしびれたでしょ！
僕も自分で書いてて鳥肌立った 君と僕は考えが真逆だけど波長が合うよね、なんだろこの一体感 >>408
全部の行に「メリット」という単語が含まれてるわけがないんだから
該当するなんてありえないですよ（苦笑）
それと全部のクラスをDIするのはメリットがないと言ったのを
お前は DI のメリットがないと言ってると勘違いしよねって指摘していい？ｗ >>411
> 全部のクラスをDIするのはメリットがない
これです、つまりメリットがないわけです
では具体的にどういうときにメリットがないのかは
コードを見ないとわからないわけです
だからあなたは日和ったのです
だったら最初から黙っとけと僕は思いました そりゃ全部のクラスをDIするのはメリットないだろ？
何に反論してるんだお前？ 大声でメリットがないメリットがないとわめいておきながら
具体的に聞かれたらさあそちらでご判断いただきたく存じますみたいな
ことになってるわけっしょ、だったら最初から全部自分で試してみなよ
そしたら分かるさ、明けない夜はないさー！！！！と言っとけばよかったのに >>413
全部の定義によるでしょ、バカじゃないの >>414
当たり前じゃん。DIするのに適したクラス、適さないクラスがあるのに
どうやってそれを他人が判断すると？ >>416
君はメリットがないと騒いでおられたので、判断できないと日和るくらいなら
騒ぐなよと僕は思いました、君が最初から自分には判断できませんので
そちらでお試しになってみてはいかがでしょうかという謙虚な態度で
書き込んでたら僕もそれはそうですねすばらしいご意見だと思いますって
思ったよ、でも君は横柄にもメリットがないと騒ぎ立てただけだったじゃないか
僕は君のその大騒ぎ根性に大迷惑しているので今後お控えいただきたいです そりゃ全部のクラスをDIするのはメリットないだろ？
ってさっきも書いたのに、
やっぱり「全部のクラスを」の部分を
見なかったことにしたいわけだｗ こうやって絞り込んでいくと、
どの部分を見たくないのかはっきりしていくよねｗ >>418
それは全部の定義しだいでしょうね
全部のクラスがDIとパーフェクトマッチするクラスかもしれないし
それこそその人のコード見ないと判断できないってこと >>419
君は妄想で早とちりする傾向があるからもう少し落ち着いて
スローペースでも良いので論理的に物事を考えたが良い >>420
だから最初から、さあそちらでご判断いただきたく存じますって言ってんじゃんｗ
全部のクラスがDIとパーフェクトマッチするクラスかかもしれない
そうじゃないかもしれない。わからないし
それこそその人のコード見ないと判断できないってこと >>422
> そりゃ全部のクラスをDIするのはメリットないだろ？
という発言といま君が言ってることは矛盾してるので
もう少し落ち着いて、整理して話したが良いと思うんですよ コード見ないとわからないならメリットないこともわからないじゃん 詫びソースコードコメント 1件
アイミョン
[KS108-054]
テーマ：冒険者の広場・DQXショップ2020/02/17 16:22
今月になってから急にシステム障害が多発しており、運営としては説明責任を果たすべきと考えます。
https://hiroba.dqx.jp/sc/news/category/3/
不具合を出した個所とその修正箇所の両方を「詫びソースコード」として開示するのです。
ソースコードも企業の重要な著作物ですが、だからこそ開示して詫びることが大切です。
それと同時にシステムの不具合がなぜ多発しているのかを、プレイヤーも一緒に考えるのです。
バンダイナムコゲームスの『ドラゴンボールZ ドッカンバトル』を見習うべきです。
https://i.imgur.com/s2RHkxT.png >>425
DQXはやろうと思ったことあるんだけどパスワードをコピペで入力できなくて詰んだ よく分からないから何でも取り敢えずDIっぽい構造にして
やってるうちに分かるだろって？
そんな奴がこの業界に居るだけで吐き気がする
他人の仕事を増やすだけだ
転職しろ まぁ経験則で説明しようとして
上手く説明出来なかったんだろうね 俺が槍玉に挙げたのは説明を試みた奴の方じゃないんだが
俺の書き込みだけ見て文脈もまともに把握せずにレスしてんだろうけど
こうなレスする奴ばかりだとメチャクチャにしかならんな
5chって終わってるよな >>423
> という発言といま君が言ってることは矛盾してるので
だから引用しろって
どの行とどの行が矛盾してるのか >>430
その件につきましては>>429から説明させていただきます >>432
スレをきちんと読んで>>430に誠実に説明して欲しい >>433
こいつが何言ってるのか分かる奴いるのか？ >>435
>>430のお客様がどの行が矛盾してるのかとお聞きになっておられるので
支配人から直接ご説明いただきたい >>430
ゲンさんもこう言っておられることだし良いですねそういうことで あーそうか
はだしのゲンのセリフだったんだなあ
微妙に元ネタを思い出せなくて気になってたんだわ
サンキュー、クソガイジ >>428
あるトピックを説明する際に
関係のない事柄や不必要な詳細を長々と語ろうとするのは
そのトピックについてよく理解してないことの証左
説明の上手い下手とは違う >>442
君は何をよく理解してるのかな？ 保健体育かな？ ちょっと覗いてみたが、やはり大人げない発言が多いな
プログラマは幼稚なのか、一般常識がないのが多いな この水準をプログラマの一般だと思うやつがいる程度には、一般常識がないやつが多いのよ スレの最初の方のやり取りを見てればこの議論に加わっても意味はないと分かるし、途中からおかしなのも参戦してるから、しょうもない流れになるのは当然かと思われる。 初心者のフリをした>>1が、教えてくれた人に対して、以前からあったOOPに対する批判をぶつけるクソスレ
だったのがいつものやつに乗っ取られた後
今は初めて見るやつに乗っ取られている つまり教えに来ている奴も大して教わりに来ている奴とレベルが違わないバカだから
教わりに来た奴から舐められて昨日みたいに荒れまくるってことだな >>450
>つまり教えに来ている奴も大して教わりに来ている奴とレベルが違わないバカだから
ならば「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ チンポシコシコいい加減飽きるわ
志村のギャグ並みにしつこくてクソうざいわ 本人だけは面白いと思ってやってんやろな
池沼の子が同じこと連呼するようなやつやろな >>452
ならクリントン大統領の「不適切な関係」はどうなんだ？ Javaなんかやってると頭悪くなるから仕事でなければ使うべきでない
Javaという単語を口にするだけで頭悪くなるんだ
現に今、俺の知能指数は10下がった >>456
クリントン大統領もチンポがシコシコしてしまって、大統領権限をもってしてもどうすることもできなかった。 令和２年度 第2回島本町いじめ等対策委員会
この会議は令和3年2月4日に終了しました。
【会議録】会議録は準備中です。
会議はとっくに終わったんだろ
その議事録が２カ月近くも経ったのにまだできないのか
どれだけ鈍臭いんだよ
それとも公表しにくい理由でもあるのか？
町長選挙が終わるまで公表しないのか？
電話０７５－９６２－０３９１島本町教育こども部 教育推進課（役場１階）
ファックス075-962-0611 知能指数ってマイナスも示す場合があるって初めて知ったわ ム板で勢いNo1のスレがこの過疎っぷりかよ
最近はみんなとぅいったーとかやってんのかな
俺も2ch覗いたの久々だわ チンポシコシコ野郎って糖質か何か？
普通にガイジ過ぎる >>462
クリントン大統領もチンポがシコシコしているぞ？ オブジェクト←何を意味してるのかわからない
指向←何を意味しているのかわからない
こんなもんわかるか！！！ プログラムモジュールを
「現実の実体ある物体のように考える方向で」
という思想なので、わからない！って人は
別にそこの地べたを永遠にのたうっててええんやで。 わからないのが正しい
本人がわからないのを胡麻化しているんだから
わかるいうやつが詐欺師 >>465
>「現実の実体ある物体のように考える方向で」という思想なので、
class チンポ｛
super.不適切な関係;
｝
クリントン
↑
チンポ
クリントン大統領の「不適切」というのは、チンポが独立して主体意思でシコシコしてしまったから。
チンポは独立した生き物であり、アメリカ大統領の権限をもってしても、制御することは不可能だ。
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ >>465
こういう人に入門書を書かせるとすぐにclass Person extends Mammalし始める
Strategyをその思想で表現できると思うのならやってみろ >>465
俺が作りたいのは「現実の実体のある物体のようなもの」
なんかじゃねえんだよバーカ！
バーカ！ >>470
>俺が作りたいのは「現実の実体のある物体のようなもの」
オシッコするときのチンポは、随意筋だけど、勃起するときのチンポは不随意筋だよね？ >>470
>俺が作りたいのは「現実の実体のある物体のようなもの」
オシッコをするときはメッセージングによる制御、射精するときはモジュールによる独立ね！ だから射精じゃなくて潮吹きに変えてくれっつってんだろ >>465
Wikipediaにはデータとコードをまとめてオブジェクトにする開発手法としか書かれてない
>「現実の実体ある物体のように考える方向で」
これの出典はどちらかな？ https://ja.wikipedia.org/wiki/オブジェクト指向分析設計
> オブジェクトは、モデル化を行うシステムにおいて
> 関心の対象となっている実体の表現であり
見つけた プログラムでは、契約やキャンペーン,支払といった実体のないものもオブジェクトとして扱うので
実体ある物体は違うように思う オブジェクトは日本語では物と訳されるけれども物には2つの意味がある
・形のある対象物
・形のない抽象的な概念
オブジェクト指向のオブジェクトは形のない抽象的な概念の方が近い
概念は論理学の言葉で事物に共通な性質を抽出したもの
論理学は人間の認知に基づいて正しいとは何かを突き詰めて発展した
オブジェクト指向の良いところは人間の認知に即しているところ
オブジェクト指向だとプログラムがわかりやすい
わかりやすいことこそがオブジェクト指向の価値だと思う >>480
>オブジェクト指向のオブジェクトは形のない抽象的な概念の方が近い
オシッコをするチンポと射精するチンポ、繋がっているけど独立しているチンポ。 >>480
分かりやすいことでプログラムの生産性が向上する
これがオブジェクト指向がもてはやされる原因だろうな
複数人でのプログラムのいじりやすさ、後付けで機能を増やしたり改造したりしやすい
メモリ効率や実行速度の点ではそれほど利益はないがCPUの機能向上やメモリの低価格化のせいで今ではそれらは余り求められていない ブルマなんて恥ずかしいって言うけれど、
請負業者の彼は毎年、マハラシュトラ州で250人以上を集め、6カ月間の労働のために遠隔地の農園に送り込む。子宮摘出の費用として賃金を前借りさせ、法外な利子で女性の自由を奪うことも多い
https://www.newsweekjapan.jp/picture_power/2021/04/post-42_1.php
中身丸ごと剥ぎ取られてる女性も居るらしい。 もともとは以前書いたように、大型化やネットワークで
プログラムモジュールの動作を逐一追って狙った順番に動作させていくのが
困難になっていくだろうというビジョン、予測から
プログラムモジュールを一種のロボットのように捉えて
「よし、おまえはこれをやれ！」「ワカリマシタ！」的に
完全に独立した単位として扱おうという考え方なのだけど
その前提から考えられたさまざまな思想が便利だったものだから
「これとこれだけ必要だわ」「いやいやこれとこれだろう！」と
各言語の後継が好き勝手に一部の機能だけをつまみ食いして実装したのが
「これがオブジェクト指向言語！これがオブジェクト指向！」ってそれぞれ主張して
訳がわからないことになったってだけだし。
だからスタティック還暦じいさんがずーっと
「このゴワゴワして毛が生えた柱のようなものがゾウじゃろ！説明してみろ！」って
寝言ほざき続けてるわけでw >>487
> プログラムモジュールの動作を逐一追って狙った順番に動作させていくのが
チンポは独立した生き物で、本人の意志とは無関係にチンポは勃起する。
> 完全に独立した単位として扱おうという考え方なのだけど
オブジェクト指向は俺の股間に付いているモノなのだ！
> 「これがオブジェクト指向言語！これがオブジェクト指向！」ってそれぞれ主張して
チンポ【を】シコシコするのではなくて、チンポ【が】シコシコする、これがオブジェクト指向ね！ >>487
簡潔に書いてくれよ
いくつかのプログラム手法を指して「オブジェクト指向」と名付け呼んでいるだけ
なぜかその「オブジェクト指向」を特殊技術か何かのように勘違いして身に着けようとしたり無意味に反発しているバカがいる
そんな無意味なスレをここだけじゃなく乱立させたうえに食いついているバカが多数いるのが情けない。まともなプログラム技術身につかないから違う方向で頑張っているんだろうけど何の役に立つんだろう >>489
> なぜかその「オブジェクト指向」を特殊技術か何かのように勘違いして身に着けようとしたり
チンポはそれ自体が独立した主体意思で勃起して射精するということだな。 >>489
オレオレ定義に固執するガイジにマジレスしても意味無いぞ >>491
オレオレ定義？アクターとメッセージパッシングの説明じゃん >>492
明らかにそれだけじゃないことをゴチャゴチャ言ってるだろうが
実行順の制御が難しいシステムを構築するテクニックが
オブジェクト指向であるかのような
おかしなことを延々と語ってんのお前だろ
少なくとも今のオブジェクト指向て言葉にそこまでの意味なんかあるわけないだろうが
マジでいい加減に一般的な意味をググってこいよ
通じない言葉ばっか喋ってんじゃねーよクソうざいわ
ギャグなら分かりやすく言いやがれ
チンポシコシコ野郎を見習えよ >>493
> 少なくとも今のオブジェクト指向て言葉にそこまでの意味なんかあるわけないだろうが
繋がっているけれども独立している、メッセージング制御とモジュール独立、チンポ【が】シコシコする。 >>492
よく見たら違うIDの奴か
発言の全体見ろ
アクターを使った別プロセスとのメッセージパッシングなんて
明らかにオブジェクト指向の基本ではなく応用
初心者を混乱させるようなことばっか言って混乱させて
マウント取りたいアホが無駄に分かりにくいことを言うんだよ そもそもこのスレにオブジェクト指向を教えてほしい初心者なんていません >>496
使ってる言語の機能を適切に使え
OOPなんて無意味な言葉は忘れろ
終わり >>496
制御性と自律性。オシッコは制御型、勃起・射精は自律型。メッセージングとモジュール。
オブジェクト指向とはまさに俺の股間に付いているモノだ。 俺にとってのオナニーはするしないではなくて、気がついたらしていた、オナニーはそこにあったのだ！！
チンポ【を】シコシコするのではなくて、チンポ【が】シコシコする！ >>485
では私の嫁を絵の中から出してください。 概念モデル化されるものは全てオブジェクトとしてモデリングしうる
モデル化されたそれらの間にメッセージ・パッシングが行われる
これ以外は後付の定義だと思ってるけど メンタルモデルという最重要単語が未だに出てこないレベル。 オブジェクト指向UIの著者がメンタルモデルという言葉を使ってるけど
オブジェクトを操作の対象と言ってるのが怪しさ満点なんだよなあ
ソーカルが批判したポストモダンのように思えてならない アラン・ケイの専門の一つは分子生物学だが、ミンスキーにも影響されてるから「心の社会」も当然読んでるだろう >>492
基本的に昔から「オブジェクト指向なんてー」って叫んでるじいさんは
あれ90年代初頭に「これからはオブジェクト指向のC++の時代だー！」ってのに乗って
読んでみたらなんにも理解できなくて発狂した専門学校卒プログラマーの類だから。
大学でコンピューターサイエンス系の教育を受けてないから
システム設計側の思考ができないし、知識が永久に
C++レベルの“クラスと継承がオブジェクト指向”で止まってるもんで
それ以外の話をしても「俺が知ってるオブジェクト指向と違う！嘘定義だ！」って言い出すわけw やれやれ人格批判で自己の正当性を主張するつもりかこの御仁は 割と的を射ていてワロタ
理解出来なくて発狂した知り合い居るわｗ
今生きてるのかどうかも知らんがｗ >>500
チンポがシコシコするということは
チンポが何をシコシコするのだ？
その一番大事な部分が表記されていないから
お前は無能なのだ
自分自身を指しているならそれはただの振る舞いに過ぎない オシッコを出したり止めたりは、チンポオブジェクトへのメッセージング操作なんだが？
>>506
> オブジェクトを操作の対象と言ってるのが怪しさ満点なんだよなあ
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>511
チンポはチンポ自身が自らの意思で自律的に勃起してシコシコする。 スレタイに「オブジェクト指向」が入ってるとワラワラとおっさんが集まってくるのは
新しいパラダイムにはついていけないがよく見知ったオブジェクト指向なら思う存分自分語りできるから
20年以上前にオブジェクト指向というパラダイムについていけなかった人たちを見下すことで
リアルでは得られない自己肯定感を得ようとしている
反面教師として見るべき存在 >>514
> 新しいパラダイムにはついていけないがよく見知ったオブジェクト指向なら思う存分自分語りできるから
オブジェクト指向は俺の股間に付いているんだが？ >>514
新しいパラダイムって具体的にどれのことを言ってるの？ >>513
だとすればその設計には致命的な欠陥がある
何故ならチンポは自身が勃起することが有っても
自身がシコシコすることはあり得ないからだ よくこんなスレが伸びてるなぁ。そんなに難しい話じゃないんだが。
「オブジェクト志向（オブジェクト・オリエンテッド）」って、そんなに難しい概念じゃないんだが。
昔は「算体主導言語」と呼ばれていて、「オブジェクト・オリエンテッド」つーより、「メッセージング」のほうがわかりやすいという話があった。
「オブジェクト」というのは「もの」であって、「もの」にメッセージを投げるとメッセージが投げ返されてくる、という話ではある。
で、「もの」には「すでに具現されているスタティックなもの」と、「設計図だけあって、new しないと具現しないダイナミックなもの」がある、という話。
僧帽筋凝ってねぇ？ >>101
> Cで充分です
はライブラリ水準だったらその通りなのだが、大規模プログラムになるとマルチで動いているので、「広域変数にアクセスするときにケンカしない」という安全性のためにカプセル化したかった、という話があった。
C 言語は「超高級マクロアセンブラ」と呼ばれていたわけで、C++ は C の名前空間を隠蔽しようとして、さらにプリプロセッサを重ねたわけだ。
つまり、C++ は「アセンブラ⇒マクロ・プリプロセッサ⇒ C ⇒ C++」という、「三枚重ねのコンドーム」みたいな言語なのだが、「気持ちよくない上に、安全でもない」という問題があって、「オブジェクト志向の言語体系を一から見直そう」という話になったわけだ。
C でちゃちゃっと書けるプログラムだったら、正直 C で書きゃあいいと思うが、GOTO 文がないだけで、フツーに Java とかで書けると思う。
メソッド内で実装するんだったら、それほど不自由はないと思うが。 >>518
> 新しいパラダイムって具体的にどれのことを言ってるの？
オシッコするときはメッセージング制御、勃起・射精するときはモジュール自律ね！ >> ところで「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
なんか懐かしいな。十年以上前に読んだ気がする。 シコシコという『擬音』は確かに有り得ないが、
>>520
>自身がシコシコすることはあり得ないからだ
自我とチンポが、相互に葛藤し合っているのだとは考えられないだろうか？
>>115
> チンポ≫自我
>
> 『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
自我であって自我では無いもの、言い換えればそれは、拡張された自我としてのチンポ！ >>525
同時に葛藤し合っているというのであれば、
それはチンポが>>525に「シコらせたい」のであってそれを見て>>525がシコるか
シコらないかの判断をして>>525がシコっているということになる。
つまりこれはオブザーバーパターンに該当するのであり、
チンコの情報を常に監視することによって>>525がシコっていることに他ならない 785 名無し三等兵 sage 2019/12/03(火) 08:03:27.78 ID:sujZBpWD
>>762
＞「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
チンポにチンポ自身を扱く機能が備わっていないので自動詞は不適切だから（34文字）
胸（心臓）には鼓動する機能があるため自動詞の適用対象だが
チンポには勃起する機能はあっても自身を扱く機能はないので「チンポ『が』勃起する」は成立しても「チンポ『が』シコシコする」は成立しない
夢精した状況を「チンポ『が』シコシコした」と称したければ「チンポがエロい夢を見させ夢精した」＝「脳ではなくチンポが思考を司りエロい夢を見させて夢精させた」という状況で可となる
脳でなくチンポで物を考える生物についてなら「チンポ『が』シコシコする」は成り立つ
如何にもだつお的じゃないか >>527
チンポでものを考える生物であってもチンポはシコシコしない
何故ならチンポ自体にシコシコする機能が備わっていないからだ >>528
> 何故ならチンポ自体にシコシコする機能が備わっていないからだ
クリントン大統領の『不適切な関係』は、チンポが独立的にシコシコして、大統領権限を超えてしまっただろう？ >>528
> 何故ならチンポ自体にシコシコする機能が備わっていないからだ
『人格を性欲に乗っ取られる』というのは嘘なのか？
https://mobile.twitter.com/takinamiyukari/status/1356895993338318848
瀧波ユカリ
@takinamiyukari
「女性の生理も大変らしいけど男性の性欲も大変、人格を性欲に乗っ取られるから」という旨のツイートを読んだ（似た内容は定期的に目にする）。
私は男性に「女は子宮でものを考えるから理性的な思考ができないので男性と同じ役職には就けない」と言われ見下されたことがある。
一体なんなの。
https://twitter.com/5chan_nel (5ch newer account)
https://twitter.com/5chan_nel (5ch newer account) >>531
それはチンポに>>531という人格が乗っ取られて
チンポの思うままに操られて行っているだけで
チンポが勝手に動いてシコシコしている訳ではない
ただの言葉遊びであってObject指向を語るにはそぐわない >>530
クリントンは知らんがバイデンの息子のムスコはシコシコではなくズポズポだな
しかもチンポがやったことではなくバイデンの息子がやったことだからあれだけ話題になって叩かれている
本当なら隠蔽されるべきメソッドが外部から読み出し可能だからそうなる >>532
> チンポの思うままに操られて行っているだけで
つまりチンポは独立した生き物という、まさしくオブジェクト指向ということだな！
> チンポが勝手に動いてシコシコしている訳ではない
まあ確かに『シコシコ』という擬音は無意味かもなw あわしろ氏は(どうでも)良い
｢あわしろ氏は、｣は糞 つまりあわしろ氏はExceptionを継承して作られたクラスということ 同期とか非同期かとかいった話は、
複数のスレッドから要求があったときに
待合せが必要になるのと、システム内で共有する
（C とかでは一般的な）広域変数的なパラメータを
どうするかという話に結びついていると思う。
「オブジェクト志向」という言葉に反応して
反射的に荒しにくる人というのは、たぶん
「シングルトン実装は禁止」とかいう現場で
深いトラウマを受けた人なんじゃないかと思う。
オブジェクト志向は、べつに無くても困るもんじゃないが、
プロジェクトが大きくなって頭数が増えると
概念の共有化の役には立ちそうに思う。
ただ、それに乗じて縛りをきつくするジジイがいたりすると迷惑だが (-_-!)。 本質外したところで認識してて、言語仕様に振り回されていながら
マウントしようとしてる間抜けな馬鹿ばっかですからここは >>539
打ち間違いかと思っていたんだが
複数回間違えていたので
どうやら間違えて覚えているようなので
指摘させて頂くが
「Object志向」ではなくて「Object指向」な
別にObjectを志す訳ではないだろう？ オブジェクト指向は日常生活でやってることそのもの
ほぼ物を扱う
家事もそう
コンマリの片付け術はときめきモデルだ 志向は、心の向きだから「俺はオブジェクトになる！」みたいなことだろうね
-orientedは、～を重視するという意味じゃないかな
重視は、ある物事を重要だと考えること
重要は、物事の根本に関係していること
根本は、物事が成り立っている基礎になるもの
基礎は、ある物事を成り立たせる、大もとの部分
言葉をそのように分析すると
～指向は、ある物事を成り立たせる大もとを～と考える、という意味になるんかね こどもにクソの話すると異常に興味をシメス
これがオブジェクト指向だ >>544
> ～指向は、ある物事を成り立たせる大もとを～と考える、という意味になるんかね
オシッコするチンポは制御型、勃起・射精するチンポは自律型。こんな不思議な生き物が俺の股間に付いている。 >>547
それをシコシコ指向と呼んだ場合省略してもシコシコになる件についてどう思うのか見解を述べよ >>548
「シコシコ」は単なる擬音表現に過ぎず、チンポはチンポ自身が独立した別の生き物であり、
言い換えれば『人格を性欲に乗っ取られる』、その点だけをご理解いただければ十分だ。 >>542
「オリエント」というのは、アレクサンドロス大王のころ、「光は東方より」ちゅーので、チグリス＝ユーフラテス地方（いわゆる、「河の間の土地」を目指したというのが語源。
当時はアケメネス朝ペルシャなんかのペルシャ文化の爛熟期だったので、「東征」といっても「征服」というよりも「文化的融合」を目指していたらしい。
「オリエンテーション」なんていう言葉も、「方向づける」という意味で使われる。
そういうわけで、「指向」はもちろん間違いではないのだが、ある種の「着地点」としての「志向」のほうを使っている。
まぁ、「多重継承を認めるかどうか」とかいった議論もあるので Java でもインタフェースとか抽象クラスとかいろいろツギハギな部分はあるわけだが。
まぁ、アレクサンダーさんもインドまで征く途中で西ナイル熱にやられてバビロンで死んじゃったので、いまのところ「使い勝手のいい大規模開発向けの汎用言語のコンセプト」として
OOL があるんだと思う。
COBOL ⇒ Ada ⇒ Java みたいな流れかな。C と C++ は、システム開発言語としては優秀だけど、汎用言語としては、ちょっと危なっかしい。 >>544
「メッセージを投げると、メッセージが返ってくる」
（「あなた」と呼べば、「あなた」と応える的な）という「対象」として、
「ルーチン」みたいな「内部状態が固定なのが原則」ではなくて
「もの」を考えるのがオブジェクト志向という考え方だと思われる。
そのときに、static だと「すでに存在していて、メッセージをただ投げればいい」のだが、
「いちいちクラス定義から生成しないといけない」やつは、若干わかりにくい。
さらに、呼ばれたときに自動的に初期化されて、
用が済んだら内部状態をセーブしてから消えるとか、
「別々に呼んでると思ったら、じつは実態はひとつ」みたいな
シングルトン実装とか、いろいろとややこしい話がある。
C でも、「ポインタがわからん！」という話はあったけれど、
参照とか実体とかいった話を「オブジェクト」という概念で整理してみたものの、
「いまひとつ整理しきれていない」とか「かえって分かりにくくなった」とか
「使いにくくなった」とかいった声があるのが OOL の現状かも。
とはいえ、詰将棋的な面白さはあるんだけどね。 オシッコするときのチンポは随意筋、勃起するときのチンポは不随意筋ね！
>>552
> まぁ、「多重継承を認めるかどうか」とかいった議論もあるので
随意筋 不随意筋
↖ ↗
チンポ >>555
その上に筋肉というクラスがあり
随意筋と不随意筋を継承させれば
立派なダイアモンド継承の出来上がりである >>556
> ホンモノの static おじさんだ初めて見た
そんなに若く見られると照れちゃうじゃないか (^_^!)。
Java という言語は、LISP とか BASIC とか BCPL とか Pascal とか、
いろんな言語の影響を受けている（とくに文字列表現なんかはそうだ。
処理系という点では、SmallTalk 80 なんかに影響を受けている）ので、
私は「前世紀の遺物」的な存在だ。
つーか、若造と一緒にされても困るんだがね。
>>557
「森ダイアグラム」というのもあるな。
正比例 → 微積分
正比例 → 線形代数
というのがあって、微積分と線形代数から多重継承したのが
多変数部積分（ベクトル解析）だという話がある。 オブジェクトを「もの」として説明する人はオブジェクト指向とは何かを全く理解してないってアラン・ケイが言ってたな >>559
> オブジェクトを「もの」として説明する人はオブジェクト指向とは何かを全く理解してないってアラン・ケイが言ってたな
オブジェクト指向は俺の股間に付いている『もの』だが？ >>560
いや、お前の股間に生えているそれは
ガワこそチンポかも知れないが実は中身は
寄生した新種の巨大なロイコクロリディウムで
本来「シコれ」と指令を送るはずが
「コロナに掛かりそうな場所へ行け」と
指令を出しているかも知れない
つまり中身がだしている指令(メッセージ)が大事で
別に「もの」かどうかなんてあまり重要じゃない
というのがアラン・ケイとかいう奴の言い分らしい
さっきググったらそんな感じだった >>559
C++の時は「クラスと継承がオブジェクト指向！」だったから
バカがほざいてるような「馬から牛が簡単に！」みたいな説明ばっかだけど
オブジェクト指向の実体は「進め！止まれ！曲がれ！に反応するように」だから
「“馬と御者”を“エンジンとハンドル”に差し替えられます」で
まったく方向と次元の違う概念なのに、まずそこからわかってねぇんだよな。 「オブジェクト」というと、「UFO（未確認飛行物体）」じゃないけど
「実在物」として考えちゃうんだろうなぁ。
> オブジェクトを「もの」として説明する人
というのは、流行り言葉に翻弄されているのではないかと思う。
馬場あき子『鬼の研究』によれば、「鬼」には「もの」という訓が
充（あ）てられていたという。
メモリ空間上に、メッセージ交換ができるものとして「実体」として
機能しているもの、というものを想定してシステムを構築する、という
コンセプトが「オブジェクト志向」なのであって、
「スタティックおじさん」というのは「ROM に焼いてある」
「ライブラリに入っている」程度の理解しかないのだろうと思う。
データベースや疑似乱数生成と連携したりとかいった、
ネットワーク系の仕事をしたことのある奴なら、それなりに
OO は腑に落ちると思うのだが。 >>562
C++はSimulaからパラダイムを受け継いだ正統なオブジェクト指向だよ
アラン・ケイのオブジェクト指向がクソなんだよ、ただのアクターパターンでオブジェクト指向による設計例の一つでしかない、それがまるで源流かのように思わせてるクソ定義ですわ、アラン・ケイのオブジェクト指向は井の中の蛙です >>519
ウォズニアックが大学に入って勉強をしなおしたときに、
「"paradigm" のスペルを憶えた」とか嬉しげに
言っていたとかいう話を思い出した。
勉強をするのに「年をとりすぎた」ということはないぞ。 >>566
> 志向じゃなくて指向やで
スレタイはな。
老眼が進んでいるが、それくらいは読める。
昔は「算体主導型言語」とか言ったものだ。 >>569
そうか、ジジイなのか
安心しろ、俺もジジイだ >>568
「メッセージング言語」のほうがよかった、という声もある。
ただ、「どこのどいつにメッセージを投げるのか」を考えると、
「オブジェクト」が出てくるのはいたしかたない。 オブジェクト指向について自分の意見を述べるにせよ、
『 ブ レ て 』 い な い か ？
ということも検証して欲しい。 時と場合によりけり、というのも立派なオブジェクト指向ね！
>>562
> オブジェクト指向の実体は「進め！止まれ！曲がれ！に反応するように」だから
オブジェクト指向の実体は、オブジェクト自らが独立した知能回路を有し、自らの判断で動くものだ！
キミたちは「勃起するぜ！ウオォォー！」って思うだけでチンコが勃つか？
そんなことはない！
https://tottokotokoroten.hatenadiary.com/entry/20130516/1368716650
しかしながら時に『メッセージング』により制御される場合もある！
そして、トイレへ行き尿を出そうと思うと、脳が「出してよい」という信号を送ります。ここで副交感神経が
主にはたらき、尿道の筋肉がゆるみ、反対に膀胱の筋肉は締まって尿を押し出し、尿が排出されるのです。
健康な成人では、1回の排尿量は300ミリリットルほどで、約30秒で膀胱が空っぽになるのが普通です。
https://www.hainyou.com/sp/m/mechanism/ コンテナとかもろものを表す単語だし
ものだから名前をつけられる
プログラムのオブジェクトがものじゃないのは
理解してる >>574
> コンテナとかもろものを表す単語だし
> ものだから名前をつけられる
> プログラムのオブジェクトがものじゃないのは
オブジェクト指向は俺の股間に付いている『もの』だが？ >>569
志向だと、君がオブジェクトになりたいって意味になるよ >>575
「プログラムのオブジェクトは」と前提条件があるようだが君はデジモンか？ >>574
ものでええんやで
ものには抽象的な概念という意味もある
論理学では命題を作るときにものを使って概念化して動詞文を名詞文に書き換える技法が使われるんよ
例えば、鳥は空を飛ぶという文は、鳥は空を飛ぶものだ、という文に変形して論理学では扱うんよ >>579
> 例えば、鳥は空を飛ぶという文は、鳥は空を飛ぶものだ、という文に変形して論理学では扱うんよ
ならチンポがシコシコするという文は、チンポは自律的に勃起してシコシコするものだという文に変形できるのか？ >>576
> 志向だと、君がオブジェクトになりたいって意味になるよ
指向か志向かだが、拡張された自我がチンポだと考えれば、志向している自我と指向しているチンポとなる！
チンポはそれ自体が独立した主体生物とは考えられないのか？？？
自我ーーーーーーーーーーーーー
┃ ┃
┃ ┃
┃ ┃
┃ ┃
┃ ┃
ーーーーーーーーーーーーーーー
┃ﾁﾝﾎﾟ┃
￣￣￣￣
ﾁﾝﾎﾟは自我の拡張クラスね！ . .,ｘ;Ρ. ． r'ニ、
.. с⌒l^ г、 .rｮ .＿＿|｛＿,..＼ヒﾉ. .rｭ _ ｎ′
...､．=ﾆ．〉∟．．、 `ゝ' ﾉ/. `￢￢；冖'''′ ,xヒ'.,コ;-､ ´＼ `'
.´~￣⌒"|.Г~~` ノ/ ｨ |_| -、 Υ//. ｣.| ヘヽ、
､// ノｧ′ ｌ.｝ ｝|. `('x, ､/j'′ .ノﾝ. `'´
,ﾝｼ´. ⊂ﾆニ-'′. tノ ､|.| ＼ ． ~ └`
... `´. ｀′ ~′
.. ∩... ． ,､..＿
. Л.. Ｌニニﾆ⊃.. |.| `^''''￢￢-ニｒ
」｛. l｜.
!ｲ. ；､ И ,.ｎ
V． //. .-..､_ _.．.． Ｙ- ィﾝ´.. `～ニ;-=ィ'√
´`:-ｺェｚ:シ ´`'.￣-'⌒. ￣￣￣ ￣. >>580
シコシコするは他動詞なので対格がないとダメ 受け身にすれば良い、シコシコされるものだ、ならOK >>581
「チンポは自我の拡張クラス」
そう考えるとチンポは自我の機能を保有していることになり
>>581はチンポという関係が成り立つ 「抽象的な比喩ではなく具体的なコード例を通してオブジェクト指向を学びなさい
人生の時間を無駄にしたくないのであれば」Bjarne Stroustrup 人間はオブジェクトを通して考えを理解する
オブジェクトと無関係な
アセンブラや命令型言語だと1と0で考える世界
むしろ天才しか扱えない >>588
やっベーアセンブラやってた俺って天才じゃん このスレの一連のレスが
オブジェクト指向がもてはやされた本質の暗部を現している
良い意味ではなく だからこそ
いいぞもっとやれって感じかな
オブジェクト指向とは
所詮この程度のものだったのだと >>587
ゴミの中に投げ込まれた宝石のような言葉だ メッセージングベースの正統オブジェクト指向の成果がiOSとAndroid
クラスと継承ベースの欺瞞オブジェクト指向の成果がWindows
わかりますね？ じゃ俺Windowsでいいや
iOSはともかくAndroidアプリ作る
javaの糞っぷり考えれば必然的にそうなる
遅いし >>587
> 「抽象的な比喩ではなく具体的なコード例を通してオブジェクト指向を学びなさい
class チンポ｛
super.不適切な関係;
｝
クリントン
↑
チンポ
クリントン大統領の「不適切」というのは、チンポが独立して主体意思でシコシコしてしまったから。
チンポは独立した生き物であり、アメリカ大統領の権限をもってしても、制御することは不可能だ。
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ >>595
> Javaの糞っぷり考えれば必然的にそうなる
> 遅いし
私はジジイだが、もっとジジイを久々に見た。
昨今のオプティマイザは侮れないぞ？
「こんなに速ぇのか」と orz になるくらい速いし、
開発効率やマシンの性能向上とかを考えると、
「遅い」の評価基準の問題になると思うんだが。 >>590
オンオフとかニモニックまで遡ると味わい深いぞ。 ジジイなら解ると思うんだが
JavaはILを翻訳しながら走っているからな
Android開発は
WindowsPhoneを開発するC#、VB.Netや
iPhoneを開発するObjectiveC、Swiftみたいに
直接ネイティブコードを生成することが
出来ないためどうしてもレスポンスが遅くなる
環境を選ばないためにそちらを犠牲にしてしまったのだ。これはゲームアプリなどでは死活問題になる場合も出てくる
Androidという括りであればまだXamarinで別言語を使って回避することも出来る部分もあるが
Javaは糞ということに何ら変わりはない >>597
俺もつい最近みたベンチマークのスコアでは
一位二位がたしかCとC++だったかで
その次にRustが入ってたためにスレに引用されたやつなんだが
俺がむしろ驚いたのはその次くらいにJavaが迫って来てたこと
原理は分からんが今やJavaってそれくらいの位置に来てる印象 >>599
「間に中間言語（IL）をかますと遅くなる」という話はわかるのだが、
ハンドアセンブルでチューニングして高速化するとかいうのは
いまどきの大規模ソフトウェア開発だと、あまり
現実的ではないように思う。昨今のオプチマイザは優秀なので、
人間がカリカリにチューニングしても（おそらくは）倍は違わない。
ジジイとしては、「速くする前に分かりやすくしよう」に一票。
UCSD-Pascal だって、p-code という中間言語を使っていたわけだし、
昨今の中間言語は侮れないぞ？ >>601
その中間言語を一発翻訳して実行ファイルにしてくれないところに問題がある。
何故にハンドアセンブルする話になるのか。
いくらジジイと言ってもPC-8001やMZ80Bが出てる頃にはアセンブラや逆アセンブラは普通に売ってたし
雑誌にも掲載されていたしその気になれば自分で作れたろ？
まぁ分かり易くするというのは同意だが
そう思うのであれば是非ともこのスレにもそれを反映して欲しい >>599
> 直接ネイティブコードを生成することが
> 出来ないためどうしてもレスポンスが遅くなる
>>600
> 原理は分からんが今やJavaってそれくらいの位置に来てる印象
Java は（中間言語インタプリタ言語である）LISP の影響をけっこう受けていて、
「ループしてると判断したら、その部分の中間コードを
ネイティブコンパイルしてぶっ込む」とかいうことを
わりと平気でやっちゃうのだ。
もう数十年前の話だが、FORTRAN と LISP でベンチマーク勝負したら、
1.4 倍しか違わなかったという話もある。
C や C++ だったらアセンブラに落ちたところでチューニングする手も
あるんだが、昨今はコンピュータ・リソースが余っている感じなので、
下手に人間が頑張るよりは、コンピュータ様に丸投げしちゃったほうが
（人間全体の）作業効率は上がりそうに思う。 >>602
それは漏れも思っている。
『Joel on Software』にもその話があったが、
「.exe ファイルが作れない」つーのがけっこうイライラするというか、
コマンドラインで実行するのに、いちいち「Java」と指定しないと
いけないというのが鬱陶しい。
このあたりの話をすると MS に対する愚痴になって、何を言うかわからないので
止めておくが。
> いくらジジイと言ってもPC-8001やMZ80Bが出てる頃には
> アセンブラや逆アセンブラは普通に売ってたし
> 雑誌にも掲載されていたしその気になれば自分で作れたろ？
若く見られて嬉しいな (^_^;)。
こちとら通信用のスーパーミニコンのオブジェクトに
パッチを当ててた世代だぞ？
「パッチの上塗り」「泣きっ面でパッチ」とか言ってたなぁ（笑）。 >>604
どんだけジジイなんだよw
ま、最初にやったのがAppleⅡの6502だからあまり人のことは言えないか・・・ ランタイムに依存してるし
一行づつ翻訳してるわけもなく
仮想環境作ってメモリに展開してる class チンポ {
キンタマ きんたまＡ
キンタマ きんたまＢ
float length
void 勃起(){}
void 射精(){}
} >>605
> どんだけジジイなんだよw
『I/O』の創刊世代だな。
フェアチャイルドの F-8 とか、宮永さんが
ナショナル・セミコンダクタの SC/MP を推してた頃だ、
TK-80 とか LKIT-8 とか、そのあたりの思い出を語りだすと
なかなか尽きない部分があるのだが、スレの趣旨から外れるので
温慮しておこう。
「手続的言語」「論理型言語」「函数型言語」とか
いろいろなコンセプトはあったわけだが、
「算体主導型言語」というコンセプトは
（「究極」とか「志向」とかは）言わんけど、それなりに
ソフトウェア開発の現場においては有効なパラダイムで
あるように思う。
上の（ミニコンの）世代からは「パソコン坊や」と
あしらわれていたんだがね。 >>608
I/Oも長いこと続いて厚くなったり薄くなったり小さくなったりしてたもんなぁ
ま、俺がやってたのは少し特殊でどちらかと言えば芸夢狂人さんとかの方が参考になったけど。
それでも実際そういった業界に入ってみるとそれですら児戯に等しいことを思い知らされたよ。
Object指向とはかなり逸れるけど、機会があったらスーパーマリオのソースとかみるといいよ。
アセンブラの知識だけでは組み得ないひとつの洗礼された完成形だよあれは。 お前らマジで知的障害者のモノマネなんかやめろよ
不謹慎だぞ >>609
「NIBL」だっけか？ 『I/O』の折込でそういうのがあった稀ガス。
それに８K BASIC のコードが掲載されていたように記憶している
（「スター・トレック」がプレイできる）。
当時はBASIC 全盛（N88-BASIC。「N88-DISK BASIC」は
フロッピーディスクがベースだった。ハードディスク以前の時代だ）
だったので、言語環境に関してはいろいろあった時代だったような。
Pascal の p-code システム、COBOL の I-code システム、
N88-BASIC 上で動く Micro Prolog、Basic 上で動く FORTH 、
仮想マシン上で動く BCPL 、RATFOR 上で動く LISP （純 LISP だったか
LISP 1.5 だったか）だとか、「表現したいものがあったら、それ向きの言語を
自分で作っちゃえ！」という時代だった。
それを考えると、「オブジェクト志向」というのはインプリメント向けだし、
システム開発言語としてもそこそこ優秀だし、汎用言語としても
そこそこ使えるので、もっと「やんちゃ」な若手が出てくることを期待したい。
まぁ、ジジイに意見されても鬱陶しいだけだろうがな。 チンポはチンポ自身が本人とは独立した主体意思判断存在であり、
>>612
> それを考えると、「オブジェクト志向」というのはインプリメント向けだし、
繋がっているけれども独立している、まさにメッセージングとモジュールの両立こそがオブジェクト指向だ！
> システム開発言語としてもそこそこ優秀だし、汎用言語としても
> そこそこ使えるので、もっと「やんちゃ」な若手が出てくることを期待したい。
オシッコするときはメッセージング制御、勃起・射精するときはモジュール独立、この使い分けが大切！ >>611
> お前らマジで知的障害者のモノマネなんかやめろよ
×知的障害者
〇発達障礙者
×モノマネ
〇素（す）
少なくとも発達障礙者（高機能広汎性発達障害）である私は、
モノマネなんかしてないぞ。 >>613
若いなぁ。体力と勢いだけでコーディングしてた頃を思い出す。
>チンポはチンポ自身が本人とは独立した主体意思判断存在であり、
今はただ 小便だけの 道具かな
「製品」「納品」「納期」「コーディング規約」「周囲の人間のスキル」
とかいった要素に配慮しようと思うと、「オブジェクト志向」というのは
フラッグシップ的な役割があると思う。
組込み系で Z80 かなんかで独りでシコシコしているならともかく、
規模が大きくなってくると、「おれがおれが」とかいうのは
通用しにくいぞ？ クリントン大統領の『不適切な関係』についてたが、
>>528
> チンポでものを考える生物であってもチンポはシコシコしない
むしろクリントン大統領のほうが、自分のチンポにシコられてしまったとは考えられないだろうか？
> 何故ならチンポ自体にシコシコする機能が備わっていないからだ
『人格を性欲に乗っ取られる』、つまりクリントン大統領は、シコシコしたチンポに人格を乗っ取られてしまった！ >>615
本物なので、質問があったらどうぞ。スレ違いになるのでこのスレではなくて
別板の別スレに誘導していただけたらありがたい。
ちなみに、「IQ 70 未満」とか「IQ 130 越え」とかいうのは
「3σ 限界」を越えているので、「扱いに困る」とう点で「知的障害」と
呼称するのは必ずしも間違いではない。
平均的なプログラマの生産性の三倍とか八倍とか二十倍とかいった
ハッカーは、基本的に常人とは別枠で扱ったほうがいいと思う。
実際、IQ 70 未満で、「私、小学校の頃は『ちえおくれ』だったんですよ」
という凄腕プログラマを知っている。 『人形つかい』（1951）はSF小説の高度化と大衆化に貢献した巨匠ロバート・A・ハインラン初期の長篇作品で、
ナメクジのような謎の宇宙寄生生物と地球人との攻防を描いたもの。ナメクジに肩の後ろにとりつかれると、
宿主は知能や知識、経験もそのままに操り人形と化してしまう。ナメクジたちは自己増殖を繰り返して人から人
へとこっそり寄生を重ね、静かに地球侵略を進めていくが、この事態をいち早く察知した秘密機関のボス
「オールドマン」と有能な捜査官の「ぼく」、その同僚の謎めいた美女「メアリ」らがとにかくがんばる。
https://note.com/claris_ishinabe/n/n852bc519282c メッセージングを基礎単位として取ることは、より徹底的な遅延束縛を可能にする。というのも、
メッセージそれ自体は意味を持たず、実際にメッセージがオブジェクトに送信されてはじめて、意味が決まるからである。
https://qiita.com/ukyo-su/items/8c861f114809a96d1378
オシッコを出したり止めたりというのは、チンポから力を抜いたりチンポに力を入れたりと、
オシッコはオシッコそれ自体は意味を持たず、オシッコが尿道を介してチンポに送られることによって、
オシッコを出したり止めたりが可能になるということだ。 メッセージングに伴う遅延束縛とは、トイレでオシッコを出したり止めたりして、オシッコを遅延束縛すること。 論理的な話より、より深くオブジェクト指向というものがどういう動作なのかを取り扱おうとすれば、結局の所、
特定の言語の説明になってしまう。しかし、それでいいのだ。オブジェクト指向はこうあるべきと論じることこそが
無意味であり、各言語に合わせたオブジェクト指向の作法に従った方が有意義なのだ。
では、なぜオブジェクト指向で考えるのが良いのか？となる。オブジェクト指向とはデータ構造から関心を
分離すること、と最初の方で述べたが、それは確かに重要かも知れない。だが、私達が本当にしたかったことは、
人間の思考に近づけたかっただけだったのではないかと思う。
https://qiita.com/raccy/items/58254f842788707f8c53
オブジェクト指向とは自我とチンポを分離すること、オシッコするときと勃起・射精するときの違いを認識する。
繋がっているけれども独立している、チンポは随意筋であり不随意筋である、これがオブジェクトの多重継承だ。 この車は、タイヤがパンクしてしまった！
クリントン大統領は、チンポがシコシコしてしまった！ >>617
＞むしろクリントン大統領のほうが、自分のチンポにシコられてしまったとは考えられないだろうか？
それはちょっと雑過ぎ
チンポはあくまで「俺をシコれ！！」と発しているだけで、シコるのはあくまでクリントンの役割
＞『人格を性欲に乗っ取られる』、つまりクリントン大統領は、シコシコしたチンポに人格を乗っ取られてしまった！
人格は乗っ取られているかも知れないがそれはクリントンの状態変化であって
乗っ取られるという状態変化を起こしたクリントンがシコっていることに変わりはない
チンポ自体はシコられることはあってもシコシコすることはない >>607
キンタマはあくまで『委譲』先ね。オシッコするときはの参照先は膀胱だから、それとこれとは区別すべき。
オブジェクト指向はオブジェクトのメソッドごとに委譲先を変えることが大切。
オブジェクト指向プログラミングでは、具体的には以下の方法で委譲を実現します。
委譲を行うオブジェクトは、委譲先のオブジェクトへの参照を持つ
メッセージの応答を、参照を通じて委譲先のオブジェクトに委ねる
このような手法を用いることによって、他のさまざまなオブジェクトから必要な機能をピックアップして再利用
しつつ、独自の機能を持つ、新たなオブジェクトを作り出すことが可能になります。
https://codezine.jp/article/detail/3710 オシッコするときはチンポと膀胱が委譲合成、射精するときはチンポと睾丸が委譲合成、この使い分けが大切！ チンポや膀胱は、医学的には『不随意筋』だと？？？
ではオシッコを出したり止めたりは、どうして行うんだ？？？
クラスの「継承」より「合成」がよい理由とは？ゲーム開発におけるコードのフレキシビリティと可読性の向上
https://postd.cc/why-composition-is-often-better-than-inheritance/
オシッコの時は、チンポと膀胱が『オブジェクトの合成』により『随意筋』となる！
チンポはチンポだけでは不随意筋だけど、オシッコの時は膀胱との合成により、『随意筋』として振る舞う！ オブジェクト志向に関する議論において、
「シコシコ」という言葉を恣意的に使って
議論をまぜっかえすのはいかがなものだろうか。
麺類において「シコシコ」しているというのは、
「麺」オブジェクトの状態であって、
「シコシコする」「シコる」というのはメッセージングの
問題だ。
「チンポがシコシコした状態になっている」と
「チンポをシコシコする」は、別の話だ。
そこは分別しなければならない。
「饂飩を打つ」は、「麺をシコらせる」行為であって、
「饂飩を喰ったらシコシコしていた」は、また別の話だ。
そのあたりを明らかにしてもらおう。 外尿道括約筋は随意筋である？？？
では『尿道』は、チンポに含まれないのか？ チンポと尿道は別なのか？
尿道は随意筋だが、陰茎は不随意筋なのか？ 精液を漏らしてしまったとのことだが、これは『大統領命令』なのか？
>>626
> 乗っ取られるという状態変化を起こしたクリントンがシコっていることに変わりはない
シコシコしたチンポにシコられたクリントン、ということでは？ 違うか？ 大統領命令は？
1998年には、クリントンが大統領執務室でモニカ・ルインスキー（Monica Lewinsky）に
オーラルセックスをさせたことが発覚しましたが、このときも女権運動家およびリベラル派は、モニカを嘘つき呼ばわり
してクリントンを守りました。そして、クリントンの精液のシミがついたドレスをモニカが保管していることがわかり、
http://www.kenkyusha.co.jp/uploads/lingua/prt/18/gendai1805.html 西村ひろゆきの語るオブジェクト指向
https://youtu.be/I-p5ts6zk1g
『チンポがシコシコ』ってのと比べてどうだ？？？ >>596
> class チンポ｛
> super.不適切な関係;
> ｝
>
> クリントン
> ↑
> チンポ
class チンポ extends クリントン{
super.不適切な関係;
}
クリントンーーーーーーーーーー
┃ ┃
┃ ┃
┃ ┃
┃ ┃
┃ ┃
ーーーーーーーーーーーーーーー
┃ﾁﾝﾎﾟ┃
￣￣￣￣
『人格を性欲に乗っ取られる』、つまりクリントンはﾁﾝﾎﾟに人格を乗っ取られて、ﾁﾝﾎﾟにｼｺられてしまった！ 初心者板でも聞いたけどこっちの方が良さそうだからこっちでも質問させてください
データ型がクラスっていうのがどういうものかピンとこないから
わかりやすく解説おねがいします
例えばSystem.out.println();のSystemがクラスでoutは
SystemクラスのPrintStreamのクラスのデータ型を持つ
クラスフィールドの変数でそのクラスフィールド変数のprintln
メソッドを呼び出してるってのはわかるんだが
いまいちそのクラス型のデータってのがわかんないです >>637
https://www.google.com/search?lr=lang_ja&;ie=UTF-8&q=%E3%83%87%E3%83%BC%E3%82%BF%E5%9E%8B%E3%81%8C%E3%82%AF%E3%83%A9%E3%82%B9 >>637
質問が難解でちょっとわからんが説明を試みると、
Javaだと各変数や定数が必ず「型」を持つ
単に「型」という場合もあれば「データ型」と呼ぶ場合もあるけど基本的に同じ
クラスは「型」の一種、クラス以外にはインターフェースやプリミティブ(intやboolean)も「型」の一種
System.out.printlnは以下のFooクラスとBarクラスがある時にFoo.out.printlnを呼ぶのと同じイメージ
class Foo {
static Bar out;
}
class Bar {
public static void println(String text){
System.out.println(text);
}
} もう少し読める質問文書けるようになるまでほっとけばいいのに >>637
クラスはデータ型じゃない
構造体とか配列のほうが近い
分類できる仕組みを持ってるのがクラス >>640
>>642
ありがとうございます。
バカなので正直まだピンと来ているわけではないですが
答えてもらった内容を元にもう少し理解を深める勉強をします。 >>639
>>641
ネタじゃなくてガチガイジです
ここに質問するには学習進度的に早かったようなので出直します。。。 46 仕様書無しさん sage 2021/04/02(金) 19:08:29.69
>>45
お前じゃあ人クラス敬称してチンポクラスつくるのかよ
いいか、人クラスから赤ちゃんクラスつくってそれがもってるチンコフィールド、胸フィールド
に対する操作がそれぞれあるわけで、クラス内でフィールドに対する操作は好きに設定していいはずだ。
胸がドキドキ、チンポをシコシコがそれぞれのフィールドに設定されているんだから
それはその使い方が正しいとしか言えないわけだ
クラスと属性を一緒に考えようとするから
お前のような錯覚に陥ってしまうんでないか？ >>645
「人」クラスを継承するのはいいとして、
条件反射とか脊髄反射とかをどう扱うかという問題がある。
そういう意味では、オブジェクト志向というのは交絡（コンフリクト）の
可能性を完全には排除できない部分があるので、
けっこう憂鬱な概念ではある。 いや、そもそもあのチンポチンポ言ってた奴は
「人とチンポはそれぞれ独立した生き物」と言っていたから
生き物クラスをそれぞれ継承したクラスかも知れないし
is a 関係にすら無いかも知れない。
あの「シコシコ」というのも動詞か形容詞かハッキリしない
つまり
今の状態だと要件定義の時点で破綻しているように見える オブジェクト指向の長所の一つと言われている大規模プロジェクトでの適用だが
例示できないよな・・・ Nextstep(1986~)→macOSX(2001~)⇄iOS(2007~)
うまく行きすぎていまだにiOS開発のライブラリプリフィックスがNS~だらけだけど。 NHKの子供向け番組で、突然ど下ネタがぶっこまれる事案が発生「NHKから怒られる」「受信料払うことにした」
https://togetter.com/li/1075927 『体中が引き締まるような快感を感じた』、つまり『チンポがシコシコする』は『胸がドキドキする』と同じ！
>>647
> あの「シコシコ」というのも動詞か形容詞かハッキリしない
＜俺＞
「 部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
＜チンポ＞
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」 >>654
> ふーんガイジじゃん
ならそういうお前が、オブジェクト指向について分かりやすくかつ自分の言葉で語れよ！！！！ >>656
> だから動詞と形容詞どっちなんだよ
チンポ【が】(チンポ自身で自律的に)シコシコする、自『動詞』ね！ チンポ【が】(自律的に)シコシコしたということだが、
>シコシコしたチンポにシコられたクリントン、
『ムスコ』がシコシコしたのは、親の責任である！！
class チンポ extends クリントン{
super.不適切な関係;
} チンポはクリントンと繋がっており、チンポはクリントンそのものを『継承』しているということだ！
継承の元となるクラス（ここではPerson）をスーパークラス、継承して新しく作るクラス
（ここではStudent）をサブクラスと言います。 サブクラスのインスタンスはスーパークラスのメンバーに加え、
サブクラスで追加したメンバーを使うことができます。 継承の原語であるinheritance（インヘリタンス）
には遺産とか相続の意味があります。 継承とは、まさにスーパークラスの遺産をそっくり受け継いで、
最初から自分が持っていたかのように利用することです。
https://www.fujitsu.com/jp/group/fap/services/java-education/course/technology/java-cobol/07-inheritance/
まさにこの『ムスコ』は、クリントンの遺産を全て引き継ぎ、かつ独立してシコシコしてしまったのだ！ ガイジのくせに生意気じゃね？
なんでム板にこんなゴミみたいな書き込みしてんの？ ダイクストラの構造化プログラミングは、プログラムの大規模開発への道を開いたが、あくまで単一スレッド（single thread）計算機を前提としたトップダウン型開発方法であった。すなわち、プログラムのすべての機能は単線の計算プロセス上で実行する必要があり、たとえ甲と乙という汎用的な単機能を提供する検証済みのプログラムがそれぞれ独立に存在していても、両機能を実現するプログラムを作成するためには、ソースコードから該当機能部分を抜き出し、単線上に乗るように連接（concatenation）した上で、一つのプログラムとして正しく動作するように修正し、さらに再度検証しなければならない。
一方で、複数スレッド（multi thread）計算機においては、主プログラムから、甲と乙のプログラムなどの従プログラムをそれぞれ並列に実行させた上で、処理内容を従プログラムに（OSの機能などを仲介して）伝言受け渡し（message passing）して代わりに処理させることで、検証済みプログラムのソースコードに手を加えることなく、低コストで開発することができる（以下、これを第0世代オブジェクト指向プログラミング[独自研究?]と呼ぶ）[3]。
オーレ＝ヨハン・ダールとアントニー・ホーアは、この第0世代オブジェクト指向プログラミングのような考え方の有効性を主張し[4]、上記のような一連の操作を一つの言語の中で完結させるための機構を提案した。それがクラスの構文である。
ダールとホーアは、まず主プログラムから従プログラムを並列呼び出しする際、読み込みするにあたって新たに（new）割り当てられたメモリ領域に限定して走る計算プロセスを実例（instance；インスタンス）と名付け、さらにその実例の集まり（class of instances）をそれが記述されたソースコードと同一視した。その上で、呼び出されたときだけではなく、存在し続ける従プログラムの実例のもとになる手続きをクラス（class）、その実例を（「クラスの実例」ではなく）改めてクラスの対象（object）と名付けた[5]。さらに、その考えに基づいてSimula 67にクラスの構文を実装した[6]。 >>661
ならそういうお前が、プログラミング未経験者にも分かりやすく、オブジェクト指向とは何かを語れよ！！！ >>665
プログラミング未経験者がオブジェクト指向知る意味はない
おまえ毎日何やってんの？他にすること無いの？ よし単純に説明してみるぞ
Aさんが甲というちゃんと動作するプログラムを組みました。
Bさんは乙という同じくちゃんと動作するプログラムを組みました。
Cさんは甲の機能と乙の機能の２つを併せ持つ丙というプログラムを組むことにしました。
イチから作るのはめんどいのでCさんはAさんBさんからコードをそのままもらうことにしました。
ただ言語にクラスの機能もモジュールの機能も無いので、組み合わせるには変数名を衝突しないように変更しなければならず、条件分岐もやたら複雑になりました。
こんなときクラスの機能があれば変数名がリセットされて衝突しないのに‥ >>586
>そう考えるとチンポは自我の機能を保有していることになり
『ムスコ』は親クラスを継承し、かつ親クラスたるクリントンはその責任を負うのだぞ？
>クリントンの精液のシミがついたドレスをモニカが保管していることがわかり、
罪はチンポに責任はクリントンに、不適切な関係でした！ >>667
>イチから作るのはめんどいので
反復期間ごとに現実に動作し役に立つソフトウェアを提供することで、開発サイドとビジネスサイドが
「現物のソフトウェア」を介してコミュニケーションすることが可能となります。
共に現物を触れることで、開発サイドは即座にフィードバックを受けることができます。
ビジネスサイドは現物に（文字どおり）触発され、新たな要求やアイデアが湧き立ちます。
アジャイル開発は、要求の変化へ追従するだけではなく、新しい変化を自らもたらします。
https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/about-agile-01.html 基本情報技術者 H27年春 午前 【問48】 分類：システム開発技術
オブジェクト指向の考え方に基づくとき、一般に"自動車"のサブクラスといえるものはどれか。
ア エンジン
イ 製造番号
ウ タイヤ
エ トラック
http://itnavi.style-mods.net/question/fe27_1/fe27_1_48.htm
625 デフォルトの名無しさん 2021/04/08(木) 15:53:22.47 ID:I7qINfxA
この車は、タイヤがパンクしてしまった！
クリントン大統領は、チンポがシコシコしてしまった！ カテゴリ分別ということなら、クリントンとチンポの関係は、そのまま自動車とトラックには当てはまらない！
Carクラスには、フィールドとしてTyreオブジェクト(への参照)4つとEngineオブジェクト(への参照)
1つが定義されている。 つまり、CarオブジェクトはTyreオブジェクト4つとEngineオブジェクト1つを持つこと
になる。 これで「自動車が4つのタイヤと1つのエンジンを持っている」ということを表現できるのである。
http://www.rsch.tuis.ac.jp/~ohmi/software-intro/objectoriented.html
チンポは内部クラスにもサブクラスにも成り得るはずだ、違うか？
解答と解説
解答： エ
解説： オブジェクト指向
データを外部から隠ぺいし、メソッドと呼ばれる手続きによって間接的に操作することができる。プログラムは、データとメソッドをひとまとめにしたものの集まりである。
分類： テクノロジ系 ＞ 開発技術 ＞ システム開発技術 オシッコするときのチンポはインナークラス、勃起・射精するときのチンポはサブクラス、けれども自動車
のサブクラスはタイヤではなくてトラック、すると俺のオブジェクト指向理解は間違っていたのか？？？
だとすればチンポは随意筋なのか不随意筋なのか、どっちなんだ？？？
オシッコするときは随意筋で、射精するときは不随意筋って、どういう筋肉なんだ？？？ >>667
モジュールやネームスペースに相当する機能で十分なのでオブジェクト指向は必要ないねー しかしながらこういう時にチンポをクリントンのインナークラスにすると、
>>626
>人格は乗っ取られているかも知れないがそれはクリントンの状態変化であって
クリントンの『状態』をオブジェクトにしなければならなくなる。しかしながら、
>乗っ取られるという状態変化を起こしたクリントンがシコっていることに変わりはない
チンポ【が】シコシコして、シコシコしたチンポがクリントンをシコらせる、こう考えざるを得ない！
・・・・異論があるなら何なりと！
250 デフォルトの名無しさん sage 2021/03/21(日) 16:00:54.94 ID:rWfpUSZ4
状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質 オブジェクト指向には、インナークラスとサブクラスの２種類があって、
>"自動車"のサブクラス
『トラック』は独立した自動車として振る舞えるが、『タイヤ』はそうではない！
>クリントンの精液のシミがついたドレスをモニカが保管していることがわかり、
チンポは独立した主体存在であり、かつクリントンそのものとして振る舞える！
こ れ で 全 て の 謎 は 解 け た ！ ガイジって志村といっしょだよな
面白いの最初だけなのにくどいわ >>677
だから『オブジェクト指向』について、他にわかりやすい説明が有るのかって？？ >>675
＞「ボタンを押している状態」
＞をクラスにしてしまうと
＞プログラムが無茶無茶になる
ならないよ
というかゲーム作成では1画面書き換える前と
書き換えた後のボタンの状態をとっておいて
書き換え前と書き換え後の論理積を取ったもののビットが1ならボタン押しっぱなし、
書き換え前と書き換え後の排他的論理和に書き換え後の論理積を取ったもののビットが1の場合はボタン立ち上がり、
書き換え前と書き換え後の排他的論理和と書き換え前の論理積のビットが1だった場合はボタン立ち下がりという
シングルトンなクラスを持ってそれを見に行って各キャラクターの処理分けを行うなんて普通にあること。
何で上で書いたみたいに思っちゃったのかな？ >>679
それ「ボタンを押してる状態」をクラスにしてる？ >>680
そうだよ
これはあくまでベースで
更に格闘ゲームなんかだと
コマンド入力クラスの中で
これを使っている場合もある >>682
ならばオブジェクト指向とチンポ【が】シコシコとは、関係無いのか？ >>681
何がそうなのかよく分からない
>>679を読む限りではボタンの各状態をそれぞれクラスとして定義してるようには全く見えないんだけど？
書き換え前と書き換え後のボタンの状態を表現する各インスタンスをオペランドとして論理演算してるってことなの？
もしそうだとしたら何のためにボタンの各状態をわざわざクラスとして定義するのかわからない
stateパターン使って状態遷移を制御するんなら理解できるんだけど >>684
なんかここまで説明して分からない人にこれ以上説明するのは無駄な気がする
Object指向以前にコンピュータとはどういうものかもっと基礎的なことから勉強した方がいいと思う
恐らく掛け算のロジックを作れと言われたらそのまま掛けられる数の回数分だけ掛ける数をループして
足しこむようなロジックを作るタイプだな 「ボタンを押している状態をクラスにしてしまうとプログラムが無茶無茶になる」という主張に対する反論に
「ボタンを押している状態」をクラスにしてない例を持ってきても意味なくないかい？
何か意図があったのだろうか？ >>686
何を言ってるのか全く分からんけど
>>679はれっきとしたボタンが押されているか、今押されたのか、ボタンを離したのかの状態を監視するクラスだ。
それが読んで分からない人にそこから先の何が理解出来る？ ゲームみたいな例外をだしたって参考にならないんだがな
ゲームのボタンは押したらロボットに変形したりする 仮想コントローラークラスにして
コントローラオブジェクトとして扱ってるってことか >>688
別にゲームのボタンでなくてもいいよ
スマホとかのタブレットデバイスで
スライドするとそれに合わせてスクロール
したりするのも原理的には同じだ >>690
スマホとかの～ボタンだと
そういうのは予め用意されてる
何のフレームワーク・ライブラリの話をしてる？ >>691
そうだな
例えばスクロールする枠とスクロールを検知する枠が異なる場合、
通常のフレームワークだとそこまでやってくれない場合がある。
例えばWeb画面だと本来CSSだけでそれは出来ることだが
上記のような条件がつく場合、>>691だったらどうするよ？ さあさあ皆さん、チンポ【が】シコシコして参りました！ チンポがシコシコ君はいい加減に消えて欲しいが
「～が」の時点で主語(サブジェクト)だから、それはサブジェクト指向やぞ static変数を持つクラスを作ると
そのクラスに依存するクラスがたくさんできる
プロジェクト内で完結してるなら問題ない
そのかわり次のプロジェクトで使えないようなクラスが
たくさん残る
そういうことじゃ >>696
いつものじーさんか
んー、上のボタン制御のロジックに限って言ってしまうとボタン情報による状態変化を司るクラスを作っておいて
それだけ変えればいいように設計すればそこの変更だけで済むんだけど
Object指向のスレ的に言えば本来、開放閉鎖原則というのがあるからそれに関しては否定しないよ。 >>692
そういうのを作ればいいだけでは？
それとゲームのボタンとは全く違う >>699
＞そういうのを作ればいいだけでは？
＞それとゲームのボタンとは全く違う
そういうのをどう作るのか聞いている
そこに行き着く前に思考停止しているから
原理が同じことに気付けない >>700
だから既存のものはどうなってるかって聞いたんだよ
どれもゲームのようにはなってないだろ？
YAGNIって知ってるか？出来るかどうかの話はしてない。
必要ないのに無駄な汎用性をもたせるなという話
それともゲーム並みに無駄な汎用性をもたせるといい理由でもあるか？ ゲームが必要だから、それ以外でもゲームと同じようにするべき
という考えなら、それこそ思考停止 後輩「先輩」
先輩「何だ後輩」
後輩「すみません、画面スライドしたとき、スクロール範囲でないところでスクロールを検知させたいんですけど」
先輩「それで？」
後輩「CSSじゃ出来なそうなんです。どうすればいいですかね」
先輩「そう作ればいいだろ」
こんな感じで笑えたわw
流石に上司や客先にはやったらクビになるから
今度後輩にやってみよう 後輩「先輩」
先輩「何だ後輩」
後輩「すみません、画面スライドしたとき、スクロール範囲でないところでスクロールを検知させたいんですけど」
先輩「それなら全画面を透明のCSSで覆えばいいよ」
こんな話か？ｗ >>702
この話においてゲームの話はただのトリガーで
「ゲームのような特殊な」って言うから
比較的一般のものの話をしているんで
そんな心配しなくていいよ。
で、どう作るのかまだ回答を貰っていないんだが
どうすんの？コレ あれだな。見えているもがオブジェクト全てだと考えてしまうゲーム脳だなｗ >>705
スクロールする枠と、スクロールを検知する枠を別にすればいいだけ
それとボタンを押した状態を別のオブジェクトにする話と何が関係あるんだ？ 後輩「先輩」
先輩「なんだ後輩」
後輩「なんか画面がスクロールしなくなっちゃったんですけど」
先輩「いいから、出来るように作ればいいんだよ！！」
こんな感じ 後輩「○○で作れそうじゃないんですけど。どうすればいいですかね」
↑相談
先輩「そう作ればいいだろ」
↑無能
こういうのが報連相をぶち壊しにするんだよな
後輩が相談してるのに、その相談にのらない それでボタンを押した状態というのは
どれも状態としてボタンが持ってるのが普通なのに
なんでわざわざ別のオブジェクトにするんですか？
まだ答えもらってないよ 答えに詰まったようだねｗ
ゲームのボタンっていうのはキャラクターの一種なんだわ
例えばマリオだとPスイッチは、押したら潰れて消える
持って投げられる。ベルトコンベアやバネの上で動く。
壁として障害物になる。
そういうのとUIのボタンを一緒にするのは抽象化能力が低い
ボタンという名前だから同じものだと考えてしまっている
ゲームのボタン（キャラクター）を持ち出して
UIまでキャラクターにするのはアホ >>710
え？何？そこから？
なら画面が動いている最中に
ボタンが押されたばかりか離されたか
押しっぱなしか押してないかどう検知するんだよ？
まさかボタンのイベント括り付けて常に拾うつもり？ >>712
常にイベント拾う必要ないだろ
ボタンが押された・・・onPressイベント
押しっぱなし・・・そのまま何もイベントが発生しない
ボタンが話された・・・onReleaseイベント
こんなとこだろ そもそもフレーム単位で描画処理するというのがゲームの発想なわけで
普通のUIはそんなことはしない。
やっぱり理解できてないとしか言うしかないな
マジのゲーム脳だなｗ >>711
＞ゲームのボタンっていうのはキャラクターの一種なんだわ
ちょっと何言ってるか分かりませんね
十字キーやABボタンがキャラクター？
あれって勝手に外れて動き出すの？
・・・狂った？
>>714
＞そもそもフレーム単位で描画処理するというのがゲームの発想なわけで
お前、スマホとかの開発出来ねーな >>715
十字キーやABボタンの話をしてたのか？
それもう現実世界のもので
ソフトウェアのオブジェクトじゃないじゃん
お前何言ってるの？
それに「オブジェクトを押した状態」をクラスにするのが
アホ設計って話をしてるよね
つまり、お前のABボタンは、押すと別のオブジェクトに変わるんか？
>>715
> お前、スマホとかの開発出来ねーな
やっぱり反論できなくなったら遠吠え DA・YO・NE☆ >>716
いいか？
ボタンをクラスにするのではない
「ボタンの状況」を把握するクラスを作ること
それが最初から言われている大条件だが
日本語苦手なのかな？
で、俺はスマホでスクロールの話をしたとき
お前は「原理は全く別のもの」と吹っかけた
では原理的に何がどう違うのか説明して貰おう
否定すると言うことは当然理解もしているし
こうだから違うと言うことを自分が
理解していて説明出来るからという解釈でいいんだよな？ >>717
話をすり替えるな
>>675
＞「ボタンを押している状態」
＞をクラスにしてしまうと
＞プログラムが無茶無茶になる 680 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/10(土) 18:35:00.78 ID:edMGid1M [2/4]
>>679
それ「ボタンを押してる状態」をクラスにしてる？
681 名前：デフォルトの名無しさん[] 投稿日：2021/04/10(土) 18:52:25.48 ID:GLiDRYw8 [2/6]
>>680
そうだよ 「ボタンの状況」を把握するクラスっていうのも意味不明なんだよな
イベントドリブンをしらないのか？
ボタンは状況が変わればそれをイベントとして通知する
それはハードウェアやドライバレベルで処理する話なの
いちいちフレーム単位でボタンの状況を
スキャンしたりしないの >>718
何もすり替えていない。
「ボタンを押している状態」のクラスを作ることだろ？
ボタンが別のオブジェクトになるとか
さっきから何の話をしているんだ？
俺からするとお前の方が回答したくなくて
話を逸らしているように見えるんだが？
なぁ、早く答えてくれよ > 「ボタンを押している状態」をクラスにする
> 「ボタンの状況」を把握するクラスを作ること
この２つが区別つかないようじゃ話にならんなｗ >>722
「ボタンの押している状態」
「ボタンの押している状況」
「ボタンの状況」
俺からすれば言葉遊びのように見えるが
では何がどう違うのか説明してくれ > 「ボタンを押している状態」をクラス
ButtonPressedClass
> 「ボタンの状況」を把握するクラスを作ること
ButtonStateScannerClass
ぜんぜん違うだろ >>724
馬鹿か？
ボタンのイベント処理そのものをクラスにするなんて常識としてあり得ないだろ？
そういう言葉遊びはもう沢山だから
キチンとボタンの状態を管理する話から話を逸らすなよ。
で、スクロールの件は？早く答えてくれよ。 > ボタンのイベント処理そのものをクラスにするなんて常識としてあり得ないだろ？
誰もそんな話はしてない
どこをみて「ボタンのイベント処理そのものをクラス」と
書いてあると思ったのか？
そして>>724へのレスはなし。
都合の悪いレスは無視して違う話を始めるｗ >>726
>>724ぬ対してのレスは見えなかったことになってるのか
ButtonPressedClassって
どう見てもボタン押下しましたクラスだが
それはボタンを押下したイベントを司るクラスでないなら何のクラスなんだ？
こっちからしてみるとそっちの言ってることはさっきから支離滅裂なことにしか見えないんだが？ > どう見てもボタン押下しましたクラスだが
> それはボタンを押下したイベントを司るクラスでないなら何のクラスなんだ？
ボタンが押された状態のクラスだろ
なんでもう押されてしまった状態なのに
ボタンを押すイベントを司らなければならないのか
ボタンを押すイベントが発生した後のクラスだろうに
はぁ英語も通じないのか・・・ >>728
そのボタンが押された後に発生したクラスで何をやっているのか？
押された後の状態管理で有れば>>724で言っている下のクラスとは何が違うのか？ チンポという主体意思決定存在(サブジェクト)を、オブジェクト指向で表現するということなんだが？
>>695
>「～が」の時点で主語(サブジェクト)だから、それはサブジェクト指向やぞ
カンタンに表記すれば、
Subject = 法則,
Object = (法則によって規定される)集団
になるんでしょう。
これをコンピュータのプログラミングに当てはめると、
Subject = コンピュータの処理方法,
Object = プログラマが設定可能な部分
になるんではないかと。
https://note.com/nephews_tech/n/n02380a2cc0e3 >>729
> そのボタンが押された後に発生したクラスで何をやっているのか？
>>716より
> それに「オブジェクトを押した状態」をクラスにするのが
> アホ設計って話をしてるよね
「ボタンが押された後に発生したクラス」なんてのを
作るのがアホと言ってる俺に聞くなアホ > >>724で言っている下のクラスとは何が違うのか？
それはお前が「ボタンを押してる状態のクラス」と聞いて
「ボタンの押してる状態を把握するを把握するクラス」と勘違いしたものだろ
お前が想像で作り出したものなんか知らんわ >>718
ここで話を本質に戻すと、もしチンポをクリントンのインナークラスとして固定してしまうと、
>>626
>人格は乗っ取られているかも知れないがそれはクリントンの状態変化であって
『チンポに人格を乗っ取られた【状態】のクリントン』を【再定義】【継承】が不可欠ということだ！ >>731
なんだ結局>>724で言ってたものの上下は
言葉を変えただけの言葉遊びか >>732
まぁいいや何が言いたかったかは大体分かった。
後はスクロールの件だけ答えてくれればいいや。 >>734
どこを読んで言葉遊びだと思ったの？
全く違うものであるといったよね？
「どこを読んで同じものだと思ったの？」
次のレスはそれだけ言えばいいよｗ > 後はスクロールの件だけ答えてくれればいいや。
すでに返答済み >>736
結局ボタンを押した後に行うのは
それに対しどう状況が変化するのか
管理するものへの設定だけだろ？
名前が違うだけでやることは同じだからな
だから言葉遊びと言ったんだ。
>既に回答済み
ああ、あの「そのように作ればいい」ってやつね。
はいはい オブジェクトの更新処理
一般にゲームは、時間の経過とともに状態が変化します。
その時間経過による状態の更新を、BattleクラスのUpdate()メソッドで処理することとします。
そして、BattleクラスのUpdate()の中で、各BattleObjectのUpdate()を呼びます。
https://developer.aiming-inc.com/programming/design-battle-program/ バトル通信ラグ軽減のための「武器持ち替え廃止論」コメント 1件
アイミョン
[KS108-054]
テーマ：バトル2020/09/20 15:47
https://hiroba.dqx.jp/sc/forum/pastthread/413734/
>現在できている操作ができなくなってしまう可能性もあるため
武器持ち替えは操作が無駄に多くなるし行動ターンを浪費するので、無くしてしまっても問題無いと思います。
https://i.imgur.com/U4jgmc3.png >>739
お、いつもチンポチンポ言ってるけど
こういうのの反応は早いのね。
ちょっと見直したよ。
ちょっとC++は忘れたけど時間経過と言うか
確か走査線が一画面分走ったときに起る
VSYNC割込みが使えたんじゃなかったかなー
まぁその辺の単位で処理しているのは違いないよ
ネットでの他者との同期は俺もそこまで詳しくないけど
他のPCとの同期は2台だけでもかなりややこしかったからね
後で色々起きるのも理解出来るよ。 状態変化といっても、オシッコするときのチンポはインナークラス、勃起・射精するときのチンポはサブクラス。
>BattleクラスのUpdate()メソッドで処理することとします。
オンラインゲームのバトルはごくシンプルに、同一人格の状態変化はインナークラスが良い。
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 君たち日曜の朝からなにやってんのwww
>>687
とりあえず「状態をクラスにする」の意味が分かってないことは良くわかった
誰も問題にしてないことに対して頑張って反論してたわけね >>743
まぁお前はその入口にすら立てていないことも解ったけどな >スクロールする枠とスクロールを検知する枠が異なる場合
検知するというのがスクロールイベント自体を作成することを言ってるのか
それともスクロールイベントをハンドリングすることを言ってるのかわからないな
前者ならスクロールされた枠がスクロールイベントを発行すればいいだけなのに
別のところでスクロールされた枠用のイベントを発行する意味がわからない
後者ならごく一般的なことなので何を問題にしてるかがわからない
とかいっても無駄かな >>745
というかお前はまずスマホのタッチとかスライドとかどうなってんのとか、
昨日も言ったけどコンピュータとは何か、から勉強しような。
自分の後輩なら手取り足取り教えるけど
スクロールイベントがどうのなんて言ってる時点で本質が全く見えていないのミエミエだから 話続きだったな
自分の後輩なら手取り足取り教えるけど
そんな義理は全くないから。
ましてや質問者じゃなくて教える立場として
このスレに来ているなら尚更。 ボタンが押されたか離されたかってのはともかく、
>>712
>なら画面が動いている最中に
>ボタンが押されたばかりか離されたか
押しっぱなしか押してないかどう検知するんだよ？
オンラインゲームでバトルキャラが死んだか否かってことでの『死亡ラグ』は珍しく無いぞ？
他のプレイヤー視点では既に倒れている。しかし、遅れているので自分では分からないためいきなり何も
ないところで死ぬ。また、デスマッチなどでは既に死んでいるため、自分が動けてもリスポンされていたり
して無敵時間が無くなり、復活した瞬間に倒されることもある。
自分がいつ死んでいるのか分からず突然死んで突然画面が切り替わってしまう。その結果キルログを注視してしまいゲームを楽しめなくなってくる。
https://gamingpcs.jp/knowledge/kankyou/kaisenhuguai/ オシッコを出している状態と、オシッコを止めている状態、インナークラスのメッセージング処理だなw
724 デフォルトの名無しさん sage 2021/04/11(日) 08:28:12.36 ID:CjAFb9gH
> 「ボタンを押している状態」をクラス
ButtonPressedClass
> 「ボタンの状況」を把握するクラスを作ること
ButtonStateScannerClass
ぜんぜん違うだろ
250 デフォルトの名無しさん sage 2021/03/21(日) 16:00:54.94 ID:rWfpUSZ4
状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質 さっきトイレでオシッコを出したり止めたりしていたが、
>オンラインゲームでバトルキャラが死んだか否かってことでの『死亡ラグ』は珍しく無いぞ？
オシッコを出したり止めたりするのに、脳とチンポで『通信ラグ』を感じたのは、自分だけたろうか？？？ インナークラスを用いたメッセージングによる状態操作、イベントドリブンによる割り込み処理と通信ラグ、
それはトイレでオシッコを出したり止めたりして、脳とチンポで必ずしも『同期』が取れるかという問題だ。
728 デフォルトの名無しさん sage 2021/04/11(日) 08:50:34.59 ID:CjAFb9gH
> どう見てもボタン押下しましたクラスだが
> それはボタンを押下したイベントを司るクラスでないなら何のクラスなんだ？
ボタンが押された状態のクラスだろ
なんでもう押されてしまった状態なのに
ボタンを押すイベントを司らなければならないのか
ボタンを押すイベントが発生した後のクラスだろうに
はぁ英語も通じないのか・・・ プログラミング言語の性能差
主な言語とスループット
言語 スループット 特性 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
オンラインゲームでは『メッセージング』なんて当たり前なのに、いつの時代の話をしているのかな？
701 デフォルトの名無しさん sage 2021/04/11(日) 07:11:59.27 ID:CjAFb9gH
>>700
だから既存のものはどうなってるかって聞いたんだよ
どれもゲームのようにはなってないだろ？
YAGNIって知ってるか？出来るかどうかの話はしてない。
必要ないのに無駄な汎用性をもたせるなという話
それともゲーム並みに無駄な汎用性をもたせるといい理由でもあるか？ オブジェクト指向には、大きく分けて２種類ある。
1 インナークラス(オシッコをするときのチンポ)
ネットワーク、メッセージング、イベントドリブン、同期処理・・・
2 サブクラス(勃起・射精するときのチンポ)
自然言語処理、人工知能・・・
世界初のパーソナルコンピュータであるApple Iと、キーボードやメモリ、CPU、画像出力装置、外部記憶装置、
音声出力装置とのインターフェース、プログラム言語などのオールインワンパッケージ化を可能にした
最初のコンピュータであるApple IIの開発を１人で成し遂げたのもスティーブ・ウォズニアックです。
https://engineer-shukatu.jp/column/archives/26603
↑
インターネットも人工知能も無い1980年代のプログラミングは、いかにメモリを節約するかということだった。
演算処理をいかに早く正確に行うかが全てであって、オブジェクト指向がどうこうという議論は無かったはずだ。
近年のオブジェクト指向を意識したシステム開発は、インターネットと人工知能が背景にあり、従って、
チンポ【が】シコシコするという、新しい言語パラダイムが求められているということだ。 >>748
> 押しっぱなしか押してないかどう検知するんだよ？
>
> オンラインゲームでバトルキャラが死んだか否かってことでの『死亡ラグ』は珍しく無いぞ？
だからお前はゲーム脳（ゲームの設計しか知らない）だと言ってる
フレーム単位でボタンの状態をスキャンするなんてことは
普通のアプリではしないんだよ
そもそもな、フレーム（1/60）ごとに発生するイベントが存在しない
お前は1/60ごとに描画しなきゃならないと思ってるんだろうが、そんなことをするのはゲームだけ
普通は何もイベントが発生しない限り変化がない
ボタンは押したときと離したときにイベントが発生する
それに応じて処理をするのがイベントドリブン
押しっぱなしは普通キーリピートとして、何度も押したというイベントが発生するのが普通のUI
それじゃゲームには役に立たない！っていいたいんだろう？ゲーム脳だからゲームに役に立たない！としか言わんわけだ
普通のUIで押しっぱなしの状態で何かを変化させる必要があれば
そのときにタイマーイベントを設置する。
ゲーム脳のお前は、このタイマーイベントがあるという前提でしか物事を考えられないんだろうが
普通のUIじゃそんなの追加機能だ
そして押しっぱなしの状態を検知したいんだったな？
ボタンオブジェクトは自身に押されたか押されてないかの状態を示すステータスフラグを持ってる
（なければそういうステータスフラグを作って、ボタンが押された・離されたときにフラグを更新するだけ）
そしてタイマーイベントからそのステータスを見るだけだ >>710
むかーし、スマートフォンアプリ(Java/Objective-Cベース)開発初期に
ケータイやWebアプリ(flashベース)の人が来て質問してきた時に
スマホ側は「ボタン自体がタッチイベントなどの属性持ってる」前提で話してるのに
ケータイflashの人が「画面へのタッチをトリガーに
if文で矩型の範囲設定してどこを触ったか？で条件分岐させよう」としてて
噛み合わなさに苦笑したの思い出した。 高橋名人だっけ？
1秒間に、18回クリックできた人
確か、これがこの当時の限界のはず >>754
つまり君の言い分はこうだ
「ぼくのさいきょうのおぶじぇくとしこう(ただしげーむやすまほではつかえません)」
つまり時間による状態変化にはついて行けないということだ。
別にタイマーみてボタン押下のイベントを見るのは構わないが、ひと処理がタイマー期間に間に合わず、次の期間にもなだれこむ場合、
ひとつの処理の中で複数回のボタン読み込み処理が発生する場合があり、それだけだと正確なボタン検知が出来なくなるし
それ用の処理をそのために作るのも大変だしな
作るとしてもそれを含めて
結局正しいボタン情報を監視、制御するクラスはそういう役割として持たせておくと楽だろう
それとあの後一生懸命勉強したのだろうが、フレーム(1/60秒)と書いてあるがfpsという言葉を知っているか？
身に付けたばかりの知識はひけらかすと恥をかくから気をつけた方がいいぞ
後、プログラマーのゲーム脳というのは
少なくとも君の語る最強のオブジェクト指向のようなカタワではないから褒め言葉として受け止めておくよ
それと人が居なくなった頃を見計らって書き込むのはいいが、
いくら俺が怖いからって他の誰かれ構わす他噛みつくのはみっともないな
後でチンポさんに謝っておけよ >>757
> 別にタイマーみてボタン押下のイベントを見るのは構わないが、ひと処理がタイマー期間に間に合わず、次の期間にもなだれこむ場合、
コマ落ちでもすりゃいいじゃん。なにか問題でも？
やっぱりゲームのことしか考えてないよね >>757
お前はイベントドリブンっていうのを知ったほうがいいよ
今の主流の開発手法。ブラウザなんかもイベントドリブンで処理する
マウスクリック、キーボード入力、タッチ、などなど
それぞれのイベントが発生し、そのイベントの中で処理を行う
それらのイベントが発生しない間に、常にボタンを監視するなんてことはしない ？？？
>>754
>押しっぱなしは普通キーリピートとして、何度も押したというイベントが発生するのが普通のUI
756 デフォルトの名無しさん sage 2021/04/11(日) 21:18:16.23 ID:LXnW0jT4
高橋名人だっけ？
1秒間に、18回クリックできた人
確か、これがこの当時の限界のはず イベントドリブンは省エネ
メインループをずっと繰り返すというのはアンチパターン
特にスマホなんかだと、そんな事するとあっという間にバッテリーが無くなる >>760
イベント知ってるからこそ
そこの落とし穴も知ってて
>>757のようなことを書いてるんだけどなー
まぁ処理落ちのことをコマ落ちとかいったり
そうした場合の処理が結構大変なのを
知らないというのも幸せなんだろうなー >>763
だからその落とし穴ーをお前が説明した途端
ああ、やっぱりゲームのことしか考えてないよねって思ったわけだ >>764
いんや別にゲームでなくても
画面にボタン操作が入って時間経過の概念があるものは何でもそうだよ
そうであれ、なかれ
きみの言うさいきょうのおぶじぇくとしこうではそれに対応出来ないってだけ イベント連携機能では、発生する『イベント』と、イベントを検知したときにどう振る舞うかといった
『アクション』を事前に登録していただければ、『イベント』の発生を監視し、イベントの発生を検知したら、
事前に登録されている『アクション』を自動実行することができます。
http://a-auto50.blogspot.com/2014/11/blog-post.html?m=1
760 デフォルトの名無しさん sage 2021/04/12(月) 09:15:25.81 ID:yZXPyOt1
>>757
お前はイベントドリブンっていうのを知ったほうがいいよ
今の主流の開発手法。ブラウザなんかもイベントドリブンで処理する
マウスクリック、キーボード入力、タッチ、などなど
それぞれのイベントが発生し、そのイベントの中で処理を行う
それらのイベントが発生しない間に、常にボタンを監視するなんてことはしない >>766
うーん、リンク先見たけど
リアクティブプログラミングの話かな？
だとしたらカタワ指向君にはまだ早いし
自信損失に繋がるからやめたげて 左側の太い線で書いたループはイベントループと呼ばれ、発生するイベントを常に監視しています。そして、
ユーザがマウスを押したり、キーを押したりして何らかのイベントが発生すると、それに対応する処理を呼び
出します。各処理は自分の仕事が終わると再びイベントループに戻り、次のイベントを監視します。
http://www.ics.kagoshima-u.ac.jp/edu/ProgramingJava/Event/top.html
762 デフォルトの名無しさん sage 2021/04/12(月) 09:17:17.08 ID:yZXPyOt1
イベントドリブンは省エネ
メインループをずっと繰り返すというのはアンチパターン
特にスマホなんかだと、そんな事するとあっという間にバッテリーが無くなる >>768
これは比較的俺が言っていたのに似ているね
まぁ普通のアプリの場合(何を持って普通というのかはアレだけども)、
あんまし画面描写関係ないなら
処理単位でのループだし、さっき言った落とし穴にもはまらないからいいと思うよ チンポから力を抜く、チンポに力を入れるという体内の『イベント』により、
>『アクション』を事前に登録していただければ、『イベント』の発生を監視し
オシッコを出す、オシッコを止めるという体外の『アクション』に繋げられる！
・・・我流なので、異論があれば何なりと！ >>765
> 画面にボタン操作が入って時間経過の概念があっても
そこじゃない
> 処理がタイマー期間に間に合わず、次の期間にもなだれこむ場合
を気にしないといけないのがゲームぐらいしかない >>768
> 左側の太い線で書いたループはイベントループと呼ばれ、発生するイベントを常に監視しています。
メインループとイベントループをごっちゃにするな
イベントループはイベント（マウスボタン押下など）が発生しない限り何もせず休んでいる
ゲームのメインループは、一定間でボタンの状態をスキャンしている
全く別のものだ しかもそこに書いているな
> 左側の太い線で書いたループはイベントループと呼ばれ、発生するイベントを常に監視しています。
> そして、ユーザがマウスを押したり、キーを押したりして何らかのイベントが発生すると、それに対応する処理を呼び出します。
> 各処理は自分の仕事が終わると再びイベントループに戻り、次のイベントを監視します。
ユーザがマウスを押したり、キーを押したりして何らかのイベントが発生すると、それに対応する処理を呼び出します。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> GUI部品に対してのこれらのイベントを自分で処理する必要はほとんどありません。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> マウスやキーボードを自分で処理する必要があるのは、アプレットやキャンバス上で発生したイベントについてだけです。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>771
さっきも書いたけど、
そうであれ、なかれ
君のカタワ指向では対応出来ないってだけ >>767
> リアクティブプログラミングの話かな？
ぜんぜん違う。
リアクティブプログラミングはマウス等のイベントの発生をきっかけに
処理がすすんでいく（マウス等のイベントに対してイベントハンドラを設定する）
ゲーム脳が言ってるやつは、マウスのイベントではなく一定時間ごとに
自分でマウスの状態をスキャンする。タイマーがイベントとも言えるが
普通のUIはタイマーをイベントにしない。
マウスのイベントをトリガーとすればマウス操作で即座に反応できるが
しかしタイマーをイベントとしてマウスの状態をスキャンする場合
即座に反応させるためには、短い間隔のタイマーを設置しなければいけない
しかも精度の高いリアルタイムタイマーでなければならない
リアクティブプログラミングでリアルタイムタイマーをサポートしているライブラリは
おそらくないだろう。だからゲームではリアクティブプログラミングは使えず
イベントドリブンではない旧来のメインループを使うという特殊なプログラム技法を使っている
完全に概念が別なんだわ。 >>774
> さっきも書いたけど、
> そうであれ、なかれ
> 君のカタワ指向では対応出来ないってだけ
書いてないよ。ただお前が主張してるだけで
その根拠が全く書かれていない イベントと状態を区別して整理できてないから落とし穴にハマってるだけだな
結局オブジェクト指向とは関係ない 参考と言えるほどのものではないが
ゲーム開発と一般的なアプリケーション開発の違いについて
https://qiita.com/sawasaka/items/288c745b48328e76ca66#%E3%81%AA%E3%81%9C%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%AB%E3%83%BC%E3%83%97%E3%82%92%E4%BD%9C%E3%82%8B%E3%81%8B
決定的な違い
一般的なアプリケーションはイベント駆動型で
ボタンを押したり、メニューを選択した時などのアクションが発生した際に処理を行う。
ゲームは終了するまで永久に回り続けるメインループを作り
ループ内でアクションの発生を確認し、それに応じて処理を行う。 >>776
横からだが、イベントってのはそもそも言語やフレームワークやOSの機能だから、まずはそこを定義してないから話が噛み合わないんじゃないのか？
低レベルの部分ではハードウェア割り込みやポーリングは必要だし、キーバッファだってあるわけだから、組み込み系だったりそういうレベルでコーディングしてる人からしたらイメージしにくいのかも >>780
言語、フレームワーク、OS、いずれにしろイベントというのは
イベントが発生したときに、そのイベントに対応する処理を書くという点では一緒
ゲームのメインループはイベントを使わず、（以下>>779） >>780
折角書いたのにね
恐らく割込みというのを知らないんだよ
ちょっとアレな人だから許してあげてね ？
>>772
>イベントループはイベント（マウスボタン押下など）が発生しない限り何もせず休んでいる
プログラムは，イベントに対する処理内容をコールバック関数で動作した後，イベントループと呼ばれる無限ループに動作が移る
この無限ループで，イベントの監視と，それに対応する処理を永遠行う
https://qiita.com/twipg/items/8f2a00354f6159cd1a5a >>783
そこに書いてあんだろｗ
> イベントループ
> イベントを待機するループを持つ仕組み >>782
割り込みとイベントは似てるようで違う
割り込みは他の割り込みをブロックしないように短時間でその処理を終えなければいけない
イベントはそうではない。時間がかかる処理を行ってもいい。
その間に割り込みがブロックされることはない。処理するレイヤーが全く違っている。 動作アプリと静止アプリという程度の違いと思われるが、
>>779
>ゲーム開発と一般的なアプリケーション開発の違いについて
調査機関IBISWorldの調査によれば、企業がERPソフトウエアに支払う費用は2012年以来、1年につきほぼ
2パーセント減少してきています。同社は、顧客が今日ERPのソフトウエア・ライセンスに支払うと予測される
平均価格は1ユーザー、1年について約$1,911と言います。さらに、この先3年間、ERPソフトウエアの価格にプレッシャーが
掛かり続けて下落し、2018年迄に年間ライセンス料は1ユーザーにつき平均$1,800まで下がると予測しています。
https://www.e-bellnet.com/category/jungle/1512/1512-829.html
↑
ワードやエクセルも含めて、事務処理用の静止アプリは、年々衰退しつつあるのでは？ スゲーな
俺も含めてだけど
ゲーム脳指向
チンポシコシコ指向
カタワ指向と
基地外がよりどりみどりだわw >>786
> 年々衰退しつつあるのでは？
質問スレでしろ https://youtu.be/08W9VWUdkjI
NHKの子供向け番組で、突然ど下ネタがぶっこまれる事案が発生「NHKから怒られる」「受信料払うことにした」
https://togetter.com/li/1075927
>>631
>オブジェクト志向に関する議論において、
>「シコシコ」という言葉を恣意的に使って
『シコシコシコシコしこランド！』って、問題になったらしいぞ？ >>786
Switchや新型XBOXの売れ行きが好調なのと
スマホのソーシャルゲーム系がそこそこ行けてるからね
家電量販店辺り行くとLiteでないSwitch、XBOXのXシリーズ辺りは慢性的に品切れだよ
PS5はたまに売ってるけど、それでもこれも慢性的に品切れと言えるね
ただPS5は逆鞘なのでソフトが出ないと売れれば売れるほど損失が出るからソフトが揃うの待ち
CS業界ではSwitchが出てからずっと好調かな
カタワ指向君が言う通りゲーム脳だからこのくらいのことは即答出来るよ 令和のコペルニクス
https://youtu.be/7DbdPKWhrpY
自作プログラミング、ソースコードと解説付き！！！ ゲーム脳というが、ゲームに例えるとプログラミングがわかりやすくなる！
静的変数(コンティニュー可)
例 ドラゴンクエスト
自動変数(コンティニュー不可)
例 テトリス オブジェクト指向と関係ない話を始めた理由は、みなさんわかりますよね？ｗ なんかよくわかってないというかそもそもスマホの“OS”レベルの動作から知らない人がいるっぽいんだけど
iOSなんかはWindowsCEとかのクソ遅いアプリレスポンスを反面教師として設計されたから
OSが画面タッチをOSの最優先処理として監視しているので毎秒何フレームとかいうレベルじゃなくて
触れた瞬間に最優先割り込みが起動して、画面のその場所のパーツレイヤーに重ね順番に沿って即座に
「この場所のオブジェクト！タッチイベントに反応できる？する？」ってリクエストが飛ぶ仕組みなんだけど…
全画面をスプライトとか扱うゲームキットレイヤで覆えば
ゲームキット側で「オーケーあとはうちで」ともできるし
可視、不可視ボタンオブジェクト置いといてそっちでイベントフックしてもいいし
それはアプリ設計側の自由だし。
また、逆に「割り込み」ってCPUレベルの機能知らないなら書いておくけど
「割り込み」はメインループが回ってようがリクエストが来た瞬間に
メイン処理を棚上げにして、割り込みで割り当てられた処理を優先するハードウェア機能ね。
アプリどころかOSの処理に画面タッチ関連が最優先割り込み指定されてるの。 >>796
わかってないのはお前でどのOSもタッチとか割り込みで処理されてるの
ゲームが例外でタッチが割り込みで処理されてるにもかからわず
毎秒何フレームのポーリングで処理するんだよ
そもそも毎秒何フレームとかいう考え方自体がゲーム特有で
1秒間に何回も画面を書き換えてるの（もちろん工夫して書き換える量を減らしてる）
その書き換えのタイミングで（割り込み）ではなくタッチの状態をスキャンしてるんだよ
ゲームは基本的に何も触らなくても画面が書き換わるし
割り込みが発生時でやる処理によってタイミングがずれるのは困るから
割り込みで正確にタイミングを測るのが難しい。だからOSやハードウェアでは
割り込みを持っていたとしても、それを使わない（正確に言えば状態を更新するだけ）で
あと毎秒何フレームのメインループで処理するんだよ 割り込みはデバイスドライバがやるので
その情報は漏れなくOSに伝わってる
格闘ゲームとかコントローラの操作で入力が
反映されないのは何かの性能が悪いから
ネットゲームはメインのプログラムがサーバー上にあるので
それの作り次第
たくさん人がいると本当のリアルタイムのような
ことは難しくなる >>798
そういう話じゃないんだよね。
割り込み（イベント）はメインの処理をしてるときに割り込まれてくるだから割り込み
ゲームに置いてメインの処理として画面描画を行っている
このときに割り込みが入って、そこですぐにプレイキャラを動かしたりしたら問題があるんだよ
例えばプレイヤーが連射なんかしたら、割り込みが入る分、画面描画が遅れてしまう
割り込みのほうが優先だからね
だから逆に画面描画のタイミングでバランスを取って、そのタイミングでボタンが押されていれば
それに応じた処理をするという設計になってる OSが無い大昔のPCゲーやアーケードでもなきゃ
OSが割り込み取ってゲームキットに伝えてるってのに
そのOSからの「いま入力来たで！」を非同期的に受け取ってるアプリ側から
「ゲームアプリはフレームごとにメインループ処理してんだよ」って…
あの…別にゲームは30とか60とかそんな「遅い」反応しなくてもいいんですよ？ >>796
ふーんスマホではタッチが最優先割込みになるんだ
たださっきメインループとか雑な説明のリンクをカタワ指向君が貼っててそういうもんだとみんな錯覚しているかも知れないけど、
そういう仕組みにすることもあればタイマで起動時間を区切ってその間隔単位で処理することもあれば
画面上を走査線が走り終わったタイミングの割込みを見ることもあるんだよ。
上の二つはともかく、走査線の割込みについては
俺はてっきり画面系の割込みが最優先だと思ってて
まぁハードウェアによってそういうこともあるのかなと思ってちょっと調べてみたけど
https://ja.m.wikipedia.org/wiki/割り込み_(コンピュータ)
これ見てるとやっぱり走査線の割込みが優先順位高いみたいだね。
IiPgone辺りはCPU、ARMじゃなかったっけ？
まぁスマホという枠を外れればキー割込み自体が存在しないハードがあることも考えればそれも納得なんだけれどね。
まぁメインループとか言ってる方式は言わずもがな、タイマによる割込みはソフトウェア割込みだからそこではタッチ割り込みが優先されるよ
ドンマイ！ ゲームプログラムが割り込み受ける仕組みがあるのか
それは知らなかったな
何というクラスで受け取ってるの？
デバイスドライバから直で？ >>800
画面の書き換えが30や60だから、それより速く反応しても意味ないんだよ
普通のアプリはレスポンス重視＝イベントで処理する
ゲームはタイミング重視だから遅い反応で十分 ところでイベントループが休んでいる時に、どうやってイベントログをリアルタイムで監視するんだ？
集中管理するログデータの安全性確保、データの有効活用のための効果的な対策が求められます。
そのためには、リアルタイムで問題や予兆を管理者が知ることのできる仕組みも必要です。たとえばWindows
イベントログのひとつであるセキュリティログを監視することにより、
ネットワーク経由の異常なアクセスやアクセス許可のないデータへのアクセス試行を検知し、
大事に至る前に追跡・対策することが可能となります。
https://www.manageengine.jp/products/EventLog_Analyzer/windows-event-log-monitoring.html
772 デフォルトの名無しさん sage 2021/04/12(月) 10:53:49.34 ID:yZXPyOt1
>>768
> 左側の太い線で書いたループはイベントループと呼ばれ、発生するイベントを常に監視しています。
メインループとイベントループをごっちゃにするな
イベントループはイベント（マウスボタン押下など）が発生しない限り何もせず休んでいる
ゲームのメインループは、一定間でボタンの状態をスキャンしている
全く別のものだ > ところでイベントループが休んでいる時に、どうやってイベントログをリアルタイムで監視するんだ？
マルチタスクOSって知ってる？
ゲーム脳だから、実行中のプロセスは一つだけという前提なのか？ｗ イベントログはポーリングするapiみたいなのがある
例えばプロセスが起動したら教えてくれる 『実行中のプロセス』がいくつあろうが、マウスクリックへの反応が後回しになるんか？？？
805 デフォルトの名無しさん sage 2021/04/12(月) 20:29:26.92 ID:wo2ZdM5G
> ところでイベントループが休んでいる時に、どうやってイベントログをリアルタイムで監視するんだ？
マルチタスクOSって知ってる？
ゲーム脳だから、実行中のプロセスは一つだけという前提なのか？ｗ >>803
最近のゲームは描画ループとゲームループは分かれてること多くてな、内部的には120とか240で回してたりすることもあるんよ
ちなみにむかしのゲームはvブランク割り込みって言うやつに同期してることが多いからゲームループは60とか50だったりする お前らオブジェクト指向の話見失ってない？
いつまでゲームプログラムの実装の話してるの？ >>808
>最近のゲームは描画ループとゲームループは分かれてること多くてな、
そのために『死亡ラグ』が起こってしまうらしいね！
>自分がいつ死んでいるのか分からず突然死んで突然画面が切り替わってしまう。
サーバー側のバトルシステムと、プレイヤー側の描画システムが乖離してる！ >>807
どこを読んでマウスクリックへの反応が後回しになるって思ったの？
意味不明すぎてさっぱりわからん アプリのレイヤーから見れば
iOSならRunloop、AndroidならLooperでイベントループ回して
ループ単位でUIイベント処理してるんだから考え方は一緒なんだよなぁ
画面タッチでハードウェア割り込みが発生しようが
それによってアプリの処理が直接割り込まれるわけじゃなくて
アプリのイベントループ内でチェックするイベントキューにメッセージが送られるだけ
イベントキューをチェックするフェーズが過ぎてからイベントが発生したら次のイテレーションに回される
ゲームはタイミングコントロールのためにゲームループを一定時間で回すものが多いけど
それもイベントループという意味では同じ >>810
一人で空回りしてるとこ悪いけど、オンラインゲームの話はしてないからｗ >>812
> ゲームはタイミングコントロールのためにゲームループを一定時間で回すものが多いけど
> それもイベントループという意味では同じ
違うのはループじゃなくて、ボタンの話だよ
アプリはボタンが押された時のイベントに応じて処理を行う
ゲームはループの中でボタンの状態を検知して処理を行う >>808
＞ちなみにむかしのゲームはvブランク割り込みって言うやつに同期してることが多いからゲームループは60とか50だったりする
なーんか遠い昔vblankと言うのはあった気が・・・
ゲームボーイだっけ？ スレ違いや板違いの書き込みをするやつは詳しいやつがいないと見込んで調子に乗っている卑怯者の荒らし
そんなのが何回真っ赤になって書き込んでいるんだ情けない >>814
>ゲームはループの中でボタンの状態を検知して処理を行う
アプリが直接ハードウェアの状態チェックするようなコードを今どき本当に書いてる？
少なくともモバイルアプリならボタンイベントを受け取ってそれを処理する
コンソールゲームでも一緒じゃないの？
そのレベルの抽象化すらされてなくてゲームごとに実装しなきゃいけないってかなり昔の話に聞こえる >>818
直接ハードウェアの状態をチェックするなんて言ってないよ
ハードウェアを仮想化したデバイスの状態をチェックしてると言ってる
論点はイベントを使うか使わないかだから するとスマホのタッチとパソコンのマウスクリックは違うのか？
>>796
>アプリどころかOSの処理に画面タッチ関連が最優先割り込み指定されてるの。
その辺は俺もあまり自信無いなぁ・・・
1.4. 割り込み Interrupt
割り込みとは、CPUが受けとる緊急の処理要求信号である。
割り込みは、割り込み要求信号線と割り込みハンドラプログラムの開始番地からなる。
(割り込みに種類があるときは、開始番号もそれぞれ決めておく。ベクタ割り込みという。)
CPUの割込み要求信号線(IRQ = Interrupt ReQuest)に信号が発生すると
現在実行中のプログラムを(ほんのわずかの時間だけ)中断して、緊急に(割り込んで)、
対応するプログラム(割り込みハンドラ)を実行する。
http://www.cs.gunma-u.ac.jp/~nakano/OS16/intro.html
785 デフォルトの名無しさん sage 2021/04/12(月) 11:32:46.54 ID:yZXPyOt1
>>782
割り込みとイベントは似てるようで違う
割り込みは他の割り込みをブロックしないように短時間でその処理を終えなければいけない
イベントはそうではない。時間がかかる処理を行ってもいい。
その間に割り込みがブロックされることはない。処理するレイヤーが全く違っている。 話を元に戻すと、ゲームではこのボタンの状態をチェックするクラスが登場するわけさ
724 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/11(日) 08:28:12.36 ID:CjAFb9gH [17/24]
> 「ボタンを押している状態」をクラス
ButtonPressedClass
> 「ボタンの状況」を把握するクラスを作ること
ButtonStateScannerClass
ぜんぜん違うだろ そして、ボタンを押してるか押してないかというのが
ボタンクラスの属性であって
「ボタンを押している状態」をクラスにするのはアホ
そして更にゲーム脳はこの話を聞いて
「ボタンの状況」を把握するクラスのことだと勘違いしてる
マヌケだろ と言う言葉遊びを指摘されて
カタワ指向君は今朝から大ハッスルだったのさ おっと俺も間違い！
>>751
>イベントドリブンによる割り込み処理
アプリが直接ハードウェアの状態チェックする『割り込み』は違う！
812 デフォルトの名無しさん sage 2021/04/12(月) 21:30:38.33 ID:o1bf8P7D
アプリのレイヤーから見れば
iOSならRunloop、AndroidならLooperでイベントループ回して
ループ単位でUIイベント処理してるんだから考え方は一緒なんだよなぁ
画面タッチでハードウェア割り込みが発生しようが
それによってアプリの処理が直接割り込まれるわけじゃなくて
アプリのイベントループ内でチェックするイベントキューにメッセージが送られるだけ
イベントキューをチェックするフェーズが過ぎてからイベントが発生したら次のイテレーションに回される
ゲームはタイミングコントロールのためにゲームループを一定時間で回すものが多いけど
それもイベントループという意味では同じ >827
アプリがハードウェアの状態をチェックするなら割り込みじゃないよ
まったくそこから知らんのか 『割り込み』はハードウェアへのアクセスであり、
>割り込みとは、CPUが受けとる緊急の処理要求信号である。
OSによるイベントループ・イベントキューとは全く異なる！ 揚げ足取りで申し訳無いが、
>>828
>アプリがハードウェアの状態をチェックするなら割り込みじゃないよ
プリンターのSDカードをチェックする、割り込み印刷するアプリも有るけどね。
優先的に印刷する（割り込み印刷）
08RU-07L
今処理中の印刷ジョブを止めて先に印刷するモードです。止められた印刷ジョブは、プリンターのSDカードに保持され、割り込み印刷の印刷ジョブが終わると、印刷しなおされます。
プリンタードライバーの「出力方法」で「割り込み印刷」を選択して印刷します。
https://oip.manual.canon/USRMA-0207-zz-SS-jaJP/contents/08100000.html 例 マウスの動きをチェックしたい
方法1(ポーリング)(割り込みではない方式です)
マウスが動くとあるメモリの値が変化するようにハードウェアを設計する。
定期的にそのメモリの値をチェックする方式(ポーリング=定期的なチェック)だと
次のような欠点がある。
(1)プログラムが複雑になる。
(2)他の部分の処理が長びくと、チェックが遅れるかもしれない。
(3)頻繁にチェックしなくてはならないので、CPUの負担が大きい。
方法2(割り込み)
マウスが動くとハードウェアからCPUの割込み要求端子へ信号が発生するようにハードを設計する。
この信号が発生すると、CPUは、実行中の(他の)プログラムを中断して、割り込みに対応した
プログラム(割り込みハンドラ)を、すぐに(ごく短い時間だけ)実行する。
その後、中断したプログラムを再開する。
(ポーリングのように定期的にメモリをチェックする必要はない!)
http://www.cs.gunma-u.ac.jp/~nakano/OS16/intro.html
1980年代の『互換性の無いハードウェア依存システム』になりそうな気がする・・・
821 デフォルトの名無しさん sage 2021/04/12(月) 22:02:29.09 ID:wo2ZdM5G
>>818
直接ハードウェアの状態をチェックするなんて言ってないよ
ハードウェアを仮想化したデバイスの状態をチェックしてると言ってる
論点はイベントを使うか使わないかだから すると例えばキャノンのプリンタードライバーのような仮想化デバイスを、
>>821
>ハードウェアを仮想化したデバイス
キーボードやマウスやUSBメモリにも適用させようと？？？
デバイスのインストールと起動が面倒くさいことになりそうだな！ >>821
OSやフレームワークが提供するイベントを使わなくてもやってることは変わらないよね？
デバイスの状態をチェックしてアプリケーションにとって意味ある入力(=イベント)として解釈するレイヤーと
発生した入力(=イベント)を使ってアプリケーションの管理する状態を更新するレイヤーとは別でしょ？
それを混在させるメリットある？
適切にレイヤー分けできてないだけに思える >>833
ボタンのイベントで処理するのと
（ボタンを無視して）タイマーのイベントでボタンの状態をスキャンして処理するのとの違いだよ
いい加減ポーリングはイベントと違うということを理解しよう >>832
そのためのプラグアンドプレイだよ
PS2接続とUSB接続のマウスでは別のデバイスドライバが使われるが
APIでは同じ物として使用できる >>834
Stateパターンを知った上で、"ボタン"を状態にするなんかゲームぐらいなので
そのゲーム前提でしか語ってないからゲーム脳なんだって話をしてるんだよ 業務用システムでもいろんなわけわからん条件に応じて
いろんなコントロールが友好になったり無効になったりするときに
Stateパターンでスッキリするときはあるぞ
Stateパターン使うというより
ステートマシンが必要なら作るという
それだけの話だが >>839
そう言う考えに至らないからこその
カタワ指向君なんだが だから最初に「ボタンを押している状態をクラスにするのはアホ」と書いた
よく読まないから恥をかく
824デフォルトの名無しさん2021/04/12(月) 22:06:58.46ID:wo2ZdM5G
そして、ボタンを押してるか押してないかというのが
ボタンクラスの属性であって
「ボタンを押している状態」をクラスにするのはアホ >>836
ポーリングした結果をイベントに変換するだけでしょ
>>679のゲーム脳の例でも
～の場合はボタン押しっぱなし、～場合はボタン立ち上がり、～場合はボタン立ち下がり
というイベントに変換してるじゃん
イベントを発行する低レイヤーの処理がポーリング使ってようがいまいが
上位のレイヤーからすればどうでもいい話なんだよ
レイヤーが違う話をごちゃ混ぜにしてるよって指摘に「違うｷﾘｯ」って返されても困るわ > ポーリングした結果をイベントに変換するだけでしょ
だからゲームではしないんだよ > ～の場合はボタン押しっぱなし、～場合はボタン立ち上がり、～場合はボタン立ち下がり
> というイベントに変換してるじゃん
イベントは発生するもの。はぁ。そこからかよ > イベントを発行する低レイヤーの処理がポーリング使ってようがいまいが
低レイヤーの話はしてない。
ゲームアプリの実装はイベントを受け取らず定期的にボタンの状態をスキャンしてるの
ゲーム脳がなぜ「ボタンの状況を把握するクラスを作る」ものだと思ってるのかわかってないでしょ？
724 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/11(日) 08:28:12.36 ID:CjAFb9gH [17/24]
> 「ボタンを押している状態」をクラス
ButtonPressedClass
> 「ボタンの状況」を把握するクラスを作ること
ButtonStateScannerClass
ぜんぜん違うだろ なにも言い返してないことに対して続けてと言われても
反論がないならレスしなくていいのよ ああ、いつまでも完結してないことにして
反論できないことを、ごまかすって言ってるわけねｗ まぁそう受けとってもいいよ。今はね。
邪魔をして悪かった。続けて。 なら何もID変えるほどビビることもないだろ？
自信があるならどうぞ続けてください おっとIDの話にすり替えようとしても、お前の反論がないというこの状況に変化はないぞｗ いいよ、今は反論がないということで
だから続けなよ >>844
なるほど、自分でイベントを発生させたことがないんだね
それでイベントドリブンを語るのはStateパターンすら知らずにオブジェクト指向語るのと同レベルだわ
ゲーム脳に比べると君のほうが常識人に感じてたが
視野狭窄という意味でやっぱりゲーム脳とどんぐりだな
レスバする理由がよくわかった > なるほど、自分でイベントを発生させたことがないんだね
なぜゲームではイベントを使わずに
ポーリングでボタンの状態を検出するというだけの話から
そんな発想が出てくるんだろうか？
意味わからんよねｗ 印刷中は電源オフ要求があったら下の領域でラッチして覚えておき、印刷が終わったところでラッチを調べ、
電源オフ要求があったならば、電源オフ処理を始める。
このように、何かをやっている最中に、何かが起きることを覚えておきたい、というときに、直交合成状態を使うことができる。
この形のことを Latch State (ラッチステート)パターンと言う。リアルタイムUMLワークショップという本の中で、ブルースダグラスさんが命名している。
https://qiita.com/saltheads/items/abd039ec2df18bdd7995
839 デフォルトの名無しさん sage 2021/04/13(火) 11:03:47.18 ID:3qmwHhLR
業務用システムでもいろんなわけわからん条件に応じて
いろんなコントロールが友好になったり無効になったりするときに
Stateパターンでスッキリするときはあるぞ
Stateパターン使うというより
ステートマシンが必要なら作るという
それだけの話だが >>857
視野搾取と言うけど俺は別にそう言った作り方をしていないものを否定はしていないよ
常に追加に対しては開いていて変更に対しては閉じているのだ >>859
正直リンク先見たとき英語で記載されてて
俺じじいだし英語読めないし
DEEPLE先生で翻訳しても訳分からないし
Stateパターンって名前がついているのは知らなかったけど、
クラス図見たとき「ああ、あのアレか」と思うほど結構使われてるやつだったよ
ま、そう言うとまたゲーム脳って言われるんだろうけど データベースとオブジェクト指向の間には溝があります。インピーダンスミスマッチと呼ばれていますが、
ゲームを構築する際にも、インピーダンスミスマッチが生じています。
ゲーム世界をプログラムコードに落とす上で、継承という仕組みは貧弱すぎるのです。
https://qiita.com/tshinsay/items/739ad875cc3925d51f12
一般的なゲームプログラミングで使われるオブジェクト指向は、サブクラスではなくインナークラスのほう。
オブジェクト指向は要らないという意見もあるが、サブクラスについては人工知能に活用したいところ。
例えばクリントン大統領はチンポ【が】シコシコしてしまったのが『不適切な関係』だったとか。
1 インナークラス(オシッコをするときのチンポ)
ネットワーク、メッセージング、イベントドリブン、同期処理・・・
2 サブクラス(勃起・射精するときのチンポ)
自然言語処理、人工知能・・・ こういう場合は、サブクラスとして『ひげそり機を使っている状態のFred』を再定義するしかないかも。
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, アーロンカービル
一般的なアプリやゲームやプリンターにおいては『状態』そのものをオブジェクトには出来ないが、
>>626
> 乗っ取られるという状態変化を起こしたクリントンがシコっていることに変わりはない
人工知能とか自然言語処理なら、シコシコしたチンポにクリントンがシコられたと解釈したいところ。
250 デフォルトの名無しさん sage 2021/03/21(日) 16:00:54.94 ID:rWfpUSZ4
状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質 このスレでゲーム脳って言われてる人って
アーケードか家庭用ゲーム機で作ってたりするん？
老舗あるいは有名メーカーだったりするん？ メッセージループでメッセージを受け取る->処理する
送り側はメッセージキューに送る
すべてそれで理解できる
何年も何にも変わってない >>864
それは答えられないなぁ
なんで答えられないのかも答えられない >>865
Windows 3.1や95の初期あたりの頃とかはそうだった
プログラマがウインドウメッセージを直接処理していた
今はそういったものはライブラリが処理し
アプリケーションプログラマから見るとウインドウメッセージは
イベントとして受け取る形でプログラミングできるようになってる
時代は変わってるんだよ >>868
95の初期とか、、、MFCなんて使わないしWindowsXPくらいまでは普通にメッセージ処理してたわいw さて、仕事も終わったことだし
昼頃に言い淀んだことの説明をするか
実はカタワ指向君に反論ではなく>>842に
苦情をいいたかったんだ
カタワ指向君の後にレスしたからカタワ指向が自分のことと思って俺にレスしてきたから
悪いとは思ったけどちょっと面白くなって濁らしたんだ。すまんな、俺は人格破綻者なんだ。
さて
>>842
＞>>679のゲーム脳の例でも
＞～の場合はボタン押しっぱなし、～場合はボタン立ち上がり、～場合はボタン立ち下がり
＞というイベントに変換してるじゃん
いつ俺がイベントに変換しているなんて言ったよ
変に曲解して俺が変なことを言ったように風潮するのは止めて頂きたい
そっちがイベント作成して飛ばすのは勝手だがな。 >>869
> 95の初期とか、、、MFCなんて使わないしWindowsXPくらいまでは普通にメッセージ処理してたわいw
それはお前が選択したものの話であって、Delphi、C++Builder、VB、Javaなんでもありました。
その頃になればC#も登場してますね >>871
それはお前にも言えることだぞ
身近な環境だけがすべてではないことを学ぼう >>225
開発あるあるだなw
そうか、確かにVBAだと後ろが伸びるだけになるかも知れないね。
他のある程度大きいシステムになると
・客先から上がって来ない要件定義
・客先だから強く言えないチームのリーダー
・差し迫る納期
・焦りが出てきてイラつく俺ら。それを宥めるリーダー
この辺からが違うところかな
・システム間の連携や他システムとの連携のため伸ばせない納期
・更に焦る俺ら。宥めきれなくなるリーダー
・上がって来る要件定義、血眼で設計書を作る俺ら
・時間がなくて客先との対面レビューのはずが回覧レビューになる設計書
・PGしながら単体テストケース作りながら単位テストしながらエビデンス取る俺ら
・超える納期、無くなる休日、伸びまくる勤務時間、倒れる仲間
・覆る要件定義、設計種ミス発覚、他の嶋から助っ人入るも焼石に水、発狂する助っ人
・何とかSTまで終了。飛ばされるリーダー、バグだらけの成果物、昇天する俺ら
最悪こんな感じかな。 >>872
だからゲームでボタンを状態にする例をだしたのち
それは例外だって話をしてるだろ
こっちは知った上で話しをしてるんだよ 訂正
だからゲームでボタンの状態をクラスにする例をだしたのち 話を戻すが、「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ にしても
>>250
＞状態をオブジェクトにするな
＞は昔からよく言われている
＞「ボタンを押している状態」
＞をクラスにしてしまうと
＞プログラムが無茶無茶になる
＞「モノ」をオブジェクトにする
＞これがオブジェクト指向の本質
これが未だに釈然としない
もうゲーム脳認定されてるから遠慮なくそっちの話で書くけど
正直、ボタンの状態をイベントで取ろうが
ポーリングで取ろうがCやC++で直接I/Oポートアドレスの値読みに行こうがそんなことはどうでもいい。
キチンと処理に同期してボタン状態が取得出来れば手段はこの話の本質とは関係ない。
以前、イベントでボタンの立ち上がりやキーの立ち下がりは取得出来るから必要ないとの意見もあったけど、
格闘ゲームなどではコマンド入力の判断を行うため、ある程度の期間ボタンの状態をどこぞに格納するのはザラ。
それがエンティティのクラスだからって何故プログラムが滅茶苦茶になるのか理解出来ない。
一般業務になるとどのような制限を受けるのか分からんけど、
処理は無駄になるかも知れないけど、無茶苦茶になるとは思えない。
Object指向的な制約があって、そういうこともあるのかググってみたけど、どれも釈然としない。
終いには昨日聞いたStateパターンの話が出てくる始末。
で、知りたいのは「何故ボタンの状態をクラスにすると無茶苦茶になる」のか、どういう原理で無茶苦茶になるのかと言うところ。
ちなみにカタワ指向君と昨日Stateパターンの話をした人はこの件について別にレスする必要はないと思ってる。
カタワ指向君は既に一般業務以外のものは対象外とバッサリ切り捨てているし、
Stateパターンの話をした人は状態をクラスに持つことを許容していると分かっているからね。 なんだか分からねえが熱いバトルが続いてることは伝わったぜ…! ＞「ボタンを押している状態」
＞をクラスにしてしまうと
「ボタンの状態をクラスにするな」と言われてるのに
> 正直、ボタンの状態をイベントで取ろうが
とボタンの状態を取る方法の話だと思ってしまう人は
オブジェクト指向の設計を全く理解してない
根本的に理解していない 何かしらの状態をクラスにすることはありえるが
「ボタンの状態」をクラスにするなと言われてることが
まだわかってない >>883
うむ、だとしたら解っていないんだろうな。
見解を説明して貰ってもいいかな？ > 状態をオブジェクトにするな
> は昔からよく言われている
ちなみにこれどこ界隈で言われてたんす？
よく言われてるとのことだが聞き覚えは無いんで >>884
お前が「ボタンの状態をクラス」にしたものに
なんて名前のクラスにするかを答えれば
お前の勘違いがはっきりする >>885
俺はStateパターンを知ってるから状態をクラスにするなとは言ってない
だがボタンの状態はクラスにするな >>883
正直、「何かしら」の状態は良くて
ボタンと限定されると駄目なのかが分からん。 >>888
ボタンの状態で振る舞いが変わるのはボタン自身ではないから >>886
以前、
724 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/11(日) 08:28:12.36 ID:CjAFb9gH [17/24]
> 「ボタンを押している状態」をクラス
ButtonPressedClass
> 「ボタンの状況」を把握するクラスを作ること
ButtonStateScannerClass
と言うのは聞いたが実際には
「ButtonStates」になるのではないか？ >>887
>>250に書いてある
> 状態をオブジェクトにするな
> は昔からよく言われている
↑これが言いたいことは
「ボタンの状態はクラスにするな」
が
「昔からよく言われている」
ってこと？ ButtonStatesというのは
どういう状態なのか言え
Stateパターンで「ButtonStatesという"状態"の時」なんて
言い方はしねーよ
結局Stateパターンもわかってない
ググってこい。Stateパターンにおける状態のクラス名を >>892
ボタンと限定されると駄目なのかが分からん。
とお前が言ったから、
だめな理由を答えたんだが？
で？とお前が言うなら、こう答えるだけだぞ
ボタンの状態で振る舞いが変わるのはボタン自身ではないから
ボタンに限定すると駄目 >>893
いや別にここではStateパターンの話をしている訳ではないんだがな。 >>891
どうみても、そういう日本語じゃないよな？ｗ >>895
最初の質問を無視するのはなぜ？
ButtonStatesというのは
どういう状態なのか言え >>896
じゃあどういう日本語なんよ・・・
草生やしてないで「昔からよく言われている」のが何なのか教えてよ
そして、どこでいつよく言われてたのかを最終的には知りたいんよ ButtonStatesとう名前のどこに
「ボタンを"押している"」という状態が含まれてるというのか
「ボタンを押している状態」をクラスにするのがダメという
日本語が理解できていない >>897
ああそうか
例えば上、下、右、左、A、Bというボタンが合ったとして、
それらがいつ押されたとか、いつ離されたとか、どのくらいの期間押されていたかの情報を抱えるクラスだな >>898
「状態をオブジェクトにするなは昔からよく言われている」
に対して俺はそんなこと聞いたことがないと言ってる
この話に「昔からよく言われている」ことが何なのかは
一切書かれていない >>901
「ボタンを押している状態」をクラスにするというのは
「ボタンの上を押している状態」をクラスにする
「ボタンの下を押している状態」をクラスにする
「ボタンの右を押している状態」をクラスにする
「ボタンの左を押している状態」をクラスにする
「ボタンのAを押している状態」をクラスにする
「ボタンのBを押している状態」をクラスにする
ということなわけだ
ありえないだろ >>902
> 俺はそんなこと聞いたことがないと言ってる
それはどこで？ >>903
なるほどそう言うことか
ありがとうカタワ指向君
なんか言いたいことがわかったよ >>904
>>887で言ってる
>>905
今なら最初の頃に指摘したこれも理解できるだろ
711 名前：デフォルトの名無しさん[sage] 投稿日：2021/04/11(日) 07:34:09.10 ID:CjAFb9gH [9/24]
答えに詰まったようだねｗ
ゲームのボタンっていうのはキャラクターの一種なんだわ
例えばマリオだとPスイッチは、押したら潰れて消える
持って投げられる。ベルトコンベアやバネの上で動く。
壁として障害物になる。
そういうのとUIのボタンを一緒にするのは抽象化能力が低い
ボタンという名前だから同じものだと考えてしまっている
ゲームのボタン（キャラクター）を持ち出して
UIまでキャラクターにするのはアホ >>906
そもそもクラスに当てはめるものの見解が違ってたってことだね ゲーム脳が、ゲームキャラクタとしてのボタンのことを
言っていたのか今となっては不明だが
ゲームキャラクタとしてのボタンであれば
ボタンの状態によってボタン自身の振る舞いが変わるから
これはあり得るんだよ
だが物理的なボタンの状態をクラスにするとかありえない んで、ゲームキャラクタとしてのボタンの話かと思ってりゃ
今度はボタンの状態をスキャンする話を始めたからな
こりゃ完全にゲーム脳（ゲームの設計しか知らない）だとｗ >>906
失礼
>> 状態をオブジェクトにするな
>> は昔からよく言われている
>
> ちなみにこれどこ界隈で言われてたんす？
> よく言われてるとのことだが聞き覚えは無いんで
これにレスくれたからってっきり>>250さん本人が
俺の疑問に回答くれてるのかと思ってたが別人だったのね
>>250
> 状態をオブジェクトにするなは昔からよく言われている
>>887
> 俺は(略)状態をクラスにするなとは言ってない >>910
そうそう。俺の主張だと勘違いされるのを防ぐためだ。 >>909
というか最初にボタンの状態をと聞いて
>>903
＞>>901
＞「ボタンを押している状態」をクラスにするというのは
＞「ボタンの上を押している状態」をクラスにする
＞「ボタンの下を押している状態」をクラスにする
＞「ボタンの右を押している状態」をクラスにする
＞「ボタンの左を押している状態」をクラスにする
＞「ボタンのAを押している状態」をクラスにする
＞「ボタンのBを押している状態」をクラスにする
＞
＞ということなわけだ
＞ありえないだろ
これは思いつかないよ
もっとも俺の頭が堅いのかも知れんけど >>912
たぶん単に経験が乏しいんかもね
怒らないでね >>913
怒りはしないけど
アセンブラ時代からやってたところに
そう言われると凹むわー >>912
俺にとってはstateパターンを知ってるから状態をクラスにすることはあり得る
ありえるが「ボタン」の状態をクラスにすることはありえない
あるとしたらゲームのキャラクターであるボタンのことを言ってるのかと推測したが
ボタンの状態をスキャンするとかいい出したから
ゲームのメインループの話をしてるのか？と推測したわけだ
ちなみにMS-DOS時代だがアセンブラも使ってたぞ
割り込みベクタを直接書き換えてた人間に、割り込みの話をされてもなーって感じだし
ゲームは本業ではないが、昔はでべろで遊んでた
今は普通にRubyやらJavaScriptやらオブジェクト指向言語も使ってる B型プログラマ同士が卑語を交えつつマウンティングし合う大会の会場はここかな？ はいそーです
マウントされたくなければ、うかつに手を出さないことだｗ >>916
でべろってあのPCエンジンのか
あれやってるなら
処理単体を1/60と言っていたのも頷けるわ >>918
ちなみに俺はAB型だ
だから人格破綻者だと言ったろ？ アマチュアでもよく使ってたタスクシステムってやつはオブジェクト指向とは違うの？ >>922
オブジェクト指向だと思うよ
最近はコンポーネント思考が主流？ >>920
60fpsは単なるよく使われる割り込み単位の一つだろ？
もとはVSYNC割り込み間隔で、アナログテレビの
垂直周波数（インターフェース）が大元じゃなかったか？
その間隔でなければならない理由はないが
名残で今でもその間隔（またはその倍数）が使われてるんだと思うが >>924
今は1/120とか速いものだと1/240になっている
vsync割り込みは今でもそうだけど
でべろで言うならNMI割り込みかな >>924
PALだと50fpsになるんだよなー
海外版と通信対戦するときはフレームレートの差を気を付けないといけなかったのはいい思い出 >>925
それはディスプレイの話だよね？
映像の表示だけなら高速でもいいが
ボタンのスキャンは低い方に合わせないと
プレイが不公平になると思うが
まあ1秒間に60回以上入力できるやつなんていないから
120回読み取りにしちゃっても差はないというかもしれんがｗ >>927
いんや作りによりけり
例えば1Pと2Pの格闘ゲームを作ってたとして
同じフレームの処理の場合、1Pの処理を
先にするとしたら当然1Pの方が先に
攻撃を当てることが出来るけど
1Pでも2Pでもその際に逆側の攻撃が
当たってないか判定を入れるだけ。
投げる処理とかも同じ処理では違いの
位置の同期をとって行うよ そのことは実は結構大事なことで
これをしないと同時にダメージを
受けるという事象がなくなってしまう
場合があるんだよ >>929
いや、対戦じゃなくて一人プレイの場合よ
仮に連射するだけのゲームが有ったとしたら、1秒間に60回スキャンするよりも
1秒間に120回スキャンする方がが取りこぼしがないだろうけど
そもそも1/60 = 16.7ミリ秒を超えて反応出来る人はまずいないから
気にしてないのかなーって話
でも個人的感覚では人間は瞬間的な速度であれば10ms程度で
反応することは出来ると思うんだよね
昔イライラ棒（物理）を作った時の接触判定を10msのポーリングに決めた経験からｗ
Cバスは単純だから線つなげるだけで割り込みが使えたと思うんだけど
そこいらに転がってたLSIを再利用して適当に作ったから面倒だった。 >>930
> これをしないと同時にダメージを
> 受けるという事象がなくなってしまう
そうそう。そうなるよね。
上の方でゲームではイベントを使わない理由の一つがそれだと思ってる。
イベントで処理してしまうと、どちらかが先に反応してしまうから
だからフレームレート等の一定間隔で1Pと2Pの両方の入力が済んで
両者の計算が終わってから判定処理をするべき
ということを自分で思いついて、小学生か中学生の頃に
MSXのBASICで作った連打するだけのレースゲームで実装してたｗ
当時は記憶媒体がなくて電源消したら全部消える。
紙にソースコード書いてたよｗ >>931
それはその通りで論理的に言えば
60fpsだと1秒に30回、120fpsだと60回の
立ち上がりを検出することが出来るのかも
知れないけど、余り現実的ではないね。
映画で連打でスイカ割ってた高橋名人が
一秒間に18回って言ってたから
打てたとしてもボタンや
キーボードクラッシャーになると思うよ
そこは冗談だけど >>932
ちなみにだけど、
昔の業務用のゲームはたまーにRAMにプログラム載せてて
電池が切れると全部無くなるというのが存在するよ >>898
もともとのオブジェクト指向の意味が「“こうしろ”ってメッセージで自律行動できる単位でプログラムを区切る」だから
単なるフラグ管理レベルをオブジェクト化するのは無駄だからやめろって話だわな。
フラグ管理スペシャリストクラスが必要とかなら別だが、それはそれで設計からおかしいだろうし。
そもそもオブジェクト指向はオブジェクト指向なんか要らないローレベル処理と
オブジェクト指向設計が必要な高レベル処理を自覚して使うものだから
正直な話、処理速度重視とかならそんなとこでオブジェクト指向なんて使う必要ないのよ
それをC++とかローレベルでのパーツ使い回しにオブジェクト指向使ったから
いらんとこまで『オーブージェークーートーー！…指向！」ってなって
低レベルプログラマが発狂していまに至る。 するとチンポは自律行動できる単位なのか？？？
>>935
>もともとのオブジェクト指向の意味が「“こうしろ”ってメッセージで自律行動できる単位でプログラムを区切る」だから
なら話を戻すが、「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ メッセージングはインナークラスとしてのオブジェクト指向でオシッコするときのチンポ、
>>935
>“こうしろ”ってメッセージで自律行動できる単位
『自律行動できる単位』は、サブクラスとしてのオブジェクト指向で勃起・射精するときのチンポ！
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 割込み（インタラプト）は、OSのほうで隠蔽してくれないと
オプジェクト志向とは相性が悪い。ウィンドウシステムでも、
そこはイベント駆動（イベントドリブン）ということで
なんとか押さえこんでいるわけだし。
ボタンとかキーボードとかだと、チャタリングの処理があるので、
そこは別プロセスで割込みを受けとってキューイングしてくれないと、
メインで動いていているプロセスは対処に困る。
まぁ、入力にも出力にも関わらないプロセスを立てておいて、
出力側がタイマーでそのステートを提示の割込みで見にゆくとか、
そんな実装になるんだと思うが。 577 その名前は774人います (ｽｯﾌﾟ Sd22-ObUD) sage 2021/04/14(水) 00:52:35.71 ID:/qa39Aihd
https://i.imgur.com/u2RSU8j.jpg
https://i.imgur.com/kLtQspe.jpg まぁそうね、考え方は人それぞれ
俺は使い分けだと思うけど。
別にCやC++だって自分で趣味的にやるなら
一切必要ないし、ゲームの仕事してても
多数の言語選べる環境もあるし。
ただ詳しくは言えないけど
CSでゲーム作るなら「今は」C、C++は
やっておいた方がいいと思うよ。
ま、これはObject指向には余り関係ない
から気にしなくていいよ。聞き流して。 コールバック関数というのがあって
常にデバイスをみてるOSやデバイスドライバに
コールバック関数を登録すると
データを渡してくれる
自分で作ったコールバック関数が実行される >>941
詳しそうだね。その登録するときに使う
関数名は言えるかい？ 同時判定って本当に同時だったっけ？
投げは絶対に同時発生しないんだから、どっちか優先だよね？（オブジェクト指向関係ない）
ボタン入力を1ビットづつ読み出し中に分岐して処理したりはしないけど、大体2P側不利にならない？（オブジェクト指向関係ない） 割込みベクタ書き換えて、自前の処理の最後に元の飛び先への分岐も入れとく感じかな？
IOCSに自分でパッチあてたりとか（なんの機種の話だ） >>943
ベストをつくしたいのかもしれないけど
遅延とか普通なのに同時を
判定するのは意味ないような なんかスレ伸び速杉（笑）
昔は CPU が遅かったので、30 FPS としたら
33ms の奪いあいだったわけだが、
現在はプロセッサは速いわ I/O 周りのチップ
（出力側のグラフィックも含めて）は
充実してるわで、 60 FPS でも
16.7 ms の分配ということになる。
しかも最近は CRT じゃなくてディジタル表示なので、
リフレッシュタイムとかは表示側のプロセッサに
丸投げできる（とにかくグラフィック・メモリに描いてあれば
表示してくれるわけだから）。
>>940
> CSでゲーム作るなら「今は」C、C++は
>やっておいた方がいいと思うよ。
同意見ではあるのだが、
アセンブラ →〔マクロプリプロセッサ〕→ マクロアセンブラ →
〔C コンパイラ〕→ C 言語 →〔プリプロセッサ？コンパイラ？〕→
C++
という構造を踏まえたうえで、OS とか 制禦とかについて、理解して
もらいたいと思う。
とはいえ、ぶっちゃけこのあたりの話は「オブジェクト志向」では
隠蔽するのがお約束なので、もはやオカルトになってしまう。
C++を「オブジェクト志向」と呼ぶのは、正直いかがなものか、
と思う。 >>943
それも作りによりけり
1P側有利になっているものもあれば
はじき合うように作られてるものもあれば
投げを奪い合うように作られてるのもあるよ
投げを奪い合うものというのは
ちょっと説明しにくいけど組み合う形になって
その後、操作のタイミングとか、連打回数とか
そういう本来の投げの動作と違う動作になって
投げ勝ち負けの判定をするタイプのもの。
でも実際は通信対戦とかすると
僅かにラグが発生したりするので
その辺は多少は許容するという
暗黙の了解があるみたい。
最近「ラグい」って言葉を聞くことない？
あれはそのラグが酷くて文句を垂れてる
ときの言葉なんだ。 >>950
最近でばその矢印の指すC++の後ろにUnityが控えてたりもするね。
C++は痒いところに手が届く反面、多重継承が使えたり戻り値の参照渡しが使えたり
ポインタの概念があったりするある意味Object指向言語の中では
かなり特殊な立ち位置にいるものと言えるだろうね。
とは言え、OSの話はおいとくとしても
他の言語にもあるようなLinqやラムダ式も
果たしてObject指向の概念と言えるのか
ってのもあったりするからね。 >>952
Unity よりは Unreal なんじゃないかと
ソシャゲは Unity が多いけど、コンソールは Unreal だな >>948
あまり虐めてあげるな
コールバックは概念的なところが大きいから
使う言語やシチュエーションによっても行い方が変わるの分かっててそれ聞いているんでしょ？
>>941
とりあえずこれ読んどけば？
イベントもコールバックの一種だって事が分かるよ
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/events-and-callbacks
こんな感じで実施する前のメソッドの参照渡しておくのもコールバックだし
リフレクションとかもコールバック
VBA(旧VB6)とかはObjectの場合はCallbyName使ったりObjectでない場合はAPI使ったり
使い分けしなければいけない場合も出てくるし
ポインタの概念があるものは関数ポインタに設定して飛ばしたりするし、
アセンブラの場合はあらかじめワークエリアにアドレス設定してジャンプ命令でそのアドレス目掛けて飛んだりとか
コールバックについて言語やメソッド、あるいは関数単位で説明すると切りがないよ。 >>952
最初からオブジェクト指向なんてラベルはどうでもいいだけだ
C++の目標はかなり初期からゼロコスト抽象の追求だろうし
最近の言語は役に立つなら何でも取り入れている >>956
＞最初からオブジェクト指向なんてラベルはどうでもいいだけだ
＞C++の目標はかなり初期からゼロコスト抽象の追求だろうし
うーん、そうだねぇ
俺もそういう一面で考えることもあるけど
デザインパターンなんかは結局今まで色々苦労してやってきた人達の足跡みたいなもんだし
それを疎かにしてもいいのかなって一面もある。
結局使いどこかなーとも思ってるけど
それに対して結論を出せるほど実力がある訳じゃないんだ。ごねんね。
＞最近の言語は役に立つなら何でも取り入れている
これは素晴らしいことだと思うよ。
この間から話してたCやC++なんか細かいところをその気になればどうとでも作れるフニャフニャな感じなものと真逆で
ゲーム開発でもとある理由からガッチガチなものも存在するから色んなものに対応出来るのはゲーム脳でじじいで頭の硬くなった俺からしても
羨ましい限りだよ。 このガッチガチのっていうのは
OSにも関係のあることなんだけど
その内クロスプラットフォームの話でも
出て来たときに話せればいいかなって思ってるよ >>959
ちなみにC#だとどんなイメージになるの？ まぁでもこれはこれで面白い考えだね
だけどみんなはどう思っているのかな？
ちょっとスレ立てて聞いてみるかな 人というスーパークラスを
男性クラス
チンポクラス
女性クラス
が継承してる 人クラスはシコシコするというメソッドしか持っていない
男性もチンポも女性もみんなシコシコする オシッコはインナークラス、勃起と射精はサブクラス。後者の場合は『人格を性欲に乗っ取られる』時で、
これはクリントンそのものを再定義するしかない。人工知能や自然言語処理では多重継承が大切。
250 デフォルトの名無しさん sage 2021/03/21(日) 16:00:54.94 ID:rWfpUSZ4
状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質
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, アーロンカービル >>966
クラス名は名詞だけと言うよね
チンポも名詞だからクラス チンポ【が】シコシコするという『世界の真理』、これこそがオブジェクト指向の新たなるパラダイムなのだ！ オブジェクト指向をクリアに説明してあるサイトがない
ということからオブジェクト指向はクリアに説明できないのだろう
他の概念はうまく説明しているサイトがある > 他の概念はうまく説明しているサイトがある
どこどこ？ >>975
>あわしろ氏：「不随意運動、ハイ論破」
そして、トイレへ行き尿を出そうと思うと、脳が「出してよい」という信号を送ります。ここで副交感神経が
主にはたらき、尿道の筋肉がゆるみ、反対に膀胱の筋肉は締まって尿を押し出し、尿が排出されるのです。
健康な成人では、1回の排尿量は300ミリリットルほどで、約30秒で膀胱が空っぽになるのが普通です。
https://www.hainyou.com/sp/m/mechanism/ >>974
>ということからオブジェクト指向はクリアに説明できないのだろう
class チンポ extends クリントン{
super.不適切な関係;
}
クリントンーーーーーーーーーー
┃ ┃
┃ ┃
┃ ┃
┃ ┃
┃ ┃
ーーーーーーーーーーーーーーー
┃ﾁﾝﾎﾟ┃
￣￣￣￣
『人格を性欲に乗っ取られる』、つまりクリントンはﾁﾝﾎﾟに人格を乗っ取られて、ﾁﾝﾎﾟにｼｺられてしまった！ つまりあわしろ氏と人とチンポは
Is a 関係が成立するのである >>970
つまらないどころかオブジェクト指向の要素抜きでプログラム組むのはオブジェクト指向型言語以外でも苦行だ
900レス以上のスレになってもまだ理解及ばないアホがいるんだな。マジクソスレ >>981
オブジェクト指向は俺の股間に付いているから、オブジェクト指向言語は要らないよ？ 「～を教えてくれ！」というスレッドができる→マウントおじさんが大集合する→マウントおじさんをからかうガイジも集合する→クソスレになる >>950 だが、
「オブジェクト志向」というと、「下位オブジェクトにメッセージを投げると
返ってくる」というイメージがどうしてもつきまとうんだよな。
それを考えると、「main」の扱いがけっこう難しくなると思われる
（まぁ、Java 限定の話かもしれないが）。
「それぞれのオブジェクト間の相互作用」を上位で見守っているクラスがあり、
たとえば C 言語のような「広域変数」をシングルトン実装するのが
上位オブジェクトの役割かもしれない。 ところで、次スレはどうする？
「チンポシコシコ」が無駄にスレを伸ばしているわけだが、
肝心の「オブジェクト志向」（昔は「算体志向言語」と呼んだものだが）に
ついては、あまり議論が進んでいないように思う。
誰か「算体志向を教えてくれ！」とかいったスレでも立ててくれんかな。 >>987
>「チンポシコシコ」が無駄にスレを伸ばしているわけだが、
「オブジェクト指向」について、他にわかりやすい説明をしてみろ！ >>991
じゃあ「チンポシコシコ」の話をやめて
人の話を聞いてくれるか？ >>993
こんなところにまで来て
あわしろ教で荒らすな >>992
なら「オブジェクト指向」について、自分の言葉で語れよ！ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 41日 22時間 6分 56秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
