オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/06/11(日) 10:27:47.17

>>711
> 分岐さえ言語でサポートしてくれれば、ロジック部の自作はどんな言語でも可能で(チューリング同等)

仰りたいことは分かるのですが、マシン語やラムダ式ましてチューリングマシンで何かを記述するのは
知的愉しみや学術・学習目的でならともかく、通常のプログラミングにおいては苦痛しかもたらしません
生産性を考えるなら、言語の機能や特性は
車輪の再発明のしやすさより、あるレベルまでのレイヤーの適切な抽象化に費やされるべきです

そういう切り口でメッセージングというパラダイムはいろいろなレベルの抽象化されたレイヤーに乗っけて
便利に使えるので私は気に入っています

**デフォルトの名無しさん** · 2017/06/11(日) 13:31:27.60

なにこの気持ち悪いスレ

**デフォルトの名無しさん** · 2017/06/11(日) 14:03:25.44

Person taro = new Person();
みたいな典型的な文法使ってくれる文には問題ないが、
関数内や引数のカッコ内で new したり、
コンストラクタ内でさらに new したり、
Person(new Car() ) みたいにコンストラクタの引数内でnewしてたり、
オブジェクト名のはずが array['taro'] みたいにクォートで囲まれて
'文字列' として連想配列のキーに指定されたりすると、
俺の中での「オブジェクト」のイメージが色々と崩壊する。
これどう解釈すりゃいいの？ってなる。

**デフォルトの名無しさん** · 2017/06/11(日) 14:03:32.47

HaskellerとSmalltalkerの最底辺の争い

**デフォルトの名無しさん** · 2017/06/11(日) 14:36:30.58

>>714
お前のオブジェクトのイメージがおかしいんじゃね？

**デフォルトの名無しさん** · 2017/06/11(日) 16:54:46.48

オブジェクト指向は「playと言ったら"再生"のことだろう」って
コードのわかりやすさ優先だけど
関数言語は「?って書いたらPRINTのことに決まってるだろ」って
『略語でタイプが減ってサイコー』厨が推進してる臭くて
どうにも胡乱(うろん:確かでなく、怪しいこと。うさんくさいこと)なものを感じる。

**デフォルトの名無しさん** · 2017/06/11(日) 17:41:37.82

感想文

**デフォルトの名無しさん** · 2017/06/11(日) 20:23:12.88

Haskellは実装が簡単
オブジェクト指向言語はクラスリファレンスがすべて

**デフォルトの名無しさん** · 2017/06/12(月) 08:23:44.68

>>712
それって結局ライブラリが揃っていて、探しやすければオブジェクト指向とか構造化プログラミングとか関数型とかのパラダイムはどうでも良いって言ってる様なものだなと。
そして、実際その通りなんですが、全てのプログラムのパターンを網羅するライブラリは事実上不可能です。
Delphiのコンポーネントでpascalインタプリタがあってポトペタで一行のコードも書かずにpascal処理系を作れたとしても。
結局どの言語もライブラリの関数なりクラスなりを組み合わせます。
smalltalkは検索しやすい方向へ進化し、Haskellは自作しやすい方向に進化したんじゃ無いかと。

そのsmalltalkコードは出力に依存してますが、私もRubyやPythonでよく書きます。
Haskellの場合は強制的に出力に依存しないコードになるので、number.hsのコードの最後の行を

mapM_ (putFileContent.(\(f, c) -> (f, searchWord word c)))

の様にputFileContentの受け取る値を横取りしてsearchwordコマンドを作っても良いです。
型さえ考慮すればnumbering以降から出力直前まで、好きな段階でsearchWord関数を使えます。

numberingとsearchWordそれぞれlines/unlines使ってるので汎用性高い代わりに無駄な処理も多いと言うなら、汎用性を犠牲にしてsearchWordにnumberingの中身を入れてしまえば良いです。

この様に特異な発想？にも柔軟に答えてくれます。

**デフォルトの名無しさん** · 2017/06/12(月) 11:40:59.36

>>720
> 全てのプログラムのパターンを網羅するライブラリは事実上不可能

ライブラリで、将来起きうるすべてのパターンを網羅しろというのは極論では？
学習目的でないなら車輪の再発明は避けるべきだし
よく使うパターンならライブラリ化（抽象化）されるべきだろうという主張に対し
件のご指摘は本末を転倒しています

