13/11/11 11:17:03.61
遅いんですよ、オブジェクト指向は。
2:デフォルトの名無しさん
13/11/11 11:36:44.62
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
3:デフォルトの名無しさん
13/11/11 11:57:21.27
俺の場合速いが？
4:デフォルトの名無しさん
13/11/11 12:29:10.02
むしろオブジェクト志向じゃないプログラミングってどこで使われてるの？
5:デフォルトの名無しさん
13/11/11 12:36:19.17
つまらない一発ネタスレもやめてください
6:デフォルトの名無しさん
13/11/11 14:11:21.90
CからC++に移行するときに散々gccの出力アセンブリコード読みまくって特性を検証したけど
ペナルティはせいぜい20～30％程度である、
利便性・保守性が勝るという結論に達して早々に移行したな。
当時は今と違ってCPUの性能もぐんぐん伸びてたしな。
その後ずっとC++は遅いって足踏みしてた連中を鼻で笑ってたわ
これがプログラマとしての能力の差
7:デフォルトの名無しさん
13/11/11 14:14:15.38
JavaScriptなんぞもJITコンパイラの出力アセンブリコード読めば
タコで不安定なコード吐きまくっててC/C++に遠く及ばないのがすぐわかるのに。
その後ずっとWebアプリがネイティブアプリを倒せるってはしゃいでた連中を鼻で笑ってたわ
これがプログラマとしての能力の差
8:デフォルトの名無しさん
13/11/11 14:23:41.60
最近はちょっとアホなコンパイラかな？くらい引き締まったコード吐くよ
オブジェクトとか絡んで複雑なところは流石に比較しづらいから分からんが単純計算の所とかはそう
まあ勿論TypedArrayとかを使わないと太るけどね
9:デフォルトの名無しさん
13/11/11 15:32:26.70
オブジェクト指向のポリモーフィズムつかいまくるようなコードではC++よりもjava7の方が圧倒的に早い。
C++はvirtualが妙に遅い。
>>6 javaに移ることをすすめるよ。
10:デフォルトの名無しさん
13/11/11 15:33:25.56
オブジェクト指向はしっくりこないのでやめてください
11:デフォルトの名無しさん
13/11/11 15:36:09.55
今Javaに移るよりはDartとか始めたほうがよっぽど将来性ありそう
12:デフォルトの名無しさん
13/11/11 15:45:53.31
Objective-Cもいいよ。
パフォーマンスクリティカルな処理はCで書けるし。
ああ、プラットホームが限定されるかw
13:デフォルトの名無しさん
13/11/11 16:33:27.29
>>12
UNIX(Linux, FreeBSD, Solaris, OSX..etc) と
iOS で使えるから十分じゃね？w
14:デフォルトの名無しさん
13/11/11 16:46:48.33
pythonは十分速いから関係ないな
15:デフォルトの名無しさん
13/11/11 16:53:42.30
Pythonはデフォの実行環境だと遅いじゃん
Cythonとか使ったりして頑張ってようやくって感じ
Rubyはこの度のメジャーバージョンアップでデフォのでもマシになったけど
16:デフォルトの名無しさん
13/11/11 19:03:40.52
そうだな やめよう
17:デフォルトの名無しさん
13/11/11 19:09:37.96
PythonもRubyもJavaもSmalltalk(Visual Works)よりおせえもんな。
18:デフォルトの名無しさん
13/11/11 19:11:39.47
C#はやい
19:デフォルトの名無しさん
13/11/11 19:29:17.47
アイちゃんも呆れとったわ
20:デフォルトの名無しさん
13/11/11 19:35:53.53
すいませんでした。
21:デフォルトの名無しさん
13/11/11 20:05:46.39
オブジェクトをブジョクするな
22:デフォルトの名無しさん
13/11/13 01:07:00.72
オブジェクト指向の遅さよりパフォーマンス厨の開発の遅さの方が深刻
23:デフォルトの名無しさん
13/11/13 03:23:41.42
オブジェクト指向にするとボタンを押してから結果が出るまでの時間が
10ミリ秒程伸びてしまいました。
でもユーザーは、体感できる人や文句を言う人はいませんでした。
ちゃんちゃん。
24:デフォルトの名無しさん
13/11/13 09:11:43.17
10ミリ秒も伸びるわけねーだろ
25:デフォルトの名無しさん
13/11/13 09:49:33.47
>>22
まあコストを容認出来る（趣味、最先端分野）場合は実行時間にこだわる意味はあるけどね。
演習や実務では、他にも考えるべき要素が有る。
26:デフォルトの名無しさん
13/11/15 15:09:31.90
実行速度より開発速度
27:デフォルトの名無しさん
13/11/17 19:36:16.35
スクリプト最強
28:デフォルトの名無しさん
13/11/27 23:50:00.12
オブジェクトを使わずにプログラムなんて出来ないだろうに...
29:デフォルトの名無しさん
13/12/07 03:08:39.75
今後の世界はc++かjsかの二極化
30:デフォルトの名無しさん
13/12/07 07:18:51.75
JSと聞いて
31:デフォルトの名無しさん
13/12/08 22:58:05.83
おいキチガイスレ立てたのお前らか
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
ｽﾚﾘﾝｸ(poverty板)
32:デフォルトの名無しさん
13/12/14 12:56:50.66
>>12
プラットホームほ駅
33:デフォルトの名無しさん
13/12/15 03:54:01.10
ところでだ。「チンボがシコシコする」という日本語表現は、文法的に正しいのか？
チンボ「を」シコシコするのではなくて、チンボ「が」シコシコする。この場合、「チンボ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンボが勃起して射精してたとか。
違うか？
「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！
34:デフォルトの名無しさん
13/12/15 10:37:42.66
手がシコシコする
35:デフォルトの名無しさん
13/12/15 12:54:24.52
前立腺ガンの疑いがあるとき、「海綿体がシコシコする」と医師に相談するのでは？
36:デフォルトの名無しさん
13/12/15 12:57:46.12
他動詞的な用法での「シコシコする」が誤り
37:デフォルトの名無しさん
13/12/15 13:02:40.97
日本人以外は帰ってくれないか
38:デフォルトの名無しさん
13/12/15 13:13:34.32
女医にチンボがシコシコすると相談するプレイ
39:デフォルトの名無しさん
13/12/15 13:13:39.45
関係者以外立ち入り禁止
40:デフォルトの名無しさん
13/12/15 14:40:19.60
チョンくせぇ流れだな。
41:デフォルトの名無しさん
13/12/26 11:31:03.05
正直な話、1人で作る個人ユースで使うプログラムで継承だのジェネリックだの
使いどころが全く分からない。無くても困らないだけでなく速い
42:デフォルトの名無しさん
13/12/27 00:09:00.67
作るのが一人かどうかは関係なくて、
プログラムが大きくなったらあると便利。
43:デフォルトの名無しさん
13/12/27 08:15:29.21
Javascriptで、グローバル変数の個数分、関数があったりすると萎える
44:デフォルトの名無しさん
13/12/28 16:02:33.01
>>41
こういうのがチームにいると開発効率が落ちるから困る。
どんなパラダイムだってチューリングマシンと等価なんだから、無くて困らないのは当たり前だろ。
それでも使う理由があるってことなのに。
45:デフォルトの名無しさん
13/12/29 00:51:02.87
まず日本語勉強してこい
46:デフォルトの名無しさん
14/01/02 01:35:17.61
もはや継承は悪手で、委譲が一般化してないか？
47:デフォルトの名無しさん
14/01/02 03:04:41.39
>>46
使うだけだとインタフェースあればほとんど要らんけど
大規模なクラスライブラリの中では重要な役割だと思う
48:デフォルトの名無しさん
14/01/08 07:42:33.21
実装の継承が悪手で、多態を目的とした継承ならむしろOK。
49:デフォルトの名無しさん
14/01/08 14:55:22.88
Go言語は継承無い
50:デフォルトの名無しさん
14/01/08 18:56:33.37
インタフェースで済む
51:デフォルトの名無しさん
14/01/08 21:11:32.92
実はオブジェクト指向ってしっくりこないんです！
52:デフォルトの名無しさん
14/01/08 23:23:46.10
オブジェクト指向などと仰々しい名前がついてるせいさ
と一瞬思ったけど、他に適当な呼び方なんて無いな
しかし、厳格すぎるオブジェクト指向はプログラムの障壁になりえる
その点Golangって丁度良さそうだな
53:デフォルトの名無しさん
14/01/08 23:48:20.78
そうそう、オブジェクト指向なんて名前付けるから変な反発というか、
なかなか理解出来ないなんてことになるんだよ。
個人的には、そのままクラス指向とか、その目的をダイレクトに表した
モジュール化プログラミングと呼んだ方が良かったと思う。
多態というのは結局、同じインターフェースを呼び出しても
その先のモジュールが違えば違う動きするというだけのことを
もったいぶってそう呼んでいるだけだしね。
54:デフォルトの名無しさん
14/01/09 01:01:52.90
客体指向
55:デフォルトの名無しさん
14/01/09 18:59:36.18
オブジェクト指向、ホントにあった怖い話(2004/7/10)から
>…平澤氏は、オブジェクト指向を巡る混乱の要因は、「プログラミング技術」としての
>オブジェクト指向と「汎用の整理術」としてのオブジェクト指向を同一のものとして認
>識しようとする態度にあるとする。
> 例えば、オブジェクト指向の基本解説書や記事では、クラスやポリモーフィズムなど
>…を説明する際に、現実世界をそのままオブジェクト指向という考え方を適用して表現
>しようとする。しかし、「オブジェクト指向と現実世界は大違い」（平澤氏）であり、
>オブジェクト指向を正しく理解するには、まず、プログラミング技術として、構造化プ
>ログラミングの限界を突破した後に登場した新たな技術として理解することが重要であ
>り、主に上流工程における汎用の整理術として応用されるオブジェクト指向とはまった
>くの別物としてとらえることが必要だと力説した。
56:デフォルトの名無しさん
14/01/09 19:49:20.26
汎用の整理術とすらでもなくて、
モロにプログラミング技術として
「現実世界をそのままコードに落とせる」←？
というのを最大にして唯一のOOPのメリットだと言い張る人は過去にみたことある。
57:デフォルトの名無しさん
14/01/10 00:49:34.49
>>>55
>オブジェクト指向と現実世界は大違い
そうなんだ
俺は今でもオブジェクト指向は、テレビとリモコンの関係だと思ってるけどw
58:デフォルトの名無しさん
14/01/10 04:54:20.47
「リモコン」という概念を定義できるのがオブジェクト指向。
構造化手法だといちいちテレビ側のボタンを押しに行かないといけない。
59:デフォルトの名無しさん
14/01/11 00:36:43.02
a.Run();
と
Run(a);
って、単に構文が違うだけだよね？
a.Run()という書き方をするのがオブジェクト指向というなら、
C++は、ユーザに見えないところで、a.Run()をRun(a)に置き換えてるよね？
じゃあ、C++はオブジェクト指向を装っているだけであって、オブジェクト指向じゃないんだ。
と言われたらどうする？
60:デフォルトの名無しさん
14/01/11 02:56:50.52
>>59
その2つだと責任者が違うよね。
前者はa側にRunの処理内容を封じ込められるから、Runしたい側はaの内容が正しいことを保証せずに済む。
そもそもオブジェクト指向って実際にコンパイラがどう解釈するかというよりどうやってコーディングできるか、ってとこに主眼が置かれるわけだが。
パッと見オブジェクト指向に見えればそれは立派なオブジェクト指向だよ。
61:デフォルトの名無しさん
14/01/11 03:00:21.83
見た目の問題でもないけどな。
C言語でもオブジェクト志向出来るわけだし
その内のいくつかは何となくやってた人も多い。
ソケットとか、ファイル辺りの関数はよくOO的と言われるし。
データや処理などの主体をどう切り分けるか、が最大の肝だと思う。
62:デフォルトの名無しさん
14/01/11 05:36:50.49
>>61
データや処理の主体の切り分け方こそ完全に見た目だけの問題だろ。
63:デフォルトの名無しさん
14/01/11 10:34:22.33
結局、オブジェクト指向は何のためにするの？しないといけないの？
というのが、よくある入門者の疑問で。入門者に限らないけど。
例えば、構造体を定義して、それにアクセスする関数を定義して、
必ずその関数を使わないといけないという運用にすれば、
後は見た目だけ書き方だけの問題だよね？
そして、これって、C言語とかの構造化プログラミングで普通にやっていることだから、
じゃあ、オブジェクト指向って何なの？構造化プログラミングと何が違うの？
テレビ構造体、リモコン構造体を定義して、それで"オブジェクト"設計すればいいだけだし、
関数の呼び出し構文が違うだけだよね。
64:デフォルトの名無しさん
14/01/11 12:23:52.57
そもそもC++やC#のサポートするOOPはなんちゃってOOPなはずだが。
真祖smalltalk様と渡り合えると思ったのか。
65:デフォルトの名無しさん
14/01/11 12:37:06.44
原理主義者は頭が固くて
場を荒らす事しかしないという印象がある
66:デフォルトの名無しさん
14/01/11 12:48:24.23
>>63
＞例えば、構造体を定義して、それにアクセスする関数を定義して、
＞必ずその関数を使わないといけないという運用にすれば、
実はC言語でのオブジェクト志向の、カプセル化のやり方がそれだったりする。
公開ヘッダには構造体は前方宣言しかなく関数実装だけ。
なのでポインタを関数に渡すしか参照方法がなくなる。
まあ、継承のときにはもうひとつヘッダ作るから、そっち使われると参照されてしまうが…
＞そして、これって、C言語とかの構造化プログラミングで普通にやっていることだから、
実は構造体プログラミングだけならば、それは普通ではないんよ。
構造体を使わず、もしくは使っても処理との結び付きが弱い。
でも自然と、普通にみんなやっている。構造体と処理とを結び付けている。
それをOOPと意識せずともね。
要するに特別なことではなく、割と自然な考え方に名前付けただけよ。
そこに多態性(C++ならオーバーロードでも可能だし、C言語でも関数ポインタなどで可能だった)や
継承(ちと面倒だけどこれも可能)っていう、更に発展したやり方を持ち込んだだけ。
67:デフォルトの名無しさん
14/01/11 16:04:54.98
そう。
C++という名前が表しているように、上の平澤氏の話のように、
構造化プログラミングの限界により、"運用"でカバーしなければならず、
不便だったことを改善した仕様にオブジェクト指向という固有名詞を付けただけなんだよ。
例えば、特に複数で開発するような場合、
変数を勝手な理解で自前のコードで扱う処理を書いてバグったり後の仕様変更に支障をきたしたりする対策で、
扱う関数を決めて勝手なことをしないように"運用"する必要が有ったのを、
クラスという仕組みでコンパイラが監視するようにしたり。
状態に対するイベント処理を、関数ポインタで処理を切り替える設計で、
関数１つ１つを確実に、後で仕様変更追加したものも漏れなく対応しなければならない"運用"を
ベースクラスでインターフェースを定義して継承し、オブジェクトのポインタ１つを差し替えるだけの
簡単なものにしたり。
モジュール設計で、同じインターフェースのモジュールを差し替えることで、
Ａのモジュールでは「ワン」と鳴いていたのがBのモジュールで「ニャン」と鳴く
仕組みを"運用"していたのを（以下略
「オブジェクト指向」って、モジュール設計なんだよ。そのモジュールの動きがまるで「オブジェクト」みたいだ、
ということで「オブジェク指向」なんてどっかのバカが付けたせいで、逆に初心者が分からなくなってるんだよ。
68:デフォルトの名無しさん
14/01/11 16:08:30.02
で、オブジェクト指向のメリットって一言で言うと何？
69:デフォルトの名無しさん
14/01/11 16:41:30.95
開発速度とメンテナンス性が良い
70:デフォルトの名無しさん
14/01/11 16:51:27.24
>>67
>「オブジェクト指向」って、モジュール設計なんだよ。そのモジュールの動きがまるで「オブジェクト」みたいだ、
>ということで「オブジェク指向」なんてどっかのバカが付けたせいで、逆に初心者が分からなくなってるんだよ。
モジュール設計はオブジェクト指向の持つ特徴の一つであって、
決してモジュール設計とオブジェクト指向は同一であると見なすべきではない
たとえばC(手続き型)からC++(オブジェクト指向)の流れであれば、
Cでの様々なコード設計手法に対して、定まった「制約」を加えたものがC++だ
ここで、制約という言葉は否定的なニュアンスがあるので、巷では
「枠」という言葉のハイカラな表現である「フレームワーク」が好まれるらしい
いいかえると、「C(手続き型)を定まった枠で縛りつけたものがC++(オブジェクト指向)」である
そして最近では、自ら喜んで縛られて快感を追い求めるマゾ気質の若者が増殖中
まとめると、こういった縛りプレイ(？)を総称してオブジェクト指向と名前を付けた人はバカではないし、
名前を付けたことが初心者を困惑させる要因になっている訳でもない
あるフレームワークをマスターすることが難しいのと同様に、オブジェクト指向とは
本質的に難しいものであり、それを分かっていない人達が混乱を巻き散らしていると考える
71:70
14/01/11 18:12:36.87
>>68
設計をオブジェクト指向という一つの「枠組み」でとらえることができる、こと
ここで設計とは、従来の手続き型設計手法における：
機能設計/構造設計/詳細設計(コード設計)
に対応する
オブジェクト指向は本格的な開発プロジェクトにとって
有益であるのはもちろんのこと、個人のプログラミングにも役に立つ
たとえば、何か作りたいモノ(=主題、要求仕様)があったと仮定すると、
それを分析して「適切なオブジェクト指向モデルを設計」できれば、
そのモデルを直接的にオブジェクト指向言語のコード設計に反映できる
これにより、モノ作り(いわゆるソフトウェア開発)の効率化が図れる
ここで注意すべきは、「モノ(=主題、要求仕様)」は現実世界に存在する概念であり、
「多くの概念モデルは、オブジェクト指向モデルでは表現できない」点である
オブジェクト指向の教科書で取り上げられるような単純なモノであれば、
その概念モデルをオブジェクト指向モデルで表現できることは多いが、
現実世界にある大半の複雑なシステムには当てはまらない
これがオブジェクト指向分析/設計(OOA/OOD)の本質的な難しさである
そして、オブジェクト指向プログラミング(OOP)を理解しただけで
オブジェクト指向(OO)のすべてを分かった気になっていた平澤氏(>>55)が、
現実世界の開発現場でプロジェクトに混乱を巻き散らしていた張本人であったのは
言うまでもないことだ
72:デフォルトの名無しさん
14/01/11 18:28:31.89
>>68
有益だけど面倒だったことが誰でも簡単に出来るようになった
73:デフォルトの名無しさん
14/01/11 18:28:53.27
>>69
レストン！
>>71
失礼、ちょっと大げさになりすぎた。
もっと限定して、本当に聞きたかったことはこう。
非OOPと比較してOOPのメリットは？
俺は、結局んところモジュール性の上乗せだと思う。
ただしこれは想像であって、クラスという単位で名前つけたり、
インスタンスを複数の抽象レベルで扱えたりすることが、
非OOPで出来るのかどうか不勉強で知らない、
仮に出来ないとしたら、出来るOOPのほうがその分オイシイ、の発想。
74:デフォルトの名無しさん
14/01/11 18:30:59.87
>>72
レストン！
まぁよく聞く「CでもOOP出来る！」発言はじゃあオマエがそれをやってみろ、
実用としてそれでラクをしてみろ、という気分になっちゃうね。
まあこういうと単にOOPLへの感謝にすぎないが。
75:70
14/01/11 18:54:24.49
>>73
>クラスという単位で名前つけたり、
>インスタンスを複数の抽象レベルで扱えたりすることが、
>非OOPで出来るのかどうか
クラス(class)とは「型(type)」いわゆるデータ型であり、
インスタンス(instance)とは「値(value)」である、と想定してみよう
もしこれが正しければ、型と値を表現できる非OOP言語であっても、
「型という単位で名前つけたり、値を複数の抽象レベルで扱えたり」
することはできる、と言える
クラスと(一般の)型との違いは、クラスが各クラス間に「継承」という
階層関係を持てるのに対して、(一般の)型は階層関係を持てない点にある
ただし、ここまではC言語によるOOP技法のように非OOPでも実現できる
そして非OOP言語の世界には「型とは値である」という発想がある
つまりデータ型を(値として)実行時に定義したり生成できるパラダイムであるが、
実験的な言語はいくつか提案されてきたけれど、どれ一つとして普及には成功しなかった
この「型とは値である」という発想をOOPの世界で言い換えたものが
「リフレクション(メタプログラミング)」になる
そしてリフレクションは Ruby on Rails の成功等で実用化が一般にも知られるようになり、
現実のOO設計技法として普及に成功した
つまり「OOPで出来て非OOPでは出来ない」のはリフレクションである
76:デフォルトの名無しさん
14/01/11 19:08:45.37
コンピュータの歴史を辿れば分かりやすいかな。といっても実際の歴史は知らんので想像ｗ
最初は機械語レベルで十分だったけど、規模が大きくなってくるとやってられなくなるので、
ある程度の一連の機械語をまとめて１つの抽象的な命令に置き換える高級言語が生まれた。
そしてさらに規模が大きくなってくると長大なソースコードにやってられなくなったので、
一連のコードを抽象化して擬似的に１つの命令化、すなわち関数化する、構造化言語が生まれた。
そしてさらに規模が大きくなって大量の関数にやってられなくなったので、
関連の強い関数群とか、データとその処理をグループ化して１つの単位にするオブジェクト指向言語生まれた。
そしてさらに規模が大きくなると？？？？
サービス指向とかかな？？
77:デフォルトの名無しさん
14/01/11 19:08:46.23
まさかそんなところに着地する話とは思いもよらなかったｗ
結論については消化できてないのでひとまず言及は避けておく。
> ここまではC言語によるOOP技法のように非OOPでも実現できる
ここらに一回、慎重に線引きをしてみたいもんだが、
非OOPLでOOPできる場合、そのメリットはOOPのものなのか？
それとも、非OOPLのものなのか？
手柄はOOPにあるのか非OOPLにあるのか。
この領域に入った議論はいっつもモヤッとしてるのを感じる。
非OOPLで、非OOPをして、それが、
OOPのメリットに迫るか上回るかの例をいつも見たいと思っている。
78:デフォルトの名無しさん
14/01/11 19:16:33.98
OOP言語で作っても実行されるのは機械語だよ。だから機械語でもOOPは出来るｗ
構造化言語は、構造化を簡単に出来るようにした
オブジェクト指向言語は、オブジェクト指向を簡単に出来るようにした
だけ。
79:デフォルトの名無しさん
14/01/11 19:17:57.98
>>78
その考えのほうがスパッと行ってるな。
どうも俺余計なこと考えちゃってたみたい。
80:デフォルトの名無しさん
14/01/11 21:48:39.30
オブジェクト指向って１つ１つのオブジェクトの作成でその力を使いきっていて、
オブジェクトをどのようにつなげていくかに関しては無能っぷりを撒き散らしている。
デザインパターンのグダグダっぷりを見ていると痛々しい。
81:デフォルトの名無しさん
14/01/12 04:06:08.19
>>80
忘れがちではあるけど、実はデザインパターンを構造型で作るとオブジェクト指向より更に胡乱でメンテナンスの難しい糞コードが生まれる。
グダグダに見えてあれが一番便利でコンパクトだったりするんだよ。
それに、一つの機能の使い方だけで性格の全く違う有用なものが最低23個も生まれるって考えると、
つなげ方には自由度と一貫性が両立されてるわけで、むしろ美しいとは思わないか？ 俺は思わないけど。
82:デフォルトの名無しさん
14/01/12 19:12:18.26
>>71 面白い書き込みをありがとう。オブジェクト指向はわからんなぁと思っ
ていたが、経験的に身に着けられるような、テクニックやハッキング技術と
は違うということがわかった。
書きぶりを見るに、オブジェクト指向「設計」はきちんとした
計算機科学専攻の大学院レベルのトレーニングを経ないと習得できないもの
なのだろう。そのような教育を修めた技術者が基底クラスの設計とコーディング
ルールを決めたう上で、開発をするのがあるべき姿なのだろう。
83:デフォルトの名無しさん
14/01/12 21:19:56.49
なるほど。こういう人が設計するべきだね。
URLﾘﾝｸ(el.jibun.atmarkit.co.jp)
84:デフォルトの名無しさん
14/01/12 22:11:16.30
正直業務アプリのフレームワークなんて決まりきっててすでに用意されてるしな
日付だの画面部品だのは基本的なものはもう標準ライブラリに入ってるし
パンピーがオブジェクト指向でなに設計するん？
85:デフォルトの名無しさん
14/01/12 23:28:17.13
標準ライブラリやフレームワークで足りないものを実装するとき。
基本的な関数はともかく、画面部品はだいたい使えるが、
ちょっとだけ機能をつけ加えたいってことはよくある。
その時、だいたい部品は拡張可能になっているが、
それを拡張するときはオブジェクト指向の知識が必要になる。
86:デフォルトの名無しさん
14/01/13 00:38:58.51
それっぽい言葉だけは出揃っているんだけど実装がことごとくダサダサなのが地球のオブジェクト指向☆
87:デフォルトの名無しさん
14/01/13 00:46:14.36
>>84
パンピーならゲームじゃね？
ゲームはオブジェクト指向と親和性高いからオブジェクト指向の独壇場みたいなところあるし。
88:デフォルトの名無しさん
14/01/13 02:50:15.91
>>85
単に抽象クラスにコード実装するだけだろそれ
その程度ならVBでポトペタしたボタンをダブルクリックするのと何もかわらん
本当に何かFWが提供している以上のことをやろうと思うとどのような思想で
抽象化されているかまで理解しなければならないのがooの最大クラスの欠点
89:デフォルトの名無しさん
14/01/13 03:08:57.42
抽象クラスって言ってる時点で
オブジェクト指向の知識が必要になってるじゃねーかｗ
90:デフォルトの名無しさん
14/01/13 11:48:20.38
C++使うから、訳が分からなくなるんだよ
VBScriptでオブジェクト指向してみると分かりやすくなるさ
91:デフォルトの名無しさん
14/01/13 14:48:48.64
言語にこだわるのは無能
本質は変わらない
92:デフォルトの名無しさん
14/01/13 14:50:56.00
じゃあすべてマシン語で書け。
93:デフォルトの名無しさん
14/01/13 15:29:04.85
あれだろ仕様書の日本語やカタカナ英語にこだわっている人。
さもなくば肩書きとか名誉とか貯金とか、
結局人間は無意識に何かに拘ってるんだよ。
94:デフォルトの名無しさん
14/01/13 16:38:59.80
>>91
PrologとHaskellとRuby勉強した後に同じ事を言えればいいが
95:デフォルトの名無しさん
14/01/13 17:53:20.40
Rubyなんかパチもんは外して代わりにSmalltalkとLISPを、あとAPLを入れたいね
96:デフォルトの名無しさん
14/01/13 21:55:09.22
「言語なんて全部一緒」って言ってる人
関数型言語を意図的に無視しているから嫌い
97:デフォルトの名無しさん
14/01/13 22:00:25.74
じゃあ、言語なんて二種類しかないでいい？
っていうか、今は関数型言語の機能が
オブジェクト指向な言語に取り入れられて来ているからねぇ。
オブジェクト指向言語が純粋ではない関数型言語に近くなってるよ。
だから全部一緒っていうのもあながち間違いじゃない。
98:デフォルトの名無しさん
14/01/13 22:16:10.65
いやー、全然近くなってないよ
99:デフォルトの名無しさん
14/01/13 22:20:58.17
近いよ。もう関数型言語特有のものっていうのは
少なくなってるでしょ？
ここに関数型言語特有のものを書いてみ
ほんの数個出るだろうけど、それ以外は
もう関数型言語じゃなくても良くなってる。
100:デフォルトの名無しさん
14/01/13 22:41:41.90
カレーか
101:デフォルトの名無しさん
14/01/13 23:11:06.46
つりだろ。
102:デフォルトの名無しさん
14/01/13 23:17:36.90
最終は機械語
103:デフォルトの名無しさん
14/01/13 23:20:52.45
機械語といっても、必ずしも手続き型とは限らない
104:デフォルトの名無しさん
14/01/13 23:42:14.64
>>100
カリー化ね
URLﾘﾝｸ(yuroyoro.hatenablog.com)
> Rubyでは、1.9からProc#curryがサポートされてカリー化できるようになった。
言語構文でネイティブにサポートされてないってだけで
カリー化をする関数は作れる。
105:デフォルトの名無しさん
14/01/14 00:02:07.60
>>102
ネットの機械語はjavascript
106:デフォルトの名無しさん
14/01/14 01:31:22.59
言語なんて全部一緒なんじゃなく、全部載せの言語があるだけじゃないか？
逆だと思う。
107:デフォルトの名無しさん
14/01/14 02:11:13.68
ノコギリなんてみんな一緒って言うのとおなじくらいナンセンス。
関数型と手続き型では日本の引きノコ、海外の押しノコくらいの違いがあり、
じゃあ両方いっぺんにてんで歯の左右に角度の違う歯を配置したりするノコもある。
108:デフォルトの名無しさん
14/01/14 02:12:04.12
>>99
再代入禁止とか
109:デフォルトの名無しさん
14/01/14 02:23:41.46
鋸の由来ってJSON（ジェイソン）に対する言葉遊びかな?
110:デフォルトの名無しさん
14/01/14 02:27:55.97
>>96
（俺らがいくら関数型を使ったところで、プログラミングセンスが開花するわけじゃないんだから）
言語なんて、どれも一緒
111:デフォルトの名無しさん
14/01/14 03:54:30.40
楽器に例えると？
JavaとJavaScriptは
アコギとエレキくらい違う。
SQLとRubyは
ベースとエレキくらい違う。
112:デフォルトの名無しさん
14/01/14 07:40:50.30
代数的データ型とパターンマッチがOOPLにも欲しい
これ有る無しでプログラミングスタイルから変わってくる
113:デフォルトの名無しさん
14/01/14 16:02:42.70
>>109
そーだよ
114:デフォルトの名無しさん
14/01/15 20:45:23.41
会社の先輩が全く理解してくれない。
その人が作るプログラムはうまく動くには動くんだけど、いろんなスタイルが混在してて、
なるべくきれいなオブジェクト指向的設計にした方がいいですよ、といって説明してるんだけど。
「おまえの言うことくらい全部知ってる。だが全く実証的じゃない」って。
オブジェクト指向の利点を「実証的に」説明しろって言われてもなあ。
115:デフォルトの名無しさん
14/01/15 21:04:37.18
>>114
別に無理してオブジェクト指向することないよ
116:デフォルトの名無しさん
14/01/15 21:11:50.60
インタフェースを最初から決めとかないと後で困るだろ
117:デフォルトの名無しさん
14/01/15 21:19:08.48
>>115,116
だけど全然認めてくれないってのもくやしいよ？
俺の説明が悪いのかと思って、いろんな本やサイトの解説漁ってメリットを語っても
「そんなハウツーレベルのメリットを追求してるからダメなんだ！」と一喝。。。
頭脳じゃ全くかなわない。理学博士だし・・・
118:デフォルトの名無しさん
14/01/15 21:38:37.45
どんなに仕事を丁寧に丁寧にやったとしても、
１個問題が起きればその苦労が報われないことだってあるんだし、
理想ばっか追い求めないで、そこそこの結果を求めた方がいいと俺は思う。
てか、オブジェクト指向って何だ？
拡張性を残して再利用できるように、機能を最小にしてスマートにすること？
そのまま再利用できるように、機能を最大持たせること？
119:デフォルトの名無しさん
14/01/15 21:48:45.60
>>118
ダーティーなプログラムを、周囲に何の影響も与えることなく利用できるようにすること
120:デフォルトの名無しさん
14/01/15 21:50:33.91
やっぱり追求すべきは、まずはモジュール性だよ。
直行性あって再利用されがちな単位をみつけだして、
インタフェースを小さくよく考えて決めて、実装隠す。
モジュール性がより備わってるとき、それはやっぱり簡潔で柔軟だと思う。
OOPか否かに拘り続けるのもまたおかしい。
121:デフォルトの名無しさん
14/01/15 22:03:13.31
ファクトリー的なことにOOPを用いようとすると、
色んな処理が重なるの部品を受け取って、
組み上げる時にスコープが利かなかったりする。
ここらへんの想像が難しい
122:デフォルトの名無しさん
14/01/15 22:03:40.99
>>118
> てか、オブジェクト指向って何だ？
問題の分割のしかたの一形態です。
データ指向らしい分割のしかた
手続き指向らしい分割のしかた
オブジェクト指向らしい分割のしかた
信じる信じないはあなたの自由です
123:デフォルトの名無しさん
14/01/15 22:19:12.66
たとえば構造化プログラミングの段階ひとつとっても、
うまいひとが書いたのと下手な人が書いたのって結構差がある。
そのことについて語られない代わりに、OOPのメリットとやらが先行して語られてる気がする。
124:デフォルトの名無しさん
14/01/15 22:29:46.62
原理主義ってうざいし根拠ないよね。
オブジェクト指向の度合いがより純粋であれば、イコールより良いものなんだ・・・って、
誰かの言葉じゃないけど、実証的に確かめられてるモノんだろうか？
125:デフォルトの名無しさん
14/01/15 22:32:08.25
>>122
もし分割の仕方で～指向っていうのが決まるんだったら、複数の分割のやり方が混在していると良くないってことになるよね？
126:デフォルトの名無しさん
14/01/15 23:07:55.64
周りが理解しやすいようにOOPやGOFのデザパタを取り入れるんじゃないのか
127:デフォルトの名無しさん
14/01/15 23:12:24.34
>>125
「良くない」
ずいぶん抽象的な捉え方ですね。
もっと実証的に言ってください！
128:デフォルトの名無しさん
14/01/15 23:26:21.24
>>125
ならないよ。
データ指向30%
手続き指向30%
オブジェクト指向30%
その他10%
ってなるだけさ。
それでうまくいくことは十分ある。
129:デフォルトの名無しさん
14/01/15 23:37:40.58
オブジェクト指向でパッケージされたデータ構造を手続き型で処理するなんて普通にある話。
130:デフォルトの名無しさん
14/01/16 01:42:08.82
>>114
要はその人に「自分の知ってる文法だけで書いてください」って言ってるだけだろ？
それは単なる甘え。
その人は純粋なオブジェクト指向や他のパラダイムを一通り勉強して、その上で一番生産性の高い方法を選んでるだけ。
多分、その人は純粋なオブジェクト指向で書こうと思えば書けるんじゃないのか？
それをあえて使わない理由、メリットを聞いてみるべきだと思うよ。
そのメリットに納得したら、お前の方が先輩のやり方を学べばいい。
131:デフォルトの名無しさん
14/01/16 02:38:22.63
粗結合を実現しようと思ったら副作用は極力避けるべき
なのに、オブジェクト指向は副作用を避ける仕組みは提供しないっていうか
むしろ副作用推奨だからウンコ
132:デフォルトの名無しさん
14/01/16 02:54:56.23
小クラス主義、大クラス主義とかいうヤツだっけ？
小クラス主義が書いたコードは何かの信念を貫き過ぎてると思う
133:デフォルトの名無しさん
14/01/16 03:09:25.89
疎結合なら知っているけど粗結合ってなんだろう。
134:デフォルトの名無しさん
14/01/16 03:27:30.69
>>131
そのためのカプセル化だろ。
関数単位ではなくオブジェクト単位での副作用禁止を推奨してるだけ。根っこは同じ。
ダダ漏れの副作用はオブジェクト指向でも推奨されてないよ。
135:デフォルトの名無しさん
14/01/16 03:49:30.24
オブジェクト単位での副作用禁止ってなんだよアホか？
オブジェクトの状態を一切変化させないのか？
136:デフォルトの名無しさん
14/01/16 04:06:32.24
>>135
オブジェクト内の変数とオブジェクト外の変数を別物として扱ってるだけだよ。そのためのアクセス修飾子。
オブジェクト指向において適切にカプセル化がなされていれば、コンストラクタに同じものを与えて、同じ回数、同じ引数で呼び出した時に返ってくる値が変わらないことは保証されてるだろ？
最終的に参照透過性の理念の要求は満たすことになる。
137:デフォルトの名無しさん
14/01/16 04:18:31.57
ゴミｗｗｗｗｗｗｗｗｗｗｗ
138:デフォルトの名無しさん
14/01/16 04:23:01.20
どの言語のオブジェクト指向なんだろうか、少なくともjavaやC++のオブジェクト指向で副作用とか考慮されてないし
考えるのはキチガイ。