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

遅いんですよ、オブジェクト指向は。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

俺の場合速いが？

むしろオブジェクト志向じゃないプログラミングってどこで使われてるの？

つまらない一発ネタスレもやめてください

CからC++に移行するときに散々gccの出力アセンブリコード読みまくって特性を検証したけど
ペナルティはせいぜい20〜30％程度である、
利便性・保守性が勝るという結論に達して早々に移行したな。
当時は今と違ってCPUの性能もぐんぐん伸びてたしな。

その後ずっとC++は遅いって足踏みしてた連中を鼻で笑ってたわ
これがプログラマとしての能力の差

JavaScriptなんぞもJITコンパイラの出力アセンブリコード読めば
タコで不安定なコード吐きまくっててC/C++に遠く及ばないのがすぐわかるのに。

その後ずっとWebアプリがネイティブアプリを倒せるってはしゃいでた連中を鼻で笑ってたわ
これがプログラマとしての能力の差

最近はちょっとアホなコンパイラかな？くらい引き締まったコード吐くよ
オブジェクトとか絡んで複雑なところは流石に比較しづらいから分からんが単純計算の所とかはそう
まあ勿論TypedArrayとかを使わないと太るけどね

オブジェクト指向のポリモーフィズムつかいまくるようなコードではC++よりもjava7の方が圧倒的に早い。
C++はvirtualが妙に遅い。
>>6 javaに移ることをすすめるよ。

オブジェクト指向はしっくりこないのでやめてください

今Javaに移るよりはDartとか始めたほうがよっぽど将来性ありそう

Objective-Cもいいよ。
パフォーマンスクリティカルな処理はCで書けるし。
ああ、プラットホームが限定されるかw

>>12
UNIX(Linux, FreeBSD, Solaris, OSX..etc) と
iOS で使えるから十分じゃね？w

pythonは十分速いから関係ないな

Pythonはデフォの実行環境だと遅いじゃん
Cythonとか使ったりして頑張ってようやくって感じ
Rubyはこの度のメジャーバージョンアップでデフォのでもマシになったけど

そうだな　やめよう

PythonもRubyもJavaもSmalltalk(Visual Works)よりおせえもんな。

C#はやい

アイちゃんも呆れとったわ

すいませんでした。

オブジェクトをブジョクするな

オブジェクト指向の遅さよりパフォーマンス厨の開発の遅さの方が深刻

オブジェクト指向にするとボタンを押してから結果が出るまでの時間が
10ミリ秒程伸びてしまいました。
でもユーザーは、体感できる人や文句を言う人はいませんでした。

ちゃんちゃん。

10ミリ秒も伸びるわけねーだろ

>>22
まあコストを容認出来る（趣味、最先端分野）場合は実行時間にこだわる意味はあるけどね。
演習や実務では、他にも考えるべき要素が有る。

実行速度より開発速度

スクリプト最強

オブジェクトを使わずにプログラムなんて出来ないだろうに...

今後の世界はc++かjsかの二極化

JSと聞いて

おいキチガイスレ立てたのお前らか

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://engawa.2ch.net/test/read.cgi/poverty/1386476617/

>>12
プラットホームほ駅

ところでだ。「チンボがシコシコする」という日本語表現は、文法的に正しいのか？

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

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

違うか？

「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！

手がシコシコする

前立腺ガンの疑いがあるとき、「海綿体がシコシコする」と医師に相談するのでは？

他動詞的な用法での「シコシコする」が誤り

日本人以外は帰ってくれないか

女医にチンボがシコシコすると相談するプレイ

関係者以外立ち入り禁止

チョンくせぇ流れだな。

正直な話、1人で作る個人ユースで使うプログラムで継承だのジェネリックだの
使いどころが全く分からない。無くても困らないだけでなく速い

作るのが一人かどうかは関係なくて、
プログラムが大きくなったらあると便利。

Javascriptで、グローバル変数の個数分、関数があったりすると萎える

>>41
こういうのがチームにいると開発効率が落ちるから困る。
どんなパラダイムだってチューリングマシンと等価なんだから、無くて困らないのは当たり前だろ。
それでも使う理由があるってことなのに。

まず日本語勉強してこい

もはや継承は悪手で、委譲が一般化してないか？

>>46
使うだけだとインタフェースあればほとんど要らんけど
大規模なクラスライブラリの中では重要な役割だと思う

実装の継承が悪手で、多態を目的とした継承ならむしろOK。

Go言語は継承無い

インタフェースで済む

実はオブジェクト指向ってしっくりこないんです！

オブジェクト指向などと仰々しい名前がついてるせいさ
と一瞬思ったけど、他に適当な呼び方なんて無いな

しかし、厳格すぎるオブジェクト指向はプログラムの障壁になりえる
その点Golangって丁度良さそうだな

そうそう、オブジェクト指向なんて名前付けるから変な反発というか、
なかなか理解出来ないなんてことになるんだよ。

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

多態というのは結局、同じインターフェースを呼び出しても
その先のモジュールが違えば違う動きするというだけのことを
もったいぶってそう呼んでいるだけだしね。

客体指向

オブジェクト指向、ホントにあった怖い話(2004/7/10)から
>…平澤氏は、オブジェクト指向を巡る混乱の要因は、「プログラミング技術」としての
>オブジェクト指向と「汎用の整理術」としてのオブジェクト指向を同一のものとして認
>識しようとする態度にあるとする。
>　例えば、オブジェクト指向の基本解説書や記事では、クラスやポリモーフィズムなど
>…を説明する際に、現実世界をそのままオブジェクト指向という考え方を適用して表現
>しようとする。しかし、「オブジェクト指向と現実世界は大違い」（平澤氏）であり、
>オブジェクト指向を正しく理解するには、まず、プログラミング技術として、構造化プ
>ログラミングの限界を突破した後に登場した新たな技術として理解することが重要であ
>り、主に上流工程における汎用の整理術として応用されるオブジェクト指向とはまった
>くの別物としてとらえることが必要だと力説した。

汎用の整理術とすらでもなくて、
モロにプログラミング技術として
「現実世界をそのままコードに落とせる」←？
というのを最大にして唯一のOOPのメリットだと言い張る人は過去にみたことある。

>>>55
>オブジェクト指向と現実世界は大違い

そうなんだ
俺は今でもオブジェクト指向は、テレビとリモコンの関係だと思ってるけどw

「リモコン」という概念を定義できるのがオブジェクト指向。
構造化手法だといちいちテレビ側のボタンを押しに行かないといけない。

a.Run();
と
Run(a);
って、単に構文が違うだけだよね？

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

と言われたらどうする？

>>59
その2つだと責任者が違うよね。
前者はa側にRunの処理内容を封じ込められるから、Runしたい側はaの内容が正しいことを保証せずに済む。

そもそもオブジェクト指向って実際にコンパイラがどう解釈するかというよりどうやってコーディングできるか、ってとこに主眼が置かれるわけだが。
パッと見オブジェクト指向に見えればそれは立派なオブジェクト指向だよ。

見た目の問題でもないけどな。
C言語でもオブジェクト志向出来るわけだし
その内のいくつかは何となくやってた人も多い。
ソケットとか、ファイル辺りの関数はよくOO的と言われるし。
データや処理などの主体をどう切り分けるか、が最大の肝だと思う。

>>61
データや処理の主体の切り分け方こそ完全に見た目だけの問題だろ。

結局、オブジェクト指向は何のためにするの？しないといけないの？
というのが、よくある入門者の疑問で。入門者に限らないけど。

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

テレビ構造体、リモコン構造体を定義して、それで"オブジェクト"設計すればいいだけだし、
関数の呼び出し構文が違うだけだよね。

そもそもC++やC#のサポートするOOPはなんちゃってOOPなはずだが。
真祖smalltalk様と渡り合えると思ったのか。

原理主義者は頭が固くて
場を荒らす事しかしないという印象がある

>>63
＞例えば、構造体を定義して、それにアクセスする関数を定義して、
＞必ずその関数を使わないといけないという運用にすれば、

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

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

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

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

そこに多態性(C++ならオーバーロードでも可能だし、C言語でも関数ポインタなどで可能だった)や
継承(ちと面倒だけどこれも可能)っていう、更に発展したやり方を持ち込んだだけ。

そう。
C++という名前が表しているように、上の平澤氏の話のように、
構造化プログラミングの限界により、"運用"でカバーしなければならず、
不便だったことを改善した仕様にオブジェクト指向という固有名詞を付けただけなんだよ。

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

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

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

「オブジェクト指向」って、モジュール設計なんだよ。そのモジュールの動きがまるで「オブジェクト」みたいだ、
ということで「オブジェク指向」なんてどっかのバカが付けたせいで、逆に初心者が分からなくなってるんだよ。

で、オブジェクト指向のメリットって一言で言うと何？

開発速度とメンテナンス性が良い

>>67
>「オブジェクト指向」って、モジュール設計なんだよ。そのモジュールの動きがまるで「オブジェクト」みたいだ、
>ということで「オブジェク指向」なんてどっかのバカが付けたせいで、逆に初心者が分からなくなってるんだよ。

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

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

まとめると、こういった縛りプレイ(？)を総称してオブジェクト指向と名前を付けた人はバカではないし、
名前を付けたことが初心者を困惑させる要因になっている訳でもない
あるフレームワークをマスターすることが難しいのと同様に、オブジェクト指向とは
本質的に難しいものであり、それを分かっていない人達が混乱を巻き散らしていると考える

>>68
設計をオブジェクト指向という一つの「枠組み」でとらえることができる、こと
ここで設計とは、従来の手続き型設計手法における：
　　機能設計/構造設計/詳細設計(コード設計)
に対応する

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

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

そして、オブジェクト指向プログラミング(OOP)を理解しただけで
オブジェクト指向(OO)のすべてを分かった気になっていた平澤氏(>>55)が、
現実世界の開発現場でプロジェクトに混乱を巻き散らしていた張本人であったのは
言うまでもないことだ

>>68
有益だけど面倒だったことが誰でも簡単に出来るようになった

>>69
レストン！

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

俺は、結局んところモジュール性の上乗せだと思う。
ただしこれは想像であって、クラスという単位で名前つけたり、
インスタンスを複数の抽象レベルで扱えたりすることが、
非OOPで出来るのかどうか不勉強で知らない、
仮に出来ないとしたら、出来るOOPのほうがその分オイシイ、の発想。

>>72
レストン！
まぁよく聞く「CでもOOP出来る！」発言はじゃあオマエがそれをやってみろ、
実用としてそれでラクをしてみろ、という気分になっちゃうね。
まあこういうと単にOOPLへの感謝にすぎないが。

>>73
>クラスという単位で名前つけたり、
>インスタンスを複数の抽象レベルで扱えたりすることが、
>非OOPで出来るのかどうか

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

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