> そのsmalltalkコードは出力に依存してます

「出力に依存する」ということの意味がわかりにくいのですが
抽出結果を各行逐次出力しているのが気にくわないのでしょうか？

それならそうでない処理の流れにすれば済む話で実際にも容易に書けます
（>>706 の２番目や >>706 の http://ideone.com/xiEftE 、http://ideone.com/RUJP49 ）
当初要求された仕様がどうなっていたか、何を重視するかといった方針の齟齬に過ぎないと思います

逆にたとえばご呈示のHsakellのコードで
メモリに一気には読み込めない巨大なファイルを扱わなければならないとしたら
今の枠組みのまま対応することはできないでしょう？それと同じ話です

**デフォルトの名無しさん** · 2017/06/12(月) 12:20:40.28

？
遅延評価なのでどんなに巨大なファイルを一気に読む様なコードに見えても、実際には表示するぶんずつしか読み込まれませんが。。。

**デフォルトの名無しさん** · 2017/06/12(月) 13:05:25.72

>>722
何の話かよくわからんが、遅延評価と遅延読み込みは違う。
遅延読み込みと非同期読み込みも違う。
何か勘違いしてないか？

**デフォルトの名無しさん** · 2017/06/12(月) 13:43:22.37

>>721
同じライブラリ化されるべきなら、より簡単にライブラリが作れた方が良いんじゃないか？と考えます。

また、ライブラリやクラスを使う際にはオブジェクト指向も関数型も差はないでしょうが、ライブラリを作る側だとクラスは使う時より楽じゃないと感じます。

**デフォルトの名無しさん** · 2017/06/12(月) 13:58:04.43

>>723
普通の言語のreadLine的なのが遅延読み込みですよね？
Haskellは表示しない値は無いのと同じ、表示して再度使う予定もないなら用済み。
(その証拠に、読み込んで複雑な処理させるけど表示しないコードは、何が書かれていようとそもそも何もしない。無限リストを表示させるとかも良い例)

一見全部読む混んで全部表示するコード書いても、表示に必要な分だけ読み込んで、表示が終わったら破棄されていきます。
普通の言語の遅延読み込みに相当するものも、遅延評価が勝手に似た様な働きをしてくれます。
違うのは、行毎とは限らない事くらいです。

**デフォルトの名無しさん** · 2017/06/12(月) 14:54:51.94

>>722
失念していました。であれば別の例を考えないといけないですね^^;

要は「部分読み込み→処理→出力」というスキームで進めなければならないシチュエーションでは
今のコードの枠組みは変えざるを得ないということが言いたかっただけです

ところでHaskellのreadFileというのは賢そいのですね
たとえば一番最後の行から逆順に出力するような場合
getArgs >>= \(file:_) -> readFile file >>= putStrLn . unlines . reverse . lines
でもファイル全体を読み込まずに済ませられる（つまり読み込むポジションのみ覚えていて適宜移動して読み込める）程度に賢いのですか？

**デフォルトの名無しさん** · 2017/06/12(月) 16:50:34.40

>>726
そこは痛い所ですね。。。
賢くないはずです。
Haskell.orgも、その弱点を知ってるので良い加減克服されててもおかしくないですが。。。

少なくとも不思議の国のアリスやこころのテキストをwebからコピペして読ませてますが、reverseしないのと体感速度に差が無いですね。
(一文字ずつreverseさせれば流石に体感速度下がりましたが、行毎は感じませんでした)
今時はメモリもGBが当たり前なので余程じゃないと体感出来ないのかも。。。
まあ、すでに(ターミナル次第ですが)Python/Rubyより遅かったりしますけどね。。。
(全面ByteString使用する様に書き換えれば同程度には高速化するでしょうが)

書き捨てコード同士では負けますが、ライブラリ化したらPython/Rubyの書き捨てコードより短くなります。

**デフォルトの名無しさん** · 2017/06/12(月) 20:22:55.90

Haskellでさ、ファイルを読み込んでアルファベット小文字を大文字に置き換えて
読み込んだファイルに上書きできる？

**デフォルトの名無しさん** · 2017/06/13(火) 09:56:27.83

Haskellに限らず楽勝ですね。

