オブジェクト指向は愚かな考え。この世は計算式 ★3©2ch.net
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
https://twitter.com/ProgrammingMono/status/665702678006140928
研究グループは、血管新生注において血管が伸長する際の血管内皮細胞注運動を制御するしくみを、生物学と数理モデル・
コンピュータシミュレーションを融合させた先端的な研究手法により明らかにしました。
生物は、最小の機能単位である細胞が寄り集まった多細胞体です。しかし、細胞の集まりが、組織や器官といった
秩序ある形態や構造をつくり機能するしくみはほとんど分かっていません。中でも血管は、体中の全組織に十分な
酸素や栄養源を効率よく供給するため、組織や組織の間に入り込み、血管外の環境との相互作用により、巧妙な
枝分かれ構造をとっています。
これまでに本研究グループは、新しく血管がつくられる（血管新生）際の細胞の動きに着目し、特に血管内皮細胞の
動きをリアルタイムで可視化し、定量的に捉えることを可能にしてきました。
今回さらに、血管の伸長を制御するしくみについて、細胞が自発的に自らを制御して動く過程（自律的過程）と、
隣接した細胞から適宜影響を受けて動く過程（協調的過程）がうまく共存することで、全体の動きが巧みに統制
されていることを世界に先駆けて実証しました。
興味深いことに、血管内皮細胞が前後したり、お互いに追い抜きあったりという血管新生で見られる複雑な細胞集団の
動きを制御している中枢部分は、細胞一つ一つの動き（スピードと方向性）の「確率的な変化」として十分説明できる
ことをコンピュータシミュレーションで実証しました。
http://www.jst.go.jp/pr/announce/20151120-2/#YOUGO3
前スレ
オブジェクト指向は愚かな考え。この世は計算式 ★2
http://peace.2ch.net/test/read.cgi/tech/1450153388/ オブジェクト指向は直観に反するんだよな。
こいつを見てくれ。
http://pbs.twimg.com/media/CW4jn4jUkAAqIlA.jpg
Coffeeオブジェクトに振る舞いがある。これはオブジェクト指向的に完全に正しい。
しかし、現実にコーヒーを飲むのは人間だ。コーヒーは人間によってカップに注がれる存在だ。
これが思考を混乱させる。オブジェクト指向に従うとよくわからないソースコードのできあがりだ。
データに振る舞いを持たせるのは大失敗だと言わざるを得ない。 空かどうか判定するEmpty()を定義したCupクラスとLiquidクラスを継承したCoffeeクラスを作って、HumanクラスにRefill(Cup,Liquid),Drink(Cup)を定義すればいいだけだ
if(cup.Empty())
{
human.Refill(cup,coffee);
}
else
{
human.Drink(Cup);
} コーヒーの属性定義が広範囲すぎる
量をのオブジェクトに突然､実態コーヒーを入れている
量のオブジェクトの範囲のクラスを作っる
コーヒークラスに量をコンポジションさせる
設計の間違え >>4
単純。
コーヒーはただの量であり、人間オブジェクトの一変数だ。
いや、コーヒーはオブジェクトであり、生成からの時間により温度変数の値が変わる。
いや、コーヒー生成の時刻を保持するのは人間であり、コーヒーの温度を計算するのは人間である。
いや、コーヒーはコーヒーサーバーオブジェクトの変数であり、、、、 >>5
ま^､これでもいいがこれをオブジェクト指向と思っている時点で
何をやっても後が大変｡ >>8
目的次第としか言えんわ
直感的なコードが求められるなら>>5ってだけ その直感が､直感的だと思う時点
斜め直感にしか見えん すまん、自動で口にコーヒー注いでくれない前時代のコップ使ってる雑魚おる？ 現実をそのままモデル化してOO否定って5周くらい遅れとるで 形式主義ではコーヒーを椅子に置き換えても成り立つってことをいいたいんじゃないのか。 >>14
>>4は現実をそのままモデル化できていない。
大事なのは、そのままモデル化するのではなく、どうモデル化するかなのだ。 まー初心者(OOだけでなくプログラミング全般の初心者)向けのオブジェクト指向の解説とかでよくある説明だよね。
「オブジェクトとは日本語で物、対象物などという意味です」みたいなさ。とっかかりとしては平易なためによく使われているけど、
数学の定義のように後生大事にするべき、応用の効く、正しいイメージじゃない。 メソッドに何かやらせるのはやめて全て物理演算で動作を決めるべき コンピュータ内でシミュレートするのではなく実際の分子原子を用いるべき そんなことしたら分子原子の仕様変更で全てがひっくり返るぞ メソッドコールのかわりにオブジェクトに対するフォースとトルクを搭載した言語を作ればいい beDrank, beRefilledにかえればいいだけだろ。 >>25
drinkに渡すのはcup.contentsとかにする？ >>4は一般的なコーヒーのモデル化じゃなくて
コーヒーの消費が常態化したマの皮肉じゃないの
最後にコメント付いてるし >>25-27
こんな議論になる時点でオブジェクト指向はヤバいだろ >>9
そこまでしてオブジェクト指向にこだわる意味がわからない。
そんなもんperlやrubyのワンライナーですませろよ オブジェクト指向も結局はコミュニケーションというか
メソッド(関数)指向という方が正しい。
結局はメソッド(関数)をどのように呼ばれるか、まとめられるかってことだから。 メソッドは関数ではない
メソッドとは特定のオブジェクトにのみ適用可能な手続きであり、
関数とは特定のオブジェクトに依存しないものである
特に純粋関数は状態にも依存せず、参照等価性が成り立つものである
ところでオブジェクトが状態を持たず、メソッドを持たなければ、
それは単なるデータ(例えばハッシュマップ)と同じである
従ってオブジェクトというものは状態、及びメソッドの存在を暗示している
オブジェクト志向とは全てのものを変更可能なデータ（言い換えればエンティティ）とメソッドで表そうという観念である
関数型はそれに反して極力多くのものを変更不可能なデータ（値）と関数で表そうとする
ここの話はいわゆるドメイン駆動設計にも絡んでいる
どちらが、現実世界の捨象に有用であるかということが問題なのである オブジェクト志向で実装可能なことは、原理的に関数型でも実装可能であり
関数型で実装可能なことは原理的にオブジェクト志向でも実装可能なはずである
関数はオブジェクト志向においては、staticクラスを使えば実装できる
メソッドは関数型においては、第一引数によって動作を変更するポリモーフィズムとして実装できる
問題はどちらが汎化に適しているかということなのである
関数型にはオブジェクト指向では綺麗に実装できない麗としてマルチメソッドというものがある
これは第一引数及び第二引数＋・・・の型を持ってして動作を変更するという技であるが、
特定のオブジェクトに依存しているオブジェクトにおいてはこれはif文を内包したディスパッチをする他に実装する方法はないだろう
一方staticクラスによる関数のパッケージ化は煩雑である
必要な関数だけをインポートするには、その関数を内包したstaticクラスをインポートする必要がある
もしここで厳密なカプセル化を適用するならば、
1つの関数のために1つのクラスを使う必要がある、さもなくば利用可能でない関数も同時にインポートしてしまう
カプセル化もまた、オブジェクト志向の特権ではないのである
関数型は関数をカプセル化しているのである
そして変数のカプセル化もまたクロージャで実装できる
オブジェクト志向での変数のカプセル化は容易ではあるが、本当に変数はカプセル化されるべきか
それが私の問いなのである >>37
その問いにおける「変数」とは状態のことであるから、
それは構造化・カプセル化によってアクセス制限されるべきなのは明らか。 >>1>>4
結局のところ、この問題に誰もが納得するシンプルな回答を示せない奴が設計するからデスマーチになるんだろ。 自分も参加してるプロジェクトでデスマが起こるなら多分自分にも原因があるんだと思うよ >>4
そもそもなんでコーヒーに命令するとコーヒーが自分で動作してんだよ。
そんなコーヒーがあるかw
いきなり設計段階から間違ってるじゃねーか
どう考えても最後の"//I am a software developer"って時点で
そういう設計をやらかす>>4みてぇなバカを揶揄したセルフパロじゃんかw ああ、ジョークまで完全に見えた
>>4は「プログラマがコーヒーを飲む」じゃなくて
「コーヒーがプログラマに飲まれる」って逆転ジョークで
絶え間なくコーヒーが自動的にプログラマに注がれ続ける
おかしな逆転コードでプログラマジョークになってんだ。
「こいつをみてくれ」じゃねーよ！プププ >>36-37 が大嘘であることはOCamlの存在が証明している こういう根本的に理解できてないのが大量に居る時点で、オブジェクト指向は愚かな考えｗ コーヒーはどうでもいいけど、
2.log() とか数に数学的関数計算をくっつけるってどうなのよ？
気持ち悪いったらありゃしねえ。 数学みたいにlog(2)でいいと思うが。
その()は何のためにあるんだと言いたい。 大分昔だけどフリー関数は気持ち悪くて、1.sin()とか1.cos()とか書けるのが本来の在り方だ、といった
痛い記事を読んだ記憶がある。Rubyがらみだったかなあ。
今ちょっと検索すると見つからないから俺の妄想なのかもしれん。 数字は計算をしないからそう書いちゃいかんのだけどな >>46
> 何のため
関数そのものなのか、関数を呼び出した結果なのかを区別する括弧。
括弧がなければ関数そのもの、あれば関数呼び出しの結果。
括弧がなければlogという関数そのもの、あればlog(hoge)の計算結果。
かどうかは言語による。 >>45
こういう主語述語みたいなくだらない議論に陥るのがオブジェクト指向の最大の問題点だな
どっちでもいいからそのためのテストなりサンプルコードをがつがつ作ってくれれば問題ないんだが
糞みたいな議論ばっかりふっかける輩を生むところが最大の問題点だな。 >>53
何も考えずに作業こなすだけの社畜 VS 議論ばかりやる頭でっかち ファイッ！！ >>53
ドット構文を変な風に使うバカの問題であってオブジェクト指向関係ないな。 主語述語っていうけど、オブジェクトは目的語だからね 昔ながらのfunc( obj ); 形式だと、オブジェクトを主語と考える人はいないだろうし
obj.func(); は↑が変形したものにすぎないから同じ理屈だよね
しかも時期C++ではfunc( obj )でもobj.func()でもどちらの形式でも呼び出せるようにするって
C++の超偉い人がやる気満々だし、見た目は最早重要ではないよね
普通に考えると、主語はコンピュータや処理系だね
プログラミングを全然知らない人でも、主語は誰？って聞いたらコンピュータって答えるだろうね
何するにしても、結局実行するのはコンピュータだからね
これが全く現実世界でおこっている物理現象なのに、あえてオブジェクトを主語という風に
ひねくれた別な観点で考え直す必要は無いね
現実世界に合わせて、主語をコンピュータ、オブジェクトを目的語、関数を述語、と捉えると
それで多態や継承が出来なくなるっつーんなら困るけど、そういうわけではないからね
だったら現実世界で起こっていることに合わせて考えたほうが自然だね メッセージングのオブジェクト指向の言い方で言うと、
主語はメッセージのレシーバであり、文の残りはメッセージだ >>58
x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。
どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想（？）の根源は何なんだ？ 演算子前置のポーランド記法は嫌いだなぁ
存在する意味がわからないレベルで嫌い。
演算子後置の逆ポーランドじゃないとね。 > 存在する意味がわからないレベルで嫌い。
なんで？
> 演算子後置の逆ポーランドじゃないとね。
なんで？ Add 3 to 5, then multiple it by 2. 逆ポーランドの方が実装しやすいと思う。
人それぞれの範疇だが。 >逆ポーランドの方が実装しやすいと思う。
意味がわからん。
構文木作るのに一番前と後でなんか変わるか？
AST作らずにそのまま逐次実行するならスタックに
積むだけでいい逆ポーランドの方がいいかもしれんが x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。
どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想（？）の根源は何なんだ？
違うよな
どちらがオブジェクト志向的かといえばx.sin()でしょ
xというオブジェクトにsin()というメソッドが属しているという考えなんだから
sin()は関数に対してxというオブジェクト、あるいは単にデータを引き渡しているだけ
後者は明らかに関数的な考え方、動詞優位 関数へのエイリアスのようなメソッドはドットで繋ぐのでなく、
別の文字にした方がいいよな。 釣りじゃなくて単に本当にあたまおかしいのかな？
Xはデータであって演算ではない。Xは演算しない。
Xをオブジェクトとして扱った場合、その操作として実装されるメソッドは
データのゲットセットなど内部状態を隠蔽するためのメソッドと
可変不変などのデータ状態をあらわすメソッド。
まだお前の脳内じゃおまえがコーヒーを飲むんじゃなくて
コーヒーが勝手に口に飛び込んで来てんのか。 x.sin()は手続き言語的だと思うけどなあ
もちろんsin(x)も。
オブジェクト指向ならメッセージを送るような記述の方が自然では 現実世界をオブジェクト指向に当てはめるやついるけど馬鹿だよなー
コーヒーが勝手に口まで運ばれてくる機能をコーヒにつけただけじゃんw
ついでにコーヒーがしゃべる機能もつけたよ。
問題がないからそういう設計にしたんですよ どちらがより汎化されているかではなく
具体例で語ろうとする人間は、プログラムを実装したことがないのでは？
具体的な手続きによる具体的な文字通りのプログラムを書きたいなら
Cでかいてどうぞ オブジェクト指向だろうと関数志向だろうとやってることは変わらない
オブジェクトはメソッドの第一引数でしかない
コーヒーを飲むという行為を書くためには手続き的に書くしか無い
コーヒーが俺の口の中にあるという結果を宣言的に書きたいのに
その手続きを丹念に描写したいならそうすればいい
I.drink(coffee)と書けばいいんだよ
I.drink(coffee)とyou.drink(coffee)は飲み方が違う！というのならそう実装すればよい
モデリングとは物事を単純化する行為、汎化する行為であって具象化する行為ではない
Iとyouの違いがモデルのキーポイントなら、Iとyouという（メソッドの第一引数）をパラメータに加えればいいし
そうでないなら含まないほうがモデルがシンプルに保たれる
数学ができない自称モデラーはプログラムを手続き的に書いたらいいんだよ 特化させたいのに汎化する必要ある？
狭い世界で使うなら特化させていい。
広い世界で使うなら汎化させる。
それだけ。 >>74
言ってることはわかるがコーヒーを主語に対象を汎化なら
coffee1.drunkBy(me);
coffee2.drunkBy(you);
だろ >>72
普通モデリングなんて想定される実装の多さや効率の問題で変えるものだからね
感性にまかせる初心者ほど文脈や抽象に拘って依存性の上下を無視するよ アクセル→エンジン→ギア→タイヤじゃなくて
タイヤ.回転で自動車設計してそうだなおまえら。 >>79
そうやって現実の構造を想定している時点でもう駄目なんだよ ちうかこれオブジェクトが目的語とか言ってる人か？
英語とプログラミングのobject混同とかとてもまともとは思えないよ >>74
JavaScriptだと実際foo.barは第０番目の引数を指定するための糖衣構文でしか無い
オブジェクト指向は別にそんな大したものでも、手続き型と相容れないものでもない
指向とは言うが実際の所スタイルの一部だね >>82
そういう嘘をまき散らさないでもらいたいなあ。
毛の人といい、技術の普及は嘘との戦いだな。
オブジェクト指向は嘘つきが多すぎた。 >>68
いいえ。
sin(x) と書いたときのsinは十分オブジェクトに見えるでしょ。
xとsinは違う階層（空間）に属するモノだけど、後者の方が階層としては高い。
x.sin()と書くと、あるオブジェクトが自分より高い階層のオブジェクトを所有しているように見えてしまう。
これは俺にとっては不自然なので好きになれない。 オブジェクト指向は手続き型と直行する概念だと理解してないのが何人かいるな >>80
"現実の構造を想定しちゃダメ"て
おまえの作るシステムはどんな現実離れした
脳内妄想ベースなんだよ。 sinは関数だろね。
テーブルを持つためにクラスを使わなければならない言語があったとしても、
極力、ユーザーにとって関数に見えるように実装するべきじゃないのかな。 >>79
君が設計する自動車ではエンジンブレーキが効かないようだな。 ブレーキなんてのは外部から
ベクトルの力を操作するんだから
後付けで全然構わないんだが。 関数を手続きだと思ってるならそれでいいけど、名前が関数ってだけで数学関数をそういうカテゴリーのものとするのは不適当でしょうね。 クロージャーって、関数なの？オブジェクトなの？
rubyだとProcのインスタンスでしかないよね >>91
わからないなら無理に口を挟まないほうがいいよ。 >>92
関数が状態を持つべきかどうか考えると自ずと答えが出るのではないだろうか。 sin(x)は関数の値であって関数ではないよな。 関数は∀x∈double.sin(x)のことだよな。 >>85
実装がどうあれ、OOPではメソッドはオブジェクトに属するものとして考えるから、
x.sin(value)の表記は不自然じゃ無いだろ。sinはオブジェクトxに属している。 >>97
それは不自然な考え方じゃないかな。
原点に立ち返ってみると、オブジェクト志向とはコード再利用に際して
コンポーネント化の要求から発生したもの。
現実に存在する物のように、ディスプレイ上のウィンドウに四角形を
描画しろとメッセージを送るというようなシンプルなものだ。
この場合、四角形自体がオブジェクトであることは問題が無いように感じる。
これは、四角形が状態を保持しているからかもしれない。
一方、数値に対してsinを要求するのは突拍子もないように感じる。
これは、数値を日常いたるところで使用していて、数値がメッセージを受け取る性質を
もたないと良く知ってるからではないだろうか。
あるいは計算機オブジェクトに対してsinを要求するなら不自然に感じないのかもしれない。
どうだろうか？ この種のくそ議論って恣意的な答えしかないんだから、
議論するだけ無駄なんだけどねぇ。 >>95
状態をもつかどうかは実装しだい。
関数を初期化するとき係数のセットを与えるとかあると思う。
関数がグループとしてまとまって環をなすとか つか、sin(x)ってなんやねんw
引数無しのメソッドの話か？ それならsinは例として不適当だ。
sinを例にするなら、x.sin(value) か、sin(x, value) だろ。 >>97
そりゃメソッドはオブジェクトに属するだろ。
メソッドとして位置付けるのが適切かどうかの議論をしてるんだよ。 こういうシンプルな考えに基づくと、四角形と三角形は形状クラスから
派生すると思われる。
しかし、四角形オブジェクトと三角形オブジェクトの合成メソッドは、形状クラスあるいは
その派生クラスにあってはならないように感じる。
それは形状合成器クラスに、あるいは単純な関数であった方が良いように感じる。 >>87
物理的構造物とは違うんだよ
それすら理解できないならもう向いてないとしか 例えばゲームでキャラクターが特定のアイテムを使用するモデル
キャラ.使う(アイテム)はもらうアイテムによってメソッドの動作を変える必要があるが
設計としてはアイテム.適用(キャラ)のが遥かに取り回しやすい
なのにあえて前者のクソ設計を選ぶのが>>87のようなオバカさん >>102
それならOOPの議論じゃないな。
>>105
いや、属する/所有するという概念の方が適当だと思う。（実装は違うが）
実際クラスを書くときそう書くだろ。 >>101
現実の姿を模すという意味だとsinなどは連想配列であって、sin(x)という書き方はそのまんまだよね。
実装においては計算手続きだろうけど。 Smalltalkerが引き上げたらもう初心者しか残ってないのかよ そもそもクラスだってオブジェクト指向とは直接関係ない
>>84
嘘ではなく現実だ 美少女が云々言うのも一般的なクラスベースは融通が効かないねという話であって
オブジェクト指向とは直接関係ないし >>111
ほう、それならウンコをしない美少女をオブジェクト指向で設計して貰おうか >>97
見逃したいたが、x.sin(value)の value って何だい？ >>113
引数だよ。
クラスxのメソッドsinに渡す引数。
俺はそういう話をしてると思ったから。 xって中身は例えばfloatのデータ自身だぞ？
だから、引数は必要ないんだぞ？ >>115
理解した。
それなら、x.sin() なんて形が出てくる余地は無いよな。 一般に sin に必要な引数は、 pi/2 とかの実数(もしくは複素数) かな。
あとはいくつまでの級数和をとるとか何桁まで計算するとかが引数になるんじゃないかね。
その辺をあいまいなまま value とか x がクラスだの引数だの言ってることに何か意味があると思ってんのかね。 >>117
いや、sinの引数がオブジェクトの場合はあるよ。
実数や10進型をクラスで表現したりするし、俺も実際やる。
xがそういうオブジェクトなら、sin(x)でいいし、x.sin()はおかしい。
まあ絶対におかしいとか無理ってわけじゃないけどなw 新しいC++ではsin(x)でもx.sin()でも、どちらの方法でも統一的に呼び出せるようになる予定だから
こんな議論は全く意味ないんだよ？
呼び出す側からしたら、sinがメンバ関数だろうが外部関数だろうが、何であれ、知ったことではないからね
気にしなければならないのは実装する側だけ
だからどちらの方法でも呼び出せるようになる、らしい
どちらの方法でも呼び出せるんだから、喧嘩する必要ないし、気にする必要ないよね どちらの方法でも呼び出せるんだから
どちらの方が、よりオブジェクト指向的か、考えるのは意味がないんだよ
等しいわけ、等価と考えてよい
見た目が違うだけ
大した問題じゃない こんなにややこしいプログラムがオブジェクト指向を使って
こんなに簡潔になりましたって事例が欲しい >>112
思うんだけど、
うんｋをしないというのが、
意思を持ってひたすら我慢して（人の目がある場所では）しないのか、
それとも腸内の美少女菌のおかげでする必要が無いのか、
もしくは他の何かなのかによってイメージが変わってくると思う。
でもしないにしろする必要がないにしろ、排便メソッド自体は備わっててもなんら問題ないと思う。
逆に、腸内やなんかの問題を解決せずに、排便メソッドだけ外して他を流用するということは、
オブジェクト指向的であろうがなかろうが不可能だと思う。
それこそ亞人として設計しなおして全ての手続やメソッドを別に用意することが妥当かもしれない。
だから結論を言うと、この例はそもそも良くないと思う。 >>122
サイズを持っていてくれるのですら俺は嬉しいと思う
文字列や配列を扱うとき
int string::size() {return strlen(data);} // 数える関数を使うって例
↑こーいうのじゃなくて
int string::size() {return end - begin;} // 簡単な計算（ポインタの差分）で返す
int string::size() {return size;} // 内部でケアしていたprivate変数を返す
こういう実装をしうるのが嬉しい
使うときに
a = s.size * s.size / s.size % s.size
みたいにいっぱい呼び出しても安心
逆に言うとせっかく用意されたsizeメソッドが内部で数えなおしてる場合はつまらないと思う >>112
美少女はマーカーインターフェースであり、
美少女として扱うとき排便は隠蔽される。
interface 美少女 {
}
class おっさん implements 美少女 {
void 排便() {
}
} >>126
それは「何もしない」という排便メソッドを持つ
持たない，ではない >>127
何を言うてんの？排便メソッドを持つのはおっさんだよ。 オブジェクト志向の考えだと
大便ableインターフェースを実装するんだろ 美少女クラスを欲する奴が美少女のウンコがついたぱんつを欲しがらないかと考えると
これは要件定義から間違っているような気がしてならない。 実装からメソッド設計を考えるより使い方から設計したほうが上手く行くと思う
つまり美少女がうんこ出来るのか、出来ないのかで考えるのでは無く美少女にうんこをさせたいのか、うんこさせたくないのかで考える 肛門はコンポーネントとしてアタッチする。
美少女は肛門をインプリメントしていない 関数型言語っていい点もあるけど、変更に弱過ぎない?
ちょっと動作を変えるのにかなり見直さないといけない >>138
関数型言語を使えば完璧なプログラミングが可能なので後から変更する必要が無い。 >>140
完璧なプログラミングは出来ても
将来の仕様の変化を完璧に予測することは出来ないでしょ？ オブジェクト指向は細かい修正で済むと手を抜き続けた結果メチャクチャ悲惨なことになる
全て書き直すくらいがちょうどいい 関数型言語は仕様変更のたびにめちゃくちゃ悲惨なことをしなければならないのか 関数型言語にとって型とはプログラムの設計図なのである。 >>155
関数型じゃなくてお前を馬鹿にしてるんだよｗ >>157
ああそう、なら良いんだ。
関数型馬鹿にしたら唐沢弁護士に頼んで勝訴しちゃうからね？ 関数型に不可能はない。関数型は神にのみ扱える至高の言語
関数型を疑ってはならない。汝の実力を疑え 広く使われてて実用的な言語は多かれ少なかれマルチパラダイム
関数型っていうのも結局は作者がそう言ってるかどうかの線引でしか無い
理想的な関数型gwンゴを想定してなにか言うのはあまり意味が無い 関数型ンゴwwwwwwwwwwwwwwwwwwwwwwwwwww 今時は大学とかでも言語比較とか講義しているのかな。 「オブジェクト指向プログラミングの例を挙げましょう。2000年代には、オブジェクト指向プログラミングは、企業向けプログラミングにおける基盤的技術の地位を確立したと思われていました。
しかし今では、私を含めて多くの人が、この潮流は20年間に渡って本流から逸れていたものであり、そのほとんどが間違いだったと考えています。」
コーディングを学ぶこと、それはあなたが考えるよりも大変です
http://postd.cc/learn-to-code-its-harder-than-you-think/ >>173
記事のベースはイギリスのプログラマ教育のあり方と社会地位の話で
"大学で教えていることが現場で役に立たない"ことと
"高級技術者としてのプログラマの社会的地位の低さ"について
そして、前者関連の話で「教えるべき技術は次々と移り変わる」例として
オブジェクト指向を挙げてみてるが、筆者があまり理解してる感じではないなぁ…
20年前なら単語そのまま「構造化プログラミング」に置き換えて書かれた
単なる流行りワードの扱いだわな。 また、書かれている内容のとおりイギリスのプログラミング技術のほとんどが
学校教育ではなく「独学」で学ばねばならないもので、その上でガチで
『しかし今では、私を含めて多くの人が、この潮流は20年間に渡って
本流から逸れていたものであり、そのほとんどが間違いだったと考えています。』
と、思ってるとしたら本当にイギリスのプログラミング業界界隈の危機は
深刻なものだと考えざるをえない… >>176
>>173のリンクを読んだ感じではイギリスではどうも国を挙げて
学校や社会人教育で「無償で国民にプログラミングを学ばせる」事業をやってたっぽい
で、たぶん日本でやってもそうなるだろうけれど
みんな合格するようなレベルの簡単な内容なので
わざわざ教える意味がない的な事態になったっぽい？
大学の情報学科だったら日本でもまぁ直でコーディングの役には立たんが
逆に大学レベルの情報工学理論面を広く教えるから
オブジェクト指向なんて～って池沼はでないだろう(皮肉 コードの奇麗さはなになに指向とかとはいつだって無相関だよ。 それはツールに設定したルールを守ってるかの判別器でしか無いな。
本当に一般的に綺麗なコードとやらを図るには、
統計を集めて機械学習でもさせる必要があるだろう。
もしくは綺麗というのが、編集しやすいということなら
最低きちんとした理論と根拠を元に基準を決めるべき。
今の基準の多くはただ作者の信念だったり、狭い範囲での多数はを取っているだけ。 コードとは言語だから、綺麗な英語と置き換えてみればわかる。 学校で教えられるのは全部綺麗な英語だから実際の外人の喋ってることなんか一つも役に立たない。 汚いコードを書いてどんな汚いコードも読めるようになるのが大切。 実際に効果があるかそっちのけで、主観的な綺麗さばっかり気にしてルールを
固定化しようとするやつなんなの？
どことなく自閉症的で気味が悪い。 あ、このスレの発言のことじゃないです。リアルの話。 コードコンプリートを書いたのはマイクロソフト()だぞ
林檎がビューティパーフェクトコードを書くまで待て >>186
ルールなんて誰でもわかってると思うけどな。
・重複する処理はかかない。
・同じことに関する値を重複して定義しない。
・計算で求められるものは計算でだす。
・ある処理に関するコードは一箇所にまとめる。
・条件分岐を減らす。
・ループを減らす。
・設計とファイル名やディレクトリ構造を一致させる。
・役割毎に関数やクラスを分ける
・関数やクラスはなるべく短くする
・テストしにくい所を減らす
・適切な名前（グローバルに近いほど長く、ローカルに近いほど簡単な名前）をつける。
・十分にテストされた信頼性が高いライブラリを使用する。独自実装しない。
・コーディングスタイルに適合すること
・メトリクス（複雑度等）が悪いものは認めない
これらは主観じゃないので、このルールにしたがえば、
誰でも良い方がどちらかわかる。 >>190
それらは効果があるとわかるものだから問題ないよ。 Smalltalker達がいなくなったら途端に初心者スレ化w Smalltalkの人はボコボコにされて
Smalltalkに自信を失って帰っちゃったからな
実際全然使われていない現実なわけだから
何を言っても説得力皆無だし机上の空論になるし
こいつマゾと思って皆で玩具にしたが
言うほどマゾじゃなかったのかもね 7 minutes of Pharo Smalltalk for Rubyists
https://www.youtube.com/watch?v=HOuZyOKa91o
Pharo - Welcome to Pharo!
http://pharo.org/ >>185
どんな汚いコードも読めることは大切だが
汚いコードは書くなよ…
まあその汚さをある程度許されるようになるオブジェクト指向は嫌いじゃない >>197
いや、それでも人間クラスに
排便メソッドは必要だ。 >>198
そんな汚いコード書くと人間クラスを継承した美少女クラスで不都合が生じる >>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば... >>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば... >>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば... 人間クラスを継承せずに、
必要に応じて肛門を持たせればいいのでは？
この問題は、設計を誤ると修整が容易ではないと言ってるの？
論点は何？ >>206
メンバーの種類を制限したり、メンバー間に何らかの制約を入れたクラスが欲しいときの
ベストプラクティスはっていう話かい？
言語によるけれど c++ のテンプレート使った方法が「Modern C++ Design」に書いてあった気はする。
有用かどうかは知らん。 天使クラスを継承するともれなくおちんちんがついてくるぞ 滑ったな
どうすんのこれ
教えてよ
今すぐあんたが教えてよ この板にいたなら知ってる人も多いだろうけど
このスレタイで建てる前に延々「オブジェクト指向は～」ってスレ建てては
毎回、議論についてけなくなると「美少女クラスはうんこしない」みたいなこと書いて
荒らし逃げしてんだよこいつは。
んで、またそれ始めたから知ってる人々がサーッと逃げた。 そんな糞みたいな議論に持ってがれる時点でオブジェクト指向って切り口は何か問題があるんだろう。
もう少しバズワードと距離とれるスタンスが必要だったんじゃないのかね。 美少女の件は、キモオタクラスからは美少女の排便参照不可にすれば解決。
また、キモオタクラスからは他のどの処理を呼んだ場合にもキモ例外が発生することにすれば万全。 排便量を(オブジェクト指向について僕ができる最大の議論) >>216
排便メソッドの引数にいちいち排便量足すのかよ… 排便量は流石にインスタンス変数で管理するだろ
トイレに行って半分だけ出すとかいうマニアックな機能をつけたいならともかく get_unko を仮想関数にして美少女クラスは 0 を返すようにすればよい。 ワンチャン便秘のババアクラスを継承しても美少女クラスは成り立つのではないだろうか 日本の現場は永続化層が糞すぎてオブジェクトにマッピング出来ない
これじゃまともにOOPは出来ないから関数型でやらざるをえないんだね
別に関数型がOOPより優れてるという事ではなかったんだね >>227
OOPが愚かなのではなくDB設計者が愚かだったという事 永続化層が糞でも関数型なら上手く行くならOOPより優れてるってことになるんでは？ RDBにオブジェクトをそのまま永続化できないように、
RDBに関数を値として永続化できないんなら同じじゃん >>229
うまくいくからやるというかそうせざるをえないからやる
そして一見うまくいっているように見えるが保守性も拡張性も悪い
製造が進むほど歪みが大きくなり破綻に近付く
OOPなら最後まで破綻しないが永続化層はOOPに譲歩して合わせなければならない
しかし日本ではDB中心のアプローチしか出来ない老害が支配的だからそれが出来ない
OOPが優れているのに足を引っ張る老害のせいでOOPはダメだという風評被害を受けている >>231
便秘が永続化するババアがいるのは日本だけだぞ？知らんかったんか？ DBには関係代数という理論的バックボーンが存在するからやり方の是非に真偽をつけられるが
Mutableなオブジェクトを許容するオブジェクト指向にはそれが無い
何でもできるかわりに何でもアリすぐる mutable なオブジェクトは糞。
美少女はウンコをしない。
オブジェクトの値が破壊的に変更出来てしまっては、
並列的な処理に容易に分割できないから、
マズイだろってな的話じゃないか？ 例えばC++の入門書で必ずと言って良いほど載ってる複素数クラスComplexだけども、
たいてい代入演算詩（かコピーコンストラクタ）とか定義していやがる
藻前はa+2iに3+4iが代入されるのを見たことがあるのかっていうか、
Complexはもはや複素数ではない何か別の異形のものを表してしまっているのではないか、 ｽﾏﾝorz;
誤1：詩
正1：子
誤2: a+2i
正2: 1+2i 1+2i + 3+4i = 4+6i
意外と便利かもしれないww >>242
右辺値に対するoperator = をdeleteすればいいんでしょ？ 関数型とかいう産廃はイベントがないから使い物にならない
最近の大規模システムはみんなイベントがないと始まらない ちょっとだけ期待してスレひらいてみたら美少女のうんこ
λ計算すらないのかよ 「美少女はうんこしない」という話を「美少女のうんこ」の話だと理解してしまうようなおっちょこちょいが
オブジェクト指向を理解出来るわけがない 依存型とか見てみると結局行き着く先は同じなんだなと思うけどどうよ 美少女はウンコするのかしないのか。
それでみんな行き詰まる。 うんこをした時点で美少女ではない
しかし、うんこを我慢している美少女は萌えるのだ うんこをしないのにうんこを我慢するわけないだろ
絶対にしないから美少女のうんこには底知れぬ価値があるのだ スコープだったり変数の生存期間を気にしたりってのは関数型だろうとオブジェクト指向だろうと
同じように気にする。
要はまとめ方ってだけの話。 「野球もサッカーも球技だからおなじようなもの！」いただきましたw オブジェクト指向は役に立っている。
関数型言語はトイプログラムしか作れない。 僕みたいな芸人とか人前に出る人は、多かれ少なかれちょっとした発言や態度がネットで炎上したり、
罵詈雑言を浴びせられたりします。けれど、僕はそんなのにまったく腹も立たないし、
むしろオブジェクト指向を“カチャカチャ”してる人のほうが可哀想やなあ、と思うんです。
エラい人たちは、オブジェクト指向で時間を使うことはないでしょう。
だから僕は子どもにも「金持ちやエラい人のマネせえ、幸せな人のマネをせえよ」と言うようにしています。
はい、ここで問題です。オブジェクト指向でカチャカチャしてる人とそうでない人、どっちが幸せですか？
そんなの100%、カチャカチャじゃないほうですよ。カチャカチャばっかしてたら不幸になることは、みんなわかってる。
「あの人幸せそう、エエ人やわ」と評判の20人のおばはんをモニタリングしてみてください。
ちゃんと挨拶して、言葉遣いも優しくて、お店でもエラそうな態度をとらない、とか共通項があるはずです。
逆に「あの人意地悪いわ、不幸やわ」と言われてる20人のおばはんを見ると、絶対カチャカチャみたいな行動をしてるはずです。
オブジェクト指向をカチャカチャして、クラスのインスタントを参照して「やったった感」を持ってるのかも
しれんけど、それでハッピーエンドの人生が待ってると思いますか？ それよりも、もっとお友だちと
おしゃべりするとか、勉強するとか自分が幸せになる方法を考えるのがいいんじゃないですか。
オブジェクト指向をカチャカチャするのは、自分から不幸になりに行ってるようなものですよ。
あまりに生産性がなさすぎる。それを考えると可哀想やなと思えてくるんです。
僕は「日本は沈没しかけとる。こりゃどエラい時代が来るぞ……」とゾッとしたもんですが、
今まさにそれが当たり前のどエラい時代になりましたね。 関数型は「このわかりにくい書き方をすればある問題が絶対発生しない！」だからなぁ…
いや、わかりにくいって時点でダメじゃんっつか。 >>265
問題が絶対に発生しないなんてあるわけねえだろ
Haskellだってランタイムエラー出るときは出るわ ○○は学習コストがーとかわかりにくいってよく聞くけど、仕事でやってる人なら誰でもすぐわかるような（もしくはわかったつもりになれるような）技術だけ使い続けるより安心じゃね？ 覚える価値があるなら特に。 誰でもわかる
↓
コストがかからない
↓
人気がある
↓
衰退しない 誰でもわかる
↓
バカが混入する
↓
コードが荒れてプロジェクトが燃える
↓
マトモな技術者が新しい言語に逃げ出す
今、関数型言語界隈がstep 2のど真ん中w 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
＠ オブジェクト指向って別に世の中の色んな事を記述するためのものじゃないよねw
pcの制御を記述するためのものじゃん
たぶん世の中 = pcって偏狭な人間が混乱してるだけなんじゃない？ 手続き型の一部に関数型っぽい書き方するのがカコイイという風潮が強くなってきて
熱心な子が意気込んで本格的なものに手を出してみるがわけわからなくて
酷い目に遭って帰ってきました、という感じじゃない？ 誰でもわかる
↓
コストがかからない
↓
人を集めやすい一方、単価が下がる
↓
人気が減る 関数型言語って狭義のプログラミング言語じゃない気がするよ
アルゴリズムをシステマティックに表現するスクリプトに近い
コンピュータが手続きの連鎖で動いている以上、普通は関数を中心に記述するのはオーバーヘッドが大きすぎる
アルゴリズムが最適化される事で最終的な手続きが減るほど複雑なロジックを組む人が使えばいいと思う 言語はJavaでもC#でも良いけど、凡人はデータとロジックは分けて扱う方が良いと思う
デザインパターンも、多少スキルのある人に任せて、自分では手を出すべきではない
アホが好き勝手に弄った挙げ句トンズラこいた、巨大でインスタンス変数やstatic変数を弄りまくる分岐とループにまみれたクラスの継承元と継承先を飛び回るのは、とてもツラい
何をもって安心すれば良いのかわからない
仕事戻りたくない 名前空間で分けられるOOの方が構造化プログラミングより安全だ
バカを隔離するためにクラスを作ると昔の人は言った おお、そのとおりだよw
末端のクラスは融通の効かないバカに作る。
そうすると見通しがいい。 「言われたことをちゃんとこなすように」が正解。
途中途中で権限委譲しておかないと
上流がすべての決定をしなきゃいけなくなるので破綻する。 >>276
藻前の悩みは名前空間の汚染しかないのｶﾖ…
クラスにして良いのはふるまいに状態を持たせる覚悟のある奴だけ もしくはクロージャとかfunctorを作りたいときとかだが
C++で作るクロージャとかfunctorは
クロージャとかfunctorですよみたいな顔して状態を隠し持ちかねないところが恐ろしい… c++のクロージャってレキシカルスコープ以外の状態を持つのか？
後 functorもクロージャって全然違わない？ Objectから派生したものは、メンバ変数とメソッド、つまり状態と処理を持つ
クラス・ラムダ・クロージャ・無名関数・Functor・ブロック・Proc、
どういう名前を付けようと、First Class(第1級)オブジェクトである
第1級オブジェクトとはオブジェクトなので、newできて、
簡単に持ち運びできるし、カプセル化してアクセス制御もできる
関数の引数として渡せて、戻り値にもできる >>283
なにその中学生がぐぐりながら書いたような文章 ポケモンってオブジェクト指向が出て来たら
これで効率よくやってそうだよな モンスターは物じゃない
物じゃないんだ、友達なんだ ゲームはオブジェクト指向が適しているだろうが、
それでもやっぱり思考ロジック部分はオブジェクト指向じゃないさ。
ロジックを固めるフレームワークに設計は適している。 >>287
なにその小学生がヤフりながら書いたような文章 100レス位まで読んだけどクッソどうでもいい事をぎゃーぎゃー言い合ってるだけやんけ >>287
はっきり言ってゲームにオブジェクト指向なんて適してない
すべてのオブジェクトをエクセルの縦の列に並べて
すべてのパラメータを横の列にすべて書き出す
こういう感じでチェックできるプログラムにしないと完成しない オブジェクト指向なんて意味ないよな
スーパーマリオもテトリスもプレイに必要なのはエクセル ネタとしても面白くないなぁｗ
オブジェクト指向が使われてるのを
目の前にして適していないと言われてもねｗ ここからオブジェクト指向を見た事がない人だけがオブジェクト指向を批判出来るスレになります オブジェクト指向は重複したメソッドが発生する。こういうのは無駄。
coffee.owner=human
coffee.drink()
human.drink(coffee) >coffee.owner=human
>coffee.drink()
いやいやいや オブジェクト指向
「白痴の面倒までみれねーよww」 オブジェクト指向が面倒を見なくても
白痴はオブジェクトらしきものをプロジェクトに残してくんだ･･･ すべては名前
きちんとした､名前
名前､名前､名前
名前思考でお願いします
機能と名前が違うのがありすぎ
国語力の欠如した人のプログラムでは
反対語で書く奴もいるし
動詞を､名詞で隠す奴 正しくオブジェクト指向を使ったMacOSXは16年間で11回メジャーアップデートし
オブジェクト差し替えでiOSに派生しiPhoneやiPad、果てはAppleTVにも使われ
一方、間違ったオブジェクト指向を使ってしまったWindowsは
15年間で5回しかアップデートできない上に不具合オンパレードで阿鼻叫喚
ユーザが一つ前のバージョンしか信用しないので常に5年前のバージョンが大半
そして強硬策「いま入れますか、あとにしますか？」地獄へ。
後者をオブジェクト指向だと思ってる奴はそりゃ全力で否定せざる負えないわな。 iOSとかMacのメジャーアップデートって完全に人柱じゃないですかヤダー 最近推し激しいが今のiOSっていいのか？
まぁiOS使うくらいならLinux使うけどw どうなんだろうか。
「お前のは本当のオブジェクト指向じゃない」だとか不毛な論争の火種にしか
なってない気はする。
もうちょっとコードベースのモジュール化やコードの隔離方法なんかを議論した方がよっぽど建設的。 >>300
> 一方、間違ったオブジェクト指向を使ってしまったWindowsは
最近2週間で一回ぐらいのペースで、開発者版リリースが行われてる。
これはMSアカウントを作るだけで一般の人が入手できる。
これって正しくオブジェクト指向を使ったからだろうね。 何とも言えんね
ぶっちゃけいまのmsのアップデートはデバッグをユーザに押し付けてるようにしか見えんし
よくわからない用語で煙に巻くって点がオブジェクト指向だね オブジェクト指向だから早くリリースしてるんでしょ？ｗ 既存のクラスはなるべくいじらずそのまま静かに置いておく
オブジェ思考 "クラスとは構造体に操作する関数がついたもの"と
"クラスはメッセージコマンドを受けて動く"の違い。
前者はプログラマが陥りがちなタイプ数が少ない暗号みたいなパーツの組み合わせと
責任の所在がわからない動作をぜひ作り込んでくれと言わんばかりのジャンクで
まさにそのとおりのジャンクができた。 >>310
クラスと（そのインスタンスとしての）オブジェクトとの区別がつかない人間は永久にROMってろ きみが棲んでるジャンク界隈がそういう仕様なのは知ってるけど
こっちはクラスにメッセージ送るとクラスがインスタンス作るんだ。
うん。 >>312
クラスと（そのインスタンスとしての）オブジェクトとの区別がつかない人間は永久にROMってろ いちいち()で囲まなくてもよくない？
無駄な仕事多くしてそう。(どうでもいいけど) オブジェクト指向とかクラスが分からないのは多分メモリ周りのことが全然わからないからなんだろうな。
アセンブラからやれとは言わんが、メモリアロケータくらい自作したらオブジェクト指向がいかに理に叶ったものかわかってくるんだけど。 メモリアロケータを自作しないと理解できないってのもなぁ（苦笑） オブジェクト指向がわからない人は関数型を勉強してないんだろうな
手続き型はオブジェクト指向のメリットを潰してしまうから手続き型の書き方しか知らないとオブジェクト指向は身に付かない データのカプセル化ができてれば手続き型でもオブジェクト指向でも関数型でもいい気がするが オブジェクト指向つっても当初の「継承で差分プログラミングうまー」
みたいなのは否定されてきたからな。
入門書だと哺乳類クラスから犬クラスと猫クラスとかやってるけど、
動物が沢山出てくるゲームや動物病院のカルテシステムを開発するとして、
いちいち動物種ごとにクラスを作ることはしないだろう。
インターフェイス以外の継承は最小限にというのを教えないと。
でも未だに入門書レベルだと著者が勘違いしている。 >>324
かといって、というか
継承ってのがどんなものなのか「だけ」を説明するのなら
やっぱ犬猫でもいいんでねえのって俺は今は思う
継承をどう使って設計していくかってのはまた先の話
親、子A、子Bという三者の関係「だけ」示すのが動物犬猫 >>325
例自体は反対しないよ。
でもそれで継承というものがどういうものかは分かっても、
継承がどういうときに使うべき物なのかは分からない。
そこまで教えてる本ってあまりないね。 (HP)をプロパティで持った「キャラクター」クラスを作って
それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
これを再利用して、「武闘家」クラスを作れば
おなじ"たたかう"メソッドで武闘家はてつのつめで戦うようにできる。
さらには(MP)と"まほう"メソッドを追加で「魔法使い」クラスが…
ってこの辺りで便利さがわかると同時に
(MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって
継承の不便さが浮き彫りになってくるという。
全部独立パーツでそれを必要に応じて束ねて使っていればもっと取り回しが楽だったり 実装の再利用は継承でやるよりtraitが便利
smalltalkで発表されて、PHPに輸入されて、後は知らないが Scalaとかの静的型言語がただのmixinをあえてtraitsと呼ぶのは誤解を招くよなぁ… >>327
> それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
> これを再利用して、「武闘家」クラスを作れば
武闘家は戦士を継承していません。 そもそもオブジェクトの粒度が高すぎんだよ
アビリティクラス的なものを作るべき > ってこの辺りで便利さがわかると同時に
> (MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって
全然混乱しないなｗ
どこにつけるかなんてシステム次第だが
ドラクエ方式であればMPプロパティはキャラクタークラスで
魔法メソッドなんていうのは、特技メソッドの表示名の違いでしか無い。 継承ベースだと
キャラクター>戦士>武闘家というクラス階層で
90年代のバカみたいな継承信奉してると武闘家の後ろとかに
"魔法使い"作って泥沼に嵌まるんだよな。
継承=オブジェクト指向だから。 継承を使いこなせないのは要するに馬鹿なんだよ
オブジェクト指向も関係なくプログラミングの基礎が出来てないから >>333
> キャラクター>戦士>武闘家というクラス階層で
それはどう考えても間違った継承だろ。
継承信奉以前の問題で、継承関係にないものを
継承しているのは、お前が馬鹿だからってだけなんだが。 「よくバカな奴が"延々と"を"永遠と"って書いてたりするよねー」
「え、おまえ"延々と"を"永遠と"って書いてんの！？バカじゃね！
俺なんか絶対そんな間違いしないね！！おまえバカだろ！バーカwww」
「えっ？」 >>326
そやねぇ
あまりないというか、見たことが無いｗ
あともしそれを書いてる本があっても
入門者には意外と伝わらないと思う
それを必要とする状況まで陥ってないと
デザパタ本ですらろくに伝わってない
困って、考えて、本読むという順じゃないと多分ダメ
…多分だけど 目的に合わせて正しく抽象化出来れば継承関係は自然に導かれるはず
継承だけに着目して教える/教わるという考えがそもそもおかしい 概念の継承関係とコードの継承関係を同じ目線で見ると失敗する 自分のモデリングの間違いを言語機能のせいにする
な？要するに馬鹿なんだよ オブジェクト指向もずいぶん枯れたわけだし、アンチパターンの確認から入るってのも悪くはない。 正しく抽象化できれば正しくできる、
って意味のないこと言ってどうすんの？
その正しく抽象化する方法が問題なんでしょ？ >>328
その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入りしたのでは？ たとえば魔法使いと魔法という概念が"新たに生まれた"場合
それは魔法を使える魔法使いのみが使うから魔法使いクラスの固有プロパティなのか。
それとも、使えないだけですべてのキャラクターが持つ基礎パラメータなのか。
すべての基底クラスにMPデータフィールドを追加していいのか。
運を消費して奇跡を起こす聖者、MPやHPを消費して治療を行う僧侶などが
あたらしく出てきた時はどこにパラメータをつけて相互管理すればいいのか。
現実でその時は"ただしい"と思った抽象化が根底から揺さぶられることはいくらでもあって
(固定価格に追加される消費税、新たに追加される福祉控除項目、すべてを一元化しようというマイナンバー…)
まず、そういう認識すら持たずに「ちゃんとちゅうしょうかしないからだよ
ぼくならなんでもただしくちゅうしょうかできるからきみたちよりえらいのさ！」とか
うそぶいている時点で君はいま指をさして静かに嗤われてるのを自覚した方がいい。 >>348
要するに正しく抽象化モデリング出来てないだけだなｗ
お前が馬鹿な理由にオブジェクト指向も継承も全く関係ないわｗ >>347
> その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入り
それもありそうな話で笑えるけど、traitsに限ってはModule#mixという名前で同機構の導入が
検討されたものの、既存の機能との整合性で致命的な問題が見つかって結局断念したらしい。
www.rubyist.net/~matz/20100617.html
http://d.hatena.ne.jp/nagachika/20111003/ruby_trunk_changes_33379_33380 振る舞いの抽象化なら型クラスやインターフェイスを使えばいいし、実装の再利用ならtraitのような仕組みを使えばいい
継承による型の階層構造なんて邪魔にしかならんわ モデリングに間違いがなくかつモデルが未来永劫変化しないならID:4cC坊やの言い分は正しいね
そんな世界がやってくるといいね とりあえず>>348で言われてることを具体的にイメージできないぐらい"疎い"ってのだけはわかるよね…
多くのクラスに関わるモデリングを変えなきゃいけないぐらい大きな変更の例が列挙されていて
オブジェクト指向の黎明期と違って、オブジェクト指向があたりまえの空気になった現代だからこそ
強力な束縛を持つ継承がシステム組み替えの際の足かせになってきてるって話の流れにまったくついていけてない。 お前らのは抽象化でなく、ただのぼんやりしたイメージ
いわば妄想プログラミングだなw
お前らみたいな馬鹿がまともに設計出来ないから
言語が馬鹿を縛れるような進化が求められてるだけなんだぜ
ダメなのは言語ではないお前ら自身だ 継承にしろオブジェクト指向にしろ
コードを簡潔にしたり、仕様変更に強くするために利用すべき技術だから
「猫と犬は哺乳類クラスを継承する、なぜなら猫も犬も哺乳類だから」ってのは
熟練したプログラマの発想とはだいぶ離れているんだよね
熟練したプログラマは書かなければならないコードが頭に浮かんでいて
それを何処に書くかという整理整頓の意味で継承などの技術を使っているわけで
結局OOは整理整頓術で、どう整理したらプログラミングの効率が上がるかというだけの話
それ以上の意味はない
が、整理整頓は非常に奥が深い そもそも哺乳類と言うのが最初にあって
そこから猫や犬が生まれたわけじゃないからな。
最初に猫や犬があって、そこから共通する特徴を
もっているものを哺乳類と分類した。
どっちかと言ったら名前空間みたいなもので
継承関係じゃない。（だけど理解するのに役立つ）
で実際のプログラミングでは哺乳類がどうとかいう話とは関係なく、
継承構造は役に立つもの >>352
> モデリングに間違いがなくかつモデルが未来永劫変化しないなら
変化するからこそリファクタリングが重要なんだよね。
リファクタリングは汚いコードを修正することじゃなくて
過去の時点では正しかった設計を、
今の時点の変化に合わせて設計を変えることだから。 359 名前：デフォルトの名無しさん[sage] 投稿日：2016/07/13(水) 08:17:59.46 ID:+CQztjRc
継承はそういう時に身動き取れなくなるから困る 割とマジで「オブジェクト指向って継承って奴だろ」な人で
言われてることがまったくわからなくてパニクってるんじゃないかと。 原始時代じゃあるまいしそんなプログラマがいるのか？
にわかに信じがたいな 美少女が人間クラスから継承できない問題は
どうなったんだ？
それでオブジェクト指向は破綻したときいたが。 ぱっと思いつくだけでも
Unkoオブジェクトに量の概念をもたせて量がゼロのうんこを作るかNullObject的な対処をする
うんこしないAngelクラスを継承する
排便の概念を抽象化したメソッドを用意してうんこ以外の可能性を見出す
などなど
なんとでもなるやろ UnkoのサブクラスとしてOhgonクラスを実装するんや！ 美少女はウンコをしない
この「しない」という所が美しいんじゃないか
汚れなき乙女を全うする意志の問題だ
これが「出来ない」という物理的構造に由来する問題に成り下がってしまったら
何の味わいもなくなるだろ
チンコ勃たんわ 頭の悪い人の悲しいところは
頭の悪い冗談を好んで言い続けるということだ
飽きもせずに繰り返し繰り返し何度も何度も… 美少年にクラスチェンジすることで破綻せずにハッテン というか>>211で書かれてるとおりをまたワンパターンで始めただけだしな。 美少女ウンコ問題は高度すぎて解決の糸口すら見つからないもんな
ついていけない奴の気持ちもわかる ちょっとしたネタ書き込みにすら
知能やセンスがもろ出しになっちゃうから悲しいね
>>372
それ言っちゃうと今度は意地になってレスし続ける可能性 >>372
面白くない→顔が白くない→色白でない→実は美少女ではない→ウンコしても問題ない
なるほど要件の再定義によって解決か 解決しとらんのにワンパターンもくそもないだろ
根気のない奴だなあ 解決できると思ってるのが間違いだと気付くといいよ
分類学的な階層を作っても「書いた人どう対象を捉えているか」というどうでもいいことしかソースに残せない
鳩クラスと鹿クラスが同じ親クラスを持ってて、ニワトリクラスとブタクラスが同じ親クラスを持ってて、
一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ
そういう情報を一切俎上に出さずにAはBの子クラスであるべきか否かなんて話すのは無意味
そういう文脈をソースに組み込む必要があるかもまず考えないといけない なるほど
現状の研究成果に比べると一風変わった意見だが私は興味深く聞かせてもらったよ
つまり君はウンコをしない美少女が人間クラスから派生されるべきコンテキストについて
もっと掘り下げた議論をすべきだと言うのだな
ところで君はそういう文脈をソースに組みこむ必要があるかについては
どんな考えを持っているのかね？ 生成するUnkoオブジェクトのtasteフィールドが最大値になるだけ >>380
いやねーだろｗ その手のシステムで種ごとにクラスを分けるわけがない。
全部同じクラスだろ。 まあなんでも抽象化すればいいってもんではないわな。
物質は究極的にはクォークのセットだからって、そのまま実装したらそりゃ破綻するだろうし。 君それは細分化やないか
美少女のウンコふりかけ食わしたろか 同じ型のインスタンスの振る舞いをポリモーフィズムさせるのは、
・継承
・委譲
・switch文
・関数ポインタ、ラムダ式
・別途スクリプトなどを用意する
などの方法がある >>384
データはDB管理かもしれないしDBに沿った構成になるかもしれない
UIで必要であれば 380 の構成もありえるし
だから 380 は文脈と言ってるんだろうに どんな文脈やねんｗ
肉屋の仕入れアプリでブタにダンスでもさせる気なんかｗ
そんなら俺はウンコを我慢する美少女の方がええわｗｗｗ
何でも文脈言えばええっちゅーもんちゃうでホンマ >>389
いや、当然RDBMSでデータ管理しているという前提だが？ 計算式が面倒になったら
またどうせオブジェクト指向になるんだろ >>380
> 一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ
見たこと無いが「あり得る」という話なら、
C言語でgotoばっかり使うってのもあり得るよ。
C言語なのに、オレオレライブラリとマクロを使って
COBOLみたいに使うことだって有り得るよ。
お前の大好きな言語をクソみたいな使い方する方法だって有り得るよ。
有り得るかどうかを語るのって意味なくね？
クソみたいなコードを書くのは書いた人間が悪いのであって
言語の問題でもオブジェクト指向の問題でもない。 >>393
というか、人間がプログラムをユニット単位に分けた時に
"こいつはこういうコマンドを与えれば勝手にそれをやる単位"って
分け方をすれば『人間がわかりやすい』だろう。ってのが
いまあたりまえのメソッド型オブジェクト指向なんで、
こうすれば"副作用"が出ない！って計算式の方はむしろ
問題が起きないように『機械の都合に人間が合わせる』流れで
たぶん遠からず下火になるわ、あれ。つかもうなった感じ。
むしろ、アルゴリズム解析みたいなのを開発環境がやって
こうすると副作用が最小になるっぽいですよ？って
AIがサジェスチョンするようになんじゃね？つか。 それはどうかわからんよ
もともと機械の都合で生まれた静的型が
実は人間にも優しいってことで大人気だし
本来静的型じゃなくても動く筈の動的型言語も
どんどん静的型の機能を取り入れていくのが今のトレンドでしょ
それに、副作用の無い関数型は全然機械の都合じゃないし
あれは数学の理論とかから生まれたような理論先行のもので
コンピュータの動作原理を考えたら、むしろ副作用ありの方が
自然だと思う
副作用ありの静的型言語が一番機械の都合に合っていて
その金字塔がC言語であり、今でも使われ続けている
主にローレベルなことやOSの開発やドライバの開発などに
使われているのは、それだけ機械の都合にあっているから
昔の言語なのに破たんせずに使われ続けているのは
それだけコンピュータの動作原理を素直に表現していて
流行り廃りというものと無縁だから Cで書いたコードが速く動くようにCPUやOSが設計されているという面も
あるからぬ…だからって新世代の言語に合わせてCPUやOSを作り直すか？
といわれたらそんなことは起こりっこないと断言できるが おまいさんそれは逆ですぜ。
Cがアセンブラに馴染み易く出来てるんですぜ。
でも本来はintelの系統じゃ無くて、
モートローラとかミニコンから派生した石に馴染み易く出来てるんですがね。
まあ、Cが最初からintelの石用に作ってたら、
もう少し違った構文になってたかもね。 アセンブラやってた連中が、構造化プログラミングを提唱して、
プログラムを小さな塊の組み合わせで作る様になったんで、
同時期に条文分岐やサブルーチンの扱いをマクロ処理を被せて
読み易くするのが流行ったんだよ。
それをもっと書き易くして行って出て来たのがコンパイラ言語
いわゆる高級言語だけど、簡単なアセンブラへの置き換えしかしてなかった。
今ではそこから更にそれら高級言語を分かり易く記述出来る高次な高級言語が流行ってるけどね。 例えば、hoge+とかやれば自動的にインクリメントしてくれる仕様だって、そういうアセンブラ命令があったからなんだぜ。 >>397
＞Cで書いたコードが速く動くようにCPUやOSが設計されている
何を根拠に？ >>399
時系列がぐちゃぐちゃじゃね？
最初の高級言語と呼べるものはFortranだけど、
数式を人間フレンドリーな形で記述できるのが売りだった。
Fortranはアセンブラの簡単な置き換えレベルではないでしょ。
構造化プログラミングはALGOLからだろうけど、
Fortranより後だし、Cのようなレベルに達するのはもっと先。 自信を持って声を大きくして叫び続ければやがてそれが歴史となる Cの何がすごいって、メモリに対する考え方がシンプルで凄い
構造体のメンバは単なる先頭からのオフセットだし
配列の添え字も先頭からのオフセットでしかない
しかも配列とポインタはある種の互換性がある
だから何だかよくわからないメモリブロックを
構造体にキャストしてアクセスできたり
同様に単なるメモリブロックを配列としてアクセスできたりする
メモリの扱いがとにかくシンプルでありつつ強力なアクセス方法があり応用が利く
こういうことができる言語はあまりない
C++ですらvtableが入ってたらもうオフセットずれるし >>406
言語の実装がシンプルなのと、その言語を
使ってアプリを実装するっていうのは別の話で
なんでも一つの機能で出来てしまう言語っていうのは、
冗長で意味代わりにくいコードになりがちなんだよ。
例えばシンプルと言うのならアセンブラが一番シンプル
条件判定命令と条件ジャンプ命令だけでループを表現できてしまう。
プログラム言語っていうのは、特定のパターンに対して
専用の命令を作ることでコードの可読性を高くしてきた。
これは圧縮の仕組みにも近い。特定のパターンに短い単語を当てはめて
簡潔に書くことができるようになる。
条件判定命令と条件ジャンプ命令さえあれば十分であっても
そこからforパターンやwhileパターンを見つけ、専用の単語に
割り当てることで可読性が高くなる。 だからCだけが生き残ったんだろ？
大衆プログラマが望んだ形で変化した結果だからな。 生き残ったっていうのは古い言語とくらべての話？
確かにFortlanとかPascalは消えた。
多くの優れた言語が生まれている中、今でも通用するのは
C言語ぐらいだと思うが。 >>410
第三者の人が検証できるランキングとかある？
そりゃどこか目につかないところではあるかもしれないが、
例えばその言語で仕事したいと思ったとき
探せ出せないような言語は消えたと思っていいだろう。 >>411
Intel Visual Fortran とかググッてみ。
リアルタイムで今も製品出てるのを消えたとは言わないでしょ。 >>408
ということで、C以外も生き残ってるんだが？ｗ 問題は暗黙に行う言語の動きに対してどれだけ
コンセンサスがとりやすいかってことだ。
c++ はもうその意味でどっか行ってる。 >>407
俺の言いたいことはそういうことじゃなくて
ローレベルな世界ではその言語固有のオブジェクトになってない
単なるメモリブロック、データ、信号を扱わなきゃならない場面が多いんだよ
それはファイルから読み込まれるかもしれないし
ネットワーク越しにやってくるかもしれないし
ディバイスとのやり取りかもしれないし
ま、要するに単なるデータ
Cはメモリモデルがシンプルだからこういった単なるメモリブロックを扱うのに
長けているんだよ
構造体にキャストするだけでそのまま扱えるから
今でもC言語が現場で活躍しているのはこれができるから
もしこういったことが出来なかったとしたら、C言語なんかとっくに滅んでいたに違いない
メモリブロックをキャストして構造体や配列としてアクセスできないとしたら
そんなC言語に価値なんかあるか？
その一点がすごいんだよ、マジセンスある、もしくは運が良かった そして多くの言語が見落としがちな部分でもあったんだよ
オブジェクトにしなきゃならないっつってvtable持たせたり
動的にしなきゃならないと、メンバをオフセットではなくハッシュにしたり
どんどん賢い機能を盛り込んでさ
その点C言語の構造体や配列はフラットでむちゃくちゃシンプルな作り
適当なメモリブロックをキャストしても何の問題も起きない
仕様もシンプルで分かりきってる 別に必ずしも偉い機能を盛り込むのがダメと言っているわけじゃないよ
ただ、Cが何故か生き残っていて今でも使われ続けている原因はソレということ
C言語の用途と、うまい具合にマッチしてて、いい感じに生き残っている 構造体の先頭メンバ以外のオフセットは規定されていない
まぁ、オフセットなのでメンバアクセスでどうとでもなるわけで
構造体が定義されたままメモリ上に存在していると考えているアホ
一般的なコンパイラなら定義通りだろうけど規定されていない
規定されていない規定されていない 構造体のメンバ間のパディングは未規定だけど、オフセットが未規定って言うのは
順番も入れ替わるって言ってるの？ 簡単に入れ替わるさ。
わざわざ入れ替えないでねと指定するレベル 構造体のメンバの順番が入れ替わらないのは仕様で決まっているよ
決まってないのは間に入る詰め物だけ
http://portable-c.jugem.jp/?eid=17
しかし、詰め物をどうするか、指定できるコンパイラがほとんどだから
実質的に詰め物も問題にならない
C言語プログラマーは自分の使っているコンパイラの仕様ぐらい分かって使っているからね
問題になるとすればエンディアンぐらい intのサイズがアーキ依存だから通信に構造体は使うなってのが常識だけどな。 cはメモリは意識するがレジスタは隠蔽するって落とし所がよかったんじゃない。 Cはパーサが複雑なのとゼロコストで導入できる便利機能が無いのを除けば悪くはない cの最大の失敗は波カッコ
ブロックのスコープがパイソン風だったら人類は1世紀以上先の進んでいた 代入演算子=と比較演算子==だけは許されざるよ。
つうか、IDEのサジェスチョン機能実装前の
"タイプ数が減る云々"な言語はすべて滅ぶべし。 C言語は特徴ある機能で生き残ることができた。
だけそのその特徴ある機能がなかったら生き残れないのか？というと
そうではない。現にその特徴ある機能がない言語ばかりだからだ。
ここから言えることは、なにもない言語は消え行く定めだが、
C言語の機能がなくとも、それに上回る機能があれば生き残るということだ。 >>429
IDEを使うことでタイプ数が減る機能はどうでもいいんだよね。
どうでもいいというのは、タイプ数が多くても少なくても
さほど違いはないということ。
重要なのはタイプ数じゃなくて読む文字数だから。
ただしタイプした文字数＝読む文字数ではないということ。
どういうことかというと、人間は文章を読むとき
読み飛ばしをするということ。
例えばJavaでいうimportやMainクラス定義なんかは
読み飛ばす部分。だからそんなところで読む数の違いは出てこない。
また型定義は読むところではあるが、型定義だけを読むことで
型を理解できると言うメリットが有る。
これは型が書かれていないコードから、型を解析する
作業よりも読む文字数は少なくなる。 Cが生まれた時代はな
シンタクスハイライトどころか下手すると
スクリーンエディタ(ｷﾘｯ カットアンドペースト(ｷﾘｯ
すら高価な機能だったんやで Cが生まれた頃にはまだコピー＆ペーストはなかったぞ。 最初のクリップボードはAltoかな
Cが1972年でAltoが1973年 >>430
で、その、この先生きのこるのはどの言語！ アセンブラ C Fortran Lisp の古代言語
Javascript COBOL Python
HTML PHP はなんだかんだ言って生き残るんだろな～
あとは Java がどうなるかな お前ら、テーマに戻れや。
なぜオブジェクト指向は愚かな考えなんだ？ 初期設計を少しでも間違えたり手抜きしたら
そのシステムの成長絶望的になり死ぬ >>444
そして>>41-42で完全に解説完了
ジョークとしてわざとオブジェクト指向として間違ったプログラム例だしてるってのに
「この通りオブジェクト指向は直感に反して～」じゃねぇっつのw >>440
Javaは普及してるから残るだろうなぁ
なんか、いつものベストじゃないけど普及したから
ベターとして残るというプログラム史のいつもの展開というか。 問題はそういうジョークを本気にする人が多すぎるってことだろうに。
つまりオブジェクト指向ってのは一般にコンセンサスをとりずらい概念なんだよ。 おまえ等の好きそうなネタ見つけた
オブジェクト指向で料理を例える場合，chicken.cut()かchef.cut()か
https://teratail.com/questions/41875 >>446
コーヒーの例は単純明快だからいいけど、美少女は実際に正しく設計できるやつが日本に何人いるかってレベルだろうな >>448
これをジョークだと思って実戦に挑む奴がデスマーチを引き起こす くだらん与太話はこれくらいにしてそろそろ全力でウンコ美少女問題に取り組むか ウンコしない美少女は偶像
つまり人間からの派生ではない なんか、いっつも同じレベルの書き込みするから
自演になってないって自覚しとる？きみ。 ユーザーはうんこなんて機能は求めて無いから削除しろよと 人間がウンコするのは、
ユーザーが求めているからなのか？ ソフトの機能に不要な要素まで組み入れても誰も買わないだろ。
現実の要素を完全に網羅する必要は無いから それは当たり前のことではあるな
必要な要素だけ実装すればよいからな
Humanクラスがどういった要素を持つかは案件によるし
もし人の持つすべての機能をHumanクラスに実装できるっていうんなら
そのHumanクラスにプログラムも書いてもらえばよい
よって現実の人間がうんこをするからと言って
必ずしもHumanクラスにうんこをする機能が必要かどうかはわからないし
必要な案件に出会ってから美少女クラスのうんこの扱いについて考えればよい 要件で一言も触れてないのに「はぁ？○○はあって当然だろ」とか言い出す顧客しかいないから
想像できるものは全て詰め込んでおく必要がある。
ウンコだろうとゲロだろうと例外はない。 肝心なことを決めずに作り込んでいく。
美少女クラスのスーパークラスは人間クラスである。
排便メソッドは関係ないからそれでいい。
だが、ある時ユーザーからの要望で人間クラスに排便メソッドを作った。
人間だもの、当たり前だ。
それでいいと思った。その時がくるまでは。
ある時私は気がついた。
これだと美少女が排便すると www このスレ的にはgo言語とかD言語のダックタイピングってどうなん？ ダックタイピング
由来
アヒルのの鳴きマネをする人間はアヒルに違いない ダッチワイフィング
由来
オランダの人妻はエロいに違いない COBOLからJavaへの移行で「実際に」成功した案件は存在しない >>468
COBOLって単なる言語じゃなくて運用まで含めたシステムの総称だからな。かなうわけがない
とは言え、高賃金のCOBOLプログラマーもいずれ死に絶えるわけでなんとかしないといけないんだけどさ
Adaなんか勉強して損した オブジェクト指向を考え出した人間もオブジェクト指向の解釈を誤っていたのではないか
クラスというのは人間が直感的に思い描く世界の事物をプログラムコードにマップする手段ではなくて、
プロセスという大きなチューリングマシンの中の小さなチューリングマシンを記述する手段にすぎなかった
（チューリング完全性の利用例の一つだった
クラスのコンストラクタは状態機械であるところのチューリングマシンの初期化と生存期間の始まりに相当する
デストラクタは後始末と生存期間の終わり。
メソッドはチューリングマシンにlive timeを与え、計算を進めさせる。
そんだけ
状態（mutableなデータ）を含むから関数型プログラミングとは似て非なるものだし、
数学的にカタをつけるにはチューリングマシンの一変種で無限長の磁気テープをクラスで小分けにしたもの、
としか言い様が無い こう考えると継承のしくみを使ったプログラミングが
ごく一部のデザインパターンにおいてしか成功しないことも理解できる
継承というしくみのは人間が「こうだったらｲｲなあ…」と思い描いて作っただけで、
>>476な解釈からは必然性が出てこない
つまり継承というしくみは論理的妥当性を欠いており、
継承を下手に使ったらあちこちで矛盾が生じて話が発散していく傾向なのも仕方が無い だいたいプログラミング業界って、
新しいものが導入される
→古いものはやめてこれ使いましょう
→新しいものも色々問題があることが分かってくる
→極力使わないようにしましょう
の繰り返しだからな。継承しかり例外しかり。
最近はテンプレート使いすぎなんじゃねーのって思うけど。 > 継承しかり例外しかり。
継承も例外も極力使わないようにしましょうなんて
誰も言ってないが？
間違った使い方が明らかになって、
間違った使い方をしないで
正しい使い方をしましょう。
っていう結論ならばいつもそうなっている。
継承しかり例外しかり。 結局、人間クラスと美少女クラスは
どうすればいいんだ？ >>479
正しく使おうってのは常に真だから内容が無いのと同じだな。
できるだけ使わないようにって風潮はある。程度の差はあれgotoとかと同じ。 javaはオラクルがVMを提供しなくなったら
廃れるだろ。 >>479
結局、言語の問題よりも馬鹿を入れない事のが重要ってことだろ。
そういう意味じゃ linus のやり方は正しいってことになる。 >>481
> できるだけ使わないようにって風潮はある。
無いよそんなのｗｗｗ
アルアル言っていても、
嘘がホントになったりしないアルよ～ｗ （定義が論理的に妥当でなかったりあいまいだったりするとお議論が紛糾する例 多少コピペが多くなっても継承をむやみに使ってはいけない場面ってのは想定しなきゃなぁ なんで継承をやめたらコピペが多くなるのかそれがわからんｗ
正しく継承使うといういうのは、
継承以外の方法を使うべきときに、違う方法を使うという意味であって、
ならばその違う方法で、コピペを回避すれば良いんだよ。 委譲を使えばいいんだろ。
肛門クラスを作って、
人間クラスと美少女クラスのプロパティに肛門インスタンスを持てばいいんだ。
排便できる肛門と出来ない肛門と。 コーデングテクニックでごまかすのはアカンね
そーゆーことするから所謂ひとつのスパゲッテイー的ソースコードが出来上がるんや
デザインの問題はデザインで解決出来な一生炎上商法プログラマーのまんまやで >>487
ミックスインの手法が確立されてないってことは、継承が害悪になる場面ってのはあるんだよ。
そういう場合は、下に書かれてる通り、コンポーネント的な設計が必要。
そういう時に、コンストラクタでコピペが必要ってこと。 そうするとインタフェースの定義が必要になってくるから、結局継承が楽だし、よほどのことじゃなければそれで済ませるんだけどね だから、委譲というか、
デリゲート使えっていうか。 ほんと最近、is-a関係、has-a関係っていうの
軽視されてるよな。
is-aのときに継承すれば良いんだって
昔から言われてるんだが。
これは古い概念じゃないぞｗ >>494
is-a関係は一般に存在しない
例外なのは同値関係と包含関係が数学的に定義できて無矛盾性が担保された
（＝直接証明されたか、より一般的な体系の無矛盾性に帰着できる）ケースだけだが
そんなのはｽｹﾞｰまれ
いっぱいあると感じるのは錯覚
不用意にis-a関係を導入することでクラス分けにあいまいさが紛れ込み、
プログラムの設計とか簡単に壊滅する その点ha-a関係はやりやすいなぜなら単なる集約であって分類が絡まないから
has-a関係の導入自体が矛盾を生じることは無いからだ is-a関係だと思っているものは全てhas-aとしても実装できる。
概念系統が複数ある場合、is-aでは多重継承もしくは、
全ての組み合わせの派生クラスを定義することが必要だが、
has-aではそういう問題は無く柔軟に設計できる。 OO使わない場合に
フラグとかカウンタとかステータスってのをどう管理するのかを
単刀直入に知りたい。
関数型なんかでもこの辺がよくわからない
（消せるはずはないから何か別の概念などで整理・管理されるんだとは思うけど） >>499
普通の構造体でいいのでは？（Cでいうところの） is-a だったらliskov置換原則の方が理解し易いし、コード書くときの指針になる。 ちなステータスというのは大概I/Oを通じて外界と繋がっている事物の結果を意味し、
実時間軸上でうつろうもの（mutableなﾌﾞﾂ）なので厳密には関数型プログラミングに存在し得ない概念
関数型プログラミングでは「1」を返す関数と、和を返す関数から「1」+「1」=「2」という演繹ステップを経て
「2」を返す関数を作る、というように演繹ステップとしての時間経過しか扱わない
これでどうやって実時間で動くシステムをプログラムするのかというと、
演繹ステップの順序と実時間軸上の物事の変化順序が一致するように関数を設計してやって、
擬似的に演繹順序を実時間軸上の順序と合わせてそれっぽい動きを実現しているわけや
例えばHDDのエラーステータスとか、昨日のステータスに対し今日のステータスが変化した、と捉えるのではなしに、
「HDDの昨日のステータス」を返す関数と、ステータスの適切な処理に対応する何がしかを返す関数とから
「HDDの今日のステータス」に対する処理に対応する何がしかを返す関数を生成する
ことでHDDの今日のステータスを処理する >>494
女は一般に存在しない
いっぱいあると感じるのは錯覚
って言ってるようなもんだなｗ
一般に存在しないというのなら
存在しないと言う根拠を書け >>504
is-a関係は一般には存在しないと書いたのじゃ
例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう
また、なんで女クラスの派生クラスが妻クラスではいけないのか？その根拠を目下人類は手にしていない
はい論破
ちな、有限集合に関しては無矛盾性は常に証明できるから別に
女クラス←妻クラス
でも
妻クラス←女クラス
でも良いが、有限のケースしか想定しないんならswitch文で良いやという話で
オブジェクト指向の出る必然性がかなり減る
あくまで無限集合としてのクラスXを今数学的に正しく定義付けできるか？（X=妻 or 女 or so on）というのが問題 is-aかどうかなんて抽象的すぎて判断の材料になんないよな。
何を持ってしてis-aとするかが大事なんだけど、そこをきちんと答えられる人は少ない。 >>505
そりゃ妻のような一時的な属性に過ぎないものををクラス化するのがそもそも間違ってる
同性婚以前に結婚離婚で既に破綻してるじゃないか
例が悪いので説明になってない、やり直し >>507
男も改造すれば女になりうるから、男クラスのインスタンスを作ると、参照を維持したまま女クラスに変身できない。
だから、is-aなんてものは、性転換をしないという契約がなければなりたたない。
契約をしてないのにis-aなんて言いきれる訳ない。 妻とか女とか、単なる属性をクラスにするからワケが分からなくなる。 口に肛門つけてください。
しゃべれるしうんこできるし便利だと思うんです。 話についていけない子が
必死で面白レスしようとするのが悲痛
人間の悲しみが透けて見える >>505
> 例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう
ならないなｗ
お前設計がおかしいよ。
妻をクラスするって発想がそもそも
キチガイじみてる。 普通は性別は属性だよなｗ
人クラスがあって、名前・年齢・性別
ほら属性だ。
そのうち佐藤クラスを作るとか言いそうだｗｗｗｗ is-a関係っていうのは必要条件であって十分条件じゃないんだがｗ
is-aになっていれば必ず継承関係にあるってことじゃない。
継承しようと思ったとき、is-a関係を満たしていなければいけないって話だ。 オブジェクト指向ってどこで間違ったんだろう
途中までは良い線行ってたと思うんだけど、どこからか使いものにならなくなったよね オブジェクト指向が使われてない
フレームワークなんて無いんだが？
使い物にならなくなったという考えがそもそも間違いだな。
まあ「使い物にならなくなった」と言い続けることで
他の人に事実だと錯覚させようとする手段ニダ？ｗ >>517 本当にオブジェクト指向が必要だから使っているのか、
抽象化の手段がオブジェクト指向しか無いから使わざるをえないのか
昨今の言語なら継承以外の方法で抽象化とか再利用とかできたりする
OOは本当に最小限にして、late bindingやメッセージパッシングの妙を際立たせるとより効果的
Real World OCamlだとヘテロな型を持つ木構造を探索するのに使ってたりしたな 継承捨てて委譲を使えっていうのは
マイクロソフト用語でコンポーネント指向っていうんだが、
これを意図的に取り入れたのが2000年前後に使われていたVB6なんだよな。
そのVB6も.NETになってから継承をサポートしたし、
コンポーネント指向だけではだめだということだろう。 >>519
オブジェクト指向は必要だから使うんじゃなくて
いくつもある手段の中から一番適切だから使うんだよ。
お前が例示する使い方は、単にオブジェクト指向じゃないほうが
適切だってだけ。そしてオブジェクト指向が適切だから
ほとんどのフレームワークでオブジェクト指向が使われている。
他に代替技術があるにもかかわらずだ。 >>513
だからその設計はねーってこと言ってるんだろ。
日本語読めないの？ >>516
＞どこからか使いものにならなくなったよね
C++の奇形めいたオブジェクト指向は衰退して
別方面で進化してきたObjecive-CとJavaが本流として
いま街でみかける全てのスマホアプリを支えてるけどな。 今はObjrctive-CじゃなくてSwiftじゃね？ >>521 適切だから使うというなら何故デザインパターンなんて出てきたのか？
デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
他の手段が使える言語なら間違いなく採用しない
他にもExpression ProblemをJavaで解決しているのとOCamlで解決しているのを比較してみるといい
OOだと論文書けるくらいには面倒な方法があるけど、OCamlのVariant使った方法と比べて圧倒的に可読性と簡潔さに劣っている JavaはC++よりレガシーな言語になってしまったが… >>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
違う。OO便利だなーって使っているうちに
設計のアルゴリズムが確立されていって、
それをまとめたのがデザパタ いや、デザパタはOOと関係無いから。
関係あるのはOOPの方 【閲覧注意】戦闘に巻き込まれて頭部を切断された少女の遺体。これがリアルなシリア。
http://dqnworld.com/archives/34.html
これが本当の戦争の恐怖。この少女には大人の戦争は関係ないですからね。巻き込まれた少女の遺体を持って何か
を訴えかけている男たちの映像です。
【閲覧注意】シリアで反体制派の兵士が顔を吹き飛ばされてしまう瞬間。
http://dqnworld.com/archives/89.html
スローモーションが怖すぎる・・・。
【閲覧注意】アッラーフアクバルを叫びながら少年を斬首する映像を公開する。
http://dqnworld.com/archives/3975.html
点滴？のようなものが見えるんだけど。助けられた少年じゃなかったのか。助けられた所を強奪されてアッラーフ
アクバル？なのかしら・・・。
【閲覧注意】磔にされた戦闘機パイロットの遺体。シリアにて。
http://dqnworld.com/archives/3996.html
今日のアッラーフアクバル動画。
妻の目の前でぶっ飛ばされた旦那さん？これは死んだかな(°_°)
http://dqnworld.com/archives/4004.html
さすがにこれだけ飛ばされたら助からないかな・・・。
【閲覧注意】あおむけでゲロを吐きまくっている男性。助けてやれよ・・・。窒息するぞ(@_@;)
http://dqnworld.com/archives/4007.html
これ結構危ないんじゃないの？撮影してないで横向きにしてやれよ。これ窒息する可能性あるだろ。
衝撃映像。事故って大回転した車から少女がポロリ。
http://dqnworld.com/archives/4013.html
この少女がどうなったのかが気になる所ですが動画の説明には何も書かれていなかった・・・。 >>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
おしい。
デザパタはJavaやC++に適さない問題を無理やりJavaやC++で解決するためのもので、
SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。 smalltalk だと、人間クラスと美少女クラスの問題は
どう解決するの？ Squeak Smalltalk だと、こんな感じか？
Object subclass: #人間
instanceVariableNames: 'もろもろ'
classVariableNames: ''
poolDictionaries: ''
category: '美少女-排便'.
人間 compile: '排便 ^#便'.
Trait named: #美少女 uses: #() category: '美少女-排便'.
美少女 compile: '排便 self notify: ''トイレには行きません''. ^#プリン'.
おまえら := 人間 new.
おまえら 排便. "=> #便 "
橋本環奈 := 人間 new.
橋本環奈 assureUniClass class uses: 美少女.
橋本環奈 排便. "Warning: トイレには行きません => #プリン" >>531
> SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。
例えば、どのパターンが簡潔明瞭に記述できるの？
一番簡単なパターンでいいので書いてみて。
考えるのが面倒なら俺が出題しても良い？
Singletonは個人的につまらないので
そうだね、DecoratorはSmalltalkやSelfで書いたらどうなる？ >>534
試しにウィキペの Decorator パターン
https://ja.m.wikipedia.org/wiki/Decorator_パターン
にある例を Smalltalk で書いてみた
http://ideone.com/Y1WAxY
けど、圧倒的に簡潔になった感じはしないな
>>531 ならどんなふうに書く？ シングルトンなんて言語に最初から組み込んでおけ（Scala信者並感） >>532
そもそもきみは継承関係=オブジェクト指向でしか発想してないから
クソ邪魔くさい継承取っ払ってモジュール自由に組み外しできるタイプの
オブジェクト指向の話にまったくついてこれてないからずっと嗤われてるわけで。 >>535
別にDecoratorじゃなくていいんだけどね。
圧倒的に簡潔かつ明瞭に記述できるっていってるから
そのコードを見たいだけ。 デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。
型が完全に動的なSmalltalkやSelfではデコレータパターン自体が不要。 型が動的だと>>535の例のようなコードはどうなるの？ そそ
例えばアセンブリや機械語は制約がないからデコレータパターンとか要らないでしょ
それと同じでSmalltalkには何も必要ないよ 全然違うのだが。デコレータもSmallTalkも理解してないとみた。 アセンブリというかC言語だとこんな感じか。出来るには出来るけどちょっとねえ
http://codepad.org/XgRtJlQb なにも知らなくても語れる。
それが Smalltalk のいいところらしい。
人間の悲しさがほの見えるな・・・ >>540
Smalltalkはよくわからないけど、
DoublePriceとかWholesalePriceとかいうクラスを増やすより、
元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
SmalltalkのPluggableMVCとかもクロージャで柔軟な変換を実装しているし。 >>545
> 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
こんなんでどうですかね？
http://ideone.com/d8iLSE
ついでにRuby版も書いてみた
http://ideone.com/WW8gva >>543
これだと Java 版でいうところの getValue() する前に
毎回、二倍にして 利益80乗せて、また二倍にしてもう一度 利益200乗せて…とかって
いちいち書かないと 840を返せないから、結果は合っているけど要求仕様を満たしていないような気がする いつになったら、
人間クラスと美少女クラスの問題に辿りつけるのかね？
悲しいの～。 どう解けてるんだよ。
人間の肛門と天使の肛門にコンポーネントするのか？ 用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。 もうそろそろいいかな？
みんな「デコレーターパターン」をどうするか？というテーマで
会話が成り立ってるよね？
つまりこういうことさ。デザインパターンっていうのは用語。
実装じゃない。
デコレーターパターンをJavaならこう書く、SmallTalkならこう書くと
いうふうに共通認識ができてる。これこそデザインパターンの有用な所。
だからコードの書き方が決まってるわけじゃないんだよ。
設計だからね。言語が決まらない状態であっても話はできる。
デザインパターンをどういうふうに書くかってのは例でしか無いんだよ。
目的を達成できるならどう書くてもいいし、デコレータパターンを
どう書いてもそれはデコレータパターンなのさ。
SmallTalkであってもデコレーターパターンっていうのは存在する。
だからこそSmallTalkでデコレータパターンをシンプルに書くことができる！と
主張できる。 >>553
なんでみんなより二歩も三歩も手前な意見を
そんな長文で書き込めるの？ Smalltalk の t を大文字で書くやつは無知か知ったかぶり 実は誰も Smalltalk なんて知らない www 言語は関係無いと言う内容の話への反論が、言語名のミスプリントの指摘とか、レベル低過ぎだろw
小学生の負け惜しみかよw >>561
え？それ反論だと思ってたの？
反論はまだ一つも来てませんよｗ >>553
>>538で「見たいだけ」って言ってるところをみると、これは反語で
>>546みたいに簡潔なのが出てくるとはこの時点では考えてなかったんじゃない？
だからデザパタは用語で実装じゃない、言語は関係ないって趣旨替えしたように読むのは穿ちすぎ？ >>565
いやｗ
最初からこのために、
デコレータパターンをSmallTalkで書いたらどうなるの？って
話題を振って会話をさせたんだよ。
デコレータパターンという共通知識があり、
SmallTalkでそれを実装することができるという会話をね。
もし実装が決まっているものであれば、
SmallTalkでデコレータパターンを実装すれば
シンプルな形で実装できるんだっていう話はでてこない。 そもそもC++でデコレーターでもそんな難しくないでしょｗ
シングルトンの方がよっぽどややこしい。 「シングルトン」だけで話が通じる所がデザインパターンの
便利なところだね。
さてシングルトンにもいろんな実装があるけど、
DIコンテナを使ってシングルトンに見せるっていう方法もあるよね。
これだと普通にクラスを作るだけで良くなる。 Java8ならもっとHENTAIなコードが書けるぞ
http://ideone.com/DbIiD0 Smalltalk の最大の魅力は、
それが雑談に過ぎないということである。
by アラン・ケイ >>570
new Price((120*2+80)*2+200) を作りたいわけではなくて
new Price(120) をデコって 840 を返させるのが Decorator
だからデコったあとに setValue(100) してから getValue() すると 760 が返るはず
http://ideone.com/Z24LFA
http://ideone.com/Diod1I
http://ideone.com/x2goNr
http://ideone.com/do6fT9 >>566
まるでちがう。>>546はデコレータパターンじゃない。
Javaではデコレータパターンを使う問題を
デコレータパターンを使わずにより簡潔に記述した例。 >>539
型が動的だと>>535の例のようなコードはどうなるの？ 関数型インターフェースの方が簡潔になる
http://ideone.com/6MAwKM
>>573
setValue(100)してからgetValueしたら100返らなきゃバグってるだろ
setOriginalValueとかに修正するところだな Wikipediaにある
> Decorator パターンの方針は、既存のオブジェクトを新しい Decorator オブジェクトでラップすることである。
がわかってない奴がいるな デザパタの目的とされがちであるが
常に失敗しているのが語彙の共有
いつでもつねに認識がバラバラｗ >>579
ごく一部の人間が正しく理解できてないだけで、
> いつでもつねに認識がバラバラｗ
は言い過ぎ >>577
> 関数型インターフェースの方が簡潔になる
そんなんでいいなら Smalltalk でも簡潔に書けるけどね
http://ideone.com/RZHQ7P Smalltalkに意味なんかないよ
登場してから30年とか40年とか経ってるのに
誰も現場で使ってない言語だからね
40年という歳月は結論を出すのに十分な時間だと思うよ
これから先もずっと使われないだろう
こんな言語についてあれこれ考えるのは時間の無駄だよ
御幣を恐れずに言うと、Smalltalkは間違っている、机上の空論
本当によくできていたなら、もうちょっとぐらい使われていてもおかしくない
少なくともRuby程度ぐらいには使われてないと話にならない
Smalltalkは実用にならないスジの悪い言語だということ Smalltalkは言語だけじゃダメで。
windows上では使い物にならないから仕方無い。 要するに、windows自体がオブジェクト指向に向いてないんだよ。 結論。
誰も Smalltalk なんて知らない www それは関係ない
なぜなら概念上の問題より運用上の問題のほうが大事だから
いくら概念的な素晴らしさを語ったところで
まともに運用できないならゴミ
使えない >>574
> Javaではデコレータパターンを使う問題を
> デコレータパターンを使わずにより簡潔に記述した例。
お前は勘違いしているな。
デコレータパターンを実装しなさいというお題なんだから
それがデコレータパターンなんだよ。
Javaならこういう実装でやるが、他の言語では
その実装方法が違うだけ。 >>582
まあ仮にSmalltalkが本当に誰も使ってなくて
処理系も失われたり、あるいは as-is で放置された言語だとしたら
そんなものに意味がないって意見は全くもって正しいよね シングルトンやアイテレーターなどは時代が変わっても重要だろうけど、
デコレーターは継承関係への依存度が高いから微妙だな。 >>583
Smalltalkは独自のGUIもそうだけれども、もうひとつ、通常のセルフホスティング
（自身で自身を記述）にとどまらず、処理系を構成する実行時オブジェクト群を
仮想イメージと呼ばれる、ある種のオブジェクトストアに永続化して次回起動時も
継続利用する運用スタイルも毛嫌いされるよね。個人的には示唆に富んでいて好きなんだけど >>587
いや？
クロージャで実装しているのだから、デコレータパターンによる実装ではないよ。
コード読めない子？ > クロージャで実装しているのだから、
クロージャで "何を" 実装しているの？ デコレータパターンを実装できてはいないんだよｗ
これでわかった？ｗ いや、何を実装したのかを聞いたんだが？
実装したものは何？ >>590
あのあたりはむしろメモリや記憶装置いくらでも使える現代向けというか
過去にオブジェクト指向の要素をちょっとだけ輸入してみた中途半端なオブジェクト指向言語が次々出ては滅びの興亡続けてたのは
"コンパイル後のサイズが大きいじゃないか"とかいまじゃヘソが茶を沸かすような理由がメインなわけだし。 デコレータパターンと同等の機能をクロージャで実装した
じゃね？
同等の機能を持った違った実装があるのは当たり前じゃね？
デコレータパターンと同じような機能をもたらすけど
デコレータパターンじゃない実装は普通にあり得るんじゃね？ >>595
パターンは機能じゃないよ。設計。
デコレータパターンという設計
この設計の実装はいろいろある。
決まっていない。
Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。 wikipediaにすら書いてあるしｗ
https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
デザインパターンは、よく使われる設計を一般化された形でまとめたものに過ぎない。
そのため、具体的な実装を提供するものではなく、
あくまでもコンセプトとして参照されることが意図されている。
つまり、サンプルコードは、実装例に過ぎない。 >パターンは機能じゃないよ。設計。
それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ？
俺の言ってることと一緒だね ID:jTAWnEUaを教育してあげる義務は我々には無い >>599
わざわざ複雑にしないでいいよｗ
やりたいことがある。
でも説明するのが面倒くさい。
じゃあ「デコレーターパターン」と呼びましょう。
これで話は通じてるじゃん。
だからこれだけの情報でコードを書くことができる。
そのデコレーターパターンを
クロージャーで実装したんでしょ？
そういえば良いんだよ。 >>600
じゃあ一緒に勉強していきましょう（笑）
http://www.techscore.com/tech/DesignPattern/foundation/foundation1.html/#dp0-2
> 前章でも説明したとおり、デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」を
> まとめたものです。 デザインパターンを利用するメリットとして、最初にあげられるのが、
> 「再利用性の高い柔軟な設計ができる」という点です。各パターンには、多くの知恵が凝縮されています。
> これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
> 初心者でも先人たちが詰め込んだ「知恵」を利用した設計をすることが可能となります。
> また、先人たちの知恵を参考にすることで、設計力の向上も期待できます。
>
> 次のメリットは、「技術者どうしの意思疎通が容易になる」ことが挙げられます。
> デザインパターンを習得している技術者どうしであれば、設計について相談するとき
> 「Singleton パターンで行きましょう」とか「Strategy パターンが応用できるのではないでしょうか」と
> いうようにパターン名で設計の概要の合意を取ることが可能です。デザインパターンを
> 習得していない技術者には「こんなクラスを作って、このクラスはこんな役割を持っていて・・・。」と
> 延々と説明しなければなりません。このように、デザインパターンを学習しておくことで
> 開発者どうしの意思疎通がスムースになるのです。
あなたは何で勉強していますか？ 話をややこしくしているのはあなたです
>パターンは機能じゃないよ。設計。
↑これは君が言ったことだよね
その上で俺は、同等の機能を持った、違ったデザインなんじゃね？って言ってるわけ
機能が同じであっても、同じデザインパターンとは限らない
何故なら、デザインパターンは機能じゃないから、設計のパターンだから
↑君の言ってることと全く同じだよね
だから同じ機能だけど、違った設計パターンであり
同じデザインパターンに属さない設計は有る
ということを君は認めているということ デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの
ってのは正に君が自分で言ったことであって
それは俺も了承している
だから同じ機能であっても、それだけで同じデザインパターンとは言えないよね
と俺は言ってるわけ
なぜならデザインパターンは機能では無いから(君の言ったことだよね)
そもそも俺とお前とのやり取りに、何のとどこおりも無い
俺は、>>596で同等の機能を別の設計で実装したんじゃないか、と言い
お前は>>597でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている
合わせると、「同等の機能であっても同じデザインパターンであるとは限らない、設計で決まる」
という結論が得られる デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。
これと同じことが他のデザインパターンでもできるんじゃね？という主張だったと思うんだが。
Singletonは言語によって容易に達成できるものもあればそうでない言語もあるが、そう難しくは無いはず。
OCamlだったらmutable valueを持ったモジュール使えば同等のことが実現できる。
Adapterパターンも変更できない物がオブジェクトだったら関数1つで済むし、
モジュールだったらファンクタ使えば良い。
これを続けていけばデザインパターンがOOPの表現力の低さを解決する妥協案である、と示せる気がするが、
逆にOOPでデザパタ使うのが一番簡潔になる問題を探す方が難しいかもね。 やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。
まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。
そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。 OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。
C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。 >>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。
JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。 デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。
「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。
プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。 内容を理解してないから例にある記述方法しか受け付けないんだよ。 > だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。
じゃあなんでこんな本が存在するんですか？ｗ
Rubyによるデザインパターン-Russ-Olsen/
https://www.amazon.co.jp/dp/4894712857
JavaScriptデザインパターン
https://www.oreilly.co.jp/books/9784873116181/
The Design Patterns Smalltalk Companion
https://www.amazon.com/dp/0201184621 >>610
あ。引用部分は自炊本の OCR のコピペなんで、タイポは脳内補完ねがいます。 >>612
GoF も「Smalltalk では簡単に記述できるものもある」とは言っているけど、
ぜんぶがぜんぶとは言っていないよね。 >>612
おまいみたいなバカに本を売り付ける為だろw > だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。
Smalltalkを好意的にとらえて持ち上げてくれるのは、狭い視野で意味なし認定しちゃう人たちよりは
ファンとしてはありがたいけど、これはさすがにオーバーエスティメートだし、
もうちょっとSmalltalkならではのアドバンテージを学んでから、適切な持ち上げ方をしてほしい… 「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。 >>619
もしそうだとしても、少なくとも>>591は「GoFの（デコレーター）」と明記すべきですよね smalltalkって簡単に色々できるんでしょ？
なんで現代でメジャーじゃないの？ 日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ？ MSがVisual Smalltalkをつくらなかったから >>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが？ はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。 >>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン（GoFの定義如何に関わらない）というのを提示してもらうことはできますか？
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。
そもそも Smalltalk ではデコレーターパターンが不要（なので、実装はナンセンス）とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。 つか、>>546のruby版って一体何？
デコレータパターンのつもり？ >>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満？ >>628
あ、デコレータパターンの実装だったんだ。
同じ感じでこれ実装できる？
class Log
def output(s)
puts s
end
end
class TimeStampLog
def initialize(log)
@log = log
end
def output(s)
@log.output "#{Time.now} #{s}"
end
end
class PidLog
def initialize(log)
@log = log
@pid = Process.pid
end
def output(s)
@log.output "[#{@pid}] #{s}"
end
end log = TimeStampLog.new(PidLog.new(Log.new))
log.output 'aaa'
log.output 'bbb'
log2 = PidLog.new(TimeStampLog.new(Log.new))
log2.output 'aaa'
log2.output 'bbb'
結果：
[24968] 2016-08-04 14:41:58 +0900 aaa
[24968] 2016-08-04 14:41:58 +0900 bbb
2016-08-04 14:41:58 +0900 [24968] aaa
2016-08-04 14:41:58 +0900 [24968] bbb >>631
なんか実装手段が違ってきてますが・・・。
>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。 >>632
> なんか実装手段が違ってきてますが・・・。
本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので
> closureを使えばデコレータパターン同等のことができる
>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい >>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。
WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。
一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか？
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。 >>626
だーかーらー、
デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装（当然、上記デコレータパターンの実装ではない）で実現できる。
という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる？ >>634
> 一方、>>546のコードだとそうはいかない。
単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
http://ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。 >>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。 >>638
Smalltalk と C++ との比較で？ それならもちろん Smalltalk です。
（同書P.289より）
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。
（標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。） >>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね？
別にSmalltalkが特別ってことにはならない。 >>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、
修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。 デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。 >>640
Smalltalkが特別ってことにはならないという点については同意します。
ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも
とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか？
あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を
http://qiita.com/jonichonpa/items/208dc2361414f93efacf
Smalltalkで書いてみました
http://ideone.com/oplhQu
もちろんSmalltalk方式を採用した言語（たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため
http://ideone.com/xlQZqc イテレーターパターンをSmalltalkで書いてみたわけね。 イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ >>643
for each (range based for）でいいじゃん。
for (auto& item : collection)
{
// print an item
}
クロージャ風がいいなら、
std::for_each(collection.end(), collection.begin(), [](auto& item){ /* print */}
アイテレーターが登場するけど昔の名残みたいなもんで、
本質じゃないだろ？（範囲を指定してるだけ） >>642
クロージャを使ったらデコレータとは言わないのでは？
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。
無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。
言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。 >>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。 >>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。 Structureは日本語にしたら
構造って意味ですよｗ >>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。 > そこが実質的な定義だと（俺様が）言ってるの。
知らんがなｗ
お前が何を言ったところで、
Structureは日本語にしたら構造
Definition（定義）じゃない。
まさか単語の意味を強弁するとは思わなかったなｗ >>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。 この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。 デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。 まさかデザインパターンがGoFの23個だけだと？
あれはパターン例だよ >>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ？ Structureは日本語にしたら構造
Definition（定義）じゃない。
国語と英語の問題なｗ あるプログラム片の構造がパターンカタログのものと異なっていたら、
そのプログラム片はそのパターンの実装とは言えないな。
実際問題として、このスレで出ているRuby実装は、GoFに掲載されたデコレータパターンの実装ではない。
それを無視するなら、あなた (ID:jTAWnEUa) にはデザインパターンを使うための
最低限の素地が備わっていないということ。 >>644
あまりにひどくて、なにをいっているかわからなかった。SmalltalkはともかくRubyのコードも読めないのかと。
内部イテレーターを使ったこの実装をイテレーターパターンだと言い切るのはどう考えても無理があるし、
同じ理屈でクロージャーを使った件の実装をデコレーターパターンだと言い張っているなら混乱するだけだからやめてほしい。 >>664-665
この二人は単に常識的な発言をしているだけだが
きっと相手には伝わらないだろうね 結局オブジェクト志向が理解出来なくて管を巻いていたら
世間はプロトコル志向に移ってしまったでござるの巻
お前ら何周遅れたら走り出す気になるの？ Swiftのプロトコルも何周回目か遅れですよ？
ScalaやRustのトレイトとか知らないんですか？ イテレータをアイテレータって書いてる人がいるけど
どこの方言なの？
weblioさんの発音もイテレータなんだけど weblioワロタｗ もっとちゃんとした辞書持って来いよ。
Merriam Websterとかさ。和英辞書を引用して日本語論じたりしないだろ？
色々調べてみたけど、Wikitionaryのiterateでは二重母音の発音も載せてる。
その他の辞書では見つからなかった。
実際に英語ネイティブのアメリカ人が/ai/でも発音しているのを聴いたこともある。
伝統的には一般的な発音じゃなかったけど、IT界隈でよく使われているうちに、
発音変種が発生したんじゃないか？ 英語発音学的にはどちらでも許容されそうだし。 >>669
方言というより極度の経験不足なんだろ
イテレータについて人と語った事が無いから
間違いがずっと正されずにここまで来たんだろうな >669
iとかitとかitrとかiterとかに略すから
アイ、イット、アイター、アイターとかって呼んでいるのでは
発音している本人に聞かないと真相はわからんがな クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ クロージャーを使った実装はデコレーターパターン（GoFの）ではないという話なんだが >>673
別のパターンって言ってるだけでは？
覚えやすさや関連性からデコレーターの名前を関するのは自由だけど。 Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする デコレータパターンの機能を持っている設計を
全部デコレータパターンとしてしまっては
デザインパターンの意味がないからな
そりゃどんな方法でも同等の機能は実現するかもだが
ある程度を設計をパターン化して縛るのが目的でもあるからね
なんでもOKだったら意味ないよね カタログ化の価値を下げようとする連中は居るんだよ
広義のデザインパターンは～とか
○○も××パターンの亜流と言えるだろう～とか
拡大解釈と独自解釈でどんどん元の輪郭をぼやかしていくんだよ >>677
ケーキにホイップクリームのせるのもおちんぽにコンデンスミルクかけるのもデコレーションには違いないだろ実装が違うだけでやってることは完全に同じなのだから継承か委譲かクラスかクロージャかといった細かい違いを気にしなくていいからこその設計だと思うのだよ 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ >>680
そうか、おまえがいう「デザイン」「ソフトウェア設計」は実装を縛らないのか。
ずいぶんフリーダムなプログラマだなw クラス図レベルがデザインパターン。
そこから実際にどう具体的な言語でコードに落とし込むかが実装。
クラス図レベルで全く違うものはパターンとして別物です。 おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな？ >>684
なまってるんじゃなくて、発音が[i]の母音に強いアクセントがつくと[ai]に転じるのは普通。
iterateの第1母音は普通は[i]だが、iterateという語を特に強調する時には[ai]になることもある。
ちなみにweblioはUS出身のNLP研究者にも評価が高かったりするから、そう馬鹿にしたものでもない。 >>686
Haben Sie gelesen, eine deutsche Übersetzung? >>689
Was davon ist im Zusammenhang mit? >>691
Das ist meine Frage. そんなアイレテーター君にヒントをもらった>>646 ですが、
週末の余暇を使って調べ調べ C++ で書いてみました。
http://ideone.com/aMHgqO
なるほど。このくらい抽象化して簡潔に書けるなら
今の C++ には35年ほど前の Smalltalk 同様イテレーターパターンは不要と言い切ってよさそうですね。
惜しむらくは逆順用の range-based for くらい用意しておけよ…、という不満は残りますが。^^; そもそもbegin, endなどのモロモロが
既に（外部）イテレータ以外の何物でもないわけでｗ
内部イテレータ形式を欲しがるかどうかはともかく
range-based forとかはどうでもいいよねこの場合 アメリカ英語なんて
英語の方言そのものだろ。ｗ
トマトをトメイトゥとか、
ポテトをポテイトゥとか
馬鹿みたいな発音するんだぜ。
アイテレーターみたいな馬鹿っぽい発音が好きなのか？ >>695
おっしゃりたいことがよくわからなかったのですが
「イテレーター（内部なり外部なりの）が標準で提供されていればイテレーターパターン（GoFの）はいらない」
という主張（>>639,646）に対して「そもそも～」はどういう反論で、
range-based forがなぜ「どうでもいい」という話になるのしょうか？ >>693
おいおい、Neinに続いて肯定文とか、なんなんだその日本語みたいなドイツ語もどきはw >>696
はいはい、あなたは馬鹿ですよ。認めてあげましょう。 >>695
>そもそもbegin, endなどのモロモロが
>既に（外部）イテレータ以外の何物でもないわけでｗ
だめだ、こいつは手の施しようがないw >>697
ごめん
流れつかめて無かったわ
標準のコンテナにイテレータがあるんなら
それを使う限りはイテレータパターンの必要も無い
（内部イテレータ形式もrange-based forも無くてもいい）
それだけの話
スレの最初のほうに既に書かれてる話 もう少し正確に言えば、言語やライブラリが
イテレータパターンを実装しているから、
あとはそれに従うだけって感じかな。
意識せずにイテレータパターンを使っている。 >>702
「意識せずにイテレータパターンを使っている」は大間違い。 >>704
そやね
そっちが正しい
パターンを使うのは設計者だからね おっすおらフリーダムプログラマ
日夜社畜プログラマと戦ってるだ >>702
> もう少し正確に言えば、言語やライブラリが
> イテレータパターンを実装しているから、
正確に言うなら、イテレータパターンというのは、
> コンテナオブジェクトの要素を列挙する手段を独立させることによって、コンテナの内部仕様に依存しない
> 反復子を提供することを目的とする
実装パターンのことで(Wikipediaより)、言語やライブラリがiterableな何かを提供しているからといって、
それらがイテレータパターンを実装しているとは限らない。 >>680
> 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
発想が逆だね。
ある機能を実現するための実装パターンを分類・カタログ化したものが、GoFのデザインパターンだ。 まさしくその通りだね
そして同じ機能だったらどんな設計でもOKとしてしまっては
デザインパターンの意味がない
でもこの話題はもう終わりにしたいね だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
だから積み木のおうちでも構わないんだよなぁ パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。 >>709
とは言っても言語が違ってもデザインパターンは通用するわけで
実装がたった一つというわけじゃないのは確か
C言語でオブジェクト指向をすることだってあるし、
クラスがなかったES5時代のJavaScriptでもデザインパターンは作れた。
重要なのはデザインパターンの設計に出てくる登場人物があるかどうかではないだろうか？
例えば、Decoratorパターンだと、Component、ConcreteComponent、
Decoretor、ConcreteDecoratorという登場人物がある。
これはクラス図で書かれているだろうけど、別にクラスである必要はない。
例えばクロージャーを使って実装してもかまわない。
またインターフェースは明示的に継承していなくても、事実上特定の関数を実装していなければ
正しく動かないなら、それはインターフェースを使っていると言ってもいいだろう。
これと同じ登場人物が出てくるものは同じデザインパターンといっても良いだろう。 そこまで行ったら別物だって。
クロージャーやら使ってクラス図レベルで逸脱してもいいという
宗派をひらきなよ。 >>713
そうはいってもだね。
クラス図がないES5でもデザインパターンの
設計通りに作れるでしょ？ >>714
クラス、クラス図がないからデザパタにクラスは不要というのは、本末を転倒してますよ。
GoF も述べているように（>>610） クラスの無い言語では、クラスの役割りを「カプセル化」パターン、
「継承」パターン等で補ってから、その上でたとえばデコレーターパターンを実現しているというだけです。 >>716
なるほど。言語仕様としてクラスの有無ではなく
継承パターンができていれば、その実装がクロージャーでも
かまわないということですね。
そして継承パターンと言うものには、何が何を継承している
という概念があるはずですから、その「何」が登場人物に
なるわけですか。 「○○言語だともっと簡単に実装できる」君と
「クロージャを使えばもっと簡単に実装できる」君は
いい加減うざいよ？ >>719
その通りだと思います。
まずはソフトウェア設計は実装ではないが、
実装を縛る規範であるということを
理解したらいいと思います。
それが理解できたら帰っておいで。 デザインパターン
日本語で
設計見本でいいですか？ >>708
それは過程の話な結果として実装を示すならインプリメンテーションパターンと言っているだろうしかしデザインパターンと言っているから実装を抽象化したものだ具体的な実装を示すものではないってことさ その前に君の書き込みを日本語のパターンにしてください >>681
設計が実装を具体的に決めてしまったら設計の意味がないと思うんだよおトイレとお風呂が一緒になってますってことと具体的な便器の形とは分けられると思うんですデザインパターンっていうのはいわばそういうものでお風呂とトイレを一緒にしたら便利だよってことさ いい加減、オブジェクト指向 vs 関数型なんていう無意味な議論やめようよ
直交する概念じゃん
関数型言語でも「本物の」オブジェクト指向プログラミングは出来るし、
最近の流行りはオブジェクト指向言語に関数型的な機能を付けることだろう 本当のオブジェクトプログラムは、メッセージ交換だから、関数型が入る余地なんか無いけどな。 お前ら、早く本論に入れ！
美少女クラスはなぜ人間クラスを継承出来ないのよ！！！ 美少女はクラスじゃなくて人間クラスのインスタンスで
パラメータが特定の値のものなだけだよ。
プリンセスメーカーであれば「魅力」のパラメータが
高くて「年齢」が若ければ美少女なんじゃね？ >>732
まあそうだな。
人間クラスの女性属性で年齢属性が十代で、
あとはいろんなパラメータがバランス良く絶妙なバランスであるだけ。 >>733
排便性能とでもいうパラメータ作れば良いんじゃねーの？
美少女じゃなくても排便が困難な人っているからな。 |
| 彡 ⌒ ミ
＼ (´･ω･`)またうんこの話してる...
(| |)::::
(γ /:::::::
し ＼:::
＼ オブジェクト指向は愚かな考え。
排便メソッドを実装した人間クラスから美少女クラスが作れない。 アヒルががーがーなくのではなく、がーがー鳴けばそれがアヒルなのである
うんこができればそれは人間なのである >>738
「ウンコを覗くときウンコもまたおまえを覗いているのだ。」
もうこの子は脳の端までウンコになっちゃったんだよ… 頬を紅潮させた少女のアナルは今にも決壊寸前のダムの如くヒクヒクと静かに脈打つのであった
そのアナルをまるで獲物を狙う蜥蜴の様な眼差しでジットリと凝視していたお前は… やはり、オブジェクト指向は愚かな考えなんでしょうか？
それはなぜですか？ オブジェクト指向にクロージャーが取り入れられてから、
オブジェクト指向は更に便利になった。 どうせなら理想のクロージャの構文はどんなものか議論しよう。
美少女のウンコの話はもういいから。 じゃあ質問
若い時は買ってでもするものな～んじゃ？ コンビニでトイレだけ借りるのは気まずいので後で何か買って帰る >>752
http://find-travel.jp/article/2123
シンガポール初 キッズクラブ
１２歳までの子供が安全に遊べます。小さい子供連れのファミリに―にはうれしい施設です。
セントーサエキスプレスの終点ビーチ駅で下車、徒歩五分ほどです。
子供は有料ですが、付き添いの大人は、無料です。 http://www.dan-b.com/tp_luna/page1_1.html
ウェーブスターライド
すべり台
もくば館の電動木馬
自走式のジェットコースター。小さなお子様でも、
大人の付き添いがあれば乗れる。
付き添いの大人は無料にしてくれる心遣いがうれしい。 オブジェクト指向と計算式という対比がまずおかしいスレ >>757
その前に>> 1の脳みそがオカシイ。
議論以前の話 >>733
排便メソッドつくってうんち吐き出させれば良いじゃん… できの悪いプログラマはこうやってくだらんことに執着した挙げ句道を外すからな
オブジェクト指向を禁ずるのは当然だが、プログラムも規制すべきだろ 外に公開するインターフェイスだけオブジェクト指向で中身は手続きとかできないの？ なんでもかんでもOOPしないといけないという強迫観念も新しい病気みたいなもんだ OOPは自然な概念。
しようとしなくても自然にOOPで書いてしまう。 んじゃ、Cでファイル読んで行毎に番号振るプログラムを自然にOOPで書いてくれ。
OOPな言語でも油断してると手続き的なコードになるのが実感。
手続き型言語や関数型言語のが自然と言えば自然。
OOPはどっちかと言うと手続き型言語の限界を超える苦肉の策。
有効ではあっても、自然ではない。 手続き型の言語使ってるんだからそりゃ書き方は自然に手続き的になるわw >>765
とりまなんかのOOPLで「ファイル読んで行毎に番号振る」操作の“油断した”版をideone.comあたりで晒して見せてよ >>765
> Cでファイル読んで行毎に番号振るプログラム
FILE構造体使うからOOPだな。 後での取り回しのために動作分離してオブジェクトにするんであって
なんで"その中身をオブジェクト指向で書けるか？"なんて
頓珍漢な発想が出るのかの方が不思議だよ。 まぁそうだよね。関数型だって関数の中味に手続き書くだろうし >>771
関数型言語では手続きは書かない。
式か、式とパターンマッチやガードによる条件わけだけ。モナドもdo形式で書くと手続きっぽいけど、実際は大きな一つの式。
if/caseに似てるけど、文と式が入り乱れるのと違って全部式。
それで何が嬉しいかと言うと、正しい動作をすると言う証明が出来る。 せやね関数型言語でも中身はモナド駆使して手続き的に書くのが自然やからね
…せやろか？ >>767
import sys
for i, line in enumerate(open(sys.argv[1])):
____print i, line,
Python3だとprint i, line end = ' '
ついついこう書いちゃうだろ？
でも、出力先がGUIになった途端破綻する。
そう言うのを見越して汎用的にしとかんと。 出力先を切り替えられるようにしたい、は別の要件でしょ CでOOPしてたやつって、なんかのGUIライブラリでなかったっけか？ オブジェクト指向の方が自然だと思うし好きだけどPythonやjsみたいな動的型付け言語でオブジェクト指向は無理というか無駄な気がしてきた
オブジェクト指向は副作用を限定化するためにカプセル化が必須だけど動的型付け言語だとそれが保証されない
横からいくらでもメンバの付け足しやメソッドのすげ替えができてしまう
そうなると副作用の保証ができないどころか、静的解析によるインテリセンスやエラー検出というメリットさえ捨てる羽目になる
そうなるともうオブジェクト指向で作る意味がない
クラス単位で保証ができない以上、関数で保証する他なく
必然的に関数型にせざるを得ない 「世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない…
そうでなければ世界はバラバラになってしまう…」
「どうしたんですか？先輩」(もぐもぐ
「おお後輩！…なんだそれ？」
「売店がパンじゃなくて弁当扱い出したんですよ
ゴミかさばるから売店とこで捨てろですって。
まぁ、どうせ僕が一括して持ってくんでしょうがw」
「後輩」
「はい？」
「カレーある？」
「たしか」
「じゃあ、それ一つ」
「はい」 パイセン方、JS勉強したてでオブジェクト指向って言葉が出てきたばっかでよく分かってないドブネズミ以下の僕に教えて
オブジェクト指向ってプログラミングのルールとか具体的な所作のことを指すの？
例えば「このプログラムは誰が読んでも分かりやすいものしよう」程度のものはオブジェクト指向とは言わないの？ >>785
最初、「適当に飛び先決めて好きなように処理書いて戻す」やってたら
後でプログラマが死にそうになったので
"入り口があったら出口はここ"とブロック化しようぜ！が『構造化プログラミング』
Cなどが直接の成果で今の言語はほぼこの流れを受け継いでる。
次にブロック(サブルーチン)化されたからこれをクラスとして使いまわそうぜ！が『オブジェクト指向』
ここで単純に使い回しの方向でCから発展したのがC++
主目的が使い回し。
それとは別にブロックを使い回すにあたって「これをやれ」という具体的な
コマンドを受けてクラスが独自に動くようにすれば
相互の関係がゆるくなって取り回しと修正が楽になる。というのが
smalltalk>objective-C>JAVA～と続いてるメッセージ/メソッド方式
目的はクラスの独立
もっと進んで命令すればクラスが自分でデータや仕事探すぐらいになるだろ？
というエージェント指向はまだ実現していない。 Javaをそちらのダメな考え方の方に入れるのはJavaが可哀そう メソッドはメッセージ側のスタイルなんでなぁ。
ウィキペディアの「影響を受けた言語」書き換えてくるかい？
「クラスとは構造体に関数がついたもの」って90年代の
C++なんかをベースにしたオブジェクト指向の説明とか
いまじゃ誰も電波すぎて理解できねぇよ。
「自動車は馬車から馬が外れたものである」かっつの… オブジェクトはデータに自身を操作するための処理が付いたもの
というありがちな説明は、これを正しいとするかどうかは別として
電波すぎて理解できない、という程のものではない
厳密かどうかは置いておいたとして、具体性があり、ある種の分かりやすさはある
「データ」とか「処理」とかいう言葉は、プログラマじゃなくても知ってる一般的な言葉だし
大体の人が正しく理解して使っているであろう
ということと、コンピュータの根本の原理も大昔から特に変わってないので
「データ」や「処理」という言葉が、理解できないほどに意味をなさなくなっているわけでもない
普通に理解できる範囲
実際にはもっと賢い表現が適切であろうが、今は理解できる文言かどうかが焦点であるから
関係が無い
どちらかというとsmalltalkというかアランケイのオブジェクト指向の表現の方が若干電波であり
事前に知識が無ければ、何を言っているかよくわからない、正しく理解できない
現実の部分が見えてこない、拡大解釈してしまう、思考が発散する、といったところ
最終的には生態系がどうのこうの言い出すから >>790
> どちらかというとsmalltalkというかアランケイのオブジェクト指向の表現の方が若干電波
アラン・ケイのメッセージングのオブジェクト指向は、設計・実装・実行・運用・保守とあらゆる局面における
「遅延結合」（…という表現だと実行時のみにひっぱられる人がいるので「決定の遅延」の方がベターか）を
メッセージングというお題目を通じて実践・徹底・サポートするアイデアなのだけど
http://d.hatena.ne.jp/katzchang/20080807/p2
http://metatoys.org/oxymoron/oxymoron.html
具体的にはどこらへんが“電波”だと感じるのか、きかせてもらってもいい？ >>791
前からちょいちょい思ってたけれど、脳がパソコンの一個のCPUで完結してる人とか
処理時間の遅れとか当人の脳内世界に存在しないから概念が理解できないみたい。
60年代に大学間などの通信ネットワークが作られてこのかた
現代のマルチタスク・マルチコアに至るまで
相手の処理終了が不明な状態で
"逐次実行なんか期待できない"というところから話が始まってるのに
脳が「プログラムってバッチ処理だろ？」で止まってるから
「順番に動かないプログラムなんてあるか！」って本気で思ってるんだよ、こういう人… >>792
>全部電波じゃねえかwww
うん。だから例えば具体的にはどんなとこころ？
あるいは件の主張を端から理解する気が無いのならレスは無用に願います >>790
>事前に知識が無ければ、何を言っているかよくわからない、正しく理解できない
Smalltalkを理解するために事前の知識は要らないぞ。
実践せずに本やブログ記事を読むだけで理解しようと思っている人は苦労するだろうけど。 >>795
んー、それはどうだろう。気持ちはわらんでもないけど、ちょっと言い過ぎではないかなぁ…
たとえば同じように Python を“理解するために事前に必要とされる知識”を問われた場合、
どんな答えを想定しているか教えてもらえる？
あるいは Java なら必要だけど、Python であれば Smalltalk と同程度には必要ないとかそんな程度の話？ 例のFILE構造体を用いたファイル操作はファイルシステムに対する低水準な操作がカプセル化され利用者から見えない設計だからオブジェクト指向設計、
と言って良いものかどうか…
（内部ではiob[ ]という配列操作になっておりインスタンスの個数に上限がある
&& 物理ディスクの個数はもっと小さいから、ファイル操作の内部の実装にはiob[ ]全体を操作対象とする手続き型のコードが含まれる
これをオブジェクト指向と呼んで良いのなら、ユニックスのシステムコールやWin32 APIからハンドルを受け取って
ハンドルに対して操作を行うのは全部オブジェクト指向と呼んで良いことになる
が >>793
順番として書けないプログラムがあるか！！！！１１１！！！！１！
確かに非同期に動く複数のﾌﾞﾂというやつは全体としては順序的でない並列的な振る舞をするが
それらを同期させる手順自体は順序として書ける（そうでないとCPUに処理させられない >>798
のような話もあると思う
マルチプロセスだろうが、複数のコンピュータだろうが、なんであれ
結局、処理の順番は大事だろう
というのもあるが、それは置いておいたとして
>"逐次実行なんか期待できない"というところから話が始まってるのに
逐次実行が期待できないケースがあったとして、それはそれで置いておくけど
逐次実行が期待できるケースにまでそのモデルを使わなければならないのかどうなのか
ってのは有ると思う
a = 1 + b; ・・・①
b = c + 2; ・・・②
の①②に関しては、少なくとも逐次実行を期待したいし
複雑なモデルは必要ないと思う
全部の個所において、ありとあらゆることを想定した包括的モデル、を適用するのは
あまり好きではない a={1,2,........100};
sum(a);
こんな場合、遠くの鯖でも近くの鯖でも10なら10ずつ(実際ににはもっと粒度が大きくないと割に合わないけど)分割して1-10の合計+11-20の合計+...って感じで全部揃いさえすれば順番関係無いって処理もあるお。 >>799
オブジェクト指向（C++とかじゃなくて上でいうアランケイ的な）が
逐次処理を否定していると思ってるなら、それは違う
言うならば、並列処理できるときにも逐次処理するのを否定しているという感じ。
その例にあげた依存のある計算みたいに、逐次処理が必要なところは
そうしなきゃならない。でもそうじゃないところは並列にやればいい。
CPUのスーパースカラも同じだね。前の命令の演算結果を参照するような
場合はパイプラインが止まるけど、依存が無ければ並列にどんどん進められる >>800
バ、バラバラに計算した部分和を最後にどうするんです？ >>803
1. 同期をとってから
2. 足し合わせる
のでは… C#, Java8 の、Parallel はそう。
並列処理で、最後に同期する
各スレッドでソートして、最後にマージするとか >>804
全部揃いさえすれば=同期とったら
「最後」にどうなる？
解:合計します。
突っ込まれるような事だったかな。。。 処理が一つの処理(タスク)単位になった時に
シングルタスク指向じゃやってられないよねってあたりまえの話なのに
なんで2017年に「そんなことはない！俺はオブジェクト指向が嫌いだ！」って
頭ごとシングルタスクのじいさんが湧くんだ… >>801
そういう風に俺は言ってない
>逐次実行が期待できないケースがあったとして、それはそれで置いておくけど
>逐次実行が期待できるケースにまでそのモデルを使わなければならないのかどうなのか
と書いた シングルタスクじゃ扱いきれなくて
マルチタスクが合ってるって思える部分が出てきたら
その部分ではマルチタスク指向とやらをやれば良いのでは？
オブジェクト指向とは直接的に関係が無いね C++とかハードに直結してるのに使い回しにだけオブジェクト指向を使おうとしたクソを通してオブジェクト指向知った人の末路がこれ シングルスレッドで同時接続数、1万をこなす、Node.js の、WebSocket
ただし、CPU を多く使うものは、ダメだけど そーゆーのとオブジェクト指向は本質的に関係なくない？
タスクの実装に向いているとしたところで
じゃあ、タスクの実装以外ではメリット無いのか？ってことになる
全体的にはマルチタスク的だったとしても、細かく見ていけば、個々はシングルタスクな部分も出てくるだろ
ほとんどのOO言語のオブジェクトの実装は
「データと処理を一纏めにしたもの」、っていう実装になってることが多いんだから
それを考えると、ほとんど何でも実装しやすいんだけども
(↑マルチタスクとかシングルタスクとか関係なくね)
この説明に拒否反応を示す人がいて
> いまじゃ誰も電波すぎて理解できねぇよ。
って言うから、どーなんだよ、と
オブジェクトはデータと処理を一纏めにしたもの、ってそんなに理解しにくいか？という話だったはず
ただ、この説明の仕方は、かなりボトムアップ的で、実装から炙り出したところがあって
「とどのつまりこういうことだろ」と頭ごなしに言われているようで気分が悪い
つまり、オブジェクト指向の効率的で有効な実装は、えてしてそうなる、というような
あとオブジェクトの全貌は語ってなくて、「言っている範囲においては間違ったことは言ってない」
程度の説明でしかないけども
しかし実際にそのような実装になってる言語が多いから、完全に無視してよいというものではないし
頭にはおいておかなければならないね >>806
>全部揃いさえすれば=同期とったら
さも最初から書いてあったかのように嘘を言い… 「あ、お客さま、こちらのおリンゴ少々傷んでおりますので、交換致しますね」
レジから店員が離れたらどうなっちゃうの！どうなっちゃうの！？
もう仕事できないよね！業務崩壊だよね！！
「はい、こちらで宜しかったでしょうか？ では御会計は～」
戻ってくるなんて説明なかったよね！処理が続くとも言ってないよね！！！
ボク意味わかんない！！！！！！！！ オブジェクト指向は、データと処理をひと纏めにする？
馬鹿じゃないの。
機能で分けるの。 >>816
機能で分けることはデータと処理を一体化することを否定しない 機能で分けるって言ったら、そら、なんでも機能で分けるもんなんだよ
例えばCなんかで関数に分けるって事を考えても、当たり前、機能で分けるわ
機能で分けるってだけじゃ何の説明にもなってない
むしろ機能以外で分ける必然性がないし
だから機能で分けるのはどのような何であろうと、分ける以上は当たり前そうする前提として
「具体的にどのような方法、単位で分けるの？」って部分がないと
その時に、データと処理を一纏めにしたものをオブジェクトとして、ってのが出てくる
クラスは機能で分ける、って文言は、おかしなクラス設計をする人に対して
クラスは機能で分けなきゃダメだよ、と注意するために有るのであって
オブジェクト指向の説明にはなってないんだよ
例えば、「関数は機能でわける」って言い方も出来るし、なんでもそうじゃん 平たく言えば「機能で分ける」ってのは
クラスの作り方や設計方針の話であって
クラスやオブジェクトの根底のメカニズムについては何も言及してないんだよ ふる～いサブルーチン的な「関数」の発想だと
たとえば「ドルと円を換算する」"関数"はただの「処理機」だから
レートと額を送ると換算額が返ってくる、という発想になる。
そこがオブジェクト指向では「ドルと円を換算する」"クラス"は
そういう処理をする「処理場」なので送るのは
"換算してくれ"という命令コマンドと額になる。
違いはなんだろう？
「関数じゃなくてクラスはレートってデータを持ってて、換算という操作関数が付いてんだろ？」？
違います。自動車が馬抜き馬車ではないように。
ポイントは「換算」というタスクは当該クラスが責任を持つ仕事で
処理を頼んだ側まで責任は及ばない設計になっていることです。
オブジェクト指向の思想ではそれぞれで責任が切り分けられているので
プログラムの修正の際に修正が延々波及する事態を抑制できるし
処理はタスクを行う実行単位で切り分けられているから
処理終了を待つ必要のないタスクは並列実行できる。
"そういうこともできる"ではなく"そういうことをやるように"仕様が作られている。
そういう違いです。 で、結局クラスやオブジェクトの持つメカニズムについては言及しないのであった
書いてある内容は「そういう風に考えてください、そういう風にとらえてください」
程度のものでしかない
後半の並列処理なんか全然オブジェクト指向と関係が無いしな
そういう風に書けば、そうなる、ってだけ
「ポイントは「換算」というタスクは～」の部分に関してなど
一般化して他のものに関しても同じことが言えるし
何の説明にもなってない
唯の一般的に良いといわれるプログラミングの作法を説明しているに過ぎない
もちろんその作法はOOPでも通用するが、OOPの説明にはなってない
例えば、クラスを"関数"に置き換えて
「ポイントは「換算」というタスクは当該"関数"が責任を持つ仕事で
処理を頼んだ側まで責任は及ばない設計になっていることです。
"関数"を使う思想では、それぞれで責任が切り分けられているので
プログラムの修正の際に修正が延々波及する事態を抑制できるし
処理はタスクを行う実行単位で"関数"に切り分けられている」
っていう風に言ったって別に通じるし、オブジェクト指向の説明になってないことが分かる
一般的に良いといわれるプログラミングの作法を説明しているに過ぎない
となれば結局、「関数とクラスは何が違うのか」って事がクローズアップされるべきで
「関数じゃなくてクラスはレートってデータを持ってて、換算という操作関数が付いてんだろ？」
ってのは結構的を得た説明なわけだ、少なくとも君の糞みたいな説明よりは だたし、オブジェクトはデータと処理を一纏めにしたものって説明は
オブジェクトの性質の全部を言い表しているわけじゃない
「言っている範囲においては間違ったことは言ってない」程度のもの なんかまだ現実を理解していないみたいだけど
誰かがそう考えているとかそういう話ですらなくて
"君が"一人で自動車が走り回ってるこの時代のど真ん中で
「いいや！自動車は馬なし馬車ともみなせる！誰も自動車の細かいシステムについて
俺に懇切丁寧にマンツーマンで教えてくれないからな！
あくまで自動車とかいうのは馬なし馬車にすぎない！！」
ってほざいてるからみんななんだこのボケジジイwと笑ってるだけだよ。 俺は別に笑われてないんだけど
君の書き込みは電波すぎて誰にも相手にされてないかもしれないが
これが自己紹介乙というやつか >>823
>書いてある内容は「そういう風に考えてください、そういう風にとらえてください」
>程度のものでしかない
だってOOPとかその程度のものやとしか言いようが無いし…
OOPにしたからといってチューリングマシンでできない計算ができるようになるわけでもないし、
高階関数の系の能力を超えるわけでもない
「オブジェクト」も「機能」や「データ構造」と同じく人間が勝手に設けた区切りと考えたほうが精神衛生上宜しい
「漏れの無い抽象化」を達成せしめたクラスに属するオブジェクトのみが、独立した数学的対象同然の正当性を有す
でもそうじゃないクラス（とそのインスタンスとしてのオブジェクト）も世の中にはゴマンとあり、実用OOPはそれらも包含してゐる
OOPの枠内の全てをスッキリ定義づけて一意のクラス分けを導くような数学は目下無いしこれからも無さげ ちな
>「関数じゃなくてクラスはレートってデータを持ってて、換算という操作関数が付いてんだろ？」 （823）
というんのはクラスを「レートという束縛変数を有する「換算」という関数」の定義とみなしてゐる、
とみなすこともできる、、 そこまでわかってるなら、手続き型言語には何があるかも分かってるだろ
紐解いていけば、手続き型言語には、「テータ構造」と「制御構造」の二つしかない
あとは定数とかもあるけど、無視しといてよいし
本当に、データ構造と制御構造しかない
クラスはこの二つをまとめたパーツ、ぐらいの認識でよろしい データ構造はメモリの空間的分割構造といえるし
制御構造はCPUの時間的分割構造といえる
これで空間と時間がそろったからプログラミングの準備が出来たといえる
クラスは単に、C時代はデータ構造と制御構造を別々に定義していたのを
区切りの良いところで纏めて定義しましょうってだけだよ
小さなプログラム(クラス)の破片を集めて大きなプログラムにしましょうってだけ
実際クラスのメンバ変数はクラス内のグローバル変数だしな >>830
>実際クラスのメンバ変数はクラス内のグローバル変数だしな
これはそう作ればそうなるし、そうでない作り方もできる
（クロージャにするなら通常はコンストラクタでメンバ変数の値を固定してしまい以後変えないとか、
OOPはハマるべきところにはきっちりハマるから、必要性はある
ハマればセマンティクスとコードの表記がきれいに対応してたいへん保守しやすく書きやすいコードになる
ただしそうなるのは漏れの無い抽象化が可能とか、漏れを設計で見えにくいところに隠せるとかそういうケースに限られる >漏れの無い抽象化が可能
こんなのよっぽど単純な事象以外ありえんだろ。 なんか、別なものに見立てての説明ばかり受けたせいで
なにかに見立てないとオブジェクト指向じゃないみたいな変な理解をしてる人がおるけど
要するに会社の「◯◯部」とか「◯◯課」みたいに
仕事と処理を送るとよしなにやってくれる単位で切り分けるってだけの話だし
「こういうことも◯◯課の仕事に新設」でも「仕事の質が変わったから部課を統廃合して編成しなおし」でも
部課が責任を持つことで取り回しが楽になるよね。だし いや、会社みたいな組織は必要な仕事の流れに応じて組み変わるじゃん？
無理ないちゃもんつける人は変化しないもの出してきて
「猫に羽が生えて飛ばないからオブジェクト指向は間違い！」って言いだすからw 部署部署言ったって、それはプログラムにおいては、何に相当するのか
って話がある
そこが無いと本当に意味のないたとえ話にすぎない
プログラムで会社の部署のように振舞わせるには
データと処理の両方が必要
データだけでも処理だけでも部署のようには振舞えない
classはプログラム環境のフルセットじゃないといけない
その意味で、オブジェクトは処理とデータを纏めたものでなければならないし
そうなってる
それだけの話 変な例え話を出したり、大仰な説明をしたりしないと理解できないだろう、なんて思ってる時点で間違ってると思わないのか
プログラムの素養の無い人でもOOならプログラミングできるようになります！とか妄想してるのか？ そうだね、自動車は馬なし馬車だから運転者は御者だね。
最近の馬なし馬車は馬を繋ぐパーツが欠落してるからけしからんね。 まだ馬なし馬車とか言ってるのかよ、進歩ないな
誰も興味ないんだって、そんなアホで的を得てない例え話 「クラスは構造体」じいさんにはぴったりすぎて例えですらないけれど？ 仮想の脳内の敵と戦ってるんだな、がんばれよ
その仮想の敵はお前自身でもあるからな ttp://livedoor.blogimg.jp/bookmatome-sonesoku/imgs/4/4/44bea95a.jpg 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
MNVZG ＞例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
この車、タイヤがパンクしてるぜ！
この俺、チンポがシコシコしてるぜ！
どちらも「オブジェクト指向」だろう？
注目は、選択肢イです。この上向きが集約で、下向きが分解です。
自動車は、アクセルやブレーキ、ハンドルなどに分解されるからです。
http://sm.seeeko.com/archives/65913086.html
浮気に激怒の妻、眠る夫の局部を切断しトイレに流す（印）
2018年02月25日 04:00
https://www.excite.co.jp/News/world_clm/20180225/Techinsight_20180225_477828.html 唯一純粋なオブジェクト指向言語と呼ばれることがあるSmalltalkが
ほとんど世間一般に普及していないのに、
オブジェクト指向が持てはやされるのはなぜ？
いいとこ取り？ いいとこ取りというよりはその時々で模倣可能な機能が徐々に実用化されてずいぶん近づいている
例えばホットスワップとかデバッグ中のコード変更とか
で、後者とかは実行中コンテクストの保持まではまだ模倣できてないとか このスレタイは「この世は飛行機も自動車も不要！北海道から沖縄までは徒歩で十分！」
みたいに見えるんだがｗ このスレはC++でオブジェクト指向に挫折したじいさんが
「オブジェクト指向なんてゴミだね！」って喚いて回ってたら
周り中から「あんなもん真のオブジェクト指向じゃねぇよアホw」ってツッコミまくられて
今度は「よくわからないけど“真のオブジェクト指向”ってのがゴミなんだろ！」って
暗闇に向かって手を振り回してみたら敵に当たるだろう！ってスレなんで… >>852
はげどう
>>853
全ての飛行機が墜落するほどにはひどい話ではない
メーカーや航空会社によっては墜落せずに目的地まで行き着くかもしれん
>>854
真のオブジェクト指向は人間の直感的分析とコードが完全に一対一に対応する
ただしそれは一般には存在しない だいたいオブジェクトを命令コードで書くという時点で理論が破綻している 破綻しているは言いすぎかもしれん
崩壊の序曲を奏でているに訂正
オブジェクト指向設計に基づくありとあらゆるプロジェクトが 序曲を奏でるｗｗｗ
＞オブジェクト指向設計に基づくありとあらゆるプロジェクトが
とか、なに言ってるんだよオブジェクト指向設計ごときにｗｗｗ そもそもモジュール間の接続を密にしたら変更の影響がどこまでも波及してシャレにならんから
モジュールごとに独立して、できるだけ抽象的な命令(メッセージ/メソッド)によって
モジュール内で処理を完結させるようにしよう。
モジュール内で完結してればパーツとして使い回しもできるし。
だからな。 モジュールの依存性を弱くするのは手続き型でもできる
foo.bar()はbar(&foo)と手続き的な表現にいつでも直せるので
オブジェクト指向でやれる弱結合は手続き型でもやれる
カプセル化というのも強力に型付けられた手続き型言語なら上の記法で同等の安全性が実現できるから
オブジェクト指向固有の特質というには弱い
オブジェクト指向が従来の方法論に対して際立って優れた（あるいはダメダメな）ところは
継承と多態性のしくみに夢を抱きすぎたところにある、、 手続き型プログラミングにおける型に振る舞いをくっつけたことで
さまざまな振る舞いを同一の表記で書けるため、テンプレートとの相性が良くなった、
というのもオブジェクト指向の功績の一つに挙げても良いかもしれん
きわめてコンパクトな表記でパワフルな仕事をさせられる
その結果、テンプレートを使わんとするほとんどの現場に破壊と混乱がもたらされた ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ クリーンアーキテクチャでも言ってるように、関数ポインタの安全な渡し方という見方が一番しっくりくる。 >>864
どう考えてもシコシコの主語は手であってちんこは引数だからだろ。手がなければシコシコという動きはありえない。一方手は何でもシコシコできる。お前のちんこでもな。 プログラミングを素人をわかった気にさせるだけが目的ならいいが、対等な議論ときに概念や言葉の定義を延々とこねくり回すやつは信用できない
完全に時間の無駄
例えば、オブジェクト指向を説明するときに現実世界の概念や具体物で例示するのは初心者に向けてならいいが、ちょっとプログラム齧った奴同士の会話ならただの言葉遊びでしかない
このスレ建てて遊んでるバカも、まず手続き型でオブジェクト指向並の生産性を実現できる具体的な方法論を開発してこいよ 依存性逆転の原則からオブジェクト指向を考える方が良い。
アホみたいな現実の見立てとか持ち出すと話が変な方向にばかり行く。 プログラム書く奴が無限の記憶力と管理力を持ってるんならオブジェクト指向なんかいらない
現実の人間はチープな頭しか持ってないだろ？ smalltalk/Objective-Cあたりはクラスに「おまえ何できるんだっけ？」って
動的メソッド問い合わせあるのに、ガッチガチのハードコーディングで効率化図る流れが
「狭い範囲でちゃんと作ればそんなんいらんやろ」してモダン()になる度に消える…
もともとはネットワークの各コンピュータでプログラムが
バラバラに非同期的に処理してる(停止も含め)想定だからそうなってたのに。 >>872
YAGNI そんなものは必要にならない
KISS シンプルにしておけボケが
その言語の開発者はソフトウェアの格言を知ったほうが良いねｗ やり方は何でも良いから、サルでも読めてサルでも直せるように作れ。 >>871
記憶力と管理力か
ソース固定で、個別の業務動作の全てをマスタ登録するメタシステムを作ったことある
画面デザインやボタンも、そのマスタから動的に生成される
毎年のように法改正があり、法改正のたびに膨大なプログラムの膨大なＩ／Ｏについて影響関係を調査する会社があり
このメタシステムなら、瞬時に検索できる
シンプルな書式で変更も簡便
Ｉ／Ｏ設計書のような書式で、ほぼ設計書と実装がイコール
ただし物事をなんでもＳＱＬに置き換えるような思考回路が要求され、ウルトラ級のＳＥしか扱えない
メタシステム自身の改修となると、ウルトラスーパー級（ようは言語自身を開発するようなことなので）
社内政治により引き継ぐ間もなく追い出された（または立ち去った）ので、その後は知らない
（担当者が自殺未遂したとの噂） 違うわ、デザインは別のテンプレートで完全分離
デザインはＩ／Ｏ調査不要なので、そのために設計情報を汚さない方がいいし、見たまんまの方がいい
項目名も見たままで裏に制御用の別名を持たない
ＷＥＢ系のフレームワークにも繰り返し部分の簡便化とか、結構すっきりしたものがあるが
もっと完全にソースや特殊タグをなくした感じ
繰り返し単位の終わりに終端タグぐらいはあったかな、細かいことは忘れた >>869
>例えば、オブジェクト指向を説明するときに現実世界の概念や具体物で例示するのは初心者に向けてならいいが、
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く “そいつに何をやらせたいか”を抽象化したレベルに持って行って
ママの「おしっこしてきて」で命令が済むように
１つ１つのモジュールが自立管理する前提で考えられた概念を
下から細々組み立ててた低レベル階層に導入しようとした結果
命令が低レベルに細分化されて思想を導入した意味がなくなってるだけやで。
もともとは巨大コンピュータのネットワークで
各コンピュータで独立して動いてるモジュールに
「これやって！」「できた？」って指令送る環境前提なので。 逆にオブジェクト指向を全否定した良コードを見てみたい。 ライブラリからしてオブジェクト指向
バリバリだから使わざるを得ないのだ Win32APIはハンドルベースだけどあの仕組みで何とかなってる
オブジェクト指向は親切の押し売り 「和文タイプライターは活字を探して打っていたがあれで十分
ワードプロセッサは親切の押し売り」って人前で言ってみ？ 親切の押し売り...少なくとも親切なのは認めてるってこと？ Windowsの話なら、Windows form、WPFやUWP、Electron & React / Vue.jsを例にすればいいと思うのだが。
Win32はオブジェクト指向のオの字も出てこないくらい昔の環境って感じだけど...使う場面ある？ って、>>883は>>881への回答か。使う場面とかどうでもよかったな。
>>886
HANDLE hText; char *pText; OpenClipboard(NULL);
hText = GetClipboardData(CF_TEXT);
pText = GlobalLock(hText);
GlobalUnlock(hText);
CloseClipboard();
オブジェクト指向...？ >>881
goで書かれたコードなんて大体そうだろ。 Goのコード初めて見たけど、
func main() {
Account := account{
name: "Takashi Takashima",
age: 30,
}
Account.disable()
}
否オブジェクト指向...？
少なくとも上記Win32APIよりはオブジェクト指向してるように見えるけど Goは構造体にメソッド持たせてんだからオブジェクト指向全否定なわけがない 何故オブジェクト指向かというと、チンポが勃起したり射精したりするのは、「数式」では無いからだ！
>>881
>逆にオブジェクト指向を全否定した良コードを見てみたい。
クリントン大統領の「不適切」というのは、チンポが独立して主体意思でシコシコしてしまったから。
チンポは独立した生き物であり、アメリカ大統領の権限をもってしても、制御することは不可能だ。
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
class チンポ extends クリントン{
super.不適切な関係;
}
クリントンーーーーーーーーーー
┃ ┃
┃ ┃
┃ ┃
┃ ┃
┃ ┃
ーーーーーーーーーーーーーーー
┃ﾁﾝﾎﾟ┃
￣￣￣￣
『人格を性欲に乗っ取られる』、つまりクリントンはﾁﾝﾎﾟに人格を乗っ取られて、ﾁﾝﾎﾟにｼｺられてしまった！ オシッコを出したりオシッコを止めたり、こっちはオシッコを「数式」で制御できる！
メッセージングを基礎単位として取ることは、より徹底的な遅延束縛を可能にする。というのも、
メッセージそれ自体は意味を持たず、実際にメッセージがオブジェクトに送信されてはじめて、意味が決まるからである。
https://qiita.com/ukyo-su/items/8c861f114809a96d1378
オシッコを出したり止めたりというのは、チンポから力を抜いたりチンポに力を入れたりと、
オシッコはオシッコそれ自体は意味を持たず、オシッコが尿道を介してチンポに送られることによって、
オシッコを出したり止めたりが可能になるということだ。
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 