そして非OOP言語の世界には「型とは値である」という発想がある
つまりデータ型を(値として)実行時に定義したり生成できるパラダイムであるが、
実験的な言語はいくつか提案されてきたけれど、どれ一つとして普及には成功しなかった
この「型とは値である」という発想をOOPの世界で言い換えたものが
「リフレクション(メタプログラミング)」になる
そしてリフレクションは Ruby on Rails の成功等で実用化が一般にも知られるようになり、
現実のOO設計技法として普及に成功した
つまり「OOPで出来て非OOPでは出来ない」のはリフレクションである

コンピュータの歴史を辿れば分かりやすいかな。といっても実際の歴史は知らんので想像ｗ

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

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

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

そしてさらに規模が大きくなると？？？？
サービス指向とかかな？？

まさかそんなところに着地する話とは思いもよらなかったｗ
結論については消化できてないのでひとまず言及は避けておく。

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

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


非OOPLで、非OOPをして、それが、
OOPのメリットに迫るか上回るかの例をいつも見たいと思っている。

OOP言語で作っても実行されるのは機械語だよ。だから機械語でもOOPは出来るｗ
構造化言語は、構造化を簡単に出来るようにした
オブジェクト指向言語は、オブジェクト指向を簡単に出来るようにした
だけ。

>>78
その考えのほうがスパッと行ってるな。
どうも俺余計なこと考えちゃってたみたい。

オブジェクト指向って１つ１つのオブジェクトの作成でその力を使いきっていて、
オブジェクトをどのようにつなげていくかに関しては無能っぷりを撒き散らしている。
デザインパターンのグダグダっぷりを見ていると痛々しい。

>>80
忘れがちではあるけど、実はデザインパターンを構造型で作るとオブジェクト指向より更に胡乱でメンテナンスの難しい糞コードが生まれる。
グダグダに見えてあれが一番便利でコンパクトだったりするんだよ。
それに、一つの機能の使い方だけで性格の全く違う有用なものが最低23個も生まれるって考えると、
つなげ方には自由度と一貫性が両立されてるわけで、むしろ美しいとは思わないか？　俺は思わないけど。

>>71 面白い書き込みをありがとう。オブジェクト指向はわからんなぁと思っ
ていたが、経験的に身に着けられるような、テクニックやハッキング技術と
は違うということがわかった。

書きぶりを見るに、オブジェクト指向「設計」はきちんとした
計算機科学専攻の大学院レベルのトレーニングを経ないと習得できないもの
なのだろう。そのような教育を修めた技術者が基底クラスの設計とコーディング
ルールを決めたう上で、開発をするのがあるべき姿なのだろう。

なるほど。こういう人が設計するべきだね。
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html

正直業務アプリのフレームワークなんて決まりきっててすでに用意されてるしな
日付だの画面部品だのは基本的なものはもう標準ライブラリに入ってるし

パンピーがオブジェクト指向でなに設計するん？

標準ライブラリやフレームワークで足りないものを実装するとき。

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

その時、だいたい部品は拡張可能になっているが、
それを拡張するときはオブジェクト指向の知識が必要になる。

それっぽい言葉だけは出揃っているんだけど実装がことごとくダサダサなのが地球のオブジェクト指向☆

>>84
パンピーならゲームじゃね？
ゲームはオブジェクト指向と親和性高いからオブジェクト指向の独壇場みたいなところあるし。

>>85
単に抽象クラスにコード実装するだけだろそれ
その程度ならVBでポトペタしたボタンをダブルクリックするのと何もかわらん

本当に何かFWが提供している以上のことをやろうと思うとどのような思想で
抽象化されているかまで理解しなければならないのがooの最大クラスの欠点

抽象クラスって言ってる時点で
オブジェクト指向の知識が必要になってるじゃねーかｗ

C++使うから、訳が分からなくなるんだよ
VBScriptでオブジェクト指向してみると分かりやすくなるさ

言語にこだわるのは無能

本質は変わらない

じゃあすべてマシン語で書け。

あれだろ仕様書の日本語やカタカナ英語にこだわっている人。
さもなくば肩書きとか名誉とか貯金とか、
結局人間は無意識に何かに拘ってるんだよ。

>>91
PrologとHaskellとRuby勉強した後に同じ事を言えればいいが

Rubyなんかパチもんは外して代わりにSmalltalkとLISPを、あとAPLを入れたいね

「言語なんて全部一緒」って言ってる人
関数型言語を意図的に無視しているから嫌い

じゃあ、言語なんて二種類しかないでいい？

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

オブジェクト指向言語が純粋ではない関数型言語に近くなってるよ。
だから全部一緒っていうのもあながち間違いじゃない。

いやー、全然近くなってないよ

近いよ。もう関数型言語特有のものっていうのは
少なくなってるでしょ？

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

ほんの数個出るだろうけど、それ以外は
もう関数型言語じゃなくても良くなってる。

カレーか

つりだろ。

最終は機械語

機械語といっても、必ずしも手続き型とは限らない

>>100
カリー化ね

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

言語構文でネイティブにサポートされてないってだけで
カリー化をする関数は作れる。

>>102
ネットの機械語はjavascript

言語なんて全部一緒なんじゃなく、全部載せの言語があるだけじゃないか？
逆だと思う。

ノコギリなんてみんな一緒って言うのとおなじくらいナンセンス。
関数型と手続き型では日本の引きノコ、海外の押しノコくらいの違いがあり、
じゃあ両方いっぺんにてんで歯の左右に角度の違う歯を配置したりするノコもある。

>>99
再代入禁止とか

鋸の由来ってJSON（ジェイソン）に対する言葉遊びかな?

>>96
（俺らがいくら関数型を使ったところで、プログラミングセンスが開花するわけじゃないんだから）
言語なんて、どれも一緒

楽器に例えると？

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

SQLとRubyは
ベースとエレキくらい違う。

代数的データ型とパターンマッチがOOPLにも欲しい
これ有る無しでプログラミングスタイルから変わってくる

>>109
そーだよ

会社の先輩が全く理解してくれない。

その人が作るプログラムはうまく動くには動くんだけど、いろんなスタイルが混在してて、
なるべくきれいなオブジェクト指向的設計にした方がいいですよ、といって説明してるんだけど。
「おまえの言うことくらい全部知ってる。だが全く実証的じゃない」って。
オブジェクト指向の利点を「実証的に」説明しろって言われてもなあ。

>>114
別に無理してオブジェクト指向することないよ

インタフェースを最初から決めとかないと後で困るだろ

>>115,116
だけど全然認めてくれないってのもくやしいよ？
俺の説明が悪いのかと思って、いろんな本やサイトの解説漁ってメリットを語っても
「そんなハウツーレベルのメリットを追求してるからダメなんだ！」と一喝。。。

頭脳じゃ全くかなわない。理学博士だし・・・

どんなに仕事を丁寧に丁寧にやったとしても、
１個問題が起きればその苦労が報われないことだってあるんだし、
理想ばっか追い求めないで、そこそこの結果を求めた方がいいと俺は思う。

てか、オブジェクト指向って何だ？
拡張性を残して再利用できるように、機能を最小にしてスマートにすること？
そのまま再利用できるように、機能を最大持たせること？

>>118
ダーティーなプログラムを、周囲に何の影響も与えることなく利用できるようにすること

やっぱり追求すべきは、まずはモジュール性だよ。
直行性あって再利用されがちな単位をみつけだして、
インタフェースを小さくよく考えて決めて、実装隠す。
モジュール性がより備わってるとき、それはやっぱり簡潔で柔軟だと思う。
OOPか否かに拘り続けるのもまたおかしい。

ファクトリー的なことにOOPを用いようとすると、
色んな処理が重なるの部品を受け取って、
組み上げる時にスコープが利かなかったりする。
ここらへんの想像が難しい

>>118
> てか、オブジェクト指向って何だ？

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

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

信じる信じないはあなたの自由です

たとえば構造化プログラミングの段階ひとつとっても、
うまいひとが書いたのと下手な人が書いたのって結構差がある。
そのことについて語られない代わりに、OOPのメリットとやらが先行して語られてる気がする。

原理主義ってうざいし根拠ないよね。
オブジェクト指向の度合いがより純粋であれば、イコールより良いものなんだ・・・って、
誰かの言葉じゃないけど、実証的に確かめられてるモノんだろうか？

>>122
もし分割の仕方で〜指向っていうのが決まるんだったら、複数の分割のやり方が混在していると良くないってことになるよね？

周りが理解しやすいようにOOPやGOFのデザパタを取り入れるんじゃないのか

>>125
「良くない」

ずいぶん抽象的な捉え方ですね。
もっと実証的に言ってください！

>>125
ならないよ。
データ指向30%
手続き指向30%
オブジェクト指向30%
その他10%

ってなるだけさ。
それでうまくいくことは十分ある。

オブジェクト指向でパッケージされたデータ構造を手続き型で処理するなんて普通にある話。

>>114
要はその人に「自分の知ってる文法だけで書いてください」って言ってるだけだろ？
それは単なる甘え。
その人は純粋なオブジェクト指向や他のパラダイムを一通り勉強して、その上で一番生産性の高い方法を選んでるだけ。
多分、その人は純粋なオブジェクト指向で書こうと思えば書けるんじゃないのか？
それをあえて使わない理由、メリットを聞いてみるべきだと思うよ。
そのメリットに納得したら、お前の方が先輩のやり方を学べばいい。

粗結合を実現しようと思ったら副作用は極力避けるべき

なのに、オブジェクト指向は副作用を避ける仕組みは提供しないっていうか
むしろ副作用推奨だからウンコ

小クラス主義、大クラス主義とかいうヤツだっけ？
小クラス主義が書いたコードは何かの信念を貫き過ぎてると思う

疎結合なら知っているけど粗結合ってなんだろう。

>>131
そのためのカプセル化だろ。
関数単位ではなくオブジェクト単位での副作用禁止を推奨してるだけ。根っこは同じ。
ダダ漏れの副作用はオブジェクト指向でも推奨されてないよ。

オブジェクト単位での副作用禁止ってなんだよアホか？
オブジェクトの状態を一切変化させないのか？

>>135
オブジェクト内の変数とオブジェクト外の変数を別物として扱ってるだけだよ。そのためのアクセス修飾子。
オブジェクト指向において適切にカプセル化がなされていれば、コンストラクタに同じものを与えて、同じ回数、同じ引数で呼び出した時に返ってくる値が変わらないことは保証されてるだろ？
最終的に参照透過性の理念の要求は満たすことになる。

ゴミｗｗｗｗｗｗｗｗｗｗｗ

どの言語のオブジェクト指向なんだろうか、少なくともjavaやC++のオブジェクト指向で副作用とか考慮されてないし
考えるのはキチガイ。