**デフォルトの名無しさん** · 2017/06/13(火) 10:23:22.38

ウンコHaskellerには出来ないよ

**デフォルトの名無しさん** · 2017/06/13(火) 20:11:42.46

>>730
いやあ、同名のファイルに直で保存しようとするとロックされるの失念してた。
そう言えばtempファイルがどうとかどっかで読んだなぁとかRWH読んでたけど見つけられなくて、
でも一旦別名で書き込めばtempファイルにこだわる必要無いじゃんって事で元のファイル名の頭にoutって付けて一旦保存して、
それを開き、内容をそのまま元のファイルに書き込んだった。

これこそ発想の転換w

**デフォルトの名無しさん** · 2017/06/13(火) 20:26:50.47

そんな簡単なコードも書けない言語で
まともなシステムなんて書けないと思わない？

**デフォルトの名無しさん** · 2017/06/13(火) 20:31:40.86

ん？
書けたけど？
正攻法じゃなかったのはおいらの知識不足が問題であって、言語の問題じゃ無いよ？
それに発想の転換と言うか、知恵と工夫で解決するのは、どんな言語使ってても必要な事。
だからっておいらがプログラマに向いてるわけじゃ無いのは理解してるが。

**デフォルトの名無しさん** · 2017/06/13(火) 20:31:48.79

>>731
ちょっとググればやり方わかるのにそれすら調べもせずに幼稚で姑息な思いつきをしたり顔で「発想の転換」とか草
結局、readFileのブラックボックス化をよしとしてるからそういうことになるじゃないの
自慢の車輪の再発明のしやすさとやらは何処へ？

**デフォルトの名無しさん** · 2017/06/13(火) 21:33:59.97

少ない知識で作りたいものを作れるってのが利点だと思ってるからね。
車輪の再発明しやすいのも、その一環。
その宣伝のためにも敢えてあまりググらない。
ググって見つからないぐらいで作りたいものを作れなくなる様な言語じゃ困る。

**デフォルトの名無しさん** · 2017/06/13(火) 21:38:43.06

いやググれよHaskellerが馬鹿だと思われる

**デフォルトの名無しさん** · 2017/06/13(火) 22:21:04.68

そゆのは他の優秀なHaskellerに任せる。
おいらは実際頭悪いし。

**デフォルトの名無しさん** · 2017/06/13(火) 22:24:43.82

haskellにはカプセル化の概念がないんだよね

**デフォルトの名無しさん** · 2017/06/13(火) 22:28:26.94

カプセルすべきものがないからな

**デフォルトの名無しさん** · 2017/06/13(火) 22:30:05.60

カプセル化すべきものとは？

**デフォルトの名無しさん** · 2017/06/13(火) 22:31:18.19

つまりカプセル化はオブジェクト指向に本質的に必要ないものとなるわけですな

**デフォルトの名無しさん** · 2017/06/13(火) 22:32:14.23

本質的には何も必要ないよ？
オブジェクト指向をやりやすくするための
言語仕様を備えてるだけなんだから

**デフォルトの名無しさん** · 2017/06/13(火) 22:32:39.86

haskellはオブジェクト指向言語と言っていいでしょう

**デフォルトの名無しさん** · 2017/06/13(火) 22:34:25.58

>>742
何も？何もいらないのか？それでほんとにオブジェクト指向？なんか怪しいな

**デフォルトの名無しさん** · 2017/06/13(火) 22:42:17.98

条件分岐を書かないことで疎結合にする
これがオブジェクト指向の本質

**デフォルトの名無しさん** · 2017/06/14(水) 01:43:10.82

Haskellはモジュール単位で隠蔽機能がある。
モジュール公開側も公開したいものだけ指定出来るし、importする側も、さらに細かくこの関数だけ読み込むとか、この関数以外を読み込むとか、細かく指定出来る。

**デフォルトの名無しさん** · 2017/06/14(水) 01:47:53.66

>>743
オブジェクト指向もメソッドチェーンで宣言的プログラミングを目指したけど、何年経っても手続き的な側面を脱却出来ない時点で失敗作。
一緒にすんな。

**デフォルトの名無しさん** · 2017/06/14(水) 07:43:27.89

Haskellもモナドで手続きも書けるようにしたけど
モナドで手続き書くとマジ終わってるレベルで読みにくくて冗長
かと言ってHaskellでも性能出そうと思うと手続きを書かざるを得ない
つまりウンコ言語

