- 1 名前：デフォルトの名無しさん [2013/11/11(月) 11:17:03.61 ]
- 遅いんですよ、オブジェクト指向は。
- 71 名前：70 mailto:sage [2014/01/11(土) 18:12:36.87 ]
- >>68
設計をオブジェクト指向という一つの「枠組み」でとらえることができる、こと
ここで設計とは、従来の手続き型設計手法における：
機能設計/構造設計/詳細設計(コード設計)
に対応する
オブジェクト指向は本格的な開発プロジェクトにとって
有益であるのはもちろんのこと、個人のプログラミングにも役に立つ
たとえば、何か作りたいモノ(=主題、要求仕様)があったと仮定すると、
それを分析して「適切なオブジェクト指向モデルを設計」できれば、
そのモデルを直接的にオブジェクト指向言語のコード設計に反映できる
これにより、モノ作り(いわゆるソフトウェア開発)の効率化が図れる
ここで注意すべきは、「モノ(=主題、要求仕様)」は現実世界に存在する概念であり、
「多くの概念モデルは、オブジェクト指向モデルでは表現できない」点である
オブジェクト指向の教科書で取り上げられるような単純なモノであれば、
その概念モデルをオブジェクト指向モデルで表現できることは多いが、
現実世界にある大半の複雑なシステムには当てはまらない
これがオブジェクト指向分析/設計(OOA/OOD)の本質的な難しさである
そして、オブジェクト指向プログラミング(OOP)を理解しただけで
オブジェクト指向(OO)のすべてを分かった気になっていた平澤氏(>>55)が、
現実世界の開発現場でプロジェクトに混乱を巻き散らしていた張本人であったのは
言うまでもないことだ
- 72 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 18:28:31.89 ]
- >>68
有益だけど面倒だったことが誰でも簡単に出来るようになった
- 73 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 18:28:53.27 ]
- >>69
レストン！
>>71
失礼、ちょっと大げさになりすぎた。
もっと限定して、本当に聞きたかったことはこう。
非OOPと比較してOOPのメリットは？
俺は、結局んところモジュール性の上乗せだと思う。
ただしこれは想像であって、クラスという単位で名前つけたり、
インスタンスを複数の抽象レベルで扱えたりすることが、
非OOPで出来るのかどうか不勉強で知らない、
仮に出来ないとしたら、出来るOOPのほうがその分オイシイ、の発想。
- 74 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 18:30:59.87 ]
- >>72
レストン！
まぁよく聞く「CでもOOP出来る！」発言はじゃあオマエがそれをやってみろ、
実用としてそれでラクをしてみろ、という気分になっちゃうね。
まあこういうと単にOOPLへの感謝にすぎないが。
- 75 名前：70 mailto:sage [2014/01/11(土) 18:54:24.49 ]
- >>73
>クラスという単位で名前つけたり、
>インスタンスを複数の抽象レベルで扱えたりすることが、
>非OOPで出来るのかどうか
クラス(class)とは「型(type)」いわゆるデータ型であり、
インスタンス(instance)とは「値(value)」である、と想定してみよう
もしこれが正しければ、型と値を表現できる非OOP言語であっても、
「型という単位で名前つけたり、値を複数の抽象レベルで扱えたり」
することはできる、と言える
クラスと(一般の)型との違いは、クラスが各クラス間に「継承」という
階層関係を持てるのに対して、(一般の)型は階層関係を持てない点にある
ただし、ここまではC言語によるOOP技法のように非OOPでも実現できる
そして非OOP言語の世界には「型とは値である」という発想がある
つまりデータ型を(値として)実行時に定義したり生成できるパラダイムであるが、
実験的な言語はいくつか提案されてきたけれど、どれ一つとして普及には成功しなかった
この「型とは値である」という発想をOOPの世界で言い換えたものが
「リフレクション(メタプログラミング)」になる
そしてリフレクションは Ruby on Rails の成功等で実用化が一般にも知られるようになり、
現実のOO設計技法として普及に成功した
つまり「OOPで出来て非OOPでは出来ない」のはリフレクションである
- 76 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 19:08:45.37 ]
- コンピュータの歴史を辿れば分かりやすいかな。といっても実際の歴史は知らんので想像ｗ
最初は機械語レベルで十分だったけど、規模が大きくなってくるとやってられなくなるので、
ある程度の一連の機械語をまとめて１つの抽象的な命令に置き換える高級言語が生まれた。
そしてさらに規模が大きくなってくると長大なソースコードにやってられなくなったので、
一連のコードを抽象化して擬似的に１つの命令化、すなわち関数化する、構造化言語が生まれた。
そしてさらに規模が大きくなって大量の関数にやってられなくなったので、
関連の強い関数群とか、データとその処理をグループ化して１つの単位にするオブジェクト指向言語生まれた。
そしてさらに規模が大きくなると？？？？
サービス指向とかかな？？
- 77 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 19:08:46.23 ]
- まさかそんなところに着地する話とは思いもよらなかったｗ
結論については消化できてないのでひとまず言及は避けておく。
> ここまではC言語によるOOP技法のように非OOPでも実現できる
ここらに一回、慎重に線引きをしてみたいもんだが、
非OOPLでOOPできる場合、そのメリットはOOPのものなのか？
それとも、非OOPLのものなのか？
手柄はOOPにあるのか非OOPLにあるのか。
この領域に入った議論はいっつもモヤッとしてるのを感じる。
非OOPLで、非OOPをして、それが、
OOPのメリットに迫るか上回るかの例をいつも見たいと思っている。
- 78 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 19:16:33.98 ]
- OOP言語で作っても実行されるのは機械語だよ。だから機械語でもOOPは出来るｗ
構造化言語は、構造化を簡単に出来るようにした
オブジェクト指向言語は、オブジェクト指向を簡単に出来るようにした
だけ。
- 79 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 19:17:57.98 ]
- >>78
その考えのほうがスパッと行ってるな。
どうも俺余計なこと考えちゃってたみたい。
- 80 名前：デフォルトの名無しさん mailto:sage [2014/01/11(土) 21:48:39.30 ]
- オブジェクト指向って１つ１つのオブジェクトの作成でその力を使いきっていて、
オブジェクトをどのようにつなげていくかに関しては無能っぷりを撒き散らしている。
デザインパターンのグダグダっぷりを見ていると痛々しい。
- 81 名前：デフォルトの名無しさん mailto:sage [2014/01/12(日) 04:06:08.19 ]
- >>80
忘れがちではあるけど、実はデザインパターンを構造型で作るとオブジェクト指向より更に胡乱でメンテナンスの難しい糞コードが生まれる。
グダグダに見えてあれが一番便利でコンパクトだったりするんだよ。
それに、一つの機能の使い方だけで性格の全く違う有用なものが最低23個も生まれるって考えると、
つなげ方には自由度と一貫性が両立されてるわけで、むしろ美しいとは思わないか？ 俺は思わないけど。
- 82 名前：デフォルトの名無しさん [2014/01/12(日) 19:12:18.26 ]
- >>71 面白い書き込みをありがとう。オブジェクト指向はわからんなぁと思っ
ていたが、経験的に身に着けられるような、テクニックやハッキング技術と
は違うということがわかった。
書きぶりを見るに、オブジェクト指向「設計」はきちんとした
計算機科学専攻の大学院レベルのトレーニングを経ないと習得できないもの
なのだろう。そのような教育を修めた技術者が基底クラスの設計とコーディング
ルールを決めたう上で、開発をするのがあるべき姿なのだろう。
- 83 名前：デフォルトの名無しさん mailto:sage [2014/01/12(日) 21:19:56.49 ]
- なるほど。こういう人が設計するべきだね。
el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
- 84 名前：デフォルトの名無しさん mailto:sage [2014/01/12(日) 22:11:16.30 ]
- 正直業務アプリのフレームワークなんて決まりきっててすでに用意されてるしな
日付だの画面部品だのは基本的なものはもう標準ライブラリに入ってるし
パンピーがオブジェクト指向でなに設計するん？
- 85 名前：デフォルトの名無しさん mailto:sage [2014/01/12(日) 23:28:17.13 ]
- 標準ライブラリやフレームワークで足りないものを実装するとき。
基本的な関数はともかく、画面部品はだいたい使えるが、
ちょっとだけ機能をつけ加えたいってことはよくある。
その時、だいたい部品は拡張可能になっているが、
それを拡張するときはオブジェクト指向の知識が必要になる。
- 86 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 00:38:58.51 ]
- それっぽい言葉だけは出揃っているんだけど実装がことごとくダサダサなのが地球のオブジェクト指向☆
- 87 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 00:46:14.36 ]
- >>84
パンピーならゲームじゃね？
ゲームはオブジェクト指向と親和性高いからオブジェクト指向の独壇場みたいなところあるし。
- 88 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 02:50:15.91 ]
- >>85
単に抽象クラスにコード実装するだけだろそれ
その程度ならVBでポトペタしたボタンをダブルクリックするのと何もかわらん
本当に何かFWが提供している以上のことをやろうと思うとどのような思想で
抽象化されているかまで理解しなければならないのがooの最大クラスの欠点
- 89 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 03:08:57.42 ]
- 抽象クラスって言ってる時点で
オブジェクト指向の知識が必要になってるじゃねーかｗ
- 90 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 11:48:20.38 ]
- C++使うから、訳が分からなくなるんだよ
VBScriptでオブジェクト指向してみると分かりやすくなるさ
- 91 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 14:48:48.64 ]
- 言語にこだわるのは無能
本質は変わらない
- 92 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 14:50:56.00 ]
- じゃあすべてマシン語で書け。
- 93 名前：デフォルトの名無しさん [2014/01/13(月) 15:29:04.85 ]
- あれだろ仕様書の日本語やカタカナ英語にこだわっている人。
さもなくば肩書きとか名誉とか貯金とか、
結局人間は無意識に何かに拘ってるんだよ。
- 94 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 16:38:59.80 ]
- >>91
PrologとHaskellとRuby勉強した後に同じ事を言えればいいが
- 95 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 17:53:20.40 ]
- Rubyなんかパチもんは外して代わりにSmalltalkとLISPを、あとAPLを入れたいね
- 96 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 21:55:09.22 ]
- 「言語なんて全部一緒」って言ってる人
関数型言語を意図的に無視しているから嫌い
- 97 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 22:00:25.74 ]
- じゃあ、言語なんて二種類しかないでいい？
っていうか、今は関数型言語の機能が
オブジェクト指向な言語に取り入れられて来ているからねぇ。
オブジェクト指向言語が純粋ではない関数型言語に近くなってるよ。
だから全部一緒っていうのもあながち間違いじゃない。
- 98 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 22:16:10.65 ]
- いやー、全然近くなってないよ
- 99 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 22:20:58.17 ]
- 近いよ。もう関数型言語特有のものっていうのは
少なくなってるでしょ？
ここに関数型言語特有のものを書いてみ
ほんの数個出るだろうけど、それ以外は
もう関数型言語じゃなくても良くなってる。
- 100 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 22:41:41.90 ]
- カレーか
- 101 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 23:11:06.46 ]
- つりだろ。
- 102 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 23:17:36.90 ]
- 最終は機械語
- 103 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 23:20:52.45 ]
- 機械語といっても、必ずしも手続き型とは限らない
- 104 名前：デフォルトの名無しさん mailto:sage [2014/01/13(月) 23:42:14.64 ]
- >>100
カリー化ね
yuroyoro.hatenablog.com/entry/2012/08/10/232443
> Rubyでは、1.9からProc#curryがサポートされてカリー化できるようになった。
言語構文でネイティブにサポートされてないってだけで
カリー化をする関数は作れる。
- 105 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 00:02:07.60 ]
- >>102
ネットの機械語はjavascript
- 106 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 01:31:22.59 ]
- 言語なんて全部一緒なんじゃなく、全部載せの言語があるだけじゃないか？
逆だと思う。
- 107 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 02:11:13.68 ]
- ノコギリなんてみんな一緒って言うのとおなじくらいナンセンス。
関数型と手続き型では日本の引きノコ、海外の押しノコくらいの違いがあり、
じゃあ両方いっぺんにてんで歯の左右に角度の違う歯を配置したりするノコもある。
- 108 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 02:12:04.12 ]
- >>99
再代入禁止とか
- 109 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 02:23:41.46 ]
- 鋸の由来ってJSON（ジェイソン）に対する言葉遊びかな?
- 110 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 02:27:55.97 ]
- >>96
（俺らがいくら関数型を使ったところで、プログラミングセンスが開花するわけじゃないんだから）
言語なんて、どれも一緒
- 111 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 03:54:30.40 ]
- 楽器に例えると？
JavaとJavaScriptは
アコギとエレキくらい違う。
SQLとRubyは
ベースとエレキくらい違う。
- 112 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 07:40:50.30 ]
- 代数的データ型とパターンマッチがOOPLにも欲しい
これ有る無しでプログラミングスタイルから変わってくる
- 113 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 16:02:42.70 ]
- >>109
そーだよ
- 114 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 20:45:23.41 ]
- 会社の先輩が全く理解してくれない。
その人が作るプログラムはうまく動くには動くんだけど、いろんなスタイルが混在してて、
なるべくきれいなオブジェクト指向的設計にした方がいいですよ、といって説明してるんだけど。
「おまえの言うことくらい全部知ってる。だが全く実証的じゃない」って。
オブジェクト指向の利点を「実証的に」説明しろって言われてもなあ。
- 115 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 21:04:37.18 ]
- >>114
別に無理してオブジェクト指向することないよ
- 116 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 21:11:50.60 ]
- インタフェースを最初から決めとかないと後で困るだろ
- 117 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 21:19:08.48 ]
- >>115,116
だけど全然認めてくれないってのもくやしいよ？
俺の説明が悪いのかと思って、いろんな本やサイトの解説漁ってメリットを語っても
「そんなハウツーレベルのメリットを追求してるからダメなんだ！」と一喝。。。
頭脳じゃ全くかなわない。理学博士だし・・・
- 118 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 21:38:37.45 ]
- どんなに仕事を丁寧に丁寧にやったとしても、
１個問題が起きればその苦労が報われないことだってあるんだし、
理想ばっか追い求めないで、そこそこの結果を求めた方がいいと俺は思う。
てか、オブジェクト指向って何だ？
拡張性を残して再利用できるように、機能を最小にしてスマートにすること？
そのまま再利用できるように、機能を最大持たせること？
- 119 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 21:48:45.60 ]
- >>118
ダーティーなプログラムを、周囲に何の影響も与えることなく利用できるようにすること
- 120 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 21:50:33.91 ]
- やっぱり追求すべきは、まずはモジュール性だよ。
直行性あって再利用されがちな単位をみつけだして、
インタフェースを小さくよく考えて決めて、実装隠す。
モジュール性がより備わってるとき、それはやっぱり簡潔で柔軟だと思う。
OOPか否かに拘り続けるのもまたおかしい。
- 121 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 22:03:13.31 ]
- ファクトリー的なことにOOPを用いようとすると、
色んな処理が重なるの部品を受け取って、
組み上げる時にスコープが利かなかったりする。
ここらへんの想像が難しい
- 122 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 22:03:40.99 ]
- >>118
> てか、オブジェクト指向って何だ？
問題の分割のしかたの一形態です。
データ指向らしい分割のしかた
手続き指向らしい分割のしかた
オブジェクト指向らしい分割のしかた
信じる信じないはあなたの自由です
- 123 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 22:19:12.66 ]
- たとえば構造化プログラミングの段階ひとつとっても、
うまいひとが書いたのと下手な人が書いたのって結構差がある。
そのことについて語られない代わりに、OOPのメリットとやらが先行して語られてる気がする。
- 124 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 22:29:46.62 ]
- 原理主義ってうざいし根拠ないよね。
オブジェクト指向の度合いがより純粋であれば、イコールより良いものなんだ・・・って、
誰かの言葉じゃないけど、実証的に確かめられてるモノんだろうか？
- 125 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 22:32:08.25 ]
- >>122
もし分割の仕方で〜指向っていうのが決まるんだったら、複数の分割のやり方が混在していると良くないってことになるよね？
- 126 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 23:07:55.64 ]
- 周りが理解しやすいようにOOPやGOFのデザパタを取り入れるんじゃないのか
- 127 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 23:12:24.34 ]
- >>125
「良くない」
ずいぶん抽象的な捉え方ですね。
もっと実証的に言ってください！
- 128 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 23:26:21.24 ]
- >>125
ならないよ。
データ指向30%
手続き指向30%
オブジェクト指向30%
その他10%
ってなるだけさ。
それでうまくいくことは十分ある。
- 129 名前：デフォルトの名無しさん mailto:sage [2014/01/15(水) 23:37:40.58 ]
- オブジェクト指向でパッケージされたデータ構造を手続き型で処理するなんて普通にある話。
- 130 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 01:42:08.82 ]
- >>114
要はその人に「自分の知ってる文法だけで書いてください」って言ってるだけだろ？
それは単なる甘え。
その人は純粋なオブジェクト指向や他のパラダイムを一通り勉強して、その上で一番生産性の高い方法を選んでるだけ。
多分、その人は純粋なオブジェクト指向で書こうと思えば書けるんじゃないのか？
それをあえて使わない理由、メリットを聞いてみるべきだと思うよ。
そのメリットに納得したら、お前の方が先輩のやり方を学べばいい。
- 131 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 02:38:22.63 ]
- 粗結合を実現しようと思ったら副作用は極力避けるべき
なのに、オブジェクト指向は副作用を避ける仕組みは提供しないっていうか
むしろ副作用推奨だからウンコ
- 132 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 02:54:56.23 ]
- 小クラス主義、大クラス主義とかいうヤツだっけ？
小クラス主義が書いたコードは何かの信念を貫き過ぎてると思う
- 133 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 03:09:25.89 ]
- 疎結合なら知っているけど粗結合ってなんだろう。
- 134 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 03:27:30.69 ]
- >>131
そのためのカプセル化だろ。
関数単位ではなくオブジェクト単位での副作用禁止を推奨してるだけ。根っこは同じ。
ダダ漏れの副作用はオブジェクト指向でも推奨されてないよ。
- 135 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 03:49:30.24 ]
- オブジェクト単位での副作用禁止ってなんだよアホか？
オブジェクトの状態を一切変化させないのか？
- 136 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 04:06:32.24 ]
- >>135
オブジェクト内の変数とオブジェクト外の変数を別物として扱ってるだけだよ。そのためのアクセス修飾子。
オブジェクト指向において適切にカプセル化がなされていれば、コンストラクタに同じものを与えて、同じ回数、同じ引数で呼び出した時に返ってくる値が変わらないことは保証されてるだろ？
最終的に参照透過性の理念の要求は満たすことになる。
- 137 名前：デフォルトの名無しさん [2014/01/16(木) 04:18:31.57 ]
- ゴミｗｗｗｗｗｗｗｗｗｗｗ
- 138 名前：デフォルトの名無しさん mailto:sage [2014/01/16(木) 04:23:01.20 ]
- どの言語のオブジェクト指向なんだろうか、少なくともjavaやC++のオブジェクト指向で副作用とか考慮されてないし
考えるのはキチガイ。
|
 |