>>114
言語って道具だからね。
１つの道具だけで全てするんじゃなくて、
その人は色んな道具の使い方、特性を知り尽くして使い分けているんだよ。

>>136
> コンストラクタに同じものを与えて、同じ回数、同じ引数で呼び出した時に返ってくる値が変わらない

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

どこが参照透過性の理念を満たしてるわけ？

ンゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>140
言っている意味がよくわからん
コンストラクタはインスタンス化される際に1回だけ呼び出されるもので、1つのインスタンスで複数回呼び出されることはない
同じインスタンスを使うのであれば、コンストラクタの引数は初期化時に使ったものと同一だろ

俺だけじゃなかったんだ

今更インスタンスの説明くれたるようなレベルの事は書いてないだろ

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

普通こっち見るだろ

シングルスレッド脳に毒されてるから仕方がない

もしかして「同じメソッドを」が省略されてるとか？

マルチスレッドの場合、インスタンスの共有は避けるべきじゃないの?

なんで？
どのスレッドから呼ばれても単一スレッドで動作すればいいじゃん。

（無意味な）インスタンスの共有は避けるべき。
ってのをインスタンスの共有は（絶対）避けるべきと勘違いしてるんだろうな。

おまえらがマルチスレッドプログラミングに手を出したことすらないのは分かったｗ
たとえば、排他を管理されたキューを共有したりするのはよくあること。

immutableにしてビルダークラス作っとけ。

オブジェクト指向じゃないやり方って、どんなものがあるんですか？

オブジェクト指向なんて学ばなくても、
当然行き着く思考回路だろ。

で、オブジェクト指向は素晴らしいとか語るのはいいが、
適用できなそうな用件については経験と勘を養うしかないのか？

スコープを小さく、インターフェースを簡潔に。

関数型はおいとくとして
非オブジェクト指向のソースコード呼び方って手続き型しか呼称がない
perlとかCで普通に書いてるソースがそれ

手続き型は、OO程は「これやれ」みたいな規則ないから
他人のソースコードが読みにくいのはどうしようもない
だから手続き型を読みやすくする為にOOってルールを設けたようなもんだと思う
手続き型でかくのは読みやすく書くってより読み手が読む力つけるしかない

構造化プログラミングを手続き型でそれの対比でオブジェクト指向というのが、どうも個人的に違和感。
SQLとかHTMLのような結果を定義したら、システムがその途中の手続き処理をやってくれる宣言型言語との対比なら分かるんだが。

>>156
オブジェクト指向でプログラムするためには、構造化プログラミングをする必要があると思うのだが...

構造化ってのはgotoスパゲッティからの開放だからな。

goto から qozo へ

関数呼び出しはGoto文である、を思い出したｗ

関数呼出しはgoto文である
http://toro.2ch.net/test/read.cgi/tech/1232749808/

ミクロなコードは関数型で、
マクロな構造はオブジェクト指向で
やるのが現状ではベターですよ

共通するコードブロックがあるからクラスを派生させるんだよね?
けれど、設計段階で共通するコード片が分かってないなら、
cで書いた方が、よっぽど柔軟で保守しやすいんじゃねーの?

>>162
Ocamlでしょうか？Scalaでしょうか？

>>163
実装段階で分かったことを設計にフィードバックさせられないんだとしたら、そっちを変えた方がいいね

オブジェクト指向じゃないと、複雑さと規模に限界が来る

オブジェクト指向が許されるのはミクロとマクロな部分だけ。
ミドル付近でやらかすとグダグダになる。
何でもクラスやインターフェースでカプセル化して疎結合にすればいいってもんじゃない。

>>166
OSSだと、オブジェクト指向でプロジェクトが失敗みたいな話をちらほら聞くんだけど

今日、隣のJavaのプロジェクト覗いたんだが。。

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

んで、バグだらけでプロジェクトが上手くいってないらしい。
そらオブジェクト指向が分からないままオブジェクト指向言語だから、
で、ぐちゃぐちゃなコードを書いてればそうなるわな。

>>169
そいつらがCを使ったところでまともなコード書けるとは思えないのだが

今日、隣の診察室を覗いたんだが。。。

>>167
それ、オブジェクト同士の振る舞いを統括するオブジェクトを作れば解決するだろ。

解決した問題より大きな問題が新たに発生しないと見極めてからだな。

>>170
Cにはある意味static関数しかないから。

>>174
Javaオンリーな人向けには、そういう表現になるかもなあ
C言語やってると、微妙に誤解しそうになる表現だw

vba使ったら自由すぎてワロタ
variant便利すぎ、もうjavaに戻れんわ

型推論でええやん

インタフェースでええやん

途中で型分岐とかせず最後までvariantでいけるならいいんだけどね。

どうしてもバリアントで受け取らなければならない場合や
その方が高速である場合（セルの範囲を読み込む場合やGetRowsなど）
便利というか使わざるを得ないけど

受け取った後に計算するなら1次元配列に再配置した方が速度が出る
VBAで様々な高速化を実施するより、下手でもJavaで書いた方が性能出るけどね

性能より書いててどれだけ横着できるかが大事。

オブジェクト指向で考えると、コンピュータープログラムってのは、
どんなオブジェクトがどんな状態を持って、それぞれがどんな振る舞いをするか。
たったこれだけの事なのだ。

でもこういうのはキモくないか？
https://github.com/ruby-no-kai/rubykaigi2013/blob/master/public/ids/elevator_pitch.md

JavaでもVariant自作出来るだろ？

DBべたべたのコード書くときにVariantは楽
だが長期間メンテナンスしていくシステムだと毒に変わりやすい

ORMつかわないのか?

どうしようもない設計ををオーバーラップして型をごまかすくらいにしか使われていない
俺の会社

ゴキジェット指向に見えた

俺のコインを返してくれ

>>189
左腕を突き上げてジャンプしたらいいよ

Objective-CがC++と同じぐらい拡まってたら
オブジェクト指向の議論ももう少しスッキリしたんだろうなぁと
最近思ったりする。

>>169 classをただのnamespaceとして使って、モジュラープログラミング
してるってこと?

スレ「スレ立てるまでもない質問はここで 135匹目」のレス#100,101から、
議論が長引いてきたのでこちらへ移動してきた

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

これ対してKAC氏から「具象クラスから派生させてはいけないのは何故？」との疑問が出た
以下ではこの疑問への答えを書くつもりだが、一旦、ここで切る

