トップページ⇒tech
985コメント417KB

オブジェクト指向なんて今すぐやめてください

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2013/11/11(月) 11:17:03.61
遅いんですよ、オブジェクト指向は。
0002デフォルトの名無しさん2013/11/11(月) 11:36:44.62
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0003デフォルトの名無しさん2013/11/11(月) 11:57:21.27
俺の場合速いが？
0004デフォルトの名無しさん2013/11/11(月) 12:29:10.02
むしろオブジェクト志向じゃないプログラミングってどこで使われてるの？
0005デフォルトの名無しさん2013/11/11(月) 12:36:19.17
つまらない一発ネタスレもやめてください
0006デフォルトの名無しさん2013/11/11(月) 14:11:21.90
CからC++に移行するときに散々gccの出力アセンブリコード読みまくって特性を検証したけど
ペナルティはせいぜい20〜30％程度である、
利便性・保守性が勝るという結論に達して早々に移行したな。
当時は今と違ってCPUの性能もぐんぐん伸びてたしな。

その後ずっとC++は遅いって足踏みしてた連中を鼻で笑ってたわ
これがプログラマとしての能力の差
0007デフォルトの名無しさん2013/11/11(月) 14:14:15.38
JavaScriptなんぞもJITコンパイラの出力アセンブリコード読めば
タコで不安定なコード吐きまくっててC/C++に遠く及ばないのがすぐわかるのに。

その後ずっとWebアプリがネイティブアプリを倒せるってはしゃいでた連中を鼻で笑ってたわ
これがプログラマとしての能力の差
0008デフォルトの名無しさん2013/11/11(月) 14:23:41.60
最近はちょっとアホなコンパイラかな？くらい引き締まったコード吐くよ
オブジェクトとか絡んで複雑なところは流石に比較しづらいから分からんが単純計算の所とかはそう
まあ勿論TypedArrayとかを使わないと太るけどね
0009デフォルトの名無しさん2013/11/11(月) 15:32:26.70
オブジェクト指向のポリモーフィズムつかいまくるようなコードではC++よりもjava7の方が圧倒的に早い。
C++はvirtualが妙に遅い。
>>6 javaに移ることをすすめるよ。
0010デフォルトの名無しさん2013/11/11(月) 15:33:25.56
オブジェクト指向はしっくりこないのでやめてください
0011デフォルトの名無しさん2013/11/11(月) 15:36:09.55
今Javaに移るよりはDartとか始めたほうがよっぽど将来性ありそう
0012デフォルトの名無しさん2013/11/11(月) 15:45:53.31
Objective-Cもいいよ。
パフォーマンスクリティカルな処理はCで書けるし。
ああ、プラットホームが限定されるかw
0013デフォルトの名無しさん2013/11/11(月) 16:33:27.29
>>12
UNIX(Linux, FreeBSD, Solaris, OSX..etc) と
iOS で使えるから十分じゃね？w
0014デフォルトの名無しさん2013/11/11(月) 16:46:48.33
pythonは十分速いから関係ないな
0015デフォルトの名無しさん2013/11/11(月) 16:53:42.30
Pythonはデフォの実行環境だと遅いじゃん
Cythonとか使ったりして頑張ってようやくって感じ
Rubyはこの度のメジャーバージョンアップでデフォのでもマシになったけど
0016デフォルトの名無しさん2013/11/11(月) 19:03:40.52
そうだな　やめよう
0017デフォルトの名無しさん2013/11/11(月) 19:09:37.96
PythonもRubyもJavaもSmalltalk(Visual Works)よりおせえもんな。
0018デフォルトの名無しさん2013/11/11(月) 19:11:39.47
C#はやい
0019デフォルトの名無しさん2013/11/11(月) 19:29:17.47
アイちゃんも呆れとったわ
0020デフォルトの名無しさん2013/11/11(月) 19:35:53.53
すいませんでした。
0021デフォルトの名無しさん2013/11/11(月) 20:05:46.39
オブジェクトをブジョクするな
0022デフォルトの名無しさん2013/11/13(水) 01:07:00.72
オブジェクト指向の遅さよりパフォーマンス厨の開発の遅さの方が深刻
0023デフォルトの名無しさん2013/11/13(水) 03:23:41.42
オブジェクト指向にするとボタンを押してから結果が出るまでの時間が
10ミリ秒程伸びてしまいました。
でもユーザーは、体感できる人や文句を言う人はいませんでした。

ちゃんちゃん。
0024デフォルトの名無しさん2013/11/13(水) 09:11:43.17
10ミリ秒も伸びるわけねーだろ
0025デフォルトの名無しさん2013/11/13(水) 09:49:33.47
>>22
まあコストを容認出来る（趣味、最先端分野）場合は実行時間にこだわる意味はあるけどね。
演習や実務では、他にも考えるべき要素が有る。
0026デフォルトの名無しさん2013/11/15(金) 15:09:31.90
実行速度より開発速度
0027デフォルトの名無しさん2013/11/17(日) 19:36:16.35
スクリプト最強
0028デフォルトの名無しさん2013/11/27(水) 23:50:00.12
オブジェクトを使わずにプログラムなんて出来ないだろうに...
0029デフォルトの名無しさん2013/12/07(土) 03:08:39.75
今後の世界はc++かjsかの二極化
0030デフォルトの名無しさん2013/12/07(土) 07:18:51.75
JSと聞いて
0031デフォルトの名無しさん2013/12/08(日) 22:58:05.83
おいキチガイスレ立てたのお前らか

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://engawa.2ch.net/test/read.cgi/poverty/1386476617/
0032デフォルトの名無しさん2013/12/14(土) 12:56:50.66
>>12
プラットホームほ駅
0033デフォルトの名無しさん2013/12/15(日) 03:54:01.10
ところでだ。「チンボがシコシコする」という日本語表現は、文法的に正しいのか？

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

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

違うか？

「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！
0034デフォルトの名無しさん2013/12/15(日) 10:37:42.66
手がシコシコする
0035デフォルトの名無しさん2013/12/15(日) 12:54:24.52
前立腺ガンの疑いがあるとき、「海綿体がシコシコする」と医師に相談するのでは？
0036デフォルトの名無しさん2013/12/15(日) 12:57:46.12
他動詞的な用法での「シコシコする」が誤り
0037デフォルトの名無しさん2013/12/15(日) 13:02:40.97
日本人以外は帰ってくれないか
0038デフォルトの名無しさん2013/12/15(日) 13:13:34.32
女医にチンボがシコシコすると相談するプレイ
0039デフォルトの名無しさん2013/12/15(日) 13:13:39.45
関係者以外立ち入り禁止
0040デフォルトの名無しさん2013/12/15(日) 14:40:19.60
チョンくせぇ流れだな。
0041デフォルトの名無しさん2013/12/26(木) 11:31:03.05
正直な話、1人で作る個人ユースで使うプログラムで継承だのジェネリックだの
使いどころが全く分からない。無くても困らないだけでなく速い
0042デフォルトの名無しさん2013/12/27(金) 00:09:00.67
作るのが一人かどうかは関係なくて、
プログラムが大きくなったらあると便利。
0043デフォルトの名無しさん2013/12/27(金) 08:15:29.21
Javascriptで、グローバル変数の個数分、関数があったりすると萎える
0044デフォルトの名無しさん2013/12/28(土) 16:02:33.01
>>41
こういうのがチームにいると開発効率が落ちるから困る。
どんなパラダイムだってチューリングマシンと等価なんだから、無くて困らないのは当たり前だろ。
それでも使う理由があるってことなのに。
0045デフォルトの名無しさん2013/12/29(日) 00:51:02.87
まず日本語勉強してこい
0046デフォルトの名無しさん2014/01/02(木) 01:35:17.61
もはや継承は悪手で、委譲が一般化してないか？
0047デフォルトの名無しさん2014/01/02(木) 03:04:41.39
>>46
使うだけだとインタフェースあればほとんど要らんけど
大規模なクラスライブラリの中では重要な役割だと思う
0048デフォルトの名無しさん2014/01/08(水) 07:42:33.21
実装の継承が悪手で、多態を目的とした継承ならむしろOK。
0049デフォルトの名無しさん2014/01/08(水) 14:55:22.88
Go言語は継承無い
0050デフォルトの名無しさん2014/01/08(水) 18:56:33.37
インタフェースで済む
0051デフォルトの名無しさん2014/01/08(水) 21:11:32.92
実はオブジェクト指向ってしっくりこないんです！
0052デフォルトの名無しさん2014/01/08(水) 23:23:46.10
オブジェクト指向などと仰々しい名前がついてるせいさ
と一瞬思ったけど、他に適当な呼び方なんて無いな

しかし、厳格すぎるオブジェクト指向はプログラムの障壁になりえる
その点Golangって丁度良さそうだな
0053デフォルトの名無しさん2014/01/08(水) 23:48:20.78
そうそう、オブジェクト指向なんて名前付けるから変な反発というか、
なかなか理解出来ないなんてことになるんだよ。

個人的には、そのままクラス指向とか、その目的をダイレクトに表した
モジュール化プログラミングと呼んだ方が良かったと思う。

多態というのは結局、同じインターフェースを呼び出しても
その先のモジュールが違えば違う動きするというだけのことを
もったいぶってそう呼んでいるだけだしね。
0054デフォルトの名無しさん2014/01/09(木) 01:01:52.90
客体指向
0055デフォルトの名無しさん2014/01/09(木) 18:59:36.18
オブジェクト指向、ホントにあった怖い話(2004/7/10)から
>…平澤氏は、オブジェクト指向を巡る混乱の要因は、「プログラミング技術」としての
>オブジェクト指向と「汎用の整理術」としてのオブジェクト指向を同一のものとして認
>識しようとする態度にあるとする。
>　例えば、オブジェクト指向の基本解説書や記事では、クラスやポリモーフィズムなど
>…を説明する際に、現実世界をそのままオブジェクト指向という考え方を適用して表現
>しようとする。しかし、「オブジェクト指向と現実世界は大違い」（平澤氏）であり、
>オブジェクト指向を正しく理解するには、まず、プログラミング技術として、構造化プ
>ログラミングの限界を突破した後に登場した新たな技術として理解することが重要であ
>り、主に上流工程における汎用の整理術として応用されるオブジェクト指向とはまった
>くの別物としてとらえることが必要だと力説した。
0056デフォルトの名無しさん2014/01/09(木) 19:49:20.26
汎用の整理術とすらでもなくて、
モロにプログラミング技術として
「現実世界をそのままコードに落とせる」←？
というのを最大にして唯一のOOPのメリットだと言い張る人は過去にみたことある。
0057デフォルトの名無しさん2014/01/10(金) 00:49:34.49
>>>55
>オブジェクト指向と現実世界は大違い

そうなんだ
俺は今でもオブジェクト指向は、テレビとリモコンの関係だと思ってるけどw
0058デフォルトの名無しさん2014/01/10(金) 04:54:20.47
「リモコン」という概念を定義できるのがオブジェクト指向。
構造化手法だといちいちテレビ側のボタンを押しに行かないといけない。
0059デフォルトの名無しさん2014/01/11(土) 00:36:43.02
a.Run();
と
Run(a);
って、単に構文が違うだけだよね？

a.Run()という書き方をするのがオブジェクト指向というなら、
C++は、ユーザに見えないところで、a.Run()をRun(a)に置き換えてるよね？
じゃあ、C++はオブジェクト指向を装っているだけであって、オブジェクト指向じゃないんだ。

と言われたらどうする？
0060デフォルトの名無しさん2014/01/11(土) 02:56:50.52
>>59
その2つだと責任者が違うよね。
前者はa側にRunの処理内容を封じ込められるから、Runしたい側はaの内容が正しいことを保証せずに済む。

そもそもオブジェクト指向って実際にコンパイラがどう解釈するかというよりどうやってコーディングできるか、ってとこに主眼が置かれるわけだが。
パッと見オブジェクト指向に見えればそれは立派なオブジェクト指向だよ。
0061デフォルトの名無しさん2014/01/11(土) 03:00:21.83
見た目の問題でもないけどな。
C言語でもオブジェクト志向出来るわけだし
その内のいくつかは何となくやってた人も多い。
ソケットとか、ファイル辺りの関数はよくOO的と言われるし。
データや処理などの主体をどう切り分けるか、が最大の肝だと思う。
0062デフォルトの名無しさん2014/01/11(土) 05:36:50.49
>>61
データや処理の主体の切り分け方こそ完全に見た目だけの問題だろ。
0063デフォルトの名無しさん2014/01/11(土) 10:34:22.33
結局、オブジェクト指向は何のためにするの？しないといけないの？
というのが、よくある入門者の疑問で。入門者に限らないけど。

例えば、構造体を定義して、それにアクセスする関数を定義して、
必ずその関数を使わないといけないという運用にすれば、
後は見た目だけ書き方だけの問題だよね？
そして、これって、C言語とかの構造化プログラミングで普通にやっていることだから、
じゃあ、オブジェクト指向って何なの？構造化プログラミングと何が違うの？

テレビ構造体、リモコン構造体を定義して、それで"オブジェクト"設計すればいいだけだし、
関数の呼び出し構文が違うだけだよね。
0064デフォルトの名無しさん2014/01/11(土) 12:23:52.57
そもそもC++やC#のサポートするOOPはなんちゃってOOPなはずだが。
真祖smalltalk様と渡り合えると思ったのか。
0065デフォルトの名無しさん2014/01/11(土) 12:37:06.44
原理主義者は頭が固くて
場を荒らす事しかしないという印象がある
0066デフォルトの名無しさん2014/01/11(土) 12:48:24.23
>>63
＞例えば、構造体を定義して、それにアクセスする関数を定義して、
＞必ずその関数を使わないといけないという運用にすれば、

実はC言語でのオブジェクト志向の、カプセル化のやり方がそれだったりする。
公開ヘッダには構造体は前方宣言しかなく関数実装だけ。
なのでポインタを関数に渡すしか参照方法がなくなる。
まあ、継承のときにはもうひとつヘッダ作るから、そっち使われると参照されてしまうが…

＞そして、これって、C言語とかの構造化プログラミングで普通にやっていることだから、

実は構造体プログラミングだけならば、それは普通ではないんよ。
構造体を使わず、もしくは使っても処理との結び付きが弱い。

でも自然と、普通にみんなやっている。構造体と処理とを結び付けている。
それをOOPと意識せずともね。
要するに特別なことではなく、割と自然な考え方に名前付けただけよ。

そこに多態性(C++ならオーバーロードでも可能だし、C言語でも関数ポインタなどで可能だった)や
継承(ちと面倒だけどこれも可能)っていう、更に発展したやり方を持ち込んだだけ。
0067デフォルトの名無しさん2014/01/11(土) 16:04:54.98
そう。
C++という名前が表しているように、上の平澤氏の話のように、
構造化プログラミングの限界により、"運用"でカバーしなければならず、
不便だったことを改善した仕様にオブジェクト指向という固有名詞を付けただけなんだよ。

例えば、特に複数で開発するような場合、
変数を勝手な理解で自前のコードで扱う処理を書いてバグったり後の仕様変更に支障をきたしたりする対策で、
扱う関数を決めて勝手なことをしないように"運用"する必要が有ったのを、
クラスという仕組みでコンパイラが監視するようにしたり。

状態に対するイベント処理を、関数ポインタで処理を切り替える設計で、
関数１つ１つを確実に、後で仕様変更追加したものも漏れなく対応しなければならない"運用"を
ベースクラスでインターフェースを定義して継承し、オブジェクトのポインタ１つを差し替えるだけの
簡単なものにしたり。

モジュール設計で、同じインターフェースのモジュールを差し替えることで、
Ａのモジュールでは「ワン」と鳴いていたのがBのモジュールで「ニャン」と鳴く
仕組みを"運用"していたのを（以下略

「オブジェクト指向」って、モジュール設計なんだよ。そのモジュールの動きがまるで「オブジェクト」みたいだ、
ということで「オブジェク指向」なんてどっかのバカが付けたせいで、逆に初心者が分からなくなってるんだよ。
0068デフォルトの名無しさん2014/01/11(土) 16:08:30.02
で、オブジェクト指向のメリットって一言で言うと何？
0069デフォルトの名無しさん2014/01/11(土) 16:41:30.95
開発速度とメンテナンス性が良い
0070デフォルトの名無しさん2014/01/11(土) 16:51:27.24
>>67
>「オブジェクト指向」って、モジュール設計なんだよ。そのモジュールの動きがまるで「オブジェクト」みたいだ、
>ということで「オブジェク指向」なんてどっかのバカが付けたせいで、逆に初心者が分からなくなってるんだよ。

モジュール設計はオブジェクト指向の持つ特徴の一つであって、
決してモジュール設計とオブジェクト指向は同一であると見なすべきではない

たとえばC(手続き型)からC++(オブジェクト指向)の流れであれば、
Cでの様々なコード設計手法に対して、定まった「制約」を加えたものがC++だ
ここで、制約という言葉は否定的なニュアンスがあるので、巷では
「枠」という言葉のハイカラな表現である「フレームワーク」が好まれるらしい
いいかえると、「C(手続き型)を定まった枠で縛りつけたものがC++(オブジェクト指向)」である
そして最近では、自ら喜んで縛られて快感を追い求めるマゾ気質の若者が増殖中

まとめると、こういった縛りプレイ(？)を総称してオブジェクト指向と名前を付けた人はバカではないし、
名前を付けたことが初心者を困惑させる要因になっている訳でもない
あるフレームワークをマスターすることが難しいのと同様に、オブジェクト指向とは
本質的に難しいものであり、それを分かっていない人達が混乱を巻き散らしていると考える
0071702014/01/11(土) 18:12:36.87
>>68
設計をオブジェクト指向という一つの「枠組み」でとらえることができる、こと
ここで設計とは、従来の手続き型設計手法における：
　　機能設計/構造設計/詳細設計(コード設計)
に対応する

オブジェクト指向は本格的な開発プロジェクトにとって
有益であるのはもちろんのこと、個人のプログラミングにも役に立つ
たとえば、何か作りたいモノ(=主題、要求仕様)があったと仮定すると、
それを分析して「適切なオブジェクト指向モデルを設計」できれば、
そのモデルを直接的にオブジェクト指向言語のコード設計に反映できる
これにより、モノ作り(いわゆるソフトウェア開発)の効率化が図れる

ここで注意すべきは、「モノ(=主題、要求仕様)」は現実世界に存在する概念であり、
「多くの概念モデルは、オブジェクト指向モデルでは表現できない」点である
オブジェクト指向の教科書で取り上げられるような単純なモノであれば、
その概念モデルをオブジェクト指向モデルで表現できることは多いが、
現実世界にある大半の複雑なシステムには当てはまらない
これがオブジェクト指向分析/設計(OOA/OOD)の本質的な難しさである

そして、オブジェクト指向プログラミング(OOP)を理解しただけで
オブジェクト指向(OO)のすべてを分かった気になっていた平澤氏(>>55)が、
現実世界の開発現場でプロジェクトに混乱を巻き散らしていた張本人であったのは
言うまでもないことだ
0072デフォルトの名無しさん2014/01/11(土) 18:28:31.89
>>68
有益だけど面倒だったことが誰でも簡単に出来るようになった
0073デフォルトの名無しさん2014/01/11(土) 18:28:53.27
>>69
レストン！

>>71
失礼、ちょっと大げさになりすぎた。
もっと限定して、本当に聞きたかったことはこう。
非OOPと比較してOOPのメリットは？

俺は、結局んところモジュール性の上乗せだと思う。
ただしこれは想像であって、クラスという単位で名前つけたり、
インスタンスを複数の抽象レベルで扱えたりすることが、
非OOPで出来るのかどうか不勉強で知らない、
仮に出来ないとしたら、出来るOOPのほうがその分オイシイ、の発想。
0074デフォルトの名無しさん2014/01/11(土) 18:30:59.87
>>72
レストン！
まぁよく聞く「CでもOOP出来る！」発言はじゃあオマエがそれをやってみろ、
実用としてそれでラクをしてみろ、という気分になっちゃうね。
まあこういうと単にOOPLへの感謝にすぎないが。
0075702014/01/11(土) 18:54:24.49
>>73
>クラスという単位で名前つけたり、
>インスタンスを複数の抽象レベルで扱えたりすることが、
>非OOPで出来るのかどうか

クラス(class)とは「型(type)」いわゆるデータ型であり、
インスタンス(instance)とは「値(value)」である、と想定してみよう
もしこれが正しければ、型と値を表現できる非OOP言語であっても、
「型という単位で名前つけたり、値を複数の抽象レベルで扱えたり」
することはできる、と言える

クラスと(一般の)型との違いは、クラスが各クラス間に「継承」という
階層関係を持てるのに対して、(一般の)型は階層関係を持てない点にある
ただし、ここまではC言語によるOOP技法のように非OOPでも実現できる

そして非OOP言語の世界には「型とは値である」という発想がある
つまりデータ型を(値として)実行時に定義したり生成できるパラダイムであるが、
実験的な言語はいくつか提案されてきたけれど、どれ一つとして普及には成功しなかった
この「型とは値である」という発想をOOPの世界で言い換えたものが
「リフレクション(メタプログラミング)」になる
そしてリフレクションは Ruby on Rails の成功等で実用化が一般にも知られるようになり、
現実のOO設計技法として普及に成功した
つまり「OOPで出来て非OOPでは出来ない」のはリフレクションである
0076デフォルトの名無しさん2014/01/11(土) 19:08:45.37
コンピュータの歴史を辿れば分かりやすいかな。といっても実際の歴史は知らんので想像ｗ

最初は機械語レベルで十分だったけど、規模が大きくなってくるとやってられなくなるので、
ある程度の一連の機械語をまとめて１つの抽象的な命令に置き換える高級言語が生まれた。

そしてさらに規模が大きくなってくると長大なソースコードにやってられなくなったので、
一連のコードを抽象化して擬似的に１つの命令化、すなわち関数化する、構造化言語が生まれた。

そしてさらに規模が大きくなって大量の関数にやってられなくなったので、
関連の強い関数群とか、データとその処理をグループ化して１つの単位にするオブジェクト指向言語生まれた。

そしてさらに規模が大きくなると？？？？
サービス指向とかかな？？
0077デフォルトの名無しさん2014/01/11(土) 19:08:46.23
まさかそんなところに着地する話とは思いもよらなかったｗ
結論については消化できてないのでひとまず言及は避けておく。

> ここまではC言語によるOOP技法のように非OOPでも実現できる

ここらに一回、慎重に線引きをしてみたいもんだが、
非OOPLでOOPできる場合、そのメリットはOOPのものなのか？
それとも、非OOPLのものなのか？
手柄はOOPにあるのか非OOPLにあるのか。
この領域に入った議論はいっつもモヤッとしてるのを感じる。


非OOPLで、非OOPをして、それが、
OOPのメリットに迫るか上回るかの例をいつも見たいと思っている。
0078デフォルトの名無しさん2014/01/11(土) 19:16:33.98
OOP言語で作っても実行されるのは機械語だよ。だから機械語でもOOPは出来るｗ
構造化言語は、構造化を簡単に出来るようにした
オブジェクト指向言語は、オブジェクト指向を簡単に出来るようにした
だけ。
0079デフォルトの名無しさん2014/01/11(土) 19:17:57.98
>>78
その考えのほうがスパッと行ってるな。
どうも俺余計なこと考えちゃってたみたい。
0080デフォルトの名無しさん2014/01/11(土) 21:48:39.30
オブジェクト指向って１つ１つのオブジェクトの作成でその力を使いきっていて、
オブジェクトをどのようにつなげていくかに関しては無能っぷりを撒き散らしている。
デザインパターンのグダグダっぷりを見ていると痛々しい。
0081デフォルトの名無しさん2014/01/12(日) 04:06:08.19
>>80
忘れがちではあるけど、実はデザインパターンを構造型で作るとオブジェクト指向より更に胡乱でメンテナンスの難しい糞コードが生まれる。
グダグダに見えてあれが一番便利でコンパクトだったりするんだよ。
それに、一つの機能の使い方だけで性格の全く違う有用なものが最低23個も生まれるって考えると、
つなげ方には自由度と一貫性が両立されてるわけで、むしろ美しいとは思わないか？　俺は思わないけど。
0082デフォルトの名無しさん2014/01/12(日) 19:12:18.26
>>71 面白い書き込みをありがとう。オブジェクト指向はわからんなぁと思っ
ていたが、経験的に身に着けられるような、テクニックやハッキング技術と
は違うということがわかった。

書きぶりを見るに、オブジェクト指向「設計」はきちんとした
計算機科学専攻の大学院レベルのトレーニングを経ないと習得できないもの
なのだろう。そのような教育を修めた技術者が基底クラスの設計とコーディング
ルールを決めたう上で、開発をするのがあるべき姿なのだろう。
0083デフォルトの名無しさん2014/01/12(日) 21:19:56.49
なるほど。こういう人が設計するべきだね。
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
0084デフォルトの名無しさん2014/01/12(日) 22:11:16.30
正直業務アプリのフレームワークなんて決まりきっててすでに用意されてるしな
日付だの画面部品だのは基本的なものはもう標準ライブラリに入ってるし

パンピーがオブジェクト指向でなに設計するん？
0085デフォルトの名無しさん2014/01/12(日) 23:28:17.13
標準ライブラリやフレームワークで足りないものを実装するとき。

基本的な関数はともかく、画面部品はだいたい使えるが、
ちょっとだけ機能をつけ加えたいってことはよくある。

その時、だいたい部品は拡張可能になっているが、
それを拡張するときはオブジェクト指向の知識が必要になる。
0086デフォルトの名無しさん2014/01/13(月) 00:38:58.51
それっぽい言葉だけは出揃っているんだけど実装がことごとくダサダサなのが地球のオブジェクト指向☆
0087デフォルトの名無しさん2014/01/13(月) 00:46:14.36
>>84
パンピーならゲームじゃね？
ゲームはオブジェクト指向と親和性高いからオブジェクト指向の独壇場みたいなところあるし。
0088デフォルトの名無しさん2014/01/13(月) 02:50:15.91
>>85
単に抽象クラスにコード実装するだけだろそれ
その程度ならVBでポトペタしたボタンをダブルクリックするのと何もかわらん

本当に何かFWが提供している以上のことをやろうと思うとどのような思想で
抽象化されているかまで理解しなければならないのがooの最大クラスの欠点
0089デフォルトの名無しさん2014/01/13(月) 03:08:57.42
抽象クラスって言ってる時点で
オブジェクト指向の知識が必要になってるじゃねーかｗ
0090デフォルトの名無しさん2014/01/13(月) 11:48:20.38
C++使うから、訳が分からなくなるんだよ
VBScriptでオブジェクト指向してみると分かりやすくなるさ
0091デフォルトの名無しさん2014/01/13(月) 14:48:48.64
言語にこだわるのは無能

本質は変わらない
0092デフォルトの名無しさん2014/01/13(月) 14:50:56.00
じゃあすべてマシン語で書け。
0093デフォルトの名無しさん2014/01/13(月) 15:29:04.85
あれだろ仕様書の日本語やカタカナ英語にこだわっている人。
さもなくば肩書きとか名誉とか貯金とか、
結局人間は無意識に何かに拘ってるんだよ。
0094デフォルトの名無しさん2014/01/13(月) 16:38:59.80
>>91
PrologとHaskellとRuby勉強した後に同じ事を言えればいいが
0095デフォルトの名無しさん2014/01/13(月) 17:53:20.40
Rubyなんかパチもんは外して代わりにSmalltalkとLISPを、あとAPLを入れたいね
0096デフォルトの名無しさん2014/01/13(月) 21:55:09.22
「言語なんて全部一緒」って言ってる人
関数型言語を意図的に無視しているから嫌い
0097デフォルトの名無しさん2014/01/13(月) 22:00:25.74
じゃあ、言語なんて二種類しかないでいい？

っていうか、今は関数型言語の機能が
オブジェクト指向な言語に取り入れられて来ているからねぇ。

オブジェクト指向言語が純粋ではない関数型言語に近くなってるよ。
だから全部一緒っていうのもあながち間違いじゃない。
0098デフォルトの名無しさん2014/01/13(月) 22:16:10.65
いやー、全然近くなってないよ
0099デフォルトの名無しさん2014/01/13(月) 22:20:58.17
近いよ。もう関数型言語特有のものっていうのは
少なくなってるでしょ？

ここに関数型言語特有のものを書いてみ

ほんの数個出るだろうけど、それ以外は
もう関数型言語じゃなくても良くなってる。
0100デフォルトの名無しさん2014/01/13(月) 22:41:41.90
カレーか
0101デフォルトの名無しさん2014/01/13(月) 23:11:06.46
つりだろ。
0102デフォルトの名無しさん2014/01/13(月) 23:17:36.90
最終は機械語
0103デフォルトの名無しさん2014/01/13(月) 23:20:52.45
機械語といっても、必ずしも手続き型とは限らない
0104デフォルトの名無しさん2014/01/13(月) 23:42:14.64
>>100
カリー化ね

http://yuroyoro.hatenablog.com/entry/2012/08/10/232443
> Rubyでは、1.9からProc#curryがサポートされてカリー化できるようになった。

言語構文でネイティブにサポートされてないってだけで
カリー化をする関数は作れる。
0105デフォルトの名無しさん2014/01/14(火) 00:02:07.60
>>102
ネットの機械語はjavascript
0106デフォルトの名無しさん2014/01/14(火) 01:31:22.59
言語なんて全部一緒なんじゃなく、全部載せの言語があるだけじゃないか？
逆だと思う。
0107デフォルトの名無しさん2014/01/14(火) 02:11:13.68
ノコギリなんてみんな一緒って言うのとおなじくらいナンセンス。
関数型と手続き型では日本の引きノコ、海外の押しノコくらいの違いがあり、
じゃあ両方いっぺんにてんで歯の左右に角度の違う歯を配置したりするノコもある。
0108デフォルトの名無しさん2014/01/14(火) 02:12:04.12
>>99
再代入禁止とか
0109デフォルトの名無しさん2014/01/14(火) 02:23:41.46
鋸の由来ってJSON（ジェイソン）に対する言葉遊びかな?
0110デフォルトの名無しさん2014/01/14(火) 02:27:55.97
>>96
（俺らがいくら関数型を使ったところで、プログラミングセンスが開花するわけじゃないんだから）
言語なんて、どれも一緒
0111デフォルトの名無しさん2014/01/14(火) 03:54:30.40
楽器に例えると？

JavaとJavaScriptは
アコギとエレキくらい違う。

SQLとRubyは
ベースとエレキくらい違う。
0112デフォルトの名無しさん2014/01/14(火) 07:40:50.30
代数的データ型とパターンマッチがOOPLにも欲しい
これ有る無しでプログラミングスタイルから変わってくる
0113デフォルトの名無しさん2014/01/14(火) 16:02:42.70
>>109
そーだよ
0114デフォルトの名無しさん2014/01/15(水) 20:45:23.41
会社の先輩が全く理解してくれない。

その人が作るプログラムはうまく動くには動くんだけど、いろんなスタイルが混在してて、
なるべくきれいなオブジェクト指向的設計にした方がいいですよ、といって説明してるんだけど。
「おまえの言うことくらい全部知ってる。だが全く実証的じゃない」って。
オブジェクト指向の利点を「実証的に」説明しろって言われてもなあ。
0115デフォルトの名無しさん2014/01/15(水) 21:04:37.18
>>114
別に無理してオブジェクト指向することないよ
0116デフォルトの名無しさん2014/01/15(水) 21:11:50.60
インタフェースを最初から決めとかないと後で困るだろ
0117デフォルトの名無しさん2014/01/15(水) 21:19:08.48
>>115,116
だけど全然認めてくれないってのもくやしいよ？
俺の説明が悪いのかと思って、いろんな本やサイトの解説漁ってメリットを語っても
「そんなハウツーレベルのメリットを追求してるからダメなんだ！」と一喝。。。

頭脳じゃ全くかなわない。理学博士だし・・・
0118デフォルトの名無しさん2014/01/15(水) 21:38:37.45
どんなに仕事を丁寧に丁寧にやったとしても、
１個問題が起きればその苦労が報われないことだってあるんだし、
理想ばっか追い求めないで、そこそこの結果を求めた方がいいと俺は思う。

てか、オブジェクト指向って何だ？
拡張性を残して再利用できるように、機能を最小にしてスマートにすること？
そのまま再利用できるように、機能を最大持たせること？
0119デフォルトの名無しさん2014/01/15(水) 21:48:45.60
>>118
ダーティーなプログラムを、周囲に何の影響も与えることなく利用できるようにすること
0120デフォルトの名無しさん2014/01/15(水) 21:50:33.91
やっぱり追求すべきは、まずはモジュール性だよ。
直行性あって再利用されがちな単位をみつけだして、
インタフェースを小さくよく考えて決めて、実装隠す。
モジュール性がより備わってるとき、それはやっぱり簡潔で柔軟だと思う。
OOPか否かに拘り続けるのもまたおかしい。
0121デフォルトの名無しさん2014/01/15(水) 22:03:13.31
ファクトリー的なことにOOPを用いようとすると、
色んな処理が重なるの部品を受け取って、
組み上げる時にスコープが利かなかったりする。
ここらへんの想像が難しい
0122デフォルトの名無しさん2014/01/15(水) 22:03:40.99
>>118
> てか、オブジェクト指向って何だ？

問題の分割のしかたの一形態です。

データ指向らしい分割のしかた
手続き指向らしい分割のしかた
オブジェクト指向らしい分割のしかた

信じる信じないはあなたの自由です
0123デフォルトの名無しさん2014/01/15(水) 22:19:12.66
たとえば構造化プログラミングの段階ひとつとっても、
うまいひとが書いたのと下手な人が書いたのって結構差がある。
そのことについて語られない代わりに、OOPのメリットとやらが先行して語られてる気がする。
0124デフォルトの名無しさん2014/01/15(水) 22:29:46.62
原理主義ってうざいし根拠ないよね。
オブジェクト指向の度合いがより純粋であれば、イコールより良いものなんだ・・・って、
誰かの言葉じゃないけど、実証的に確かめられてるモノんだろうか？
0125デフォルトの名無しさん2014/01/15(水) 22:32:08.25
>>122
もし分割の仕方で〜指向っていうのが決まるんだったら、複数の分割のやり方が混在していると良くないってことになるよね？
0126デフォルトの名無しさん2014/01/15(水) 23:07:55.64
周りが理解しやすいようにOOPやGOFのデザパタを取り入れるんじゃないのか
0127デフォルトの名無しさん2014/01/15(水) 23:12:24.34
>>125
「良くない」

ずいぶん抽象的な捉え方ですね。
もっと実証的に言ってください！
0128デフォルトの名無しさん2014/01/15(水) 23:26:21.24
>>125
ならないよ。
データ指向30%
手続き指向30%
オブジェクト指向30%
その他10%

ってなるだけさ。
それでうまくいくことは十分ある。
0129デフォルトの名無しさん2014/01/15(水) 23:37:40.58
オブジェクト指向でパッケージされたデータ構造を手続き型で処理するなんて普通にある話。
0130デフォルトの名無しさん2014/01/16(木) 01:42:08.82
>>114
要はその人に「自分の知ってる文法だけで書いてください」って言ってるだけだろ？
それは単なる甘え。
その人は純粋なオブジェクト指向や他のパラダイムを一通り勉強して、その上で一番生産性の高い方法を選んでるだけ。
多分、その人は純粋なオブジェクト指向で書こうと思えば書けるんじゃないのか？
それをあえて使わない理由、メリットを聞いてみるべきだと思うよ。
そのメリットに納得したら、お前の方が先輩のやり方を学べばいい。
0131デフォルトの名無しさん2014/01/16(木) 02:38:22.63
粗結合を実現しようと思ったら副作用は極力避けるべき

なのに、オブジェクト指向は副作用を避ける仕組みは提供しないっていうか
むしろ副作用推奨だからウンコ
0132デフォルトの名無しさん2014/01/16(木) 02:54:56.23
小クラス主義、大クラス主義とかいうヤツだっけ？
小クラス主義が書いたコードは何かの信念を貫き過ぎてると思う
0133デフォルトの名無しさん2014/01/16(木) 03:09:25.89
疎結合なら知っているけど粗結合ってなんだろう。
0134デフォルトの名無しさん2014/01/16(木) 03:27:30.69
>>131
そのためのカプセル化だろ。
関数単位ではなくオブジェクト単位での副作用禁止を推奨してるだけ。根っこは同じ。
ダダ漏れの副作用はオブジェクト指向でも推奨されてないよ。
0135デフォルトの名無しさん2014/01/16(木) 03:49:30.24
オブジェクト単位での副作用禁止ってなんだよアホか？
オブジェクトの状態を一切変化させないのか？
0136デフォルトの名無しさん2014/01/16(木) 04:06:32.24
>>135
オブジェクト内の変数とオブジェクト外の変数を別物として扱ってるだけだよ。そのためのアクセス修飾子。
オブジェクト指向において適切にカプセル化がなされていれば、コンストラクタに同じものを与えて、同じ回数、同じ引数で呼び出した時に返ってくる値が変わらないことは保証されてるだろ？
最終的に参照透過性の理念の要求は満たすことになる。
0137デフォルトの名無しさん2014/01/16(木) 04:18:31.57
ゴミｗｗｗｗｗｗｗｗｗｗｗ
0138デフォルトの名無しさん2014/01/16(木) 04:23:01.20
どの言語のオブジェクト指向なんだろうか、少なくともjavaやC++のオブジェクト指向で副作用とか考慮されてないし
考えるのはキチガイ。
0139デフォルトの名無しさん2014/01/16(木) 07:49:32.07
>>114
言語って道具だからね。
１つの道具だけで全てするんじゃなくて、
その人は色んな道具の使い方、特性を知り尽くして使い分けているんだよ。
0140デフォルトの名無しさん2014/01/16(木) 08:40:11.21
>>136
> コンストラクタに同じものを与えて、同じ回数、同じ引数で呼び出した時に返ってくる値が変わらない

仮にこれを満たしていたとしても、オブジェクトが複数箇所で参照されてたら
何回どんな引数で呼び出されたかを把握するのが難しくなるわけだが。

どこが参照透過性の理念を満たしてるわけ？
0141デフォルトの名無しさん2014/01/16(木) 13:15:32.73
ンゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0142デフォルトの名無しさん2014/01/16(木) 22:26:32.59
>>140
言っている意味がよくわからん
コンストラクタはインスタンス化される際に1回だけ呼び出されるもので、1つのインスタンスで複数回呼び出されることはない
同じインスタンスを使うのであれば、コンストラクタの引数は初期化時に使ったものと同一だろ
0143デフォルトの名無しさん2014/01/16(木) 22:39:12.98
俺だけじゃなかったんだ
0144デフォルトの名無しさん2014/01/16(木) 22:40:15.87
今更インスタンスの説明くれたるようなレベルの事は書いてないだろ

>同じ回数、同じ引数で呼び出した時に返ってくる値が変わらない

普通こっち見るだろ
0145デフォルトの名無しさん2014/01/16(木) 22:43:22.62
シングルスレッド脳に毒されてるから仕方がない
0146デフォルトの名無しさん2014/01/16(木) 22:43:39.56
もしかして「同じメソッドを」が省略されてるとか？
0147デフォルトの名無しさん2014/01/16(木) 23:15:07.45
マルチスレッドの場合、インスタンスの共有は避けるべきじゃないの?
0148デフォルトの名無しさん2014/01/16(木) 23:22:43.65
なんで？
どのスレッドから呼ばれても単一スレッドで動作すればいいじゃん。
0149デフォルトの名無しさん2014/01/16(木) 23:28:16.27
（無意味な）インスタンスの共有は避けるべき。
ってのをインスタンスの共有は（絶対）避けるべきと勘違いしてるんだろうな。
0150デフォルトの名無しさん2014/01/16(木) 23:45:28.07
おまえらがマルチスレッドプログラミングに手を出したことすらないのは分かったｗ
たとえば、排他を管理されたキューを共有したりするのはよくあること。
0151デフォルトの名無しさん2014/01/16(木) 23:48:29.34
immutableにしてビルダークラス作っとけ。
0152デフォルトの名無しさん2014/01/16(木) 23:57:46.64
オブジェクト指向じゃないやり方って、どんなものがあるんですか？
0153デフォルトの名無しさん2014/01/17(金) 02:21:10.98
オブジェクト指向なんて学ばなくても、
当然行き着く思考回路だろ。

で、オブジェクト指向は素晴らしいとか語るのはいいが、
適用できなそうな用件については経験と勘を養うしかないのか？
0154デフォルトの名無しさん2014/01/17(金) 02:28:57.41
スコープを小さく、インターフェースを簡潔に。
0155デフォルトの名無しさん2014/01/17(金) 07:41:40.21
関数型はおいとくとして
非オブジェクト指向のソースコード呼び方って手続き型しか呼称がない
perlとかCで普通に書いてるソースがそれ

手続き型は、OO程は「これやれ」みたいな規則ないから
他人のソースコードが読みにくいのはどうしようもない
だから手続き型を読みやすくする為にOOってルールを設けたようなもんだと思う
手続き型でかくのは読みやすく書くってより読み手が読む力つけるしかない
0156デフォルトの名無しさん2014/01/17(金) 07:50:01.47
構造化プログラミングを手続き型でそれの対比でオブジェクト指向というのが、どうも個人的に違和感。
SQLとかHTMLのような結果を定義したら、システムがその途中の手続き処理をやってくれる宣言型言語との対比なら分かるんだが。
0157デフォルトの名無しさん2014/01/17(金) 08:00:23.21
>>156
オブジェクト指向でプログラムするためには、構造化プログラミングをする必要があると思うのだが...
0158デフォルトの名無しさん2014/01/17(金) 08:05:11.35
構造化ってのはgotoスパゲッティからの開放だからな。
0159デフォルトの名無しさん2014/01/17(金) 11:12:08.56
goto から qozo へ
0160デフォルトの名無しさん2014/01/17(金) 15:30:24.13
関数呼び出しはGoto文である、を思い出したｗ
0161デフォルトの名無しさん2014/01/17(金) 15:32:00.79
関数呼出しはgoto文である
http://toro.2ch.net/test/read.cgi/tech/1232749808/
0162デフォルトの名無しさん2014/01/18(土) 16:06:30.86
ミクロなコードは関数型で、
マクロな構造はオブジェクト指向で
やるのが現状ではベターですよ
0163デフォルトの名無しさん2014/01/28(火) 03:07:50.32
共通するコードブロックがあるからクラスを派生させるんだよね?
けれど、設計段階で共通するコード片が分かってないなら、
cで書いた方が、よっぽど柔軟で保守しやすいんじゃねーの?
0164デフォルトの名無しさん2014/01/28(火) 03:09:19.25
>>162
Ocamlでしょうか？Scalaでしょうか？
0165デフォルトの名無しさん2014/01/28(火) 06:38:10.96
>>163
実装段階で分かったことを設計にフィードバックさせられないんだとしたら、そっちを変えた方がいいね
0166デフォルトの名無しさん2014/01/28(火) 07:34:32.13
オブジェクト指向じゃないと、複雑さと規模に限界が来る
0167デフォルトの名無しさん2014/01/28(火) 11:27:27.08
オブジェクト指向が許されるのはミクロとマクロな部分だけ。
ミドル付近でやらかすとグダグダになる。
何でもクラスやインターフェースでカプセル化して疎結合にすればいいってもんじゃない。
0168デフォルトの名無しさん2014/01/28(火) 19:12:22.85
>>166
OSSだと、オブジェクト指向でプロジェクトが失敗みたいな話をちらほら聞くんだけど
0169デフォルトの名無しさん2014/01/28(火) 20:40:18.56
今日、隣のJavaのプロジェクト覗いたんだが。。

あ・・・ありのまま 今 起こった事を話すぜ！
Javaのソースを見たら、Cだった
何を言（ry

んで、バグだらけでプロジェクトが上手くいってないらしい。
そらオブジェクト指向が分からないままオブジェクト指向言語だから、
で、ぐちゃぐちゃなコードを書いてればそうなるわな。
0170デフォルトの名無しさん2014/01/28(火) 21:13:01.28
>>169
そいつらがCを使ったところでまともなコード書けるとは思えないのだが
0171デフォルトの名無しさん2014/01/28(火) 21:51:02.96
今日、隣の診察室を覗いたんだが。。。
0172デフォルトの名無しさん2014/01/29(水) 03:36:26.53
>>167
それ、オブジェクト同士の振る舞いを統括するオブジェクトを作れば解決するだろ。
0173デフォルトの名無しさん2014/01/29(水) 23:21:31.35
解決した問題より大きな問題が新たに発生しないと見極めてからだな。
0174デフォルトの名無しさん2014/02/02(日) 13:25:13.41
>>170
Cにはある意味static関数しかないから。
0175デフォルトの名無しさん2014/02/02(日) 13:40:55.60
>>174
Javaオンリーな人向けには、そういう表現になるかもなあ
C言語やってると、微妙に誤解しそうになる表現だw
0176デフォルトの名無しさん2014/02/11(火) 17:25:57.60
vba使ったら自由すぎてワロタ
variant便利すぎ、もうjavaに戻れんわ
0177デフォルトの名無しさん2014/02/11(火) 18:05:16.79
型推論でええやん
0178デフォルトの名無しさん2014/02/11(火) 19:33:04.86
インタフェースでええやん
0179デフォルトの名無しさん2014/02/11(火) 22:16:02.60
途中で型分岐とかせず最後までvariantでいけるならいいんだけどね。
0180デフォルトの名無しさん2014/02/12(水) 08:53:48.18
どうしてもバリアントで受け取らなければならない場合や
その方が高速である場合（セルの範囲を読み込む場合やGetRowsなど）
便利というか使わざるを得ないけど

受け取った後に計算するなら1次元配列に再配置した方が速度が出る
VBAで様々な高速化を実施するより、下手でもJavaで書いた方が性能出るけどね
0181デフォルトの名無しさん2014/02/12(水) 20:57:51.67
性能より書いててどれだけ横着できるかが大事。
0182デフォルトの名無しさん2014/02/12(水) 21:08:41.44
オブジェクト指向で考えると、コンピュータープログラムってのは、
どんなオブジェクトがどんな状態を持って、それぞれがどんな振る舞いをするか。
たったこれだけの事なのだ。
0183デフォルトの名無しさん2014/02/12(水) 21:34:48.46
でもこういうのはキモくないか？
https://github.com/ruby-no-kai/rubykaigi2013/blob/master/public/ids/elevator_pitch.md
0184デフォルトの名無しさん2014/02/13(木) 11:25:37.34
JavaでもVariant自作出来るだろ？
0185デフォルトの名無しさん2014/02/14(金) 14:53:36.28
DBべたべたのコード書くときにVariantは楽
だが長期間メンテナンスしていくシステムだと毒に変わりやすい
0186デフォルトの名無しさん2014/02/19(水) 15:10:05.89
ORMつかわないのか?
0187デフォルトの名無しさん2014/02/19(水) 21:04:50.46
どうしようもない設計ををオーバーラップして型をごまかすくらいにしか使われていない
俺の会社
0188デフォルトの名無しさん2014/02/20(木) 07:46:24.18
ゴキジェット指向に見えた
0189デフォルトの名無しさん2014/02/27(木) 20:19:06.96
俺のコインを返してくれ
0190デフォルトの名無しさん2014/02/28(金) 07:12:17.53
>>189
左腕を突き上げてジャンプしたらいいよ
0191デフォルトの名無しさん2014/03/07(金) 12:03:13.05
Objective-CがC++と同じぐらい拡まってたら
オブジェクト指向の議論ももう少しスッキリしたんだろうなぁと
最近思ったりする。
0192デフォルトの名無しさん2014/03/21(金) 03:14:10.78ID:GtGmhcv1
>>169 classをただのnamespaceとして使って、モジュラープログラミング
してるってこと?
0193デフォルトの名無しさん2014/04/04(金) 22:22:43.50ID:FlB7JCyi
スレ「スレ立てるまでもない質問はここで 135匹目」のレス#100,101から、
議論が長引いてきたのでこちらへ移動してきた

議論の発端は以下に示す同スレ「134匹目」のレス#991になる
>あと、オブジェクト指向設計で忘れられがちな概念の一つに、
>(クラス間の関係における)抽象クラスと具象クラスという考え方(原理/原則)がある：
>・ある抽象クラスはサブクラスを持てる(=継承できる)が、具象クラスはできない
>・ある具象クラスはインスタンス化(=インスタンスを生成)できるが、抽象化クラスはできない

これ対してKAC氏から「具象クラスから派生させてはいけないのは何故？」との疑問が出た
以下ではこの疑問への答えを書くつもりだが、一旦、ここで切る
0194デフォルトの名無しさん2014/04/04(金) 23:21:02.37ID:FlB7JCyi
(>>193の続き)
具象クラスから派生させる具体例として、これはIllustratorやVisioのような
ドローアプリの開発を想定し、二次元座標における幾何学図形クラスの設計を検討する
図形クラスには直線/円/多角形などが様々な仕様が考えられるが、ここでは
具象クラス「長方形(Rectangle)」とそれから派生した具象クラス「正方形(Square)」に限定する
派生については、「正方形とは長方形の高さと幅が等しい図形である」という幾何学の定義に従い、
「ちょっと特別なもの」という発想で派生させることを決めた

Rubyによるコードを以下に示す

class Rectangle　　# 長方形クラス
　　attr_accessor :height, :width　　# 高さと幅 -- getterとsetterを伴う属性
　　def initialize(height, width)　　# コンストラクタ
　　　　@height = height; @width = width
　　end
　　def area; @height * @width; end　　　　　　　# 面積を計算する
　　def perimeter; (@height + @width) * 2; end　　# 周辺の長さを計算する
end

class Square < Rectangle　　# 正方形クラス
　　def initialize(size)　　# コンストラクタ
　　　　super(size, size)
　　end
　　def set_size(size); self.width = size; self.width = size; end　　# 大きさを再設定する
end

# 使用例
r = Rectangle.new(3, 5)　# 高さが3で幅が5の長方形インスタンスを生成
s = Square.new(7)　　　　# 大きさが7の正方形インスタンスを生成

さて、この具象クラス継承には、どんな問題があるだろうか？
0195デフォルトの名無しさん2014/04/05(土) 00:26:33.29ID:uFCYQY3d
まあ、問題があるとすればRectangle.new(3.3)ってやっても、正方形として扱えないってことだな。
でもそれはRectangleとSqueareが
AbstractRectangle（仮）という抽象クラスから派生したものであっても同様に抱える問題だ。
01961932014/04/05(土) 00:57:21.05ID:UcRTpVkm
>>195
そのとおりだね、その問題は確かに存在する
そして、それは具象クラス継承と抽象クラス継承の両者に共通する問題だから、
以降の議論では除外できると思う

さて、問題は他にもあるけど、わかるかな？ >>all

# ....などと質問を投げて、自分は寝るとします
0197デフォルトの名無しさん2014/04/05(土) 01:36:33.37ID:uFCYQY3d
大丈夫だ問題ない。
0198デフォルトの名無しさん2014/04/05(土) 01:37:07.19ID:uFCYQY3d
つか、お前がその問題を解説する役割じゃないのかよｗ
0199デフォルトの名無しさん2014/04/05(土) 01:37:57.50ID:iKzYf4PO
ポカーン
0200KAC2014/04/05(土) 02:02:43.29ID:Dr+e6snh
>>194
問題提起の前に、そもそもクラスの定義がおかしい。
こんな状態で継承関係の話をしても無駄。

そのコードでいう「長方形」「正方形」の振る舞いを
日本語で書いて並べてみ？
間違えてる事に気がつくから。
0201デフォルトの名無しさん2014/04/05(土) 07:42:57.21ID:Gxm31Mf6
>>193-200
ネタスレにマジレス汚物撒き散らすな。
02021932014/04/05(土) 14:09:45.24ID:UcRTpVkm
>>200
おかしいのなら、それを単刀直入かつ具体的に指摘し、
もし可能なら対策も具体的に示すべき
KAC氏ならできるよね？

>>198
昨晩は眠かっただけで、続きの準備はできているよ
書こうと思ったけど、しばらくKAC氏のレスを待つつもりだ
0203KAC2014/04/05(土) 16:00:08.67ID:Dr+e6snh
>>202
クラスの振る舞いがまともに書かれていないだろ？

長方形は、高さと幅で初期化され、面積と周辺の長さを取得できる。
正方形は、サイズで初期化され、長方形の計算に加えて、サイズを再設定できる。

↑これ読んで気がつかないか？
これ、そもそも正方形の特徴をあらわした派生じゃないだろ。

せめて、「正方形とはこういうものです」って自然な派生クラス書いてからにしてくれ。
02041932014/04/05(土) 16:23:36.51ID:UcRTpVkm
>>203
だから、「まとも」とか「自然な」みたいな
曖昧な理想論や精神論しかKAC氏は書けないの？
もしそれだけ大口を叩けるなら、「正方形とはこういうものです」という
自然な派生クラスについて、お手本となる仕様定義やコードを示せばいい
KAC氏ならできるだろ？

あと、何か勘違いしているかもしれないけど、
この例は「具象クラス継承の問題」を説明するために選んでいる
だから、厳密で実用的な幾何学図形クラスの仕様としては不完全だよ
それとも、そんな枝葉の些細な問題を大きく取り上げたいのかな？
0205KAC2014/04/05(土) 16:31:50.52ID:Dr+e6snh
>>204
いや、あまりにもクラス設計が酷かったから思わず書いただけ。
せめて、長方形のクラスにも同じメソッドがないと話が進まないと思って。

今後の話に関係ない部分なんだったら無視して進めてくれて構わない。
02061932014/04/05(土) 16:46:03.46ID:UcRTpVkm
>>205
だから、「クラス設計が酷い」のなら、それを具体的に指摘するか、
きれいなクラス設計を示しなさい、という話だよ
ただ単に「まともでない」「不自然だ」「酷い」と吐くだけなら幼児にもできる
大人ならば、ナゼそうなのかという論理的な理由を明解に文章化できるはず
0207デフォルトの名無しさん2014/04/05(土) 17:04:50.47ID:cyL1yVuU
>>194
よくある例だよね。
なんとかプリンシプルが守られてないっていう例。
親クラスのインスタンスの代わりに子クラスのインスタンス入れても動かない例。

rectangles.add(new Rectangle)
rectangles.add(new Square)
void stretchwidth(rs, rate) {
　rs.each {|r| r.with *= rate}
}
stretchwidth(rectangles, 10.0)
みたいにしたときね。まあこれはアクセッサをオーバーロードして面倒みたら回避できるけど。

あと気軽に多角形でクラス階層育てようとして、
案外うまくいかねーな、おいしくないな、ってのもよくある話。
そこらへんをKAC氏は言いたいんじゃないかな最終的に。
0208KAC2014/04/05(土) 17:38:04.47ID:Dr+e6snh
>>206
具体的に指摘も何も、203読んだら流石にわかると思ったんだけど。。。

少なくとも、一般的に認識される「正方形」「長方形」の扱いと、
書かれているクラスの仕様がかけ離れてるぞっていう指摘なんだけど、
もしかして193のいう図形ってのはたとえば以下のような特徴を持つのか？

　正方形は大きさを変化させることができるが長方形は変化しない。

そうなんだとしたら、別に構わない。
ただ、それならそういうものだという日本語での仕様説明があったほうがいいと思う。
0209デフォルトの名無しさん2014/04/05(土) 17:55:16.94ID:zPG1X+2f
スレタイの意味がよくわかる。
02101932014/04/05(土) 18:08:44.01ID:UcRTpVkm
では、>>194の具象クラス設計について、３つの問題点を以下に示す
(1) Squareクラスは常に２つの属性を持つが、正方形の高さと幅は
　必ず等しいから情報量として無駄であり、どちらか１つがあればいい
(2) Squareクラスではsetterメソッド Square#height= と Square#height= が
　公開されているから、インスタンス化した後にこれらのメソッドを使うことで
　高さと幅の異なる正方形を作成できてしまう
(3) 正方形の周辺の長さは大きさを４倍するという簡単な計算で求めることができるのに、
　この実装コードでは計算量として複雑になる

これら具象クラス継承固有の問題は、「抽象クラス-具象クラス」という概念を
導入することによって解決できる

(長過ぎるので、ここで切る)
02111932014/04/05(土) 18:09:22.83ID:UcRTpVkm
(>>210の続き)

class SubclassResponsibility < StandardError; end　# 例外クラス（StandardErrorはRubyの標準クラス）

class AbstractRectangle　　# 長方形クラス（抽象クラス）
　　def area; raise SubclassResponsibility; end　　　　　# 面積を計算する（抽象メソッド）
　　def perimeter; raise SubclassResponsibility; end　　# 周辺の長さを計算する（抽象メソッド）
end


class Rectangle < AbstractRectangle　　# 長方形クラス（具象クラス）
　　attr_accessor :height, :width　　# 高さと幅 -- getterとsetterを伴う属性
　　def initialize(height, width)　　# コンストラクタ
　　　　@height = height; @width = width
　　end
　　def area; @height * @width; end　　　　　　　# 面積を計算する
　　def perimeter; (@height + @width) * 2; end　　# 周辺の長さを計算する
end

class Square < AbstractRectangle　　# 正方形クラス（具象クラス）
　　attr_accessor :size　　# 大きさ -- getterとsetterを伴う属性
　　def initialize(size)　　# コンストラクタ
　　　　super(); @size = size
　　end
　　def area; @size * 2; end　　　　　　# 面積を計算する
　　def perimeter; @height * 4; end　　# 周辺の長さを計算する
end

最後に、これらを比較した(集合の)ベン図とクラス図を以下のリンク先で示す
　http://www.h6.dion.ne.jp/~machan/misc/abstract-class.png
0212デフォルトの名無しさん2014/04/05(土) 18:11:29.41ID:oSbQ4SXU
あんたちょっと大げさよｗ
0213KAC2014/04/05(土) 18:20:28.71ID:Dr+e6snh
>>210
やはり正方形ってものを正しく認識できていないだけにしか見えない。

あと、(2)に関してはオブジェクト指向その物の理解がなっていない事によるバグだし、
(3)のような瑣末な事に気をとられ過ぎてコード量を増やし、バグの温床になってる。

　　def area; @size * 2; end　　　　　　# 面積を計算する

とか、わざわざコード書いてバグ出してるとかアホの極み。
02141932014/04/05(土) 18:43:44.47ID:UcRTpVkm
>>208
>もしかして193のいう図形ってのはたとえば以下のような特徴を持つのか？
>
>　正方形は大きさを変化させることができるが長方形は変化しない。

いいや持たないよ、長方形は高さと幅を(setterメソッドで)変化させることができる

変化させることができるから、「attr_accessor :height, :width」というコードへ
コメント「# 高さと幅 -- getterとsetterを伴う属性」を書いている
（なお、Rubyではreader/writer/accessorという用語を使うのが一般的であるが、
　Rubyに不慣れな人も多いことを考慮し、getter/setterというJava用語で記述した）
それともgetter/setterという用語すら知らなかったのかな？

もしもLAC氏が「Rubyはまったく知らない」のなら、最初にそれをレスすべきだよ
それなら(自分はJavaが不慣れだから)時間はかかるけど、Javaへ書き直すこともできた
KAC氏のいつものパターンだけど、
後になってから「言い訳することばかり考える」のは、いいかげん見苦しい
02151932014/04/05(土) 18:46:53.76ID:UcRTpVkm
>>213
それはコーディングのバグだね
以下のように訂正する

X: def area; @size * 2; end　　　　　　# 面積を計算する
O: def area; @size * @size; end　　　　# 面積を計算する
02161932014/04/05(土) 19:08:38.75ID:UcRTpVkm
>>207
>親クラスのインスタンスの代わりに子クラスのインスタンス入れても動かない例。

そのとおりだね、まさに「よくある例」のハズだと思うんだけど、
なぜそれにKAC氏は気付かない or 気付けなかったんだろうか....

>あと気軽に多角形でクラス階層育てようとして、
>案外うまくいかねーな、おいしくないな、ってのもよくある話。

その話もよくあるけど、こちらは抽象クラス継承でも解決できない問題だ
オブジェクト指向分析/設計(OOA/OOD)とオブジェクト指向プログラミング(OOP)との違いの
一つとも言える、より本質的な問題と言える
この問題については、このスレでも以前に一部書いた(>>71)けど、
機会があれば議論を続けたいと思う
（今は、具象クラス継承の問題とごっちゃにすべきじゃないから....）
02172072014/04/05(土) 19:20:31.07ID:Whr3oZ1+
半笑いで遠くを見つめながら言うけど、
どうして人はオーバーロードとオーバーライドを書き間違い続けるのか…ｗ
いつでも半笑いである。
0218デフォルトの名無しさん2014/04/05(土) 19:38:09.67ID:alNqa9E3
設計がおかしい。
正方形クラスを継承して長方形クラスを定義すべきだろ。
0219KAC2014/04/05(土) 19:46:17.99ID:Dr+e6snh
>>216
| なぜそれにKAC氏は気付かない or 気付けなかったんだろうか....

あまりにもツッコミどころが多すぎて書かなかっただけ。
設計観点からいうとその指摘じゃなくて既に指摘済みの内容の方が先だろ。
オブジェクト指向にとっては、そんな実装の問題よりも重要な事があることを理解しろよ。


まあ、そんなことはどうでもいいけど。
>>210-211に書いてあることが「長方形から正方形を派生してもできる」
という当たり前の事実(→実装あの仕方が下手なだけ)に何故気がつかないのかが不思議。
0220デフォルトの名無しさん2014/04/05(土) 19:50:11.00ID:uFCYQY3d
>>210
(2)について、
>>211のAbstractRectangleが許されるなら、
>>194においてwidthとheightをprivateにしていい。
そうすれば幅と高さの違う正方形は生まれない。

(3)は、適切な計算式を使うようにオーバーライドすれば良い。

問題があるとすれば(1)だけ。
0221デフォルトの名無しさん2014/04/05(土) 20:31:26.51ID:iKzYf4PO
［MyRectangle setWidth:hoge setHeight:hage］を
作ったんなら、別にそのMyRectangleを基底オブジェクトを継承した新しい
［MySquare setSize:hoge］の"中に入れて"
単純にsetSizeで飛んできた同じ数値を中のMyRectangleの両方にセットするだけじゃねぇの？
それで四角くなんねぇの？？
0222KAC2014/04/05(土) 20:41:15.19ID:Dr+e6snh
>>214
あぁ、読み落としてた。

| いいや持たないよ、長方形は高さと幅を(setterメソッドで)変化させることができる

属性を直接触って変化させることを良しとしないからこそ
　　def set_size(size); self.width = size; self.width = size; end　　# 大きさを再設定する
こんなメソッドを用意したんだと思ったんだが、そういう思想すら無い訳ね。

| それともgetter/setterという用語すら知らなかったのかな？

お前のソースは酷すぎて意図すらロクに相手に伝わらない事を自覚しろ・・・
0223デフォルトの名無しさん2014/04/05(土) 20:50:54.03ID:alNqa9E3
普通サブクラス化によって機能・情報が増えるだろ。
この喩えは逆なんだよ。四角形じゃなくラーメンでやってくれ。
02241932014/04/05(土) 20:58:20.10ID:UcRTpVkm
>>218
設計がおかしいのなら、具象クラス継承のまま問題を解決できる
「正方形クラスを継承して長方形クラスを定義」したコードを示せばいい
（Rubyでなくても、C++/Java/C#/Smalltalkくらいなら読むことはできるよ）
それが示すことが「具象クラス継承でも問題無し」実証することになる
論よりコードだ

>>21
>あまりにもツッコミどころが多すぎて書かなかっただけ。

また後から言い訳をするのかな？
コーディングのミス(=バグ)は、コードを修正すればいい
でも具象クラス継承という設計のミスは、設計にたちかえって対策しなさい、という話だ

>>218へのレスと同様、「実装あの仕方が下手なだけ」なら、
具象クラス継承のまま問題を解決できる「上手な実装」を示せばいい
0225KAC2014/04/05(土) 20:59:34.10ID:Dr+e6snh
>>224
じゃあ、C++で同じコードかいてくれ。
おかしいところ全部なおしてやるから。
0226デフォルトの名無しさん2014/04/05(土) 21:11:20.38ID:uFCYQY3d
抽象-具象　というのは、javaで言うところのinterfaceなんじゃないかという気がしてきた。
ちなみにrubyやC++にはinterface無いからね。
0227KAC2014/04/05(土) 21:13:53.22ID:Dr+e6snh
>>224
どうせ後で「後出し」とか言い出すんだろうから先に言っといてやるけど、

そもそも「長方形」と「正方形」でクラスを分けるってのに
長方形の形を変化させることができるってのがナンセンスだろ？
長方形を 10,10で作っても正方形の特徴を持たないのか？
こういうところから、"オブジェクト指向がわかっていない"って言ってるんだ。

"今回の実装ではそういう前提にする"というのはよくあることだから、
それなら話を聞いといてもいいかと思って細かいことは言わんかったけど
前提の話を出してくるわけでもなく、正方形の説明があるわけでもなく、
ソース見て判断したら読みづらいし、よくわからん言いがかりつけてくるし。

お前がちゃんと設計できるようになったら設計の相手してやるけど、
今回はお前の実装指摘するくらいはしといてやるよ。
0228デフォルトの名無しさん2014/04/05(土) 21:14:50.03ID:h7/csfF/
>>226
？

interface - abstract class - (concrete)class
の後ろ二つの話を単にしてるようだけど？
0229デフォルトの名無しさん2014/04/05(土) 21:16:10.50ID:alNqa9E3
だからラーメンのほうがわかりやすいって。
0230デフォルトの名無しさん2014/04/05(土) 21:19:25.79ID:LKf4adEN
まず手続き型で書いてみて
オブジェクト駆動に翻訳して書いてみる
シックリくる方を採用。


関数型はハミゴ
0231KAC2014/04/05(土) 21:33:22.05ID:Dr+e6snh
あ、>>225にコードだけ指定したけど、
やっぱりお前のコードは見ても理解できないだろうから先に要求出しとく。

今回の設計における
長方形とは、 (1) の属性を持ち、(2) の操作が可能な図形である。
正方形とは、長方形のうち (3) という特徴をもったものである。

の形でいいから、(1)〜(3)を埋めてそれぞれのクラスの意図を書いてくれ。
0232デフォルトの名無しさん2014/04/05(土) 21:34:50.39ID:uFCYQY3d
>>228
>>210 の (1)を懸念した結果として、>>211 の AbstractRectangleのようなものが出来てるので、
これはinterfaceの話。
abstract classならデフォルトのデータセットや実装を持てるから(1)に対する答えとならない。
02331932014/04/05(土) 21:42:52.00ID:UcRTpVkm
>>220
>(2)について、.....(中略)....
>>>194においてwidthとheightをprivateにしていい。

たとえばRubyならば、>>194のコードのSquareクラス定義内に
「private :height, :width」という宣言を追加すれば実現できるかもしれない

でも、今回はたまたま直接の継承関係にあるからprivateにするという対策に
気付くことができるけど、多段継承で多数の属性を持つ現実のクラスライブラリ開発では、
どの属性がpublicのままでどれがprivateにすべきか洗い出すのは労力が多すぎる
それなら最初から抽象クラス継承で再設計するほうが、全体としては楽になると思う


>(3)は、適切な計算式を使うようにオーバーライドすれば良い

適切な計算式とは、「@height * 4」あるいは「@width * 4」になると思うけど、
それは高さまたは幅の「どちらかを選ぶべきか」という悩ましい問題を抱えることになるよね
とはいえ、この反論がいささか苦しいのは認める


>問題があるとすれば(1)だけ。

まず根本に(1)の問題があり、(1)によって(2), (3)の問題が派生しているという意味で、
この部分の指摘はまったく正しいと思う
02341932014/04/05(土) 21:52:36.59ID:UcRTpVkm
>>221
"中に入れて" という意味が分からない
実際、>>194では、メソッドSquare#set_size(size)の定義の中で
setterメソッド Rectangle#=(height) と Rectangle#=(width) を使って実装している
Smalltalkでもかまわないんで、"中に入れて" をコードで表現してくれないかな？
02351932014/04/05(土) 21:53:55.81ID:UcRTpVkm
>>222
>お前のソースは酷すぎて意図すらロクに相手に伝わらない事を自覚しろ・・・

setter/getter というキーワードを見落とすKAC氏に言われてもね....
0236デフォルトの名無しさん2014/04/05(土) 21:54:43.95ID:Rvr2fR9T
>>232
なるほどねえ。おっしゃるとおりに思えてきたわ。
>>193からの「抽象クラスと具象クラス」連呼を字のとおり読み取ってたわけだけど。

ただまぁ、「具象クラスから派生させてはいけない」ってのも分からないし、
「抽象クラス継承」で何かが解決できるからといって、
だからどうしたんだ、という気も依然しているが…。
0237デフォルトの名無しさん2014/04/05(土) 21:57:07.10ID:iKzYf4PO
みんな、君の「ぼくがかんがえたおぶじぇくとしこうのもんだいてん」って奴が
いったいどういう勘違いから生まれたなんなんだろうな？と訝しんでるだけで
たぶん君のコードがおかしいだけで、本質はどこもオブジェクト指向と関係ないと思ってるんだが
まだやるか。
0238KAC2014/04/05(土) 22:02:42.14ID:Dr+e6snh
>>235
正方形に別のメソッド作ってたのみて、
お前の意図はそういうことだと思ったんだが深読みしすぎただけだったよ。

だから、早くクラスの説明をしろ・・・と
0239デフォルトの名無しさん2014/04/05(土) 22:13:28.20ID:bVXjG6ay
「具象クラスから派生させてはいけない」
そんなもんなのかねぇ？と思ってちょっと調べてみたら、
javaのクラスライブラリには

public class Stack extends Vector
public class LinkedHashMap extends HashMap
public class Properties extends Hashtable
public class BufferedInputStream extends FilterInputStream
public class BufferedOutputStream extends FilterOutputStream
（以下略）

なんかいっぱいあってワロタｗ
02401932014/04/05(土) 22:18:54.40ID:UcRTpVkm
>>225
いや、こちらはコードを書いたのだから、次はKAC氏がコードを示す番だろ
最初に「Rubyをまったく知らない」のに「知ったかぶり」をしたのだから、それを突き通せ
（もし次にコードを示すターンがあれば、その時は自分が書くよ）
それとも、KAC氏とは大口を叩いたあげく、いざとなるとコードが書けない「口先番長」なのかな？
もちろん>>224で書いたように、C++でもかまわないよ

では、継承関係を持つ２つの具象クラス：長方形(Rectangle)」と正方形(Square)に限定し、
>>210で挙げたものと類似の問題が生じない実装をコードで示してくれ
待っているよ
02411932014/04/05(土) 22:25:27.15ID:UcRTpVkm
>>227
>どうせ後で「後出し」とか言い出すんだろうから先に言っといてやるけど、

いや残念ながら、その問題はすでに>>195氏が指摘していて、それに対して>>196でレスを返している
頭に血が上っているみたいだけど、もう少し冷静になった方がいいと思う

>ソース見て判断したら読みづらいし、

読みづらいも何も、LAC氏は「Rubyをまったく知らなかった」んじゃないの？

>ソース見て判断したら読みづらいし、

捨て台詞ですか？
02421932014/04/05(土) 22:35:36.39ID:UcRTpVkm
>>241の最後の一文を訂正

誤：
>>ソース見て判断したら読みづらいし、
>
>捨て台詞ですか？

正：
>>今回はお前の実装指摘するくらいはしといてやるよ。
>
>捨て台詞ですか？

こちらも冷静さを失っているようだ
注意しよう
02431932014/04/05(土) 22:45:52.66ID:UcRTpVkm
>>231
>>241で書いたように、次はKAC氏がコードを示す番だ
では、それら意図を満たし、なおかつ>>241の条件：

　継承関係を持つ２つの具象クラス：長方形(Rectangle)」と正方形(Square)に限定し、
　>>210で挙げたものと類似の問題が生じない実装

をコードで示してくれ
では、待っているよ
0244デフォルトの名無しさん2014/04/05(土) 22:47:45.73ID:Dr+e6snh
>>240
すごいな。
訳わからんソースだして勝ち誇るのか

これ、どっちが先に喧嘩売ったの？
0245KAC2014/04/05(土) 22:48:34.40ID:Dr+e6snh
名前わすれた
0246KAC2014/04/05(土) 23:08:17.44ID:Dr+e6snh
書き損じのままじゃ伝わらない気がしたのでもう一度。

>>240
まず、この話題は何のためにやっているのか思い出せ。
お前が主張する「具象クラスから派生させてはいけない」を説明するためのものだよな。

で、例示してきたソースはぐちゃぐちゃ、仕様もわからない。
肝心の解説もソースの実装が下手な事によるバグのことだけ。

お前のやったことは、
　「ほら、このコードにはこんなバグがあるでしょ」
って説明して、
　「ほら、このコードにはそのバグは無いでしょ」
って説明しただけ。

でも、そもそもの仕様からバグってるから言ってることが誰もわからない。
誰も賛同していないことに気がつかないのか？

で、
仕様もわからんけどバグだらけのコードをどうやって正しく示せというのか。
逃げも何も、そんなエスパー求められても困るし、正直どうでもいい。
0247KAC2014/04/05(土) 23:10:10.14ID:Dr+e6snh
せっかくお前の説明が理解できるようにフォローのコメントしてやってたのに
>>241-243みたいな態度をとられるともうね。

もうフォローしないので、ちゃんと自分で説明しろよ
02481932014/04/05(土) 23:41:03.68ID:UcRTpVkm
>>246
コードが汚いとか仕様が意味不明と騒いでいるのは
KAC氏一人だけじゃないのかな？
それ以外の具体的な指摘には、その各論が正しければ正しいと認め、
違っていれば真面目に答えているつもりだ
実際、>>213のバグ指摘はそれを素直に認めて訂正してる

もし>>194の仕様では満足できないなら、KAC氏が自ら幾何学図形クラスの
仕様について、お手本となる定義を示せばいいと思うがね
02491932014/04/05(土) 23:41:52.81ID:UcRTpVkm
>>240,243ではKAC氏のコードを待っていると書いたけど、
やっぱり、こちらでもC++のコードを示すことにする
ただし、>>194に対して直接LAC氏がC++のコードを希望したと想定し、
>>194のRubyコードの意味を変えずC++へ移植したものとする
また、そのほうが両方のコードを比較できるから、
KAC氏以外の人達にとっても有益だと判断する
（ただし、>>213,215のKAC氏指摘バグは、最初から対策済みとする）

まず最初は、具象クラス継承のC++版コードを示す

class Rectangle {
public:
　　Rectangle(int h, int w): height(h), width(w)
　　void set_height(int h) { height = h; }
　　void set_width(int w) { width = w; }
　　virtual int area(void) { return height * width; }
　　virtual int perimeter(void) { return (height + width) * 2; }
private:
　　int height, width;
}

class Square: public Rectangle {
public:
　　Square(int s): Rectangle:(s, s) {}
　　void set_size(int s) { set_height(s); set_width(w); }
}

// 使用例
Rectangle R(3, 5);
Square(7);

(続く)
02501932014/04/05(土) 23:55:53.07ID:UcRTpVkm
(>>249の続き)
次は、>>211のRubyコードに対応した抽象クラス継承のC++版コードを示す

class AbstractRectangle {
public:
　　virtual int area(void) = 0;
　　virtual int perimeter(void) = 0;
　　virtual ~AbstractRectangle() = 0;
}:

class Rectangle: public AbstractRectangle {
public:
　　Rectangle(int h, int w): height(h), width(w) {}
　　void set_height(int h) { height = h; }
　　void set_width(int w) { width = w; }
　　virtual int area(void) { return height * width; }
　　virtual int perimeter(void) { return (height + width) * 2; }
private:
　　int height, width;
};

class Square: public AbstractRectangle {
public:
　　Square(int s): side(s) {}
　　void set_size(int s) { side = s; }
　　virtual int area(void) { return size * size; }
　　virtual int perimeter(void) { return size * 4; }
private:
　　int size;
};

(終わり)
0251デフォルトの名無しさん2014/04/06(日) 00:55:17.97ID:O4YLAHOK
いつまでどうでもいい議論やってるんだよ。
そもそもの設計がおかしい。Square をクラスにするのが間違い。
Rectangle に IsSquare() メソッドを用意するのが正しい。
加えて Rectangle.createSquare(size) メソッドもあるとよい。
0252デフォルトの名無しさん2014/04/06(日) 01:02:21.27ID:Bz2fL/Bm
Rectangleはjavaではすでに用意されてるから自作するのはアホらしい。
0253デフォルトの名無しさん2014/04/06(日) 06:58:31.20ID:M292oQRa
このスレのやり取りでオブジェクト指向は時間の無駄なのが判った
0254デフォルトの名無しさん2014/04/06(日) 09:34:47.01ID:1V1mpQ2/
非常に短くまとめると、
コードの実装を考えながらオブジェクトを設計するから失敗する。
0255デフォルトの名無しさん2014/04/06(日) 13:18:59.09ID:vCvEJP4g
今のやり方はテストコードを書いて作りつつ、
設計を修正しながら開発するという手法。

全く何も考えないのは駄目だが
最初に完璧なものを考えようとしても無理
どうせ後から要求が来て変えざるをえない。

その時テストコードがないから、
設計を変えないで局所的に対処してお茶を濁すことになって
どんどん失敗への道へ突き進むことになる。
02561932014/04/06(日) 17:34:59.78ID:9QIW1syL
>>251
今回の>>193から始まった流れは、
まず継承を使うという前提の元で、
具象クラスから派生させることの是非を議論してきた

その提案のポイントは、オブジェクト指向設計で
そもそも継承は必要か？という、継承を使うことの是非だよね？
そうした視点も大切だと思うけど、
今回の議論の流れからは脱線している
0257デフォルトの名無しさん2014/04/06(日) 17:52:47.96ID:KLQmxdDw
ちなみにObjective-Cには抽象クラスがない。
すべて具象クラスから継承する。
具象抽象うんぬんは言語仕様の問題でOOPの問題ではない。
02582512014/04/06(日) 17:53:16.69ID:O4YLAHOK
> その提案のポイントは、オブジェクト指向設計で
> そもそも継承は必要か？という、継承を使うことの是非だよね？
アホか。継承は必要に決まってんだろ。

間違った設計に間違った継承をしている時点で「非」であって
お前らの議論は無意味だっていってるだけだ。
お前らは「議論っぽい何か」をしているに過ぎない。
0259デフォルトの名無しさん2014/04/06(日) 17:55:47.03ID:ofic9QKu
なにがどうまちがっているとか具体的な指摘はできない、まで読んだ。
02601932014/04/06(日) 18:00:19.98ID:9QIW1syL
さて、KAC氏はコードが書けず逃げ出したようなので、
ここまでの議論をマトメて終わらせようと思う
・安易な具象クラス継承(>>194)には、問題(>>207前段,210)がある
・この問題のいくつかは、抽象クラス継承(>>211)によって解決できる
・ただし抽象クラス継承によって、すべての問題が解決できるわけではない(>>195,207後段)
・また、そもそもオブジェクト指向設計に継承は必要か？という視点もある(>>251)

これで自分は名無しに戻る
長文レスの連投、失礼しますた
02612512014/04/06(日) 18:04:09.78ID:O4YLAHOK
具体的な指摘？251で書いたじゃん。
正方形である、というのは長方形の１つの属性だから。
変える可能性がある属性を、簡単には変更できない「クラス」
として表現するのは間違っている。
高さと長さを変えられない immutable な設計なら
別クラスでもまだマシ。
02621932014/04/06(日) 18:20:27.72ID:9QIW1syL
>>260カキコの後にレスに気付いたので、短くレスを返す

>>257
Obj-Cと同様、>>194のコードを書いたRubyにも抽象クラスの構文は存在しない
そして安易な具象クラス継承の問題は、Obj-Cでも起こりうる
つまり、これはプログラミング(OOP)や言語(OOPL)の問題ではなく、
設計(OOD)の問題だと考える

>>258
>>207後段で指摘があるように、幾何学図形クラスのような
複雑なクラス継承設計では、「上手に」やらないと失敗することが多い
これを「上手い/下手」や「美しい/汚い」といった
理想や直感で表現することは簡単だけど、そこで思考停止せず、
ナゼそうなのかという論理的かつ具体的な理由を探求していくことが大切だと思う
0263デフォルトの名無しさん2014/04/06(日) 18:25:32.01ID:KLQmxdDw
揚げ足取るようで悪いんだけど、もっと短く言うと設計の問題って事だよねw
0264デフォルトの名無しさん2014/04/06(日) 18:30:26.41ID:XHqlAa3G
用語の定義についてやりあうつもりはないが、
個人的にはOOPつったら、
そらその設計も含むやろ？って考えなんでモヤモヤするｗ
OOXXについてはOOPとOOPLだけでいいやｗ
02651932014/04/06(日) 18:52:54.76ID:9QIW1syL
>>261
横レスするけど、その問題はすでに>>195で指摘されていて、
>>196でレスを返しているよ
そして、たとえimmutableであっても問題の本質が減るわけではないことは、
>>195のコードで示されている
0266デフォルトの名無しさん2014/04/06(日) 18:57:41.02ID:MIkXP9Ib
まぁ、Rectangleあるのに正方形がどうしてもほしい、
それがあったらとにかく捗るんだ、っていう状況なら、
単独で、そのままクラス一個書いたほうがマシだろうね。
0267デフォルトの名無しさん2014/04/06(日) 19:14:25.52ID:vFcnRkT9
長方形と正方形は、プロパティが違うだけで、
継承関係ではない

それに具象クラスは、メンバ変数を持てるが、
抽象クラスやインターフェースは持てない

だから、具象クラスから派生させている場合は、
メンバ変数も同じものが使える
02682672014/04/06(日) 19:27:05.99ID:vFcnRkT9
抽象クラスから派生させる場合は、
円、4角形、3角形のように、
頂点数が違うなど、クラス同士の違いが大きい場合

具象クラスから派生させる場合は、
かなりクラス同士が似ている場合
0269デフォルトの名無しさん2014/04/06(日) 20:12:08.16ID:M292oQRa
どうせなら元ネタのドローアプリの部品として使う方向で話してくれないかな
>具象クラスから派生させる具体例として、これはIllustratorやVisioのような
ドローアプリの開発を想定し、
この部分だけに注目してね
そもそも長方形と正方形でクラス分ける必要あるんかこれ
0270デフォルトの名無しさん2014/04/06(日) 20:22:27.36ID:KLQmxdDw
ない。
boolean isSquare() があればいい話なのでw
0271デフォルトの名無しさん2014/04/06(日) 20:35:09.90ID:IDxsBa0K
>>257
むしろObjective-Cしか最近やってないから抽象クラスってなんだったっけ？って
調べに行っちゃったよ…Obj-Cだったらプロトコル準拠とか
完全に"単なるインターフェースの話"で終わりじゃん、こんなの…
ある言語の仕様じゃ不具合が出るからオブジェクト指向は〜とかなんだそれ。
0272デフォルトの名無しさん2014/04/06(日) 21:37:43.69ID:9QIW1syL
>>268
その「違いが大きい」とか「かなり似ている」とは、
具体的には何かな？

また、4角形から頂点を1つ取り除くという変形操作からは3角形が作れる
これは、>>261の考え方に従えば「頂点数は(派生ではなく)属性」になる
さて、どちらが正しいのだろうか？
0273デフォルトの名無しさん2014/04/06(日) 21:56:46.27ID:wJ4fkLfq
目的によって変わる
0274デフォルトの名無しさん2014/04/06(日) 22:18:59.06ID:9QIW1syL
課題を更に一般化してみる

長方形と正方形の関係に限定した場合、
派生(=継承)を使う方法(>>194,211)と
属性を使う方法(>>251,261)が提案された

さて、ここに幾何学図形の関係を表す図がある
http://sicp.iijlab.net/fulltext/fig226.png
これをクラスとして実装する時、
どのような考え方で設計できるだろうか？
派生、属性、それとも委譲、あるいはそれらの混在？
02752512014/04/06(日) 22:34:07.02ID:O4YLAHOK
おい、勝手に一般化するなよ。
273 がいうように、目的によってふさわしい設計は
変わるんだからさあ。
頂点数が増減するなら、３角形と４角形はもちろん
多角形クラスの属性に決まってんじゃねえか。
0276デフォルトの名無しさん2014/04/06(日) 22:35:13.68ID:IDxsBa0K
というかその人193ってハンドル外しただけで193本人でしょ？
0277デフォルトの名無しさん2014/04/06(日) 22:46:28.71ID:wJ4fkLfq
描画目的ならPath使うとか
0278デフォルトの名無しさん2014/04/06(日) 22:55:28.80ID:9QIW1syL
>>276
もちろんIDを見れば分かるように193本人だよ
>>260で書いたように、
具象クラス継承の話題は終わったので名無しに戻っている
0279デフォルトの名無しさん2014/04/06(日) 23:12:46.04ID:9QIW1syL
>>277
・4要素のPathオブジェクトがある
・先頭の頂点と末尾の頂点が等しい
・ある2辺の角度が直角である
さて、このオブジェクトは長方形ではないのか？
というのが>>195の指摘

特にimmutableと明示されていなければ
オブジェクトの変形操作を想定することは自然だし、
困った問題だね
0280デフォルトの名無しさん2014/04/06(日) 23:39:55.58ID:wJ4fkLfq
IsRectangleが真になるだけ
描画目的ならそれだけで十分じゃないの？
0281デフォルトの名無しさん2014/04/06(日) 23:57:37.94ID:KiSKuklc
何が問題かさっぱり分からん。

Java界隈で実際のコーディングには糞の役にも立たない議論のための議論をしてる
馬鹿な連中がいたけど、あれと同類だなこのスレの連中は。
0282デフォルトの名無しさん2014/04/07(月) 00:45:22.57ID:oXMI25oe
>>278のサルがいきなり迷い込んできて
「おい！俺が壺に手を突っ込んでバナナ握ったら手が抜けないぞ！
バナナと壺は間違ってる！！」って喚いてるだけだもの。
人間に理解できるわけがない。
0283デフォルトの名無しさん2014/04/07(月) 11:37:39.15ID:LtIPC3gj
OOの勉強を始めた頃、たいていの人はis-a関係なら継承できるということを知り、AnimalやDogがどうこうとか
BirdとPenguinがどうこうみたいな説明を読んで、わかったようなわからないような感じで通り過ぎたと思う。

>>194のコードの問題の本質は、具象クラスを継承したことにあるのではなくて、長方形と正方形が実は
is-a関係ではないということ。
何がis-a関係を壊しているかというと、長方形はwidthとheightを個別に設定出来なければならないが、
正方形は個別に設定されると正方形ではなくなるという性質。

これはよく知られた問題で、C++ FAQに"Is a Circle a kind-of an Ellipse?"という項目がある。
http://www.parashift.com/c++-faq/circle-ellipse.html
軽くググると、1996年に、故まさーる氏のNiftyでの発言が引っかかる。
http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/nifty-logs/circle-isa-rectangle.html

is-a関係に関しては、 リスコフの置換原則(LSP)というものが提唱されてて、LSPを破る例として「長方形-正方形」
問題が良く取り上げられる。知らなかった人は、このスレの議論より「LSP 正方形」でググった方がいい。

LSP違反になる危険性があるから具象クラスの継承は全て禁止というのは思考停止で、具象クラスを継承するなら
LSP違反にならないようにしようというのが正しいエンジニアの態度だと思うね。
0284デフォルトの名無しさん2014/04/07(月) 11:42:56.92ID:LtIPC3gj
で、>>260で
> ・安易な具象クラス継承(>>194)には、問題(>>207前段,210)がある
という微妙な表現になっているが、これは安直ではない具象クラスの継承ならやってもOKということなのかな？

大きく戻るが、元スレの以下のコードに問題があるなら、それを指摘して欲しい。

class Person
　def work
　　# 具体的なコード
　end

　def eat
　　# 具体的なコード
　end

　def sleep
　　# 具体的なコード
　end
end

class Japanese < Person
　def sleep
　　# Japanese特有なコード
　end
end
0285デフォルトの名無しさん2014/04/07(月) 13:30:56.98ID:alAzooFJ
class BeautyGirl < Person
　def unko
　　# 何もしない
　end

　def charm
　　# 歌って踊る
　end
end
0286デフォルトの名無しさん2014/04/07(月) 13:36:23.76ID:alAzooFJ
俺の美少女がポリモーフィズム（笑）なんかでそんじゃそこらのPersonと一緒にされてたまるか。
ざけんじゃねーぞ。LSPなんて窓から投げ捨てちまえ！！
0287デフォルトの名無しさん2014/04/07(月) 14:00:53.30ID:alAzooFJ
などと、多態できなければ継承する意味がないとする風潮に異を唱えており……
0288デフォルトの名無しさん2014/04/07(月) 14:03:46.51ID:em392Pz9
アイちゃん、元気良すぎるよねー
0289デフォルトの名無しさん2014/04/07(月) 14:04:25.66ID:UtNGELLj
まーたレベルの低いのがまぎれこんだぞこれ。
0290デフォルトの名無しさん2014/04/07(月) 20:56:09.38ID:cLSEaO9j
>>284
結論を一言で述べれば「そのコードでは、問題の有無を判断できない」になる

具象クラス継承が問題となるのは、属性を継承する場合だ

もしもメソッドの振る舞いがクラスだけに従属するのなら、問題にはならない
たとえばメソッド sleep が単純に寝具を文字列で返すだけであれば、
クラス Person の実装コードは "ベッド" に
クラス Japanease の実装コードは "布団" になるが、これば問題ない
しかし、たとえばベッドの種類が年齢(という属性)によって変わるのであれば、
>>210で挙げたものと同類の問題が生じる

もし必要であれば、実装コードの中身を埋めてから再質問してもらいたい

なお、>>283はとてもいい参考資料だね
LSPという言葉は知らなかった、ありがとう
0291デフォルトの名無しさん2014/04/08(火) 01:52:29.12ID:oJprcDQC
なにが問題なのかさっぱりわからん。
0292デフォルトの名無しさん2014/04/08(火) 02:29:41.87ID:pzcPlx8G
たぶんずっとこの子は

肉まんの頭はネジネジになってるので
肉まんの型では餡まんは作れない！

って叫び続けてるのだと思うよ。
ネジネジは肉まんの本質じゃないだろwとみんなが言ってるのに
まったく聴く耳ないみたいだけど。
0293デフォルトの名無しさん2014/04/08(火) 10:55:40.45ID:7tBkTIa1
なんだ、DDJの引用とかしてるからもう少し知識があるかと思ったが、SOLIDも知らないど素人だったか。
0294デフォルトの名無しさん2014/04/08(火) 13:31:53.38ID:vDS7KuCw
>>290
実装コードの中身ってなにさ。
訳わからん条件付けて質問を回避するんじゃなくて
わからないならわからないって正直に書けよ。

お前の意見に賛同してる奴なんて一人もいないだろ？
全く頓珍漢な事を喚くだけなら邪魔だから黙ってて。
0295デフォルトの名無しさん2014/04/08(火) 13:39:08.61ID:vDS7KuCw
反対意見が多くなってきた途端に名無しになるようなチキン野郎は
意見の主張なんて10年早いってことだよな。
0296デフォルトの名無しさん2014/04/08(火) 14:19:36.48ID:L1P7kA7L
誰に言ってるんだ？名無しばっかりだろう？
0297デフォルトの名無しさん2014/04/08(火) 14:23:27.93ID:8UuyoCZR
オブジェクト指向のプロが集まるスレはここですか
0298デフォルトの名無しさん2014/04/08(火) 14:36:36.01ID:G5uD774T
>>296
ちょっと前の>>278のことだと思われ

まあ、名前消しても>>290も同一人物だろ。
0299デフォルトの名無しさん2014/04/08(火) 15:53:13.23ID:G5uD774T
193の言ってることが理解できた奴いたら
代わりに翻訳してくれないか？

結局の所なにが問題だって言ってるの？
0300デフォルトの名無しさん2014/04/08(火) 16:31:51.04ID:7tBkTIa1
>>299
もともとの主張はこんな感じ。

スレ立てるまでもない質問はここで 134匹目
http://toro.2ch.net/test/read.cgi/tech/1393350301/991
1. オブジェクト指向設計で忘れられがちな概念の一つに、抽象クラスと具象クラスという考え方がある
2. クラスツリーにおいて、具象クラスたり得るのはリーフノードのみ
3. リーフノード以外に具象クラスがあるとすれば、それは設計に問題があると推測できる
「だから、具象クラスを継承してはいけない」という結論になってるようだ。

その後、「いや具象クラスを継承したっていいよ派」が出てきて、具象クラスを継承してはいけない
理由を尋ねられると、193はこのスレに移動してきて、いろいろあったあげくの結論がこれ。
>>260
> ・安易な具象クラス継承(>>194)には、問題(>>207前段,210)がある
> ・この問題のいくつかは、抽象クラス継承(>>211)によって解決できる
> ・ただし抽象クラス継承によって、すべての問題が解決できるわけではない(>>195,207後段)
> ・また、そもそもオブジェクト指向設計に継承は必要か？という視点もある(>>251)

安易でない具象クラス継承ならやってもよいかどうかという問いには、明言を避け続けている。
0301デフォルトの名無しさん2014/04/08(火) 16:35:25.50ID:G5uD774T
安易な具象クラス継承というか、例は"馬鹿な"クラス継承だよな。
そもそもの問題からして理解できないんだが・・・
0302デフォルトの名無しさん2014/04/08(火) 16:49:39.50ID:BcEyRfdK
193本人が継承とは何かって事をちゃんと理解してないし
継承に関係ない問題点だらけだし指摘されても理解できないし
最後は回りに突っかかってごまかして終わり。

理解するにはかなりのエスパー能力が求められる。
0303デフォルトの名無しさん2014/04/09(水) 22:01:40.30ID:kfnTQyIb
>>291,299
>>210(および>>207)を参照


>>294
>>290の先頭行で率直に「判断できない」と書いている
「判断できない」ってのは、つまり「わからない」と意味は同じだろ

そして、続けて判断できない理由を具体例付きで説明しているつもりだ
属性という単語を知らないとは思えないし、
(感情的で主観的な意見ではなく、)具体的な質問ないし技術的な反論を希望する


>>298
>>193から始まった議論は、(そこで書いたように)KAC氏の疑問
「具象クラスから派生させてはいけないのは何故？」に応えるつもりで始めたけど、
結果的には(>>260で書いたように)KAC氏はコードが書けずに逃げ出して終わった

自分としてはKAC氏の疑問に対して>>139以降で真面目に応えているつもりだし、
唯一の具体的な指摘であるコーディングのバグ(>>213)についても、すぐに対応した(>>215)
さらにKAC氏の追加要望(>>225)にも応えてC++で、書き直したコードも示した(>>249,250)
そして「あまりにもツッコミどころが多すぎ(>>219)」とか「お前のソースは酷すぎ(>>222)」といった
大口を叩くなら、KAC氏自身がこの「長方形-正方形問題」に対して
お手本となるクラス設計をコード付きで示すべきだ、と要求した(>>240,243)

もしKAC氏から設計やコードのレスがあれば、その時は自分も番号コテを復活するつもり
もちろん、KAC氏ではない他の人からの設計やコードでもかまわない
0304デフォルトの名無しさん2014/04/09(水) 22:25:08.96ID:+pM0qgCN
だから、まず長方形と正方形クラスをなんの目的で作ってんのかわからないとどうしようもないって
0305デフォルトの名無しさん2014/04/09(水) 22:27:15.72ID:kfnTQyIb
>>300
過去スレを引用するなら、改変/改竄せずに(以下の>>193のように)そのまま複写すべき

>議論の発端は以下に示す同スレ「134匹目」のレス#991になる
>>あと、オブジェクト指向設計で忘れられがちな概念の一つに、
>>(クラス間の関係における)抽象クラスと具象クラスという考え方(原理/原則)がある：
>>・ある抽象クラスはサブクラスを持てる(=継承できる)が、具象クラスはできない
>>・ある具象クラスはインスタンス化(=インスタンスを生成)できるが、抽象化クラスはできない

自分は、元スレを含めて、クラスツリーやらリーフノードといった言葉は一度も使っていないぜ


>>安易でない具象クラス継承ならやってもよいかどうかという問いには、明言を避け続けている。

安易でない具象クラス継承と言っても範囲が広すぎるし、そもそも安易という言葉そのものが曖昧だ
そして、具体的な質問(>>284)に対しては、>>303で書いたように明解な答え(>>290)をレスしている
0306デフォルトの名無しさん2014/04/09(水) 22:43:37.57ID:+pM0qgCN
よくみたら>>194にドローアプリと書いてあった
ドローアプリでどういう理由で正方形と長方形を別にする必要があるの？
扱いに違いが出るならそもそもis-a関係にないし、同じならわざわざ無駄なクラスを作る必要はない
0307KAC2014/04/10(木) 00:35:55.40ID:RtckMDN4
>>303
いっぱい言いすぎたのは悪かった。理解できないんだな。
では、>>304氏も指摘しているように>>231だけでいいから答えてくれ。

「仕様がないことには設計の話なんてできない」って事は理解できてる？
0308デフォルトの名無しさん2014/04/10(木) 00:39:57.80ID:/AIMsHz9
KACの超超超絶設計書まーだー？
0309KAC2014/04/10(木) 00:47:54.98ID:RtckMDN4
>>308
「仕様がないことには設計の話なんてできない」って事は理解できてる？
0310デフォルトの名無しさん2014/04/10(木) 01:41:47.84ID:u/ao0IlG
vimと同じ動作っていうのは
仕様だってわかってるかい？

「vimと同じ動作」というのは仕様じゃないという反論は
まだ一度もしてないよね？
0311KAC2014/04/10(木) 02:19:25.45ID:RtckMDN4
>>310
該当スレの8読め。何騒いでるんだか。
0312デフォルトの名無しさん2014/04/10(木) 02:25:44.66ID:u/ao0IlG
読んだ。で？
言いたいことは何も変わらんよ。

仕様はvimと同じでいい。
0313デフォルトの名無しさん2014/04/10(木) 04:22:56.27ID:4OHbUqu5
自分が間違ってるのがわかったなら
みんなにゴメンナサイしないとね。
0314デフォルトの名無しさん2014/04/10(木) 14:33:43.22ID:jXRv5b7w
>>305
> 過去スレを引用するなら、
引用したつもりはないよ。

> 自分は、元スレを含めて、クラスツリーやらリーフノードといった言葉は一度も使っていないぜ
引用じゃなくてまとめだから。
俺のまとめが間違ってるならそう指摘してくれ。
0315デフォルトの名無しさん2014/04/10(木) 16:16:41.64ID:tZxH7aP+
今回の正方形-長方形クラスの問題点は、具象クラス、抽象クラスとかは関係ないと思う。
煽り抜きで、ドローアプリ用の図形クラスを考えた場合、座標に関する情報を全く持って
ないとか話にならない。だって、それを画面のどこに描画するのかがさっぱりわからない
んだもん。
逆に、図形を頂点の集合として表現すれば、正方形とか長方形とかにクラス分けする意味
もなくなる。それが何角形だろうが何方形だろうが、どのクラスから継承されようが、統一
されたメソッドで変形、移動、描画、面積の計算、等々出来るよ。

自分の考えをまとめるよ。
1.具象クラス、抽象クラス、継承という議論をするのに、今回の正方形-長方形クラスは
適切とは言えない。
2.抽象クラスというアイデアが、そもそも良くない。「我輩の血を引くものは、みな
満月になると狼に変身できるメソッドを身につけないといけない。しかも、変身する
時は独自のポーズを編み出すこと」なんていう家の子供に生まれたくはないだろ？
「変身？できなくはないけど、親に教わった通りのやり方でやるよ」と言える方が自然。
0316デフォルトの名無しさん2014/04/10(木) 17:10:11.12ID:tZxH7aP+
3.デフォルトの動作が決まっていた方が使いやすいから、可能ならば具象クラスから継承
した方がラクだよね。いつ継承を利用するのかと言えば、大体の動作は申し分ないけど、
ここだけちょっとカスタマイズしたい、っていう時だもんね。
0317デフォルトの名無しさん2014/04/10(木) 17:15:19.22ID:/ZxWThzL
全くその通りで、継承の基底クラスならわかるが、抽象クラス？　なんだそれって感じ。
0318デフォルトの名無しさん2014/04/10(木) 17:42:31.77ID:jXRv5b7w
実装継承云々の議論からは撤退するけど、ひとつだけ疑問に答えてくれるかな。
暇があればでいいんだけど。

>>250のコードで、「四角形と正方形を二つ選んで、両者の幅を揃えたい」とき、クライアントコードはどう書くの？
0319デフォルトの名無しさん2014/04/10(木) 17:45:03.86ID:jXRv5b7w
ちょっと訂正。
「四角形と正方形を二つ選んで、両者の幅を揃えたい」
↓
「長方形と正方形が複数個ずつある中からそれぞれ一つずつ選んで、両者の幅を揃えたい」
0320デフォルトの名無しさん2014/04/10(木) 18:27:09.32ID:Uir6dqld
vimと同じってどこのレス？

>>315
抽象クラスのない言語はやったことないんだけど、ファイルとネットとメモリ上と区別せずにデータを読み込みたいとかの場合はどういうふうに実装するの？
0321デフォルトの名無しさん2014/04/10(木) 19:53:54.85ID:tZxH7aP+
>>320
おいらはpythonをメインにしていて、そういうことをデータ源を区別しないで読みこむ、みたいな
ことは真面目にやったことないけど、もし今そういうコードを実装するとしたら、

1.とりあえずローカルファイルとして開いてみる
2.ローカルになければネットから開いてみる.
3...以下、総当たりで試してみる
4.どっかでハンドルがオープンできれば、そこから内容を読みこむ
5.どこにも見つからなければ例外を投げる

みたいにするでしょうね。もっと上手い方法があれば教えてください。
0322デフォルトの名無しさん2014/04/10(木) 21:32:56.08ID:Uir6dqld
>>321
言い方が悪かった
C#のStreamみたいな感じのやつを言いたかった
FileStream,MemoryStreamみたいに目的ごとにStreamを継承したクラスがある設計
0323デフォルトの名無しさん2014/04/10(木) 22:16:07.28ID:7rEGmphP
>>306
>ドローアプリでどういう理由で正方形と長方形を別にする必要があるの？

必要があるかどうかは、自主開発なのか受注開発によって変わる
ここでは、顧客からの要求仕様の一部に図形オブジェクトとして
長方形と正方形が含まれていた、とでも想定してもらいたい

あるいは、>>194が記述式の試験問題として出題された、という想定でもかまわない


>扱いに違いが出るならそもそもis-a関係にないし、

そもそも論は、>>193から始まった議論の積み重ねがあったからこそ言えるのではないのかな
もしも>>306が最初から分かっていたのなら、>>194の設問に対して即座に
「そもそも長方形と正方形の間にis-a関係が存在しないのは当たり前」とレスすればよかった
そしてナゼ当たり前なのかという理由を具体的に説明できれば、
>>194の設問に対して満点の解答になる

今からでも遅くないので、説明してもらえないかな？
そして可能であれば、>>284の設問に対しても>>306の模範解答を示してもらいたい
0324デフォルトの名無しさん2014/04/10(木) 22:20:42.28ID:4OHbUqu5
＞そもそも論は、>>193から始まった議論の積み重ね
笑うとこはここ？
0325デフォルトの名無しさん2014/04/10(木) 22:38:10.69ID:/ZxWThzL
>>318
C++じゃなくて悪いんだが、そもそも図形はPathクラス一個でいいから、
セッター　 void setWidth(Path *path, float width);
ゲッター　BOOL isRectAngle(Path *path);

float w = 100.0;
if (isRectAngle(selectedPath1) && isRectAngle(selectedPath2)) {
　　setWidth(selectedPath1, w);
　　setWidth(selectedPath2, w);
}
0326デフォルトの名無しさん2014/04/10(木) 22:43:58.55ID:/ZxWThzL
>>320
Streamを継承して…っていうパターンは知らないが、
そういうのはfacadeオブジェクトを作って、内部的に処理を分ければいい。
引数にファイル名やらファイルの場所を取ればいいでしょ。
0327デフォルトの名無しさん2014/04/10(木) 22:45:15.21ID:Uir6dqld
>>323
まずKAC氏の>>231に答えようぜ
長方形の要件が「高さと横幅を自由に変更できる」なら正方形はそれに当てはまらないので、ここでは正方形は長方形ではない。
派生させたのが間違い

また、正方形の高さ、幅を変更可能なら正方形は長方形の一つの状態にすぎない。
正方形かを判定できるメソッドなりを作るだけで良い
0328デフォルトの名無しさん2014/04/10(木) 22:56:41.36ID:Uir6dqld
>>326
あんまりデザインパターン詳しくないんだけど、新しいStreamをユーザーが追加したくなったらどうするの？
例えばデータベースとか、暗号化データを自動処理するStreamとか

Streamを使ってるライブラリ側は変更不能だとして、抽象クラスなら継承してやればいいだけだが
0329デフォルトの名無しさん2014/04/10(木) 23:04:55.13ID:/ZxWThzL
>>328
facadeに機能追加するかな。
そのデータベースを使うAPIなり、暗号化処理のライブラリを使うためのメソッドまたはオプションを追加。

ただ、そちらは抽象クラスStreamを基底に、機能別にサブクラスを作るパターンだと思うし、
俺が言ってるのは別個の機能をもったクラスをfacadeに纏める話なので、
話が噛み合ないだろうというか、俺も書いててトンチンカンだなと思った。
0330デフォルトの名無しさん2014/04/10(木) 23:48:30.27ID:7rEGmphP
>>307
>では、>>304氏も指摘しているように>>231だけでいいから答えてくれ。

まず、>>304氏は>>306ですでに説明されていることを納得している
（IDが同じだから同一人物だと思われる）
また、>>231の括弧付き数字は>>210の問題のことだと思うけど、
その問題点にわからない事があるなら、どこがわからないのかを質問しなさい

>「仕様がないことには設計の話なんてできない」って事は理解できてる？

ソフトウェア工学の一般論としては理解しているよ
そして、この一般論が今回の「長方形-正方形問題」と無関係であることは、
>>306へのレスである>>323を読めば、明らかではないのかね
「仕様が書かれていないからわかりません」という解答では０点だ
さらに付け加えると、>>283が紹介してくれた文書や指定キーワードの
検索先サイト文書によれば、「長方形-正方形問題」または「楕円-正円問題」の存在は
多くの人達にとって常識らしく、特に仕様を明確に定義することなく各自が自由に論述している
「仕様がないから設計について議論できません」なんて詭弁を主張する人なんて誰一人いない

(長いので、次に続く)
0331デフォルトの名無しさん2014/04/10(木) 23:49:27.40ID:7rEGmphP
（>>330の続き)

ということで、繰り返しになる(>>240,243,303)けど、KAC氏自身が
この「長方形-正方形問題」に対してお手本となるクラス設計をコード付きで示しなさい
KAC氏は>>219で以下のように書いている
　　>まあ、そんなことはどうでもいいけど。
　　>>>210-211に書いてあることが「長方形から正方形を派生してもできる」
　　>という当たり前の事実(→実装あの仕方が下手なだけ)に何故気がつかないのかが不思議。
「長方形から正方形を派生してもできる」のが当たり前の事実であるなら、
KAC氏がお手本となる実装コードを示すのはとりわけ難しいことではないだろ？
では、クラス設計と実装コードを待つことにするよ

（これで終わり）
0332デフォルトの名無しさん2014/04/11(金) 00:35:42.41ID:YT8HAvrs
じゃあなんでドローアプリとか中途半端な目的を与えるんだよ
0333デフォルトの名無しさん2014/04/11(金) 00:39:37.14ID:bq61KSFr
問題が悪いんじゃないもん!
答えられないやつが悪いんだもん。

だれかちゃんと実装してくれなきゃやだやだ。
仕様なんて決めたら実装しなきゃ駄目だけどそんなんできないもん。

わるくないもんわるくないもん。
0334デフォルトの名無しさん2014/04/11(金) 00:46:59.78ID:ueT20Zq9
ID:7rEGmphP触るな危険。

何だかんだと言い訳して何も主張できないアホ。
ボロボロのソース出して無知を晒した後、二度と情報を出せなくなった。
何を言っても>>330-331みたい逃げ口上だけで終わる。
相手する価値もなし。
0335デフォルトの名無しさん2014/04/11(金) 00:59:52.15ID:bsaGs7xP
>>314
>俺のまとめが間違ってるならそう指摘してくれ。

まず、このスレから議論に加わったすべての人に「発言するなら元スレの先頭からすべて嫁！」と
強要するのは無茶であるし、>>314は、彼らの理解の助けになると考えてまとめてくれたのだと理解する

ただ、自分の「もともとの主張」は、(>>305で書いたように)元スレのレス#991そのものであり、
そこに書いた内容以上でも以下でもない
>>300がまとめだとすれば、最も肝心な抽象クラスと具象クラスの定義が欠けているのは問題だし、
原文で使ってもいない用語へ勝手に置き換えるのは、いらぬ誤解をまねく間違った行為になっていたと思う

あと#991(>>305)に加えて重要な「継承そのものの定義」は、元スレ「同135匹」のレス#22で書いている
>(前略).... 以下の集合論を元にしたモデル化の方法論です
>・クラスとは(数学における)集合である
>・継承とは直和であり、ここで直和とは集合の互いに交わらない
>　部分集合への分割を意味する
>・ここで集合の要素とは、属性を指す(メソッドではない)
>・交わりのある分割とは、いわゆる「多重継承」のことである
この中の属性を要素とする集合については、>>211末尾のベン図が理解の助けになると思うし、
その考え方は>>290でも詳しく説明しているので、再度、読み直してもらいたい

集合論という堅苦しい学問を持ち出しているけど、ここまでの内容を理解するには、
中学校で学ぶ集合の範囲に「直和」の概念を加えたもので十分だから、堅苦しくとらえなくてもいいはず
また「直和」については、Wikipediaでも詳しい解説されているので、そちらも参考にしてください
0336デフォルトの名無しさん2014/04/11(金) 03:42:52.44ID:mI2EoNIj
そもそも主張の基本が間違っててそこを指摘されてるのに
それすら理解してないから話が一つも進まず
議論の体を成してないのになに言ってんだ。

おまえは知恵遅れなんだよ。いい加減自覚しろ。
0337デフォルトの名無しさん2014/04/11(金) 12:50:55.88ID:jXUwhTSe
>>335
> 再度、読み直してもらいたい

お断りします。

> そちらも参考にしてください

お断りします。
0338デフォルトの名無しさん2014/04/11(金) 16:25:35.61ID:Bz/jLjhI
今更横だけど>>193の抽象具象の定義は狭いか足りない気がする…継承も実体化もできるクラスは何と呼ぶのよ
・それを具象クラスと呼ぶなら、継承しても良いと言いたい
・それは具象クラスではないと言うなら、じゃあ何と呼ぶのか聞きたい
　→ 存在してはならない！と言うなら、存在しても良いと言いたい
継承も実体化もできるクラスは、安易に作るのは危険だが、安易でなければ良いとも思う
その安易さってのが曖昧過ぎるというなら>>283みたいなのもあるワケで
0339デフォルトの名無しさん2014/04/11(金) 17:24:10.37ID:jXUwhTSe
>>338
そういうこと、あまり気にする必要無いよ。
193は具象クラスを継承したことによって発生する問題みたいなこと言ってるけど、それは間違いだから。
193以降で言われてる問題は、全部実装を継承したことによる問題だよ。抽象クラスだって実装を持てる。

このスレの戯言なんか気にせずに、普通に正しく設計することが学べる書籍を読んだ方がいい。
『オブジェクト指向のこころ』
『ドメイン駆動設計』
なんかがお勧め。
0340デフォルトの名無しさん2014/04/12(土) 00:03:30.52ID:owT3sDzh
>>327
>まずKAC氏の>>231に答えようぜ

>>231については、すでに>>330にて「仕様がないことには設計の話なんてできない」という
一般論は「長方形-正方形問題」とは無関係であり、それを設計を語らない理由とするのは詭弁である
と答えている
そして、その答えが正しいことは、>>231の要請を(自分が)拒否したにもかかわらず、
(以下の文章で)>>327自身が>>194の具象クラス継承に対する問題点を的確に指摘したことで実証された


>長方形の要件が「高さと横幅を自由に変更できる」なら正方形はそれに当てはまらないので、
>ここでは正方形は長方形ではない。派生させたのが間違い

着眼点として、完全に正しい
長方形が高さと幅を自由に変更できるのは、>>194のsetterを伴う属性宣言の実装コードから明らか
それに対して、正方形は高さと幅が常に等しくなければならないから、自由には変更できない(=すべきではない)
したがって、長方形から正方形を「派生させたのが間違い」である
0341デフォルトの名無しさん2014/04/12(土) 00:43:17.31ID:owT3sDzh
>>338
>継承も実体化もできるクラスは何と呼ぶのよ

あえて呼べば、抽象クラスと具象クラスが「混在した(mixed)クラス」になる


>継承も実体化もできるクラスは、安易に作るのは危険だが、安易でなければ良いとも思う

>>193はあくまで「原理/原則」のたぐいだから、
それをどこまで現実の開発に適用するかは>>210の問題点に対するリスク管理の判断になる
いいかえると、最初はプログラムが動くことを優先に素早くクラスを設計し、
うまくいかなくなったら「原理/原則」に照らし合わせてレビューする(=設計を見直す)
という大胆なアプローチだってアリだと思う


>その安易さってのが曖昧過ぎるというなら>>283みたいなのもあるワケで

長方形と正方形の継承に関する問題の発見手段として、いくつかの方法論があっていい
ただ、自分は>>283の「リスコフの置換原則(LSP)」よりも、
・集合論を基礎にした継承の定義(>>335)、および
・「抽象クラス-具象クラス」という概念(>>193)
のほうが単純明解ではないかと思う、というだけの話
どちらが分かりやすいかは人によって異なるはずだから、納得できるほうを選べばいいんじゃないかと....
0342デフォルトの名無しさん2014/04/12(土) 05:21:13.13ID:jnsRXNx1
Java,C++やってた感覚としては、mixedって言い方は変な感じがする。インスタンス化もできる時点で、それ普通に具象クラスだと思うのだけれど。
0343デフォルトの名無しさん2014/04/14(月) 15:43:32.63ID:X1Ha03PK
まあ>>250程度のゴミコードしか書けない奴が何を言っても説得力ないんですけどね。
C++は不得意なんだとか言い訳するか？
0344デフォルトの名無しさん2014/04/19(土) 11:32:42.33ID:9DQupnhQ
すでに指摘されている事だけれど、何に使う長方形、正方形かによってクラスデザインが変わってくるのだから、万人が納得する定義はないよ。
0345デフォルトの名無しさん2014/04/23(水) 20:46:31.38ID:RWtzhUZK
オブジェクトの性質を決めるのは、周りとの関係だからな。
オブジェクト単体でどうこう考えるのは誤り。
0346デフォルトの名無しさん2014/04/30(水) 08:23:24.62ID:mWnK1xiU
長方形と正方形だけを考えるなら正方形の継承クラスとして長方形を定義すれば良いと思うんだが。
0347デフォルトの名無しさん2014/04/30(水) 10:51:23.77ID:AM1UNNpg
継承無くてもいいな
0348デフォルトの名無しさん2014/04/30(水) 12:46:10.97ID:vY6pY8oi
>>346
それは一番無いと思うぞ。
0349デフォルトの名無しさん2014/04/30(水) 13:33:39.55ID:mWnK1xiU
>>348
数学的な定義にとらわれすぎだと思う

集合的に見れば、長方形は正方形を完全に含んでるんだから
正方形を基底クラスに選んだ方が無駄も破綻もない。

長方形を継承して正方形を作ろうとするのは、派生クラスで共通では無い要素を持つ基底クラスを定義している事になる。

ふつうに実務的なコードを書くときにはみんなそんな事しないのに、長方形と正方形と言うすごく単純な話になると、変なこと考える子が増える。
0350デフォルトの名無しさん2014/04/30(水) 13:51:36.51ID:E490Ymqi
長方形と正方形を共通のインタフェースで扱いたいなら、
それ専用のインタフェース（あるいは基底クラス）を作るのが妥当だろ。
（言っておくがそれは「四角形インタフェース/クラス」じゃないぞ）

言葉に引っ張られて長方形の都合を正方形に持ち込んだり、
正方形の都合を長方形に持ち込んだりするからややこしくなる。
0351デフォルトの名無しさん2014/04/30(水) 14:32:00.16ID:0tDh1ngs
>>349
？ 長方形の中に正方形が含まれるなら
長方形の基底クラスから正方形という特例だろ
正方形から長方形じゃ継承する意味がないじゃん
0352デフォルトの名無しさん2014/04/30(水) 21:30:39.22ID:Yub+hwyc
この場合の設計って、人に理解しやすいやつを目指してるの？それともリソースを少しでも節約する方針でやっているの？
それによって継承の仕方も変わると思うけど…
0353デフォルトの名無しさん2014/04/30(水) 22:02:28.88ID:NF/fYeus
>>349
じゃあ、長方形クラスのインスタンスを正方形にクラスの変数にいれたらどうなるの？
高さと幅のどっちを一辺の長さにするんだ

>>352
もともと言い出したやつは、条件も目的もまともにあげてない
目的が不明だから、何が正解とも言えない
0354デフォルトの名無しさん2014/04/30(水) 22:37:59.96ID:mWnK1xiU
>>353
どうなるもこうなるも長方形にダウンキャストしない限り長方形特有の機能に触れないだけでしょ。

多態にしたいなら目的に応じたインターフェース切ればよろし。
0355デフォルトの名無しさん2014/04/30(水) 22:51:38.30ID:NF/fYeus
>>354
だから、長方形から正方形にアップキャストしたらどうなるのって聞いてるじゃん

正方形でない図形をどうやって正方形として処理するの
0356デフォルトの名無しさん2014/04/30(水) 23:24:43.69ID:mWnK1xiU
>>355
処理ってどんな処理だ、、、

正方形クラスのインターフェースは触れるし、オーバーライドしてるなら長方形クラス側の実装が走るでしょ。

ていうか、アップキャストしたままで操作するってのは多態なんだから、目的の示されていないこの問題で考えるだけ無駄だよ。
まじめに使用目的を類推したら正方形と長方形で別のクラス定義しなくなるし。
0357KAC2014/05/01(木) 00:02:03.79ID:uGMj/LB5
まず想定する仕様くらいはっきりさせないと。
こんな状態で話してても混乱するだけ。
(まあ、発端の奴が仕様の必要性すら理解してなかったのが原因だけど)

例えば、

　長方形ってのは、高さと幅を自由に設定できる四角形。(その他諸々のメソッドあり。)
　正方形ってのは、高さか幅のどちらかを設定するともう一方にも同じ値が設定される長方形。

と定義したら、クラス構成もどんなメソッドをどうオーバーライドするかもイメージできるだろ？
各自が思っている仕様なんて実はバラバラなんだからまずはその辺を意識するべき。
0358デフォルトの名無しさん2014/05/01(木) 00:12:41.92ID:fTCh8YTW
>>356
オーバーライドに想定するインタフェースを教えてくれないか？
正方形が基底になるケースって、俺は思い付かないんだが、相当特殊なケースだよね？
0359デフォルトの名無しさん2014/05/01(木) 00:17:33.34ID:fTCh8YTW
>>356
すまん、俺が読み違えたわ。
君のその主張だと、ポリモフィズムを考慮するのは(現状の情報だけでは)無駄だって言ってるんだよね？
それは、そもそも継承を論じるラインに立って無いわ。
0360デフォルトの名無しさん2014/05/01(木) 00:50:52.13ID:alUa+e9i
>>356
長方形クラスでできることを再利用するために
それを継承して正方形クラスを作るならわかるが、
正方形クラスを継承して長方形クラスを作った上
正方形クラスとは別に長方形用のメソッド書くってナンダ。

また舞い戻ってきて意味不明な脳内前提で語り始めたか
0361デフォルトの名無しさん2014/05/01(木) 02:04:43.49ID:phibx9jh
>>358
そんなに特殊だろうか、、、
外部から使うときの要件が示されていないから多態は考えない。
でも継承したいらしいから継承はする。
正方形と長方形の重複要素は正方形と一致するので正方形を基底クラスにしたら継承クラス側で無駄なコードを書く必要がない。
↑共通コードを全部基底クラスに置けるから二つのクラスを実装する上でコード量が一番少なくできそうな気がする。
ってだけだよ。

そもそもふつう長方形を扱うクラスを作った上で正方形だけのクラス作る事が有るとも思えないから、用途が特殊と言うより、正方形と長方形で継承関係作ろうとすること自体が特殊だと思うけど。
0362デフォルトの名無しさん2014/05/01(木) 02:09:30.32ID:t/6urRre
> オーバーライドに想定するインタフェースを教えてくれないか？

って>>358は言ってんだから答えてやれよそれを。
0363デフォルトの名無しさん2014/05/01(木) 02:16:10.96ID:alUa+e9i
>>361
オブジェクト指向の大前提である既存のパーツを再利用して
必要な新要素を足して新しいクラス作るんじゃなくて
"全部含んだでっかいもの"を作ったとこから機能削減版を派生させようとしてんの！？
なんだそら
0364デフォルトの名無しさん2014/05/01(木) 02:37:42.98ID:phibx9jh
>>363
逆だよ。
長方形の方が集合として大きいんだから、
長方形を基底クラスにすると正方形にするために削る要素が出るだろ。


>>362
んなまじめに考えてない。
と言うより、幅か高さの片方しか変更できない正方形クラスにもう片方の変更機能を追加するだけで長方形になるでしょう。
それ以外の機能は関係ないよ。なにやろうと共通だし。
0365デフォルトの名無しさん2014/05/01(木) 04:06:25.37ID:alUa+e9i
なにをするクラスの話をしてるのかちょっと説明してみ？
正方形クラスにはどんな要素とメソッドがあって
長方形クラスにはどんな要素とメソッドがあんのよ。
0366デフォルトの名無しさん2014/05/01(木) 04:55:00.26ID:z0bRnMRX
＞長方形を基底クラスにすると正方形にするために削る要素が出る

…出るか？

getWidth()とgetHeight()が内部的に同じ処理になって
setWidth()とsetHeight()が内部的に同じ属性を弄るようになるくらいで
表向きには削るインタフェースは無い気がするんだが…
0367デフォルトの名無しさん2014/05/01(木) 10:05:19.09ID:wxxx//Hr
>>365
まさにそれ。
というよりID:phibx9jhつついても有意義な回答が得られる気配は無いがｗ
OOPなーんもわからんのに聞きかじりでしゃべってないかコイツ。
0368デフォルトの名無しさん2014/05/01(木) 15:50:19.35ID:C2Wy7tu3
>>364
> と言うより、幅か高さの片方しか変更できない正方形クラスにもう片方の変更機能を追加するだけで長方形になるでしょう。
> それ以外の機能は関係ないよ。なにやろうと共通だし。

長方形と正方形がそれぞれ複数個存在するオブジェクトの集合から任意に二つ以上の
オブジェクトを選んで、その幅をそろえたり高さをそろえることを考えると、その設計では
破綻する。
0369デフォルトの名無しさん2014/05/01(木) 23:09:42.01ID:CqnWdcr7
長方形正方形の関係は>>357がわかりやすい
関係を反対にしたら実装も破綻する
0370デフォルトの名無しさん2014/05/02(金) 00:15:29.32ID:6QFg0jzk
>>364
コード出してみなよ
お前の考える仕様の擬似コードでいいからさ
0371デフォルトの名無しさん2014/05/02(金) 00:34:49.86ID:fy5cK8tS
まずは仕様だろ
0372デフォルトの名無しさん2014/05/02(金) 01:28:58.68ID:Nz0HSdS/
オブジェクト指向は再利用がメインではない。
特定の傾向の問題に対して特定の構造のプログラムで
対処すれば処理しやすい、その構造に名前をつけたもの。
基本的にクラス言語を前提として考案されているから
非クラス言語には向かない。
0373デフォルトの名無しさん2014/05/02(金) 02:21:44.11ID:io0T5RUt
正方形は長方形であり、菱型であり、平行四辺形であり、台形でもあり、そしてその他の四角形でもあるわけ。
確かにis-aなんだけれども、派生よりもキャスト演算子を定義する方が適切と思う。
0374デフォルトの名無しさん2014/05/02(金) 02:57:25.60ID:p/4K7Y7n
意味がわからん
コード書いてみろ。破綻するから。
0375デフォルトの名無しさん2014/05/02(金) 08:13:21.47ID:VGttU68Q
正方形 is 長方形
正方形 is 菱形
長方形 is 平行四辺形
長方形 is 菱形…とは限らない
菱形 is 平行四辺形
菱形 is 凧形
菱形 is 長方形…とは限らない
平行四辺形 is 台形
台形 is 四角形
台形 is 凧形…とは限らない
凧形 is 四角形
凧形 is 台形…とは限らない

素直に継承関係にするとダイアモンド継承になるな
流石に長方形is正方形なんていう逆の関係は成り立たないけど

ただ、ちと普通の継承と違うのは非継承関係のものが is NOT とは言えないことか
長方形が菱形である場合もあるし、菱形が長方形である場合もある(それが正方形)
あくまで「…とは限らない」だから
0376デフォルトの名無しさん2014/05/02(金) 08:22:27.69ID:VGttU68Q
http://upload.wikimedia.org/wikipedia/commons/f/f1/Quadrilateral_hierarchy.png

…やっぱ、継承で表現すること自体が無茶そうだなあ
0377デフォルトの名無しさん2014/05/02(金) 08:35:20.24ID:9AvonwzJ
正方形を基底にもつ長方形クラスの仕様 or コードまだぁ？
( ・∀・)っ/凵⌒☆ﾁﾝﾁﾝ ☆
0378デフォルトの名無しさん2014/05/02(金) 11:03:19.10ID:elUB2MyC
>>375
まずは仕様だろ
0379デフォルトの名無しさん2014/05/03(土) 22:09:43.44ID:GmvysJO6
結局、オブジェクト指向をやめる理由はなんなの?
0380デフォルトの名無しさん2014/05/03(土) 22:33:07.92ID:fJ7lFAYg
オブジェクト指向まがいが平然と広まるからだろ
0381デフォルトの名無しさん2014/05/04(日) 04:28:40.66ID:6L9orx0/
いつの間にか継承に関しての問題になってるな
0382デフォルトの名無しさん2014/05/04(日) 10:04:19.65ID:0sFu+rgC
オブジェクト指向は〜とご高説をのたまう人の「オブジェクト指向」は
継承のことだからな。
0383デフォルトの名無しさん2014/05/04(日) 11:50:11.57ID:ph7JBR1/
>>382
それではあなたのオブジェクト指向とは？
0384デフォルトの名無しさん2014/05/04(日) 15:38:01.72ID:kNk/VSFl
聞いてみたいもんだ。
答えられない思うけど。
0385デフォルトの名無しさん2014/05/04(日) 15:39:18.84ID:+QdsA4rP
オブジェクト指向って厳密な定義があるわけじゃなくて、雰囲気みたくぼんやりした存在
0386デフォルトの名無しさん2014/05/04(日) 16:00:33.13ID:Wf2XX2VO
>>383-384
とりあえずWikipediaの「オブジェクト指向」の項にまるっとそのまま書いてあるな。
あと俺が思ってる事も「オブジェクト指向の名称とメッセージング」の項そのまんま。
0387デフォルトの名無しさん2014/05/04(日) 16:44:58.21ID:+QdsA4rP
じゃあ俺は
Object-oriented programming - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Object-oriented_programming

の方を推そうかな。読んでないけど日本語ページとは何か違うｗ
0388デフォルトの名無しさん2014/05/04(日) 16:45:35.41ID:ph7JBR1/
オブジェクト指向は〜とご高説をのたまう人の「オブジェクト指向」は
参考Wikipediaのことだからなｗ
0389デフォルトの名無しさん2014/05/04(日) 16:59:48.58ID:+QdsA4rP
オブジェクト指向プログラミング - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
>オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming, OOP）とは
>相互にメッセージ (message) を送りあうオブジェクト (object) の集まりとしてプログラムを構成する技法である。

Object-oriented programming - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Object-oriented_programming
>Object-oriented programming (OOP) is a programming paradigm that represents the concept of "objects"
>that have data fields (attributes that describe the object) and
> associated procedures known as methods.
訳： OOPとはフィールドとメソッドを持つ"オブジェクト"の概念を表現するプログラミングパラダイムである。

なぜ日欧でこうも解説の方向性がズレるのか。
0390デフォルトの名無しさん2014/05/04(日) 17:04:42.29ID:5zOv7lJS
> Object-oriented programming is an approach to designing modular, reusable software systems.

これで十分だと思うけどな。それぞれのOOPLが持ってる特徴って、
けっきょくんとこ、モジュール性を高めるための手段にすぎないって我思う。
0391デフォルトの名無しさん2014/05/04(日) 18:50:40.60ID:/ciZwNf1
このスレにOO 否定派はまだいるのかな。

肯定派がOO の実践方法について議論してるだけ？
0392デフォルトの名無しさん2014/05/04(日) 18:59:00.14ID:n8bRVLF6
>>391
例えば>>346は反対派のエージェントである可能性が高い。
肯定派がOO議論しているように見せかけているが、実は反対派の高等戦術で、混乱をけしかけている。

…のかもしれないなw
0393デフォルトの名無しさん2014/05/04(日) 19:12:31.99ID:oGtcACYv
否定派ならともかく、反対派っていう捕らえ方はないだろｗ
利害関係の押し引きになってる状況じゃないし。

あと>>346は単にアレと思うよ。
なーんもわかってないのに知ったかぶりたいだけの子。
0394デフォルトの名無しさん2014/05/04(日) 19:53:59.19ID:x5ttWhAX
否定派にはもっと頑張ってほしいね
否定派が立てたスレなんだし
0395デフォルトの名無しさん2014/05/04(日) 20:04:20.86ID:Wf2XX2VO
>>390
おまえみたいにカンチガイしてる奴がいるが"そうではない"
と日英ともはっきり釘を刺す内容になっているわけだが。
0396デフォルトの名無しさん2014/05/04(日) 20:28:48.50ID:1k1MLKr+
結局正方形クンは逃げたの？ｗ
0397デフォルトの名無しさん2014/05/05(月) 17:24:29.69ID:1BHBnJWI
馬鹿は複雑に考えすぎなんだよな
0398デフォルトの名無しさん2014/05/10(土) 05:55:12.43ID:KeiPU5wL
2chも変わったな。昔はアホみたいなオブジェクト指向否定派がうようよいたのに
0399デフォルトの名無しさん2014/05/10(土) 11:16:26.84ID:ig/JFcDb
知らない間にオブジェクトに頼ってることに気づいたからじゃね？
代わりにオブジェクト指向まがいのなんちゃって縛りを強要する輩が増えたけど
0400デフォルトの名無しさん2014/05/10(土) 11:21:00.16ID:CJDkOhBY
オブジェクト指向まがいのなんちゃって縛り？
たとえば？
0401デフォルトの名無しさん2014/05/10(土) 11:25:26.45ID:YjKbVChI
ID導入されたら自作自演が出来なくなるからな。
0402デフォルトの名無しさん2014/05/10(土) 11:33:28.75ID:CJDkOhBY
はぁ？？
0403デフォルトの名無しさん2014/05/10(土) 12:47:25.14ID:WYEbozfr
オブジェクト指向でも出来るだけ不変オブジェクトを使う
設計のほうがバグが出にくくなることに気付いて
実施し続けた結果、関数型で良いじゃんという結論になった
0404デフォルトの名無しさん2014/05/10(土) 14:42:54.64ID:m9xHqVTZ
関数型で全てを書くのはきついので、
オブジェクト指向＋関数型言語が現実的

全体の構造部分にオブジェクト指向を使い
メソッド内の処理の部分に艦型言語を使う。
0405デフォルトの名無しさん2014/05/10(土) 14:47:18.09ID:+MtOT02M
「オブジェクト指向まがいのなんちゃって縛り」って何だよ。
それを「強要する輩が増えた」ってどこの話だよ。意味不明すぎる。
0406デフォルトの名無しさん2014/05/10(土) 15:27:42.00ID:U+Hd/Mih
>>404
関数型言語にも立派なモジュール化機構があるじゃん
なんで全体構造をオブジェクト指向にする必要あんの？
0407デフォルトの名無しさん2014/05/10(土) 15:31:54.57ID:VTwiXu6w
>>398
昔はオブジェクト指向=C++でCを使ってる構造化プログラマと
C++を信奉するオブジェクト指向(？)プログラマが争ってて、
いまはその二者にJavaやObjective-Cプログラマがツッコミ入れてる状態。
0408デフォルトの名無しさん2014/05/10(土) 17:04:28.81ID:m9xHqVTZ
>>406
> なんで全体構造をオブジェクト指向にする必要あんの？
適材適所だから。
0409デフォルトの名無しさん2014/05/10(土) 20:09:36.11ID:U+Hd/Mih
>>408
どう適してるのかを問われてる訳だが
0410デフォルトの名無しさん2014/05/10(土) 20:20:36.73ID:m9xHqVTZ
関数は状態を持たなくてよいが
オブジェクトは多くの場合
状態を持っているから。
0411デフォルトの名無しさん2014/05/10(土) 20:31:34.54ID:08d85pd8
大部分を状態を持たないオブジェクトで構成すればいいじゃん
0412デフォルトの名無しさん2014/05/10(土) 21:28:57.68ID:m9xHqVTZ
それは無理。
実際作るべきもの、アプリの仕様の時点で
状態を持っているのだから。
0413デフォルトの名無しさん2014/05/10(土) 21:37:57.18ID:395PONG4
「関数型プログラミングなんて今すぐやめてください」
というスレになってるかもな、何年後かには
0414デフォルトの名無しさん2014/05/10(土) 21:49:43.51ID:WYEbozfr
状態と処理を分離したほうが
汎用的なコードになるしテストもしやすいんだよなぁ
0415デフォルトの名無しさん2014/05/11(日) 00:09:28.18ID:Gj23aJd4
>>412
アプリの仕様に状態が含まれていても、
それを関数型言語で実装することは可能だよ
もちろん破壊的代入を使わなくともね
0416デフォルトの名無しさん2014/05/11(日) 00:19:47.51ID:5bM6wK/T
汎用性とは無条件に善なるものではない
0417デフォルトの名無しさん2014/05/11(日) 00:45:26.20ID:nsjh45L3
オブジェクト指向ってのは２５年ぐらい前にこのままだとやがて手に負えなくなるから
各モジュールを分離して、その間を人間に理解できる命令でやりとりするように作り、独立性と再利用性を高めようという考え方で
それに対して当時の貧弱なパソコンでプログラムしていたプログラマがそういう『ムダ』なオーバーヘッドをとことん嫌って
「playなんて予約語作んなくても、引数Fが1だったら処理A、2だったら処理Bの方が『効率がいい』じゃん。
いやいや、１バイト８ビットの中で256の状態が表せるからコントロールの１バイトバイナリを送った方が『もっと効率がいい』ぞぉ〜！」
みたいな思考だったもんだからマシンの処理速度が上がってプログラムの規模が巨大化した近年までなかなか普及しなかったわけだけども
もういまでは家電の中身の基盤同士をハンダ付けで結んだりしないのといっしょで、
こういうブロック分け的なオブジェクト指向は揺らぐことのない既定路線になったと思う。
一方で、関数型ってのはどうも上のミニマムなアプローチの発展系で細々した部分で
こうやって書いたら齟齬やバグが少ないぞ！って方向性に見えるので、モジュール内の記述言語としては一定の需要が…あるのかなぁ？
Objective-CがC+smalltalkであるみたいに中身が関数型でモジュールの扱いがオブジェクト指向のなんかが出たりするのかなぁ…
Obj-Cといっしょで関数型信奉者がすげぇキモチワルがりそうだｗ
0418デフォルトの名無しさん2014/05/11(日) 01:00:24.30ID:7C8AQ4Bd
>>417
だから関数型言語にもモジュール化の機構はあるってば
知らんのだったら無理して語るなよ
0419デフォルトの名無しさん2014/05/11(日) 01:00:31.95ID:wc2dKz5b
>>417
25年どころか、1972年にsmalltalkの開発が始まったわけで、概念自体は
それ以前に遡るのですが？
0420デフォルトの名無しさん2014/05/11(日) 01:18:56.47ID:u7IgX1OS
モジュールってかクラスそのものに近いような機構もあるだろ関数型言語でも
0421デフォルトの名無しさん2014/05/11(日) 01:38:37.52ID:9G/k18dk
>>415
仕様が状態であるなら、それをそのまま状態として表現したほうが分かり易いかと
0422デフォルトの名無しさん2014/05/11(日) 01:58:22.11ID:Gj23aJd4
>>421
なにかに置き換えるみたいなことをしなくとも、
そのまま直感的に関数型言語で書けるよ
0423デフォルトの名無しさん2014/05/11(日) 08:33:28.83ID:nnM0cOjj
>>422
じゃあ書いてあるコード見せて
0424デフォルトの名無しさん2014/05/11(日) 12:13:05.16ID:Gj23aJd4
>>423
明示的な仕様であれば、"Unix System Programming with Standard ML" という書籍に
FSM(Finite State Machine, 有限状態機械)そのものを実装したコードがある
このタイトルでググればPDF文書が見つかるから、そのp.43を開けばいい

あと、関数型によるFSMの実装については過去にも議論になっているので、以下を参照
・関数型言語Part5
　http://toro.2ch.net/test/read.cgi/tech/1252470706/491-543
0425デフォルトの名無しさん2014/05/11(日) 13:14:10.10ID:ktmFmLGc
ほらとたんに難しい話になるｗ
完全にオーバースペックなんだよね。

簡単に実装するにはオブジェクト指向が適切なわけ。
0426デフォルトの名無しさん2014/05/11(日) 14:49:19.88ID:Gj23aJd4
>>424程度の話が、>>425にとっては難しいのか....
0427デフォルトの名無しさん2014/05/11(日) 14:51:46.60ID:ktmFmLGc
え？ 難しくないつもり？
英語の時点でアウトなんだけど。

せめて日本語で入門書がでるぐらいにならないと
それは簡単とは言わない。

俺はわかる。じゃなくて客観的な指標で考えようね。
0428デフォルトの名無しさん2014/05/11(日) 15:06:14.00ID:Gj23aJd4
ID:ktmFmLGc は技術英語が読めない

これが客観的評価だろ
0429デフォルトの名無しさん2014/05/11(日) 15:11:31.05ID:Gj23aJd4
ID:ktmFmLGc は "関数型 状態遷移" でネット検索するだけのスキルも無い

これも客観的評価だな
0430デフォルトの名無しさん2014/05/11(日) 15:16:27.42ID:iydoLvGY
あーあ、相手を貶める方向に行っちゃった…
0431デフォルトの名無しさん2014/05/11(日) 15:17:34.57ID:DD3eXZ56
ID:Gj23aJd4 は切れやすい

これが客観的事実であることがよくわかった、
0432デフォルトの名無しさん2014/05/11(日) 15:26:26.03ID:DIiBgHNQ
>>424の例文は要するに再帰だね。Cで書き直すとこうなる。バッファオーバーフローすることをのぞけば大差ない。
int word_count(char* text)
{
　　return out(text, 0);
}

int out(const char* text, int count)
{
　　char c;
　　if (!*text) reutrn count;
　　c = *text++;
　　if (!c) return count;
　　if (!isspace(c)) in(text, count);
　　return out(text, count);
}

int in(const char* text, int count)
{
　　char c = *text++;
　　if (!c)
　　{
　　　　count++;
　　　　return count;
　　}
　　if(isspace(c))
　　{
　　　　count++;
　　　　return count;
　　}
　　in(text, count);
}
0433デフォルトの名無しさん2014/05/11(日) 15:27:12.07ID:M5uHChWE
ID:ktmFmLGcの評価をしてどうするｗ

関数型言語で状態があるものを作るのが
難しいかどうかの評価をしろよ。
0434デフォルトの名無しさん2014/05/11(日) 15:31:58.60ID:DIiBgHNQ
再帰を難しいと思うなら、関数型で状態のあるものを作るのは難しいと思う。
0435デフォルトの名無しさん2014/05/11(日) 15:45:13.40ID:+3tWBSvz
末尾再帰の展開が保障されてない言語で再帰愛用奴ｗｗｗｗ
0436デフォルトの名無しさん2014/05/11(日) 16:10:06.88ID:M5uHChWE
再帰は状態がないだろ？
状態があるものの例になっていない。
0437デフォルトの名無しさん2014/05/11(日) 16:13:21.61ID:DD3eXZ56
>>436
むしろ状態を再帰で定義するんだ
筋金入りの関数型言語派はたしか自然数ですら再帰で定義したがるとか
0 を定義して
1 = f(0)
2 = f(f(0))
3 = f(f(f(0)))　あー、ペアノの公理そのものだね‥
0438デフォルトの名無しさん2014/05/11(日) 16:15:31.92ID:M5uHChWE
無理やり状態を定義するために再帰を使う。
普通にクラスあって、フィールドがあればできることなのにね。
0439デフォルトの名無しさん2014/05/11(日) 18:09:10.88ID:nsjh45L3
とりあえずわかったことは関数型とかいうのは文章で表せなくて
「自明だ」「ググれ」「バーカバーカ」で成り立ってる言語らしい。
0440デフォルトの名無しさん2014/05/11(日) 18:20:26.19ID:zMciFWHi
関数型の方がオブジェクト指向より文章で良さを説明しやすいぞ
再代入禁止でバグりにくいとか、テストしやすいコードになるとか、強い静的型付けでバグを未然に防ぐとか
0441デフォルトの名無しさん2014/05/11(日) 18:45:01.86ID:7C8AQ4Bd
むしろオブジェクト指向の方が
説明が宗教っぽくて「疑うな！信じろ！」になりがちなんだよなぁ
0442デフォルトの名無しさん2014/05/11(日) 18:55:47.09ID:94ZbuLbW
説明が宗教っぽくて？
たとえば？
0443デフォルトの名無しさん2014/05/11(日) 19:01:50.39ID:SNrxmPoy
疑うな信じろ
0444デフォルトの名無しさん2014/05/11(日) 19:22:10.00ID:Ic2gBOwq
オブジェクト指向は英語が読めない
技術者失格レベルの低脳でも
分かった気になれるのが良い点だね
0445デフォルトの名無しさん2014/05/11(日) 20:07:29.26ID:ycVSANCo
まあ、流行った順だろ
0446デフォルトの名無しさん2014/05/11(日) 21:47:18.34ID:cHHoPszx
車を作ります。何からできているでしょうか？

ボディ、シャーシ、エンジン、ミラー、ハンドル、シート、etc

これらがオブジェクトです。
オブジェクトには属性があります。たとえばシートの色とかですね。
あなたが思いつくとおりです。すごく自然です。


さて関数型言語で車を作ります。

サイキガー、サイキガー

・・・無理でしたｗ
0447デフォルトの名無しさん2014/05/11(日) 22:32:20.01ID:/hKFbzvY
オブジェクト指向厨っていつまで経っても
例えのセンスが犬猫クラスから進歩しねーのな
0448デフォルトの名無しさん2014/05/11(日) 23:08:06.97ID:0i/ruqgF
>>446
その車クラスとやらインスタンス化するのに幾ら費用が掛かるのだ？
0449デフォルトの名無しさん2014/05/11(日) 23:10:45.33ID:Gj23aJd4
>>446
関数型で車の静的にモデリングする時、分析/設計の段階、
いわゆる OOA/OOD まではオブジェクト指向と同じ
つまり ボディ、シャーシ、エンジン、etc は関数型でもオブジェクト
オブジェクトがシートの色といった属性を持つことも変わらない
違うのは実装(プログラミング)の段階
関数型だと、上記のようなオブジェクトはタプルやレコードといった直積型を用いる
もしカプセル化が必要であれば抽象データ型を用いる

再帰が必要になるのは動的モデルを実装(プログラミング)する時
つまり手続き型を基礎とする一般的なオブジェクト指向プログラミングでは
ループ(=反復)を用いるけれど、関数型プログラミングでは再帰を用いるという違い

なお、上流工程の分析/設計にオブジェクト指向以外の方法論を採用してもかまわない
たとえば業務システム開発であれば、1980年代頃に普及し今でも活用されている
DOA(データ中心指向)をそのまま用いてもいい
逆に言えば、関数型に最適化されたシステム分析/設計の方法論が確立していないのが現状
0450デフォルトの名無しさん2014/05/12(月) 00:48:00.81ID:gfHEQtpm
>>449
だから、構造はオブジェクト指向で
関数の中だけ、関数型使えばいいってことでしょう？
最初に言ったとおりじゃんか。
0451デフォルトの名無しさん2014/05/12(月) 01:16:34.41ID:tZJrUaMC
>>450
>だから、構造はオブジェクト指向で
>関数の中だけ、関数型使えばいいってことでしょう？

そのとおりだと、(少なくとも自分は)そう思うよ


>最初に言ったとおりじゃんか。

知らんがなw
2chで主張が一貫していると表明したいなら、ハンドルを使わないとね
0452デフォルトの名無しさん2014/05/12(月) 07:59:53.46ID:Bvy5QoIN
関数がファーストクラスのオブジェクトの言語では
値と関数の区別があんまり無いですが、
レコードに関数を含めれば
関数型もオブジェクト指向になりますか？
0453デフォルトの名無しさん2014/05/13(火) 14:06:05.99ID:I3YIR7QR
プロトタイプベースのオブジェクト指向？
0454デフォルトの名無しさん2014/05/13(火) 20:17:18.14ID:hYM/qL6P
オブジェクト指向というとなぜかC++とかの"機能面でのオブジェクト指向"にいくけど
上でもたしか出てたように、JavaとかObjective-Cとかのオブジェクト間を
「これをやれ」というメッセージコマンドで結んで人間にオブジェクト間の関係が
わかりやすいように作るってのが本来の方向なんで
本気でやるならだいぶ違う概念のものを混在させることになるから
(よく概念が違うものが混在して気持ち悪い言われるObjective-C…)
ちょろっと改造して見た目オブジェクト指向的にしましただと
これが新言語haskell++だぁ〜みたいになって空中分解する気がする。
0455デフォルトの名無しさん2014/05/13(火) 20:18:57.48ID:CPtaMwWt
オブジェクト指向がスレッドなど手続きの主体に縛られるのはよくないと思う。
0456デフォルトの名無しさん2014/05/13(火) 21:17:31.39ID:aey4rags
ちゃんとメッセージのやりとりでプログラムを表現できてるのは
Erlangくらい
Smalltalkのはニセモノ
0457デフォルトの名無しさん2014/05/13(火) 21:39:40.55ID:SrU89nrW
>>456
並行オブジェクトという視点だと、ABCL の他、
手続き型では Occam、論理型では Concurrent Prolog や GHC(KL1) がある
マルチパラダイム言語である Oz も対応している

関数型の Erlang は新顔だね
0458デフォルトの名無しさん2014/05/17(土) 21:44:55.40ID:lmWxNHfJ
>>454
機能そのものがオブジェクト指向なのではなくて、オブジェクト指向し易いように機能がある
…ってのは、本来最初に語るべきなんだろうに、どうしても機能の紹介から入っちゃうからなあ
0459デフォルトの名無しさん2014/05/29(木) 10:33:27.73ID:7BbAPvjC
現在のオブジェクト指向の矛盾はクラスからオブジェクトを作ることだろう
本来ならオブジェクトが先にあり、それを型に当てはめる事で共通の処理を行う
クラスよりオブジェクトのほうが大きくなければならないのだ
オブジェクトには動的にいくらでも要素を追加でき
１つのオブジェクトに対し様々な型（クラス）がアプローチする
これが本来のオブジェクト指向のあり方だと思う
0460デフォルトの名無しさん2014/05/29(木) 12:39:01.25ID:ogYYoMo4
先に[オブジェクト指向の矛盾]を説明してくれ
0461デフォルトの名無しさん2014/05/29(木) 12:56:14.55ID:mt7Rzz1h
>>459
＞本来ならオブジェクトが先にあり
＞本来のオブジェクト指向のあり方
「本来」っていう根拠はなに？

オレオレ定義に思えて、オレも納得いかない
0462デフォルトの名無しさん2014/05/29(木) 13:16:14.66ID:/eBjlUzR
>>459
MVCの提唱者であるTrygve Reenskaug氏による、
現在のオブジェクト指向に対する批判とDCIの提唱に通じるものがあり
興味深いですね。

http://d.hatena.ne.jp/digitalsoul/20100131/1264925022
0463デフォルトの名無しさん2014/06/10(火) 23:04:10.32ID:u8Egy4AR
>>459
それなんていうプロトタイプベースのプロパティー？

ｵﾌﾞｼﾞｪｸﾄ指向を状態変数の状態管理みたいに言ったり、

きみらは一体…

ど素人？
0464デフォルトの名無しさん2014/06/11(水) 06:53:46.53ID:rR8zW/BA
javascriptしか知らねーのかよ。おめーこそ素人丸出しじゃねーか
0465デフォルトの名無しさん2014/06/11(水) 20:39:14.45ID:PVL/Hx0I
>>464
ﾌﾟﾛﾊﾟﾃｨｰやプロトタイプベースｵﾌﾞｼﾞｪｸﾄ指向は
javascriptだけの物ではないんだが…

素人にまで知られた言語ではjavascriptが有名だ。
0466デフォルトの名無しさん2014/06/13(金) 19:46:39.56ID:WhAPXXPX
あ、このスレだ。
いま、Swiftのクラスとオーバーライドの説明読んでたら
サンプルがそのまんま「名前付き多角形」って
「名前」というプロパティを持ちメソッドで「説明」返すクラス作って
次にイニシャライザでインスタンス生成時に名前を送る方法
その次に「名前付き多角形」を継承して新しい「正方形」クラスを作って
「辺の長さ」というプロパティと「面積」ってメソッド追加して
説明を返すメソッドをオーバーライドして
正方形の説明返すようにする
オーバーライドの解説…と
>>300辺りから聞き分けのない子と延々やってたネタそのまんまで噴いたw
0467デフォルトの名無しさん2014/06/20(金) 20:19:55.63ID:iTBJxYSd
全てのオブジェクトをグローバルなプールに浮かべて
クエリにかかったオブジェクトを一括処理って感じの言語って無いかな
シューティングゲームで言えば、Enemy毎に処理したり、画面上の全ての
オブジェクトを一括処理したりとクエリによって集団が変わる感じ
コンテナをインターフェイスとして使うイメージって言えばいいのか

座標と移動ベクトルを持ったオブジェクトを列挙して移動させる
みたいなのを１行で記述できたらカッコイイ
0468デフォルトの名無しさん2014/06/26(木) 06:36:05.83ID:XZ5cuq4F
クラスから作るのはインスタンスであって
オブジェクトはクラスの上位概念

って習ったけど矛盾って何？
0469デフォルトの名無しさん2014/06/26(木) 13:44:12.28ID:czaPPBC9
>>459のことなら言葉の使い方が変すぎてよく伝わらないが
なんとなく「いまの車はエンジンとかタイヤとかのパーツから組み立てられてるが
本来は"基本の車"みたいなものがあってそれを改造するのが
正しい姿だとボクは思う」ってんじゃないの。
バイクとかボートとかどうすんだよとか、そもそも
オブジェクト指向なんだから、パーツ組み立てた「基本の車」って
クラス自分で作って再利用すりゃ終わりだろそれとかあるけど。
0470デフォルトの名無しさん2014/06/26(木) 17:52:30.14ID:R3vLWhek
無知なんでプロトタイプベースとどう違うのかわからん
0471デフォルトの名無しさん2014/06/26(木) 19:19:28.33ID:EPphEQd9
オブジェクトという言葉は文脈によって意味が大量にあるから日本語が下手なやつが使うとおかしくなる
04724592014/06/27(金) 08:56:24.73ID:CHZQFB1A
なんて言えば良いのか
オブジェクトは全ての情報を持っていて、クラスはその１面を
表すにすぎないみたいな感じ
全ての情報を予め持たせる事は出来ないから
オブジェクトには後々新しい意味を付加できて、
それによって対応できるクラスが増えていくみたいな

太郎には実は弟が居た ← 兄クラスも適用できるようになった

それだと全てのオブジェクトからクラスで検索掛けられる仕組みがいるかな
0473デフォルトの名無しさん2014/06/27(金) 09:27:30.72ID:CHZQFB1A
オブジェクト=インスタンスの意味で使ってまつ
現実のあり方に合わせたオブジェクト指向っていうのか
物が先にあって、人間による概念を適用することで
そのように扱うことができる、みたいな

ペンを凶器として扱う場合、"先が尖っている"、"手に持てる"
この２つの情報を持っていれば、凶器クラスに当てはめることができる
といった感じで、概念(クラス)の方を柔軟に合わせていくことが出来れば
面白いなと

SQL文みたいな感じでクラス(&値指定)検索をかけて
生成されたコレクションにアクセス、といった感じでプログラムできたら
ものすごいスマートになると思う

シューティングゲームでいえば
HPと座標と短形を持ったオブジェクト(キャラ)と
ダメージと座標と短形を持ったオブジェクト(弾)を抽出して
その２つを当たり判定関数に通す、とか出来たら便利そう

例えが微妙か
0474デフォルトの名無しさん2014/06/27(金) 09:39:26.44ID:+ZczKhMv
オブジェクト指向は愚かな考え。
http://peace.2ch.net/test/read.cgi/tech/1393660194/
0475デフォルトの名無しさん2014/06/27(金) 12:12:45.65ID:v0p75oAp
アタリとかナムコとかのゲーム機では、まさに自機とか弾とかを
オブジェクトと呼んでたんだよね
つまりVCSはオブジェクト指向だったんだよ
0476デフォルトの名無しさん2014/06/27(金) 18:59:19.58ID:Wripzelr
Rubyとか、動的言語ならよくある気がするが
継承などに関係なく、名前で呼び出しができる

すべてのインスタンスを配列なんかにいれておき、メソッドやら変数やらについて関数をわたして絞り込んで新しい配列を作るとかも簡単だぞ

しかし、検索コストが高い。オブジェクトが増えると、マイフレーム抽出を行うのが辛くなるかもしれん
あとは、規模によっては名前の衝突とかも

さらに、ペンを凶器としてつかうのに威力とかの設定が必要になるとあらかじめ用途を考えてるわけで、まずオブジェクトありきとはいかない
0477デフォルトの名無しさん2014/06/27(金) 21:30:44.39ID:BbQZN6SM
>>473
AppleのSpriteKitがそもそもそういう感じだし
知らんけどcocosとか最近のゲームキットはみんなこれ系ちゃうの。
http://d.hatena.ne.jp/glass-_-onion/touch/20140411/1397220091
0478デフォルトの名無しさん2014/07/02(水) 14:25:02.68ID:NrkI7BAW
オブジェクトって対象のことだろ
英文法のSVOのOだろ

ﾄﾙ→ﾃｶﾞﾐ　みたいのがV指向で
ﾃｶﾞﾐ→ﾄﾙ　みたいにするのがO指向

後者式に書くプログラミングだから
オブジェクト指向プログラミングなんだろ
0479桃白白 ◆9Jro6YFwm650 2014/07/02(水) 21:13:44.10ID:TNx19tqM
>>478
オブジェクト指向のオブジェクトは
メッセージを受け取るものだから、Sだよ。
昔はさあ、こう書いてたんだよね。
Take(Taopaipai, Mail)
オブジェクト指向ではTakeというメッセージをTaopaipaiが受け取るようになるんだよ。
Taopaipa.Take(Mail)
0480デフォルトの名無しさん2014/07/02(水) 21:56:42.03ID:sFQ5DsId
ジョークにマジレスすんなよ
0481デフォルトの名無しさん2014/07/02(水) 22:21:51.74ID:NrkI7BAW
Sはないだろ命令文なんだから
VOにするかOVにするかだけ
0482デフォルトの名無しさん2014/07/02(水) 22:22:35.67ID:fO8xTu4u
VO_OV
0483デフォルトの名無しさん2014/07/02(水) 22:23:07.94ID:fO8xTu4u
VOsOV
0484デフォルトの名無しさん2014/07/02(水) 23:28:14.46ID:3GppMyES
オブジェクト指向とは「処理の移譲」です。
Cに代表される構造化プログラミング言語がモジュールを
関数というブロックに分けることによって入力と出力という
ブラックボックスとして扱えるようにカプセル化したのに続いて
オブジェクト指向はオブジェクトに"コマンド"を送る形にすることで
オブジェクトが能動的に振る舞い方を変えることを期待しているのです。

簡単な例としてはRPGの戦闘コマンドを考えてみましょう。
RPGでは戦士>戦う>刀,魔法使い>魔法>炎という風に
明確な指示を与えることで動作を規定できます。
では、もしこれがパーティメンバーが100人、いや一万人いたらどうでしょう？
上位クラスが全員に指示を与えれば一番間違いはないはずですが
上位クラスに末端までの完璧な指示を求めることはおよそ現実的ではありません。
いくつかの階層に分けた上で、具体的ではなく処理と指示が分離した
もっと単純な「戦え」「魔法」や「支えろ」「下がれ」のような
階層ごとのコマンドでオブジェクトが最適と思われる動作を行うようにすれば
コマンドに対する反応の調整という形で問題をそのオブジェクト階層に閉じ込め
また魔法使いパーティと戦士パーティでの同じ「戦え」での振る舞いの
違いを組み立てることができます。

この「コマンドと具体的な処理を分離する」という考え方が
オブジェクト指向の重要なポイントなのですが
"プログラムとは間違いのない完璧な指示を与えて完璧に指示通りに動作させることだ。"
というコンピュータプログラマに刷り込まれた教義とまさに真っ向からぶつかるため
ベテランプログラマであればあるほどなかなか受け入れてくれません。
オブジェクト指向とは"そういうもの"です。
0485デフォルトの名無しさん2014/07/02(水) 23:58:37.86ID:7n8xwuS9
どうせ内部ではthisを第一引数にとる関数に変換されるんだろ？
0486デフォルトの名無しさん2014/07/03(木) 01:50:40.85ID:dV5x+oVa
どうせ仮想関数も内部では switch 文の嵐だろ？
0487デフォルトの名無しさん2014/07/03(木) 06:15:44.20ID:Tr0ANLtY
>>485-456
つまり複雑な内部はコンピュータが生成し、表面（人間が書く所）は
シンプルに見せてくれるのがオブジェクト指向ってこと？
0488デフォルトの名無しさん2014/07/03(木) 07:08:15.42ID:fAvFazkN
それはオブジェクト指向を実現するための手段であって
オブジェクト指向そのものじゃないだろ

操作と操作対象があったら
操作対象の方に着目するのがオブジェクト指向だろ
0489デフォルトの名無しさん2014/07/03(木) 07:14:24.12ID:fAvFazkN
>>484
自動化とオブジェクト指向は関係ないだろ

＞簡単な例としてはRPGの戦闘コマンドを考えてみましょう。
＞RPGでは戦士>戦う>刀,魔法使い>魔法>炎という風に

これ肝心の対象が抜けてるだろ
0490デフォルトの名無しさん2014/07/03(木) 07:19:43.17ID:fAvFazkN
Windowsでいうなら
notepad.exeでhoge.txtを開くのは非オブジェクト指向で
hoge.txtをnotepad.exeで開くのがオブジェクト指向
どっちを基点にするかの問題だ
0491デフォルトの名無しさん2014/07/03(木) 11:46:21.47ID:0tabs9DN
>>487
プログラムするのは人間だからコンピュータがなにかを生成するわけじゃないけど
モジュールに役割と責任を与えることで責任の所在を分離する。

「これを今日中に○○商事まで届けてくれ」というミッションに対して
従来の考え方ではプログラムはあくまで入力を実行する道具(関数)でしかないから
「12:30の電車に乗ってこのルートでここで降りてこの道を行け」という
上層が細かい指示と責任を持つ形式に陥りがちだったものを
ルートと時間はオブジェクトの側で責任を持ち自分で判断するように作ることで
最初の命令に対して「電車が止まってるんですけど…」「道が工事中ですが？」を
上層の命令ミスではなく当該オブジェクトの機能の問題として責任分離(バグの局所化)ができる。

命令を「電車で〜」と上層が手段を指示するのではなく
あくまで目的の「届けろ」と限定することで、「アメリカ支局に」と大幅に
目的地が変更されても上層部の実装は変えずに
モジュール側が飛行機に選んで乗れるようにするだけで済む。
そういうモジュール分離と責任移譲の考え方＞オブジェクト指向

歴史でなにが酷いって、よりによってオブジェクト指向を大々的に名乗ったC++が
ここの部分をムダ要素として切り捨てて単に継承と再利用を
オブジェクト指向の主要素とした言語だったってこと。
JavaとかもっとファンダメンタルなObjective-Cが再発見されるまで
一番大事なとこが伝わりゃしなくてみんなで
そこにはいないオブジェクト指向の意義を議論してたという…
0492デフォルトの名無しさん2014/07/03(木) 12:46:00.10ID:OnssUzad
>>491
長ぇよ。
伝えたい事はシンプルに。
0493デフォルトの名無しさん2014/07/03(木) 12:59:05.93ID:gJnQQam8
なんか脱アルゴリズムの人と同じ臭いがする
0494デフォルトの名無しさん2014/07/03(木) 15:12:44.36ID:CWwdUlLe
いじめられっ子がここにきて苦だ巻いてる
上司のパワハラが原因か
0495デフォルトの名無しさん2014/07/03(木) 19:06:03.25ID:cXWcwOau
長い上に要領を得てない
最近本でも読んで分かった気になった大学生か
0496桃白白 ◆9Jro6YFwm650 2014/07/03(木) 19:44:12.52ID:gqLdubbD
桃白白は興味深く拝読させていただいたけど？
0497デフォルトの名無しさん2014/07/03(木) 20:06:52.13ID:Iy1KPWDv
オブジェクト四股なら強くなれるの？
0498デフォルトの名無しさん2014/07/03(木) 20:31:02.33ID:M7lcZRBS
要はポリモじゃなくて
インタフェースとファクトリを主力にすべきだったって言いたいんだべ
0499デフォルトの名無しさん2014/07/04(金) 06:49:25.50ID:jjVM/fWv
そんな意図じゃないでしょ。単に、データ抽象の概念を知ったか発見したかで感動して、
俺はオブジェクト指向を理解したお前らは理解してないって思い込んでるだけ
0500デフォルトの名無しさん2014/07/04(金) 11:48:48.67ID:GnENWps5
アクターやエージェントの話だとピンとこないやつははっきり言ってダメじゃねぇかな。
0501デフォルトの名無しさん2014/07/04(金) 12:40:21.51ID:uMeOyuJS
オブイェークト
0502デフォルトの名無しさん2014/07/04(金) 15:45:01.48ID:5MCl0kdm
俺だけはわかった病
0503デフォルトの名無しさん2014/07/04(金) 17:37:49.44ID:ISFMNPJd
エージェント指向なんかは命令された目的をに対してエージェントが自発的に目的を果たすのを期待されてるからそっち系だよね
0504デフォルトの名無しさん2014/07/05(土) 12:54:57.14ID:0MkTlugE
多重分類を多重分類のまま扱えるということに意義がある
0505名無しさん＠お腹いっぱい。2014/07/06(日) 04:27:39.52ID:prIPBUwm
名前空間もデータ構造も関数も継承も多相も全て一緒くたになっちゃうんだよね
ばぁっかじゃないの
0506デフォルトの名無しさん2014/07/06(日) 07:11:13.05ID:TqSPj71g
所詮、どれも分類の問題じゃないか
0507デフォルトの名無しさん2014/07/06(日) 15:39:26.60ID:OwUAQaOm
普通にプログラムすると、メモリやメモリ空間を虫食い状態にするからなあ。
オブジェクト指向派は、それを言語仕様のせいではなく、OSに責任転嫁するんだよねえ
0508デフォルトの名無しさん2014/07/06(日) 19:47:33.97ID:PgwRX7N+
>>507
昨日iphone5を再起動した、動かなくなったカメラがまた動くようになった、結局どのOSも似たり寄ったりだねメモリがらみでは
0509デフォルトの名無しさん2014/07/06(日) 21:58:48.05ID:XSnNqaqG
>>507
まさに上で言われてたのはメモリ管理などはOSレイヤに処理を任せて
アプリ側では考えなくてもいい、いやむしろ考えては"いけない"形にしないと
アプリが自分でメモリにちょっかいを出すことでアーキティクチャの違い、変化を吸収できなくて
将来の保守、移植に支障をきたすという類の話なのだが。
0510デフォルトの名無しさん2014/07/08(火) 07:35:17.46ID:KjaCWqA1
>>509
実際にはアプリ側でもメモリ管理をバンバンしているんだがねここ最近は
オブジェクトを解放したからといって、OSにまでそのメモリを返しているわけではなかろう？
0511デフォルトの名無しさん2014/07/08(火) 21:06:44.87ID:M37XHoid
×アプリ側でも
○ライブラリがやってる。
0512デフォルトの名無しさん2014/07/09(水) 04:49:03.36ID:rw7n2XLh
ライブラリとリンクされたアプリがやってるんだろ
動的リンクならギリギリライブラリがやってると言えなくもないが
0513デフォルトの名無しさん2014/07/14(月) 22:44:24.49ID:5duasKc4
iPhone のカメラアプリの動作がおかしくなった‥写真が取れない‥
アプリを再起動してもだめ‥
ふと気がついて iOS 自体を再起動したら直った‥

どこもメモリの断片化を完全に解決できてないんだね
Java も起動して半年もたつと占有したメモリが積もり積もってどうしようもない
0514デフォルトの名無しさん2014/07/15(火) 00:17:27.08ID:N8JfPDs6
iPhone のカメラアプリの動作がおかしくなった‥写真が取れない‥
アプリを再起動してもだめ‥
ふと気がついて iOS 自体を再起動したら直った‥

ネイティブアプリは
メモリの断片化を完全に解決できてないんだね
0515デフォルトの名無しさん2014/07/22(火) 01:37:24.11ID:Ewtf7wqj
i=CInt(S)
i=S.ToInt
2番目のがオブジェクト指向ってやつなんでしょ?
0516デフォルトの名無しさん2014/07/22(火) 20:10:54.95ID:vNYu1ctv
>>515
・着眼点としては良いけど、ちょっと足りないかな
・まず、疑似コードの意味をコメントとして付け加えてみる
　　　i=CInt(S)　　# 関数 CInt へ文字列値 S を適用(apply)する
　　　i=S.ToInt　　# 文字列オブジェクト S へメッセージ ToInt を送る
・この1番目のスタイルは一般に「手続き型」(または「関数型」)と呼ばれ、
　計算モデルとしては「命令型計算モデル」(または「適用型計算モデル」)に分類される
・命令型と適用型とは、副作用を伴うか/伴わないかという違いで区別される
・同様に2番目のスタイルは「オブジェクト指向」と呼ばれ、
　計算モデルとしては「アクタ(actor)計算モデル」に分類される

・1番目のスタイルはオブジェクト指向でも模倣できる
　　　i=CInt.Value(S)　# 関数オブジェクト CInt へメッセージ Value(S) を送る
・ここでアクタ計算モデルでは、命令型に相当する副作用を伴うアクタを「不純アクタ」と呼び、
　関数型に相当する副作用を伴わないアクタを「純粋アクタ」と呼ぶ
・まとめると、「アクタ計算モデル(オブジェクト指向)とは、命令型計算モデル(手続き型)と
　適用型計算モデル(関数型)とを統合した計算モデルである」と言うこと
・結果として適切な言語設計をすれば、たとえば Swift/JavaScript/Ruby のような
　手続き型/関数型も可能なオブジェクト指向言語が存在しうることになる
0517デフォルトの名無しさん2014/07/23(水) 02:12:57.60ID:dhI/c0wJ
うーむ
0518デフォルトの名無しさん2014/07/23(水) 15:46:44.19ID:dhI/c0wJ
オブジェクト指向とわなにか
って問いの答えがわけわかめ
0519デフォルトの名無しさん2014/07/23(水) 20:22:24.00ID:LF1+gxP+
構造体に関数を持たせたら何かをしてくれる機能体として扱えるようになった
それだけ
色んな哲学があるけど全部後付け
0520デフォルトの名無しさん2014/07/23(水) 22:02:19.42ID:tuCyG7DU
俺的には、構造化プログラミング時代に散々苦労してたモジュール化を
言語仕様で簡単に出来るようにしたもの、という理解だな。

例えれば、電気の分野で、抵抗やらコンデンサやらダイオード、トランジスタだけで
無数の配線で繋いで複雑な回路を組んでたのを、class という呪文を唱えるｗだけで
ICチップ化するようなもの。
0521デフォルトの名無しさん2014/07/23(水) 23:19:05.72ID:QSNktYB/
>>519
断じて違う。インターフェースだ。インターフェースが全てなんだ。
0522デフォルトの名無しさん2014/07/23(水) 23:36:44.14ID:Ux3YHclp
>>521
そうは言っても、javaですらテスト用のモックライブラリが出てきたのは
ずいぶん後の下火になってきた時で、全然一般化しなかったわけで。
DIだのAOPだの言ってPOJOｻｲｺｰみたいな状態になってinterfaceを
使うやつなんて時代遅れみたいな空気になったし。 他人と作業をする
場合に一番重要な部分だけど、一番ないがしろにされるよね。
0523デフォルトの名無しさん2014/07/24(木) 04:23:31.75ID:nUCTCIFT
>>519
サブルーチンを関数って言い換えただけだし
データレコードの束を構造体って言い換えただけだから
データレコードとサブルーチンを混ぜたのがオブジェクト指向だよな！
うんうん、きみの住んでる世界の理屈はよくわかるよ！

…なにいってんだおまえ。
0524デフォルトの名無しさん2014/07/24(木) 09:01:24.97ID:yL8JDCTa
何十年経ってもオブジェクト指向とは？って言ってるとは思わなかった
0525デフォルトの名無しさん2014/07/24(木) 18:40:36.19ID:Ty+Ay6iN
>>523
お前が何言ってんだw
0526デフォルトの名無しさん2014/07/24(木) 20:47:43.04ID:f4kjQ3wJ
>>524
そりゃそうだろ。人は入れ替わる。
常に素人は生まれ続けているんだよ。
0527デフォルトの名無しさん2014/07/25(金) 05:01:03.08ID:uaQf20sd
え？
0528デフォルトの名無しさん2014/07/25(金) 05:41:16.27ID:mPXiIZE+
>>526
教育できる人材が生まれてないってことか。
0529デフォルトの名無しさん2014/07/25(金) 13:17:16.12ID:WTL9RIqo
C++とか「え？それオブジェクト指向言語だっけ？」的な
"オブジェクト指向の考えを一部取り入れました"って奴で
オブジェクト指向を理解した！って老人が解説しようとするからな。
>>519とかなんだよw
0530デフォルトの名無しさん2014/07/25(金) 16:17:57.94ID:x483l8C/
>>529
自分がオブジェクト指向を理解してると思うなら、まず、
アラン・ケイのメッセージングのオブジェクト指向と
ビョーン・ストラウストラップの抽象データ型のオブジェクト指向との
違い程度はきちんと把握しておいてほしいもんだ。
0531デフォルトの名無しさん2014/07/25(金) 18:17:29.80ID:xlI8xKYO
で、C++より実用性はあるの？
0532デフォルトの名無しさん2014/07/25(金) 19:15:24.34ID:WTHJyFHk
なにその「COBOLより実用性あるの？」と同じネタ振り
0533デフォルトの名無しさん2014/07/26(土) 04:30:16.73ID:8QVtVKLI
オブジェクト指向に抵抗があるのは、手続き型プログラミングから入って、それが全てと思ってしまい、捨てられないから。
0534デフォルトの名無しさん2014/07/26(土) 07:21:24.42ID:h/TRjXuF
問題はオブジェクト指向(ｷﾘｯとか言ってても、やることは結局細切れで見通しが
悪くなった「手続き」をメソッドだのプロパティだのという欺瞞で以前より沢山作る
はめになって帰って時間が足りなくなってる現実だな…

汎用性がどうとかで使いもしないメソッドやらプロパティやらを沢山作らされるのって
楽しいの？
0535デフォルトの名無しさん2014/07/26(土) 07:41:31.07ID:hR2xQUcF
結局、引数の数が減る代わりに、オブジェクトが増えるだけ
0536デフォルトの名無しさん2014/07/26(土) 08:37:29.62ID:dtlUMapw
メモ帳で書いた１ページのスクリプトでも
サブルーチンがあったりしたらそれだけでオブジェクト指向
0537デフォルトの名無しさん2014/07/26(土) 10:17:47.43ID:61LWZQBw
抽象､愚像､分類
0538デフォルトの名無しさん2014/07/26(土) 13:38:39.48ID:h+FgCzMo
手続き型の延長がオブジェクト指向
0539デフォルトの名無しさん2014/07/26(土) 18:18:05.60ID:LrvxXizj
汎用性が〜使い回しが〜ってのはC++の時に宣伝された
典型的な「なんちゃってオブジェクト指向」だなw
オブジェクト指向のポイントはそんなところではなく
モジュールを機能で切り分けて最も単純な命令のやりとりで
モジュール間の通信が済むように作ることでモジュールの独立を担保し
モジュールの変更が他へ波及しないことを保証することだから。

おまえはこれに責任を持つクラスだ。という形で単純に切り分けられないなら
別にそこはそういうグループとしてモノリシックに作ってもいいし
独立のための通信の単純化が目的なのだから
作ったり治したりの度にインターフェースが増えるようなのは
典型的ななんちゃってオブジェクト指向だそりゃ。
C++でオブジェクト指向もどきを囓った>>534みたいな手続き型プログラマがよくやってるやつなw
0540デフォルトの名無しさん2014/07/26(土) 22:50:03.47ID:h/TRjXuF
うむ、まあ理想的で美しいプログラムを作るだけなら、それ>>539 でいいんだが、
現実は厳しいんだよ…
納期通りに要求通りの機能を発揮するソフトウェアを作らなきゃならないからね…
0541デフォルトの名無しさん2014/07/27(日) 04:45:32.11ID:76uDopVH
これが老害か…
0542デフォルトの名無しさん2014/07/27(日) 05:09:06.19ID:4s/XWePC
>>540
納期そのままで変更要求だけ来るからこそのオブジェクト指向なのでしょう。
0543デフォルトの名無しさん2014/07/27(日) 06:17:31.89ID:wsh1VGaY
オブジェクト指向とモジュール独立はそれぞれ別々の要素だろ

オブジェクト指向性の言語がそうなってることと
オブジェクト指向そのものはまた別の話だろう

何で意図的に混同するやつ多いんだろうな
0544デフォルトの名無しさん2014/07/27(日) 06:28:04.23ID:rpr4QuL8
多重分類を解決できないオブジェクト指向なんてゴミ
0545デフォルトの名無しさん2014/07/27(日) 06:36:25.23ID:4s/XWePC
独立かどうかではなく、出現するオブジェクトをそのままプログラミングしているから、仕様変更で困ることが少ない。これがわからない奴は、オブジェクト指向といいつつ機能的分類をしている可能性が高い。
0546デフォルトの名無しさん2014/07/27(日) 08:17:36.56ID:agU5E6e7
現実では仕様変更なんてのは、想定外のことがほとんどだから
どんなに綺麗に設計できていても、苦労すること多いんだけどね。
想定できる仕様変更に対応して設計した時点で、その変更は仕様内になる。
0547デフォルトの名無しさん2014/07/27(日) 10:15:17.98ID:wsh1VGaY
>>545
それはオブジェクト指向とは関係ないだろ
0548デフォルトの名無しさん2014/07/27(日) 10:35:32.01ID:4s/XWePC
わかってないのが2名。
0549デフォルトの名無しさん2014/07/27(日) 11:51:41.71ID:wsh1VGaY
わからないなら素直にわからないと言えば教えてやるのに
0550デフォルトの名無しさん2014/07/27(日) 11:56:29.10ID:qQkKtguE
>>539
煽り口調はともかくｗ
OOPのポイントを自分の言葉で説明しようとする心意気は評価したい。
そんで、モジュール性についてまっさきに押さえたセンスも評価したい。
0551デフォルトの名無しさん2014/07/27(日) 13:26:38.94ID:cbICNF91
Cから"オブジェクト指向"のC++へって時に
Cをやってたプログラマは既存の"関数による構造化"で
自分たちの世界でのモジュール化は済んでると思ってたんだよ。
だからC++で売りになってくるのがクラスの汎用性と使い回しだったという。
そして、その程度のことならオブジェクト指向なんていらない！となるという…

実際は関数とオブジェクトは思想からして異なる次元のもので
夕飯を食べたい時に"関数"だと機能単位の切り分けが
関数の特徴である入力から出力の関係で『夕飯(松屋の牛丼)』と
オーダーを送信する形で、命令側が明確に指示をする形態になりがちで
オブジェクト指向の『奥さん［夕飯］』とは役割の切り目の発想が全く異なるという。

転勤で松屋がなくなったとき前者では修正しなければならないのは
オーダーの形で命令を出してる全モジュールだ。リストは命令者が持ってるんだから。
でも命令->結果の単純さに慣れた人は
「そこはオブジェクト指向で『奥さん［夕飯:松屋の牛丼］』としようよ」と言っても
「なんで？夕飯(松屋の牛丼)の方がシンプルじゃん！」と言い張る…
"奥さん"が責任を持つことで
奥さん［なにができるの］でリストを返したり
アメリカ行こうがインド行こうが奥さん［夕飯］で飯が出てくる
責任と修正を"奥さん"に局所化できる。
そこがポイントなのに伝わらないというね…

「夕飯ってメソッドでいろんな食べ物が出てくるのがポリモーフィズムって奴だろ。知ってるよ！」じゃねーっつの。
切りわけで自然に出てくるあたりまえのことなんだよ、そのへんわ
0552デフォルトの名無しさん2014/07/27(日) 13:44:33.41ID:fsjRbqzy
こういう勘違い君が多いのがオブジェクト指向信者の特徴だね
たいていC++が（純粋な）オブジェクト指向言語と思い込んでる
0553デフォルトの名無しさん2014/07/27(日) 13:58:28.06ID:OxWVtzKf
>>552
お前はもう発言しないほうがいいな。
俺がなぜそんなことを言うのか分からないだろうけど。
0554デフォルトの名無しさん2014/07/27(日) 14:02:49.73ID:gd2hQW68
人によって意見がバラバラすぎるのが致命的ｗ
0555デフォルトの名無しさん2014/07/27(日) 14:59:00.61ID:kK8gelhu
>>554
それは神の定義のことか？
0556デフォルトの名無しさん2014/07/27(日) 15:12:57.08ID:ZiDdulSZ
>>551
完全に同意
0557デフォルトの名無しさん2014/07/27(日) 15:50:22.49ID:rpr4QuL8
で、その素晴らしいオブジェクト指向を実装してる言語を教えて下さい。
0558デフォルトの名無しさん2014/07/27(日) 17:55:37.61ID:wsh1VGaY
>>551
その例だとオブジェクトは奥さんじゃなくて夕飯かあるいは牛丼だろ
0559デフォルトの名無しさん2014/07/27(日) 18:07:56.01ID:930xxhbD
なんで定義が混乱してるのかわかったよ。
モデルとクラスは別の概念だが、どちらもオブジェクトだという事がわからないんだろ。
0560デフォルトの名無しさん2014/07/27(日) 18:15:12.04ID:wsh1VGaY
>>559
「その例だと」って言ってるだろ
奥さんなんてどこにも居なかったものが
いきなり出て来てるじゃねーか
0561デフォルトの名無しさん2014/07/27(日) 18:18:50.18ID:930xxhbD
>>560
俺が言ってるのは「その例」に限った話ではないが、
「その例」で言えば奥さんはクラスオブジェクトだ。
0562デフォルトの名無しさん2014/07/27(日) 18:20:34.16ID:wsh1VGaY
どちらにしろ奥さんはオブジェクトというよりはサブジェクトだろ
0563デフォルトの名無しさん2014/07/27(日) 18:24:04.62ID:930xxhbD
サブジェクトもオブジェクトじゃんかw
サブジェクトとオブジェクトは違うものなのか？
0564デフォルトの名無しさん2014/07/27(日) 18:32:32.63ID:wsh1VGaY
オブジェクトにもなりうるが
その例の場合はサブジェクトだろ
0565デフォルトの名無しさん2014/07/27(日) 18:36:42.10ID:rpr4QuL8
・・・これが哲学か
0566デフォルトの名無しさん2014/07/27(日) 18:40:13.78ID:wsh1VGaY
>>551の例がおかしいのは
オブジェクト指向ではない例の方で
奥さんなんて一言も言及れてないのに
オブジェクト指向の例とする方には
どこからともなく奥さんが現れてることだろ

対比しようとしてるくせに
論点以外の部分がまるで変わってしまってるんだよ
0567デフォルトの名無しさん2014/07/27(日) 18:44:24.12ID:ZUBJK7Xm
ここまでの話の流れをまとめると：
・可愛くて優しくて寛容な奥さんがいれば、すべては丸く収まる
というのが、オブジェクト指向の真理である

もうこれでいいんじゃないの？
0568デフォルトの名無しさん2014/07/27(日) 18:53:16.67ID:wsh1VGaY
奥さんに何でもやらせようとするなら
それはサブジェクト指向だろ
0569デフォルトの名無しさん2014/07/27(日) 19:23:49.88ID:hIbqMMii
おまいら2次元の嫁に夢見すぎるなよ
0570デフォルトの名無しさん2014/07/27(日) 19:29:12.38ID:szzhZjwg
>>566
「ゼロなんてなにもない数が出てくるのおかしいだろ」って
エキサイトしてる未開な土人を眺めてる感じです。キミ
0571デフォルトの名無しさん2014/07/27(日) 19:46:35.12ID:wsh1VGaY
>>570
それで何か指摘したつもりなのか？
なら551で省略した奥さんを登場させてみろよ
0572デフォルトの名無しさん2014/07/27(日) 19:48:23.52ID:ZUBJK7Xm
>>557
命令型計算モデル(手続き型言語)/作用型計算モデル(関数型言語)/
アクタ計算モデル(オブジェクト指向言語)という代表的な計算モデル(>>516)、
それらすべてが融合したプログラミング言語を一つだけ挙げるとすれば、
それは Oz(オズ) とその処理系である Mozart(モーツァルト) だな

ただし、Oz は計算モデル(もしくは計算そのもの)を学習を目的に設計された言語になる
もしも実用性で選ぶなら、その第一候補は Ruby だろう
Ruby はオブジェクト指向を中心に三つの計算モデルがバランスよく設計されている
（ただし Oz と比較すれば、Ruby には並行性と制約の概念が欠けている）
0573デフォルトの名無しさん2014/07/27(日) 19:52:54.23ID:n45f7OkJ
なぜ出てきたのかの意味がわかってない時点で
オブジェクト指向の考えかたそのものを理解できてないのがまるわかりなので、
それ以上口を開かない方があなたのためかと。
失笑されてますよ。
0574デフォルトの名無しさん2014/07/27(日) 19:55:07.20ID:n45f7OkJ
>>557
んじゃ俺はSwift
まだベータだけど
0575デフォルトの名無しさん2014/07/27(日) 20:17:16.34ID:wsh1VGaY
具体的なこと言うわけでもなく
おまえはわかってない
だもんなｗ

まあ定番だが
つまらない決着だったな
0576デフォルトの名無しさん2014/07/28(月) 00:55:58.44ID:MwQcMhyW
広辞苑や国語辞典みたいな普通の辞書の
オブジェクト指向
という単語にわなんという説明文を書いて本屋で発売すべきなんだぜ?
0577デフォルトの名無しさん2014/07/28(月) 01:25:00.22ID:5RBLx+nV
>>576
すぐブームで廃れたプログラミングスタイル
勘違いによる一時的な流行
0578デフォルトの名無しさん2014/07/28(月) 07:34:30.55ID:9L8umOkN
プログラミングスタイルに限らんだろ
オブジェクト指向はもっと広範囲の言葉だ
0579デフォルトの名無しさん2014/07/28(月) 08:39:02.39ID:XR3nwuS9
うわぁ
>>551の完全勝利じゃんか
0580デフォルトの名無しさん2014/07/28(月) 18:22:46.97ID:FHFsPlLG
>>576
物を中心とする考え方。
0581デフォルトの名無しさん2014/07/28(月) 20:14:33.43ID:9L8umOkN
物じゃなく目的
0582デフォルトの名無しさん2014/07/28(月) 20:15:46.64ID:9L8umOkN
物じゃなく目的あるいは対象
0583デフォルトの名無しさん2014/07/28(月) 20:29:25.19ID:wmXh8pjD
中心がいっぱいだな
0584デフォルトの名無しさん2014/07/28(月) 20:51:01.56ID:5nKHcVaS
言ってしまえば仕事をする単位をひとつひとつの「手続き」ではなく
それを実際に行うユニット、いわばひとつのロボットとみなして
そのユニットに「これをやれ」と命令する形にする考えかた。

独立して行動できるひとつのオブジェクトとして機能がまとまっているので
ユニットをコピーして命令に対する振舞いを変えることで
ユニットを一から作り直さず新しい環境で再利用できる。
0585デフォルトの名無しさん2014/07/28(月) 20:59:02.73ID:5nKHcVaS
あたりまえの話もしておくと
ユニットを独立させるということはつまりユニット同士を相互通信のための
共通インターフェイスでラップするってことでその手間がかかる。
「この変数に2が入ったら再生でいいじゃねぇか」で済むところには別にいらない。
もし、後で他の人が「おい、この2ってなんだ！？」って
ソースを追う羽目にならない場所なら。
0586デフォルトの名無しさん2014/07/28(月) 21:45:52.59ID:+JNLoSEV
>>585
このひと、殆どソフト書いたこと無いと思う
0587デフォルトの名無しさん2014/07/28(月) 22:12:32.38ID:0o8pZv/S
ソ、ソフトを書く？？
0588デフォルトの名無しさん2014/07/28(月) 22:37:02.81ID:RMFuHAU+
>>585
そしていまどきそんな場所ないという
0589デフォルトの名無しさん2014/07/30(水) 13:09:30.31ID:q1vJpBfq
抽象からオブジェクト(物)
抽象から物(分類)が定量的に移行できないので混乱が生じる
定量に分類ができればかなり進歩する

オブジェクトができる前は抽象
0590デフォルトの名無しさん2014/07/31(木) 01:30:11.29ID:8AYf8Uja
VBのどこがオブジェクト指向じゃなくて
VB.NETのどこがオブジェクト指向なんだ?
0591デフォルトの名無しさん2014/07/31(木) 21:09:44.94ID:/7D094q1
愚問
スパゲティー
構造
オブジェクト

言語がサポートの有無ではない
0592デフォルトの名無しさん2014/08/02(土) 18:54:30.25ID:F01bnSdJ
これだけ経っても正しい理解、自然な理解が進まないオブジェクト指向ってのは
どうも人間の思考に合っていないんだろう
これだけでやめた方がいいってのが分かるな
0593デフォルトの名無しさん2014/08/02(土) 19:01:05.81ID:nYoZZETJ
こんなアホでもわかるパラダイムが理解できないなら、そりゃやめた方が良いw
0594デフォルトの名無しさん2014/08/02(土) 19:03:04.00ID:UBZX0AEK
>>593
同感だ
>>592はプログラマには向いていないから、やめたほうがいいな
0595デフォルトの名無しさん2014/08/03(日) 03:39:58.40ID:DS04efrI
普通のオブジェクト指向言語でプログラミングすりゃ
言語がそう作られてるからオブジェクト指向が理解できないとかないわな。
もう昔からはっきりしてんだよ、C++のCの部分しか使えないCプログラマが
「C++とかよくわからん」ってのを「オブジェクト指向とかよくわからん」って言ってるだけ。
0596デフォルトの名無しさん2014/08/03(日) 04:14:52.53ID:Uv66z7PH
下手に経験があって既存の考え方を捨てられない奴にオブジェクト指向は無理だと思う。
面接とかでは経験ないやつの方を注目してる。
0597デフォルトの名無しさん2014/08/03(日) 05:07:24.99ID:mR2YdfRl
C++なんて失敗作は風化して消えるのを待つだけじゃないの？
0598デフォルトの名無しさん2014/08/03(日) 10:03:42.66ID:9lKcUiz4
C++は増改築を繰り返した歪マンションみたいなもんだしな
0599デフォルトの名無しさん2014/08/03(日) 10:45:11.51ID:bgy2DICk
何このC++扱えない奴の僻みはｗｗ
0600デフォルトの名無しさん2014/08/03(日) 11:08:23.08ID:gUp0rt3Y
>>599
そういう裸の王様みたいな煽りが効かないくらいC++はオワコン
0601デフォルトの名無しさん2014/08/03(日) 11:41:24.68ID:vX8Sn0xO
まぁLINUX作った某変態もC++嫌いらしいからいいんじゃね？
ところで、もちろんおまいらも某変態級の知識・技術・実績を持っているのだろうな?
0602デフォルトの名無しさん2014/08/03(日) 12:32:54.45ID:ppjITjjs
そもそもC++まともに使えるチーム組むのが至難の業
0603デフォルトの名無しさん2014/08/03(日) 13:52:58.06ID:Uv66z7PH
オブジェクト指向は設計者だけわかってれば、実装者はあまりわかってなくても大丈夫。ってものじゃないのか。

逆に中途半端なやつが集まって設計をバラバラにするのが問題。ってならわかるけど。
0604デフォルトの名無しさん2014/08/03(日) 16:09:56.41ID:DS04efrI
C++はオブジェクトの単位がCの関数と変わらないから
その単位サイズで再利用だの保守性がーだの
オブジェクト指向の部分いるの？関数でいいんじゃねぇの？って
C++プログラマ含め全員がツッコミ入れた言語だからな。
そして、その記憶のままC++入れたツッコミを
「他のオブジェクト指向とかいうのもC++で勉強したみたいなのだろw」って
口から糞吐いちゃうから笑われる。
0605デフォルトの名無しさん2014/08/03(日) 16:29:48.10ID:GEfN9hSG
C++はオブジェクトの単位がCの関数と変わらない？？
0606デフォルトの名無しさん2014/08/03(日) 16:36:07.25ID:dLfJVniE
このスレを見ていると>>592は正しいと実感するな
0607デフォルトの名無しさん2014/08/03(日) 16:40:31.74ID:mR2YdfRl
>>593
ほらな
593-605までの短い流れにおいてでさえオブジェクト指向のポリシー理解されていないってのがよく分かるだろ
ここから導き出される結論は一つ。
10年以上だってもポリシーが統一できないようなオブジェクト指向なんて妄想は必要ない
むしろ害悪
0608デフォルトの名無しさん2014/08/03(日) 16:53:40.63ID:ZOk/dYXC
オブジェクト指向ですらこんなのなんだから、相対性理論とか完全に誤りだよな、古典物理学で十分
0609デフォルトの名無しさん2014/08/03(日) 17:33:25.69ID:mR2YdfRl
相対性理論は難しい理解できないんじゃなくて、
おおざっぱな古典物理で十分って人が多いから学ぶ人がいないただそれだけ。
0610デフォルトの名無しさん2014/08/03(日) 17:53:08.62ID:9Z+hWjys
C++は難しい理解できないんじゃなくて、
おおざっぱなjsで十分って人が多いから学ぶ人がいないただそれだけ。
0611デフォルトの名無しさん2014/08/03(日) 17:57:25.61ID:mR2YdfRl
オブジェクト指向とC++と相対性理論が一緒の物と思っている人まで出てきた。。。
馬鹿がPGやるのかPGやると馬鹿になるのかどっちだろう。。。
頭痛くなってきた
0612デフォルトの名無しさん2014/08/03(日) 18:44:12.58ID:bgy2DICk
ま、本格的なソフトの殆どがC++製なんだけどね
0613デフォルトの名無しさん2014/08/03(日) 18:52:49.68ID:WserZ6Ei
オブジェクト指向がわからんって人は、GUIを書いた事が無いんじゃないかな。
オブジェクト指向じゃない場合、イベントドリブンとかマルチスレッドとかどうすんの？
0614デフォルトの名無しさん2014/08/03(日) 19:10:04.90ID:1mBJTexV
>>613
えっ？


えっ？？
0615デフォルトの名無しさん2014/08/03(日) 19:41:29.75ID:DS04efrI
イベントドリブンもマルチスレッドもわからない…とφ(。。)メモメモ
0616デフォルトの名無しさん2014/08/03(日) 21:35:42.36ID:JoWxOlUb
>>613
イベントドリブン‥‥デバイスドライバがそんな感じだったね、あれってCで十分だと思うけど
マルチスレッド‥‥ProgramCounter と StackPointer だけ独立、と理解すれば OO とかとは関係ないし
0617デフォルトの名無しさん2014/08/04(月) 01:51:04.70ID:8BPE65mf
メソッドでオブジェクトの内部状態を変えるってスタイルと
マルチスレッドって、相性最悪なんだけどな。
それこそ、塩素系漂白剤と酸素系漂白剤を混ぜる、てぐらいに。
0618デフォルトの名無しさん2014/08/04(月) 02:37:41.14ID:tfxLBnhp
ジングルスレッドで順次動作が基本の世界に住んでりゃそりゃ
「マルチスレッドで各スレッドが独立で動作したらどうなっちゃうの！？」なんて
"A=A＋1はおかしい"レベルの疑問も出るだろうねぇ…
プププ
0619デフォルトの名無しさん2014/08/04(月) 03:28:31.38ID:tnMe/Qjc
>>617
そんな例でなくて比較対象を挙げろよ。
0620デフォルトの名無しさん2014/08/04(月) 03:43:11.87ID:FTKXgVcb
オブジェクト指向とオブジェクト指向型言語を混同してるやつだらけだな
0621デフォルトの名無しさん2014/08/04(月) 03:52:18.66ID:BMEUu4x5
オブジェクト指向最大のメリットはこのお題目を唱えることで仕事が増え
それで飯を食っていける人が養えることだろうな
あとはスケープゴートに出来ること
0622デフォルトの名無しさん2014/08/04(月) 05:12:19.12ID:Ws6nXj1D
>>607
10年どころかsmalltalkが出来たのが1960年代後半なわけで、論文的な概念が
出来上がったのは更に前になるわけで、そろそろ半世紀経つんだけどな。

学校で教えてくれるかと言えばそうでも無いのだが、結局のところ独学でちょろっと
したものが作れて、それ以上の知識をインプットしない人が大半なのが原因として
大きいんだろうな。リーマンプログラマーなんかも大半が最初の1、2年の知識で
止まってるのが多いし。
0623デフォルトの名無しさん2014/08/04(月) 09:15:51.63ID:deaXHLqi
>>617
メッセージならむしろマルチスレッドじゃない方が違和感があるよね
やっぱC++をオブジェクト指向としたのが混乱の原因だよなあ
0624デフォルトの名無しさん2014/08/04(月) 09:21:15.13ID:fE3w101w
>>623
その意味ではSmalltalkでもダメだけどな
0625デフォルトの名無しさん2014/08/04(月) 11:15:32.28ID:yw9wsgd+
>>623-624
アラン・ケイの言うオブジェクト指向における「メッセージ」はイメージしやすくするための喩えで
ケイのメッセージングのオブジェクト指向のキモは可能な限りの「遅延結合」にあります。
http://d.hatena.ne.jp/katzchang/20080807/p2

メッセージで遅延結合をイメージできる程度に処理系が柔軟性を持っていればいいので
実際にマルチスレッドや分散処理である必要はありません。もちろんそうであることを
妨げるものではありませんが。

メッセージが実際にやりとりされるかどうかということより大事なのは、
これから起こるすべてに対応することは難しいので、処理系を含めていろんなものを
メッセージを介した遅延結合にして柔軟に、機能を増やすよりメタ機能を、という主張です。
http://metatoys.org/oxymoron/oxymoron.html

ここらへんが後述の特に静的型で多くを定式化した抽象データ型のオブジェクト指向とは
相容れないところです。（ただ、目指すところを実現可能なら静的型だってかまわないとも
言っています。為念）

彼の「動的大事」の考え方に基づいて作られた Smalltalk は言語処理系としてかなりがんばって
あらゆる部分が動的に改変可能なように作られているめずらしい言語処理系になっています。
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

ただアラン・ケイはけっして満足はしていなくて、せいぜい他よりははるかにマシという程度にしか
思っていません。だから「Smalltalk はもう愛していない」とか公言してはばからないわけですが
それを Ruby の作者に Ruby の宣伝に使われてしまってなんだかなーとなったりするわけです。
http://www.rubyist.net/~matz/20060608.html
0626デフォルトの名無しさん2014/08/04(月) 11:16:47.61ID:yw9wsgd+
>>622
細かい事ですがケイは彼のメッセージングに関するオブジェクト指向についてはその暫定実装として
Smalltalk を 70年代に作って実践して示しただけで、論文にはしていません。もっとも初期でも
1972年の有名なダイナブック構想の論文にちらっとアイデアが記述されている程度です。
（ちなみに Smalltalk はその「ダイナブック」の暫定OS でもあります）。
http://swikis.ddo.jp/abee/74


あとケイのメッセージングのオブジェクト指向と混同してはいけないのが
ビョーン・ストラウストラップの抽象データ型のオブジェクト指向で、
これがいわゆる現在主流の「カプセル化・継承・ポリモーフィズム」というやつで、
1980年代に C++ の言語機能を模索するうちに整えられた考え方です。
Smalltalk も参考にした SIMULA67 という言語にあった「クラス」という機能を
用いて、抽象データ型（簡単に言うとユーザー定義型）と継承による
差分プログラミングを可能にする、というのがそのアイデアのキモになっています。
http://www.stroustrup.com/whatis.pdf
0627デフォルトの名無しさん2014/08/04(月) 16:32:30.91ID:8BPE65mf
>>623
アクターか。謳い文句への準拠度ではアクターが一番オブジェクト指向ぽく聞こえるけど
世間一般で言うオブジェクト指向 = アクターじゃないしな。
0628デフォルトの名無しさん2014/08/04(月) 19:06:10.75ID:aUVB7g/o
むしろ、現在主流言語の一角を占めるJavaや
iPhoneなどのiOSプログラミングで再発見されたObjective-Cとかで
アクターモデルから自然に導かれる概念としてのオブジェクト指向から
みんな入ってくるようになっているので
＞「カプセル化・継承・ポリモーフィズム」というやつ
がオブジェクト指向のコアだと思ってる老人の方がいまでは少数派で
話が噛み合わないのだと思うよ。
0629デフォルトの名無しさん2014/08/04(月) 19:49:12.56ID:sGQHSPwD
>>628
> アクターモデルから自然に導かれる概念としてのオブジェクト指向

これまた細かい話なんですが、カール・ヒューイットのアクターモデルのほうが
Smalltalk（当時 Smalltalk-72 ）のメッセージングを参考にして組み立てられたので
逆ですね。
0630デフォルトの名無しさん2014/08/04(月) 20:15:08.02ID:CJ83fxk4
>>628
・Java は(>>626 でいう)ストラウストラップの流れをくむオブジェクト指向であり、
　特徴としては「静的型付けかつ静的メソッド束縛」になる
・対してObjective-C は Smalltalk の流れをくむオブジェクト指向であり、
　特徴としては「動的型付けかつ動的メソッド束縛」になる
（「動的メソッド束縛」は >>625 でいう「メッセージを介した遅延結合」を指す）

全く異なる方向性の２つの言語を例に挙げて「自然に導かれる概念としてのオブジェクト指向」とは、
いったい何を言いたいのか意味不明だよ
本人は分かったつもりでいるけど、他人からすれば脱アルゴリズム宣言」と同様の妄想にしか聞こえない
「自然に導かれる概念」みたいな曖昧な言葉ではなく、
自分の言葉でオブジェクト指向を語るべきではないのかと思われる
0631デフォルトの名無しさん2014/08/04(月) 20:20:26.56ID:CJ83fxk4
>>629
ヒューイット氏本人が Smalltalk から着想のヒントを得たと
明言している、有名な話だね
0632デフォルトの名無しさん2014/08/04(月) 20:30:47.01ID:HvBJftQR
>>630
むしろJavaがそういうものだと思ってる時点で
君が辞書の言葉を暗記してるだけでなにも理解してない
「自分の言葉」がない人間にしか見えない。
0633デフォルトの名無しさん2014/08/04(月) 20:36:50.25ID:nzHcBkcu
ルーツはもうどうでもいいからメリットはよ。
0634デフォルトの名無しさん2014/08/04(月) 20:42:27.79ID:5WIeoEaO
>>631
ただヒューイットは Smalltalk-71 と -72 とを勘違いしていて、
http://permalink.gmane.org/gmane.comp.lang.smalltalk.fonc/2697
アクターは Smalltalk-71 を参考にしたと言っていることが多いので
それを信じてそのまま書いてある書籍が多いので要注意です。

ちなみに Smalltalk-71 は仕様のアイデアだけの実装がない処理系で、
Smalltalk-72 と違ってメッセージングはドグマではないうえ、
ケイはヒューイットの PLANNER を参考にアイデアを練ったので
これまた Smalltalk がアクターから派生したかのような記述を
サポートしてしまうという、ややこしいことになっています。
0635デフォルトの名無しさん2014/08/04(月) 20:43:53.45ID:Eu05eWV/
オブジェクト指向は構造化プログラミングの延長にあるので、
オブジェクト指向のパラダイムは構造化プログラミングを全部内包している。
これはあってますか？
0636デフォルトの名無しさん2014/08/04(月) 20:51:46.07ID:CJ83fxk4
>>635
「オブジェクト指向は構造化プログラミングの延長にある」という前提そのものが
>>626 のストラウストラップ流オブジェクト指向の発想だね
言い換えると、ストラウストラップ流オブジェクト指向に関する文脈であれば、
「あっている」と考えてさしつかえない
0637デフォルトの名無しさん2014/08/04(月) 21:02:49.86ID:Eu05eWV/
なるほど、遅延結合は構造化プログラミングとは別の発想ということでしょうか。
ただいずれのオブジェクト指向も、ソフトウェアの大規模化という問題の解決を目的としてるというのは合ってますか？
0638デフォルトの名無しさん2014/08/04(月) 21:04:23.97ID:CJ83fxk4
>>634
忘れられがちなのは、PLANNER はヒューイット氏が「アクタの着想を得る前に」
開発した実装知識表現言語(死語であれば「AI言語」)だということですね

その後、SIMULA と Smalltalk などからヒントを得てアクタを考案し、
それを実装したのがアクタ言語族の始祖になる PLASMA と呼ばれる言語です
0639デフォルトの名無しさん2014/08/04(月) 21:10:59.23ID:tfxLBnhp
>>633
ものすごく端的に実例を挙げちゃうと
設計がオブジェクト指向になってなくて大失敗してる例がWindows
毎回、システム改修の度に大きなトラブルが発生して延期が続き
再利用もユニットモジュールごとの最適化アップデートも機能していない。

一方の成功例はMacOSX
NeXTから持ってきた2000年から2003年ぐらいまでは
その教科書どおりのオブジェクト指向設計で重くて遅くて
大丈夫かこれ？と訝しがられたもののモジュール化の上手さで
(ある意味あたりまえの話なのだが)「バージョンが上がると軽く速くなるOS」となった。
新機能はモジュール追加でバンバン増えるし
あまつさえモジュール削ってUI差し替えでモバイル用のiOSにも化けやがった。

この二者についてはほぼC++とObjective-Cの性格の違いが出た明解な実例だと思う。
0640デフォルトの名無しさん2014/08/04(月) 21:12:27.09ID:CJ83fxk4
>>637
>いずれのオブジェクト指向も、ソフトウェアの大規模化という問題の解決を目的としてるというのは合ってますか？

合っていると思うよ
ただし、二つの流儀は解決への方向性が違っていたということ：
・Smalltalk や Objective-C は部品間の結合度を粗にすることで、
　大規模システムとその開発をより柔軟にさせる方向を目指した
・C++ や Java は部品間の結合度を密にすることで、
　大規模システムの実行効率(性能)と安全性(品質)を向上させる方向を目指した
0641デフォルトの名無しさん2014/08/04(月) 21:15:14.48ID:Eu05eWV/
なるほど、わかってきましたm(..)m
0642デフォルトの名無しさん2014/08/04(月) 21:32:51.08ID:P18SzL+z
流行次第だからあまり難しく考えてもしょうがない
イマドキ結合度が高い設計は大抵の人がいやがる
0643デフォルトの名無しさん2014/08/04(月) 21:57:48.88ID:HVeK/QjJ
>>639
それがVistaが出て以降はきっちり3年ペースで、軽くなっていく一方のWindows
同時期から開発遅延発生、リリース不定期化したOSX
ちょっとたとえが古過ぎるんじゃないかな
0644デフォルトの名無しさん2014/08/04(月) 22:31:41.45ID:8BPE65mf
>>639
Microkernelとオブジェクト指向て全然別の概念じゃね？
0645デフォルトの名無しさん2014/08/04(月) 22:56:02.34ID:CJ83fxk4
そういえば、こちらの質問にはレスしていなかったね

>>637
>遅延結合は構造化プログラミングとは別の発想ということでしょうか。

部品間の遅延結合を支えるメッセージの動的束縛とは、イメージとしては
正規表現によるパターンマッチや Prolog における単一化(ユニフィケーション)が近い
つまり動的束縛とは、オブジェクトが持つメソッドテーブルから
メッセージとマッチするメソッドを「動的」に検索し、一致したメソッド
(Obj-C であればC言語関数ポインタ)を起動するという仕掛けになる

それに対して手続き型言語およびストラウストラップ流オブジェクト指向だと、
手続きまたはメソッドとは関数ポインタに付けたラベル(シンボル)であり、
その対応関係はコンパイル時またはモジュールのリンク時、「静的」に解決される

このため >>639 が書いているように、(初期の) OSX には「動的な Obj-C では
開発効率は高くても性能的に使い物にならない」という批判がついてまわった
その一方で、(XP までの) Windows は「静的な C++ によって
高い開発効率と性能を両立した」と高い評価を受けていた
その後、こうした批判と評価は徐々に逆転していくことになる訳だけど、
その流れをマトメたのが >>639 になる（端的というか乱暴すぎとは思うけど....）
0646デフォルトの名無しさん2014/08/04(月) 23:01:50.96ID:CJ83fxk4
>>644
別の概念だね
そして WindowsNT と OSX、共にマイクロカーネル・アーキテクチャを
ベースとしたモノシリック・アーキテクチャとのハイブリッドOSに分類される
0647デフォルトの名無しさん2014/08/05(火) 00:45:07.09ID:GCYfzSWV
>>646
モノシリック
0648デフォルトの名無しさん2014/08/05(火) 01:08:06.39ID:AfbB56Nf
物知り
0649デフォルトの名無しさん2014/08/05(火) 02:32:04.25ID:KN+k7XkJ
>>645
＞(初期の) OSX には「動的な Obj-C では開発効率は高くても
＞性能的に使い物にならない」という批判がついてまわった
システム的に動的タスク管理をするなにかが必須なんでタイムシェアリング的に
そういったものが動くことで遅いってのがシングルプロセッサ時代には明白に見えたからね。
Macは常に上位機種はマルチプロセッサモデルにすることで対応してたけど
事実上のブレークスルーはC2D辺りからのマルチコアあたりまえ時代からかな
G4時代末期にも販売機種が全機種マルチコアになった時代があって
非推奨でTigerをインストールできないシングルコアのMacに
「なんでだ？」ってインストールパッチで無理矢理入れたら
フォルダを開く時に開く通常動作の裏で別コアでファイルのプレビューとか作る仕様になってて
シングルコアだと背後でマルチタスクでやってるはずのそれが割り込んで
フォルダ開く時にカクカクするので「ああもうOSの動作がマルチ前提になってんだな」と思った。
0650デフォルトの名無しさん2014/08/05(火) 02:48:46.51ID:S6pEVZdO
>>643
Vistaで大幅に内部を見直したらしいなー
だから最初の頃は問題も起きたが、その後は
安定したし、7以降にも繋がったんだと思う
0651デフォルトの名無しさん2014/08/05(火) 03:08:22.42ID:BZR3yuzP
MSはOSはまだいいんだがOfficeの2003以降の改悪は目に余る物がある
2010まではまだ我慢できたが2013なにあれ？これまでの開発者全員やめたのか？ってくらい酷い
遅い、プチフリーズする、頻繁に落ちる、機能が見つけにくい、同じ機能がサイドバーに出たりダイアログで出たりUIの一貫性皆無
まじで開発者呼び出してお前何考えているの？って説教したいレベル
0652デフォルトの名無しさん2014/08/06(水) 17:52:27.46ID:4dQxTse1
>>643
>>650
Vistaはディレクトリシステムの代わりにWinFSって
データベースとしてファイルを管理するシステムを中心にしようとして
結局、開発遅延&失敗。2003年予定が2006年に
そしてよく知られてるように様々な問題を抱えてXPからの乗り換えは遅々として進まなかった。
さらにそのWinFS用に作られたVistaのさまざまな不整合を繕って再構築したのが
2009年のWindows7(だからカーネル番号はVista改の6.1となる)
2003年予定が収束が2009年にずれ込んだ歴史的な開発失敗事例ですよ…
0653デフォルトの名無しさん2014/08/06(水) 20:06:31.86ID:CtAgobuc
Microsoft は Windows のプロトタイピングに Smalltalk を使ったりして
ケイのメッセージングのオブジェクト指向のエッセンスは不完全ながらも
いろいろと取り込んで役立てているんだよね。

だからオブジェクト指向にしなくて（できなくて）大失敗っていうと、個人的には
Windows より旧Mac OSのほうが腑に落ちる。ジョブズのこんな白状話もあったことだし。


▼ＮｅＸＴＳＴＥＰについて - スティーブ・ジョブズ １９９５年のインタビューより
http://web.archive.org/web/20121014214135/http://americanhistory.si.edu/collections/comphist/sj1.html#soft

興味深い話をしよう。アップル時代のある時期、アトキンソン達がゼロックスの成果を見る事を
僕に強く勧めてきた。ゼロックスは値上がり必至のアップルの未公開株を買いたがっていたので
その見返りとして我々はゲイツ達は見ることが出来なかった秘密を見せてもらえる立場にいた。

１９７９年、僕らはゼロックスを訪れそこで「アルト」と呼ばれる（ケイ達が提唱する意味＊１での）
「パーソナル・コンピューター」の暫定実装（＊２）と３つの中核技術を目の当たりにして驚愕する。
信じられない事にアラン・ケイ達はそれら３つの技術を１９７６年頃には具現化していたというのだ。
我々がそれらすべてをＮｅＸＴＳＴＥＰ（＊３）として再構築できたのはほんの数年前だというのにね。

残念だが当時の僕は３つの大事な技術を目の当たりにしながら、実は１つの技術しか見えていなかった。
グラフィカルなＵＩ。その衝撃があまりに強すぎて残りの同じくらい重要な２つの存在を吹き飛ばして
しまったのだ。結果、ＧＵＩのみで残りを欠いたまま出来あがったのがＬｉｓａやＭａｃというわけさ。

結局、忘れていた残りの２つの重要性に気づき再発見するのにその後何年もかかってしまったよ。
その残りの２つというのが「ＯＯＰ（メッセージングによる遅延結合＊４）」と「ネットワーク機能」だ。
そう、ＮｅＸＴＳＴＥＰにはこれらがすべて詰まってる。
0654デフォルトの名無しさん2014/08/06(水) 20:41:49.16ID:sZEMoSUh
>>652
流石に窓板でやれ
0655デフォルトの名無しさん2014/08/07(木) 17:25:16.37ID:zgGpAY99
OSXは2007年のLeopardから2009年のSnowLeopardが
非常にオブジェクト指向らしくて面白かったな。
変遷を追ってた人は知ってて>>643みたいな外野は知らないのだろうけど
10.5から10.6は外部的には最も変化がなかったリリースで
やってたことはNeXT時代から書き足してきた全モジュールの見直しと書き直し。
この時点でPPC兼用からIntel向けに、また多くのモジュールが32bitから64bitに書き直された。
この時書き直されたものがいまのiPhone/iPadのiOSのコアにもなっている。

インストールして空きが4Gぐらい増えたのは面白かった。
内臓総とっかえレベルの大オーバーホールだったけど
ユーザーにとってアップデートでなにも問題が起こらず
またいつものように「アップデートしたら速く軽くなった」だけだから
その手際に感心したのはなにをやってたかアナウンス観て
わかってるプログラマだけだったという。
0656デフォルトの名無しさん2014/08/07(木) 22:00:59.68ID:KOv3T7TP
> インストールして空きが4Gぐらい増えたのは面白かった。

たしかファイルシステムが圧縮されたのが理由だったな。
0657デフォルトの名無しさん2014/08/07(木) 23:58:05.77ID:eMsHYc4Q
たまたま見かけたのでお裾分け:
現行OOP言語 (例はC#) で困難な設計課題を
関数型言語 (Haskell) で解決する話。

http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Ralf-Laemmel-Advanced-Functional-Programming-The-Expression-Problem
http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Ralf-Lmmel-Advanced-Functional-Programming-Type-Classes

1本目がOOPでの解への駄目出しで、2本目前半にHaskellでの解ね。
2本目後半はより発展的な話。
一応断っとくと、英語のレクチャービデオだ。
0658デフォルトの名無しさん2014/08/08(金) 22:54:47.36ID:P41P+0nG
>>655
それはオブジェクト指向は関係なくて設計の話じゃん
0659デフォルトの名無しさん2014/08/08(金) 23:38:46.65ID:7OE7NDSB
>>658
これって設計っていうのか？別にコードを何も変えなくても、
圧縮ファイルシステムを使えば達成出来た問題なんだけど。
0660デフォルトの名無しさん2014/08/09(土) 00:39:08.22ID:ZFoSV29O
ま、オブジェクト指向なんて暇なPGに仕事を与える口実に過ぎないって事だな
0661デフォルトの名無しさん2014/08/09(土) 06:56:43.70ID:K0x90JEa
>>660
おだいじに
0662デフォルトの名無しさん2014/08/10(日) 18:49:49.83ID:15lVVzMQ
つーかそもそも動くマシンが少ないのに、すぐに古い機種や古い周辺機器をを切り捨てるMac OS Xと、
後方互換性のためにがんじがらめになってるWindowsは同じ状況じゃないんだから比較がナンセンスだと思うけどな。
どっちのOSにも文句を言いたいことはある。が、スレチだろ。
0663デフォルトの名無しさん2014/08/12(火) 16:41:47.33ID:DPsvz0Xi
つまり俺は汎用しかみとめんということですか
0664デフォルトの名無しさん2014/08/12(火) 19:13:17.38ID:coQ+mfY0
>>662
実際のところWindows8は2004年以前の設計のCPUにはインストールできない(動作しない)し
Vistaの時にMS担当者が「PCを買い換えるチャンスだと考えて欲しい」と明言してたように
ある程度の期間以降は「もうこれに新しいOS入れるのムリ！」って"マシンの寿命"があって
Appleは動作が実用的じゃないレベルで重い旧マシンは順次サポート外にしてるだけで
「iPhone3GSにiOS7を入れさせろ！」みたいなのは一般論としても頭おかしい人扱いでしょうが…
12年間も(VistaもWindows7も無視して)XPを使い続けてたのが旧車マニアみたいな異常事態で
そこから「(俺はXPを使い続けてVistaにもWindows7にも替えてないから)WindowsXPならなにも変えなくていいんだぞ！Appleは切り捨て！」とか
アホちゃうかと…

MSはVistaやWindows7,Windows8で古いマシンも32bitもガンガン切り捨ててたっしょ？
ただ自分たちが新しいそれを使わず「WindowsXP」(2001)を使い続けてただけで。
正気に戻りなよ。
0665デフォルトの名無しさん2014/08/13(水) 15:41:50.32ID:H0kIzvsx
>>664
Windows XPなんか使ってないよ。
アホってばかにするのはいいけど、少なくともソフトウェア資産と周辺機器に関してはMacは切り捨てまくってない？
PowerPCのコードは全く動かないんだから。仕方ないっちゃ仕方ないのはわかるけどね。

どっちのOSでも新しいプラットフォームに対応するために古いものを切り捨てていくのは当然といえるけれど、
少なくともソフトウェアや周辺機器に関してはMacの方がこれまでの変遷を見れば使えなくなるのが早いよ。
ユーザー数がどうしても多くないからソフトウェアやドライバの開発リソースが十分には割けない、というのもあるのだろうけれどもね。

OSはともかくとしても、マシンを乗り換えるたびに周辺機器やソフトウェアをアップグレードしなくちゃならないことが多いから、使い続けるには金がかかる気がするけどね。

DTM機としてMacを使ってる一ユーザーのボヤキだけど。(とはいえWindowsでDTMはそれはそれで色々めんどくさそうなんで、やりたくはないけど)
0666デフォルトの名無しさん2014/08/13(水) 16:03:08.96ID:fGMCGLtV
問題なのは切り捨てる早さじゃないの？

10万、20万を超えるものなんだから
やっぱり10年間はサポートして欲しい。

WindowsはOSだけ見ると2、3万だからもっと早くてもいいってことになるけど、
OSだけで使うものじゃないんで、パソコンシステムとして10年。
つまり10年前のパソコンまでサポートして欲しい。

Macはこれが5年ぐらいだったりするんだよね。
0667デフォルトの名無しさん2014/08/13(水) 16:04:04.73ID:jXoiUBxz
AppleがPowerPCを捨てたからこそ、今の安価でそこそこのスペックのMacがあるとも言える。
0668デフォルトの名無しさん2014/08/14(木) 15:57:40.41ID:XY7wtEPl
>>666
windowsじゃなくて各ハードウェアメーカーが新しいOSをサポートしないだけだろう。
linuxとか使えば10年くらいはだいたい動くだろう。または最初から動かないか。
ハードがUSBビデオクラスとか一般的な規格の実装だったらずっと使えるだろう。そう、オブジェクト指向のようにね。
0669デフォルトの名無しさん2014/08/14(木) 16:33:07.89ID:tETspFu4
>>667
まあ、PowerPC時代から使ってる人とIntel Macになって割といろいろまともになってからしか使ってない人で、Appleをどれだけ信用してるかが違いそうだとは思うわ。

>>668
ハードウェアメーカーが新しいOS Xをサポートしないってところまで含めて、Macでシステム組むと更新に金がかかるわけで。
Appleの努力ではどうにもならない部分はあるだろうが、ユーザはOSとコンピュータ本体にだけ金を払えば済む訳ではないから、トータルで判断を下さなくちゃならない。
だから、「ハードウェアメーカーがサポートしないだけ」かもしれないけど、誰の責任かなんてのはユーザにはどうでもよくて、結局同じ金払って長期間使えないことには代わりない。
結局Mac OS Xの脆弱さって、ハードウェアメーカー、ソフトウェアメーカーが開発継続を正当化するだけの市場規模がないと判断されてるところだと思うけどな。
0670デフォルトの名無しさん2014/08/14(木) 18:35:16.65ID:XY7wtEPl
>>669
ユーザーがそういうところを考慮してハードウェアを選んでないとこが原因。
winモデムとか、格安プリンタとか。
繋げば使えると言う戦略で囲い込んだMSの成果なのかもだけど。
0671デフォルトの名無しさん2014/08/14(木) 19:23:36.60ID:tETspFu4
>>670
ADBのタブレットとか、FireWireのオーディオインタフェースとか、「安ければ、動けばなんでもいいわ」でもないものでも切り捨てが起こるから、
別にWinモデムとか格安プリンタとかの自業自得系だけではないと思うけど。
上記の2つは実際に自分が奮発して買ったのに寿命が短くて悲しい思いをしてるケースだけど、ぶっちゃけこれらに関しては回避しようがなかったと思うけどな。
0672デフォルトの名無しさん2014/08/14(木) 20:09:03.42ID:dFzFllhN
>>671
ADB~USB変換もFW-TB変換も知らないとかどんなだ
0673デフォルトの名無しさん2014/08/14(木) 20:25:19.62ID:XY7wtEPl
>>671
前者はよく知らないが、それは主流でなくなったのでそのインターフェースで新しい機器を入手するのが困難になっただけで、Firewireのサポートは新しいOSでもあるでしょう。
OS-ハードウェア間の話だったはずだ。
ハードウェア-ハードウェア間の話になってないか。
0674デフォルトの名無しさん2014/08/14(木) 22:27:34.34ID:tETspFu4
>>672
知ってるよ。つながるかどうかだけじゃなくて、その機器を使って安定的に運用できるか、今後しばらくの期間サポートされるか、そういうところが大事でしょ。

>>673
前者については、そういう意味じゃなくて、当時は結構思い切って買ったADBのデバイスがすぐに使えなくなった、というところが問題であって、
使えてれば嫌な記憶として残ることはなかったと思うよ。ADBの新しいデバイスが出なくなる、なんてのはどうでもいい話で。
ADB→USBの変換器はあったし、USBに切り替わった瞬間は使えていたけれど、結局そういうものはメーカーが頑張ってサポートしてくれるわけではないし、
寿命が1-2年延命されるだけに過ぎない。

そして、FireWireに関してだって、FireWireのサポート自体はあるかもしれないけども、実際1-2年前まではあれだけ当たり前だったFireWireのオーディオインタフェース、
軒並み生産終了だし、ドライバももう最終更新だとメーカーが言ってるし、Mavericksは対象外だけど一応動くみたいな状況で、今後いつ使えなくなるかわからない秒読みなのよ。

何が言いたいかって言うと、特に周辺機器に関してはOSがそのインタフェースをサポートしてるってだけじゃダメで、メーカーに新しいOSに対応したドライバを継続して開発してもらわなければダメなんだけれども、
メーカーにそういうサポートを期待できる状況か？というのもシステムの構成を考える上でもちろん考えなきゃいけないことだよね。
そういうことを踏まえた上で、Macは周辺機器をどんどん買い換えることを前提とするか、周辺機器とかあまり関係ないような世界で使うのならば十分に運用できると思うけれど、
一度買った周辺機器を長く使い続けたいような場合や、特殊な周辺機器を使いたい場合は母数も少ないしメーカーがアフターサポートに意欲的じゃないから難しい、ってことだ。

OSの出来が悪いって言ってるんじゃないんだよ。単に、WindowsとMacでは求められているものが違うんじゃないか、と言いたいだけ。
0675デフォルトの名無しさん2014/08/14(木) 23:52:12.24ID:XY7wtEPl
>>674
なげぇ。
そしてそういう話してない。

オブジェクト指向のように、インタフェースに基づいて実装しろと言ってんだよ。

スレチだ消えろ。
0676デフォルトの名無しさん2014/08/15(金) 01:52:40.01ID:4VLJMFPp
>>675
>>668から微妙にオブジェクト指向を絡めてはいるが、あんたもスレチな話題に応じておいてめんどくさくなったらスレチだ消えろ、か。
言いたいことはわからなくもないがその理想が貫き通せる環境ならみんなドライバ開発で苦労しないだろうな。
0677デフォルトの名無しさん2014/08/15(金) 02:15:57.17ID:Uwb6H5qg
Boostとかについてはどう思ってるんかね？
ああいうのが自由に使えないと即老害認定かねえ
0678デフォルトの名無しさん2014/08/15(金) 02:17:17.09ID:dVghf27+
>>676
まとめられずにだらだら関係ない長文書くような粘着相手にしてもしょうがないだろ。話になんないんだから。
0679デフォルトの名無しさん2014/08/15(金) 03:42:30.98ID:3Kw1PLhR
オブジェクト指向て単語を混ぜてはいるが、使い方はデタラメだしな。
何らかのモジュール化機構は全てオブジェクト指向と呼ぶとでも思ってんのかね。
0680デフォルトの名無しさん2014/08/15(金) 04:57:59.91ID:dVghf27+
>>679
お前がわかってないことはわかった。
0681デフォルトの名無しさん2014/08/15(金) 05:03:23.07ID:Q04nt0Zy
たぶん俺以外にも「USB接続の周辺機器はメーカーがドライバを継続的に作り続けないとすぐ死ぬ！」とか喚いてる奴がいたら
「それ、メーカーの設計が根本から変なんじゃね？」って脳内でツッコミ入れてもう最初からスルーしてた奴いるんじゃないか？w

単純な話、俺が97年ぐらいに買ったWindowsPCには外部端子なんてPS2とRS232Cしかついてなくて
SCSIボードを買って刺して外付けHDDを増設してたし、当然のようにSCSIなんて2000年代に入ったらどうしようもないわけで。
え？なに？俺、ハードメーカーがSCSIのサポートを続けないのはMicrosoftのせいだ！とか言っちゃっていいのこれw
せっかく買ったSCSIボードが"すぐ"使えなくなった！とか、アナログモデム数台とかアナログRGBモニタとか
ボール式PS2マウスとか、CD-Rドライブとか、100Base-Tのルータとか、PhotoshopLEとかPainterClassicとか
ううん、2014年のいまの俺のマシンで動かないなんて実にけしからんね。
なに言ってんだ、おまえw
0682デフォルトの名無しさん2014/08/15(金) 05:48:27.38ID:3Kw1PLhR
>>680
ほう。どう分かってないのか解説願おうか。
0683デフォルトの名無しさん2014/08/15(金) 09:45:34.76ID:dVghf27+
やはり粘着か。
0684デフォルトの名無しさん2014/08/15(金) 16:42:17.71ID:3Kw1PLhR
まだ1回しかレスしてないだろw
余裕無さすぎだろ。
0685デフォルトの名無しさん2014/08/15(金) 19:42:54.97ID:dVghf27+
ほらね。
0686デフォルトの名無しさん2014/08/15(金) 21:13:09.96ID:etGjlPNj
スレタイは
「オブジェクト指向以外の話をしろ」
という意味ではない
これ豆知識な
0687デフォルトの名無しさん2014/08/15(金) 23:14:12.00ID:6IXuR3GY
>>639が変な例えを持ち出したせいで、もう10日も話題が迷走して戻ってこない
自動車の話でもしてるほうがまだマシだったな
0688デフォルトの名無しさん2014/08/16(土) 20:17:32.60ID:I0zB+b58
例えじゃなくてソフトウェアエンジニアなら誰でも知ってる目に見える実例なんですが…
0689デフォルトの名無しさん2014/08/17(日) 07:06:42.83ID:C5Nd2M3Z
Windowsが失敗というところが間違ってるので
全く信用に値しない。
0690デフォルトの名無しさん2014/08/17(日) 08:35:16.74ID:4pLmdpWp
オブジェクト指向って色々説明方法はあるだろうけど、
ざっくり言ってしまえば
「部品の組み合わせでプログラム（システム）を作る」
って理解でよろしいですか？
0691デフォルトの名無しさん2014/08/17(日) 08:40:58.28ID:fXG/tfAe
そんな幻想を抱いてるなら、お願いだから俺の仕事と絡むような事がないよう祈っててくれ…
0692デフォルトの名無しさん2014/08/17(日) 09:17:41.07ID:hMiNzxMC
>>690
あってると思うよ。
0693デフォルトの名無しさん2014/08/17(日) 10:43:01.33ID:aOv4wmTt
>>690
いいえ。部品化アプローチにも色々ある。オブジェクト指向はそのうちの一つ。
0694デフォルトの名無しさん2014/08/17(日) 11:25:38.28ID:jyIHfqgX
>>693
じゃあ「オブジェクト指向は部品化アプローチである」って事じゃん。
0695デフォルトの名無しさん2014/08/17(日) 11:48:46.10ID:nFlKUfrZ
>>694
「部品化のアプローチの一つにオブジェクト指向が向いている」くらいのニュアンス
だと思うがね。
0696デフォルトの名無しさん2014/08/17(日) 11:53:15.06ID:nFlKUfrZ
それに部品化ならカプセル化じゃなくてパーツ化とか表現するもんじゃね？
0697デフォルトの名無しさん2014/08/17(日) 11:59:25.41ID:hMiNzxMC
>>696
いや、何というか、部品化とカプセル化は同一レベルで論じる概念ではないでしょ。
0698デフォルトの名無しさん2014/08/17(日) 12:03:19.93ID:jyIHfqgX
ここの議論は定義を細分化・階層化してるだけで、ほぼ同じ事を言っている。
0699デフォルトの名無しさん2014/08/17(日) 12:21:20.55ID:m599qTIk
先に「gotoでつなげまくってたらメンテ不能になるから
入力->出力って形の関数という単位にまとめようよ」
ってCとかの構造化が出てきて、オブジェクト指向はその次に
smalltalkやObjective-C,JAVA辺りで「オブジェクト間のやりとりを
"おまえはこれをやりなさい"って動作を指示するインターフェイスに抽象化することで
ユニットの見通しと取り回し、改良を容易にしたもの」…かな？
いま主流のオブジェクト指向はこっち系統なので
そこを抜いてSimula辺りからクラスと継承だけ持ってきたC++が
オブジェクト指向を名乗るにはかなり異端だったよねって話に現在はなる。
0700デフォルトの名無しさん2014/08/17(日) 14:01:27.55ID:wn4TLg6+
>>690
オブジェクトを部品とし、その組み合わせで(ry

単に部品というと構造化の方を連想しやすい。
0701デフォルトの名無しさん2014/08/17(日) 19:02:49.01ID:YK4F6yeT
部品という概念だと、呼び出し側で部品を操作する可能性が有るから
この時点でオブジェクト「指向」じゃなくなる

部品ではなく完成品だ、呼び出し側は操作方法だけ知ってれば良い
0702デフォルトの名無しさん2014/08/17(日) 19:39:34.03ID:fXG/tfAe
>>701
ニホンゴフトクイデス？
0703デフォルトの名無しさん2014/08/17(日) 20:15:23.17ID:5ZqSNhiP
部品は単純なものから高度複雑部品が有る
CPU=部品
コンデンサ=部品
部品自体守備範囲が広すぎる
0704デフォルトの名無しさん2014/08/17(日) 21:17:47.94ID:m599qTIk
オライリーの「言語設計者たちが考えること」(インタビュー集)でそのまんま
Objective-Cの開発者がC++について「私たちは言語のICを作ろうとしたが
ストラウストラップはC++で言語のトランジスタやコンデンサを作ろうとした」と
評してたっけなー
0705デフォルトの名無しさん2014/08/18(月) 03:26:24.93ID:6vhILx3J
>>704
やっぱり他をけなすことだけは
プロ級ですねｗ
0706デフォルトの名無しさん2014/08/18(月) 04:17:41.94ID:kATBl8BV
たとえが的確すぎてグウの音も出ない
0707デフォルトの名無しさん2014/08/18(月) 11:57:44.05ID:5ASvVHjJ
しかし、喩え話は分ってる奴、言わば業界人の「あるある話」で
業界外の知らない奴が聞いいても「ふ〜ん、そんなもんか」で終わる

動物クラスから犬と猫をみたいな話をするのは百害あって一利無しだろ
アンチOOPを生んだのは、最初に現実の世界に則してなどと説明した奴が悪い
0708デフォルトの名無しさん2014/08/18(月) 14:15:56.23ID:kgpSV0N7
それで利益をあげている奴もいるから、その人のスキル次第
つまり、馬鹿には無理
0709デフォルトの名無しさん2014/08/18(月) 21:53:59.81ID:KRqMNnyR
馬鹿には無理ならオブジェクト指向なんて元来無理ゲーだったんだよ
なぜならほとんどのPGは馬鹿だからな
0710デフォルトの名無しさん2014/08/18(月) 22:21:20.49ID:5ASvVHjJ
逆だろ、馬鹿だから必須、難しい事なんて何も無い
単細胞だろうが馬鹿だろうがOOPで作れば保守も拡張もしやすいんだよ

最初に覚えるのはデータと関数を引っ付ける事、これだけ
継承だのオーバーライドだのは後だ
分かってない奴に先にメリット教えても無駄なんだよ

まず独立した関数を禁止してメソッドだけで作らせる
これだけでもフローは減り、かなりスッキリする
データに関数を紐付ける習慣が第一で他の事は次だ
0711デフォルトの名無しさん2014/08/18(月) 23:53:59.63ID:O+BqSqng
なんでもOOPで作ればいいって馬鹿は嫌い。
アプローチの一つに過ぎないのにな。
0712デフォルトの名無しさん2014/08/19(火) 00:41:31.16ID:/mYzAp9x
そうは言ってもやっつけで作ったスクリプトが巡り巡ってレガシィになって
再会するとちゃんと作っておけばよかったってなるから油断できない。
OOPは最適じゃないかも知れないが、最悪じゃないってだけで使うことも
少なくないし。
0713デフォルトの名無しさん2014/08/19(火) 01:43:13.99ID:dZTAythJ
>>709
できるやつが設計して、できないやつがプログラム書けばいい。
0714デフォルトの名無しさん2014/08/19(火) 02:04:14.60ID:5SyLJZAk
できるやつが設計して、できるやつがプログラム書けばいい。
0715デフォルトの名無しさん2014/08/19(火) 02:26:59.76ID:/hL+PG7t
>>714
やるじゃん。それ正解な。
糞コード量産マシンは全部潰さなきゃいけない。
0716デフォルトの名無しさん2014/08/19(火) 02:59:02.22ID:dZTAythJ
>>714
必要十分なやつがやるのがコストパフォーマンスよい。
お前は便所掃除までしてるかも知れないが。
0717デフォルトの名無しさん2014/08/19(火) 03:03:40.23ID:GWP9Y/No
できるけど便所掃除を馬鹿にしてやらないやつのほうが
オレは嫌いだ
0718デフォルトの名無しさん2014/08/19(火) 03:15:45.51ID:D00xZlHW
斯くして便所掃除も出来ない奴が出来るようになる機会がなくなり
便所掃除以上のことをする人もいなくなり
便所掃除しか出来ない組織が出来るのであった
0719デフォルトの名無しさん2014/08/19(火) 03:59:27.40ID:dZTAythJ
自宅の便所掃除してれば会社の便所掃除に時間がかかるのとか想像できるだろ。
0720デフォルトの名無しさん2014/08/19(火) 07:15:21.70ID:07RS64z4
出来る奴が便所掃除の概要的なルールを決めて適切な道具を揃える
出来ない奴が具体的な掃除手順を決めて掃除するだけ
0721デフォルトの名無しさん2014/08/19(火) 18:15:14.67ID:9/TUtaJo
なんでこの人はオブジェクトはデータと操作をくっつけたものって何回説明されても理解しないで
古い変な本の受け売りの「構造体に関数が〜」な俺理解を連呼するんだろう。
0722デフォルトの名無しさん2014/08/19(火) 18:46:45.02ID:YAwuk365
構造体はデータで関数も操作だろ、何で分けたんだ
メソッドになってない関数の事か？
0723デフォルトの名無しさん2014/08/20(水) 09:07:00.33ID:eiSEmaKl
別にデータと操作をくっつけなくても
データだけでオブジェクトだろ
やっぱり解ってねーやつだらけなのな
0724デフォルトの名無しさん2014/08/20(水) 09:37:59.47ID:oXhGBwDd
精神病患者が世界に向かって
お前ら全員狂ってると言うにさも似たり
0725デフォルトの名無しさん2014/08/20(水) 10:02:44.25ID:tTWGII1o
俺様だけが分ってる(ｷﾘｯ
0726デフォルトの名無しさん2014/08/20(水) 11:14:31.69ID:EYhur30S
そもそも対象がデータ限定じゃないからなー
現代に音楽ファイル再生クラスをデータとか構造体って認識する奴ぁいねぇし
あきらかにC++時代のCからC++への"オブジェクト指向"の解説でよくあった
「オブジェクトはデータ(構造体)にそれを操作する関数を含めたものです」ってのを
ベースに話をしようとしてるからチグハグ感がハンパない。
0727デフォルトの名無しさん2014/08/20(水) 11:35:19.38ID:miEQQHmS
俺はOMTをベースとした開発手法として便利に使ってる。
0728デフォルトの名無しさん2014/08/20(水) 11:36:12.17ID:tTWGII1o
初歩的な部分の解説にチグハグ感あるのは当然
メソッドから始めないとOOPとか意味不明で永遠に手続きから抜けられない
だからしょうもないスレが乱立してんじゃね
0729デフォルトの名無しさん2014/08/20(水) 12:27:13.58ID:P5DqOWPt
>>728
はぁ？？
0730デフォルトの名無しさん2014/08/20(水) 19:02:48.31ID:l4rFB+SL
これだけ経っても正しい理解、自然な理解が進まないオブジェクト指向ってのは
どうも人間の思考に合っていないんだろう
これだけでやめた方がいいってのが分かるな
0731デフォルトの名無しさん2014/08/20(水) 19:05:09.19ID:p2P5D/Mq
こんなアホでもわかるパラダイムが理解できないなら、そりゃやめた方が良いw
0732デフォルトの名無しさん2014/08/20(水) 21:59:48.16ID:l4rFB+SL
そのパラダイムっての？
君しか理解していないみたいだよ
0733デフォルトの名無しさん2014/08/20(水) 22:04:47.48ID:RXWpuYSN
パラダイムも知らんならそりゃ理解出来んだろなあ
0734デフォルトの名無しさん2014/08/21(木) 00:22:21.82ID:+8OngRcP
発売されたばかりのSoftware Design 2014年9月号でオブジェクト指向を特集している
http://gihyo.jp/magazine/SD/archive/2014/201409

紹介を見ると執筆者の間でも賛否両論のようで、このスレの流れにぴったりの記事ではなかろうか？
他の記事に興味が無さ過ぎるため、残念ながら私は買えないが、誰か読んで感想を聞かせてくれ
0735デフォルトの名無しさん2014/08/21(木) 01:14:06.09ID:2PBqelLW
SD買わなくなってから大分たつが…スゲー値段あがってるな
0736デフォルトの名無しさん2014/08/21(木) 19:48:11.36ID:PgpIBRLm
むかしもオブジェクト指向を理解してる人は普通に理解してて
その上で(Cの関数のサイズや毎回書き捨てで再利用する必要のなさから)
「こんな迂遠なことやる必要あるの？」って疑問を呈してただけで
考え方を"理解しない"ってのはただのバカでしかなかったな。
0737デフォルトの名無しさん2014/08/21(木) 20:36:24.43ID:hEC3oLSr
1人でやってんのか集団で分業してんのかで考え方なんて全く変わる
0738デフォルトの名無しさん2014/08/21(木) 20:40:31.36ID:J8oeLYzB
人数じゃなくて規模の問題だよ。
0739デフォルトの名無しさん2014/08/21(木) 21:59:54.01ID:hEC3oLSr
自分で書いた1年前のコードは他人のコードってので誘導しようとしてたのに邪魔すんなよ…
0740デフォルトの名無しさん2014/08/21(木) 22:32:40.36ID:U37bR+oO
SD 買って読んだけど、どれも（っても組み込みのはわからないのでそれ以外）
半端な知識でもっともらしい話で導入した後、我田引水的な展開しててあきれた。
0741デフォルトの名無しさん2014/08/21(木) 22:41:32.15ID:W/oig19k
ノー！ それ書いたの私じゃありません。
一年以上前のコードは他人のコードです。
そんな問題知りません。私のせいじゃありません。
0742デフォルトの名無しさん2014/08/22(金) 00:03:55.92ID:1VP24a8N
自称オブジェクト指向を理解してる人と言うのにはいくらでもいるが
それが生産性に結びついている人には会ったことは無いし
自称オブジェクト指向を理解してる人の言うことがまちまちで
それでいて自分が真に理解しているというもんだから
オブジェクト指向ってのは信仰なんだなあと
私が真に教祖様のことを理解していますという信者間の争いなんだろうなと
0743デフォルトの名無しさん2014/08/22(金) 04:00:11.65ID:bGeNJIvA
>>742
そりゃ分類方法の分類だからな。だから指向。東を向いてるからって、目的地や道順が同じとは限らない。
OMTとかRUPとか具体的な方法論を取り上げれば、かなり統一されてくるだろう。
0744デフォルトの名無しさん2014/08/22(金) 11:10:27.72ID:Dz9xBLJQ
>>742
そりゃオブジェクト指向が目先の"生産性"に結びついてるわけがないだろ。
こいつの肝はオブジェクトとして各モジュールを独立するように設計して
他まで変更が波及しないように作ることで
完成後の保守及び継続的なアップデートを容易にすることなんだから。
だから批判は「そんなことしなくてもただ書けばいいだろ？」って
明日の自分を考えないスパゲッティプログラマの不要論か
おまえのようにそこにすら至らない「よくわからないけど
なんでそんなことしなくちゃいけないの？」って池沼自慢に二分される。

ワンオフで作り切り売り切りの保守しないプログラムなら
こんなことしなくてもいいんだろうよ。
現代にそんなプロジェクトがそうあるわきゃないが。
0745デフォルトの名無しさん2014/08/22(金) 13:34:18.34ID:NukNAvU4
お前が設計とやらに時間をかけてる間に
俺はコピペでさっさと作る。

どっちが早く作れるか競争しようじゃねぇか。
0746デフォルトの名無しさん2014/08/22(金) 13:34:57.12ID:va04FkVj
どうせゴミしか作れないんだから早いほうがエライ
0747デフォルトの名無しさん2014/08/22(金) 21:23:10.78ID:GN+fUp7X
新しいことを導入したあげく新しい不具合を作り込み
思想は間違いないんです！なぁんて言っても全然説得力無いし
つまらないことにこだわるんだったら不格好でも問題の無いあり物を使って
納期も労力も短縮して数をこなすってのがプロの仕事ですな
趣味やヒョーロンカになりたければ生産性無しの愚にも付かないことをやっても許されるでしょうけど
0748デフォルトの名無しさん2014/08/22(金) 22:01:00.99ID:bGeNJIvA
>>745
お前の設計が遅いのは良くわかった。
0749デフォルトの名無しさん2014/08/22(金) 22:08:20.04ID:yxF/YUP5
とりあえず優先順位が何かをプロジェクトメンバーとよく話し合って
意識統一してから設計にメスを入れような。
0750デフォルトの名無しさん2014/08/22(金) 22:37:41.65ID:NukNAvU4
>>747
新しいこと＝生産性を上げることなんだけど、
生産性あげようと思わないの？
0751デフォルトの名無しさん2014/08/22(金) 22:42:54.57ID:BtBgkxO2
名ばかりオブジェクト指向は地獄絵図だけどね
0752デフォルトの名無しさん2014/08/22(金) 22:47:45.95ID:K+6NvYz4
全然新しいことじゃないってのは言ってはいけません。
0753デフォルトの名無しさん2014/08/22(金) 22:47:47.66ID:NukNAvU4
「名ばかり」オブジェクト指向
　　↑
当たり前だけど、地獄絵図はのはこのせい
0754デフォルトの名無しさん2014/08/22(金) 23:13:34.48ID:GN+fUp7X
>>750
これだけ定義が曖昧で共通見解を持てないオブジェクト指向の御旗の元で組織戦をしようなんて度胸があるというか死にに行くようなもんじゃね？
事実と推定がごっちゃの仕様書で、何が本当か分からないままフィーリングで仕事をしている情景が目に浮かぶわ
0755デフォルトの名無しさん2014/08/22(金) 23:16:25.70ID:BtBgkxO2
オブジェクト指向を使いこなせない奴がコード書くと大変な事になるって意味で

コピペはいかん。「同じコードを二度書くな」
不具合があるとコピペされてシステム全体に感染して一つでも取り漏らすと見つけるのが大変
0756デフォルトの名無しさん2014/08/22(金) 23:17:34.91ID:BtBgkxO2
チーム全員に指導できなきゃ危なくてしょうがないというのは確かだな
0757デフォルトの名無しさん2014/08/22(金) 23:31:40.05ID:NukNAvU4
>>755
プログラマーとして未熟な奴がコード書くと大変な事になるって意味で

でよくね？ オブジェクト指向関係ないよ。
未熟な奴は何を使っても汚いコードを書く。

汚いっていうのは、開発効率が悪くてヘタすれば
作れば作るほど、後々の開発が大変になっていくコード
0758デフォルトの名無しさん2014/08/22(金) 23:36:54.29ID:D//jJKTK
日本でオブジェクト指向を謳って商品を販売したソフトウェアって
一太郎ver7or8だった記憶があるけど、全く機能しなかった。
広告にまで、今回の一太郎はオブジェクト指向で作ったので、
簡単に機能がアップできます見たいな感じに書かれていて、
当時の自分は「オブジェクト指向すげー！！」って感激した。
0759デフォルトの名無しさん2014/08/22(金) 23:41:03.25ID:NukNAvU4
>>756
それ明らかに宣伝方法が間違ってるだけだろ。
だいたいの製品はオブジェクト指向で成功してる。
使ってる技術が当たり前すぎてわざわざいわないだけ。
0760デフォルトの名無しさん2014/08/22(金) 23:43:01.63ID:BtBgkxO2
>>757
確かにその通りだな。
0761デフォルトの名無しさん2014/08/23(土) 02:33:58.45ID:5f63ip/R
俺は頭悪いので、構造化だと破綻したり、同じようなコードになって修正が大変。
オブジェクト指向だと、そうはならない。
0762デフォルトの名無しさん2014/08/23(土) 02:51:22.83ID:S/NSb1jx
そもそも人間の頭の中身なんてそんなに進歩してるわけでもなく、実際に
数十年も前に出たアイデアや概念、理論なんかがマシンスペックが上がって
実現できるようになってきたのが実情なわけだし。 知らないから、知識が
無いから新しく見えるってのはいくらでもあるけど、アイデアレベルでさえ
どこにもなかった新しいものなんてほとんどないからね 。
0763デフォルトの名無しさん2014/08/23(土) 03:55:26.33ID:X4Ro36NP
というかJAVAでもObjective-Cでも言語自体がオブジェクト指向言語なので
ごくごく当たり前に(というよりオブジェクト指向言語でそれらを使わないってのは
Cでなんとしても関数を使わずにプログラムするぐらいの難事なので)
みんなオブジェクト指向を息をするように使って仕事してるわけで。
このなんかオブジェクト指向が現在おためし中の新技術みたいに語る人なんなのw
オブジェクト指向使わなかったらいまのスマホのアプリ一個も組めないんだけどw
0764デフォルトの名無しさん2014/08/23(土) 05:16:28.65ID:5f63ip/R
>>763
1関数で数千行とか、1クラス全てstaticとかやりようはある。
案外おまえがそんなんで、俺ってオブジェクト指向だぜとか言ってそう。
0765デフォルトの名無しさん2014/08/23(土) 10:05:39.57ID:ZY4hy+LK
構造化プログラミングだとか、オブジェクト指向プログラミングだとかって、
本当はアセンブラでだって出来るんだよ。その本質的な概念・目的さえ抑えておけば。
ただ、非対応の言語でやろうとしたら大変過ぎるんで、そういう言語を使うわけだ。

でも、その構造化やらオブジェクト指向の何たるかが分かってない奴が、
構造化言語だから、オブジェクト指向言語だから、で使っても、
一応、関数とか、クラスとか使っているが、全く構造化にもオブジェクト指向にもなってないコード
というのは良く有る話。
0766デフォルトの名無しさん2014/08/23(土) 10:58:19.87ID:l0xG8kRo
俺は不思議に思うわ本当に。
なぜ2014年にもなって、
やっぱり２ちゃんでは>>765みたいなレスが新たに書き込まれるのか。
なぜ人類は>>786みたいなレスを何十億と繰り返すのか。
そういう人はコーラを飲むとゲップが出るようなこともいちいち今日もどこかでレスしてるのだろうか。
0767デフォルトの名無しさん2014/08/23(土) 12:04:44.79ID:NnsQ9VjT
>>786
お前には期待しているぞ
0768デフォルトの名無しさん2014/08/25(月) 09:16:01.04ID:6Ei26bdn
不毛すぐる
0769デフォルトの名無しさん2014/08/27(水) 04:13:16.31ID:vqSIqdVz
>>765
おまえが解ってねーじゃん
アセンブラではオブジェクト指向できねーだろ
0770デフォルトの名無しさん2014/08/27(水) 07:52:08.75ID:T062qs6O
え？
0771デフォルトの名無しさん2014/08/27(水) 09:29:39.46ID:b8nwk8+f
>>769
なんで？
0772デフォルトの名無しさん2014/08/27(水) 18:13:39.81ID:rOfrtizG
>>769
顔が赤くなってるぞ
よく調べろ
0773デフォルトの名無しさん2014/08/27(水) 23:21:30.82ID:iMBG119U
やりにくいのと、できないのはまったく違うからな
オブジェクト指向はあくまで考え方だから、問題はそれに基づいて組んでるか
もちろん、現実的には面倒だからOOPLでやるのが一般的だけどね
0774デフォルトの名無しさん2014/08/28(木) 07:49:11.67ID:GGrjaISm
できないっての
アセンブラのオブジェクトはレジスタやメモリそのものだからな
0775デフォルトの名無しさん2014/08/28(木) 08:17:06.38ID:aaHuOzU/
え、文法の問題ってこと？ｗ
0776デフォルトの名無しさん2014/08/28(木) 08:19:10.39ID:nV1UHWpe
>>774
それ、オブジェクトの意味が違うだろ。
インスタンスごとに連続したアドレスを割り当ててメソッドやプロパティへのポインタを格納すればいいじゃない。
0777デフォルトの名無しさん2014/08/28(木) 08:32:37.10ID:aaHuOzU/
メモリだからどうとかって、「オブジェクト指向設計」には関係無いよね。でもオブジェクト指向だよね。
実際のコードの書き方がイコール オブジェクト指向じゃないんだよ。


アセンブラとか構造化言語だと、直接アクセスすべきでないメモリ領域やルーチンと公開するルーチンを決めて、
それを人力で運用するというめんどくさいことをしないといけないけど、

オブジェクト指向言語なら、classとかpublic,privateのようなキーワードだけで、
コンパイラが自動的に面倒を見てくれて便利

というだけの話なんだよ。
0778デフォルトの名無しさん2014/08/28(木) 08:37:25.61ID:MawgPZIM
どんなプログラミング言語でも最終的にはアセンブラというか機械語になるわけ
だから、言語の文法で強制的にルール化されているか、コードを書く側が外部で
ルール化しているかの違いだけだよな。
0779デフォルトの名無しさん2014/08/28(木) 19:17:38.96ID:GGrjaISm
だからコードレベルの話だろ
プログラミングにおけるオブジェクト指向ってのは文法のこと
0780デフォルトの名無しさん2014/08/28(木) 20:21:39.87ID:pLmcbVkd
文法…じゃないなぁ
むしろ、オブジェクト指向特有のモジュールの取り回しモデルがあって
オブジェクト指向言語はそれが基本仕様に含まれてるからオブジェクト指向言語なわけで
アセンブラで同じようなことはできるけど
ぜんぶ自分でID管理したコマンドをポインタ渡しで解釈させるとか
うん、たぶん新言語を造った方が速いし、そんなん一から作るくらいなら
既存のオブジェクト指向言語使うよね。的な
0781デフォルトの名無しさん2014/08/29(金) 01:44:38.85ID:h1bgB9ga
>>779
構造化とか継承とかのことを言ってんのか？
それは OOP の手助け仕様＝道具で、本質じゃないぞ
OOP の考え方をおざなりにしてこういう言語仕様に振り回されると
とんでもないクソコードが生まれる
0782デフォルトの名無しさん2014/08/29(金) 03:56:48.47ID:8CYlhDKE
構造化プログラミングも、今は当たり前に言語でサポートされてるが元々は考え方だからな、それと同じ

機械語やアセンブリ、昔のBASICなどジャンプが基本の時代には結構無茶な流れのプログラムが量産されてたワケだが
そのジャンプの使い方を「基本は上から下へ書く」「分岐」「ループとループ制御」「サブルーチン(手続き、関数)」みたいな感じで整理した(逆に言えば、これらが成り立たんコードが量産されてたワケで)
そこを文法要素でサポートしたのが現行の大半の言語

同じく、オブジェクト指向も考え方がまずあって、それを言語でサポートしただけだよ、第一初期のOOP解説本は純Cとかだぜ
0783デフォルトの名無しさん2014/08/29(金) 07:30:00.91ID:7XHfH+yr
>>779
言語毎に文法は違うが、どれが正しいんだ？ｗ

全部だというなら、適当な言語を作って、これは「オブジェクト指向言語」だ
と言い張ればオブジェクト指向になるのか？
0784桃白白 ◆9Jro6YFwm650 2014/08/29(金) 07:34:54.72ID:ppLa6QHv
>>783
はい。
0785デフォルトの名無しさん2014/08/29(金) 08:40:54.39ID:JuyS8Rqx
影響力のでかい人がオブジェクト指向だ と言い張ったらそうなる
細かいことグダグダ気にしてるニワカもその分コードレベルの事勉強してたほうが絶対良いのに
0786デフォルトの名無しさん2014/08/29(金) 11:09:38.05ID:AEpwYDBa
英語はオブジェクト指向言語じゃないが
日本語はオブジェクト指向言語だろ
だから英語圏の人には「オブジェクト指向」なんて概念が必要になるんだよ
それが何か新しいものであるかのように見えているわけだ
でも日本人にとっては当たり前のことだったからピンとこないわけ
0787デフォルトの名無しさん2014/08/29(金) 11:18:08.44ID:AEpwYDBa
print hoge

こういうコマンドがあったとする
もちろんこれはオブジェクト指向ではない
しかしこうすると

hoge print

これがオブジェクト指向になる

print……verb
hoge……object
基本はただこれだけのことだよ
0788デフォルトの名無しさん2014/08/29(金) 11:47:25.46ID:4xakm/Il
1番目の引数をオブジェクトとして扱うという考えは間違ってはいないが、lispなどを学ぶともっと世界が広がる。(print obj a)
0789デフォルトの名無しさん2014/08/29(金) 11:55:52.25ID:AO0N6kCB
「でしょでしょ？だからアメリカ人はこの平たい世界の裏側に逆さまに立ってるんだよ！」
って地球平面説の人が話しかけて来たような違和感w
0790デフォルトの名無しさん2014/08/29(金) 13:20:48.15ID:DMOOLGfY
オブジェクトが先に来るのがオブジェクト指向って考えの人なんだろう
そういう例が多いとは思う
0791デフォルトの名無しさん2014/08/29(金) 14:46:18.35ID:CVxP3Mgt
>>779
書くまでもなく当然のことだが，オブジェクト指向言語と言われてる言語で全くオブジェクト指向でないプログラムを書くのはとても簡単だろ。
「オブジェクト指向」自体はパラダイムであって文法のことを指しているわけじゃないだろ
文法レベルでどういうものがオブジェクト指向型言語であるかなんていう低レベルの話は誰もしてない
0792デフォルトの名無しさん2014/08/29(金) 14:58:09.68ID:AEpwYDBa
オブジェクト指向そのものはパラダイムであっても
それをプログラミング言語に適用した場合は文法のことになるんだよ
0793デフォルトの名無しさん2014/08/29(金) 16:03:30.32ID:8CYlhDKE
>>792
む、無理して未来アンカーに対応しなくてもいいからな？！
0794デフォルトの名無しさん2014/08/29(金) 17:52:44.34ID:AEpwYDBa
基本はただそれだけのことなんだよ
オブジェクト指向に夢を見過ぎだな
まあ過大な宣伝文句に騙された被害者ってところか
0795デフォルトの名無しさん2014/08/29(金) 18:13:23.36ID:6XulYCBt
>>787

>>515-516
話がループしてる
0796デフォルトの名無しさん2014/08/29(金) 18:21:52.19ID:tst07tzv
アセンブラ<>機械語
は同等ではない
アセンブラにはマクロが使える
0797デフォルトの名無しさん2014/08/29(金) 18:56:16.07ID:CVxP3Mgt
>>792
「オブジェクト指向型プログラミング言語」はオブジェクト指向的な文法を備えてなきゃならないって話だろ？
だけど，>>769では「アセンブラではオブジェクト指向できない」と言っている．
これを「アセンブラはオブジェクト指向的な文法を持っていない」と解釈するのは無理があるよ．
常識的に解釈したら，「アセンブラではオブジェクト指向というパラダイムを適用してプログラミングは行えない」となるが，
それは偽だ，って話だ．

基本はそれだけとか知った風に上から目線で語る前に，ちゃんとした日本語と，オブジェクト指向とオブジェクト指向型言語の違いを勉強してきなよ．

第一「プログラミング言語に適用した場合」という言葉だって不明瞭でよく意味がわからないし，>>779に至っては「プログラミングにおける」とか言っちゃってる．
ここは雑談板じゃないんで，雰囲気で適当にレスしても馬鹿にされるだけだよ．他人にちゃんと伝わるように単語は選ぼうね．
0798デフォルトの名無しさん2014/08/29(金) 18:56:16.60ID:x0K1x8yK
>>795
基本的にC++時代にオブジェクト指向ってこんなのだろ？って
理解した(理解できなかった)50過ぎのボケ老人が立てたスレっぽいしな
0799デフォルトの名無しさん2014/08/29(金) 19:20:15.23ID:LlJ3/CSr
馬鹿ほど語りたがるのはなぜか
0800デフォルトの名無しさん2014/08/29(金) 19:31:01.33ID:AEpwYDBa
>>795
>>516は勘違いしてる
0801デフォルトの名無しさん2014/08/29(金) 19:35:58.27ID:AEpwYDBa
オブジェクト指向型アセンブラを作ることはできるが
既に出来上がってるアセンブラでオブジェクト指向プログラミングはできないってことだ
うまく伝わらなかったなら
表現を間違えたのかもしれんな
0802デフォルトの名無しさん2014/08/29(金) 19:43:46.82ID:AEpwYDBa
「オブジェクト」の部分を訳さないからおかしなことになってるんだよ
文字列オブジェクトとか関数オブジェクトとか的外れなこと言ってるし
0803デフォルトの名無しさん2014/08/29(金) 19:53:44.76ID:qSIH8ln/
ボトルネックになるくらい遅くなるって、どんな極限環境で実行してるんだよ
0804デフォルトの名無しさん2014/08/29(金) 20:17:15.53ID:7qeXFNLD
ボトルネックという程ではないけど、これが好きになれない
www.slideshare.net/MoriharuOhzu/ss-14083300/30

共通の範囲を走査するループは分割じゃなくて纏めたくなる
同一範囲のループを別けずにOOPする方法って無いのかな
0805デフォルトの名無しさん2014/08/29(金) 21:21:28.48ID:4xakm/Il
>>801
お前には無理
0806デフォルトの名無しさん2014/08/29(金) 21:56:33.99ID:NR1ZEKqi
オブジェクト＝「存在」は？
0807デフォルトの名無しさん2014/08/29(金) 21:58:49.67ID:CVxP3Mgt
>>801
だから，オブジェクト指向プログラミングってのは手法であって文法の話じゃないんだって．
逆に，いくら文法がオブジェクト指向的でも書くときにstaticメソッド一発とかにしたらオブジェクト指向とは言わないの．
すでに出来上がってるアセンブラでもオブジェクト指向プログラミングはプログラマーが手法に則ってアセンブラを書けば出来る．
0808デフォルトの名無しさん2014/08/29(金) 22:08:20.25ID:jKfXQ8mh
「オブジェクト指向」の「オブジェクト」は英語の"object"のニュアンスそのままだ。
敢えて日本語に訳すなら「物体・対象・目的」だ。
だから関数も変数もオブジェクトだ。（←こう書くと異論が出るからおもしろいw）
実際「関数オブジェクト」は普通に使うし、C言語のmanではintもfloatも"object"だ。
0809デフォルトの名無しさん2014/08/29(金) 22:18:39.43ID:XRKvgaw4
とりあえずオブジェクトを日本語化する所から始めないとダメみたいだなｗ
0810デフォルトの名無しさん2014/08/29(金) 22:28:06.67ID:6XulYCBt
>>808
日本でも「このはしわたるべからず」のトンチが昔からあるように、
ある単語("オブジェクト" や "はし")の意味が文脈に応じて異なるケースは
巷にありふれている
つまりオブジェクト指向に限定した文脈におけるオブジェクトの意味と
「だから関数も変数もオブジェクトだ。」のような一般的な文脈における
オブジェクトの意味は異なるよ、ってだけの話

日常生活に支障が無いレベルの日本語読解力がある人なら無問題だろ
0811デフォルトの名無しさん2014/08/29(金) 22:47:41.37ID:jKfXQ8mh
>>810
それはそうだが、「オブジェクト指向」という方法論は、プログラムのどの階層にもあてはまると思うわけよ。
どこまで階層を遡っても自己相似形的に「オブジェクト指向」。
あるクラス内に注目した時は、各メソッドがオブジェクトになる。
「メソッドに関数オブジェクトを渡す」とかも普通に言うでしょ。
だからオブジェクトの意味は異なるというのは、注目する階層が違うだけの話ではないか？
0812デフォルトの名無しさん2014/08/30(土) 00:02:16.92ID:oWf/0mO5
>>808
多態性をいってるんか
0813デフォルトの名無しさん2014/08/30(土) 00:21:42.32ID:fktBCnc4
>>811
>>810 では「C言語のmanではintもfloatも"object"だ。」とあるけど、
この "object" のクラスとメソッドは何か説明できる？
またCコンパイラの吐く "object"、いわゆる拡張子が *.o なバイナリファイル、
この "object" のクラスとメソッドは何か説明できる？

これらが >>810 で書いた「一般的な文脈」を指す
こうした文脈における "object" の意味と
オブジェクト指向に関する文脈における "object" の意味は異なるだろ？って話だ
08148082014/08/30(土) 00:52:34.17ID:KK5HFAk7
>>812
いや、多態性はクラスの事。関数/変数は多態しない。

>>813
わかる。>>808は定義を広げすぎて取り留めも無い。
ここでは「一般的な文脈」に限定して話をするべきとは俺も思っていた。
「オブジェクト指向」は今やソフトウェアだけじゃなく他の分野でも使われる言葉なので、
限定しないと論者によって語るオブジェクト指向の定義・階層がばらばらだと思った。

Cでもアセンブラでもオブジェクト指向で書けるって話と、
クラス・インスタンスをオブジェクトと見なして組むって話が、一緒になってるんだよ。
08158132014/08/30(土) 01:01:32.44ID:fktBCnc4
細かいけど、冒頭にあるアンカのミスを訂正

X：>>810 では「C言語のmanではintもfloatも"object"だ。」とあるけど、
O：>>808 では「C言語のmanではintもfloatも"object"だ。」とあるけど、
0816デフォルトの名無しさん2014/08/30(土) 07:46:37.08ID:y6eRt+7O
ここは馬鹿が多いなぁ。
「オブジェクト指向」は固有名詞だから分解して語ったり文脈で解析したりは、
あまりお薦めできないねぇ。
0817デフォルトの名無しさん2014/08/30(土) 08:34:21.49ID:lzdnFLDF
これだけ経っても正しい理解、自然な理解が進まないオブジェクト指向ってのは
どうも人間の思考に合っていないんだろう
これだけでやめた方がいいってのが分かるな
0818デフォルトの名無しさん2014/08/30(土) 08:42:17.34ID:KK5HFAk7
>>816
それを言ったら、「オブジェクト指向つったらオブジェクト指向だ。」これで終わる話だ。

>>817
こんなアホでもわかるパラダイムが理解できないなら、そりゃやめた方が良いw
0819デフォルトの名無しさん2014/08/30(土) 08:44:49.81ID:lzdnFLDF
そのパラダイムっての？
君しか理解していないみたいだよ
0820デフォルトの名無しさん2014/08/30(土) 09:46:45.81ID:lYnfbjsC
言葉遊びをしているだけならともかく、
まじめにオブジェクト指向談義をしたいのならまず、
「オブジェクト指向」は、大きく分けて
ケイのメッセージングの「オブジェクト指向」と
ストラウストラップの抽象データ型の「オブジェクト指向」があるから
そのどちらを指すのかを決めておかないと、（あるいは
どちらの話をしているのかをこの文章のように明示的にしないと）
ぐだぐだになるよ。

メッセージングのオブジェクト指向というのは、
いわゆる「オブジェクトにメッセージを送る」ってやつで、
文法によるサポートとかも考えられるけどそれは実は飾りで
本質は「いかにあらゆるものに遅延結合を実現するか」というところ。

抽象データ型のオブジェクト指向のほうは
いわゆる「カプセル化・継承・多態性」ってやつで
クラスという継承・多態性を実現できる言語機能を使って
「カプセル化」つまり「データ抽象」、簡単に言うと
「ユーザーによるデータ型の定義」をするプログラミングのこと。

両方とも言語のサポートがなくてもあるていど実践は可能だけれども
言語のサポート（前者なら動的結合や文法、後者ならクラスかそれに
準ずる抽象データ型をサポートする言語機能）があったほうがいいね、
ってそういう話で済むと思うのだけれども、異論ある？
0821デフォルトの名無しさん2014/08/30(土) 10:41:21.10ID:elcGSB9V
>>817
そういうのは他の方法論をマスターしている人の数を示してから言え。
0822デフォルトの名無しさん2014/08/30(土) 10:50:33.01ID:l1nrucEN
メッセージを送る、の話は聞き飽きた感はあるが今一度確かめたいのは、
それはメソッドを呼び出すのと何が違うのかと。
実際の型を抽象化されたオブジェクトに大してメソッドを呼び出すのと何が違うのかと。

あらかじめ型が居るやないかい、interfaceに相当するもんが要るやないかい、
だから違うんじゃい、と言うのならフーンという感じだが。
Rubyみたいに実行時にメソッド探せば委員会。
0823デフォルトの名無しさん2014/08/30(土) 11:26:39.17ID:wXeOH4Dw
>>822
同感だな

そもそも>>820の分類でいうとRubyやPythonなどはどちらに含まれるのだろうか？
説明を読む限りではどちらにも当てはめることができてしまうように思える

820はメッセージングとはあまり関係がなく、単に動的型付・静的型付の違いや
メタプログラミングの能力による違いの問題なのではないかな？
少なくともオブジェクト指向の本質とは関係ない話だろう
0824デフォルトの名無しさん2014/08/30(土) 12:02:34.17ID:xXPkmohR
メッセージだのカプセル化だの抽象化だのといった些末は
あくまでオブジェクト指向を実現するための手段であって
オブジェクト指向そのものではないだろ
オブジェクト指向を語ってるつもりで
実際は単なる手段を語ってるだけになってないか
0825デフォルトの名無しさん2014/08/30(土) 12:03:29.77ID:MCHhsO9U
>>824
では、オブジェクト指向そのものとは？
0826デフォルトの名無しさん2014/08/30(土) 12:48:33.41ID:lYnfbjsC
>>822
> それはメソッドを呼び出すのと何が違うのか

これは、ケント・ベックの「Smalltalkベストプラクティスパターン」とかにも
出てくるあるよくある疑問なのですが、パラダイムとそれをサポートする
仕組み（の実現方法）は分けて考えなければならないということです。

すでに書いた文法によるサポートとかと同様に、
メッセージであることも実際は飾りで、いわゆる方便のたぐいです。
メッセージのやりとりと考えると遅延結合を意識しやすいということです。
あくまで本質は、多くのことに遅延結合を実現できているか、の方です。

たとえば Smalltalk はメッセージ式といって文法上はメッセージングを
サポートしているように見えますが、ACTOR や Io、Erlang のように
ファーストクラスのメッセージを持つわけでありません。でも、
その本質である動的性を実現するための仕組みは、ここで挙げた
Smalltalk よりずっとメッセージングを実現している言語よりも充実して
いますし、ケイの考え方も実践しやすくできています。

実績としても、40年以上も動かしながら変化しつつけていけている処理系は
Smalltalk をおいてほかにはないのではないでしょうか。

ただ Smalltalk でなければメッセージングによるオブジェクト指向は
実践できないかというとそういうわけではないのは先に書いた通りです。
ここ、誤解のないようにお願いします。
0827デフォルトの名無しさん2014/08/30(土) 12:53:30.86ID:ndG8p1Qr
つまり、パラダイムとしてはメソッド呼び出しもメッセージングと同じ？
0828デフォルトの名無しさん2014/08/30(土) 12:55:25.34ID:9woGvbPx
>>823
> そもそも>>820の分類でいうとRubyやPythonなどはどちらに含まれるのだろうか？

メッセージングのOOP も、抽象データ型のOOP も、考え方や手法にすぎないので
どちらを設計者が意識してサポートしようとしたかで、どちらをどの程度やりやすいかは
決まりますが、どちらに属するか分類は不毛です。で、繰り返しになりますが
考え方を理解し、それを実現するための手法のいくつかを知り、意識さえすれば
（程度の差こそあれ）どんな言語でもある程度は実践は可能です。
0829デフォルトの名無しさん2014/08/30(土) 12:56:37.77ID:yDZGZz9U
メソッド呼び出しとメッセージングはイコールではない。

と聞いて大抵の人は

　　　　メソッド ≠ メッセージング

だと思ってしまうが違うんだ。

　　　　メソッド ∈ メッセージング

これが本当に言いたいこと。

確かにイコールではない。
0830デフォルトの名無しさん2014/08/30(土) 12:57:51.49ID:9woGvbPx
>>827
メソッド呼び出しであっても、メッセージングと解釈することは可能（自由）ということです。
繰り返しになりますが、大事なのはこの場合のメソッド呼び出しが動的に
行なわれるか（あるいはそのように考えても問題ないように行なわれるか）ということです。
0831デフォルトの名無しさん2014/08/30(土) 13:00:09.37ID:yDZGZz9U
さて

「目玉焼き」と「卵料理」は違う。

と言われてどう思うかな？
0832デフォルトの名無しさん2014/08/30(土) 13:01:57.31ID:0XAXNCiU
メッセージングが目的で、メソッドが手段って感じかな。
0833デフォルトの名無しさん2014/08/30(土) 13:04:17.05ID:eCJzIMUL
>>828
> メッセージングのOOP も、抽象データ型のOOP も、考え方や手法にすぎないので

>>830
> メソッド呼び出しであっても、メッセージングと解釈することは可能（自由）ということです。

うん、ここまでよくわかる。俺の認識もそれ。

> メソッド呼び出しが動的に行なわれるか（あるいはそのように考えても問題ないように行なわれるか）ということです。

まぁOOPに消極的なOOPLじゃあそれがあるから、その点の指摘は必要か。
0834デフォルトの名無しさん2014/08/30(土) 13:18:35.81ID:9woGvbPx
>>823
>少なくともオブジェクト指向の本質とは関係ない

ケイやストラウストラップ以外にも独自の「オブジェクト指向」を主張する人は
もちろんいます。ただ、それらもこの二人の「オブジェクト指向」の影響を
程度の差こそあれ受けていますから（というか、彼らの「オブジェクト指向」を
無視して「オブジェクト指向」を語るのは事実上モグリです）、二人の
主張をきちんと区別して理解し、それをベースに議論すると、
その他の独自オブジェクト指向も整理がつきやすいはずです。
0835デフォルトの名無しさん2014/08/30(土) 13:32:17.20ID:9woGvbPx
メソッドとメッセージの件ですが、
以下は Smalltalk の話なのであくまで参考まで。


「メソッド」と「メッセージ」は別物で明確に区別されるべきです。
両者の関係は「メッセージの送信はメソッドの動的呼び出しの手段の一つ」です。

Smalltalk は文法としてメッセージ式と呼ばれる記法を採用していますが、それは

obj key1: arg1 key2: arg2 key3: arg3

というもので、この場合、key1: arg1 key2: arg2 key3: arg3 がメッセージ、
key1:key2:key3: がその結果呼び出したいメソッド（の名前）となります。

ただ通常の言語では（: をメソッド名に含められない言語が多いので _ に置き換えると）
obj.key1_key2_key3_(arg1,arg2,arg2) となるので、
key1_key2_key3_(arg1,arg2,arg2) がメッセージ、key1_key2_key3_ がメソッド名と
読み替えることもできますが、多くの場合は引数を省いた key1_key2_key3_ を
メッセージとする人が多いので、くだんのよくある疑問が生じるわけです。
0836デフォルトの名無しさん2014/08/30(土) 13:37:12.03ID:enJZJoZc
>>835
なるほど。
恥ずかしながら今の今まで完全に勘違いしてた。
メッセージと引数、みたいにぼんやりとそれを眺めてた。
この勘違いで今までいろいろ余計な誤解生んでたんだろうなｗ
0837デフォルトの名無しさん2014/08/30(土) 13:45:24.00ID:9woGvbPx
>>836
メッセージに関しては、メソッド名部分のみをメッセージと信じる派閥も
Smalltalk使いにすら一定数いて、Objective-C（ほぼ同じ文法でメッセージングを
表現します）になると、大多数を占めるまでになります。もちろん
発案者のアラン・ケイの定義に照らせば完全な間違いなのですが、勘違いでも
そう信じた人たちが教科書的な記述で流布すれば誤解も広がり定着します。
メッセージ式を持たない言語でなら、なおさらで困ったものです。
0838デフォルトの名無しさん2014/08/30(土) 14:18:15.58ID:SnBvB4qP
オブジェクト指向のモデリングのお題として使えそうな良い題材を教えてください。
「Animalクラスを継承してCatクラスを作ります」なんてのは勘弁してください。実際の現場で猫をモデリングするなんてまずありえませんから。
あくまでも実践に役立ちそうな具体的なサンプルをお願いいたします。できれば継承の具体的なパターンが欲しいですね。
0839デフォルトの名無しさん2014/08/30(土) 14:24:55.85ID:cF3O+Nfc
>>837
お主、分かっているねえ。
少し感心した。
0840デフォルトの名無しさん2014/08/30(土) 15:02:33.73ID:wXeOH4Dw
いやいやID:9woGvbPxはSmalltalk（とアラン・ケイ）に囚われすぎだろう

ものすごいこだわりを感じるけど、大多数の人にとっては「メソッド」と「メッセージ」の区別は興味が無いだろうし
ましてや、「メッセージ」に引数が含まれるかどうかなんて、さらにどうでも良いことだろう

「オブジェクト指向」と言った場合も、大多数の人はSmalltalkの動的結合の側面には興味が無いだろうし、
このスレでもその意味で話をしている人は居ないだろう
かといって、それが「ストラウストラップの抽象データ型のオブジェクト指向」の話かというとそれも違うわけで、
結局>>820の分類がおかしいのではないか

原理主義的な人にとっては許し難いことだろうけど、オブジェクト指向一般の話をするときには、むしろ
Smalltalkは持ち出さない方がいいのではないかと思う
あまりに特殊すぎるし古すぎるし知ってる人が少なすぎる
0841デフォルトの名無しさん2014/08/30(土) 15:12:16.25ID:3J76hEg2
Smalltalk自体は価値あるアプリやサービスを生み出す事は
出来なかったが、パクったObjective-Cがそこそこ成果を出したんだし
そんなに邪険に扱うもんじゃないよ
0842デフォルトの名無しさん2014/08/30(土) 16:08:08.10ID:EKM9eCJc
>>840
おっしゃるとおり、なにがメッセージで、
ましてメッセージに引数を含めるか否かなどの話は
そもそも論にすぎず、本質ではありません。

取り違えないでいただきたいのは、あくまで本質は
いかに多くのことを動的に保つかです。
たしかにSmalltalkほどこれを実践できている言語や仮想環境は
ありませんが、ほかの言語処理系ではそれを適切な範囲で
言語に限定的に実践しようとしていると解釈すれば、
身近にあるメッセージングのOOP も、ケイがもともと
提唱したものからそれほど遠いものにはならないはずです。
0843デフォルトの名無しさん2014/08/30(土) 17:24:35.44ID:+pqxcB8M
>>840
別にID:9woGvbPxは原理主義的じゃないだろｗ
アランケイのOOPこそが、みたいな論調は一つもなかったはず。
0844デフォルトの名無しさん2014/08/30(土) 21:42:34.90ID:gtgir/0Z
相変わらずなにもないなここ
0845デフォルトの名無しさん2014/08/30(土) 22:05:42.19ID:ytu69tpt
机上の空論だよね
現場なんて無視だよね
0846デフォルトの名無しさん2014/08/30(土) 22:24:03.99ID:9woGvbPx
あと ID:wXeOH4Dw が もしJS使い、もしくはPython使いならこれまでの論調に
違和感を覚えるのはしかたがないことかもしれません。

世の「オブジェクト指向」が、すでに述べたケイのメッセージングのOOP と、
ストラウストラップの抽象データ型のOOP に端を発しているのは事実ですが、
この二つに加えて現在ではプロトタイプベースのOOP の影響も無視できなく
なってきているからです。

プロトタイプベースのOOP というのは、もともとは、アンガーとスミスが
ケイ（というよりはSmalltalkから外挿した）メッセージングのOOP を
純化・徹底しようと試みて作られた SELF という言語に端を発してはいますが、
その後、必須の要素の単純化を進めるうちに、メッセージングというメタファすら
不要となってそぎ落とされ現在に至ります。お題目とはいえ、メッセージングという
キーコンセプトから解き放たれた以上、メッセージングのOOP に属するというは
無理がありますよね。

言語要素にフレーム（オブジェクト）とスロット（プロパティ、インスタンス変数）、
そして関数オブジェクトがあれば十分という考え方です。JS は言うまでもなく
Python もプロトタイプベースOOP の素養を持っているので、メッセージングか
抽象データ型かという単純な分類には当てはまらないわけです。

ところで、Python はとても興味深い言語で、オブジェクトモデルはプロトタイプ
ベースOOP を指向していながら、言語機能は動的型ながら抽象データ型のOOP を
強く意識しており、それだけではなく、組み込みのライブラリなどは適所に
狭義の「抽象データ型」、つまり、クラスの中（メソッド）だけではなく
外にも関数を持つスタイルを活用するというキメラな性格を有しています。
0847デフォルトの名無しさん2014/08/30(土) 22:47:02.35ID:9woGvbPx
いまさら言ってもしかたがないことですが、
「オブジェクト指向」は発案者それぞれが、名前の付け方を完全に間違いました。

ケイは彼のそれを「メッセージ指向」と名付けるべきでしたし、
ストラウストラップは同じく「クラス指向」と名付けていればどんなによかったか。
ついでにプロトタイプベースOOPも「フレーム・スロット指向」とでも名乗っていれば
それぞれの学習者・実践者は「オブジェクト指向」という言葉に惑わされることなく、
もっとすんなりそれぞれのパラダイムの特徴を会得できただろうにと悔やまれます。
0848デフォルトの名無しさん2014/08/30(土) 22:59:14.91ID:KK5HFAk7
>>847
人間が最初に注目した概念がオブジェクトだったって事でしょ？（SIMULA）
今ではどちらも可能な言語が主流なので、分類学には意味は無くなったかもしれないけど。

それとあなたのおかげで、アランケイが「メッセージング（遅延結合）も重要なんだぜ」って言うのもわかったよ。
結局、規模と複雑さの問題を解決できた方法は今現在それしかないし、
もっといい方法があるなら教えて欲しいけど。なんかあります？
0849デフォルトの名無しさん2014/08/30(土) 23:10:27.86ID:KK5HFAk7
>>847
それと命名だけど、確かに間違ったのかもしれないけど、
メッセージに先立ってオブジェクトという概念がなきゃならないから、仕方ないでしょう。
オブジェクト+メッセージで初めてスケーラビリティを獲得したっちゅう事だよね？
0850デフォルトの名無しさん2014/08/30(土) 23:15:05.54ID:aRBxMZZr
Simuraって1962年か
Wikipediaからだけど

> Simula 67 ではオブジェクト、 クラス、サブクラス、継承、動的束縛（仮想関数）、
> コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
> オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。

たいしたもんだねえ
2014年まで生き残ってるアイデアっつうのは

ダイクストラが構造化プログラミング言い出したのが1968年ってのも不思議な気分になるなぁ
こっちはこっちで恩恵計り知れないけど

悪魔が出てきて怖い顔でどっちか一つだけ選べ一つだけ人類に許すって言ったら
構造化でオナシャスって言うだろうなきっと
0851デフォルトの名無しさん2014/08/31(日) 00:03:30.10ID:VM252+zm
ちゅうか90年代以降出て来たものって、殆ど既存の焼き直しだったりする。
0852デフォルトの名無しさん2014/08/31(日) 00:08:02.71ID:Zl7OUBRG
仕事中には私はオブジェクト指向が何であるかを知っている。
しかし、それを尋ねられると私には分からなくなる。
0853デフォルトの名無しさん2014/08/31(日) 00:08:37.23ID:Zl7OUBRG
>>851
言語の統廃合が欲しいところだな
0854デフォルトの名無しさん2014/08/31(日) 00:31:50.61ID:jMVPb3Gf
>>849
そうですね。ただ厳密にはケイはスケールすることより
可塑性（言語処理系の仕組みも含めて変容できること）を
重視したのだと理解しています。その結果、もちろんスケールも
するので解釈としては問題ないとも思いますが。

あとちょうど>>850でSIMULA67の話が出たので絡めると、
ケイのオブジェクト指向は、「メッセージ」の受け手に
SIMULA67の「オブジェクト」を採用したことが特徴であり、
他方で、ストラウストラップのオブジェクト指向では、
ユーザー定義型（抽象データ型）にSIMULA67の「クラス」を
採用したことに意義があると考えると、SIMULA67と
そこから生まれた二つの「オブジェクト指向」の関係が
すっきりと整理できるかと思います。
0855デフォルトの名無しさん2014/08/31(日) 02:22:53.22ID:h6iDCE41
車の例が前の方に出てたが、Swift の例題にも出てるな。

乗り物を作り、

そこから継承して、車の数や、乗車人数で新しい概念を作って行く。

部品の細かな仕様は作る段階(イニシャライザ)で与えれば良い。

設計手法から見ると再利用可能な様に定義して行くことが重要だろう。

エンジンが重要であれば、それを別のオブジェクトとして交換可能にしておくとか。
エンジンが関数であれば、関数名で動作を切り替えるとか出来ると良いね。
人力、ガソリンエンジン諸々。

いかに後で自由な利用が出来るかどうかが言語の特徴になってくるんだろう。
0856デフォルトの名無しさん2014/08/31(日) 03:55:49.76ID:XMVOnZ3y
>>838
何かテーマを頼む
0857デフォルトの名無しさん2014/08/31(日) 09:55:37.87ID:e0Pxtdap
ボタンを基本クラスにして、それを継承してチェックボックスやラジオボックスを作る
0858デフォルトの名無しさん2014/08/31(日) 10:22:03.39ID:VM252+zm
>>838
ワールドクラスの開発者が書いたコードをいろいろ調査してみるのが一番だと思う。
0859デフォルトの名無しさん2014/08/31(日) 10:25:06.05ID:VM252+zm
>>838
ちゅうかSmalltalkアプリの解析がお薦めだと思う。オブジェクト図を
書いて協調関係を見たりとか。継承はあんまりに気にしなくていいと思う。
0860デフォルトの名無しさん2014/08/31(日) 10:48:44.46ID:cGOsOgKR
Smalltalkをちょっといじってみたい人のための、チュートリアルまとめ
http://qiita.com/sumim/items/6bed17961bd57daf88a3
0861デフォルトの名無しさん2014/08/31(日) 14:40:23.50ID:dK8Z1XNh
>>838 なんだって同じだろ。
動物から、猫だって
アバターから、女性用、男性用とか
そんな事も応用/想像/利用も出来なさそうだったらプログラムはやめた方が良い。

全くの初心者だったらこんなところで聴くよりもちょっとした本を見て適当なオブジェクト指向言語で練習すれば良い。

身を以て経験し無いと絵空事に終わるよ
0862デフォルトの名無しさん2014/08/31(日) 15:27:42.29ID:ehnf7Mu/
おおむね同意。結局は本なんて入り口の入り口だからなぁ。
結局は本人の応用力にかかってる。

動物犬猫ワンニャンは批判されがちだけど、
それすら手垢着き過ぎて今更そんな批判聞きたくも無いｗ

今となってはそれで別にいいんじゃねえの？とすら思う。
応用力のある人ならそれで十分ピンと来るだろうしね。
0863デフォルトの名無しさん2014/08/31(日) 15:46:05.25ID:e0Pxtdap
聞いてもいないのに説教垂れ出す人は
もうすこし我慢することを覚えたほうがいいな
0864デフォルトの名無しさん2014/08/31(日) 16:37:38.71ID:KqVPQ91w
>>861
アバタークラスを継承して、男性クラスと女性クラスをつくる？
アバタークラスに性別プロパティ持たせればいいんじゃないの？
ろくに検討もせずほいほい継承すると複雑さを招くだけだと思うけど...
0865デフォルトの名無しさん2014/08/31(日) 16:46:16.19ID:ehnf7Mu/
ホイホイ継承することによって、
それによるまんどくさい局面を見ることができるなら、
学習のため、意味があるとも言えなくも無い。
08668132014/08/31(日) 19:26:49.08ID:GHjDfw2e
>>838
>>194の四角形クラス継承は？
0867デフォルトの名無しさん2014/08/31(日) 19:49:31.14ID:KqVPQ91w
実際に四角形クラスを継承して正方形クラスをつくる選択することの方が多いのかな？
四角形クラスに、isSquareってプロパティを用意するだけで十分な気がするけど
ドローソフトだって、長方形と正方形を切り替える度にインスタンスの生成し直しになちっやうでしょ
0868デフォルトの名無しさん2014/08/31(日) 20:16:19.63ID:ipF4eAwT
ゲームかなにか作ってて、物体の操作を入力デバイスから受け付けたい。
キーボード、マウス、ゲームパッドそれぞれの入力を操作情報に変換するクラスを
KeyboardController、MouseController、GamePadControllerとかにして、抽象クラスとしてAbstractControllerを作っておく。
こうしておけば、新しくWiiリモコンとかWii FitとかKinectとかで操作できるようにしようと思ったらAbstractControllerを継承したクラスを実装するだけで済む。
みたいなのどう？
0869デフォルトの名無しさん2014/08/31(日) 20:24:13.04ID:GHjDfw2e
>>847,854
「ケイのオブジェクト指向」がメッセージングに重きを置いているのは分かる
ケイが Smalltalk プロジェクトに関わっていた時期は、
それがオブジェクト指向の定義だったのかもしれない
ただし、今日「Smalltalk のオブジェクト指向」という文脈における「Smalltalk」とは、
ケイが去った後にプロジェクトを引き継いだ共同開発者であるゴールドバーグが開発した
「Smalltalk-80」を指しているのではないかと思う

ケイは Smalltalk を子供達の教育用途を想定した言語として考えていたから、
オブジェクトやメッセージという言葉でオブジェクト指向を語る一方で、
「クラス」や「継承」という数学的な言葉よりも「ファミリ」や「ファミリに属す」という
直感的に分かりやすい言葉を選んでオブジェクト指向プログラミングを語っていた
これが「ゴールドバーグの Smalltalk-80」になると、近代的なソフトウェア工学の知見を取り込み
「カプセル化、継承、ポリモーフィズム」といった言葉でオブジェクト指向を定義している
（そのソフトウェア工学の知見を取り込んだ成果が(ケイの時代には存在していなかった)
　クラス継承を巧みに活用したSmalltalk-80 のクラスライブラリと統合開発環境になる）

つまり、ここまでをまとめると、同じ「Smalltalkのオブジェクト指向」であっても：
・「ケイのオブジェクト指向」は「メッセージング」に重きを置く
・「ゴールドバーグのオブジェクト指向」は「カプセル化・継承・ポリモーフィズム」に重きを置く
という(重視する)視点に違いがある
そして「ストラウストラップのオブジェクト指向」もまた「カプセル化・継承・ポリモーフィズム」
によって定義されているから「両者の違いはどこにあるの？」混乱が生じている
（その答えは、すでに >>630,640 で書いている）
0870デフォルトの名無しさん2014/08/31(日) 20:27:50.25ID:0hF6FVoq
オブジェクト指向に対応していない言語・・・
例えば汎用機のCOBOL等でもオブジェクト指向的に
プログラムを組んでシステムを作る事は有効でしょうか？
0871デフォルトの名無しさん2014/08/31(日) 20:31:37.74ID:v25oQIh2
>>870
最近のCOBOLはOO対応してるの多いぞ
0872デフォルトの名無しさん2014/08/31(日) 20:32:50.51ID:q0Nm8R9Q
へーおまいらくわしいね。
そろそろ合意が取れちゃうのかな？
OOPの本質とは「カプセル化・継承・ポリモーフィズム」である。

いやいやそれは手段であって…という話にやっぱりなるのだろうかｗ
0873デフォルトの名無しさん2014/08/31(日) 21:03:17.42ID:XMVOnZ3y
>>872
具体的でかつ広まっている手段、かなと思う
無視することは出来ないぐらい大きな存在だが
OOPとはカプセル化継承ポリモーフィズムのことである、と言われると、う〜ん
0874デフォルトの名無しさん2014/08/31(日) 21:05:34.96ID:ZHoB3ty7
>>868
実際の現場ではやっぱ継承といえばコントローラ系で、エンティティ系の継承ってそんなに出てくるもんじゃないよね。
下層レイヤでDAOやORMのベースモデルを継承してってのはあるけど、ビジネス層での継承って滅多にお目にかかれない。
事務系のシステムで「家具クラスを継承して、机クラスをつくります。」なんてバカな設計やってる場合じゃないしね。CADの素材用とかならあり得るかもしれんけど。
ＯＯＰはどっちかっつうとフレームワーク屋の設計ツールになってしまっている感がある。
0875デフォルトの名無しさん2014/08/31(日) 21:39:06.53ID:wWz3KGKv
>>873
> う〜ん

俺なんか「OOPとはカプセル化継承ポリモーフィズムのことである」と言われたら、
ゆっくり頷きながら「うん、そやね」と答えるだろう。

由来や歴史を語る上でそれらをイコールにしたらそりゃもう非難されるだろうけど、
日々の暮らしで「OOPのメリットは？」などと語る上では、イコールと言って差し支えないと思う。
0876デフォルトの名無しさん2014/08/31(日) 22:50:22.10ID:OTaMWp4O
オブジェクト指向の核心部分ってやっぱり擬人化したもの同士のメッセージのやりとりを
プログラムに落とす事で、「カプセル化・継承・ポリモーフィズム」等は単なる品質、再利用
性向上の手段だな。

　広まる時は商業的理由か前者は後者に埋もれて返って回りくどくなったというか。
0877デフォルトの名無しさん2014/08/31(日) 23:42:03.72ID:ORDwa/D0
擬人化だの言ってるから回りくどいんだよ
オブジェクトはメモリ上のデータの集まりだろ
0878デフォルトの名無しさん2014/08/31(日) 23:46:59.05ID:OTaMWp4O
>>877
>オブジェクトはメモリ上のデータの集まりだろ

それだったらアセンブラでプログラミングすりゃすむ話だけど。
0879デフォルトの名無しさん2014/08/31(日) 23:55:56.51ID:HWtpT9Tz
また小さいスコープでループしてるのかw
0880デフォルトの名無しさん2014/09/01(月) 00:22:14.88ID:WmSwoar8
たとえば抽象クラスAとその派生クラスB,C,Dがあるとき
Aにある共通メソッドを全ての派生クラスに対して実行したいとき
イテレータつかって１回まわせば済むと思うけど
これをオブジェクト指向言語以外で書くと面倒じゃない？
0881デフォルトの名無しさん2014/09/01(月) 00:39:19.55ID:4l8NqaAL
>>880
いきなりどしたん？
0882デフォルトの名無しさん2014/09/01(月) 01:34:36.15ID:NpQbOBlC
>>877
プログラムはデータとコードだからな
んでデータの方がオブジェクトとなる

コード主体にするかデータ主体にするかが論点で
この後者がオブジェクト指向ってことだ
0883デフォルトの名無しさん2014/09/01(月) 02:31:56.27ID:oasrXTsG
オブジェクトは関係するデータの集まりだ。その中にはメソッドもある。
ストリームＩＯの派生を扱うにも、それがデバイスであるか通信であるかなどによって処理の仕方が異なる。
処理の仕方もオブジェクトの一部だ。
0884デフォルトの名無しさん2014/09/01(月) 02:42:00.52ID:Aoi0Spsz
Swiftだと変数であろうが関数であろうが全てがオブジェクトとして扱える。
オブジェクトだから自由自在に受け渡しが可能
0885デフォルトの名無しさん2014/09/01(月) 04:53:26.11ID:fs0t73z3
車のエンジンを毎回新設計するみたいなことしなくても
"継承"すれば3型エンジンを3型エンジン改みたいにできる！
ってのが継承のアピールポイントだったんだけど
どんどん考え方が拡大していくにつれて
"これはこれの改"ってのが扱いづらいというか
"エンジンルーム"って場所につながる線(インターフェイス)を共通にして
中のものはガソリンだろうがディーゼルだろうが電気だろうが
考えずに差し替え可にした方が取り回しが楽だろう。ってんで
最近は"継承"って考え方は流れとして割と下火
(「これはこれの子」じゃなくて単純に新しいオブジェクトの中に「パーツとして入れて再利用」する)
0886デフォルトの名無しさん2014/09/01(月) 05:02:32.65ID:oGWG6Nzh
そう、継承に適したパターンならいいけど、
なんでもかんでも継承でやっちゃうと、かえってややこしい場合がある。
0887デフォルトの名無しさん2014/09/01(月) 07:31:32.36ID:7AvYn8bh
読み書き両方有るファイルクラスを継承した、
出力専用のログファイルクラスを見たこと有るｗ
もちろんpublic継承で。

確かに名前からすると継承したくなるだろうけどさ。
0888デフォルトの名無しさん2014/09/01(月) 09:47:12.48ID:Y3qdtj8+
>>887
普通にアリだろ。
0889デフォルトの名無しさん2014/09/01(月) 09:48:27.31ID:Y3qdtj8+
public継承ってのが意味わかんないけど。
0890デフォルトの名無しさん2014/09/01(月) 11:40:18.28ID:oGh1XfS9
ストラウストラップの抽象データ型のオブジェクト指向は
よく「カプセル化、継承、多態性」というキャッチフレーズで語られますが
このどれが本質なのか？　まずここから読み解いてみましょう。
くどいようですが、この文脈では「メッセージを送って」とかは忘れましょう。

「カプセル化」というのはデータ抽象、抽象データ型のことです。
抽象データ型というのはこの簡単には「ユーザーが定義したデータ型」と
読み替えて大丈夫です。
（ストラウストラップの What is OOP? [1988,1991改訂] を参照のこと）

ストラウストラップ(同時期にメイヤー、リスコフも同様の主張をしている）らの
抽象データ型のオブジェクト指向は、
抽象データ型にSIMULA67の「クラス」という言語機能を用いるアイデアです。
つまり抽象データ型が主（目的）で、クラスは従（手段）なので注意してください。

ちなみに抽象データ型はクラスを使わずとももちろん実現できます。
たとえば関数型言語のいくつかはクラスを使わず狭義の抽象データ型機構を用いて
ユーザー定義型を実現しています。そして後述のとおり問題が指摘されている
クラスによる継承よりもっとうまく安全に多態を実現しています。

残りの「継承」「多態」というのは、カプセル化にクラスを用いた結果
SIMULA67のクラスが元々持っていた継承という機構により差分プログラミング
が可能であることや、継承を使った結果、基底・派生の継承関係を持つ
クラス（データ型として使用）によって、多態が可能になるということです。

ただ、このようにクラスをデータ型と見なし、派生クラスをもって派生型を作ることは
問題があることが90年ごろにクックにより指摘され、今は彼が推奨した
インターフェイスを型の派生に用い、クラスの派生は実装の継承のみに
用いるのがその後の主流になっています。
0891デフォルトの名無しさん2014/09/01(月) 13:31:50.42ID:oGh1XfS9
抽象データ型については名付け親のリスコフのが参考になります。
http://www.cs.iastate.edu/~hridesh/teaching/362/07/01/papers/p50-liskov.pdf

が、後に書かれた解説のほうが歴史背景を踏まえていてわかりやすいかもしれません。
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.9499 の Section 2

ストラウストラップの抽象データ型のオブジェクト指向、つまり
ユーザー定義型の実現にクラスを使うアイデアについての本人の解説。
http://www.stroustrup.com/whatis.pdf

クラスをデータ型と見なして継承で派生型を実現することの問題点についてはこちら。
https://www.cs.utexas.edu/users/wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf

クックらによる「インターフェイス」という言語機能の提案についてはこちら。
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf
0892デフォルトの名無しさん2014/09/01(月) 15:25:45.10ID:giBOZVVu
委譲が適切な場面で継承して徒にクラス増やしたコード読むのは辛いです。
0893デフォルトの名無しさん2014/09/01(月) 18:14:00.75ID:RD/5UcwV
>>888
ログ出力に関係無いメソッド群がごっそり付いてくるんだぞ？
読み取りやファイルポインタの移動とか。
0894デフォルトの名無しさん2014/09/01(月) 18:43:38.42ID:Y3qdtj8+
>>893
データモデルで変更をごっそり禁止して継承と同じじゃん。
まあ、ログファイルの仕様を知らないけど。
0895デフォルトの名無しさん2014/09/01(月) 19:25:39.06ID:4sz8O0Yw
別なオブジェクトでラップして関係ないメソッド群は
見えない(使えない)ようにしとくのが"いまふう"の考え方だよね。
使用であって継承ではないよと
0896デフォルトの名無しさん2014/09/01(月) 21:31:16.33ID:4/+EiQVN
>>889
Javaなどで言うところの、普通の継承はC++で言うとpublic継承。
C++にはprivate継承やprotected継承ってのもある。
0897デフォルトの名無しさん2014/09/01(月) 23:40:57.12ID:cS7Lo3Z1
「オブジェクト指向」という言葉自体が意味をなしていないんじゃ
0898デフォルトの名無しさん2014/09/01(月) 23:46:05.61ID:oGWG6Nzh
オブジェクト指向ってのは、かなり漠然とした広いくくりなんだよ。
そう捉えると、上の議論はすべて整合するだろ。
0899デフォルトの名無しさん2014/09/02(火) 00:09:41.90ID:V9Jb92Vc
なにを言ってるんだおまえはw
0900デフォルトの名無しさん2014/09/02(火) 00:31:23.37ID:XKHIGyV2
細かく分類されるんだからそういう事だろ。
0901デフォルトの名無しさん2014/09/02(火) 00:44:02.08ID:BxPdE7CF
カプセル化・継承・ポリモーフィズムなどいくつもの概念が組み合わさって構造化を更に
組織化した物じゃないか？
0902デフォルトの名無しさん2014/09/02(火) 00:50:20.85ID:V9Jb92Vc
それはフレームワークじゃないか。
0903デフォルトの名無しさん2014/09/02(火) 00:57:37.63ID:XKHIGyV2
共通してるのは、「ナントカをオブジェクトと見なす」これだけじゃないか？
0904デフォルトの名無しさん2014/09/02(火) 01:02:51.10ID:V9Jb92Vc
オブジェクトはライブラリーなのだからフレームワークと同じじゃないか？
0905デフォルトの名無しさん2014/09/02(火) 01:05:08.10ID:gs4puFO8
Golang なんてクラスに継承すらないからオブジェクト指向と名乗ることが出来ない。
そりゃそうだ、オブジェクト指向から継承をとったら利用価値が半減以下になるからな。
何でこんなかたわの仕様にしたんだろ
0906デフォルトの名無しさん2014/09/02(火) 01:27:56.97ID:gs4puFO8
>>904 何言ってんだよ、ライブラリなんかじゃ無いよ。
れっきとした言語仕様、文法としてサポートしていなければならない

古い言語でライブラリでオブジェクト的にごまかしてるのも有るかもしれないがそれは正統派とは言えない。
0907デフォルトの名無しさん2014/09/02(火) 01:39:59.19ID:V9Jb92Vc
仕組みは同じじゃないかw
0908デフォルトの名無しさん2014/09/02(火) 01:56:14.53ID:OAvH1Kkv
分類する単位が機能でなくてオブジェクト。
0909デフォルトの名無しさん2014/09/02(火) 01:56:33.64ID:gs4puFO8
>>907 そう言うのは、非オブジェクト指向言語にオブジェクト指向機能を追加した物だから、オブジェクト指向言語とは言わない。
0910デフォルトの名無しさん2014/09/02(火) 02:00:29.14ID:V9Jb92Vc
フレームワーク言語と改名したらいい。
0911デフォルトの名無しさん2014/09/02(火) 04:07:40.75ID:vngmZpQR
オブジェクトはフレームワークでもライブラリでも、ましてや言語仕様でもねえよ
オブジェクトは「概念」。オブジェクト指向という考え方における基本単位だ

オブジェクト指向プログラミングにおいては、細かいものでは数値、文字列などをオブジェクトとして扱い
それら細かいオブジェクトを組み合わせたものもまた、オブジェクトという単位にまとめて扱うこともできる

大きなものではアプリケーション全体や、プログラミング言語そのものもオブジェクトとして扱うことすらあるし
データに限らず信号、命令などをオブジェクトをみなしてやり取りすることも概念上はアリだ
具体的な実体でなく、漠然とした概念をオブジェクト指向的に表現することも可能、もちろんオブジェクト指向上の概念も

いずれにしろ、プログラミング上扱いたい様々なものをオブジェクトという同じ単位として表現することができる
こうして表現されたひとつひとつのモノや概念などが、オブジェクト
表現したものはすべてオブジェクトだし、表現しなかったモノや概念も、その場では必要なかっただけですべてオブジェクトにはなり得る
ただそのプログラムにおいてはオブジェクトとして表現する必要がなかっただけだ
0912デフォルトの名無しさん2014/09/02(火) 08:43:53.76ID:S8CK+9Gm
複数インスタンス作りたいケースって大体限られてるよね
ほとんどのケースでは生成するインスタンスは１つだけだよね？とくに事務系ソウトでは
マルチスレッドに対応するために複数インスタンスが必要だというなら、ちょっとオブジェクト指向の本来の趣旨からは外れてるよね
0913デフォルトの名無しさん2014/09/02(火) 08:46:49.09ID:4W2L00Fu
> 複数インスタンス作りたいケースって大体限られてるよね

多くね？

まず、GUIのパーツはだいたい複数インスタンスだよね。
ゲームのキャラクターも複数インスタンスだよね。

業務系にしたって、顧客、売上、トランザクション、
これらも全部複数インスタンス。

逆に複数インスタンスでないものってなによ？
0914デフォルトの名無しさん2014/09/02(火) 08:52:15.82ID:hWaDCuQb
ＤＢから吸い上げた大量の顧客情報を画面に表示したいときはインスタンスたくさん作らない？
0915デフォルトの名無しさん2014/09/02(火) 09:07:48.02ID:S8CK+9Gm
>>913-914
うん、だから大体そんなもんでしょ
業務系だとDB絡みがほとんど
ケース的には両手で余るぐらい
0916デフォルトの名無しさん2014/09/02(火) 09:15:24.07ID:OAvH1Kkv
それが業務系の9割だから、両手で余るな。
0917デフォルトの名無しさん2014/09/02(火) 09:30:51.08ID:ja7HZQJ9
>>915
質問

逆に複数インスタンスでないものって何よ？
0918デフォルトの名無しさん2014/09/02(火) 09:54:26.50ID:S8CK+9Gm
ん？
たとえば、ビジネスロジッククラスとか、MVCのCとかVもほとんど1つでOKだし、DBへのコネクション管理クラスとか、ファイルIO関連のクラスとか、画面表示クラスとか、ユーティリティ関数クラスとか、いっぱい
そもそもDBのモデルやエンティティにしても、あえて複数インスタンスを生成しなくても、ループの中だと１つのインスタンスで済む場合が多いし、関数化とかでスコープを局所化することでも対処できる場合が多い。
１つのスコープの中で、同じクラスのインスタンスが複数必要なケースって少なくね？
あ、文字列とか数値とかのプリミティブな型は別ね
0919デフォルトの名無しさん2014/09/02(火) 10:08:48.50ID:hWaDCuQb
まあ業務系っていったら、顧客や商品といったオブジェクトもあるけど
それらを使うfacadeパターンのクラスのほうが多くなるし、
それらは普通、複数インスタンス化なんてしない。
0920デフォルトの名無しさん2014/09/02(火) 10:15:49.08ID:gs4puFO8
>>911　そう言ってるじゃない。　オブジェクトは概念だからオブジェクト指向プログラミングはどんな言語でもできるが

文法上全てをオブジェクトとして扱えるものが純粋なオブジェクト指向言語
クラスは元より変数も関数も演算子も型も全てオブジェクトとして取り扱え継承もオーバロードも持ち運びも出来る

オブジェクト指向プログラミング
https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

純粋なオブジェクト指向プログラミング言語
当初からオブジェクト指向プログラミング言語として設計されたもの。Smalltalk、Eiffel、Self、Ruby、Swiftなど。

ハイブリッド型オブジェクト指向プログラミング言語
非オブジェクト指向プログラミング言語にオブジェクト指向機能を拡張したもの。Simula、C++およびObjective-C、CLOS、Object Pascal、COBOL、Javaなど。
（Objective-CやCLOSはオブジェクト指向部分そのものは純粋。C++などは既存文法の拡張に当たる）。
0921デフォルトの名無しさん2014/09/02(火) 10:24:19.16ID:ja7HZQJ9
>>918
> MVCのCとかVもほとんど1つでOKだし

っていうけどさ、CもVも特定のクラスを継承するでしょ？
そうすると、C1とC2、V1とV2という風に二つのインスタンスを
生成することになるよね？

少なくとも、継承はできないと困る。
0922デフォルトの名無しさん2014/09/02(火) 12:09:49.80ID:nKvPNOS3
オブジェクトは概念つーか役割だろ
オブジェクトがあるんじゃなくて
オブジェクトにするんだよ
0923デフォルトの名無しさん2014/09/02(火) 15:34:18.42ID:MuxQvtYh
プロパティとインスタンスを混同してないかな？

プロパティは要素だから複数有るだろ、インスタンスはクラスを実体化した物

顧客情報は、複数プロパティを持つ
レコード毎にインスタンスを再利用して行けば、1つで済む
0924デフォルトの名無しさん2014/09/02(火) 15:50:47.18ID:3UrFGxAg
>>923
周回遅れはレスしてはいけない。
0925デフォルトの名無しさん2014/09/02(火) 16:05:00.71ID:hWaDCuQb
表示したり更新したりするたびに毎回ＤＢに接続するのかな？
0926デフォルトの名無しさん2014/09/02(火) 16:08:26.29ID:ja7HZQJ9
>>923
> レコード毎にインスタンスを再利用
なんでそんな面倒くさいことするの？

とあるコボラーがね。ループの外で変数を定義してるの。
で、ループの中でその変数を使いまわししてるの。

だもんだから前のループの値がこのっちゃってさ、バグになってんの。
せっせと初期化するコード書いてるんだけどさ、
そもそも変数を使いまわしするんじゃねーよって教えてあげた。

俺偉いねｗ
0927デフォルトの名無しさん2014/09/02(火) 18:13:14.89ID:BxPdE7CF
「人間」とか「宇宙」みたいに定義出来ない概念みたいね。
0928デフォルトの名無しさん2014/09/02(火) 19:49:20.44ID:V9Jb92Vc
結局「オブジェクト指向」の解釈はバラバラでみんなが理解していない言葉。
理解していないくせに「オブジェクト指向のプログラミング」を理解しているつもりなのだから大笑いw
0929デフォルトの名無しさん2014/09/02(火) 19:57:02.01ID:szOkFkDB
そんな難しくないけどｗ、ポインタと同じで難しいとか言ってる奴の方が頭おかしい
0930デフォルトの名無しさん2014/09/02(火) 19:57:43.86ID:BxPdE7CF
人間や宇宙と同じで共通する部分もあるだろう。何をオブジェクトとして認めるかは人によって違うかもしれんが
0931デフォルトの名無しさん2014/09/02(火) 20:18:03.31ID:S8CK+9Gm
お前らのオブジェクト指向探求の旅はまだ始まったばかりだ
だが忘れんじゃねーぜ！オブジェクトはいつだってお前らの心の中にあるってことをな
辛くなったらそのことを思い出せ
0932デフォルトの名無しさん2014/09/02(火) 20:42:53.16ID:vngmZpQR
>>920
でも言語の話に限定してるのは多分1人かせいぜい2人だよね。

>>926
COBOLにはグローバル変数しか無かったからなあ…今はあるかも知れんが。
0933デフォルトの名無しさん2014/09/02(火) 20:57:57.67ID:OAvH1Kkv
>>928
どっちみち、開発開始時には開発手法のすり合わせするだろ。
0934デフォルトの名無しさん2014/09/02(火) 21:28:44.87ID:XKHIGyV2
>>928
なんだ全く理解できてなかったのか。
どうりでトンチンカンな事を言ってるわけだ。
0935デフォルトの名無しさん2014/09/03(水) 00:13:38.59ID:/DOsRWjf
>>922 がいいこと言った
0936デフォルトの名無しさん2014/09/03(水) 17:42:08.40ID:KQZ2JdmI
モデルのリレーションで、Many-to-Manyの関係とか、One-to-Manyの関係は一杯あるけど、
One-to-Oneの関係って、意外とあんまりないですよね
夫と妻も、一夫多妻制を考慮したらOne-to-Manyだし、
部屋と借り主にしても、最近はホームシェアリングとかあるし、一人で複数の部屋借りる人もいるし、
人と、クレジットカード、銀行口座にしても一人で複数アカウント持つ人もいるし、
今んとこ、人と運転免許証やパスポートの関係、世帯主と住所の関係ぐらいしか思いつきません。
他にOne-to-Oneのモデリングのいい例ってありますかね？
0937デフォルトの名無しさん2014/09/03(水) 20:33:59.58ID:z1Y/3x7f
>>936
たしかに ExactlyOne-to-ExactolyOne の関係は、ほとんど無いと思う
（ここで、"exactly one" とは「厳密に1」とか「きっかり1」という意味）
ただし ExactlyOne-to-ZeroOrOne の関係は、ありふれていると思う
もし「あんまりない」と思うのなら、
それは nullable な属性を見落としているのではないのだろうか？

なお、世界には多夫一妻制の民族もあると聞いた事があるから(アフリカだったかな？)、
一夫多妻制を考慮するのなら Many-to-Many または OneOrMore-to-OneOrMore 関係と
しないと、某ジェンダーフリー団体関係者から女性蔑視と批判されかねないからご注意を
0938デフォルトの名無しさん2014/09/08(月) 10:38:57.62ID:6tmtTctc
ポリモーフィズム以外の目的で継承することなんてあるの？
0939デフォルトの名無しさん2014/09/08(月) 14:53:20.45ID:3GR90xPD
コードの再利用、インターフェイスの共通化
0940デフォルトの名無しさん2014/09/08(月) 16:57:42.81ID:Y11lcNSo
それってデザパタのテンプレートパターンとかだよね
結局ポリモーフィズム使ってやることじゃん
0941デフォルトの名無しさん2014/09/13(土) 15:35:57.12ID:tjZmTWX3
>>938
「ポリモーフィズムしないなら継承しない」は、大げさに言えば
「同じ処理がないから関数分けしない」みたいなもんだと思う

もちろんやり過ぎは良くないと思うけど、ポリモーフィズム以外の継承は充分あり得るよ
0942デフォルトの名無しさん2014/09/13(土) 15:51:12.18ID:hy82vpoO
具体的に頼む
0943デフォルトの名無しさん2014/09/20(土) 17:11:32.34ID:GoNpKt2f
各プログラミング技術は年を経るごとにレイヤーが下へ下へと下がっていて、
デザパタを突き詰めるとオブジェクト指向が楽になる。
オブジェクト指向を突き詰めると構造化プログラミングが楽になる。
構造化プログラミングを突き詰めると手続き型プログラミングが楽になる。
手続き型プログラミングを突き詰めれば大変便利なコマンドやアプリの出来上がり。
次はハードウェアとセットにして便利なシステムを作り、
便利なシステムが人と人をつなぐネットワークを作り
人のネットワークが巨大な意志を作り、
巨大な意志が世界を食い尽くしていく。
0944デフォルトの名無しさん2014/09/21(日) 22:43:12.84ID:McR98lNz
>>941
なるだけ、オブジェクトコンポジションを使った方がいいと思う。
0945デフォルトの名無しさん2014/09/22(月) 04:35:03.45ID:b/MXCgR3
例外クラスとか、意味だけでクラス階層作ってる最たる例じゃね
0946デフォルトの名無しさん2014/09/22(月) 10:51:11.73ID:b4rgUQbg
たしかに
0947デフォルトの名無しさん2014/09/28(日) 15:44:07.86ID:Q1HQoOgA
ソフトウェアデザインの９月号に載ってた、
「オブジェクト指向はまぼろしか？」

っていう記事が、オブジェクト指向の勃興と衰退を
分かりやすく説明していてすごく良かった。
0948デフォルトの名無しさん2014/10/04(土) 01:20:49.34ID:X9NgDlHH
ドラクエのザラキってめっちゃ強いじゃないですか、だから仲間全員ザラキだけ使えたら、すぐに魔王倒せるよね？
よっしゃ、全員に覚えさせよ！->死亡
ザラキ効かない敵がいるじゃないすかー！、けど途中の敵が使ってたメラゾーマめっちゃ強いじゃないすか！、じゃあザラキとメラゾーマで魔王なんで余裕か、すんまそんー＞死亡
魔法効かないとか、そんなのありなんすか！じゃあ打撃もいっちょ鍛えるか！ー＞やっと倒せた！

これで三回も方向転換をさせられたAさん、何だったら問題ないのかな？
打撃？いやいや打撃だけじゃ倒せない敵もいますね？


たたかうってめっちゃ強いじゃないですか！、だから俺っちたたかうをめっちゃ鍛えます！ー＞倒せた！

そうです正解はたたかうです！
0949デフォルトの名無しさん2014/10/04(土) 01:22:10.89ID:X9NgDlHH
え？ずるいですって？たたかう鍛えたらラスボス倒せるでしょ？
何？あまりにも抽象的すぎるですって？

そうなんです！これがオブジェクト指向の中心の概念は実は抽象化なんです！
プログラミングって色々仕様が変更されますよね？
あなたが経験した事のある仕様の変更って、上手く抽象化させたら同じ物にならないですか？
txtで保存でイイヨー＞やっぱDBデヨロシク　保存という抽象化

ザラキ、メラゾーマ、打撃も抽象化すると　たたかう

だから何なんだよ！ボケ！という声が聞こえてきそうですが

この抽象化させると仕様の変更が起きても使う命令は同じ名前っていうのがポイントなんです
オブジェクト指向が考えられた時代の問題点を考えてみましょう
C言語全盛期構造化の時代、ルーチンという物が開発者の武器でした。
これは、ルーチンの名前を叫ぶと、そのルーチンの名前にそった現象が起きるという大変便利な物だったんです。
しかもこれ！一個作れば何億人もの人たちが使える様になる便利な物なんです！
しかしこれには一つ問題が、そうです！これはルーチンの名前にそった現象が起きる！
つまり、メラゾーマ、打撃、ザラキ、DBに保存、txtで保存という名前しか使えない、つまり抽象的な名前しか使えなかったんです！
たたかうルーチン！って言われて何が起きるか想像できます？
0950デフォルトの名無しさん2014/10/04(土) 01:22:43.79ID:X9NgDlHH
だから、だから何だよ！？ってか？てか？
例えとして、大日本帝国軍に仮にあなたが研究者としていて、ザラキルーチンを作ったから日本軍全員に配るとします。
これ使えば皆死ぬから気をつけろよ！
そしたら我らが優秀な大日本帝国軍の兵士たちはこれをつかって色々つくる訳です！
打つたびにザラキと発するザラキマシンガン
自転車で一回漕ぐ毎にザラキを出せるザラキ自転車
駅名が全てザラキで駅に着く度ザラキを発する JRザラキ線
三分間に100百回ザラキが流れる、 Theラキ
もういい？了解しました！
けどある日重大な事に気づく訳です、ザラキで死なない敵が居た！
しかし優秀なあなたはすぐにメラゾーマルーチンを発見した訳です！
これで大丈夫やと！けどこれで解決じゃないですよね！ザラキマシンガン、ザラキ自転車などをメラゾーママシンガン　メラゾーマ自転車に変えないといけません
無事、全員やっとの思い出ザラキー＞メラゾーマに変えれました！
数日後、、、どうなったか、わかりますよね？

そして私の言いたい事分かりましたでしょうか？
ザラキー＞メラゾーマに変えた事で色々な人たちが迷惑しました。
なぜこの様な問題が起きたかと言えば！名前が変わったから
だけど、名前は変わるもんだし、、、そんな中現れたのがそうです！たたかう、保存、抽象化なんです！
ただ、ここで一つ問題が残ります、先ほども言った
たたかうルーチンの想像が出来ないと言う事です。
なぜ、想像出来ないのでしょうか？

完
0951デフォルトの名無しさん2014/10/04(土) 01:23:42.32ID:UaP/yfZa
いつ衰退したの？関数型もリスト操作と勘違いしてるやついるんだよなあ
0952デフォルトの名無しさん2014/10/04(土) 01:24:56.06ID:X9NgDlHH
どうよ？
0953デフォルトの名無しさん2014/10/04(土) 01:30:04.41ID:ZiK68qIR
オブジェクト指向を理解できない奴が書いてるんじゃない？
0954デフォルトの名無しさん2014/10/04(土) 01:35:14.31ID:X9NgDlHH
VIPで書けば良かった・・・
0955デフォルトの名無しさん2014/10/04(土) 13:35:04.31ID:X8tclADN
>>950
uy さんおヒサ！
0956デフォルトの名無しさん2014/10/18(土) 13:36:17.15ID:YYHeOkee
オブジェクト指向でないと、設計にちょっとミスがあるだけで１から作りなおした方が早いなんてことになる。
0957デフォルトの名無しさん2014/10/19(日) 01:45:09.73ID:xRooCKL+
それは設計が悪いだけ。
LinuxのカーネルはCだぜ？
0958デフォルトの名無しさん2014/10/19(日) 01:53:54.64ID:Hc++LB4w
>>957
Cというか、カーネル部分はアセンブラでしか書けないからほとんど選択肢は
無いだけなんだけどな。
0959デフォルトの名無しさん2014/10/19(日) 01:54:49.06ID:Hc++LB4w
正確にはアセンブラでしか書けない部分があるからだな。
0960デフォルトの名無しさん2014/10/19(日) 02:35:56.28ID:xRooCKL+
でもCでもカーネルのような大規模なプログラムはかける
って証明にはなってると思う。
すべては設計次第
0961デフォルトの名無しさん2014/10/19(日) 02:39:23.68ID:GulnFHAj
C言語でもオブジェクト指向で設計していれば
冗長になるだけで大規模プログラムは書ける。
という証明になってはいると思う。
全ては設計次第
0962デフォルトの名無しさん2014/10/19(日) 02:42:49.93ID:xRooCKL+
いや、モジュール化はオブジェクト指向以前にもあったわけで。
モジュール化さえしっかりしていればオブジェクト指向じゃなくても
大規模プログラムは書けるよ
0963デフォルトの名無しさん2014/10/19(日) 04:01:51.29ID:lKnJZ0BO
>>962が言いたいことは2行目以降なんだろうが、
「モジュール化がオブジェクト指向以前には存在しなかった」っていう論調を
どこから読み取ったのか気になるなぁ。
揚げ足を取るようですまんけど、1行目のツッコミは的外れだよ。

その前の設計次第というのにはすごく同意。
0964デフォルトの名無しさん2014/10/19(日) 04:12:41.14ID:k1PbD2WC
歴史的には構造化の提唱よりオブジェクト指向のが早かったんだっけ。
0965デフォルトの名無しさん2014/10/19(日) 10:57:39.22ID:C9CvfGxs
＞それは設計が悪いだけ。

設計がちょっと悪いだけで１から作りなおすことになる。
0966デフォルトの名無しさん2014/10/19(日) 11:46:50.81ID:cnhaJtur
>>964
simula〜smalltalk〜いわゆる動的言語?の流れと、c,fortran,pl/I〜ada,c++〜java,C#の２つの流れがあると思う。
ソフトウェア工学の進化の観点からいくと後者で、アジャイル系の進化からいくと前者かな。
0967デフォルトの名無しさん2014/10/19(日) 16:40:10.32ID:0fT/xqrZ
的はずれ
0968デフォルトの名無しさん2014/10/23(木) 00:24:07.57ID:3x0yfLHI
答えが出ました
設計がよければ何でもよい
0969デフォルトの名無しさん2014/10/27(月) 10:06:43.13ID:FmR1HGba
では、このスレッドは閉鎖ということでようござんすね？
0970デフォルトの名無しさん2014/10/27(月) 18:40:17.72ID:zAQ9CJbQ
オブジェクト指向はもう飽きた
これからはアセンブラの時代あるな
0971デフォルトの名無しさん2014/10/27(月) 20:34:08.66ID:40zHC+/0
次スレ

[転載禁止] オブジェクト指向を今すぐやってください(c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1414409620/
0972デフォルトの名無しさん2014/11/04(火) 11:46:49.02ID:tJPjGfpS
オブジェクト指向って名前で手続き型設計やってるからしかたない

ゲッターセッターつけただけのDTOが、サービスを出たり入ったりして加工されてく

それただの構造体やん
メソッド分割されて適当な固まりにクラス分けただけやん

オブジェクト指向してない物をオブジェクト指向って呼ぶからよけいにわかんなくなってる
0973デフォルトの名無しさん2014/11/04(火) 12:31:33.15ID:Zb8ZL2AV
>>972
あるある
0974デフォルトの名無しさん2014/11/04(火) 22:32:21.75ID:0zmauaM5
>>972
ファサードパターンに代表されるような、データと処理を分割するのもオブジェクト指向だけどね。
0975デフォルトの名無しさん2014/11/04(火) 22:44:29.52ID:E4XGFJi4
データ（＋セッター・ゲッター）だけのオブジェクト、
処理だけのオブジェクト

これらはオブジェクト指向ではない。

という考えは間違いなわけで
0976デフォルトの名無しさん2014/11/04(火) 22:47:16.88ID:S1s23DTq
ファサード勘違いしてない？
あれはサブシステムが既にあって、
それらに対する窓口を提供するだけのものだよ？
ファサードクラスの追加によってなにも分離しないし、
ましてやデータとか処理とかいうレベルの話じゃない。
0977デフォルトの名無しさん2014/11/05(水) 08:38:23.29ID:QbWIQhdw
ファサードはちゃんとデータと処理持って単一責任果たしてるくない？

複雑なインターフェースを持つオブジェクトをラッピングしてIF変換するんだから、
それは、そのオブジェクトが内包するサブシステムがデータと処理を請け負ってるわけで

結果としてサブシステムがデータ保持するから、データそのもののフィールドを持たなくなったり、
提供インターフェースの選択だけで事すんで、IF変換は引数呼び出しだけの最低限になって
サファードクラス自体には記述されないことはあるだろうけど、
サファードを通して実現さるサブシステム機能はサファード自体が持つ処理やデータと同義だから

話は変わるが、サファード(Facade)のこと近年までフェイスド(faced)と勘違いしてた
中の人はいろいろできるけど、表舞台に立つときは役割に応じた分かりやすいお面(顔=face)をかぶせる的な意味かと思ってたわ
0978デフォルトの名無しさん2014/11/05(水) 08:53:32.12ID:fg4bcb0P
俺の考える最強のファサード
0979デフォルトの名無しさん2014/11/05(水) 12:39:02.79ID:4HZqUkwb
フェイスドでもなければサファードでもない
0980デフォルトの名無しさん2014/11/05(水) 12:52:40.70ID:QbWIQhdw
oops
サファードってなんだよw
クラフトかPSO2か
0981デフォルトの名無しさん2014/11/05(水) 18:06:13.46ID:sMIrqpck
> 複雑なインターフェースを持つオブジェクトをラッピングしてIF変換するんだから

ラッピングするわけじゃあないんだなこれが。
ラッピングせずに、サブシステムを触れる状態のまま、
追加されるのがファサードなんだなこれが。それが特徴のひとつ。
0982デフォルトの名無しさん2014/11/05(水) 20:08:20.98ID:lJf3l7vH
ファサードでもフェイスドでもサファードでもない

ファザナドゥだ。
0983デフォルトの名無しさん2014/11/05(水) 20:15:43.08ID:FNyFtVyY
オリビアニュートンジョンか
0984デフォルトの名無しさん2014/11/05(水) 21:03:54.79ID:+x9XCqU/
エン、フーリナフ、トゥー、ティンクザ、ウヮッタル、ファン
0985デフォルトの名無しさん2014/11/05(水) 23:26:10.77ID:UbfQ7xJO
オブジェクト指向は愚かな考え。排便メソッド2
http://peace.2ch.net/test/read.cgi/tech/1415122540/
レス数が950を超えています。1000を超えると書き込みができなくなります。