オブジェクト指向を教えてくれ！ YouTube動画>4本 ->画像>16枚

オブジェクト指向について、調べれば調べるほど疑問が募ります。低レベルで粗末な疑問かも知れませんが、ご教授願いたいです。

・データと振る舞いをまとめる？
まとめると何か良いことあるの？
ファイルあるいはモジュールにはまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
(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
い

>>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

>>24
どういう意図でこの投稿したんですか？

>>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
もちろん歴史的経緯は違いますが

>>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批判

リンクがおかしかった

https://medium.com/@jacobfriedman/object-oriented-programming-is-an-expensive-disaster-which-must-end-2cbf3ea4f89d

そら「別に電気製品をプラグアンドプレイにしなくても
毎回電源落として各自が自分で電線を半田付けすればできるよね！」って言われりゃそうだが
まあ、あたまおかしいだろおまえ。としか

>>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

>>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おじさんが急に予防線張り出したwww

staticを理由も無く多用する奴って実際理解していないという意味だしねｗ

議論を勝ち負けで判断してる時点でstaticおじさんの素質あり

勝ち負けに拘らないなんて奴は
こんなクソスレに何しにしてるんだ？
バトルをしに来てんじゃねーのかよ

>>134
それには僕も同意します

オブジェクト指向が本当に「自然な」モデリング手法であったならこんな疑問は出てこず誰でも「自然に」理解して使えているはず。
結局オブジェクト指向が解決する問題とやらはオブジェクト指向を使うことによって産み出される問題なのだ。
とんだマッチポンプである。

人間は自然に言葉を話し、自然に考えるが
言語学や哲学があるのと一緒

人間は自然に物事を考えてるがそれを曖昧さが許されない
コンピュータ上で表現しようとすると体系化が必要になる

>>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
わかりやすい文章を書くときに主語を書けって言われるだろ？
あれだよ
オブジェクトはプログラムに主語を書くためのアイデア

サルでもわかるみたいな解説サイト見ると一般人向けに曖昧に書いてあるから余計イミフなんだよな

しにそう

rpcって最近聞かなくなったな

>>133
その渡した関数が引数で使うデータをどう渡すかって話だよ。
cで書いてみろ。型の部分で変なキャストしなきゃならなくなるから。

>>42 オブジェクトは対象語
>>148 オブジェクトは主語

どっちなの!?

>>153
チンポ【が】しこしこする、チンポは主語であり独立した主体存在である。

>>152
はい？

>目的は関数の呼び出し側と呼ばれる側の依存関係を逆にしたいってところなんだよ。
これがオブジェクト指向の目的だと主張してるんだよね？

型のキャストの有無に何の関係があるのかわからんが
ある型を引数として受け取る関数を
別の関数の引数や戻り値として受け渡しできればキャスト不要だよね？
オブジェクト指向関係ある？

オブジェク指向じゃなければCって前提なのかな？

>>151
gRPC

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オブジェクトを使うように
非同期のメッセージングさえも併呑して現代のオブジェクト指向は成り立ってると思う
アラン・ケイのオブジェクトは、オブジェクトの一形態なんだよ

そうして考えた場合にオブジェクトは何かと言われると
データと操作をガッチャンコしたプログラムということになろうかと

オブジェクト指向の設計論でよく言われる貧血ドメインはダメだという
考え方は僕は嫌いで、データと操作を分けた方が良いこともある
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待ちさせられるだけになる

あわしろ氏によると、これからはダブルスレッドの時代らしい。

>>223
ダブルスレッドをググったらミシンしか見つからなかったんだけど
これフリーザっぽくない？

ぽいというか、完全フリーザでワロ。

>>218
その通りでGUIやI/Oアクセスやネットワーク通信などの単なる計算以外のプログラミングでは非同期で書くほうが有利
そして非同期プログラミング自体も最近はメジャーな言語が次々とasync/awaitをサポートするようになったことで構文的にも同期と同様の記述が出来るようになり唯一の欠点も無くなった
これでオブジェクト指向におけるメッセージング(メソッド呼び出し)も同期だけでなく本来の非同期も使いやすくなるだろう

>>221
そのシングルスレッド＋同期のみだと相手のオブジェクトでの処理がUI、I/O、通信などで時間待ちとなる場合に自分もブロックされて何も出来なくなってしまう
つまりそうなっても構わないようなソフトウェアしか書いていないということになる

Ruby, Haskell, アラン・ケイ

ム板のごく一部のやつのせいで不必要に評判を落としてる三大被害者

>>226
小泉進次郎みたいｗ

>>228
わかりすぎる

>>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();
}

