オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。 https://twitter.com/ProgrammingMono/status/665702678006140928 http://www.jst.go.jp/pr/announce/20151120-2/#YOUGO3 http://peace.2ch.net/test/read.cgi/tech/1450153388/ オブジェクト指向は直観に反するんだよな。 空かどうか判定するEmpty()を定義したCupクラスとLiquidクラスを継承したCoffeeクラスを作って、HumanクラスにRefill(Cup,Liquid),Drink(Cup)を定義すればいいだけだ
コーヒーの属性定義が広範囲すぎる
>>4 >>5 >>8 >>5 ってだけ その直感が､直感的だと思う時点
すまん、自動で口にコーヒー注いでくれない前時代のコップ使ってる雑魚おる？
現実をそのままモデル化してOO否定って5周くらい遅れとるで
形式主義ではコーヒーを椅子に置き換えても成り立つってことをいいたいんじゃないのか。
>>14 >>4 は現実をそのままモデル化できていない。 まー初心者(OOだけでなくプログラミング全般の初心者)向けのオブジェクト指向の解説とかでよくある説明だよね。
メソッドに何かやらせるのはやめて全て物理演算で動作を決めるべき
コンピュータ内でシミュレートするのではなく実際の分子原子を用いるべき
そんなことしたら分子原子の仕様変更で全てがひっくり返るぞ
メソッドコールのかわりにオブジェクトに対するフォースとトルクを搭載した言語を作ればいい
beDrank, beRefilledにかえればいいだけだろ。
>>25 >>4 は一般的なコーヒーのモデル化じゃなくて >>9 オブジェクト指向も結局はコミュニケーションというか
メソッドは関数ではない
オブジェクト志向で実装可能なことは、原理的に関数型でも実装可能であり
>>37 >>1 >>4 自分も参加してるプロジェクトでデスマが起こるなら多分自分にも原因があるんだと思うよ
>>4 >>4 みてぇなバカを揶揄したセルフパロじゃんかw ああ、ジョークまで完全に見えた >>4 は「プログラマがコーヒーを飲む」じゃなくて こういう根本的に理解できてないのが大量に居る時点で、オブジェクト指向は愚かな考えｗ
コーヒーはどうでもいいけど、
数学みたいにlog(2)でいいと思うが。
大分昔だけどフリー関数は気持ち悪くて、1.sin()とか1.cos()とか書けるのが本来の在り方だ、といった
数字は計算をしないからそう書いちゃいかんのだけどな
>>46 >>45 >>53 >>53 主語述語っていうけど、オブジェクトは目的語だからね
昔ながらのfunc( obj ); 形式だと、オブジェクトを主語と考える人はいないだろうし
メッセージングのオブジェクト指向の言い方で言うと、
>>58 演算子前置のポーランド記法は嫌いだなぁ
> 存在する意味がわからないレベルで嫌い。
Add 3 to 5, then multiple it by 2.
逆ポーランドの方が実装しやすいと思う。
>逆ポーランドの方が実装しやすいと思う。
x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
関数へのエイリアスのようなメソッドはドットで繋ぐのでなく、
釣りじゃなくて単に本当にあたまおかしいのかな？
x.sin()は手続き言語的だと思うけどなあ
現実世界をオブジェクト指向に当てはめるやついるけど馬鹿だよなー
どちらがより汎化されているかではなく
オブジェクト指向だろうと関数志向だろうとやってることは変わらない
特化させたいのに汎化する必要ある？
>>74 >>72 アクセル→エンジン→ギア→タイヤじゃなくて
>>79 ちうかこれオブジェクトが目的語とか言ってる人か？
>>74 >>82 >>68 オブジェクト指向は手続き型と直行する概念だと理解してないのが何人かいるな
>>80 sinは関数だろね。
>>79 ブレーキなんてのは外部から
関数を手続きだと思ってるならそれでいいけど、名前が関数ってだけで数学関数をそういうカテゴリーのものとするのは不適当でしょうね。
クロージャーって、関数なの？オブジェクトなの？
>>91 >>92 sin(x)は関数の値であって関数ではないよな。 関数は∀x∈double.sin(x)のことだよな。
>>85 >>97 この種のくそ議論って恣意的な答えしかないんだから、
>>95 つか、sin(x)ってなんやねんw
>>97 こういうシンプルな考えに基づくと、四角形と三角形は形状クラスから
>>87 例えばゲームでキャラクターが特定のアイテムを使用するモデル >>87 のようなオバカさん >>102 >>105 >>101 Smalltalkerが引き上げたらもう初心者しか残ってないのかよ
そもそもクラスだってオブジェクト指向とは直接関係ない >>84 美少女が云々言うのも一般的なクラスベースは融通が効かないねという話であって
>>111 >>97 >>113 xって中身は例えばfloatのデータ自身だぞ？
>>115 一般に sin に必要な引数は、 pi/2 とかの実数(もしくは複素数) かな。
>>117 新しいC++ではsin(x)でもx.sin()でも、どちらの方法でも統一的に呼び出せるようになる予定だから
どちらの方法でも呼び出せるんだから
こんなにややこしいプログラムがオブジェクト指向を使って
>>112 >>122 >>112 >>126 >>127 オブジェクト志向の考えだと
美少女クラスを欲する奴が美少女のウンコがついたぱんつを欲しがらないかと考えると
実装からメソッド設計を考えるより使い方から設計したほうが上手く行くと思う
肛門はコンポーネントとしてアタッチする。
関数型言語っていい点もあるけど、変更に弱過ぎない?
>>138 >>140 オブジェクト指向は細かい修正で済むと手を抜き続けた結果メチャクチャ悲惨なことになる
関数型言語は仕様変更のたびにめちゃくちゃ悲惨なことをしなければならないのか
関数型言語にとって型とはプログラムの設計図なのである。
>>155 >>157 関数型に不可能はない。関数型は神にのみ扱える至高の言語
広く使われてて実用的な言語は多かれ少なかれマルチパラダイム
関数型ンゴwwwwwwwwwwwwwwwwwwwwwwwwwww
今時は大学とかでも言語比較とか講義しているのかな。
>>173 また、書かれている内容のとおりイギリスのプログラミング技術のほとんどが
>>176 >>173 のリンクを読んだ感じではイギリスではどうも国を挙げて コードの奇麗さはなになに指向とかとはいつだって無相関だよ。
それはツールに設定したルールを守ってるかの判別器でしか無いな。
コードとは言語だから、綺麗な英語と置き換えてみればわかる。 学校で教えられるのは全部綺麗な英語だから実際の外人の喋ってることなんか一つも役に立たない。 汚いコードを書いてどんな汚いコードも読めるようになるのが大切。
実際に効果があるかそっちのけで、主観的な綺麗さばっかり気にしてルールを
あ、このスレの発言のことじゃないです。リアルの話。
コードコンプリートを書いたのはマイクロソフト()だぞ
>>186 >>190 Smalltalker達がいなくなったら途端に初心者スレ化w
Smalltalkの人はボコボコにされて
7 minutes of Pharo Smalltalk for Rubyists VIDEO http://pharo.org/ >>185 >>197 >>198 >>200 >>200 >>200 人間クラスを継承せずに、
>>206 天使クラスを継承するともれなくおちんちんがついてくるぞ
滑ったな
この板にいたなら知ってる人も多いだろうけど
そんな糞みたいな議論に持ってがれる時点でオブジェクト指向って切り口は何か問題があるんだろう。
美少女の件は、キモオタクラスからは美少女の排便参照不可にすれば解決。
排便量を(オブジェクト指向について僕ができる最大の議論)
>>216 排便量は流石にインスタンス変数で管理するだろ
get_unko を仮想関数にして美少女クラスは 0 を返すようにすればよい。
ワンチャン便秘のババアクラスを継承しても美少女クラスは成り立つのではないだろうか
日本の現場は永続化層が糞すぎてオブジェクトにマッピング出来ない
>>227 永続化層が糞でも関数型なら上手く行くならOOPより優れてるってことになるんでは？
RDBにオブジェクトをそのまま永続化できないように、
>>229 >>231 DBには関係代数という理論的バックボーンが存在するからやり方の是非に真偽をつけられるが
mutable なオブジェクトは糞。
例えばC++の入門書で必ずと言って良いほど載ってる複素数クラスComplexだけども、
ｽﾏﾝorz;
1+2i + 3+4i = 4+6i
>>242 関数型とかいう産廃はイベントがないから使い物にならない
ちょっとだけ期待してスレひらいてみたら美少女のうんこ
「美少女はうんこしない」という話を「美少女のうんこ」の話だと理解してしまうようなおっちょこちょいが
依存型とか見てみると結局行き着く先は同じなんだなと思うけどどうよ
美少女はウンコするのかしないのか。
うんこをした時点で美少女ではない
うんこをしないのにうんこを我慢するわけないだろ
スコープだったり変数の生存期間を気にしたりってのは関数型だろうとオブジェクト指向だろうと
「野球もサッカーも球技だからおなじようなもの！」いただきましたw
オブジェクト指向は役に立っている。
僕みたいな芸人とか人前に出る人は、多かれ少なかれちょっとした発言や態度がネットで炎上したり、
関数型は「このわかりにくい書き方をすればある問題が絶対発生しない！」だからなぁ…
>>265 ○○は学習コストがーとかわかりにくいってよく聞くけど、仕事でやってる人なら誰でもすぐわかるような（もしくはわかったつもりになれるような）技術だけ使い続けるより安心じゃね？ 覚える価値があるなら特に。
誰でもわかる
誰でもわかる
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、 https://twitter.com/Lyrise_al オブジェクト指向って別に世の中の色んな事を記述するためのものじゃないよねw
手続き型の一部に関数型っぽい書き方するのがカコイイという風潮が強くなってきて
誰でもわかる
関数型言語って狭義のプログラミング言語じゃない気がするよ
言語はJavaでもC#でも良いけど、凡人はデータとロジックは分けて扱う方が良いと思う
名前空間で分けられるOOの方が構造化プログラミングより安全だ
おお、そのとおりだよw
「言われたことをちゃんとこなすように」が正解。
>>276 もしくはクロージャとかfunctorを作りたいときとかだが
c++のクロージャってレキシカルスコープ以外の状態を持つのか？
Objectから派生したものは、メンバ変数とメソッド、つまり状態と処理を持つ
>>283 ポケモンってオブジェクト指向が出て来たら
モンスターは物じゃない
ゲームはオブジェクト指向が適しているだろうが、
>>287 100レス位まで読んだけどクッソどうでもいい事をぎゃーぎゃー言い合ってるだけやんけ
>>287 オブジェクト指向なんて意味ないよな
ネタとしても面白くないなぁｗ
ここからオブジェクト指向を見た事がない人だけがオブジェクト指向を批判出来るスレになります
オブジェクト指向は重複したメソッドが発生する。こういうのは無駄。
>coffee.owner=human
オブジェクト指向
オブジェクト指向が面倒を見なくても
すべては名前
正しくオブジェクト指向を使ったMacOSXは16年間で11回メジャーアップデートし
iOSとかMacのメジャーアップデートって完全に人柱じゃないですかヤダー
最近推し激しいが今のiOSっていいのか？
どうなんだろうか。
>>300 何とも言えんね
オブジェクト指向だから早くリリースしてるんでしょ？ｗ
既存のクラスはなるべくいじらずそのまま静かに置いておく
"クラスとは構造体に操作する関数がついたもの"と
>>310 きみが棲んでるジャンク界隈がそういう仕様なのは知ってるけど
>>312 いちいち()で囲まなくてもよくない？
オブジェクト指向とかクラスが分からないのは多分メモリ周りのことが全然わからないからなんだろうな。
メモリアロケータを自作しないと理解できないってのもなぁ（苦笑）
オブジェクト指向がわからない人は関数型を勉強してないんだろうな
データのカプセル化ができてれば手続き型でもオブジェクト指向でも関数型でもいい気がするが
オブジェクト指向つっても当初の「継承で差分プログラミングうまー」
>>324 >>325 (HP)をプロパティで持った「キャラクター」クラスを作って
実装の再利用は継承でやるよりtraitが便利
Scalaとかの静的型言語がただのmixinをあえてtraitsと呼ぶのは誤解を招くよなぁ…
>>327 そもそもオブジェクトの粒度が高すぎんだよ
> ってこの辺りで便利さがわかると同時に
継承ベースだと
継承を使いこなせないのは要するに馬鹿なんだよ
>>333 「よくバカな奴が"延々と"を"永遠と"って書いてたりするよねー」
>>326 目的に合わせて正しく抽象化出来れば継承関係は自然に導かれるはず
概念の継承関係とコードの継承関係を同じ目線で見ると失敗する
自分のモデリングの間違いを言語機能のせいにする
オブジェクト指向もずいぶん枯れたわけだし、アンチパターンの確認から入るってのも悪くはない。
正しく抽象化できれば正しくできる、
>>328 たとえば魔法使いと魔法という概念が"新たに生まれた"場合
>>348 振る舞いの抽象化なら型クラスやインターフェイスを使えばいいし、実装の再利用ならtraitのような仕組みを使えばいい
モデリングに間違いがなくかつモデルが未来永劫変化しないならID:4cC坊やの言い分は正しいね
とりあえず>>348 で言われてることを具体的にイメージできないぐらい"疎い"ってのだけはわかるよね… お前らのは抽象化でなく、ただのぼんやりしたイメージ
継承にしろオブジェクト指向にしろ
そもそも哺乳類と言うのが最初にあって
>>352 359 名前：デフォルトの名無しさん[sage] 投稿日：2016/07/13(水) 08:17:59.46 ID:+CQztjRc
割とマジで「オブジェクト指向って継承って奴だろ」な人で
原始時代じゃあるまいしそんなプログラマがいるのか？
美少女が人間クラスから継承できない問題は
ぱっと思いつくだけでも
UnkoのサブクラスとしてOhgonクラスを実装するんや！
美少女はウンコをしない
頭の悪い人の悲しいところは
美少年にクラスチェンジすることで破綻せずにハッテン
というか>>211 で書かれてるとおりをまたワンパターンで始めただけだしな。 美少女ウンコ問題は高度すぎて解決の糸口すら見つからないもんな
ちょっとしたネタ書き込みにすら >>372 >>372 解決しとらんのにワンパターンもくそもないだろ
解決できると思ってるのが間違いだと気付くといいよ
なるほど
生成するUnkoオブジェクトのtasteフィールドが最大値になるだけ
>>380 まあなんでも抽象化すればいいってもんではないわな。
君それは細分化やないか
同じ型のインスタンスの振る舞いをポリモーフィズムさせるのは、
>>384 どんな文脈やねんｗ
>>389 計算式が面倒になったら
>>380 >>393 それはどうかわからんよ
Cで書いたコードが速く動くようにCPUやOSが設計されているという面も
おまいさんそれは逆ですぜ。
アセンブラやってた連中が、構造化プログラミングを提唱して、
例えば、hoge+とかやれば自動的にインクリメントしてくれる仕様だって、そういうアセンブラ命令があったからなんだぜ。
>>397 >>399 自信を持って声を大きくして叫び続ければやがてそれが歴史となる
Cの何がすごいって、メモリに対する考え方がシンプルで凄い
>>406 だからCだけが生き残ったんだろ？
生き残ったっていうのは古い言語とくらべての話？
>>410 >>411 >>408 問題は暗黙に行う言語の動きに対してどれだけ
>>407 そして多くの言語が見落としがちな部分でもあったんだよ
別に必ずしも偉い機能を盛り込むのがダメと言っているわけじゃないよ
構造体の先頭メンバ以外のオフセットは規定されていない
構造体のメンバ間のパディングは未規定だけど、オフセットが未規定って言うのは
簡単に入れ替わるさ。
構造体のメンバの順番が入れ替わらないのは仕様で決まっているよ http://portable-c.jugem.jp/?eid=17 intのサイズがアーキ依存だから通信に構造体は使うなってのが常識だけどな。
cはメモリは意識するがレジスタは隠蔽するって落とし所がよかったんじゃない。
Cはパーサが複雑なのとゼロコストで導入できる便利機能が無いのを除けば悪くはない
cの最大の失敗は波カッコ
代入演算子=と比較演算子==だけは許されざるよ。
C言語は特徴ある機能で生き残ることができた。
>>429 Cが生まれた時代はな
Cが生まれた頃にはまだコピー＆ペーストはなかったぞ。
最初のクリップボードはAltoかな
>>430 アセンブラ C Fortran Lisp の古代言語
お前ら、テーマに戻れや。
初期設計を少しでも間違えたり手抜きしたら
>>444 >>41-42 で完全に解説完了 >>440 問題はそういうジョークを本気にする人が多すぎるってことだろうに。
>>446 >>448 くだらん与太話はこれくらいにしてそろそろ全力でウンコ美少女問題に取り組むか
ウンコしない美少女は偶像
なんか、いっつも同じレベルの書き込みするから
ユーザーはうんこなんて機能は求めて無いから削除しろよと
人間がウンコするのは、
ソフトの機能に不要な要素まで組み入れても誰も買わないだろ。
それは当たり前のことではあるな
要件で一言も触れてないのに「はぁ？○○はあって当然だろ」とか言い出す顧客しかいないから
肝心なことを決めずに作り込んでいく。
このスレ的にはgo言語とかD言語のダックタイピングってどうなん？
ダックタイピング
ダッチワイフィング
COBOLからJavaへの移行で「実際に」成功した案件は存在しない
>>468 オブジェクト指向を考え出した人間もオブジェクト指向の解釈を誤っていたのではないか
こう考えると継承のしくみを使ったプログラミングが >>476 な解釈からは必然性が出てこない だいたいプログラミング業界って、
> 継承しかり例外しかり。
結局、人間クラスと美少女クラスは
>>479 javaはオラクルがVMを提供しなくなったら
>>479 >>481 （定義が論理的に妥当でなかったりあいまいだったりするとお議論が紛糾する例
多少コピペが多くなっても継承をむやみに使ってはいけない場面ってのは想定しなきゃなぁ
なんで継承をやめたらコピペが多くなるのかそれがわからんｗ
委譲を使えばいいんだろ。
コーデングテクニックでごまかすのはアカンね
>>487 そうするとインタフェースの定義が必要になってくるから、結局継承が楽だし、よほどのことじゃなければそれで済ませるんだけどね
だから、委譲というか、
ほんと最近、is-a関係、has-a関係っていうの
>>494 その点ha-a関係はやりやすいなぜなら単なる集約であって分類が絡まないから
is-a関係だと思っているものは全てhas-aとしても実装できる。
OO使わない場合に
>>499 is-a だったらliskov置換原則の方が理解し易いし、コード書くときの指針になる。
ちなステータスというのは大概I/Oを通じて外界と繋がっている事物の結果を意味し、
>>494 >>504 is-aかどうかなんて抽象的すぎて判断の材料になんないよな。
>>505 >>507 妻とか女とか、単なる属性をクラスにするからワケが分からなくなる。
口に肛門つけてください。
話についていけない子が
>>505 普通は性別は属性だよなｗ
is-a関係っていうのは必要条件であって十分条件じゃないんだがｗ
オブジェクト指向ってどこで間違ったんだろう
オブジェクト指向が使われてない
>>517 本当にオブジェクト指向が必要だから使っているのか、 継承捨てて委譲を使えっていうのは
>>519 >>513 >>516 今はObjrctive-CじゃなくてSwiftじゃね？
>>521 適切だから使うというなら何故デザインパターンなんて出てきたのか？ JavaはC++よりレガシーな言語になってしまったが…
>>525 いや、デザパタはOOと関係無いから。
>>525 smalltalk だと、人間クラスと美少女クラスの問題は
Squeak Smalltalk だと、こんな感じか？
>>531 シングルトンなんて言語に最初から組み込んでおけ（Scala信者並感）
>>532 >>535 デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。
型が動的だと>>535 の例のようなコードはどうなるの？ そそ
全然違うのだが。デコレータもSmallTalkも理解してないとみた。
なにも知らなくても語れる。
>>540 >>543 いつになったら、
どう解けてるんだよ。
用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。
もうそろそろいいかな？
>>553 Smalltalk の t を大文字で書くやつは無知か知ったかぶり
実は誰も Smalltalk なんて知らない www
言語は関係無いと言う内容の話への反論が、言語名のミスプリントの指摘とか、レベル低過ぎだろw
>>561 >>553 >>538 で「見たいだけ」って言ってるところをみると、これは反語で >>546 みたいに簡潔なのが出てくるとはこの時点では考えてなかったんじゃない？ >>565 そもそもC++でデコレーターでもそんな難しくないでしょｗ
「シングルトン」だけで話が通じる所がデザインパターンの
Smalltalk の最大の魅力は、
>>566 >>546 はデコレータパターンじゃない。 Wikipediaにある
デザパタの目的とされがちであるが
>>579 Smalltalkに意味なんかないよ
Smalltalkは言語だけじゃダメで。
要するに、windows自体がオブジェクト指向に向いてないんだよ。
結論。
それは関係ない
>>574 >>582 シングルトンやアイテレーターなどは時代が変わっても重要だろうけど、
>>583 >>587 > クロージャで実装しているのだから、
デコレータパターンを実装できてはいないんだよｗ
いや、何を実装したのかを聞いたんだが？
>>590 デコレータパターンと同等の機能をクロージャで実装した
>>595 >パターンは機能じゃないよ。設計。
ID:jTAWnEUaを教育してあげる義務は我々には無い
>>599 >>600 http://www.techscore.com/tech/DesignPattern/foundation/foundation1.html/#dp0-2 話をややこしくしているのはあなたです
デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの >>596 で同等の機能を別の設計で実装したんじゃないか、と言い >>597 でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。
やっぱりデザインパターンを
OOPじゃなくてC言語でも当てはまる話だよね。
>>605 デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。
内容を理解してないから例にある記述方法しか受け付けないんだよ。
>>610 >>612 >>612 > だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。
>>619 >>591 は「GoFの（デコレーター）」と明記すべきですよね smalltalkって簡単に色々できるんでしょ？
日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ？
MSがVisual Smalltalkをつくらなかったから
はやく、
>>624 つか、>>546 のruby版って一体何？ >>627 >>628 log = TimeStampLog.new(PidLog.new(Log.new))
>>631 >>546 のruby版はいったいどういう意図なのかが知りたいんだけど。 >>632 >>540 ,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい >>633 >>546 のコードだとそうはいかない。 >>626 >>634 >>546 のコードだとそうはいかない。 http://ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ >>635 >>638 >>639 >>635 デコレータパターンは言語によっていろんな実装が有って
イテレーターパターンをSmalltalkで書いてみたわけね。
イテレータパターンを使わずとも
>>643 >>642 >>647 >>648 Structureは日本語にしたら
>>650 > そこが実質的な定義だと（俺様が）言ってるの。
>>653 この場合、構造、だとしても問題無い件。
デザインパターンなんだから特定の構造を集めたものだからな。
まさかデザインパターンがGoFの23個だけだと？
>>659 Structureは日本語にしたら構造
あるプログラム片の構造がパターンカタログのものと異なっていたら、
>>644 >>664-665 結局オブジェクト志向が理解出来なくて管を巻いていたら
Swiftのプロトコルも何周回目か遅れですよ？
イテレータをアイテレータって書いてる人がいるけど
weblioワロタｗ もっとちゃんとした辞書持って来いよ。
>>669 >669
クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ
クロージャーを使った実装はデコレーターパターン（GoFの）ではないという話なんだが
>>673 Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする
デコレータパターンの機能を持っている設計を
カタログ化の価値を下げようとする連中は居るんだよ
>>677 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
>>680 クラス図レベルがデザインパターン。
おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな？
>>684 >>686 >>689 >>691 そんなアイレテーター君にヒントをもらった>>646 ですが、 http://ideone.com/aMHgqO そもそもbegin, endなどのモロモロが
アメリカ英語なんて
>>695 >>639 ,646）に対して「そもそも～」はどういう反論で、 >>693 >>696 >>695 >>697 もう少し正確に言えば、言語やライブラリが
>>702 >>704 おっすおらフリーダムプログラマ
>>702 >>680 まさしくその通りだね
だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。
>>709 そこまで行ったら別物だって。
>>713 >>714 >>610 ） クラスの無い言語では、クラスの役割りを「カプセル化」パターン、 >>716 「○○言語だともっと簡単に実装できる」君と
>>719 デザインパターン
>>708 その前に君の書き込みを日本語のパターンにしてください
>>681 いい加減、オブジェクト指向 vs 関数型なんていう無意味な議論やめようよ
本当のオブジェクトプログラムは、メッセージ交換だから、関数型が入る余地なんか無いけどな。
お前ら、早く本論に入れ！
美少女はクラスじゃなくて人間クラスのインスタンスで
>>732 >>733 |
オブジェクト指向は愚かな考え。
アヒルががーがーなくのではなく、がーがー鳴けばそれがアヒルなのである
>>738 頬を紅潮させた少女のアナルは今にも決壊寸前のダムの如くヒクヒクと静かに脈打つのであった
やはり、オブジェクト指向は愚かな考えなんでしょうか？
オブジェクト指向にクロージャーが取り入れられてから、
どうせなら理想のクロージャの構文はどんなものか議論しよう。
じゃあ質問
コンビニでトイレだけ借りるのは気まずいので後で何か買って帰る
オブジェクト指向と計算式という対比がまずおかしいスレ
>>757 >>733 できの悪いプログラマはこうやってくだらんことに執着した挙げ句道を外すからな
外に公開するインターフェイスだけオブジェクト指向で中身は手続きとかできないの？
なんでもかんでもOOPしないといけないという強迫観念も新しい病気みたいなもんだ
OOPは自然な概念。
んじゃ、Cでファイル読んで行毎に番号振るプログラムを自然にOOPで書いてくれ。
手続き型の言語使ってるんだからそりゃ書き方は自然に手続き的になるわw
>>765 >>765 後での取り回しのために動作分離してオブジェクトにするんであって
まぁそうだよね。関数型だって関数の中味に手続き書くだろうし
>>771 せやね関数型言語でも中身はモナド駆使して手続き的に書くのが自然やからね
>>767 出力先を切り替えられるようにしたい、は別の要件でしょ
CでOOPしてたやつって、なんかのGUIライブラリでなかったっけか？
オブジェクト指向の方が自然だと思うし好きだけどPythonやjsみたいな動的型付け言語でオブジェクト指向は無理というか無駄な気がしてきた
「世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない…
パイセン方、JS勉強したてでオブジェクト指向って言葉が出てきたばっかでよく分かってないドブネズミ以下の僕に教えて
>>785 Javaをそちらのダメな考え方の方に入れるのはJavaが可哀そう
メソッドはメッセージ側のスタイルなんでなぁ。
オブジェクトはデータに自身を操作するための処理が付いたもの
>>791 >>792 >>790 >>795 例のFILE構造体を用いたファイル操作はファイルシステムに対する低水準な操作がカプセル化され利用者から見えない設計だからオブジェクト指向設計、
>>793 >>798 a={1,2,........100};
>>799 >>800 >>803 C#, Java8 の、Parallel はそう。
>>804 処理が一つの処理(タスク)単位になった時に
>>801 シングルタスクじゃ扱いきれなくて
C++とかハードに直結してるのに使い回しにだけオブジェクト指向を使おうとしたクソを通してオブジェクト指向知った人の末路がこれ
シングルスレッドで同時接続数、1万をこなす、Node.js の、WebSocket
そーゆーのとオブジェクト指向は本質的に関係なくない？
>>806 「あ、お客さま、こちらのおリンゴ少々傷んでおりますので、交換致しますね」
オブジェクト指向は、データと処理をひと纏めにする？
>>816 機能で分けるって言ったら、そら、なんでも機能で分けるもんなんだよ
平たく言えば「機能で分ける」ってのは
ふる～いサブルーチン的な「関数」の発想だと
で、結局クラスやオブジェクトの持つメカニズムについては言及しないのであった
だたし、オブジェクトはデータと処理を一纏めにしたものって説明は
なんかまだ現実を理解していないみたいだけど
俺は別に笑われてないんだけど
>>823 ちな
そこまでわかってるなら、手続き型言語には何があるかも分かってるだろ
データ構造はメモリの空間的分割構造といえるし
>>830 >漏れの無い抽象化が可能
なんか、別なものに見立てての説明ばかり受けたせいで
いや、会社みたいな組織は必要な仕事の流れに応じて組み変わるじゃん？
部署部署言ったって、それはプログラムにおいては、何に相当するのか
変な例え話を出したり、大仰な説明をしたりしないと理解できないだろう、なんて思ってる時点で間違ってると思わないのか
そうだね、自動車は馬なし馬車だから運転者は御者だね。
まだ馬なし馬車とか言ってるのかよ、進歩ないな
「クラスは構造体」じいさんにはぴったりすぎて例えですらないけれど？
仮想の脳内の敵と戦ってるんだな、がんばれよ
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
唯一純粋なオブジェクト指向言語と呼ばれることがあるSmalltalkが
いいとこ取りというよりはその時々で模倣可能な機能が徐々に実用化されてずいぶん近づいている
このスレタイは「この世は飛行機も自動車も不要！北海道から沖縄までは徒歩で十分！」
このスレはC++でオブジェクト指向に挫折したじいさんが
>>852 >>853 >>854 だいたいオブジェクトを命令コードで書くという時点で理論が破綻している
破綻しているは言いすぎかもしれん
序曲を奏でるｗｗｗ
そもそもモジュール間の接続を密にしたら変更の影響がどこまでも波及してシャレにならんから
モジュールの依存性を弱くするのは手続き型でもできる
手続き型プログラミングにおける型に振る舞いをくっつけたことで
未経験から半年でフリーエンジニアになれる人の特徴 VIDEO VIDEO VIDEO VIDEO VIDEO VIDEO VIDEO VIDEO ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