**デフォルトの名無しさん** · 2017/06/14(水) 07:58:06.20

http://qiita.com/as_capabl/items/6919e338340690f37a92

実際には遅くて冗長
それがウンコ言語Haskell

**デフォルトの名無しさん** · 2017/06/14(水) 08:21:45.76

まだカプセル化不要とか言ってるバカが居るのか

**デフォルトの名無しさん** · 2017/06/14(水) 08:25:14.80

>>749
ネットに踊らされてないで自分でやってみなさい

**デフォルトの名無しさん** · 2017/06/14(水) 08:43:15.00

>>751
やってみた？

**デフォルトの名無しさん** · 2017/06/14(水) 08:45:08.83

>>750
カプセル化が必要だとするならそれは設計が間違っているというのがhaskellの議論で明らかになったわけです

**デフォルトの名無しさん** · 2017/06/14(水) 09:03:03.20

>>747
手続き型つまり構造化プログラミング
オブジェクト指向は構造化プログラミングの
延長線上にあるものだから手続き型は友達です
仲良くしましょう

**デフォルトの名無しさん** · 2017/06/14(水) 09:08:24.09

純粋関数型と呼ばれるどこぞの言語にもdoがあるでしょう
つまり手続き型は数学的モデルのあるちゃんとした方法なんです
それを駄目だと思うのは慣れすぎてマンネリ化してるからなんです

**デフォルトの名無しさん** · 2017/06/14(水) 09:10:44.44

原点に帰ろう
c言語からやり直そう
linuxはc言語で書かれていますが
完全にオブジェクト指向です

**デフォルトの名無しさん** · 2017/06/14(水) 09:42:08.75

>>753
前どこかのスレにコマンド引数の偶数番目と奇数番目を分けてリストに入れて、後から1、2番目を一つの組み。3、4番目を2つ目の組み。。。
みたいにして表示するコードをHaskellとPythonとRubyで書いたが、皮肉にもグローバル変数があっても良いはずのHaskellだけがグローバル変数作らないで済んで、
PythonとRubyはグローバル変数作らないとダメだった。

Pythonは書き様によってはグローバル変数無くせそうだったし、Rubyのsliceヒントに別の書き方のが全言語でグローバル変数要らなくなったし、シンプルになったけど。

**デフォルトの名無しさん** · 2017/06/14(水) 09:46:27.58

>>755
doの書き方は手続き型言語でも宣言的と呼ばれる関数(メソッド)呼び出しの羅列の再現。
ループとかの手続き丸出しなのの再現はあくまで再帰。
だが再現はループの代わりにもなるが、あくまで値を返す関数。
メソッドチェーンと同じで返ってくる値の型を意識する。

**デフォルトの名無しさん** · 2017/06/14(水) 09:47:28.86

x再現はループの
o再帰はループの

**デフォルトの名無しさん** · 2017/06/14(水) 10:38:47.08

カプセル化不要論者はぜひここのコメント欄で戦っていただきたい
http://qiita.com/tutinoco/items/6952b01e5fc38914ec4e

**デフォルトの名無しさん** · 2017/06/14(水) 10:50:09.06

>>757
> PythonとRubyはグローバル変数作らないとダメだった。

これ↓のどこでグローバル変数を作る必要があると？

print(list(zip(*[iter(sys.argv[1:])]*2)))

p ARGV[0...ARGV.size/2*2].each_slice(2).to_a

**デフォルトの名無しさん** · 2017/06/14(水) 11:07:50.39

>>761
お、そう書けるのね。
おいらPythonやRubyは(Haskellもそこまでじゃないけど)初心者程度だから。

そもそも重要なのは手続き型言語はグローバル変数がバグの温床になるのに、Python、Rubyじゃいとも簡単に作れちゃうって事ね。

Haskellみたいなグローバル変数がバグの温床になるわけじゃない言語でさえもパッケージ単位でカプセル化考慮されてるのに、初心者程グローバル変数宣言しちゃうし、出来ちゃうのは問題だよ。

**デフォルトの名無しさん** · 2017/06/14(水) 11:15:17.26

>>761
って、よく見たらsliceの方のアルゴリズムだし。。。
上でも、そっちはグローバル変数使わなかったって書いてるだろ。
コマンド引数の配列なりリストなりを