プログラムによる構造を越えて処理しなければいけないときにオブジェクトは有用

そう考えると構造化プログラムの発展としてオブジェクト指向ができたのはうなずける
継承やポリモーフィズムがオブジェクト指向に必要なのかはよくわからない

寝言ばかりのスレだな
取り敢えず馬鹿みたいな本や記事を書き散らして
初心者を混乱させるような仕事だけはするなよな

馬鹿に洗脳されたアホを再教育するのは面倒なんだ

>>247
責任感すごいです

状態をオブジェクトにするな
は昔からよく言われている
「ボタンを押している状態」
をクラスにしてしまうと
プログラムが無茶無茶になる
「モノ」をオブジェクトにする
これがオブジェクト指向の本質

哺乳類クラスから犬を派生させると、あわしろ氏が言ってたな。

ちん○とか言ってる時点で頭おかしい

カモノハシはどうするの？
哺乳類クラスを修正したら、
そのままでは犬も卵を産むことに。
生成時に決めるように修正しても、
結局既存の犬生成コード部分を書き換える必要が発生ｗ

>>250
デザインパターンの一つにステートパターンがあるから
ケースバイケースだと思う

モノはオブジェクトの日本語訳だと思うよ

>>253
胎生は哺乳類の定義に含まれないから哺乳類クラスを修正するわけがないでしょう
字の通りおっぱいで子どもを育てるから哺乳類

生物に例える事自体プログラムから離れるんだよなゲームキャラクラスから色々派生させるなら実感湧くけどな

クソみたいな喩え嫌いだわ

そもそも共通項でないものを親クラスに書くなっていう、そんな基礎から説明しなきゃいけないやつがいることに頭が痛い

オブジェクト指向がどうというより、その辺はDDDの話なわけでそっちでやれや

>>258
その辺てどの辺のこと？

>>257
哺乳類とカモノハシはたとえだろ。
設計時犬、猫、馬のみがあって、
胎生は共通だからクラスに書く、
その後カモノハシ追加という流れ。
こんなことすら分からんとはｗ

>>256
現実のモノ（オブジェクト）に例える事自体プログラムから離れるんだよなオブジェクト指向の喩え嫌いだわ

>>261
チンポ【を】しこしこするのではなくて、チンポ【が】しこしこする。これがオブジェクト指向。

(不適切な関係,クリントン,ルインスキー) -> ｛return フェラチオ｝

クリントン元大統領が真実を告白「モニカと口淫行為を…」
https://www.nikkan-gendai.com/articles/view/geinox/277220

哺乳類クラスを継承した犬クラスと猫クラスがあるんですよ。

これが理解できなくてオブジェクト指向に躓く人が多いんですね。

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
>チンポはお前自身のことであるっていったら

自分の体内にあっても、独立して自らの意思で勃起する不思議な生き物なんだが？

>>281
パッションを感じた

動物に例える　初心者を煙に巻くクソ講釈
チンコ　論外
通信処理実装の良し悪し　専用スレでやれ

んなとこですかね

あわしろ氏もそう言ってたね。

犬 is a 哺乳類。
犬 has a チンポ。

と、あわしろ氏に教わったけどな。

クラスの中にメソッドとプロパティを用意してなんとなく動きそうなコードを入れたらオブジェクト指向の完成

アランケイ「グラス…？　知らない子ですね…」

オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある
https://itnews.org/news_resources/269441?ref=index

オブジェクト指向が理解できなくて挫折した恨みで
これまたよくわかってない関数型とか持ち上げて
掲示板で“こっちが最新だから俺が偉い”なんて朝鮮人みたいなことやるのは勝手だが
オブジェクト指向はリアルタイム同期とれない処理の分離のための手法だから
プロセス同士の通信はオブジェクト指向で中身関数型になるだけで
おまえは結局永久にどこにも属さない頭わるいクズのままやぞ。