(>>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の正方形インスタンスを生成

さて、この具象クラス継承には、どんな問題があるだろうか？

まあ、問題があるとすればRectangle.new(3.3)ってやっても、正方形として扱えないってことだな。
でもそれはRectangleとSqueareが
AbstractRectangle（仮）という抽象クラスから派生したものであっても同様に抱える問題だ。

>>195
そのとおりだね、その問題は確かに存在する
そして、それは具象クラス継承と抽象クラス継承の両者に共通する問題だから、
以降の議論では除外できると思う

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

# ....などと質問を投げて、自分は寝るとします

大丈夫だ問題ない。

つか、お前がその問題を解説する役割じゃないのかよｗ

ポカーン

>>194
問題提起の前に、そもそもクラスの定義がおかしい。
こんな状態で継承関係の話をしても無駄。

そのコードでいう「長方形」「正方形」の振る舞いを
日本語で書いて並べてみ？
間違えてる事に気がつくから。

>>193-200
ネタスレにマジレス汚物撒き散らすな。

>>200
おかしいのなら、それを単刀直入かつ具体的に指摘し、
もし可能なら対策も具体的に示すべき
KAC氏ならできるよね？

>>198
昨晩は眠かっただけで、続きの準備はできているよ
書こうと思ったけど、しばらくKAC氏のレスを待つつもりだ

>>202
クラスの振る舞いがまともに書かれていないだろ？

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

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

せめて、「正方形とはこういうものです」って自然な派生クラス書いてからにしてくれ。

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

あと、何か勘違いしているかもしれないけど、
この例は「具象クラス継承の問題」を説明するために選んでいる
だから、厳密で実用的な幾何学図形クラスの仕様としては不完全だよ
それとも、そんな枝葉の些細な問題を大きく取り上げたいのかな？

>>204
いや、あまりにもクラス設計が酷かったから思わず書いただけ。
せめて、長方形のクラスにも同じメソッドがないと話が進まないと思って。

今後の話に関係ない部分なんだったら無視して進めてくれて構わない。

>>205
だから、「クラス設計が酷い」のなら、それを具体的に指摘するか、
きれいなクラス設計を示しなさい、という話だよ
ただ単に「まともでない」「不自然だ」「酷い」と吐くだけなら幼児にもできる
大人ならば、ナゼそうなのかという論理的な理由を明解に文章化できるはず

>>194
よくある例だよね。
なんとかプリンシプルが守られてないっていう例。
親クラスのインスタンスの代わりに子クラスのインスタンス入れても動かない例。

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

あと気軽に多角形でクラス階層育てようとして、
案外うまくいかねーな、おいしくないな、ってのもよくある話。
そこらへんをKAC氏は言いたいんじゃないかな最終的に。

>>206
具体的に指摘も何も、203読んだら流石にわかると思ったんだけど。。。

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

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

そうなんだとしたら、別に構わない。
ただ、それならそういうものだという日本語での仕様説明があったほうがいいと思う。

スレタイの意味がよくわかる。

では、>>194の具象クラス設計について、３つの問題点を以下に示す
(1) Squareクラスは常に２つの属性を持つが、正方形の高さと幅は
　必ず等しいから情報量として無駄であり、どちらか１つがあればいい
(2) Squareクラスではsetterメソッド Square#height= と Square#height= が
　公開されているから、インスタンス化した後にこれらのメソッドを使うことで
　高さと幅の異なる正方形を作成できてしまう
(3) 正方形の周辺の長さは大きさを４倍するという簡単な計算で求めることができるのに、
　この実装コードでは計算量として複雑になる

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

(長過ぎるので、ここで切る)

(>>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

あんたちょっと大げさよｗ

>>210
やはり正方形ってものを正しく認識できていないだけにしか見えない。

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

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

とか、わざわざコード書いてバグ出してるとかアホの極み。

>>208
>もしかして193のいう図形ってのはたとえば以下のような特徴を持つのか？
>
>　正方形は大きさを変化させることができるが長方形は変化しない。

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

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

もしもLAC氏が「Rubyはまったく知らない」のなら、最初にそれをレスすべきだよ
それなら(自分はJavaが不慣れだから)時間はかかるけど、Javaへ書き直すこともできた
KAC氏のいつものパターンだけど、
後になってから「言い訳することばかり考える」のは、いいかげん見苦しい

>>213
それはコーディングのバグだね
以下のように訂正する

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

>>207
>親クラスのインスタンスの代わりに子クラスのインスタンス入れても動かない例。

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

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

その話もよくあるけど、こちらは抽象クラス継承でも解決できない問題だ
オブジェクト指向分析/設計(OOA/OOD)とオブジェクト指向プログラミング(OOP)との違いの
一つとも言える、より本質的な問題と言える
この問題については、このスレでも以前に一部書いた(>>71)けど、
機会があれば議論を続けたいと思う
（今は、具象クラス継承の問題とごっちゃにすべきじゃないから....）

半笑いで遠くを見つめながら言うけど、
どうして人はオーバーロードとオーバーライドを書き間違い続けるのか…ｗ
いつでも半笑いである。

設計がおかしい。
正方形クラスを継承して長方形クラスを定義すべきだろ。

>>216
| なぜそれにKAC氏は気付かない or 気付けなかったんだろうか....

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


まあ、そんなことはどうでもいいけど。
>>210-211に書いてあることが「長方形から正方形を派生してもできる」
という当たり前の事実(→実装あの仕方が下手なだけ)に何故気がつかないのかが不思議。

>>210
(2)について、
>>211のAbstractRectangleが許されるなら、
>>194においてwidthとheightをprivateにしていい。
そうすれば幅と高さの違う正方形は生まれない。

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

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

［MyRectangle setWidth:hoge setHeight:hage］を
作ったんなら、別にそのMyRectangleを基底オブジェクトを継承した新しい
［MySquare setSize:hoge］の"中に入れて"
単純にsetSizeで飛んできた同じ数値を中のMyRectangleの両方にセットするだけじゃねぇの？
それで四角くなんねぇの？？

>>214
あぁ、読み落としてた。

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

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

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

お前のソースは酷すぎて意図すらロクに相手に伝わらない事を自覚しろ・・・

普通サブクラス化によって機能・情報が増えるだろ。
この喩えは逆なんだよ。四角形じゃなくラーメンでやってくれ。

>>218
設計がおかしいのなら、具象クラス継承のまま問題を解決できる
「正方形クラスを継承して長方形クラスを定義」したコードを示せばいい
（Rubyでなくても、C++/Java/C#/Smalltalkくらいなら読むことはできるよ）
それが示すことが「具象クラス継承でも問題無し」実証することになる
論よりコードだ

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

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

>>218へのレスと同様、「実装あの仕方が下手なだけ」なら、
具象クラス継承のまま問題を解決できる「上手な実装」を示せばいい

>>224
じゃあ、C++で同じコードかいてくれ。
おかしいところ全部なおしてやるから。

抽象-具象　というのは、javaで言うところのinterfaceなんじゃないかという気がしてきた。
ちなみにrubyやC++にはinterface無いからね。

>>224
どうせ後で「後出し」とか言い出すんだろうから先に言っといてやるけど、

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

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

お前がちゃんと設計できるようになったら設計の相手してやるけど、
今回はお前の実装指摘するくらいはしといてやるよ。

>>226
？

interface - abstract class - (concrete)class
の後ろ二つの話を単にしてるようだけど？

だからラーメンのほうがわかりやすいって。

まず手続き型で書いてみて
オブジェクト駆動に翻訳して書いてみる
シックリくる方を採用。


関数型はハミゴ

あ、>>225にコードだけ指定したけど、
やっぱりお前のコードは見ても理解できないだろうから先に要求出しとく。

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

の形でいいから、(1)〜(3)を埋めてそれぞれのクラスの意図を書いてくれ。

>>228
>>210 の (1)を懸念した結果として、>>211 の AbstractRectangleのようなものが出来てるので、
これはinterfaceの話。
abstract classならデフォルトのデータセットや実装を持てるから(1)に対する答えとならない。

>>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)の問題が派生しているという意味で、
この部分の指摘はまったく正しいと思う

>>221
"中に入れて" という意味が分からない
実際、>>194では、メソッドSquare#set_size(size)の定義の中で
setterメソッド Rectangle#=(height) と Rectangle#=(width) を使って実装している
Smalltalkでもかまわないんで、"中に入れて" をコードで表現してくれないかな？

>>222
>お前のソースは酷すぎて意図すらロクに相手に伝わらない事を自覚しろ・・・

setter/getter というキーワードを見落とすKAC氏に言われてもね....

>>232
なるほどねえ。おっしゃるとおりに思えてきたわ。
>>193からの「抽象クラスと具象クラス」連呼を字のとおり読み取ってたわけだけど。

ただまぁ、「具象クラスから派生させてはいけない」ってのも分からないし、
「抽象クラス継承」で何かが解決できるからといって、
だからどうしたんだ、という気も依然しているが…。

みんな、君の「ぼくがかんがえたおぶじぇくとしこうのもんだいてん」って奴が
いったいどういう勘違いから生まれたなんなんだろうな？と訝しんでるだけで
たぶん君のコードがおかしいだけで、本質はどこもオブジェクト指向と関係ないと思ってるんだが
まだやるか。

>>235
正方形に別のメソッド作ってたのみて、
お前の意図はそういうことだと思ったんだが深読みしすぎただけだったよ。

だから、早くクラスの説明をしろ・・・と

「具象クラスから派生させてはいけない」
そんなもんなのかねぇ？と思ってちょっと調べてみたら、
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
（以下略）

なんかいっぱいあってワロタｗ

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

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

>>227
>どうせ後で「後出し」とか言い出すんだろうから先に言っといてやるけど、

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

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

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

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

捨て台詞ですか？

>>241の最後の一文を訂正

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

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

こちらも冷静さを失っているようだ
注意しよう

>>231
>>241で書いたように、次はKAC氏がコードを示す番だ
では、それら意図を満たし、なおかつ>>241の条件：

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

をコードで示してくれ
では、待っているよ

>>240
すごいな。
訳わからんソースだして勝ち誇るのか

これ、どっちが先に喧嘩売ったの？

名前わすれた

書き損じのままじゃ伝わらない気がしたのでもう一度。

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

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

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

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

で、
仕様もわからんけどバグだらけのコードをどうやって正しく示せというのか。
逃げも何も、そんなエスパー求められても困るし、正直どうでもいい。

せっかくお前の説明が理解できるようにフォローのコメントしてやってたのに
>>241-243みたいな態度をとられるともうね。

もうフォローしないので、ちゃんと自分で説明しろよ

>>246
コードが汚いとか仕様が意味不明と騒いでいるのは
KAC氏一人だけじゃないのかな？
それ以外の具体的な指摘には、その各論が正しければ正しいと認め、
違っていれば真面目に答えているつもりだ
実際、>>213のバグ指摘はそれを素直に認めて訂正してる

もし>>194の仕様では満足できないなら、KAC氏が自ら幾何学図形クラスの
仕様について、お手本となる定義を示せばいいと思うがね

>>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);

(続く)

(>>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;
};

(終わり)

いつまでどうでもいい議論やってるんだよ。
そもそもの設計がおかしい。Square をクラスにするのが間違い。
Rectangle に IsSquare() メソッドを用意するのが正しい。
加えて Rectangle.createSquare(size) メソッドもあるとよい。

Rectangleはjavaではすでに用意されてるから自作するのはアホらしい。

このスレのやり取りでオブジェクト指向は時間の無駄なのが判った

非常に短くまとめると、
コードの実装を考えながらオブジェクトを設計するから失敗する。

今のやり方はテストコードを書いて作りつつ、
設計を修正しながら開発するという手法。

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

その時テストコードがないから、
設計を変えないで局所的に対処してお茶を濁すことになって
どんどん失敗への道へ突き進むことになる。

>>251
今回の>>193から始まった流れは、
まず継承を使うという前提の元で、
具象クラスから派生させることの是非を議論してきた

その提案のポイントは、オブジェクト指向設計で
そもそも継承は必要か？という、継承を使うことの是非だよね？
そうした視点も大切だと思うけど、
今回の議論の流れからは脱線している

ちなみにObjective-Cには抽象クラスがない。
すべて具象クラスから継承する。
具象抽象うんぬんは言語仕様の問題でOOPの問題ではない。

> その提案のポイントは、オブジェクト指向設計で
> そもそも継承は必要か？という、継承を使うことの是非だよね？
アホか。継承は必要に決まってんだろ。

間違った設計に間違った継承をしている時点で「非」であって
お前らの議論は無意味だっていってるだけだ。
お前らは「議論っぽい何か」をしているに過ぎない。

なにがどうまちがっているとか具体的な指摘はできない、まで読んだ。

さて、KAC氏はコードが書けず逃げ出したようなので、
ここまでの議論をマトメて終わらせようと思う
・安易な具象クラス継承(>>194)には、問題(>>207前段,210)がある
・この問題のいくつかは、抽象クラス継承(>>211)によって解決できる
・ただし抽象クラス継承によって、すべての問題が解決できるわけではない(>>195,207後段)
・また、そもそもオブジェクト指向設計に継承は必要か？という視点もある(>>251)

これで自分は名無しに戻る
長文レスの連投、失礼しますた

具体的な指摘？251で書いたじゃん。
正方形である、というのは長方形の１つの属性だから。
変える可能性がある属性を、簡単には変更できない「クラス」
として表現するのは間違っている。
高さと長さを変えられない immutable な設計なら
別クラスでもまだマシ。

>>260カキコの後にレスに気付いたので、短くレスを返す

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

>>258
>>207後段で指摘があるように、幾何学図形クラスのような
複雑なクラス継承設計では、「上手に」やらないと失敗することが多い
これを「上手い/下手」や「美しい/汚い」といった
理想や直感で表現することは簡単だけど、そこで思考停止せず、
ナゼそうなのかという論理的かつ具体的な理由を探求していくことが大切だと思う

揚げ足取るようで悪いんだけど、もっと短く言うと設計の問題って事だよねw

用語の定義についてやりあうつもりはないが、
個人的にはOOPつったら、
そらその設計も含むやろ？って考えなんでモヤモヤするｗ
OOXXについてはOOPとOOPLだけでいいやｗ

>>261
横レスするけど、その問題はすでに>>195で指摘されていて、
>>196でレスを返しているよ
そして、たとえimmutableであっても問題の本質が減るわけではないことは、
>>195のコードで示されている

まぁ、Rectangleあるのに正方形がどうしてもほしい、
それがあったらとにかく捗るんだ、っていう状況なら、
単独で、そのままクラス一個書いたほうがマシだろうね。

長方形と正方形は、プロパティが違うだけで、
継承関係ではない

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

だから、具象クラスから派生させている場合は、
メンバ変数も同じものが使える

抽象クラスから派生させる場合は、
円、4角形、3角形のように、
頂点数が違うなど、クラス同士の違いが大きい場合

具象クラスから派生させる場合は、
かなりクラス同士が似ている場合

どうせなら元ネタのドローアプリの部品として使う方向で話してくれないかな
>具象クラスから派生させる具体例として、これはIllustratorやVisioのような
ドローアプリの開発を想定し、
この部分だけに注目してね
そもそも長方形と正方形でクラス分ける必要あるんかこれ