args!!i -- Haskell の場合
args[i] #Ruby、Pythonの場合

このインデックスのiを奇数か偶数か判定して、それぞれのリスト(配列)を作ってzipするアルゴリズムではグローバル変数使った。
おいらの力量のせいだったのかもしれんが、そう言う書き方に自然となったのが問題って話。

**デフォルトの名無しさん** · 2017/06/14(水) 11:51:06.96

おいら　とか言う奴は
オイラー　と被せてるの？

**デフォルトの名無しさん** · 2017/06/14(水) 12:07:52.90

たしかに20年ぶりくらいに見たな

**デフォルトの名無しさん** · 2017/06/14(水) 12:32:56.95

関数の中で処理したらいいじゃん

**デフォルトの名無しさん** · 2017/06/14(水) 12:49:59.35

>>763
ふつうに書けばシンプルに書けるものをなんでわざわざ複雑にせなあかんのかがわからん

p ARGV[0...ARGV.size/2*2].select.with_index{ |_,i| i.even? }.zip(ARGV.select.with_index{ |_,i| i.odd? })

**デフォルトの名無しさん** · 2017/06/14(水) 12:51:07.02

めっちゃ複雑やんｗ

**デフォルトの名無しさん** · 2017/06/14(水) 12:53:55.83

(function(){
処理
})();

JavaScript でも、グローバルスコープにしないため、ファイル全体を無名関数で囲む。
Rubyでも、囲めばよい

結局、囲むという事は、クラスと同じ。
関数・クロージャ・ブロック・ラムダ式など、どういう表現をしようが、
スコープがあるという事は、クラスと同じ

**デフォルトの名無しさん** · 2017/06/14(水) 12:55:47.63

>>764
その発想は無かった。

>>766
実はHaskellも最初リスト内包表記でグローバル変数作ってたんだけどね。
結局判定する関数のevenとoddしか違いが無かったからmakeList関数作って纏めただけなんだが、同じリスト内包表記あるPythonで同じ様にしようとしたらi % 2 == 0とか書かないといけなかったのね。
んで、まあ良いや。0か1かで奇数偶数分けられるから関数作っちゃえって思ったらエラー出た。
定数じゃないとダメっぽくて諦めたけど、リスト内包表記に拘らなければ関数に出来たと思う。
(もしくは将来的にリスト内包表記のif式に外部から変数渡せる様になったら作れる)

処理全体を関数にしちゃうってのは確かにグローバル変数を無くす有効な手段だが、初心者ほどそんな事しない。

**デフォルトの名無しさん** · 2017/06/14(水) 12:59:16.57

>>767
ファイル名とファイルの内容をzipするコード書いた後の実験的なコードだったんで、そう言う発想になった。
後でsliceなコードのが単純だし、グローバル変数使わないって気付いたけど。

ここではどうしても使わざるを得ない場面が出て来たってのを言いたかっただけ。

**デフォルトの名無しさん** · 2017/06/14(水) 17:49:45.05

ローカル変数で良くない？

**デフォルトの名無しさん** · 2017/06/14(水) 17:50:30.90

なんでグローバルにする必要があるんですかね？

**デフォルトの名無しさん** · 2017/06/14(水) 17:52:34.20

グローバルな人材を育てたいのかな？

**デフォルトの名無しさん** · 2017/06/14(水) 17:54:12.75

>>767
古き良きパールのようじゃ

**デフォルトの名無しさん** · 2017/06/14(水) 21:53:40.74

>>771
＞ここではどうしても使わざるを得ない場面が出て来たってのを言いたかっただけ。

それが間違いなんだって言ってんだろ
どうしようもないアホだな

**デフォルトの名無しさん** · 2017/06/14(水) 22:01:32.77

そもそも771は長くても10行程度のコードしか書けないクソ初心者だろ？
その規模じゃグローバル変数でも問題ないわ

**デフォルトの名無しさん** · 2017/06/14(水) 23:10:49.67

はいシングルトンも禁止

**デフォルトの名無しさん** · 2017/06/15(木) 01:45:19.51

もう継承、ポリモーフィズム、カプセル化も禁止でいいよ

**デフォルトの名無しさん** · 2017/06/15(木) 01:53:46.41