>>306
ガラケーのメリット・デメリットを理解した上で状況に応じて技術を選択できるようになることが一番重要

特にオブジェクト指向に対する理解は古いから必要がないと言って捨てられるような段階にはまだ至ってない

オブジェクト指向は不要と考えるのはオブジェクト指向が全てと考えるのと同程度に危険

正直、不要かなと思ってる。
アーキテクチャやテストの文脈でオブジェクト指向を語るのは意味あるが
設計に持ち込んだ話はロクでもない比喩表現で現場を混乱させるだけで何のメリットもなかったというところ。
バカがこれはオブジェクト指向だ、いや違うみたいなクソ議論で時間が際限なく減っていくという
生産性のかけらもない状況になる。

DDDは今一番うさんくさい

TDDも頭がおかしい

オブジェクト指向もDDDもTDDも同じ
二元思考や教条主義的思考をしてるうちは技術者としては未熟

TDDに対してはそこまで嫌悪感薄いかな。
確かにやりすぎだとは思うが、あれくらいやらないと全くテスト書かなかったってのが
この業界の状態だったし。

>>307
>オブジェクト指向はリアルタイム同期とれない処理の分離のための手法だから

だからこれがお前だけの勝手な定義だっていい加減気づけよ
釣りなのか？
赤の他人相手にマイ言語喋ってんじゃねーよ
一般的な意味をググってこいカス

>>314
>だからこれがお前だけの勝手な定義だっていい加減気づけよ

ならば「チンポがシコシコする」という日本語表現は、学術的に正しいと言えるのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

24 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (JP 0H82-LX7o [153.145.207.163]) 2019/11/23(土) 16:54:55.03 ID:l9637O/lH

Smalltalkなんてカーネルまでリアルタイム環境でしょ

胸がドキドキはI have Heart.の関係
my->heart->dokidoki();で表現できる

しかしチンポがシコシコは私のチンポ、私の手が並列な存在として登場している
my->hand->shikoshiko(my->chimpo())

あわしろ氏によると、チンポの多態性って事らしいぞ。

あわしろ氏によると、発生学的には男性のペニスと女性のクリトリスは相同器官ってことらしい。

>>320
オシッコの時のチンポと射精の時のチンポは、全く別なんだが？

オシッコは公開型(自我で制御可能)、射精は非公開型(自我で制御不能)、非カプセル型とカプセル型の使い分け。

Laravel使ってるんだけどDIとか言うのがわからん
interfaceを使って疎結合って何？

今のコードの書き方は依存しすぎててダメだと言うことは気づいたけど
それを治すための理屈が頭に入ってこない
interfaceとやらを使う利点がよくわからん

抽象的に依存するとか、もう意味のわからない単語が並んでる
誰か教えてくれ！

>>325
Laravelのサービスコンテナのドキュメント
https://readouble.com/laravel/6.x/ja/container.html
とりあえずここ読んで分からなければPHPのスレで聞いてくれ

>>325
たとえば、こういうクラスがあったとして
https://paiza.io/projects/EmYovJbLF2HVGHjC0SMeRA

ペットを犬から猫に変えたいときはCatクラスを作って
Personクラスを修正しないといけないっしょ

あるオブジェクトを変えるときにそれを使うオブジェクトにまで
変更を波及させないのがインターフェイスのメリット

こういうふうに、動物インターフェイスを作って
犬や猫のオブジェクトがそのインターフェイスを実装する
ようにすれば犬を猫に差し替えてもPersonクラスを修正する必要はないってこと


あるオブジェクトを使うとき、そのオブジェクトを直接参照すると、使う方が使われる方に依存してしまう
電球取り替えようとしたら本体まで取り替えないといけないみたいな状況になるんよ

インターフェイスを使うと使われる方が使うほうに依存するようにできる
図を見るとインターフェイスを使うことで人から犬の矢印が、逆向きになってるのがわかるっしょ
インターフェイスを使うと依存性を逆転させることができます

>>325
たぶんあんたの場合DI以前の問題
DIを導入した所で何も解決しない