ない。
boolean isSquare() があればいい話なのでw

>>257
むしろObjective-Cしか最近やってないから抽象クラスってなんだったっけ？って
調べに行っちゃったよ…Obj-Cだったらプロトコル準拠とか
完全に"単なるインターフェースの話"で終わりじゃん、こんなの…
ある言語の仕様じゃ不具合が出るからオブジェクト指向は〜とかなんだそれ。

>>268
その「違いが大きい」とか「かなり似ている」とは、
具体的には何かな？

また、4角形から頂点を1つ取り除くという変形操作からは3角形が作れる
これは、>>261の考え方に従えば「頂点数は(派生ではなく)属性」になる
さて、どちらが正しいのだろうか？

目的によって変わる

課題を更に一般化してみる

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

さて、ここに幾何学図形の関係を表す図がある
http://sicp.iijlab.net/fulltext/fig226.png
これをクラスとして実装する時、
どのような考え方で設計できるだろうか？
派生、属性、それとも委譲、あるいはそれらの混在？

おい、勝手に一般化するなよ。
273 がいうように、目的によってふさわしい設計は
変わるんだからさあ。
頂点数が増減するなら、３角形と４角形はもちろん
多角形クラスの属性に決まってんじゃねえか。

というかその人193ってハンドル外しただけで193本人でしょ？

描画目的ならPath使うとか

>>276
もちろんIDを見れば分かるように193本人だよ
>>260で書いたように、
具象クラス継承の話題は終わったので名無しに戻っている

>>277
・4要素のPathオブジェクトがある
・先頭の頂点と末尾の頂点が等しい
・ある2辺の角度が直角である
さて、このオブジェクトは長方形ではないのか？
というのが>>195の指摘

特にimmutableと明示されていなければ
オブジェクトの変形操作を想定することは自然だし、
困った問題だね

IsRectangleが真になるだけ
描画目的ならそれだけで十分じゃないの？

何が問題かさっぱり分からん。

Java界隈で実際のコーディングには糞の役にも立たない議論のための議論をしてる
馬鹿な連中がいたけど、あれと同類だなこのスレの連中は。

>>278のサルがいきなり迷い込んできて
「おい！俺が壺に手を突っ込んでバナナ握ったら手が抜けないぞ！
バナナと壺は間違ってる！！」って喚いてるだけだもの。
人間に理解できるわけがない。

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違反にならないようにしようというのが正しいエンジニアの態度だと思うね。

で、>>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

class BeautyGirl < Person
　def unko
　　# 何もしない
　end

　def charm
　　# 歌って踊る
　end
end

俺の美少女がポリモーフィズム（笑）なんかでそんじゃそこらのPersonと一緒にされてたまるか。
ざけんじゃねーぞ。LSPなんて窓から投げ捨てちまえ！！

などと、多態できなければ継承する意味がないとする風潮に異を唱えており……

アイちゃん、元気良すぎるよねー

まーたレベルの低いのがまぎれこんだぞこれ。

>>284
結論を一言で述べれば「そのコードでは、問題の有無を判断できない」になる

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

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

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

なお、>>283はとてもいい参考資料だね
LSPという言葉は知らなかった、ありがとう

なにが問題なのかさっぱりわからん。

たぶんずっとこの子は

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

って叫び続けてるのだと思うよ。
ネジネジは肉まんの本質じゃないだろwとみんなが言ってるのに
まったく聴く耳ないみたいだけど。

なんだ、DDJの引用とかしてるからもう少し知識があるかと思ったが、SOLIDも知らないど素人だったか。

>>290
実装コードの中身ってなにさ。
訳わからん条件付けて質問を回避するんじゃなくて
わからないならわからないって正直に書けよ。

お前の意見に賛同してる奴なんて一人もいないだろ？
全く頓珍漢な事を喚くだけなら邪魔だから黙ってて。

反対意見が多くなってきた途端に名無しになるようなチキン野郎は
意見の主張なんて10年早いってことだよな。

誰に言ってるんだ？名無しばっかりだろう？

オブジェクト指向のプロが集まるスレはここですか

>>296
ちょっと前の>>278のことだと思われ

まあ、名前消しても>>290も同一人物だろ。

193の言ってることが理解できた奴いたら
代わりに翻訳してくれないか？

結局の所なにが問題だって言ってるの？

>>299
もともとの主張はこんな感じ。

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

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

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

安易な具象クラス継承というか、例は"馬鹿な"クラス継承だよな。
そもそもの問題からして理解できないんだが・・・

193本人が継承とは何かって事をちゃんと理解してないし
継承に関係ない問題点だらけだし指摘されても理解できないし
最後は回りに突っかかってごまかして終わり。

理解するにはかなりのエスパー能力が求められる。

>>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氏ではない他の人からの設計やコードでもかまわない

だから、まず長方形と正方形クラスをなんの目的で作ってんのかわからないとどうしようもないって

>>300
過去スレを引用するなら、改変/改竄せずに(以下の>>193のように)そのまま複写すべき

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

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


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

安易でない具象クラス継承と言っても範囲が広すぎるし、そもそも安易という言葉そのものが曖昧だ
そして、具体的な質問(>>284)に対しては、>>303で書いたように明解な答え(>>290)をレスしている

よくみたら>>194にドローアプリと書いてあった
ドローアプリでどういう理由で正方形と長方形を別にする必要があるの？
扱いに違いが出るならそもそもis-a関係にないし、同じならわざわざ無駄なクラスを作る必要はない

>>303
いっぱい言いすぎたのは悪かった。理解できないんだな。
では、>>304氏も指摘しているように>>231だけでいいから答えてくれ。

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

KACの超超超絶設計書まーだー？

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

vimと同じ動作っていうのは
仕様だってわかってるかい？

「vimと同じ動作」というのは仕様じゃないという反論は
まだ一度もしてないよね？

>>310
該当スレの8読め。何騒いでるんだか。

読んだ。で？
言いたいことは何も変わらんよ。

仕様はvimと同じでいい。

自分が間違ってるのがわかったなら
みんなにゴメンナサイしないとね。

>>305
> 過去スレを引用するなら、
引用したつもりはないよ。

> 自分は、元スレを含めて、クラスツリーやらリーフノードといった言葉は一度も使っていないぜ
引用じゃなくてまとめだから。
俺のまとめが間違ってるならそう指摘してくれ。

今回の正方形-長方形クラスの問題点は、具象クラス、抽象クラスとかは関係ないと思う。
煽り抜きで、ドローアプリ用の図形クラスを考えた場合、座標に関する情報を全く持って
ないとか話にならない。だって、それを画面のどこに描画するのかがさっぱりわからない
んだもん。
逆に、図形を頂点の集合として表現すれば、正方形とか長方形とかにクラス分けする意味
もなくなる。それが何角形だろうが何方形だろうが、どのクラスから継承されようが、統一
されたメソッドで変形、移動、描画、面積の計算、等々出来るよ。

自分の考えをまとめるよ。
1.具象クラス、抽象クラス、継承という議論をするのに、今回の正方形-長方形クラスは
適切とは言えない。
2.抽象クラスというアイデアが、そもそも良くない。「我輩の血を引くものは、みな
満月になると狼に変身できるメソッドを身につけないといけない。しかも、変身する
時は独自のポーズを編み出すこと」なんていう家の子供に生まれたくはないだろ？
「変身？できなくはないけど、親に教わった通りのやり方でやるよ」と言える方が自然。

3.デフォルトの動作が決まっていた方が使いやすいから、可能ならば具象クラスから継承
した方がラクだよね。いつ継承を利用するのかと言えば、大体の動作は申し分ないけど、
ここだけちょっとカスタマイズしたい、っていう時だもんね。

全くその通りで、継承の基底クラスならわかるが、抽象クラス？　なんだそれって感じ。

実装継承云々の議論からは撤退するけど、ひとつだけ疑問に答えてくれるかな。
暇があればでいいんだけど。

>>250のコードで、「四角形と正方形を二つ選んで、両者の幅を揃えたい」とき、クライアントコードはどう書くの？

ちょっと訂正。
「四角形と正方形を二つ選んで、両者の幅を揃えたい」
↓
「長方形と正方形が複数個ずつある中からそれぞれ一つずつ選んで、両者の幅を揃えたい」

vimと同じってどこのレス？

>>315
抽象クラスのない言語はやったことないんだけど、ファイルとネットとメモリ上と区別せずにデータを読み込みたいとかの場合はどういうふうに実装するの？

>>320
おいらはpythonをメインにしていて、そういうことをデータ源を区別しないで読みこむ、みたいな
ことは真面目にやったことないけど、もし今そういうコードを実装するとしたら、

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

みたいにするでしょうね。もっと上手い方法があれば教えてください。

>>321
言い方が悪かった
C#のStreamみたいな感じのやつを言いたかった
FileStream,MemoryStreamみたいに目的ごとにStreamを継承したクラスがある設計

>>306
>ドローアプリでどういう理由で正方形と長方形を別にする必要があるの？

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

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


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

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

今からでも遅くないので、説明してもらえないかな？
そして可能であれば、>>284の設問に対しても>>306の模範解答を示してもらいたい

＞そもそも論は、>>193から始まった議論の積み重ね
笑うとこはここ？

>>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);
}

>>320
Streamを継承して…っていうパターンは知らないが、
そういうのはfacadeオブジェクトを作って、内部的に処理を分ければいい。
引数にファイル名やらファイルの場所を取ればいいでしょ。

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

また、正方形の高さ、幅を変更可能なら正方形は長方形の一つの状態にすぎない。
正方形かを判定できるメソッドなりを作るだけで良い

>>326
あんまりデザインパターン詳しくないんだけど、新しいStreamをユーザーが追加したくなったらどうするの？
例えばデータベースとか、暗号化データを自動処理するStreamとか

Streamを使ってるライブラリ側は変更不能だとして、抽象クラスなら継承してやればいいだけだが

>>328
facadeに機能追加するかな。
そのデータベースを使うAPIなり、暗号化処理のライブラリを使うためのメソッドまたはオプションを追加。

ただ、そちらは抽象クラスStreamを基底に、機能別にサブクラスを作るパターンだと思うし、
俺が言ってるのは別個の機能をもったクラスをfacadeに纏める話なので、
話が噛み合ないだろうというか、俺も書いててトンチンカンだなと思った。

>>307
>では、>>304氏も指摘しているように>>231だけでいいから答えてくれ。

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

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

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

(長いので、次に続く)

（>>330の続き)

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

（これで終わり）

じゃあなんでドローアプリとか中途半端な目的を与えるんだよ

問題が悪いんじゃないもん!
答えられないやつが悪いんだもん。

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