継承、実装、DIの違いをポケモンを例に説明してくれ。

**デフォルトの名無しさん** · 2017/06/15(木) 07:08:45.79

ポケモン進化、トレーニング、？

**デフォルトの名無しさん** · 2017/06/15(木) 08:21:04.78

>>776
間違いというか効率悪い方の例をわざわざあげてる意味わかってる？
この例に限らず、グローバル変数がバグの温床になるって分かってるのに、
どうしてもグローバル変数使わないと書けない場面があるから黙認されてるっていうのが、
もうオブジェクト指向はグローバル変数に対して根本的な解決策を持たない不完全なパラダイムだって証左だよ。

**デフォルトの名無しさん** · 2017/06/15(木) 09:25:01.12

>>782
Haskellだってどーしよーもないコード書くやついくらでもいるわ
お前はそのどーしよーもないコードの書き方すら知らない存外の低脳ってだけの話

**デフォルトの名無しさん** · 2017/06/16(金) 12:29:20.85

プログラムを勉強して日が浅いのですが、LSPを意識すると継承って何の意味があるんだろうと思ってしまいます

置換可能を実現できるということは、サブクラスはスーパークラスそのものってことになるような気がして

LSPの概念は、どう便利なのでしょうか

**デフォルトの名無しさん** · 2017/06/16(金) 13:56:31.30

グローバル変数が無いと書けない場面なんて無い
グローバルスコープのシングルトンオブジェクトでいい
必要ならね

**デフォルトの名無しさん** · 2017/06/16(金) 14:28:02.28

>>784
>サブクラスがスーパークラスそのもの

受けとる側の視点ではそれでいいんだよ

違いを意識する／したいのは渡す側

**デフォルトの名無しさん** · 2017/06/16(金) 19:13:51.77

>>786
なるほど、なんとなく解った気がします

あとは、どういうシュチュエーションで便利かモデリングの数をこなして覚えたいと思います

**デフォルトの名無しさん** · 2017/06/16(金) 20:00:04.73

>>787
まあ、低次元なことを言うと、
「いろいろサブクラスを作ったけど、受ける側の関数は全く変更せずに済んだ！わーい！」
てのがメリットの一例。

**デフォルトの名無しさん** · 2017/06/16(金) 20:55:27.26

interface

**デフォルトの名無しさん** · 2017/06/17(土) 02:54:17.87

メソッドディスパッチの問題だろ？

というBlogをみて「ああそれだよそれ、そういうのでいいんだよ」（孤独のグルメ風表現）になった

**デフォルトの名無しさん** · 2017/06/17(土) 11:41:41.30

第1目標:修正が他までどんどん波及していって修正地獄にならないようにする

なのに、変な原理原則マンに限ってそこがスッポリ抜けてたりするからな

**デフォルトの名無しさん** · 2017/06/17(土) 14:11:25.74

原理原則っつーか原理主義者っつーか
そもそもOOは原理といえるほど理屈がしっかりしてないだろ
複数のオブジェクトにまたがるメソッドをどこに実装しようかっていう初歩のレベルで
すっきりしないというのに
むろんマルチメソッドという考え方もあるけど、ほとんどのOOPには実装されてないしな

だから複数の色んなことを同時に考慮して、うまい具合にしなきゃならないっつーのに
原理原則とかでは無いわ

我々は空間と時間を両方扱っているわけで、片方だけに着目すりゃよいってものでもないわ

**デフォルトの名無しさん** · 2017/06/17(土) 14:15:26.57

第一、OO程度の原理原則に思考回路が縛られるって
潜在的に、そうとうオツムが弱いよな
世の中の理屈とかけ離れすぎているというか、単純化しすぎ

**デフォルトの名無しさん** · 2017/06/17(土) 15:24:12.75

>>792
> 複数のオブジェクトにまたがるメソッドをどこに実装しようかっていう初歩のレベルで

オブジェクト指向は、現実世界で実現しているオブジェクトに
ソフトウェアの設計を合わせようとするものだが、

現実世界のオブジェクトでは、
「複数のオブジェクトにまたがるメソッド」は
どこに実装されているんですか？

複数のオブジェクトにまたがるメソッドというものが
そもそも不自然なメソッドですよね？

**デフォルトの名無しさん** · 2017/06/17(土) 16:14:00.96