そもそもDIは依存をなくしましょうパターンじゃない
（実装に依存するのではなくて）インターフェースの方に依存しましょうというパターン
インターフェースがわからないなら、それは実装とインターフェースが一体化してるということ
一体化してるということは、実装が一つに対してインターフェースも一つあるということ
そういう設計が駄目と言ってるわけじゃないし、実際実装が一つしかいらないならそうなる。

そういう状態で「依存しすぎて駄目だ」って気づいたんでしょ？
現在はコードが分類分けされてないどっかのコードに意味不明に
依存しまくっていてごちゃごちゃしてるだけだろう
それならDIで解決する問題じゃない。あんたがやらないといけないのは
コードを責務に合わせてちゃんとファイルに分離すること

そうやって分離して依存関係がスッキリしてきて、なおかつ単体テストをする時に
外部の依存をモックなどに入れ替えてテストしたいって時にDIがでてくる
モック以外でも設定ファイルで使用するモジュールを切り替える仕組みとかでDIは使えるんだが
そういう仕組にしたいときはDIを使わないでもDIに近い仕組みを自分で作るので
DIはほぼ単体テストをしやすくするためのものだと思っていい

>>297
役に立たない単発質問スレ立てといてこんなこと書くとかどこまでもクズ
自分で調べて自分で解決してクソスレ立てんな

>>331
あわしろ氏による分類では、どちらもオブジェクトになってるね。

>>330
役に立つかどうかは君が決めることじゃない（大正論）
僕はスレを立ててない（大事実）
君が調べて教えて欲しい、それが君の勉強です、君のためです（大説教）

オブジェクトアートでは？

僕のことは大先生と呼んでくれ

大先生って、もしかして、あわしろ氏ですか？

あわしろ氏って、いくやくんのこと？ かわいいよねいくやくん

もしかして、イクヤきゅんのチンポ、舐めたいですか？

>>326
読んでみる
わからなかったらPHPスレいくわ！

>>327
インターフェイス使えば、Personクラスを修正しなくていいっていうのが利点か
依存性を逆転させて、使うクラスの方は一生変えなくていいから楽ってことか
とりあえず、インターフェイスを注入しとけばいいって事だな
完全に理解した！

>>329
ちょっと何を言ってるのか理解できなかった・・・
実装が一つじゃなくて、増えてきたらインターフェイスを使わないといけないという事で
とりあえずインターフェイス注入しとけばいいという話ではない？

インターフェイス注入（笑）

依存注入ってあれしか思い浮かばない

>>339
同じインターフェースを持つクラスが複数あるか？ほとんどないだろ？
そうすると、クラスファイルのメソッド定義部分を取り出した
インターフェースファイルが出来上がるだけなんだよ

そしてどうせ後からクラスのメソッドが増えたり消したりだろ？
そうするとインターフェースもメソッド増やしたり消したりすることになるんだよ
つまりこれは単なる二度手間というわけだ

最低限、ここまではわかってないといけない

その上でやっと、それなのになぜDIを使うんだ？
DIのメリットはなんなんだ？という話ができる。

そしてこの話↑ができるレベルに達していれば

> 今のコードの書き方は依存しすぎててダメだと言うことは気づいたけど
「依存しすぎててダメ」という発言はしないんだよ
なぜなら、そんなに依存してないコードを書ける力があるから

力がない人が、とりあえずインターフェースを使ってれば〜いいってことだな！
みたいに言うと、本当に単なる二度手間で終わる。お前やるべきことだけ理解していて
やるべき理由を理解してないだろ。使うクラスを一生変えなくていいなんてことはないんだよ。

DIを使う理由は
1. （コードでやろうと思えば出来るけど）設定ファイルで使うクラスを変えられるようにしたい
2. 依存してるクラスをテストクラスに置き換えて、単体テストをしたい
この２つなんで、その話が出てないのに「依存しすぎててダメ」という話をしたのであれば
DIを使ったとしても「依存しすぎててダメ」＋「二度手間」にしかならない

DIうんぬんの前に「依存しすぎててダメ」と言う状態を
「頑張ったけどどうやってもここの依存を解消できない」と言うところまで持っていけ

○ 2. 依存してるクラスをテスト用の（ダミーの）クラスに置き換えて、単体テストをしたい

>>339
理解力といい考え方といい、君センスあるわ