わるくないもんわるくないもん。

ID:7rEGmphP触るな危険。

何だかんだと言い訳して何も主張できないアホ。
ボロボロのソース出して無知を晒した後、二度と情報を出せなくなった。
何を言っても>>330-331みたい逃げ口上だけで終わる。
相手する価値もなし。

>>314
>俺のまとめが間違ってるならそう指摘してくれ。

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

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

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

集合論という堅苦しい学問を持ち出しているけど、ここまでの内容を理解するには、
中学校で学ぶ集合の範囲に「直和」の概念を加えたもので十分だから、堅苦しくとらえなくてもいいはず
また「直和」については、Wikipediaでも詳しい解説されているので、そちらも参考にしてください

そもそも主張の基本が間違っててそこを指摘されてるのに
それすら理解してないから話が一つも進まず
議論の体を成してないのになに言ってんだ。

おまえは知恵遅れなんだよ。いい加減自覚しろ。

>>335
> 再度、読み直してもらいたい

お断りします。

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

お断りします。

今更横だけど>>193の抽象具象の定義は狭いか足りない気がする…継承も実体化もできるクラスは何と呼ぶのよ
・それを具象クラスと呼ぶなら、継承しても良いと言いたい
・それは具象クラスではないと言うなら、じゃあ何と呼ぶのか聞きたい
　→ 存在してはならない！と言うなら、存在しても良いと言いたい
継承も実体化もできるクラスは、安易に作るのは危険だが、安易でなければ良いとも思う
その安易さってのが曖昧過ぎるというなら>>283みたいなのもあるワケで

>>338
そういうこと、あまり気にする必要無いよ。
193は具象クラスを継承したことによって発生する問題みたいなこと言ってるけど、それは間違いだから。
193以降で言われてる問題は、全部実装を継承したことによる問題だよ。抽象クラスだって実装を持てる。

このスレの戯言なんか気にせずに、普通に正しく設計することが学べる書籍を読んだ方がいい。
『オブジェクト指向のこころ』
『ドメイン駆動設計』
なんかがお勧め。

>>327
>まずKAC氏の>>231に答えようぜ

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


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

着眼点として、完全に正しい
長方形が高さと幅を自由に変更できるのは、>>194のsetterを伴う属性宣言の実装コードから明らか
それに対して、正方形は高さと幅が常に等しくなければならないから、自由には変更できない(=すべきではない)
したがって、長方形から正方形を「派生させたのが間違い」である

>>338
>継承も実体化もできるクラスは何と呼ぶのよ

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


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

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


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

長方形と正方形の継承に関する問題の発見手段として、いくつかの方法論があっていい
ただ、自分は>>283の「リスコフの置換原則(LSP)」よりも、
・集合論を基礎にした継承の定義(>>335)、および
・「抽象クラス-具象クラス」という概念(>>193)
のほうが単純明解ではないかと思う、というだけの話
どちらが分かりやすいかは人によって異なるはずだから、納得できるほうを選べばいいんじゃないかと....

Java,C++やってた感覚としては、mixedって言い方は変な感じがする。インスタンス化もできる時点で、それ普通に具象クラスだと思うのだけれど。

まあ>>250程度のゴミコードしか書けない奴が何を言っても説得力ないんですけどね。
C++は不得意なんだとか言い訳するか？

すでに指摘されている事だけれど、何に使う長方形、正方形かによってクラスデザインが変わってくるのだから、万人が納得する定義はないよ。

オブジェクトの性質を決めるのは、周りとの関係だからな。
オブジェクト単体でどうこう考えるのは誤り。

長方形と正方形だけを考えるなら正方形の継承クラスとして長方形を定義すれば良いと思うんだが。

継承無くてもいいな

>>346
それは一番無いと思うぞ。

>>348
数学的な定義にとらわれすぎだと思う

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

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

ふつうに実務的なコードを書くときにはみんなそんな事しないのに、長方形と正方形と言うすごく単純な話になると、変なこと考える子が増える。

長方形と正方形を共通のインタフェースで扱いたいなら、
それ専用のインタフェース（あるいは基底クラス）を作るのが妥当だろ。
（言っておくがそれは「四角形インタフェース/クラス」じゃないぞ）

言葉に引っ張られて長方形の都合を正方形に持ち込んだり、
正方形の都合を長方形に持ち込んだりするからややこしくなる。

>>349
？ 長方形の中に正方形が含まれるなら
長方形の基底クラスから正方形という特例だろ
正方形から長方形じゃ継承する意味がないじゃん

この場合の設計って、人に理解しやすいやつを目指してるの？それともリソースを少しでも節約する方針でやっているの？
それによって継承の仕方も変わると思うけど…

>>349
じゃあ、長方形クラスのインスタンスを正方形にクラスの変数にいれたらどうなるの？
高さと幅のどっちを一辺の長さにするんだ

>>352
もともと言い出したやつは、条件も目的もまともにあげてない
目的が不明だから、何が正解とも言えない

>>353
どうなるもこうなるも長方形にダウンキャストしない限り長方形特有の機能に触れないだけでしょ。

多態にしたいなら目的に応じたインターフェース切ればよろし。

>>354
だから、長方形から正方形にアップキャストしたらどうなるのって聞いてるじゃん

正方形でない図形をどうやって正方形として処理するの

>>355
処理ってどんな処理だ、、、

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

ていうか、アップキャストしたままで操作するってのは多態なんだから、目的の示されていないこの問題で考えるだけ無駄だよ。
まじめに使用目的を類推したら正方形と長方形で別のクラス定義しなくなるし。

まず想定する仕様くらいはっきりさせないと。
こんな状態で話してても混乱するだけ。
(まあ、発端の奴が仕様の必要性すら理解してなかったのが原因だけど)

例えば、

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

と定義したら、クラス構成もどんなメソッドをどうオーバーライドするかもイメージできるだろ？
各自が思っている仕様なんて実はバラバラなんだからまずはその辺を意識するべき。

>>356
オーバーライドに想定するインタフェースを教えてくれないか？
正方形が基底になるケースって、俺は思い付かないんだが、相当特殊なケースだよね？

>>356
すまん、俺が読み違えたわ。
君のその主張だと、ポリモフィズムを考慮するのは(現状の情報だけでは)無駄だって言ってるんだよね？
それは、そもそも継承を論じるラインに立って無いわ。

>>356
長方形クラスでできることを再利用するために
それを継承して正方形クラスを作るならわかるが、
正方形クラスを継承して長方形クラスを作った上
正方形クラスとは別に長方形用のメソッド書くってナンダ。

また舞い戻ってきて意味不明な脳内前提で語り始めたか

>>358
そんなに特殊だろうか、、、
外部から使うときの要件が示されていないから多態は考えない。
でも継承したいらしいから継承はする。
正方形と長方形の重複要素は正方形と一致するので正方形を基底クラスにしたら継承クラス側で無駄なコードを書く必要がない。
↑共通コードを全部基底クラスに置けるから二つのクラスを実装する上でコード量が一番少なくできそうな気がする。
ってだけだよ。

そもそもふつう長方形を扱うクラスを作った上で正方形だけのクラス作る事が有るとも思えないから、用途が特殊と言うより、正方形と長方形で継承関係作ろうとすること自体が特殊だと思うけど。

> オーバーライドに想定するインタフェースを教えてくれないか？

って>>358は言ってんだから答えてやれよそれを。

>>361
オブジェクト指向の大前提である既存のパーツを再利用して
必要な新要素を足して新しいクラス作るんじゃなくて
"全部含んだでっかいもの"を作ったとこから機能削減版を派生させようとしてんの！？
なんだそら

>>363
逆だよ。
長方形の方が集合として大きいんだから、
長方形を基底クラスにすると正方形にするために削る要素が出るだろ。


>>362
んなまじめに考えてない。
と言うより、幅か高さの片方しか変更できない正方形クラスにもう片方の変更機能を追加するだけで長方形になるでしょう。
それ以外の機能は関係ないよ。なにやろうと共通だし。

なにをするクラスの話をしてるのかちょっと説明してみ？
正方形クラスにはどんな要素とメソッドがあって
長方形クラスにはどんな要素とメソッドがあんのよ。

＞長方形を基底クラスにすると正方形にするために削る要素が出る

…出るか？

getWidth()とgetHeight()が内部的に同じ処理になって
setWidth()とsetHeight()が内部的に同じ属性を弄るようになるくらいで
表向きには削るインタフェースは無い気がするんだが…

>>365
まさにそれ。
というよりID:phibx9jhつついても有意義な回答が得られる気配は無いがｗ
OOPなーんもわからんのに聞きかじりでしゃべってないかコイツ。

>>364
> と言うより、幅か高さの片方しか変更できない正方形クラスにもう片方の変更機能を追加するだけで長方形になるでしょう。
> それ以外の機能は関係ないよ。なにやろうと共通だし。

長方形と正方形がそれぞれ複数個存在するオブジェクトの集合から任意に二つ以上の
オブジェクトを選んで、その幅をそろえたり高さをそろえることを考えると、その設計では
破綻する。

長方形正方形の関係は>>357がわかりやすい
関係を反対にしたら実装も破綻する

>>364
コード出してみなよ
お前の考える仕様の擬似コードでいいからさ

まずは仕様だろ

オブジェクト指向は再利用がメインではない。
特定の傾向の問題に対して特定の構造のプログラムで
対処すれば処理しやすい、その構造に名前をつけたもの。
基本的にクラス言語を前提として考案されているから
非クラス言語には向かない。

正方形は長方形であり、菱型であり、平行四辺形であり、台形でもあり、そしてその他の四角形でもあるわけ。
確かにis-aなんだけれども、派生よりもキャスト演算子を定義する方が適切と思う。

意味がわからん
コード書いてみろ。破綻するから。

正方形 is 長方形
正方形 is 菱形
長方形 is 平行四辺形
長方形 is 菱形…とは限らない
菱形 is 平行四辺形
菱形 is 凧形
菱形 is 長方形…とは限らない
平行四辺形 is 台形
台形 is 四角形
台形 is 凧形…とは限らない
凧形 is 四角形
凧形 is 台形…とは限らない

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

ただ、ちと普通の継承と違うのは非継承関係のものが is NOT とは言えないことか
長方形が菱形である場合もあるし、菱形が長方形である場合もある(それが正方形)
あくまで「…とは限らない」だから

http://upload.wikimedia.org/wikipedia/commons/f/f1/Quadrilateral_hierarchy.png

…やっぱ、継承で表現すること自体が無茶そうだなあ

正方形を基底にもつ長方形クラスの仕様 or コードまだぁ？
( ・∀・)っ/凵⌒☆ﾁﾝﾁﾝ ☆

>>375
まずは仕様だろ

結局、オブジェクト指向をやめる理由はなんなの?

オブジェクト指向まがいが平然と広まるからだろ