>>794
＞現実世界のオブジェクトでは、
＞「複数のオブジェクトにまたがるメソッド」は
＞どこに実装されているんですか？

物理法則に実装されてる

**デフォルトの名無しさん** · 2017/06/17(土) 16:33:38.51

物理法則の表現って因果関係的な形ではないよねー

**デフォルトの名無しさん** · 2017/06/17(土) 17:27:39.37

はい皆さん>>794を読んでください
もうこの時点でアホっぽいってわかるでしょ
ありえないぐらいで、釣りじゃないかと疑うぐらい

アホらしいけどまず基本的なことからいうと
コンピュータは日本語で「計算機」ともいうのでそっちの方向から攻めると
足し算は現実世界のどこに実装されているんですか？っていうぐらいアホなイチャモン

物や物体的なことにこだわって、概念的なことであるとか関係性といったものを
認めない姿勢は技術者ではない以前に、人間的ですらない

**デフォルトの名無しさん** · 2017/06/17(土) 17:38:01.77

>>795
物理法則っていうのは、

例えばすべての物体は引力があるとか？
あ、これ複数のオブジェクトにまたがるんじゃなくて
個々のオブジェクトに引力があるのか

例えば、熱を加えると発火するとか？
あ、これもその物体が変化するだけか

複数のオブジェクトにまたがるメソッドってなんですかね？

**デフォルトの名無しさん** · 2017/06/17(土) 17:40:22.96

>>797
数値を入力してボタンを押すと足し算を行うのは
計算機というオブジェクトが持ってる機能ですよね？
それとも電気信号レベルの話をすれば良いのですか？

そろばんでも足し算ができますが、
もしかしてこの２つを同一のものとみなしてるのですか？
そろばんは電気信号じゃなくて物体の位置で表現するって
だけですからね。

**デフォルトの名無しさん** · 2017/06/17(土) 18:01:41.38

アホか
数学上での足し算という「概念」の話だ
1に2を足すと3になるっていう概念上の関係性の話だ
別に現実世界に実装があるわけじゃないが、1に2を足すと3になるし、有用なんだよ
ついでに言うと、1とか2とかいう数字自体からして現実世界に実装が存在しているわけではない
1とか2はあくまで数学上の概念だ
もう本当にあほだなぁと思う、あきれて言葉も出ない
こうなったらもうエンジニアとして終わりなんだと思うし
人としても鬱病になる末路なんだろうか、知ったこっちゃないが

**デフォルトの名無しさん** · 2017/06/17(土) 18:08:50.48

>数値を入力してボタンを押すと足し算を行うのは
>計算機というオブジェクトが持ってる機能ですよね？
>それとも電気信号レベルの話をすれば良いのですか？

この発言もかなり面白くて、この言葉通りにプログラムをすれば
すべてのメソッドはコンピュータインスタンスに紐づくことになる
computer.add(1,2); computer.func(a,b,c);ってところか？
OOだなんだいったって、実際に処理をするのは「コンピュータ」
に他ならないんだから至極当然な意見だわなwww
たしかに現実世界を模してるわ
いわゆるGODクラス、staticおじさんと同じだ
つまりもう、自分がどういう立場をとっていて何を言っているのかすら
よくわかっていない状態ということだな
病的

**デフォルトの名無しさん** · 2017/06/17(土) 18:17:41.65

>>800
> 1に2を足すと3になるっていう概念上の関係性の話だ

1という値の数値オブジェクトに
2という数値オブジェクトを引数に
数値オブジェクトの加算メソッドを呼び出すと
3という数値オブジェクトになるって話？

**デフォルトの名無しさん** · 2017/06/17(土) 19:35:16.50

>>798
引力を物体間の相互作用じゃなくてオブジェクト単体で定義される性質と思ってんの？

**デフォルトの名無しさん** · 2017/06/17(土) 19:48:30.88

>>803
そりゃそうでしょｗ

地球の引力を計算するには、月の存在が必要だ！
などといったら笑われるよｗ

**デフォルトの名無しさん** · 2017/06/17(土) 20:34:57.52

ほらまたバカなこと言いだしたでしょ、すごいでしょ、この病気
俺がかなり煽った文体で書きこんでるのにもかかわらず
お前の援軍は誰も現れないでしょ、これが現実
頭悪すぎて他人の言っていることも自分の言っていることすら理解できないという
もうどうしようもない残念さで、誰も味方がいない