>>345
なんでそんなレスしちゃったの？
友達とかでない限り、そんな褒める必要ないよねｗ

>>346
君がそんなに嫉妬する必要もないよｗ

嫉妬の意味がわからん。>>339のどのを読んで理解力やセンスがあると思ったのか？
下線だけでいいから引いてみて

誉めてるんじゃなく皮肉かもよ

なんで自分がほめられないんだと思ってるんでしょはいはい

僕で良ければよしよししてあげても良いけどどうする？

よく伸びるネタスレになったな

>>351
少しでもプログラミングの話をする気がある。出来る力があるなら
>343になにか言い返してみてくれよ

>>353
言い返すことはとくにないです

>>339と>>343の文章を比べて何も感じないのかな？

>>355
君は何を感じたの？ 僕は君の曖昧で思わせぶりな問いかけにイライラしてるんだ
簡潔に言ってくれないかね

はっきりと言語化して他人を説得できないのなら口をつぐんで貝になりなさい
海の底でアワビとして生きて高級食材として素潜り漁師に捕獲され
ヒルトンホテルの料理長に調理されてそれを口にした人を幸福にさせてれば良い
僕はそう思います

海の底で物言わぬ具になりたい♪

>>356
問いは相手に考えを促すことに存在価値があるからね

イライラするのは問いを発した相手が何らかの正答を想定してると思い込み、
その正答が自分では分からないから

自分の考えが相手と違っていたら減点評価されるかもという恐怖が刷り込まれてる
そういう考え方は学生のうちに早く捨てたほうがいいよ

>>357
言語化して他人を説得する必要なんてないからね
分からない相手を説得して無理に分からせようとするのは時間の無駄だから

>>357
>はっきりと言語化して他人を説得できないのなら

ならば「チンポがシコシコする」という言語化表現は、学術的に正しいと言えるのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、自ら勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

>>360
あ、できないのね

なんだできないのか、やっぱり君はアワビがお似合いだよ！

僕は君が説明できない理由を説明できるよ、君のそれは嫉妬です
なぜ他人が評価されて自分が評価されないのかという思いが君の意識の根底にあって
それと同時に嫉妬していることを認めなたくない思いもあるから本心は意識の底に
封じ込められてもやもや感となって意識の表層に現れているわけ、それを掘り下げられると困るから
問という形で誰かに説明責任を投げようとしたのだけれども、もやもや感を
きちんと説明できずに見破られたってこと、アワビ、君の心はすべてお見通しだ！

バナナマンのコント



これ面白いから見てみ、アワビ君の状況とそっくりだから

アワビ君のキメ台詞「時間の無駄だから」
かっこいいいい！！！！スコールでもこんなクールなこと言えないっしょおおおお！！！！！ひゅーひゅー！！！！

オブジェクト指向業界のスコールことアワビ君をこれからもよろしくお願いします

アワビ君を見出すためにこのスレは立てられたと言っても良いのでは!?

オブジェクト指向については、オブジェクト指向言語という「形式」を踏まえつつ、
オブジェクト指向とは何かを常に論じていきたい。



チンポは繋がっているが独立しており、チンポ自身の主体意思で勃起する！

あわしろ氏は、>>346 が正しいと言ってたな。

一日中何やってんだこいつ
他にすること無いのかな

>>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 ドッカンバトル』を見習うべきです。

>>425
DQXはやろうと思ったことあるんだけどパスワードをコピペで入力できなくて詰んだ

よく分からないから何でも取り敢えずDIっぽい構造にして
やってるうちに分かるだろって？
そんな奴がこの業界に居るだけで吐き気がする
他人の仕事を増やすだけだ
転職しろ

まぁ経験則で説明しようとして
上手く説明出来なかったんだろうね

俺が槍玉に挙げたのは説明を試みた奴の方じゃないんだが
俺の書き込みだけ見て文脈もまともに把握せずにレスしてんだろうけど
こうなレスする奴ばかりだとメチャクチャにしかならんな
5chって終わってるよな

>>423
> という発言といま君が言ってることは矛盾してるので

だから引用しろって
どの行とどの行が矛盾してるのか

>>430
その件につきましては>>429から説明させていただきます

>>431
意味不明な安価付けるなクソキモい

>>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
お前どっちもわかってないやんw