そのくせOOPを十分に理解してないから痛々しい
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
実際、「オブジェクト指向」という制限が掛かることによって
実装できなくなったプログラミングイディオムってあるよね。
「闇のデザインパターン」とでも言えばよいのだろうか。
誰か、そういうのをまとめてくれないかな。
出版してくれたら、絶対に買うよ。
アンチパターンですね。
アンチパターンは、元々やるべきではないもの。
これは、役に立つけど、諸般の事情で使えなくなったもの。
アンチパターンだから使えなくなったのです。
ttp://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
もしくはCで学ばなくてはならない。
外人のネタコピペも結構レベル高くなってきたな
どっかのオブジェクトのメソッドを実行するための何かとか
もう意味不明ｗ
>>1は責任もってネタを出すように
まさかあれで終わりということはあるまいな
そうだな
ＯＯになびく奴は昔から頭がちょっと弱めが多い
ネタが尽きたら自問自答は定番だよな
それがあるべき理想の姿だな
パターンは糞。まだ分からんのか。
糞コード化しやすいところが駄目だわ。
そのように、パターン名に名前がついてるってのは
すごく重要だよな。
もしSingletonパターンという名前が存在しなかったら、
>>25の書き込みを正確に書くことはできるだろうか？
洗脳されやすいタイプだなｗ
パターンなんてのが出てくること自体原始的状態だってことだよ。
たらたらとアドホックに追加するだけだろ。１０年たったら全部消えてるよ。
じゃあ10年後にまたおいでｗ
オブジェクト指向は動的なポリモーフィズムが必要な一部に局所化して利用するくらいがちょうどいい。
手続き型の範囲ではないんじゃない？手続き型プログラムは、クラスをがひとつだけのプログラムか、
staticメソッドだけのプログラムと同じなはずだから。
もちろんアセンブラ的なことは考慮しない。
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
所謂オブジェクト指向言語はオブジェクト指向してないんじゃないかというなにか
http://d.hatena.ne.jp/Flast/20111206/1323152264
「・・・ないんじゃない？」って、
「オブジェクト指向言語でも実装できるよ」って意味？
そりゃ当たり前。チューリング等価なんだから。
でもそれは、アンチパターンでいうところの
「抽象化の逆転(Abstraction inversion)」になるね。
うーん、オブジェクト指向の機能を使って(メッセージ送信とか)を使って、
手続き型と同じことをしようとするなら、その「抽象化の逆転」になるだろうけど、
大半のオブジェクト指向言語は、オブジェクト指向の機能を使わなければ
手続き型言語そのものになるからなんとも。
手続き型の範囲に限定したのはそのため。
関数プログラミングだってメソッドひとつのイミュータブルな
オブジェクトを使えば大体同じことができるけど、それはたぶん
「抽象化の逆転」になるんでしょう。
一応プログラムは作れる、ooに拘泥するアホはHSP厨以下
オブジェクト指向言語は小さなものを作るのに向かないので
今は大きなものを作る言語と小さなものを作る言語
最低 2 つの言語を使えないとプログラマとして使い物にならなくなった
んー・・・
例を挙げると、lisp や JavaScript の実装で使われている
ポインタへのエンコーディングとか、どう？
あれって、何かそれらしい名前がついていたような気がするのだが、
思い出せない・・・
C#＞Java＞＞C++
他の候補：F#、Python、Ruby、Scala
c++は規格のライブラリが貧弱なだけで、抽象度はライブラリによる
vclは優秀だった。。。
最適化でvcに負けたけど。。。
(mfcには負けてない)
C++のコードデバッグで辿って行ったら途中でPascalになるんだぜ。
あ、Pascalじゃなかった。Delphiという独自拡張された言語。
気持ち悪いったらありゃしない。
多分、体現度はsmalltalkが一番
その分、仮装OS的なものが必須だし、>>36の上のurl通り、全体をデバッグしてるんだが。。。
データと手続きが一緒になってるせいで並列化にも向かないって話もある
かえって構造化言語のFortlanの方が超並列ライブラリと言う資産でスパコンで現役だったり
Erlangの中の人がデータと手続きは別のものだ。一緒にするべきじゃない！と言ってたり
(日経ソフトウェア2009年6月号だったと思うけど、matzと結城さんの対談の記事で書いてた)
賛成だね。
データの寿命は長いが、手続きの寿命は小さい。
データベースなんか、データ専用じゃないか。
Cでもライブラリ充実させて、ジェネリック(C++ではテンプレート)をサポートすれば、生産性はオブジェクト指向言語と変わらんのじゃ無いか？と言う疑惑は持ってる
(疑惑だけで確証は無いんだが)
smalltalkのように制御構造までオブジェクトという程まで
徹底されてないから手続き型っぽさが抜けない。
fortlan2003ではオブジェクト指向が導入されたらしい
マ板内検索したら、確かにＦｏｒｔｒａｎだなｗ
フォーミュラ何とかランゲッジって覚えてから、lanだと思ったんだが、違ったｗ
自分のほうが、この業界から去ってしまいましたとさ。
オブジェクト指向プログラミングはともかく、オブジェクト指向設計とか、何やねん。って思うよな
クラスベースより、プロトタイプベースの方が再利用できてるじゃねえか。みたいな
クロージャの方が、継承よりも再利用に適してんじゃねぇか。みたいな
どんだけ時間の無駄だったのかと
何の話してるの？
あるある
んで、決まってOOP以外はソースがダメだダメだみたいな
プログラミングしていくに当たって
設計思考がひとつしかない奴ってどうなの･･･････
確かにOOPは万能で、どんなプログラムもかけるけど、あくまで汎用性が高いだけで
１０段階評価で全部７程度なだけ
専門特化した設計思考も選べるなら、そっちでやったほうが効率でるんだよ
そっちは１０段階評価でひとつだけ１０を取って他を３くらいにするような感じ
そもそも関数型（）っていう言葉があるのも、変な話
だって、関数っつったらプログラミングの最小単位だからな･･･？ｗｗｗｗｗｗｗｗｗ
関数のところまで分解して考えられるなら、そこからどんな設計思考だって作れるよ
一々、その設計思考に名前をつける事のほうが変な話、無限のパターンがあるのに
それにも気づけず、OOPしか出来ない奴、思いつかない奴、
かなりマジレスしてみた
どうもなるはずないよ。
ＯＯＰ、デザパタ、ＡＯＰなどなど、ほんとソフトウェア工学は他で使えない頭の弱い連中が
やりちらかしてきた歴史だな。そろそろ仕分けしろよ。
関数型ではこうはいかない
関数型言語の場合、まんま数学で言う特殊から一般へ。と言う手法が使えるから楽だよな
なるほど。特殊から一般だな。分かった気になったぞｗ
これで俺もいつ関数型言語の仕事がきても大丈夫だな
とりわけFortranの場合、90でモジュールが導入されて、モジュールの中に
手続きが書けるようになったが、さらに2003で構造体の中にも手続きが
書けるようになった。2通りの手続きを束ねる手段があって、冗長に思える。
過去のやり方を無かったことにはできないから互換性のために残してんじゃないの。
演算子オーバーロードできるなら
オブジェクト指向の使い道はあると思う
javaは使い道ありませんかそうですか
あるよ。さらに利用者定義中置演算子が定義です。ただし、これは2003の
オブジェクト指向の上に載っているのではない。Fortranには伝統的に
「総称名」という概念があって、cos(x)と書くと、xが単精度であれば、
cos(x)[字面が同じで紛らわしいが別のもの]、倍精度であればdcos(x)に
コンパイル時にディスパッチする。
95これを利用者定義型できる。具体的には、それぞれの型ごとに
同じ形式を持つ手続きをそれぞれ定義して、これらにひとつの総称名を
割り当てるという形をとる。このとき、総称名の代わりに演算子を
割り当てることができる。
>>78
Javaが演算子再定義を持たないのは、これこれで言語仕様を簡潔に保つ
という上で適切な解だと思う。メソッド名が長いのはいとわず、英文で
説明するように処理を記述することを期待しているようなので、演算子
は削ってもいいだろう。
ドカタが混乱する。
出来ないのが正解。
演算子オーバーロードをなにか特殊なものだと思ってるの？
まともなプログラマなら思わないけど、ドカタは思うだろう
…と言う意味では
高慢と偏見（1）隣は何をする人ぞ
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html
どこかの「ぼくがしんかさせたすごい言語」状態のゴミになるのを避けるために
単に力量不足、柔軟な機動力不足だろうと思ったり。
あと、設計に時間とって、ＵＭＬみたいなお絵かきを自慢げに出すようになったこと。
そんなの書くのに時間とるやつより、ちょっぱやな動作デモを即効作ってくるタイプと仕事してる方が楽しいのにな。
オブジェクト指向の弊害云々はオブジェクト指向以外にも当てはまるからいまいち
昔から沢山あるだろ。むしろ昔のほうが多かったぐらい。
「動いてるからいいじゃん」タイプか。
そういう奴に任せると、後で苦労するぞ。
趣味なら別にいいが、仕事では相手にしたくないわ
「金払ってるからいいじゃん」タイプか
そういう奴に仕事もらうと、後で苦労するぞ。
これが問題なんだ
他とのインターフェースだけオブジェクト指向とかできれいにしてりゃいいよ。
オブジェクト指向じゃないコードをバカにするわりには、面白いコードもかけない人の方が、
なんだかんだ理由をつけて進捗のボトルネックになることが多いよ。
基礎がないのに、オブジェクト指向な人が多いから、混乱するだけど、OOが悪いわけじゃないな。
> ちょっぱやな動作デモを即効作ってくる
そが即効なのは「後で変更する人たちに工数を押し付けた」結果だったりするからな。
納期直前とかならそういうやり方もありだけど、普通はOOに限らず影響範囲が小さくて済むよう
それなりに設計するもんだ。
その言い方をするなら、即効で仕上げて、あとで変更する人たち余裕を与えたともいえる。
ある設計が変更に耐えられる確率を定量的にいえるなら設計に時間与えてもいいけど、
いえる人っていないでしょ。
設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。
> ある設計が変更に耐えられる確率を定量的にいえるなら
結合度とか凝集度がそれにあたるな。
> 設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。
設計が甘かったために、ひとつのバグ修正が２つのバグを産むという例のほうが
よっぽど多いけどなｗ
OOPってアジャイルな開発には向いてないの？
どんな開発モデルでも、後工程に行けば行くほど修正コストは飛躍的に増大する。
> 設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。
そのような経験があるからといって、設計に時間を与えなくとも良いということには
ならないのはわかるよな。
設計とか分析とか工程というのは、
その次の工程を行うためにやる。
つまり、その次の工程の内容を理解していなければ、
使えないものが出来るのは当たり前の話。
たとえば使えない設計書。これができてしまうその原因は
その次の工程を全く知らないからだ。
自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。
基本的な素養がね。ないとダメなんだよね。
ゲームでの企画はあくまで雑用とアイデア出しで設計するのはプログラマー。
２年程度なら平均的なプログラマぐらいにはなれる
平均的なプログラマは
プログラミングをするべきだ。
クソな仕様書をつき返して問題箇所を指摘したり直させたりできるレベル？
レーザープリンタで感圧紙の複写印刷が出来ますと客先で宣言されたことがある。
>高慢と偏見（1）隣は何をする人ぞ
これ見ると反ＯＯ派をＫＯしたとＯＯ派は思うんだろな。
もうそろそろそんなレベルを超えろよ。
ＯＯでもまだシンドイだろ？
なにそれこわい
…プリンタのハード設計をしてるワケじゃないんだよな？
まあそれでもォィォィと思うが
プログラミング出来る出来ないは関係ないなｗ
そいつが根本的に馬鹿なだけだ
データには大きくわけて社員と役員という二つのタイプがあって、社員のメンバ変数は役員ならば全て持っている場合、
アクセッサー含めて役員の方にも同じメンバ変数をコピーするのは保守性下がるからよくないと思ったから継承させたんよ。
class 社員 {
int 社員番号;
String 氏名;
String 年齢;
int 給与額;
}
class 役員 extends 社員 {
String 役職;
int 役員賞与額;
}
こんな風に。
んで、Object型に格納して、社員と役員で手続きを共通化させたら、簡素で分かりやすいコードになるんじゃと期待していたんだけど、
実際は、Object型インスタンス.役職とかObject型インスタンス.役員賞与額とかいうのは、遅延バインディングにあたり、静的型づけできないから駄目だったｗ
じゃあ継承させずに同じメンバ変数を異なるクラスにコピーさせていかないといけないんか、とがっかりしたわ
何のための継承だったんかと
Object型に格納するのがダメなだけじゃんｗ
初心者だと自覚しているのなら、
自分が何か見落としているだけだと
最初に考えような。
何かおかしいなら、それは自分が悪いと考える。
99％間違いないから。
どこの田舎ライブラリだよ