いつの間にか継承に関しての問題になってるな

オブジェクト指向は〜とご高説をのたまう人の「オブジェクト指向」は
継承のことだからな。

>>382
それではあなたのオブジェクト指向とは？

聞いてみたいもんだ。
答えられない思うけど。

オブジェクト指向って厳密な定義があるわけじゃなくて、雰囲気みたくぼんやりした存在

>>383-384
とりあえずWikipediaの「オブジェクト指向」の項にまるっとそのまま書いてあるな。
あと俺が思ってる事も「オブジェクト指向の名称とメッセージング」の項そのまんま。

じゃあ俺は
Object-oriented programming - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Object-oriented_programming

の方を推そうかな。読んでないけど日本語ページとは何か違うｗ

オブジェクト指向は〜とご高説をのたまう人の「オブジェクト指向」は
参考Wikipediaのことだからなｗ

オブジェクト指向プログラミング - 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とはフィールドとメソッドを持つ"オブジェクト"の概念を表現するプログラミングパラダイムである。

なぜ日欧でこうも解説の方向性がズレるのか。

> Object-oriented programming is an approach to designing modular, reusable software systems.

これで十分だと思うけどな。それぞれのOOPLが持ってる特徴って、
けっきょくんとこ、モジュール性を高めるための手段にすぎないって我思う。

このスレにOO 否定派はまだいるのかな。

肯定派がOO の実践方法について議論してるだけ？

>>391
例えば>>346は反対派のエージェントである可能性が高い。
肯定派がOO議論しているように見せかけているが、実は反対派の高等戦術で、混乱をけしかけている。

…のかもしれないなw

否定派ならともかく、反対派っていう捕らえ方はないだろｗ
利害関係の押し引きになってる状況じゃないし。

あと>>346は単にアレと思うよ。
なーんもわかってないのに知ったかぶりたいだけの子。

否定派にはもっと頑張ってほしいね
否定派が立てたスレなんだし

>>390
おまえみたいにカンチガイしてる奴がいるが"そうではない"
と日英ともはっきり釘を刺す内容になっているわけだが。

結局正方形クンは逃げたの？ｗ

馬鹿は複雑に考えすぎなんだよな

2chも変わったな。昔はアホみたいなオブジェクト指向否定派がうようよいたのに

知らない間にオブジェクトに頼ってることに気づいたからじゃね？
代わりにオブジェクト指向まがいのなんちゃって縛りを強要する輩が増えたけど

オブジェクト指向まがいのなんちゃって縛り？
たとえば？

ID導入されたら自作自演が出来なくなるからな。

はぁ？？

オブジェクト指向でも出来るだけ不変オブジェクトを使う
設計のほうがバグが出にくくなることに気付いて
実施し続けた結果、関数型で良いじゃんという結論になった

関数型で全てを書くのはきついので、
オブジェクト指向＋関数型言語が現実的

全体の構造部分にオブジェクト指向を使い
メソッド内の処理の部分に艦型言語を使う。

「オブジェクト指向まがいのなんちゃって縛り」って何だよ。
それを「強要する輩が増えた」ってどこの話だよ。意味不明すぎる。

>>404
関数型言語にも立派なモジュール化機構があるじゃん
なんで全体構造をオブジェクト指向にする必要あんの？

>>398
昔はオブジェクト指向=C++でCを使ってる構造化プログラマと
C++を信奉するオブジェクト指向(？)プログラマが争ってて、
いまはその二者にJavaやObjective-Cプログラマがツッコミ入れてる状態。

>>406
> なんで全体構造をオブジェクト指向にする必要あんの？
適材適所だから。

>>408
どう適してるのかを問われてる訳だが

関数は状態を持たなくてよいが
オブジェクトは多くの場合
状態を持っているから。

大部分を状態を持たないオブジェクトで構成すればいいじゃん

それは無理。
実際作るべきもの、アプリの仕様の時点で
状態を持っているのだから。

「関数型プログラミングなんて今すぐやめてください」
というスレになってるかもな、何年後かには

状態と処理を分離したほうが
汎用的なコードになるしテストもしやすいんだよなぁ

>>412
アプリの仕様に状態が含まれていても、
それを関数型言語で実装することは可能だよ
もちろん破壊的代入を使わなくともね

汎用性とは無条件に善なるものではない

オブジェクト指向ってのは２５年ぐらい前にこのままだとやがて手に負えなくなるから
各モジュールを分離して、その間を人間に理解できる命令でやりとりするように作り、独立性と再利用性を高めようという考え方で
それに対して当時の貧弱なパソコンでプログラムしていたプログラマがそういう『ムダ』なオーバーヘッドをとことん嫌って
「playなんて予約語作んなくても、引数Fが1だったら処理A、2だったら処理Bの方が『効率がいい』じゃん。
いやいや、１バイト８ビットの中で256の状態が表せるからコントロールの１バイトバイナリを送った方が『もっと効率がいい』ぞぉ〜！」
みたいな思考だったもんだからマシンの処理速度が上がってプログラムの規模が巨大化した近年までなかなか普及しなかったわけだけども
もういまでは家電の中身の基盤同士をハンダ付けで結んだりしないのといっしょで、
こういうブロック分け的なオブジェクト指向は揺らぐことのない既定路線になったと思う。
一方で、関数型ってのはどうも上のミニマムなアプローチの発展系で細々した部分で
こうやって書いたら齟齬やバグが少ないぞ！って方向性に見えるので、モジュール内の記述言語としては一定の需要が…あるのかなぁ？
Objective-CがC+smalltalkであるみたいに中身が関数型でモジュールの扱いがオブジェクト指向のなんかが出たりするのかなぁ…
Obj-Cといっしょで関数型信奉者がすげぇキモチワルがりそうだｗ

>>417
だから関数型言語にもモジュール化の機構はあるってば
知らんのだったら無理して語るなよ

>>417
25年どころか、1972年にsmalltalkの開発が始まったわけで、概念自体は
それ以前に遡るのですが？

モジュールってかクラスそのものに近いような機構もあるだろ関数型言語でも

>>415
仕様が状態であるなら、それをそのまま状態として表現したほうが分かり易いかと

>>421
なにかに置き換えるみたいなことをしなくとも、
そのまま直感的に関数型言語で書けるよ

>>422
じゃあ書いてあるコード見せて

>>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

ほらとたんに難しい話になるｗ
完全にオーバースペックなんだよね。

簡単に実装するにはオブジェクト指向が適切なわけ。

>>424程度の話が、>>425にとっては難しいのか....

え？ 難しくないつもり？
英語の時点でアウトなんだけど。

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

俺はわかる。じゃなくて客観的な指標で考えようね。

ID:ktmFmLGc は技術英語が読めない

これが客観的評価だろ

ID:ktmFmLGc は "関数型 状態遷移" でネット検索するだけのスキルも無い

これも客観的評価だな

あーあ、相手を貶める方向に行っちゃった…

ID:Gj23aJd4 は切れやすい

これが客観的事実であることがよくわかった、

>>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);
}

ID:ktmFmLGcの評価をしてどうするｗ

関数型言語で状態があるものを作るのが
難しいかどうかの評価をしろよ。

再帰を難しいと思うなら、関数型で状態のあるものを作るのは難しいと思う。

末尾再帰の展開が保障されてない言語で再帰愛用奴ｗｗｗｗ

再帰は状態がないだろ？
状態があるものの例になっていない。

>>436
むしろ状態を再帰で定義するんだ
筋金入りの関数型言語派はたしか自然数ですら再帰で定義したがるとか
0 を定義して
1 = f(0)
2 = f(f(0))
3 = f(f(f(0)))　あー、ペアノの公理そのものだね‥

無理やり状態を定義するために再帰を使う。
普通にクラスあって、フィールドがあればできることなのにね。

とりあえずわかったことは関数型とかいうのは文章で表せなくて
「自明だ」「ググれ」「バーカバーカ」で成り立ってる言語らしい。

関数型の方がオブジェクト指向より文章で良さを説明しやすいぞ
再代入禁止でバグりにくいとか、テストしやすいコードになるとか、強い静的型付けでバグを未然に防ぐとか

むしろオブジェクト指向の方が
説明が宗教っぽくて「疑うな！信じろ！」になりがちなんだよなぁ

説明が宗教っぽくて？
たとえば？

疑うな信じろ

オブジェクト指向は英語が読めない
技術者失格レベルの低脳でも
分かった気になれるのが良い点だね

まあ、流行った順だろ

車を作ります。何からできているでしょうか？

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

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


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

サイキガー、サイキガー

・・・無理でしたｗ

オブジェクト指向厨っていつまで経っても
例えのセンスが犬猫クラスから進歩しねーのな

>>446
その車クラスとやらインスタンス化するのに幾ら費用が掛かるのだ？

>>446
関数型で車の静的にモデリングする時、分析/設計の段階、
いわゆる OOA/OOD まではオブジェクト指向と同じ
つまり ボディ、シャーシ、エンジン、etc は関数型でもオブジェクト
オブジェクトがシートの色といった属性を持つことも変わらない
違うのは実装(プログラミング)の段階
関数型だと、上記のようなオブジェクトはタプルやレコードといった直積型を用いる
もしカプセル化が必要であれば抽象データ型を用いる

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

なお、上流工程の分析/設計にオブジェクト指向以外の方法論を採用してもかまわない
たとえば業務システム開発であれば、1980年代頃に普及し今でも活用されている
DOA(データ中心指向)をそのまま用いてもいい
逆に言えば、関数型に最適化されたシステム分析/設計の方法論が確立していないのが現状

>>449
だから、構造はオブジェクト指向で
関数の中だけ、関数型使えばいいってことでしょう？
最初に言ったとおりじゃんか。

>>450
>だから、構造はオブジェクト指向で
>関数の中だけ、関数型使えばいいってことでしょう？

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


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

知らんがなw
2chで主張が一貫していると表明したいなら、ハンドルを使わないとね

関数がファーストクラスのオブジェクトの言語では
値と関数の区別があんまり無いですが、
レコードに関数を含めれば
関数型もオブジェクト指向になりますか？

プロトタイプベースのオブジェクト指向？

オブジェクト指向というとなぜかC++とかの"機能面でのオブジェクト指向"にいくけど
上でもたしか出てたように、JavaとかObjective-Cとかのオブジェクト間を
「これをやれ」というメッセージコマンドで結んで人間にオブジェクト間の関係が
わかりやすいように作るってのが本来の方向なんで
本気でやるならだいぶ違う概念のものを混在させることになるから
(よく概念が違うものが混在して気持ち悪い言われるObjective-C…)
ちょろっと改造して見た目オブジェクト指向的にしましただと
これが新言語haskell++だぁ〜みたいになって空中分解する気がする。