この手の人は本当にもうどうしようもなくて
かわいそうだからと周りの人が説得を試みても全くの無駄というか
普通の人が当たり前にできる思考が、どうにも理解できないらしく
必ず自分にわかる範囲で自分の領域に持ち込んで考えようとするんだが
その行為自体が間違っているってことが何故か分からないらしい
袋小路でとにかく打つ手なし

**デフォルトの名無しさん** · 2017/06/17(土) 20:38:27.45

駄文乙

**デフォルトの名無しさん** · 2017/06/17(土) 20:44:48.25

まず引力に関して言えば、引力という力の存在は認められているが
なぜ引力という力が働くのかということは
本当のところは誰にもわからない
つまりは表面上そう見えるからそういう力があるのだろうという程度のものであり
根本的な原理は未解明なので、誰が引力を実行しているかとか考えるだけバカ

あと本質的に>>803が言いたいのは、オブジェクトが一つしかなければ
引力など定義しても無意味だし、引力の効能は性質となって表れないから
定義もされないっていう意味だろう
まぁ一般的な考え方だな
世の中は極めて相対的だしな
お金の価値ですらそうだしな

**デフォルトの名無しさん** · 2017/06/17(土) 20:46:44.94

> オブジェクトが一つしかなければ
> 引力など定義しても無意味だし、

オブジェクトが一つしかない状態に限っていえば
無意味なんだと言われましても・・・

数字だって一つしかなければ
足し算は無意味ですよ？

**デフォルトの名無しさん** · 2017/06/17(土) 20:48:06.62

あ、そうか
マルチメソッドはオブジェクトが一つしかなければ無意味だ！
って言いたいんだな。

**デフォルトの名無しさん** · 2017/06/17(土) 21:15:05.61

わかりやすいところでWeb検索の例だと
Googleのページランクの仕組みは非常に現代的だったわな
たくさんあちこちからリンクが張られているページは有用性が高いのだろう
そして有用性の高いページからリンクが張られているページもまた有用性が
高いのだろうっていう
そんで、かつてのYAHOO方式は負けたわけだ
でも別に珍しいことではなくて、論文とかでもたくさん引用されている論文は
価値が高いってことになってるし、まぁ基本といいますか
たくさん友達のいる人は有能なんだろうってのも大体あってるし
取引先の多い企業、特に大企業との取引がある会社は信用が有るってのも
一般的な価値基準だわなぁ
資本主義に関しても、お金のような流動性のあるものに着目するっていうのが
現代的であるし、お金をどんどん回して経済を発展させようってのも
政治家の大好きな謳い文句だわな
大体世の中そういう構図になっているから、反対へ行く人や軽んじる人
もしくは君みたいに理解できない人は北朝鮮になる
ただ何事もバランスは大事なんだけど、そうはいってもどっちに軸足を置いておくか
ってのはあるわな
簡単な方の考え方は誰にでもできるし、意識する必要もないし、学ぶべき部分もないから
あまり重要視されないんだけど、本音と建て前みたいな話にもなってくるわ
ただ、とっちが建前になってどっちが本音になるかは相手とシチュエーションによるという
つまり俺もOOPを、「使う」わけだが、いつも「必要悪」という考えはある
絶えず反対のことを考えながら吟味してOOする
そのぐらいでちょうど良いバランス
ただ、本音と建前の世界なのでコンセンサスが取りにくい
hpXZLyYVみたいなのが入ってくると破たんする
いちいち面倒くさいんでLinusがC++を追い出す気持ちもわかる
OOPをおもちゃにする奴はマジで糞

**デフォルトの名無しさん** · 2017/06/17(土) 21:26:18.74

あと、物理量としての引力、っつーか質量と、相互作用としての引力の働き
では差があるわな
しかも現実世界の引力のメカニズムは解明されていない
どういう理屈で力が働くのかとか、だれにも分からん

>例えばすべての物体は引力があるとか？
>あ、これ複数のオブジェクトにまたがるんじゃなくて
>個々のオブジェクトに引力があるのか

「個々のオブジェクトに引力がある」って何ですか？
すべての人には年齢がある、と同じノリですか？