オブジェクト指向がスレッドなど手続きの主体に縛られるのはよくないと思う。

ちゃんとメッセージのやりとりでプログラムを表現できてるのは
Erlangくらい
Smalltalkのはニセモノ

>>456
並行オブジェクトという視点だと、ABCL の他、
手続き型では Occam、論理型では Concurrent Prolog や GHC(KL1) がある
マルチパラダイム言語である Oz も対応している

関数型の Erlang は新顔だね

>>454
機能そのものがオブジェクト指向なのではなくて、オブジェクト指向し易いように機能がある
…ってのは、本来最初に語るべきなんだろうに、どうしても機能の紹介から入っちゃうからなあ

現在のオブジェクト指向の矛盾はクラスからオブジェクトを作ることだろう
本来ならオブジェクトが先にあり、それを型に当てはめる事で共通の処理を行う
クラスよりオブジェクトのほうが大きくなければならないのだ
オブジェクトには動的にいくらでも要素を追加でき
１つのオブジェクトに対し様々な型（クラス）がアプローチする
これが本来のオブジェクト指向のあり方だと思う

先に[オブジェクト指向の矛盾]を説明してくれ

>>459
＞本来ならオブジェクトが先にあり
＞本来のオブジェクト指向のあり方
「本来」っていう根拠はなに？

オレオレ定義に思えて、オレも納得いかない

>>459
MVCの提唱者であるTrygve Reenskaug氏による、
現在のオブジェクト指向に対する批判とDCIの提唱に通じるものがあり
興味深いですね。

http://d.hatena.ne.jp/digitalsoul/20100131/1264925022

>>459
それなんていうプロトタイプベースのプロパティー？

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

きみらは一体…

ど素人？

javascriptしか知らねーのかよ。おめーこそ素人丸出しじゃねーか

>>464
ﾌﾟﾛﾊﾟﾃｨｰやプロトタイプベースｵﾌﾞｼﾞｪｸﾄ指向は
javascriptだけの物ではないんだが…

素人にまで知られた言語ではjavascriptが有名だ。

あ、このスレだ。
いま、Swiftのクラスとオーバーライドの説明読んでたら
サンプルがそのまんま「名前付き多角形」って
「名前」というプロパティを持ちメソッドで「説明」返すクラス作って
次にイニシャライザでインスタンス生成時に名前を送る方法
その次に「名前付き多角形」を継承して新しい「正方形」クラスを作って
「辺の長さ」というプロパティと「面積」ってメソッド追加して
説明を返すメソッドをオーバーライドして
正方形の説明返すようにする
オーバーライドの解説…と
>>300辺りから聞き分けのない子と延々やってたネタそのまんまで噴いたw

全てのオブジェクトをグローバルなプールに浮かべて
クエリにかかったオブジェクトを一括処理って感じの言語って無いかな
シューティングゲームで言えば、Enemy毎に処理したり、画面上の全ての
オブジェクトを一括処理したりとクエリによって集団が変わる感じ
コンテナをインターフェイスとして使うイメージって言えばいいのか

座標と移動ベクトルを持ったオブジェクトを列挙して移動させる
みたいなのを１行で記述できたらカッコイイ

クラスから作るのはインスタンスであって
オブジェクトはクラスの上位概念

って習ったけど矛盾って何？

>>459のことなら言葉の使い方が変すぎてよく伝わらないが
なんとなく「いまの車はエンジンとかタイヤとかのパーツから組み立てられてるが
本来は"基本の車"みたいなものがあってそれを改造するのが
正しい姿だとボクは思う」ってんじゃないの。
バイクとかボートとかどうすんだよとか、そもそも
オブジェクト指向なんだから、パーツ組み立てた「基本の車」って
クラス自分で作って再利用すりゃ終わりだろそれとかあるけど。

無知なんでプロトタイプベースとどう違うのかわからん

オブジェクトという言葉は文脈によって意味が大量にあるから日本語が下手なやつが使うとおかしくなる

なんて言えば良いのか
オブジェクトは全ての情報を持っていて、クラスはその１面を
表すにすぎないみたいな感じ
全ての情報を予め持たせる事は出来ないから
オブジェクトには後々新しい意味を付加できて、
それによって対応できるクラスが増えていくみたいな

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

それだと全てのオブジェクトからクラスで検索掛けられる仕組みがいるかな

オブジェクト=インスタンスの意味で使ってまつ
現実のあり方に合わせたオブジェクト指向っていうのか
物が先にあって、人間による概念を適用することで
そのように扱うことができる、みたいな

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

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

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

例えが微妙か

オブジェクト指向は愚かな考え。
http://peace.2ch.net/test/read.cgi/tech/1393660194/

アタリとかナムコとかのゲーム機では、まさに自機とか弾とかを
オブジェクトと呼んでたんだよね
つまりVCSはオブジェクト指向だったんだよ

Rubyとか、動的言語ならよくある気がするが
継承などに関係なく、名前で呼び出しができる

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

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

さらに、ペンを凶器としてつかうのに威力とかの設定が必要になるとあらかじめ用途を考えてるわけで、まずオブジェクトありきとはいかない

>>473
AppleのSpriteKitがそもそもそういう感じだし
知らんけどcocosとか最近のゲームキットはみんなこれ系ちゃうの。
http://d.hatena.ne.jp/glass-_-onion/touch/20140411/1397220091

オブジェクトって対象のことだろ
英文法のSVOのOだろ

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

後者式に書くプログラミングだから
オブジェクト指向プログラミングなんだろ

>>478
オブジェクト指向のオブジェクトは
メッセージを受け取るものだから、Sだよ。
昔はさあ、こう書いてたんだよね。
Take(Taopaipai, Mail)
オブジェクト指向ではTakeというメッセージをTaopaipaiが受け取るようになるんだよ。
Taopaipa.Take(Mail)

ジョークにマジレスすんなよ

Sはないだろ命令文なんだから
VOにするかOVにするかだけ

VO_OV

VOsOV

オブジェクト指向とは「処理の移譲」です。
Cに代表される構造化プログラミング言語がモジュールを
関数というブロックに分けることによって入力と出力という
ブラックボックスとして扱えるようにカプセル化したのに続いて
オブジェクト指向はオブジェクトに"コマンド"を送る形にすることで
オブジェクトが能動的に振る舞い方を変えることを期待しているのです。

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

この「コマンドと具体的な処理を分離する」という考え方が
オブジェクト指向の重要なポイントなのですが
"プログラムとは間違いのない完璧な指示を与えて完璧に指示通りに動作させることだ。"
というコンピュータプログラマに刷り込まれた教義とまさに真っ向からぶつかるため
ベテランプログラマであればあるほどなかなか受け入れてくれません。
オブジェクト指向とは"そういうもの"です。

どうせ内部ではthisを第一引数にとる関数に変換されるんだろ？

どうせ仮想関数も内部では switch 文の嵐だろ？

>>485-456
つまり複雑な内部はコンピュータが生成し、表面（人間が書く所）は
シンプルに見せてくれるのがオブジェクト指向ってこと？

それはオブジェクト指向を実現するための手段であって
オブジェクト指向そのものじゃないだろ

操作と操作対象があったら
操作対象の方に着目するのがオブジェクト指向だろ

>>484
自動化とオブジェクト指向は関係ないだろ

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

これ肝心の対象が抜けてるだろ

Windowsでいうなら
notepad.exeでhoge.txtを開くのは非オブジェクト指向で
hoge.txtをnotepad.exeで開くのがオブジェクト指向
どっちを基点にするかの問題だ

>>487
プログラムするのは人間だからコンピュータがなにかを生成するわけじゃないけど
モジュールに役割と責任を与えることで責任の所在を分離する。

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

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

歴史でなにが酷いって、よりによってオブジェクト指向を大々的に名乗ったC++が
ここの部分をムダ要素として切り捨てて単に継承と再利用を
オブジェクト指向の主要素とした言語だったってこと。
JavaとかもっとファンダメンタルなObjective-Cが再発見されるまで
一番大事なとこが伝わりゃしなくてみんなで
そこにはいないオブジェクト指向の意義を議論してたという…

>>491
長ぇよ。
伝えたい事はシンプルに。

なんか脱アルゴリズムの人と同じ臭いがする

いじめられっ子がここにきて苦だ巻いてる
上司のパワハラが原因か

長い上に要領を得てない
最近本でも読んで分かった気になった大学生か

桃白白は興味深く拝読させていただいたけど？

オブジェクト四股なら強くなれるの？

要はポリモじゃなくて
インタフェースとファクトリを主力にすべきだったって言いたいんだべ

そんな意図じゃないでしょ。単に、データ抽象の概念を知ったか発見したかで感動して、
俺はオブジェクト指向を理解したお前らは理解してないって思い込んでるだけ

アクターやエージェントの話だとピンとこないやつははっきり言ってダメじゃねぇかな。

オブイェークト

俺だけはわかった病

エージェント指向なんかは命令された目的をに対してエージェントが自発的に目的を果たすのを期待されてるからそっち系だよね

多重分類を多重分類のまま扱えるということに意義がある

名前空間もデータ構造も関数も継承も多相も全て一緒くたになっちゃうんだよね
ばぁっかじゃないの

所詮、どれも分類の問題じゃないか

普通にプログラムすると、メモリやメモリ空間を虫食い状態にするからなあ。
オブジェクト指向派は、それを言語仕様のせいではなく、OSに責任転嫁するんだよねえ

>>507
昨日iphone5を再起動した、動かなくなったカメラがまた動くようになった、結局どのOSも似たり寄ったりだねメモリがらみでは

>>507
まさに上で言われてたのはメモリ管理などはOSレイヤに処理を任せて
アプリ側では考えなくてもいい、いやむしろ考えては"いけない"形にしないと
アプリが自分でメモリにちょっかいを出すことでアーキティクチャの違い、変化を吸収できなくて
将来の保守、移植に支障をきたすという類の話なのだが。

>>509
実際にはアプリ側でもメモリ管理をバンバンしているんだがねここ最近は
オブジェクトを解放したからといって、OSにまでそのメモリを返しているわけではなかろう？

×アプリ側でも
○ライブラリがやってる。

ライブラリとリンクされたアプリがやってるんだろ
動的リンクならギリギリライブラリがやってると言えなくもないが

iPhone のカメラアプリの動作がおかしくなった‥写真が取れない‥
アプリを再起動してもだめ‥
ふと気がついて iOS 自体を再起動したら直った‥

どこもメモリの断片化を完全に解決できてないんだね
Java も起動して半年もたつと占有したメモリが積もり積もってどうしようもない

iPhone のカメラアプリの動作がおかしくなった‥写真が取れない‥
アプリを再起動してもだめ‥
ふと気がついて iOS 自体を再起動したら直った‥

ネイティブアプリは
メモリの断片化を完全に解決できてないんだね