05/07/26 04:08:53
教えたがり屋の貴様らに今一度チャンスをやる。
俺に教えろ。
前スレ ｽﾚﾘﾝｸ(prog板)
2:仕様書無しさん
05/07/26 04:12:10
2げと
3:仕様書無しさん
05/07/26 07:56:01
>>1
乙
4:仕様書無しさん
05/07/26 11:08:42
また建てたのか
5:仕様書無しさん
05/07/26 13:19:42
クソスレ２週目おめ。
6:仕様書無しさん
05/07/26 14:15:49
= 絶対に負けられない戦いが、そこにはある - VIP =
悪質手法で金を巻き上げる「ワンクリ詐欺」
VS
その悪行を全力で阻止する「ワンクリメン」
さあ、勇者よ、報道ステーションに向けて･･･
ワンクリック詐欺サイトを撲 滅 せ よ！！！！
URLﾘﾝｸ(sagamioriginal.yh.land.to)
☆ワンクリ業者を思う存分煽ってみよう！！ｗｗｗｗ
☆メールボム撃ち放題！！憂さ晴らしにもおｋ！！！
☆業者からの返信メールｷﾞｶﾞﾜﾛｽｗｗお返しメールﾃﾗﾜﾛｽｗｗｗ
☆VIPPER、いや２ちゃんねるの強さを見せ付けろ！！
※金土日夜９～１２時に田代祭り開催中 友達も呼んで盛り上がれｗｗｗｗｗｗｗｗ
（注：祭り中はｽﾚﾘﾝｸ(kova板)へ
なければURLﾘﾝｸ(tmp5.2ch.net)に行けばいいとおもうよ。
URLﾘﾝｸ(ocbyebye.tripod.com) ← 四連田代砲でワンクリ詐欺サイト砲撃中
マシンスペック･回線に自信があれば踏んでみ？
【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】
昼間はおもに業者から口座聞き出し、口座凍結、各種通報機関に通報をします。
ご協力お願いしますm(_ _)m
7:仕様書無しさん
05/07/26 21:04:50
オブジェクト指向って要するになに？
8:仕様書無しさん
05/07/26 21:31:26
仕事が・・・ほしい（ウェブアプリ-ケーション）
URLﾘﾝｸ(yum.hippy.jp)
9:仕様書無しさん
05/07/26 21:33:38
ていうか何が嬉しいの？
10:仕様書無しさん
05/07/26 21:36:03
仕事が・・・ほしい（ウェブアプリ-ケーション）
URLﾘﾝｸ(yum.hippy.jp)
11:仕様書無しさん
05/07/26 22:21:52
俺の認識では、
C言語 printf(); //ヘッダの内容をインクルードすることで使用
JAVA System.out.print(); //Systemクラスのout変数が参照するprintメソッドを指定
ｺﾚﾀﾞ!!!
12:仕様書無しさん
05/07/26 23:56:39
俺JAVAよく知らないけどoutは変数なのか？
13:仕様書無しさん
05/07/27 01:45:30
>>1
教えて君には教えてやらないよ。
努力もせずチャンスをやるなんて偉そうなこと言ってる奴には
苦労して得たアーキテクチャパターンのノウハウを教えてやらないよ。
14:仕様書無しさん
05/07/27 01:46:55
>>11-12
outは変数ともいえるが
厳密は解釈では
Systemクラスのpublic staticなPrintStream型のフィールド。
15:仕様書無しさん
05/07/27 02:09:06
変数という表現は正確ではないが
意味合い的には正しいよ
静的に標準出力ストリームオブジェクトの参照を保持している変数。
Systemクラスの静的な変数であるという意味では定数という言い方もできるし、
printメソッドから見ればオブジェクトであるとも言える。
難しそうに説明してみるテスト。
16:仕様書無しさん
05/07/27 02:12:04
>>11
> 俺の認識では、
>
> C言語 printf(); //ヘッダの内容をインクルードすることで使用
> JAVA System.out.print(); //Systemクラスのout変数が参照するprintメソッドを指定
本来ならば
JavaのCのincludeのように以下のようなimport宣言をしないとSystemクラスってなんだ？
というコンパイルエラーが出るはずだが、
import java.lang.System;
Javaではすべてのクラスは暗黙のうちにデフォルトでimport java.lang.*;が宣言されており
これを省略することができる。なお、*はワイルドカードであり、java.langパッケージ内にあるすべてのクラスをimport
するという意味である。ただし、注意しなければならないことは、JavaのimportはCのincludeとは
違うものだという意識を持つ必要があることだ。import宣言は比較的自由に扱えるもののCのinclude宣言は
一度宣言すると、それを呼び出す関数があるコードにもまったく同じinclude宣言をすると重複になってしまう。
importでは違う。そのクラスで必要なものはとにかくすべてimportしなければならないのだ。
それからJavaではimport宣言をするときに上記に示したようなワイルドカード*を使用することは
おすすめしない。なぜなら、*を使われては、どのクラスを呼び出しているのか即座に見分けにくい問題があることと、
クラス名は同じだがパッケージ名がことなるクラス(たとえば、java.util.Date, java.sql.Date)をimportした
とき*を使うと異なるパッケージだが中に全く同じ名前のクラスが使われているとコンパイラは、どっち
のクラスを使えばよいかわからずコンパイルエラーをはき出す。
Javaでは継承を宣言していないすべてのくらすにおいて
暗黙のうちに java.lang.Objectクラスを継承している。
たとえば 以下のようなクラスを宣言したとき
class Test {}
と書くが、
これは暗黙のうちに
class Test extends Object {}
のようにObjectクラスを継承しているのである。
17:仕様書無しさん
05/07/27 02:26:19
Systemクラスのoutはフィールドというが
C++でいうところのメンバ変数に相当する。UMLでいうところの属性に相当するともいえる。
ちなみにJavaでいうところのメソッドとはC++でいうところのメンバ関数に相当する。
UMLでいうところの操作に相当するともいえる。
ちなみに、Cにはあったグローバル変数、グローバル関数はJavaでは当然の如く
汚いものとして排除された。
オブジェクト指向に必要ないものはJavaではほとんど徹底的に排除されている。
18:仕様書無しさん
05/07/27 07:56:00
>>17
グローバル変数が無い場合
何かのクラスは必ず何かに属するという上下関係が出来るんだよね？
オブジェクト指向において対等にメッセージを交換し合うということはないのかな？
19:仕様書無しさん
05/07/27 09:07:33
>17
public static 変数は、グローバル変数じゃないの？
static メソッドはCの関数と同じじゃないの？
20:仕様書無しさん
05/07/27 10:29:31
オブジェクト指向がわからないC厨哀れｗ
21:仕様書無しさん
05/07/27 11:33:17
単に言語のイディオムをOOと表現するほうが憐れｗ
22:仕様書無しさん
05/07/27 11:34:35
>>19
早い話、そのとおりです。
23:仕様書無しさん
05/07/27 18:51:26
オブジェクト指向がわからないPGなんて食っていけないね
24:仕様書無しさん
05/07/27 22:17:40
オブジェクト指向とは、「プログラムよくわかんないから、現実世界の例を使って単純に考えましょ」
っていう感じの 『考え方の指針』 で、それを使ってプログラミングするとオブジェクト指向プログラミングになる
ついでに言うと、カプセル化とか情報隠蔽とか再利用性とかは、『現実世界に既に存在していた性質』 を
プログラムの世界に移植しただけなので、オブジェクト指向の機能などではないし、少なくとも機能と呼んではいけない
オブジェクト指向は、あくまで 『考え方の指針』 を提示しただけ
んで、初心者が戸惑うのは、それにくっついた数多の付属品、というわけだ
25:仕様書無しさん
05/07/28 10:16:49
>24
逆だろ、「現実世界にないから説明しにくい」んだろ。
だから動物の話や、ドラ○もん製造機の話になって、訳分からなくなるんだろ。
26:仕様書無しさん
05/07/28 13:49:10
オブジェクト指向がわからないPGなんて食っていけないね
27:仕様書無しさん
05/07/28 14:57:26
ああ五月蝿いな
28:仕様書無しさん
05/07/28 18:12:33
まだこのスレ続いてたのか
延々ループスレ認定
29:仕様書無しさん
05/07/28 23:24:46
じゃ、こういうのはどうだ？
オブジェクト指向をマスターした人が、自分のマスターした経緯を書くってのは。
これなら、参考になるんじゃね？
30:仕様書無しさん
05/07/28 23:45:59
オブジェクト指向はメタファーだ！
31:仕様書無しさん
05/07/29 01:30:36
>>29
ＵＭＬで設計したらわかるよ。
ああ、明らかに構造化設計とは違うんだなって。
32:1
05/07/29 20:04:23
>>13
お前が教えてくれるまで、俺は帰らない
33:仕様書無しさん
05/07/29 23:18:02
オブジェクト指向がわからないPGなんて食っていけないね
34:仕様書無しさん
05/07/30 01:15:23
大丈夫、すぐに慣れるさ。
35:仕様書無しさん
05/07/30 08:57:44
オブジェクト指向は他人から教えてもらうものではなく
自分で習得するものだと思っているのだが。
36:仕様書無しさん
05/07/30 09:31:58
C++の機能一通り使って中規模のシステム組んでみたらわかるんじゃね
それでも素直に頭に入ってこないのは頭が固いんだよ
37:仕様書無しさん
05/07/30 09:33:02
オブジェクト指向がわからないPGなんて食っていけないね
38:仕様書無しさん
05/07/30 12:01:45
>31
UMLってただの落書きにしか見えないんだけど、何の図を言ってる？
クラス図？シーケンス図？
39:仕様書無しさん
05/07/30 12:06:34
>36
昔、Javaで中規模のシステム組んでるの見たことあるんだけど、
仕様変更の連続で無茶苦茶になって行くのを見て、「これはオブジェクト指向じゃないな」
ってのは分かったんだけど。
40:仕様書無しさん
05/07/30 12:31:37
>>39
それは開発プロセスの問題で、開発方法論の問題ではない希ガス
41:1
05/07/30 20:10:36
ハガレンの映画見に行きたいんだけど
42:仕様書無しさん
05/07/30 21:04:55
いけばぁ～？
43:仕様書無しさん
05/07/31 23:53:05
おれはsmalltalkで遊んでオブジェクト指向プログラミングを初めて理解したな。
44:仕様書無しさん
05/08/01 06:07:12
それはよかったですね。
45:仕様書無しさん
05/08/01 11:18:52
smalltinkoでしょ
46:仕様書無しさん
05/08/01 11:45:49
俺はJavaで、構造化プログラミングで組んだが、すごいプログラムになったな。
throw使わないために先にifで判定したり、細かくtryで囲ったり。
クラスの分け方が分からなかったから、メソッドを処理の種類毎にクラスに入れてたから、
仕様変更のたびにいくつものクラスに修正が入っていたな。
数回の仕様変更で破綻して作り直したが。
47:バブル期就職
05/08/01 12:05:16
>>46
いいお勉強ができたみたいで
おれはこれから独習だよ
48:仕様書無しさん
05/08/01 16:03:32
＞throw使わないために先にifで判定したり、細かくtryで囲ったり。
＞クラスの分け方が分からなかったから、メソッドを処理の種類毎にクラスに入れてた
ここら辺が構造化プログラミングと関係ないやんっつーのがツッコミどころですか？
49:仕様書無しさん
05/08/01 20:33:37
何このオナニースレ
50:仕様書無しさん
05/08/03 09:49:10
>48
ジャンプしないのと、機能で分割するのが構造化だろ。
オブジェクト言う前に構造化を勉強して来い。ボケ
51:仕様書無しさん
05/08/03 11:57:51
>>50
この子はコーダ止まりで会社辞めて警備員のバイトってコースだね
52:仕様書無しさん
05/08/03 12:41:18
>>50
順次・反復・分岐の構造化プログラミングと、データやデータの流れに着目した
オブジェクト指向以前の設計手法である構造化分析/設計技法がごっちゃに
なってないか？
53:仕様書無しさん
05/08/03 22:01:09
>51
俺の将来の心配する前に、自分の将来を心配しろや、ボケ！！
>52
「順次・反復・分岐の構造化プログラミング」って何だ？
確かに俺の言ってるのは、
「オブジェクト指向以前の設計手法である構造化分析/設計技法」だが、
それが構造化プログラミングだろう。
54:仕様書無しさん
05/08/03 22:08:34
>>53
違うと思う。多分うちの大学では前者を教えた。
55:仕様書無しさん
05/08/04 08:31:25
オブジェクト指向がわからないPGなんて食っていけないね
56:仕様書無しさん
05/08/04 09:50:03
>54
前者の、「順次・反復・分岐の構造化プログラミング」って意味がわからん。
順次、反復、分岐を使うのが構造化プログラミングだって言いたいのか？
それはプログラム言語の3大要素だ。その論理だとプログラムは全部構造化だぞ。
つーか、学校でそんな間違いはしないだろうから、お前の理解が間違ってるんだよ。
57:仕様書無しさん
05/08/04 13:48:48
結局構造化さえ誰も理解できて無いってことね。
58:仕様書無しさん
05/08/04 14:50:20
理解してなくてもプログラムが動くなら良いじゃんｗ
59:仕様書無しさん
05/08/04 19:10:33
>>58
なまじ動いてデータ壊されたりするぐらいなら
動かないほうがまだいいと思う。心底そう思う。
60:仕様書無しさん
05/08/04 23:05:14
>58
仕様変更繰り返しても動くならいいよ。
最初に作って変更無しなら、はっきりいって適当に作っても動くんだよ。
61:仕様書無しさん
05/08/04 23:12:14
>57
俺は理解出来ているし、このスレの半分ぐらいの奴も理解出来てるよ。
そのうちのほとんどが、オブジェクト指向も理解しているように思える。
怪しいのは構造化を知らずにオブジェクト指向語る奴だな。
62:仕様書無しさん
05/08/04 23:32:16
何度も使用する処理をサブルーチンにするんだよ。
一度しか使わない処理をサブルーチンにすることは無いだろ。
と言う人が最近でもいる。
63:仕様書無しさん
05/08/05 08:24:57
まじで俺はわかんなくなってきたぞw
構造化ってなんだ？？
64:仕様書無しさん
05/08/05 10:14:33
構造化。それはあなたの青春の思い出。
65:54
05/08/05 11:44:15
>>56
＞順次、反復、分岐を使うのが構造化プログラミングだって言いたいのか
クラスを定義するのがオブジェクト指向プログラミングだって言いたいのか？
そうじゃないだろう。
66:仕様書無しさん
05/08/05 12:09:11
>65
要素と手法は違うって言いたいのか？
それは俺の言っている事だろう。だからその要素を使ってどうやって組むのかが問題なんだろう。
構造化の手法を説明してみろや。俺は出来るぞ。
67:仕様書無しさん
05/08/05 17:51:43
無知なスレが続くのでマジレス。
構造化＝手続き抽象
クラスベースＯＯＰ＝データ抽象＋手続き抽象
抽象＝．．．
という感じで言葉を正しく理解しる！
68:仕様書無しさん
05/08/05 18:56:27
オブジェクト指向がわからないPGなんて食っていけないね
69:54
05/08/05 20:19:13
>>66
悪い。なんとなく混乱している理由がわかった。
「順次・反復・分岐の構造化プログラミング」の意味を脳内解釈してましたですよ orz
70:仕様書無しさん
05/08/05 22:49:17
>67
言いたいことは分かるが、明らかに説明不足だ。
それに構造化すると結果的に処理の抽象化（分かりにくく言うな、ただの共通関数だろう）が進むが、
それ＝構造化ではない。
思想的な話はいくら言っても分からない人には分からないんで、実装的な観点で言おう。
1.「関数の入り口と出口はそれぞれ1つとする」
つまりgotoの禁止と、途中returnの禁止。
2.「グローバル変数を使わない」
グローバル変数使用の禁止。（中断処理のフラグを除く）
3.「機能毎に関数を作成する」
変数のスコープ（有効範囲）に着目し、他のブロックと最も干渉の少ない単位で機能毎に関数化する。
1関数どのぐらいにするかは意見の分かれる所だが、機能毎が判断出来ない初心者は1関数50行を
目安にするといい。
以上だ。
71:仕様書無しさん
05/08/05 23:10:27
50行？・・・長いなぁ
72:最凶VB厨房
05/08/05 23:27:03
最大50行ってことじゃねぇか？
俺には50行すらも完全に把握する脳みそがねぇからなぁ・・・。
困ったもんだ。
73:仕様書無しさん
05/08/05 23:30:37
>>71
だな。漏れの目安は30行弱ってとこかな。
74:仕様書無しさん
05/08/05 23:33:06
コメント入れまくれば何とか５０行くらいは……やっぱ無理か
75:最凶VB厨房
05/08/06 00:06:14
>>73
素晴らしい目安だ。
76:仕様書無しさん
05/08/06 01:56:06
構造化プログラミング
URLﾘﾝｸ(ja.wikipedia.org)
オブジェクト指向プログラミング
URLﾘﾝｸ(ja.wikipedia.org)
構造化プログラミングは
徹底するには訓練が必要であるものの
現在では常識的すぎる（であるべき）内容な気がする。
構造化プログラミングとオブジェクト指向プログラミングは
歴史的に連続していて、構造化プログラミングで苦労していれば
むしろ受け入れられるはず。
俺の話はいつでも長い。
77:仕様書無しさん
05/08/06 11:51:24
>72
すまんその通りだ、最大50行って事だ。
フォロー感謝する。
78:仕様書無しさん
05/08/06 12:01:25
自分はいきなりオブジェクト指向から入った若い人間で構造化なんたらってのが
よく分からんのだがこういう奴のことか？
URLﾘﾝｸ(www.vest.co.jp)
79:仕様書無しさん
05/08/06 12:20:01
※日中友好の同志を募集しています※
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
現在の日中間は最悪な局面を迎えています。
中国サイトからのサイバーテロが相次ぎ、日本のサイトは危機を迎えています。
こんな状況下で我々は日々民間日中交流を行っています。
反日系中国ウエッブサイトへの友好交流をしてくださる方！
お持ちの知識・技術を活用してくださる方！
三度の飯よりお祭りが好きな方！
今の自分を変えてみたい方！
ちょっと暇だと思ってる方！
夏休みの思い出を作りたい方！
田代砲に興味がある方！
もちろん愛国心に燃えてる方も大歓迎！！！！
どんな志願理由でもおｋ！みんなの参加を待ってるお！
「友 好」は「謝罪と賠償」じゃないです（´･ω･｀）
8/6土 20:00 集合 21:00 集団訪問開始予定です。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
★拠点
【友好交流】ハ´;）BAKKER VS VIPPER(´･ω【+盆祭+】112
ｽﾚﾘﾝｸ(news4vip板)
2chan専用プラウザをお勧めいたします。
なお、砲撃や投票に参加する人は必ずCCCにも参加してください。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
＊CCCに参加の際は板名などでもおｋですので必ずお名前を付けてください。
うんばぼ!うんばぼ!
80:仕様書無しさん
05/08/06 12:27:31
>76
リンク先の説明は分かりにくい。誤解してた人がいた訳がやっと分かった。
オブジェクト指向の方はもっとひどい。分かってる人でも混乱するぞ。
素人が読んだらオブジェクトはメッセージングだと言い出しかねない。
構造化は常識だが、新人もいる訳だから常識で済ませる訳にもいかないだろう。
それに「基本情報処理」持っていても実践していない奴は多い。
話を聞いてみると原理は勉強したが、実装方法が分からないし習ってないと言っていた。
オブジェクト指向は構造化を習得すれば受け入れやすいと言う意見だが、
それは構造化をマスターしていて、さらにそれを捨てれば受け入れやすいとは思う。
オブジェクト指向と構造化の実装は全く違う。いわば90度違うと言う所だ。
なんせ、構造化原則の「入り口と出口が1つ」と言う時点で違う。
81:仕様書無しさん
05/08/06 12:32:42
今のオブジェクト指向は最小単位を手続きで記述しなければいけないから
構造化プログラミングから逃げられないんだと思う
82:仕様書無しさん
05/08/06 12:36:16
>78
違う、ここで言う構造化とは構造化プログラミングを指す。
83:仕様書無しさん
05/08/06 12:39:38
>81
最小単位においてはその通りだ。
84:仕様書無しさん
05/08/06 12:51:33
>>80
>オブジェクト指向と構造化の実装は全く違う。いわば90度違うと言う所だ。
まぁそこはよしとして。
>なんせ、構造化原則の「入り口と出口が1つ」と言う時点で違う。
「入り口と出口が１つ」なオブジェクト指向プログラミングはありえないと？
例外機構を使わなくてもOOPは十分可能だが？
OOPとは「データに振る舞いを持たせ、それら（オブジェクト）に仕事をさせる」手法のことだ。
従来の構造化＋カプセル化をさらに発展させた物がその正体だ。
「構造化 対 オブジェクト指向」で考えるからおかしくなるんであって、
「オブジェクト指向前 対 オブジェクト指向」で一度考えてみたらどうかな？
85:仕様書無しさん
05/08/06 14:48:48
まあ手続き抽象 = 構造化って話は論外。
手続き抽象の歴史は構造化の歴史よりずっと長い。こんなのは歴史をしらなくても
ちょっと頭を働かせれば誰でもわかる。
フォンノイマンみたいな奴ならともかく、普通の人間は「意味のラベル」を貼ることができる
機能ブロックに分割できず、全てが有機的につながった様なプログラムは書けないし読めないから。
構造化ってのはその「手続き」の内部の設計を、受験勉強みたいに
パターン認識で解くことによってプログラムを書くことと読むことの両方を
効率化しようって話だよ。
ハイここは定数回ループする「パターン」、ハイここは値によって処理を選択する「パターン」、
ハイここは多分岐「パターン」って具合に。
86:仕様書無しさん
05/08/06 18:07:51
ダメダメ！！
変な説明は初心者を混乱させるだけだ。
結局、構造化プログラミングは70で説明した通りな訳だから、もうそれでいいだろう。
次はオブジェクト指向の説明に移ってくれ。
それも思想的な事じゃなくて、実際にコーディングするイメージで頼む。
87:仕様書無しさん
05/08/06 18:18:12
>84
オブジェクト指向の説明は正しいし、言いたいことは分かる。
ただその説明ではどうやってオブジェクト指向的にプログラミングするのか分からない。
ちなみに俺も構造化ほど明確に説明出来ない。
誰か「オブジェクト指向でコーディングする手順」を説明する勇者はいないか。
88:仕様書無しさん
05/08/06 18:25:08
>>86
頭大丈夫だろうかこの人。
だから、>>70に書いてあるようなことは構造化とは何の関係もない、
少なくとも構造化のテーマではないと言っているのだが。。
89:仕様書無しさん
05/08/06 19:04:40
オブジェクト指向で開発するととても楽で楽しくなった。
でも実行速度が遅くなったorz
90:仕様書無しさん
05/08/06 21:07:36
よくできたコードを読んでまねするのが一番いいよ。
91:仕様書無しさん
05/08/06 22:06:59
現在集団訪問中です
【友好交流】ハ´;）BAKKER VS VIPPER(´･ω【+盆祭+】112
ｽﾚﾘﾝｸ(news4vip板)
2chan専用プラウザをお勧めいたします。
民間の反日系中国ウエッブサイトへの抗議をしてくださる、お持ちの知識・技術を活用してくださる 等
・ ・ ・ ・
日 中 友 好 目的 での、ご参加をお待ちしております。
「友 好」は「謝罪と賠償」じゃないです（´･ω･｀）
92:仕様書無しさん
05/08/06 22:44:04
オブジェクト指向がわからないPGなんて食っていけないね
93:1
05/08/07 01:21:11
オブジェクト指向がわかる食い物を教えてくれ
94:仕様書無しさん
05/08/07 01:26:29
ピザでも食ってろ
95:1
05/08/07 01:37:04
ピザ嫌いのため却下
96:仕様書無しさん
05/08/07 01:42:27
その好き嫌いで拒絶する態度でオブジェクト指向すらも拒絶しているようですな
喰わずに死ね
97:1
05/08/08 18:45:06
そういえばまだ委譲について聞いてないな
誰かまともに教えられるやついねーのかよ。お前らゲスだなホント。
俺も時間ねーんだからもたもたすんな
自分で調べろだと？ ﾏﾝﾄﾞｸｾ
98:仕様書無しさん
05/08/08 19:18:04
今の時世にＯＯ解らない奴なんているのか？
99:仕様書無しさん
05/08/08 20:28:23
オブジェクト指向がわからないPGなんて食っていけないね
100:仕様書無しさん
05/08/09 09:23:24
>>97
前スレで話したよ
下請け会社を取り込んで作業の丸投げ(委譲)をすること。
リスクのある吸収合併（継承）や新部署設立(仕様変更/機能追加)よりイージーかつ柔軟に必要な仕事をこなせる。
class Kogaisha{
//ものすごく便利な機能
}
class Oyagaisha{
Kogaisha k；
//気に入らなくなったら
//別の会社に替えたっていい
}
これで親会社は子会社の機能を使える。
むつかしくないだろ？
101:仕様書無しさん
05/08/09 12:32:09
プログラムの見通しや再利用性を高め
継承、多態性、カプセル化を用いたもの
102:仕様書無しさん
05/08/09 12:43:55
久石譲とどこが違うのか良くわからないな。
103:仕様書無しさん
05/08/09 13:36:46
久石譲の名前の由来はクインシー・ジョーンズから。
よって全然違うよ！
104:仕様書無しさん
05/08/09 15:27:35
103様
ご教授いただきまことにありがとうございました。
今までそんなこともわからなかった自分が恥ずかしいと感じております。
ご教授いただいたことは我が家の家訓とし、
末代まで103様のことは語り継ぐ所存でございます。
105:仕様書無しさん
05/08/09 21:50:20
オブジェクト指向がわからないPGなんて食っていけないね
106:仕様書無しさん
05/08/09 22:18:08
大きなものを分割する訓練をつめばよろしいかと。
オブジェクト指向言語ではない場合でもこの訓練は有効かと。
まぁ、最初は50-100 行程度のクラスを何個も作っていったらどうでしょうか？
訓練にもなるし、資産にもなる。
107:仕様書無しさん
05/08/10 00:06:31
＞まぁ、最初は50-100 行程度のクラスを何個も作っていったらどうでしょうか？
はぁ？馬鹿ですか？
108:仕様書無しさん
05/08/10 01:11:42
関数ならともかくクラスでそんな量はつかいもんにならん
109:仕様書無しさん
05/08/10 01:17:43
>>107
行数で分けるのはおかしな話ですね。
オブジェクト指向をあまり理解せずに、行数の多いでかいクラスを作ろうとしていると、
ただ class 内にいろいろぶち込んだだけの「塊」が出来上がってしまう、
そう懸念したので、具体的な行数を出しただけですよ。
まぁ、50-100行 に無理矢理押さえ込もうとする方が苦痛になることもあるでしょうがね。
110:仕様書無しさん
05/08/10 01:18:53
最初は、と書いたと反論されそうだな。
無理矢理行数制限付けて実装するなら継承乱発かなぁ。
111:109
05/08/10 01:23:41
>>110
こんなところで「俺の方がオブジェクト指向理解しているぜぇーー」、
なんていう幼稚な喧嘩をするつもりはありませんよ。どうせレベル低そうですし。ｗ
112:仕様書無しさん
05/08/10 01:38:46
日本語よめんのかい？ 被害妄想はげしすぎんか？
これぐらいしか手がないねとしか言ってないんだが。
113:仕様書無しさん
05/08/10 08:42:53
>>109
全体の設計を視野に入れて
クラス間の関係を考えないと
伸びない気がするねえ
114:仕様書無しさん
05/08/10 08:44:48
最初はビットマップとかの画像クラス作るべきだと思う
カプセル化、再利用のありがたみがよくわかる
115:仕様書無しさん
05/08/10 10:54:49
オブジェクト指向がわからないPGなんて食っていけないね
116:仕様書無しさん
05/08/10 20:29:09
クラスライブラリにおんぶに抱っこでいいじゃん。
117:仕様書無しさん
05/08/10 23:15:21
アペオスのOOPっぷりには脱帽だね！
あれには舌を巻きますよね、ね！？
・・・・・・・・・・・・・・
どんでん返しですよね！！？！
どんでんは反さんよ、な？
どんでんは反さんでしょうｗｗｗｗ
わっはっはっは・・・・・
118:仕様書無しさん
05/08/10 23:36:51
>88
頭おかしいのはてめーだ。
ぐたぐたぬかす前に、お前が説明して見ろ。リンクじゃなくてな。
119:仕様書無しさん
05/08/10 23:50:09
>>118
文句言うの遅すぎ
120:仕様書無しさん
05/08/11 00:23:43
プログラミングの前に日本語勉強しとけ。
121:仕様書無しさん
05/08/11 01:29:52
ＯＯＰで一番大事な要素は「分類」ね。
小学生の頃やらされた知能指数測定テストにあったでしょ、
あるオブジェクトを数種類見せられて、好きなようにチーム分けしないさいってやつ。
あれですよ。
122:仕様書無しさん
05/08/11 01:34:37
>>118
10秒ほど君のレスを見させて貰ったけど>>88氏の言うとおりだ。
君、頭大丈夫？
自分で気付いてないのなら致命傷だよ。
123:仕様書無しさん
05/08/11 07:39:16
classify ってくらいだしね
124:仕様書無しさん
05/08/11 22:27:45
OOは大体分かった。
でもポインタがわからねぇ…
125:仕様書無しさん
05/08/12 00:29:36
>>124
たぶんＯＯもわかってないぞｗ
126:仕様書無しさん
05/08/12 01:40:53
>>124
ポインタがわからないと仮想関数が使えないから、
ほとんどOOの利点がいかせない．．．
127:仕様書無しさん
05/08/12 03:26:16
C++でOOするのは大変だろうな。
128:仕様書無しさん
05/08/12 05:06:19
頭悪いなりに思ってるのは変数の集合体が肉体だとして
その肉体を動かすための思考回路が肉体自身に備わっているって所だろうか
なにか間違ってる？
129:バブル期就職
05/08/12 06:57:25
リンクモジュールがどうロードされて実行されるかイメージがわかないから
から同じところで悩み続けるんだろうなぁ
しかもインタプリタだったりするからなぁ
130:仕様書無しさん
05/08/12 09:56:31
>>128
当たらずとも遠からずと言ったところか
131:1
05/08/12 16:41:05
１であるこの俺が自ら
＿＿＿. ∩゛ ∧空∧ （（（ ））） ／＼
/. ―┤. -=・=- -=・=- | | ∧ ∧｛´ ◎ `｝__＿＿（ ´∀｀）＼ う ＼
./(. = ,= | ∧∧ ∧＿∧ | | ( ´ー｀) ）:::／´∀｀ ;:::: ＼ヽ(`Д´)ﾉ゛＼ ま＼
|||＼┏┓/∫ (=ﾟωﾟ)ノ~ （ ´Д｀）／/ ＼ < .∧|∧ /::::::::::| .¶＿¶. ＼い＼
V/ ∧,,∧ ∬ ～（ x） ／ / ,一-、(´ー｀) /:::::|::::::| (ΦдΦ)／~ ＼棒＼
|| ミ,,ﾟДﾟノ,っ━~~ U U / /| / /￣ l⊂ヽ ＼/|:::::::::|::::::| γ＿＿ ∧w∧ 旦∬
人 ﾐ ,,, ~,,,ﾉ .ｎ THANK YOU 2ｃｈ ■■-っ ┌────┐ ＼ （ ﾟДﾟ ）∩゛
( ﾟーﾟ)と..ﾐ,,,/~),ヽ（凸）ﾉ~ and.. ´∀｀/. ｜ ● ● | ヽ ノ
／￣￣し'J＼［Y］ GOOD-BYE ２ｃｈ WORLD！ ／| .┌▽▽▽▽┐. |____|__||_| ））
/ ● ●､ヽ （. ┤ .｜ ｜. |□━□ ） (ﾟДﾟ)?
|Y Y ＼ またどこかで会おうね.. ＼. └△△△△┘. | J |）∧＿∧
|.| ｜ .▼ |∀ﾟ) ｜＼あ＼ | ∀ ﾉ " , 、 ﾐ
| ＼ ／■＼ ＿人 |∧∧∩゛∧＿∧∩゛∧＿∧ | ＼り.＼ | - Å′ ゝ∀ く
| （ ´∀｀）_＿＿／( ﾟДﾟ.)'/ （ ´∀｀ ）/ （・∀・ ）,. |. ＼が＼. | ）. ＼ Λ＿Λ
＼ （ Ｏ ） 冫、 U / （ / ⊂ ⊂.）ヽ(´ー｀)ﾉ゛ ＼と.. ∧_∧/(´Д｀;)<丶｀∀´>
｜││ │ ` | | ∪ | | （ （ （ ( へ (ﾟдﾟ)～⌒(ﾟーﾟ*) (-＿-) (･ω･` )
（_（__（＿_）（・∀・） ∪~∪ （＿（＿_） （＿（＿） く ⊂⌒~⊃｡Д｡）⊃⊃⊃（∩∩）（∩ ∩）
このスレはここまでです。ご愛顧ありがとうございました
132:仕様書無しさん
05/08/12 20:53:12
ﾇﾙ(･ω･)ﾎﾟﾘｰﾝ
133:仕様書無しさん
05/08/13 01:56:28
プログラミングの前に日本語勉強しとけ。
134:仕様書無しさん
05/08/13 16:27:32
遅レスするけど>>70に書いてあることはおおむねあっていると思うけど。
ジャンプ命令に関してはあってるでしょ。
入り口と出口が１つで同じ結果をえられるようにするにはとりあえず
グローバル変数廃止は必須だし。
機能毎に関数を作成するってのもおおむねはずれてはいないっしょ？
何が駄目なの？マジレスキボン。
135:仕様書無しさん
05/08/13 17:42:22
実はみんなわかってないんだよ
136:仕様書無しさん
05/08/14 00:59:36
オブジェクト指向がわからないPGなんて食っていけないね
137:仕様書無しさん
05/08/14 02:04:25
>>134
＞つまりgotoの禁止と、途中returnの禁止。
＞グローバル変数使用の禁止。（中断処理のフラグを除く）
＞変数のスコープ（有効範囲）に着目し、他のブロックと最も干渉の少ない単位で機能毎に関数化する。
内容はともかく、単なるプログラミング・ガイダンスというなら解る。
これらのどこら辺が"オブジェクト指向"なの？
138:仕様書無しさん
05/08/14 02:26:31
>>137
>>70は構造化に対する説明だろ。
139:仕様書無しさん
05/08/14 02:42:27
まだ続けるんかい、このスレｗ
140:仕様書無しさん
05/08/14 02:52:28
議論厨がわくかぎり永遠に。
141:仕様書無しさん
05/08/14 10:43:00
機能毎に部品分けするのがオブジェクト指向。
それでわからない奴や特定言語のコードの講釈たれてる奴は馬鹿。
142:仕様書無しさん
05/08/14 18:16:29
>>141
ちがう。機能別に部品分けする一つの流派がオブジェクト指向
『機能別に部品分け』 では構造化手法も含んでしまう
143:仕様書無しさん
05/08/14 18:35:16
中断処理のフラグ だけがグローバル変数化可能な理由が判らんなぁ
144:仕様書無しさん
05/08/14 18:47:02
>>143
複数の関数に渡っての処理を一気に抜けるための中断フラグは、グローバル変数にした方が便利だって言う事じゃない？
145:仕様書無しさん
05/08/14 19:29:53
>>143
俺もそれは疑問だった。スルーしたけど。
実は中断処理フラグでも俺は駄目だと思うな。
>>70の勝手な付けたしだと思う。
146:仕様書無しさん
05/08/14 19:49:46
じゃあ俺も。
途中returnって何でいけないの？
全く解らん。
保守性の高い実装もすることができるし、普通に多用されてる手法だと思うんだけど。
147:仕様書無しさん
05/08/14 20:00:07
>>146
いけなくない。
「入り口と出口は各一個なら全てのロジックは構造化して記述できる」
と証明した定理が存在していて、それを逆に考えているだけ。
つまり「構造化するなら出口は一個であるべきだ」と。
148:仕様書無しさん
05/08/14 20:04:28
>>146
ぶっちゃけ、構造化定理の立場では 『順接』 『条件分岐』 『反復』 以外の流れは全部 goto つまりイクナイなんですよ
149:仕様書無しさん
05/08/14 20:43:30
>>146
まあ、あんまり長い関数書く馬鹿がそこらへんにいたから
禁止してんだろうなって予想できる俺の環境ｗ
１０００行ぐらい続く関数眺めてると、途中returnとgotoは死ねる。
switch caseのbreakとcontinueに恐怖を抱くことができるソースを俺はもっているｗ
150:仕様書無しさん
05/08/14 20:45:05
俺、どうやっても千行の関数を作れないんだけど、コレってマズいの？
151:仕様書無しさん
05/08/14 20:58:30
改行1000行いれときゃいいだろうがボケ
152:仕様書無しさん
05/08/14 21:27:38
switch caseなんてあんまり分岐多いようならテーブル化した方がスマートだからなぁ。
153:1
05/08/14 23:00:43
今日、ハガレン見てきたよ。
いやー面白かったね。
154:仕様書無しさん
05/08/14 23:09:34
>>153
ハガレンは、言ってみればオブジェクト指向を映画化したようなもんだからな。
155:仕様書無しさん
05/08/14 23:10:11
ループの中のswitch caseで状態遷移させるようなコードはよくあるけど
goto使ってるのと同じだしな。
156:仕様書無しさん
05/08/14 23:22:42
>>155
遷移先でさらに遷移、なんてことが続いてると
ちょっと読む気無くすよね。
157:仕様書無しさん
05/08/15 09:07:46
>122
122=137なら、答えは138だ。
122はオブジェクト指向を知ってそうな様子なんで、実装観点の説明はできんか？
>143-145
中断処理のフラグってのはインタラブト（Ctrl+Cなど）がかかった時の処理だ。
Cだとシグナル使ったりするだろう。その時に後処理（リソースの解放）などをやるが、
リソースを確保する前かどうかを判定するのに使うフラグを、中断処理のフラグとした。
グローバル変数以外に使えるいい物がないんで、しかたなく使うことになるだろう。
外にいい手があるか？
>146
リターンがだめってのは、リソース解放のためだ。
つまり極端な例で言うと、10個のファイルオープンがあった場合、リターンしている箇所が
10箇所あれば、それぞれのリターンの前に10個のクローズが必要になる。
たとえそれを書いたとしても、保守になって次の担当に変わり変更が入った場合に忘れることが多い。
よかったなオマエラ、構造化プログラミングが理解できて。
次はオブジェクト指向に行くから、疑問点は解消しとけよ。
158:仕様書無しさん
05/08/15 09:37:44
>>157
めちゃめちゃ狭い視野でプログラミングを語るなよ。
159:仕様書無しさん
05/08/15 10:02:17
>>157
ﾈﾀ？
160:仕様書無しさん
05/08/15 10:03:21
＞リターンがだめってのは、リソース解放のためだ。
＞つまり極端な例で言うと、10個のファイルオープンがあった場合、リターンしている箇所が
＞10箇所あれば、それぞれのリターンの前に10個のクローズが必要になる。
こんな事言ってんだもの。程度が知れるわな。
10箇所があった場合に10個のクローズが必要になるのは
君の処理分割の方法が効率的でないからだよ。
161:仕様書無しさん
05/08/15 10:44:44
ポリモーフィズム
162:仕様書無しさん
05/08/15 11:46:39
うちの子を馬鹿にしないでちょうだい。
163:仕様書無しさん
05/08/15 13:23:30
>>19
> >17
> public static 変数は、グローバル変数じゃないの？
パッケージ名にドメイン名を織り交ぜてクラスを呼び出しかつ、
クラス名.staticフィールド名とアクセスするからCでよく起こるグローバル変数のような弊害
はほぼ起きない。下手な乱用は混乱の元だが、
大抵、public staticにするときはさらにfinalにして定数として使うものだ。
定数でないpublic staticな変数は特別な理由が無い限り不用意に作るではない。
> static メソッドはCの関数と同じじゃないの？
それに近い
164:仕様書無しさん
05/08/15 13:24:41
>>32
> >>13
> お前が教えてくれるまで、俺は帰らない
ﾌﾟ こいつ餓鬼だなw
165:仕様書無しさん
05/08/15 18:30:58
>>163
＞クラス名.staticフィールド名とアクセスするからCでよく起こるグローバル変数のような弊害はほぼ起きない
丁度ネームスペース内のグローバル変数にアクセスしている感じですな
名前の競合は起きないけど、それ以外の弊害は起きますぜ
弊害が起きるから
＞大抵、public staticにするときはさらにfinalにして定数として使うものだ
という習慣があるんだろうに
166:仕様書無しさん
05/08/15 18:42:23
おまいらはまず日本語を勉強しろ
167:仕様書無しさん
05/08/15 18:44:33
あぁ。きっと「どこで変更／更新しているかがわからない」という弊害かな。
#「検索すればイイ」という人は明示されていないという事実自体が弊害であるとは思っていない事が多いね
168:仕様書無しさん
05/08/15 19:12:35
>>167
副作用
169:8仕様書無しさん
05/08/15 19:31:40
>160
じゃあ、その効率的な例ってのを見せてくれ。
下のを修正してな。
int func(){
FILE *fp1;
FILE *fp2;
char buff1[100];
char buff2[100];
if(NULL == (fp1 = fopen("file1", "rb")){
return -1;
}
if(NULL == (fp2 = fopen("file2", "rb")){
fclose(fp1);
return -1;
}
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
fclose(fp2);
fclose(fp1);
return -1;
}
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
fclose(fp2);
fclose(fp1);
return -1;
}
fclose(fp2);
fclose(fp1);
retrun 0;
}
170:8仕様書無しさん
05/08/15 19:46:56
>158
中断フラグにグローバル変数が必要な訳と、途中リターンがダメな訳を書いたんだよ。
途中リターンがダメなのは他にも理由があるが、一番分かりやすくて重要なのを書いたんだ。
どっかの学者の宗教論みたいなのよりは、分かりやすいだろう。
試しにお前の広い視野で書いて見ろよ。
171:仕様書無しさん
05/08/15 20:34:57
オブジェクト指向COBOL
172:仕様書無しさん
05/08/15 21:29:41
つーか、このスレ、小学生がたてたんだな・・・
こんなところで議論して悲しくなってこないか？
俺は、一抜けたっとｗ
173:仕様書無しさん
05/08/15 21:34:08
>>157
>つまり極端な例で言うと、10個のファイルオープンがあった場合、リターンしている箇所が
>10箇所あれば、それぞれのリターンの前に10個のクローズが必要になる。
ファイル処理は呼び出し前後でやればいいじゃない
効率的に組めばそんな風には絶対ならないよ
174:仕様書無しさん
05/08/15 22:34:22
>>169
160じゃないけど書いてみたｗ。俺も暇人だなｗ
サンプルが悪いね。file1とfile2のデータに依存関係がある例でないと
現在の話題に沿わないのじゃないか？
int func1( char *fn, char *buf, int size ){
FILE *fp;
int ret;
if ( ( fp = fopen( fn, "rb" ) ) == NULL ) return -1;
ret = ( fread( buf, size, 1, fp ) < 1 ) ? -1: 0;
fclose( fp );
return ret;
}
int func(){
char buff1[100];
char buff2[100];
return ( func1( "file1", buff1, sizeof(buff1) ) && func1( "file2", buff2, sizeof(buff2) ) ) ? 0 : -1;
}
175:仕様書無しさん
05/08/15 22:53:18
>>169
まあオープンが１０回あったとしたらそんなコードの書き方はありえないが
サブ関数作らずにそれを途中リターンさせるならこうなるんじゃない？
int func(){
FILE *fp1=NULL; FILE *fp2=NULL;
char buff1[100]; char buff2[100];
int retcode = 0;
if(NULL == (fp1 = fopen("file1", "rb")){ retcode = -1; }
else if(NULL == (fp2 = fopen("file2", "rb")){ retcode = -1; }
if(retcode == 0){
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
retcode = -1;
}
if(retcode == 0){
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
retcode = -1;
}
}
}
if(retcode != 0){
if(fp2){
fclose(fp2);
}
if(fp1){
fclose(fp1);
}
return retcode;
}
fclose(fp2);
fclose(fp1);
retrun retcode;
}
176:175
05/08/15 23:28:55
見ずらいので少し整理してみた。
ちなみに漏れも>>160ではないでつ。
int func(){
FILE *fp1=NULL; FILE *fp2=NULL;
char buff1[100]; char buff2[100];
int retcode = 0;
if(NULL == (fp1 = fopen("file1", "rb"))){ retcode = -1; }
else if(NULL == (fp2 = fopen("file2", "rb"))){ retcode = -1; }
if(retcode == 0){
if(1 > fread(buff1, sizeof(buff1), 1, fp1)){ retcode = -1; }
if(retcode == 0 && (1 > fread(buff2, sizeof(buff2), 1, fp2))){ retcode = -1; }
}
if(retcode != 0){
if(fp2){ fclose(fp2); }
if(fp1){ fclose(fp1); }
return retcode;
}
fclose(fp2);
fclose(fp1);
retrun retcode;
}
177:仕様書無しさん
05/08/15 23:39:23
>>174のが一番無駄な処理が無く、簡潔で見やすい。
178:仕様書無しさん
05/08/15 23:45:36
動作的に微妙な違いがあるけどな。
179:仕様書無しさん
05/08/15 23:57:04
サンプルからしてコンパイルエラーなわけだが
180:仕様書無しさん
05/08/16 00:06:37
>>174って
return ( func1( "file1", buff1, sizeof(buff1) ) || func1( "file2", buff2, sizeof(buff2) ) ) ? -1 : 0;
じゃないの？
最近javaしかやっとらんので、C忘れちゃった。エヘ。
181:仕様書無しさん
05/08/16 00:12:54
>>174
１つのファイルのオープン～データの読み込み→ファイルクローズまでが
連続して行われるのならそういう形になるだろうね。
>>169の場合だと
file1オープン→file2オープン→file1読み込み→file2読み込み
→各ファイルクローズになってるけど。
182:仕様書無しさん
05/08/16 00:16:48
>>180
だな。
183:仕様書無しさん
05/08/16 00:19:29
>>175
サブルーチン使わなかったら構造化プログラミングにならないじゃない。
要するに>>169ってのは本来ならサブ化すべきところをサブ化しない為、
結果としてclose１０回書くようなコードになっちゃうって事だと思うんだけど。
184:仕様書無しさん
05/08/16 01:56:18
>>183
>>174でサブ関数使ったコードは書かれてるしね。
ポインタやフラグでリソースの状態管理をしていれば、
一連の処理後に一回close＆リターンすればいいから、
毎回一つずつcloseするなんて事はなくなる。
>>169が
＞リターンがだめってのは、リソース解放のためだ。
の証明になるサンプルではないって事が言いたいだけ。
185:8仕様書無しさん
05/08/16 09:45:30
>172,173
おいおい、コーディング出来ないからって逃げなくていいぞ。
いい機会だから勉強していったらどうだ。夏休みで暇だろう。
>174
依存関係がある物として見て欲しかったな。
本来ならreadの所に処理が入るし、write用のファイルを使ったりする。
fp2をwriteにしておけばよかったかな。
しかし酷いソースだな。短いだけで、可読性も保守性も無視してないか。
マクロ以外で三項演算子使うのはあまり良くないぞ。
あとifには{}付けろ、今は1行でも。
>175,176
それは途中リターンをしない構造化の書き方だな。
最後だけ無理にreturnを2箇所にしただけじゃ、途中リターンすると言うことにはならんだろう。
最初のリターンをifの外に出すと、リターンが1箇所になるぞ。
if(retcode != 0){
if(fp2){ fclose(fp2); }
if(fp1){ fclose(fp1); }
}
return retcode;
>184
つまり途中リターンありにすると、最後ってのが数カ所になるため、
「最後に1回やればいいだけ」ってのが出来なくなるって事だ。
わかったかな？
186:仕様書無しさん
05/08/16 09:55:00
＞わかったかな？
なんでそんなに偉そうなんだ？
187:仕様書無しさん
05/08/16 10:16:34
>>186
叩かれまくりなんで、自尊心保護の為に攻撃モードに入ってんでしょ。
188:仕様書無しさん
05/08/16 11:28:29
>>185
ファイル処理が１０箇所あると仮定するなら、>>169のような所で
途中リターンを使用するという事自体がありえない。
なので、>>169のサンプルが出来損ないなだけの話で、そのコードでは
＞リターンがだめってのは、リソース解放のためだ。
という論の証明にはなっていない。
＞最初のリターンをifの外に出すと、リターンが1箇所になるぞ。
そうした場合、正常に処理された場合にファイルがcloseされませんがなにか？
それでいいんだったら>>169での最後のfclose()もいらないという事になる。
てっきり最後に行われるfclose()の手前になんらかの処理を入れる事が前提で
ああ書かれているのかと思ってたけど違うのか。
もっとも、>>169が元々途中リターンが使えるようなコードではないから、
無理に入れたと言うのは否定しないけど。
まあ、的確なサンプルコード書けるようになってから出直した方がいいかと思うよ。
189:仕様書無しさん
05/08/16 11:43:31
＞まあ、的確なサンプルコード書けるようになってから出直した方がいいかと思うよ。
それはお前さん自身にもあてはまるんではないかと思うんだが。
190:仕様書無しさん
05/08/16 11:46:13
>>189
煽り入れる暇があるならまともなサンプルコードを提示してね＾＾；
まあ否定はしない。
191:仕様書無しさん
05/08/16 12:05:45
>>70=>>185
遊んでやるからトリップつけろ。
192:仕様書無しさん
05/08/16 12:18:19
>190
残念ながらとりあえず口はさんだだけの別人だ。
その位気付いてくれよな。
193:仕様書無しさん
05/08/16 13:13:34
void func() {
using(StreamReader sr01 = new StreamReader("file1"), sr02 = new StreamReader("file1")) {
String text01 = sr01.ReadToEnd();
String text02 = sr02.ReadToEnd();
}
}
194:仕様書無しさん
05/08/16 13:14:08
ん？ まあ良いか別に
195:8仕様書無しさん
05/08/16 20:24:28
>188
まず途中リターンする事がありえないと言うのはおかしいだろう。
エラー発生で処理を中断することは充分あり得るのではないかな？
サンプルが出来損ないと言うのはどういう事だ？問題の意図は188自身でも読み取っているのではないか？
だから174ではなく、175のサンプルを書いたんだろう。
しかしそれが途中リターンではなく、構造化の組み方だし、自分でもそれは否定しないんだろう。
途中リターンで適切な組み方は提供出来ないが、途中リターンはOKだと言いたいのか？
それとも途中リターンはNGだが、リソース解放が目的ではないと言いたいのか？
196:仕様書無しさん
05/08/16 20:47:16
まともな神経を持ったプログラマが構造化を意識してコーディングをした場合、
最終的な結果として>>169のようなコードになる事はまずあり得ないわな。
169のは使えん奴の書くコードだよ。まあたまにそういう奴居るけど。
要するに、ちゃんと構造化されてない出来損ないのコードじゃ、
途中returnの弊害を検証できるようなサンプルにはならない
って事なんじゃないの？
197:仕様書無しさん
05/08/16 21:03:28
途中リターンがリソース未解放のbugになるようなら、
「途中リターンが駄目」なのではなくて「プログラム構造が駄目」なのではないのか
198:仕様書無しさん
05/08/16 22:20:52
リソース未開放になるような所で途中リターンなんて使わないから、
途中リターン自体が駄目という理由にリソースうんぬんは関係ないな。
199:仕様書無しさん
05/08/17 00:12:45
>>198
リソースの開放なんて必要のなかった関数で途中リターンしてました
そのうちその関数でBeginTran()とEndTran()するように変更しました
案の定リリースしてからバグりました
それ以来C++のデストラクタは神だと思うようになっています。10年前の夏でした･･･
200:仕様書無しさん
05/08/17 01:14:18
浅い経験と狭い視野で物事を語る奴が多くてかなわんな。
そろそろOOに話を戻さないか？
201:仕様書無しさん
05/08/17 01:45:58
>>200
深い経験と広い視野で、OOを語ってくれないか？
202:8仕様書無しさん
05/08/17 08:57:04
>196
なるほど言いたい事は分かったが、それは誤解だ。
俺は構造化では途中リターンはダメだと言いたくて、途中リターンはいいのではないかと言う意見に対して、
「途中リターンしている構造化ではないプログラム」を提示して、途中リターンを残したまま、
構造化になるように修正してくれと言った訳だ。
結果的に175が途中リターンを廃した（無理にreturnが残っているが不要にできる）コードを提供して
くれたわけだから、途中リターンはダメだと言うのは分かっただろう。
203:8仕様書無しさん
05/08/17 09:09:49
一応、構造化されたコードを提供しておこう。
int func(){
int ret = 0;
FILE *fp1;
FILE *fp2;
char buff1[100];
char buff2[100];
if(NULL == (fp1 = fopen("file1", "rb")){
ret = -1;
}else{
if(NULL == (fp2 = fopen("file2", "rb")){
ret = -1;
}else{
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
ret = -1;
}else{
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
ret = -1;
}
}
fclose(fp2);
}
fclose(fp1);
}
retrun ret;
}
俺は201ではないが、201と同意見だ。
200にはOOを語ってもらおうでなないか。
できれば、どこかへのリンクではなく、自分の経験と視野で語ってくれるとありがたい。
204:仕様書無しさん
05/08/17 09:25:25
構造化の意味わかってんのかな
205:仕様書無しさん
05/08/17 12:01:50
>>202
まともなプログラマならリソースにからむような所で
途中リターンなんて使わないんだから、
使いもしない所で途中リターンを使えと言われても無理な話だ。
元々使わないんだから、途中リターンがダメな理由に
リソース開放うんぬんは関係ないだろ？
>>203
コンパイルエラー
括弧の数も数えられないのかい？
206:ウンコ
05/08/17 12:05:30
>>1
おれは教えたがり屋だー！
だから、おしえてやるー！
けど、教えたいことが多すぎて、とても書ききれないー！
だから、>>1は、Ｃ＋＋どのぐらいやってるのか、そして、
今までどういう本を読んだか？ 不明な点はどうやって調べてきたか？
（ 例えば.NETのオンラインヘルプでいつも調べてる、とか、）
得意な学問など教えてくれれば、多分、とっても詳しく、
しかも的確に教えてやれると思うぞ？
特に数学に関してはどのぐらいのレベルか書いてくれるとよろしいぞ。
どうだ？
まあ、「どうしてオブジェクト指向と数学が関係あるだよ！」
というようなら、おれの教える相手ではないな。
がはは！
207:仕様書無しさん
05/08/17 12:15:58
>>203
１０個のファイルオープンがあったとするなら
そんなコードの組み方ではとんでもない事になるぞ。
208:仕様書無しさん
05/08/17 13:24:32
Javaメインだから後処理はfinallyに任せて途中リターンしまくりだなあ。
C++はあんなに機能一杯なのにfinallyが無いのが信じられない。
209:仕様書無しさん
05/08/17 19:36:27
そろそろ終了か
210:1
05/08/17 21:54:36
>>206
今だから言うが、別に俺に教える必要は無い。
俺は俺で勉強してるし、聞く必要があったら上長に聞く。
このスレはつりなのだよ。わかるかね？
わからんか？！ ああ？ 死ねよｗ
211:仕様書無しさん
05/08/17 22:12:53
オブジェクト指向とは死ぬこととみつけたりぃ!!!
212:仕様書無しさん
05/08/17 22:16:55
>>209
＞このスレはつりなのだよ
大半の厨達は当然気づいている。無視しろ。
213:仕様書無しさん
05/08/17 22:17:33
>>209 ×
>>210 ○
214:仕様書無しさん
05/08/17 22:22:15
ハガレンを全巻読み直して、強気になった1がきたなｗ
215:8仕様書無しさん
05/08/17 23:08:05
まともな反論もなくなって来たようなので、構造化プログラミングは完了って事でいいだろう。
そろそろ本題のオブジェクト指向に移るとするか。
まあ実際俺もオブジェクト指向を、構造化のように簡潔に説明しろと言われても、できない訳だ。
つーわけでオブジェクト指向を簡潔に、いやこの言い方は悪いな。
オブジェクト指向型のプログラムを組む方法を、具体的に説明出来る勇者求む。
200はどうした？早く出て来い。
204でもいいぞ。
205だと、まともなプログラマはオブジェクト指向できるから説明いらないとか言いそうだな。
216:仕様書無しさん
05/08/17 23:17:42
オブジェクト指向まわりの愚痴はこのスレでいいのかな？
俺はオブジェクト指向や設計の話をするときに、ソースコードを要求する奴がウザクてかなわない。
お前はなんでそんなに馬鹿なのかと、頭ひっぱたきたくなる。
てゆうか、ホントそいつが馬鹿なことについて小１時間問い詰めたくなる。
なんでソースがいるのかと？
お前はどこの時代からやってきたのかと？
設計の話でなんでソースを出さなきゃわからないのかと？
根本的に想像力が足りないっつーか、そんなんじゃ一生オブジェクト指向なんて理解できねぇよっつーか、
人としてその程度で終わってて満足なのかっつーか、もうホント救えない。
あーすっきりした。じゃあね。
217:ウンコ
05/08/17 23:24:11
釣りか・・・。
なーんだ。
218:仕様書無しさん
05/08/17 23:25:27
ベタだけどやっぱソースより醤油だよな。
219:仕様書無しさん
05/08/17 23:28:52
>>215
「誰に何をやらせるかを考えて設計する」でどう?
220:仕様書無しさん
05/08/18 00:01:46
設計で一番大切なのはアプリケーションの抽象モデルを正しく理解する
あるいはおおむね正しく理解することだと思う
その点で入門書的なOOは非常に問題がある。
人と犬は哺乳類から派生して･･･というやつだ
人と犬のBaseクラスを作るべきかどうか、作るとして哺乳類かどうかはアプリケーションによる
アプリケーション内の現実をどうやってモデル化するか？という問題のはずだ
これをリアル世界で人も犬も哺乳類だからといういう理由で哺乳類Baseを作るのは設計の基本が
なっていないと思うがどうよ
正直設計に王道はないし、確立された方法もないと思う。OOが有効なのはOOPってのが俺の結論
221:仕様書無しさん
05/08/18 00:22:44
設計ならCRCカードとか結構使えると思うぞ。
ほんとにカード使うとふざけてると思われるので
ホワイトボードとかにエッセンスだけ使うとOO知らない人でも
結構通じるみたいだぞ。
222:仕様書無しさん
05/08/18 00:24:33
>>215
で、君はファイル１０個オープンという前提なのに>>203のような
コードを書くのかい？
223:仕様書無しさん
05/08/18 00:39:01
>>221
CRCは悪くないと思うが箇条書きやホワイトボードやUMLと比べて
特に優位性はないと思う。
設計はいろんな手法を織り交ぜて、さまざまなレベルで繰り返し考えて
完成させるものだと思うので特定の技法が支配的にはならないと思う
224:仕様書無しさん
05/08/18 00:50:21
>>222
if～elseの多用はアホグラマーの常套手段だからしょうがない
225:仕様書無しさん
05/08/18 00:58:59
「ネストの上限は5とする」という規約を決めたい
226:仕様書無しさん
05/08/18 01:11:29
>>223
まあ確かにね。
227:8仕様書無しさん
05/08/18 09:30:44
>222,224
一応RESしとこうかな。他の人は分かってると思うので読み飛ばしてくれ。
もし10個のファイルの同時使用が必要ならば、10段のネストにするよ。
しかし実際に同時に必要なのは3段ぐらいに収まるはずだから、3段のぐらいのネストにして、
その中は関数にするよな。
すまん、本気で疑問に思ってるとは思わなかったんで無視してた。
228:8仕様書無しさん
05/08/18 10:02:41
>220
俺もそう思う。
大昔に読んだオブジェクト指向の入門書もそんな感じだった。
「ドラ○ちゃん」は「ドラ○もん」の派生であるとか、ドラ○もん製造機がどうのとかの内容だった。
その頃はCの全盛期だったんで、Cとの違いを調査していたのだが、継承の説明が簡略されてて意味不明だった。
そのため、その本を読んだだけでは、
「外部変数を撤廃して関数をカプセル化すればオブジェクト指向と同じ」
と言う無茶苦茶な結論に達した。
ただ、そんな訳はないだろうとの事で、
「きっとほとんど説明されていない継承がすごいんだろう」
と言うことになってその時は保留になった。
つまり入門書にドラ○もんや哺乳類が出て来たら、捨てた方がいい。
229:8仕様書無しさん
05/08/18 10:10:21
>206
俺は1じゃなくて、オブジェクト指向マスター済みだが、みんなのために教えてくれ。
対象は、
・C++は未経験だが、Cは3年の経験。構造化マスター済み。
・読んだ本はオブジェクト指向の入門書で、哺乳類の事が書かれてるやつ。
・検索はグーグル。趣味は自作とアニメ。
・数学は小学生レベルで、四則演算マスター済み。
以上で、よろしく。
230:仕様書無しさん
05/08/18 10:29:09
ちょっと聞きたいんだが、貴様らの中でruby厨の奴、
もしいたら手上げろ。市場調査したい。
別にここに聞く必要は無いが、なんとなくだ。別にｗ
こないだ宇宙戦争見たんだけどよ、50年前の映画をまあまあ忠実に再現してると思うぞ。
収拾のつけ方はたぶんあれしかないし、主人公が科学者という矛盾もなくなってよかったじゃねーかよ。
この映画の落ちがだめだとか言ってるヤローはたぶんオリジナル知らない奴だな。ＤＶＤ借りて情報仕入れとけよ。糞が。
矢口マリ、テメーだよ。
231:仕様書無しさん
05/08/18 11:08:16
rubyは興味あるが今のところ使用する用途がない。
宇宙戦争ってたしかH.G.ウェルズのSF小説が原作じゃなかったっけか？
100年前だぞ。
232:仕様書無しさん
05/08/18 11:43:19
映画は50年前にやってたんだよ。
233:仕様書無しさん
05/08/18 11:57:43
>>220
モデルの理解と入門書的OOの批判とモデリングの方法論不在を同時に語っていて
論点が不明瞭だな
>どうやってモデル化するか？という問題のはずだ
ここだけ同意
234:仕様書無しさん
05/08/18 13:29:13
>>230
ヤグチマリが糞かどうかわ知らんが，オリジナルを知らんと面白さがわからんような映画は糞だろ
235:仕様書無しさん
05/08/18 13:38:09
落ちが糞といってたからな。映画は普通だが、矢口は間違いなく馬鹿だ。
236:仕様書無しさん
05/08/18 13:45:15
矢口が馬鹿だということは誰もが認めるところだろ。
映画通ぶってるけど、ほとんど何も知らないみたいだし。
宇宙戦争って言うのはほとんどのエイリアンものの元になった映画。インディペンデンスデイでは落ちをパクってるくらいだし。
237:仕様書無しさん
05/08/18 13:48:54
問題は矢口にどうやってOOの真髄を教えるかだな。
238:仕様書無しさん
05/08/18 13:52:45
今日の勉強の成果を発表する。
ドラえもんとガンダムは、
どちらもロボットクラスから派生したものである。
public class ドラえもん extends ロボット {
public 道具 ポケット();
}
public class ガンダム extends ロボット {
public ビーム 鉄砲();
}
239:仕様書無しさん
05/08/18 14:00:47
ってことは明日はロボットクラスの実装に入るんだな！
240:仕様書無しさん
05/08/18 14:15:52
>>227
１０段のネストだろうが関数だろうが同じ事だろｗ
241:仕様書無しさん
05/08/18 14:26:56
>>229
まずは参考にオブジェクト指向マスター済みのあなたの講釈が聞きたいな。
ぜひ、ご教授いただきたい。よろしく。
242:仕様書無しさん
05/08/18 14:30:11
無駄な関数で溢れ返るなら、ためらい無くネストを深くするなぁ俺は
243:仕様書無しさん
05/08/18 14:42:14
括弧の数も数えられないのにオブジェクト指向マスターとか言われてもなぁ（汗
244:仕様書無しさん
05/08/18 14:53:02
ネストを深くすると見ずらい上に拡張性の希薄なコードになるからな。
無駄に階層増やすより、できるところは一本道で組めるように心がけてる。
245:仕様書無しさん
05/08/18 14:59:00
「自称○○の専門家」 ほど怪しげな職業は無いです
246:仕様書無しさん
05/08/18 15:05:40
「～をマスターしてます！」とかって採用面接でよく言う奴いるけど
実際テストしてみるといろはのいの字も知らない奴ばかり。
プログラマは常に創意工夫の上に成り立っている職業なので、
マスターしたと思う事は途中で投げ出すのと同義だと思ってる。
247:仕様書無しさん
05/08/18 15:09:44
>>246
＞マスターしたと思う事は途中で投げ出すのと同義だと思ってる
同感。途中で投げたか、あるいは飽きたか
248:仕様書無しさん
05/08/18 16:30:55
>>238
リスコフの置換原則を守ってない。
安易な継承はいけません！
249:仕様書無しさん
05/08/18 16:43:58
>>248
悪いが、>>238 は守っていると思う
250:仕様書無しさん
05/08/18 17:30:59
>リスコフの置換原則について
このスレ初のためになる議論を頼む
251:仕様書無しさん
05/08/18 18:05:46
>>250
SubClass extends SuperClass の時、SubClass は SuperClass と置換可能であることが望ましい
掻い摘んで言うと、SubClass は SuperClass と同じように振舞う事が理想だということ
ガンダムってロボットと同じように振舞えるんじゃないの？
252:仕様書無しさん
05/08/18 18:13:32
ごめん文章が微妙に変だ
SuperClass は SubClass と置換可能である事が望ましい
要は SubClass は最低限 SuperClass と同じ仕事をこなせることが理想と
253:8仕様書無しさん
05/08/18 23:06:55
>240
何がｗなのか分からん。ネストを深くするのに抵抗がある人なのかな？
見にくいって言う人もいるけど慣れの問題だよ。拡張性が希薄ってのも何を指してるのかわからんな。
まあしかし、Javaとかではネストが浅くなるし、finallyもあるから途中リターンOKだから、
現代向きと言えば言えるな。
さてそろそろオブジェクト指向の説明に移るとするか。
254:8仕様書無しさん
05/08/18 23:17:58
ではお待ちかねのオブジェクト指向プログラミングの説明だ。
まず最初に言っておくが、これは俺のやり方なので、誰でも出来るかは分からない。
さらに完全版ではない。また他にいい方法もあるかもしれないので、自分で研究して開発してくれ。
まずオブジェクト指向プログラミングには、経験とセンスが必要だ。
多少の訓練をすれば誰でも出来る構造化プログラミングとはちょっと違う。
新人で出来ない人でも気にする必要は無い。3年ぐらいの実務経験を積んでからチャレンジすれば良い。
5年の実務経験があって、半年勉強しても分からない人は諦めた方がいい。
それはセンスの無いためだが、センスが無くても普通の業務ぐらいはこなせるから、
無理して覚える必要は無い。
まあ、俺の経験ではプログラマの中で30%ぐらいは、頑張ってもオブジェクト指向を理解出来ない人がいる。
255:仕様書無しさん
05/08/18 23:24:07
終始センスかよ
256:8仕様書無しさん
05/08/18 23:32:39
オブジェクト指向型プログラミングの方法には2種類ある。
1.構造化プログラミングで作成した後に、作成された構造体をクラスにして、
それに関連する関数を作成したクラスのメソッドとして追加する。
2.使用するデータをDB設計の手法を用いてテーブルとして作成し、それをクラスとする。
その後にそのデータに関連する処理をメソッドとして作成する。
1の方法は非常に困難である。まず構造化手法で脳内で作成して、分解、分類を行うため、
相当の熟練者でなければ不可能である。また一度に作成出来る量も少なくなる。
そのため、1の方法は推奨しない。長年構造化をやってきた人がオブジェクト指向に移るために
最初に行うのはいいかもしれない。
次に2の方法だが、まずDB設計が出来るのが前提である。
DB設計と言うのは非常に高度な作業で、経験と学習が必要である。
経験というのは設計から保守までを言う。
最初に設計しただけではだめで、多くの仕様変更に耐えたDBを設計運用した経験が必要である。
また経験だけでもだめで、学習が必要である。最低でも正規化ぐらいはマスターしておいて欲しい。
では2の方法で説明しよう。今日はここまで、また次回。
257:仕様書無しさん
05/08/19 00:16:35
>>254,256
他の書き込みを完全に無視した長文お疲れ
258:仕様書無しさん
05/08/19 02:10:00
>>256
OOPとRDBは仮面夫婦。
本質的に仲が悪いのに世間体のために同居している。
そんなことも知らんのか。
259:仕様書無しさん
05/08/19 04:14:20
オブジェクト指向をマスターしたのに完全版ではないとはこれいかに
260:仕様書無しさん
05/08/19 04:19:47
そう言っておく事で突っ込みの言い訳する逃げ道を作ってるんだろｗ
261:仕様書無しさん
05/08/19 06:18:47
>>256
ＤＢ設計手法はオブジェクト指向型プログラミングに適したものではないな。
根本的に違うものだから。
262:8仕様書無しさん
05/08/19 09:47:07
>258
そうかな？
オブジェクト指向と仲の悪いのは、DB自体でなく「SQL」だろ。
そんな事もしらんのか？とは言わないが、ちょっと考えてみてくれ。
>259,260
分かった分かった。
突っ込まれたら「完全ではないで逃げない」事にするから、ちょっとは内容に突っ込んで見たらどうだ？
>261
根本的に違うのは承知の上だが、データ分けする部分などの正規化の部分が利用出来ると思う。
DB設計の知識の方が膨大だが、その一部をオブジェクト指向に利用する物だと考えてくれ。
また、反論の時は具体的な理由も書いて欲しいな。
こっちが反論する時に対象が曖昧になるからな。
「～するときに、～が問題になる」形式だと助かる。
263:8仕様書無しさん
05/08/19 09:57:51
>241
ほらおまえの番だぞ。
264:248
05/08/19 10:07:57
>>249
おわー賑わってる。遅レスすまんです。
痴漢原則に則ると、これが望ましいと思われます。
public class ドラえもん extends ロボット {
public 出るもの 出す(){
return new 道具;
};
}
public class ガンダム extends ロボット {
public 出るもの 出す(){
return new ビーム;
};
}
もちろん、道具とビームは出るものの子クラス。
せっかく同じロボットクラスを継承した兄弟なんだから
インタフェースは極力一緒にしたい。
そうすれば、コンテキスト側を変える事無く
ドラもガンムも使える事になる。
ただ、メソッド名が汎用的すぎて不明瞭てのはあるかも。
そこは思案のしどころだね。
265:248
05/08/19 10:13:18
おっと失敬、セミコロン消し忘れがあった。
あと、ロボットクラスはどうせならインタフェースにしたい。
public interface ロボット {
public 出るもの 出す();
}
>250
こんなんでためになる？
なんか皆さんには釈迦に説法みたいで恐縮なんですが。
266:仕様書無しさん
05/08/19 11:12:24
>>262
＞2.使用するデータをDB設計の手法を用いてテーブルとして作成し、それをクラスとする。
＞ その後にそのデータに関連する処理をメソッドとして作成する。
DB設計的に良い分割がOO的には役に立たないと思う
OOの基本のひとつに隠蔽、データ抽象があるけど、これとDBの正規化は真逆の概念でしょ
ただ現実世界ではObjectを永続化する必要があるわけで、そのときにRDBを使うならORマッピング
は避けて通れない。ORマッピングを苦労するくらいならOO的な美しさを捨ててDB基本主義で作る
っていうのは賛成する
でもそれはOOの敗北であって、決してOOとRDBが仲がいいということではない
267:仕様書無しさん
05/08/19 11:14:18
俺も白いものがある部位から出てくるので
public class 俺 extends ロボット {
public 出るもの 出す(){
return new 白いもの;
}
}
でOKか？
268:仕様書無しさん
05/08/19 11:26:10
>>263
２の方法での説明とやらはどうしたんだい？
269:248
05/08/19 12:32:04
>>267
オーケーオーケー。
ただロボットはinterfaceにしたいから
implementsだとありがたいです。
これじゃ多態性ってより、多態・性ですね。
270:248
05/08/19 12:55:07
いったんまじめな話に戻ると
>>252
に書いてある事だと継承はただの差分プログラムになっちゃう。
ロボット型変数でガンダムのインスタンスを受けた時、
鉄砲メソッドを使おうとするとガンダムにキャストしなきゃいけない。
だから置換原則に反してると思った訳です。
出すメソッドをオーバーライドする形ならキャストは要りません。
簡単に白いものも飛ばせるようになった事でも
interfaceへのプログラミングの柔軟性が判りますね。
まあやりすぎはソースが読みにくくなっていやんだけど。
出すメソッドって名前じゃ抽象的すぎるし。
こんなんでどうでしょう。
271:仕様書無しさん
05/08/19 14:07:25
ロボットクラスの例って設計時の手順のヒントにもなってるね。
1. ドラえもんクラスとガンダムクラスをつくろうとした。
2. ドラえもんクラスはポケットメソッド、ガンダムクラスは鉄砲メソッドを持つ
3. ポケットメソッドと鉄砲メソッドを出すメソッドで抽象化できることに気づいた
4. ロボットインターフェースで出すメソッドを定義しドラえもんクラスとガンダムクラスで、
出すメソッドを実装した
5. 俺クラスもロボットインターフェースをインプリメントできることに気づいた
こういう流れでクラス設計してくのって結構ありがちじゃない？
272:仕様書無しさん
05/08/19 16:17:08
>>256
ぐぐるだけでどこにでも書いてあるような事を
自論であるかのように得意げに語られても困るわ。
273:仕様書無しさん
05/08/19 17:02:25
ホリエモン無所属かよ
まあ小泉の独裁政治に加担するよりましだな
274:仕様書無しさん
05/08/19 17:03:58
ｽﾏﾝごばくったorz
275:仕様書無しさん
05/08/19 17:15:08
>>273
いやいや、無所属だが小泉自民のバックアップつきだぞ
276:仕様書無しさん
05/08/19 17:40:30
で、ホリエモンクラスは何を出すんだ？
277:仕様書無しさん
05/08/19 18:08:24
>>271
そうですねえ。
オブジェクトは現実世界のなんちゃらとかゆうよりも
だんぜん現実的。
このスレ初のためになる議論になったかな。
そうでもないか。
278:8仕様書無しさん
05/08/19 20:38:05
>272
本当にどこかに書いてあるなら、俺の考えと同じ考えの人がいるって事で、
俺の正当性が増したってことだな。
さらに272自身が内容自体に文句を言ってないって事は、272も内容に異存はないって事で、
さらに正当性が増したって事だな。
おつかれ。
279:8仕様書無しさん
05/08/19 20:42:52
ロボット説明はドラ○もん説明や哺乳類説明と同じで、オブジェクト指向を知っている人にしか分からない。
で、オブジェクト指向知っている人が、分かりやすい説明だとか言うから、
知らない人に「キ○ガイが集まるスレはここですか」と言われる。
280:仕様書無しさん
05/08/19 21:06:48
>>271
お世辞にもいいサンプルとはいえないな
共通のベースクラスを作るのに【ポケットメソッドと鉄砲メソッドを出すメソッドで抽象化できることに気づいた】
が理由というのはOO覚えたての初心者によくある「なんでもいいからOO使いたい病」にしか見えん
281:仕様書無しさん
05/08/19 21:23:53
>>271
俺だったら、
class Robot
{
public:
virtual void gun() = 0;
//または virtual void gun(){} か？
virtual void pocket() = 0;
//または virtual void pocket(){} か？
};
class Doraemon : public Robot{};
class Gandom : public Robot{};
のようにするな。gun や pocket でいったい何をするのか
さっぱりわからんがｗ
C++ですまん。
282:仕様書無しさん
05/08/19 21:27:04
>>281はCからの転向組。
283:仕様書無しさん
05/08/19 21:35:24
「オブジェクト指向で開発をする」
と言いつつ、結局最後には昔ながらの開発スタイルになってやがる。
そして残ったのは、開発を始めた頃に書かれた誰も読まなくなったUMLの各種設計書・・・
284:仕様書無しさん
05/08/19 21:48:02
>>283
それほどまでに「オブジェクト指向開発」は難しいものなのだよ。さて、ここでオブジェクト指向
開発を最後まで持続できる方法に関するヒントをあげよう。
ヒント：「適度な忍耐力」と「割り切り」と「切り捨て」
285:仕様書無しさん
05/08/19 22:00:10
>>284
割り切ってオブジェクト指向を切り捨てよう
すると忍耐もいらない。
286:仕様書無しさん
05/08/19 22:08:12
オブジェクト指向なんて子供のおもちゃですよ。
それで給料が上がるわけじゃない。
287:仕様書無しさん
05/08/19 22:14:00
>>278
別に否定するつもりは元からないから。ただつまらんだけだ。
３流サイトの丸写しで満足かい？
君にしかできない身のある説明をしてくれ。
288:仕様書無しさん
05/08/19 22:20:58
>>287
俺は278ではないが、君は批判しかしていないだろ。
君こそ、君にしかできない身のある説明をしてくれよ。
289:仕様書無しさん
05/08/19 22:22:50
自演乙
290:仕様書無しさん
05/08/19 22:25:44
>>288
そういう君こそ、君にしかできない（ｒｙ
291:仕様書無しさん
05/08/19 22:28:16
結局のところ、ここには身のある説明ができる人は一人もいないって事でＦＡ？
いたら説明してくれ。マジで。
292:仕様書無しさん
05/08/19 22:30:25
結局、糞の集まりだな。
293:仕様書無しさん
05/08/19 22:39:14
そろそろこのスレ終了かな。
ためになる事一つもないからもういいよ。
といいつつage
294:仕様書無しさん
05/08/19 22:48:28
オブジェクト指向やってるとこあります？
やっぱ専用の開発ツール必要ですよね？
295:仕様書無しさん
05/08/19 22:51:33
こりゃまたすごい質問がきたな
296:仕様書無しさん
05/08/19 22:52:21
緊急告知！
今ＶＩＰと韓国サイバーテロ集団が火花をあげて戦っています！
この夏の思い出作りに是非貴方達ももこの祭りに参加しませんか？
↓↓↓詳しくはは↓↓↓
ｽﾚﾘﾝｸ(news4vip板)
ご協力、よろしくお願いします。
【VIP】抗議文を考えてくれ
ｽﾚﾘﾝｸ(english板)
297:仕様書無しさん
05/08/19 22:59:29
犬＝オブジェクト
犬．尻尾を追っかけてクルクル回る
犬．俺に前足を掛けて腰を振る
まっ、そういうことだ。
298:仕様書無しさん
05/08/19 23:19:33
>>280
元がネタだしな。
- ロボットを戦わせるゲームをつくる
- ロボットのみを後からリリース可能で、ゲームに追加できる
という前提をつけてみたら?
299:仕様書無しさん
05/08/19 23:34:28
今日は、ファクトリーパターンというものを教えてもらった。
public class ４本足Factory {
public ４本足 factory(String 特徴) {
if (特徴.equals("背もたれ")) {
return new 椅子();
}
if (特徴.equals("ぬれた鼻")) {
return new 犬();
}
}
}
300:仕様書無しさん
05/08/19 23:47:08
戦争だ。援軍頼む。
ｽﾚﾘﾝｸ(news4vip板)
301:仕様書無しさん
05/08/19 23:47:54
>>299
それでは椅子が食えないから中国人が文句たらたらだろ。
302:仕様書無しさん
05/08/20 00:09:46
>300
チョンと同レベルの阿呆は(･∀･)ｶｴﾚ!
303:仕様書無しさん
05/08/20 01:41:39
はいはいワロスワロス
304:仕様書無しさん
05/08/20 10:22:15
2chでまじめな話するのはいやだが、
しょうがないから業務システムでありそうな例考えてみた。
- なんちゃら申請書が何種類もある
- 申請書は上司の承認が必要である
- 申請書の入力項目はまちまちである。
- 申請書は書きかけでもシステムに保存できる
- ほとんどの申請書は上司に提出する前なら書いた本人が削除できる。
ただし、タクシー代清算申請書は金額が低ければ、上司に提出後
上司が削除できる。
- 削除できない場合は画面上に削除ボタンは表示しない。
- 今の開発は第一フェーズで第二フェーズで申請書の種類が増えるが
仕様は全く決まっていない。
こんな感じのときお前らどう作る?
305:仕様書無しさん
05/08/20 10:30:18
素直に助けてくださいって言えよ。
306:仕様書無しさん
05/08/20 10:36:49
>>304
助けてください。
なーんて、実は昔作ったのとほぼ一緒の内容。
俺は単純に
申請書ベースクラスで表示可か不可を返すメソッドを実装してディフォルト動作とし、
タクシー代清算申請書で上書きした。
二次フェーズで削除可不可のロジックがまたいろいろ出てきそうだったしね。
もちろんOOしなくても書けるし、OOでも他にやりかたあんだろうね。
他人がどうするか見てみたい。
307:仕様書無しさん
05/08/20 10:41:20
レス番を間違えるあたり、>>306の必死さが覗える
308:仕様書無しさん
05/08/20 10:43:33
>>307
せっかくまじめな例出してやったのにそんないいかたするなよ。
で、お前はどうするよ。
309:仕様書無しさん
05/08/20 10:49:01
夏休みの宿題は自分でやろう
310:仕様書無しさん
05/08/20 10:53:06
おいおい。
つまらん連中だな。
311:8仕様書無しさん
05/08/20 11:11:05
>287
本当にあるようなので、そのサイトのアドレス教えてくれないか？
いや287への攻撃って意味じゃなくて、そのサイトでどういう説明しているのか見てみたい。
大体、コピペかどうかは本人がよく知っている訳だから、俺にコピペだって批判されても、
そうじゃないとしか言えないな。大体、長文で本当のコピなら見れば分かるだろう。
312:8仕様書無しさん
05/08/20 11:26:30
>266
266に反論するつもりだったんだが、304で面白いのが出て来たのまた今度。
>304
やっとホネのありそうな奴が出て来たので、解答を考えて見る事にする。
是非ともロボットマニアの方々の設計も見せて頂きたい。
大口叩いた連中は、クラス分けぐらいでも見せてみろよ。
（俺が一番大口というのは別棚）
313:仕様書無しさん
05/08/20 11:28:16
はいはいワロスワロス
314:仕様書無しさん
05/08/20 11:36:47
いい反論が思いつかないから先延ばしって事なんだろうねー
315:仕様書無しさん
05/08/20 11:40:27
>>304
漏れもそんな感じの設計１週間で完了しろって言われたよ。
316:仕様書無しさん
05/08/20 12:01:36
お、頼むよ。
期待してるよ！
317:仕様書無しさん
05/08/20 12:45:32
>>304
申請書の規定クラス作って、そこにそれぞれの種類の申請書クラスをぶら下げるだけだろ？
318:仕様書無しさん
05/08/20 12:54:09
全体的に実装すべきことは、大別して、
・申請書の登録、更新、削除
・申請フロー制御
・各ユーザごとの権限制御
だな。
319:仕様書無しさん
05/08/20 13:03:51
どの申請フローを通るかは、申請書ごとに決定するわけだから、
申請書には、申請フロー情報がぶら下がる。
ただ、出した人間の部署によって、各所属の部課長の承認が必要な可能性があるな。
そうすると、申請フロー図の各ノードに乗る承認者は、１ユーザであったり、役職であったりする可能性があるな。
あと、承認者不在時の代行処理や、申請迂回も考慮した方がいいかもな。
誰か一人いないせいで、処理が止まってしまっては、使えないから。
あと、一つの承認レベルに複数の承認者がいる可能性もあるな。
3人が承認して、初めて次のレベルの承認者に書類が回されるけど、
この3人のレベルは同じで、下位のレベルで承認された場合は、3人同時に書類が届かないといけない、みたいな。
逆に、一つのレベルに複数の承認者がいて、誰か一人承認すればよい、みたいのもありうる。
ないならないで、いいが、全く考慮しないのはあぶないな。
この辺を考慮して申請書フローのクラス構造を考えないと、あとで直しが大変だな。
320:仕様書無しさん
05/08/21 00:47:07
申請書はDBに保存するんだろ?
ならBaseクラスはLoadとSaveのメソッドを持たなくてはいけないな
後必要そうなのは
・申請(Person 提出者)
・承認(Person 承認者)
・却下(Person 承認者)
そして振る舞いをオーバーライドしたいから
・virtual On申請されたとき()
・virtual On承認されたとき()
・virtual On却下されたとき()
プロパティとしてその報告書特有のフィールドがあるだろう。そしてそれはDBの各カラムと対応しなければならない
俺なら定義書ファイルからDBのTable作成のためのSQLとソースコードを同時に作成するスクリプトを作る
そのほかに全ての報告書に共通のプロパティとして
・承認フローのタイプ
・申請者
・承認状態
・申請時間
などがあるかな
321:仕様書無しさん
05/08/21 12:45:14
>319,320
おれはO-Rマッピングツール、ワークフローは出来合いのものを使ったのでその辺は楽ちんだった。
その辺自分で作るとなると結構大変だよな。
322:仕様書無しさん
05/08/21 17:49:10
ちょっと待てｺﾞﾗｧ！
323:仕様書無しさん
05/08/22 19:35:17
オブジェクト指向プログラミングではグローバル変数が存在しないって本当ですか？
324:仕様書無しさん
05/08/22 19:48:40
>>169
超効率悪いな。
わざと言ってるだろ
325:仕様書無しさん
05/08/22 20:21:12
オブジェクト指向ならこんなにスッキリ！
#include <string>
#include <cstdio>
class FileReader
{
std::string fname;
FILE *fp;
char buf[100];
public:
FileReader(const char *pfname, const char *mode) : fname(std::string(pfname)), fp(NULL)
{ if( NULL == (fp = fopen(fname.c_str(), mode))) throw "fopen error : " + fname; }
~FileReader() { if( fp ) fclose(fp); }
char *read_byte()
{ if( 1 > fread(buf, sizeof(buf), 1, fp)) throw "fread error : " + fname;
return buf;
}
};
int func(){
try{
FileReader fr1("file1", "rb");
FileReader fr2("file1", "rb");
char ch1 = *fr1.read_byte();
char ch2 = *fr2.read_byte();
}catch(...){
return -1;
}
return 0;
}
326:仕様書無しさん
05/08/22 20:50:02
>>325
try catch があればこんなにスッキリ
なら理解できるけど
どのへんがOOかをもっと詳しくお願いしたい
327:仕様書無しさん
05/08/22 21:08:12
>>326
見るところはtry-catchじゃなくてﾃﾞｽﾄﾗｸﾀでのｸﾛｰｽﾞだろ？
328:仕様書無しさん
05/08/23 00:05:29
>>169
import java.io.file;
//(ry
public class FileIoDemo{
private File file;
public FileIoDemo(File file){
this.file = file;
this.file.createNewFile();
}
329:仕様書無しさん
05/08/23 00:07:38
public int func(){
PrintWriter writer = null;
try{
writer = new PrintWriter(
new PrintWriter(
new OutputStreamWriter(
new FileOutputStream(fp1), encode
)
)
);
while(何か処理){
writer.write(何か書き込む);
}
330:仕様書無しさん
05/08/23 00:09:29
} catch(IOException e) {
e.printStackTrace();
} catch(FileNotFoundException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
} finally {
try {
if(writer != null){
writer.close();
}
} catch(IOException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
} finally {
}
331:仕様書無しさん
05/08/23 00:09:42
publise UsingDemoClass{
public static final void main(final String[] args){
File directory = new File("/usr/local/apps/examples/io/");
if(!directory.exists()){
directory.mkdirs();
}
File fp1 = new File(directory, "file1");
File fp2 = new File(directory, "file2");
List<FileIoDemo> fileIoDemoList = new ArrayList<FileIoDemo>();
FileIoDemo fileIoDemo1 = new FileIoDemo(fp1);
FileIoDemo fileIoDemo2 = new FileIoDemo(fp2);
}
}
これはどう？
332:仕様書無しさん
05/08/23 00:20:27
もともとのお題が良くないから別になんともって感じだね。
サブルーチンがメンバメソッドに変わった程度じゃね、、
ＯＯって程のもんじゃないでしょ。
333:仕様書無しさん
05/08/23 01:24:48
なにを書やりたいのか意味不明なお題だよな
334:仕様書無しさん
05/08/23 01:25:30
なにを書やりたいのか意味不明なレスだよな
335:仕様書無しさん
05/08/23 05:47:59
>>332
サブルーチンなんて死語を今どき使うお爺さんがいるとは
336:仕様書無しさん
05/08/23 05:53:14
>>332のような分からず屋のために
>>328を改良したほうがよさそうだ。
改良型FileIoDemoの実装としては
フィールドにWriterを追加だ。
そしてFileIoDemoにclose()メソッドを委譲させる。
そして、Listオブジェクトをwhile()で回して
close()メソッドの記述を一回で済ませる。
それとimport文を忘れている。
import java.io.PrintWriter;
import java.io.BufferedWriter;
import java.io.Writer;
import java.nio.charset.Charset.;
import java.io.FileWriter;
import java.io.OutputStreamWriter;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.FileNotFoundException ;
あとはまかせた、
337:仕様書無しさん
05/08/23 05:56:08
ささ、抽象クラスを作ってあげたから継承しなさい！
public abstract class 改良型FileIoDemoAbstract {
private Writer writer;
public 改良型FileIoDemo(Writer writer){
this.writer = writer;
}
public abstract void close() throws IOException {
}
//あとは任せた
}
338:先生
05/08/23 05:56:38
こうやって絶えずリファクタリングするんだよ
339:仕様書無しさん
05/08/23 06:57:27
こうやって、前に進んでいるようで進んでいない
予算ばかりかかるプロジェクトは破綻していくんだよ
340:仕様書無しさん
05/08/23 10:14:30
専門学校生が学習中の中途半端な知識をひけらかして悦に入るスレはここですか？
お前らさ、何を得意げに無意味なゴミコード晒してんの？
341:仕様書無しさん
05/08/23 10:30:59
そういやこの前しゃべり場でスキルを身につけるために
大学よりもコンピュータ専門学生に行く事を選んだとかいってた
馬鹿がいたな。
そういう奴らが集まって恥部を晒すスレか
342:仕様書無しさん
05/08/23 14:47:48 BE:624370289-
>>339-340
あんたらネガティブだねえ
>>340
思うんだが、専門学校卒業した香具師が
バイト先にいるんだがオブジェクト指向なんて全然しらないのが
不思議でしょうがないんだけどなあ。
ちなみに漏れは大学院生ね
>>341
オブジェクト指向教育は専門学校ですらやらないところが多そうだがなあ。
とりあえず、デザインパターンの本でも読んでみなよ。
専門学校なんて行かなくても
オブジェクト指向スキルが身に付くから。
343:仕様書無しさん
05/08/23 14:52:34 BE:182107973-
スーパークラスに
publiv Writer getWriter(){
return this.writer;
}
を追加しないといけないね。
public class 改良型FileIoDemo extends 改良型FileIoDemoAbstract {
public 改良型FileIoDemo(Writer writer){
super(writer);
}
public void close() throws IOException {
this.getWriter().close();
}
//さらにあとは任せた。
public void write() throws IOException {
//任せた。自分で実装してくれ
}
}
ついでにスーパークラスにこいつも追加ね
/**
* 書き込み.
public abstract void write() throws IOException;
344:252
05/08/23 15:34:56
>>270
亀だがすまぬ。なんか返信したつもりでしてなかったみたいで
リスコフの置換原則ってのは具体例を挙げて言うと、
『ガンダムはロボットを継承している。ならばロボットにできることはガンダムにもできてしかるべきだ』
って言うこと。
この原則に反する設計は、スーパークラスの振る舞いをキャンセルするような設計だ。
んで >>238 はその原則をとりあえず守ってるみたいなんだな。
ついでに言うと、
＞ロボット型変数でガンダムのインスタンスを受けた時、
＞鉄砲メソッドを使おうとするとガンダムにキャストしなきゃいけない。
ロボットにできない筈の事をしようとしているんだから、ある意味キャストは自然だよな。
こんなの置換原則でもなんでもない。
345:270
05/08/23 16:59:33
>>344
レスありがとう。
でも原則の定義がちょっと違うと思います。
それだと差分プログラムでしかないでしょう？
『派生型は基本型と置換可能でなければならない。』
これが要約。つまり、コンテキスト側で
ガンダム.出す()
と書いてある所を、
ロボット.出す()
って置換しても振る舞いが変わらないようにしなきゃいけない。
これがLSPだと、俺はずっと思ってたんだけど、違うのかな？
少なくともR.マーチンの文章からはそう読んだんですが。
もちろん原則は原則であって、やぶったら絶対にいけないって訳じゃないから
キャストくらいする局面は幾らでもあるでしょう。
でも、なるたけそれは避けようぜ、って話ですね。
346:270
05/08/23 17:01:10
あわわ間違えた。
＞置換しても振る舞いが変わらないようにしなきゃいけない
振る舞いは変わるんだよ！バカだなー。すまそ。
347:252
05/08/23 17:25:13
>>270
あれ？と思って調べてみたら
＞派生型はその基本型と置換可能でなければならない
＞基本クラス型を派生クラス型に置き換えても正常に動作しなくてはならない
の両方を見つけたよ
URLﾘﾝｸ(www.atmarkit.co.jp)
俺は下の方をリスコフの置換原則だと思ってたけど原書ではどうなんだろ
けど、２個目の文の直ぐ下にも
＞そのためには派生クラスは基本クラスの振る舞いの妥当性を維持する必要がある。
＞基本クラス以下の機能しか持たない派生クラスは、基本クラスと置き換えることはできない
って書いてあるし
348:252
05/08/23 17:31:01
良くわからんが、リスコフの置換原則は負の可変性をできる限り無くしましょうって話じゃないのか？
親クラスの振る舞いをキャンセルする子クラスが無いようにしましょうって
349:270
05/08/23 19:24:20
>>347
継承はis aの関係でなくてはいけないってのが
そもそもだから、上と下両方でしょうね。
俺はリスコフの原書じゃなくて
R.マーチンの『アジャイルソフトウェア開発の奥義』で
初めて知ったんだけど
兎に角親クラスだろうと派生クラスだろうと
何が来ても正常に動作するように設計するのが
よろしいって話でした。
350:仕様書無しさん
05/08/23 19:26:29
「派生 is a 基本」はいいけど、「基本 is a 派生」はなりたたないんでね？
351:350
05/08/23 19:27:22
んなこたわかってるね。失礼しました。
352:252
05/08/23 19:43:07
>>349
上と下と両方なのか。了解でし
最初の例に戻るけど、「ロボット」に「鉄砲を撃つ」メソッドを付けることはできないんだから、
このメソッドは、たとえ置換原則に反してでも「ガンダム」に付けるのが正しい設計なんじゃないかな
無理してトリッキーな事するよりも、よほど自然な設計だと思うけど
353:仕様書無しさん
05/08/23 20:33:14
ロボット::指を動かす();
ガンダム::ビームライフルを撃つ()
{
if( ビームライフル != NULL )
{
指を動かす();
;
}
}
354:270
05/08/23 20:41:42
>>352
そうですねー。ドラえもんも道具をポケットから出すし、
それで「出す」メソッドに抽象化してみたんですけど、
やっぱり直感的じゃないですな。
まあ俺の考えるLSPにのっとった設計の例、って事で許して下され。
元々のロボットクラスの例がネタだし。
355:仕様書無しさん
05/08/23 22:02:52
俺はメイヤー先生の本で最初に知った
メイヤー先生はAssertion大好きなのでBaseクラスのメソッドのAssertionをパスする入力は
派生クラスのAssertionも通らなくてはいけない。
同じようにBaseクラスのメソッドが約束する振る舞いは派生クラスのメソッドも満たさなくてはいけない
という原則をうたってたなぁ
これは数学的だなとおもったよ
356:仕様書無しさん
05/08/23 22:54:35
専門学校で本格的なOO教えるとこ
なんかあんのか？
OOに限った事じゃないけど、独学ばっかりで
なんのために学校通ってたのかわかんなく
なってたよ。
357:仕様書無しさん
05/08/23 23:11:04
あらゆるジャンルの専門学校で役に立つとこってほんとにあんのか
358:仕様書無しさん
05/08/23 23:25:14
>>357
学ぶ人間の資質が一番重要だが、
スペシャリストを輩出する専門学校はそれなりにあるよ。
でも殆どはゴミ生産工場。特ににコンピュータ関連は酷いね。
359:仕様書無しさん
05/08/23 23:35:43
俺は現役専門学校生だけど俺が通ってる学校は
せっかく2年間もあるのに内容を薄く薄く伸ばした授業しかないよ
そんな授業にもついていけてない連中がSE、プログラマーとして内定取ってたりするの見てて
プログラマーになるの怖くなったよ。趣味が一番なのかな？
360:仕様書無しさん
05/08/23 23:36:29
書いてから気づいたが思いっきりスレ違いだな…スマン
361:仕様書無しさん
05/08/24 10:22:42
>>359
まあ大抵は実務をこなしながらスキルアップしていく訳だけど、
人間性も含めプログラマとしての最低限の資質を兼ね備えてない奴は
デスマ引き起こしたり精神患ったりしてるわな。
362:仕様書無しさん
05/08/24 10:39:05
スキル不足だけが原因の長時間残業は、デスマとは呼ばないけどね
363:仕様書無しさん
05/08/24 14:22:48
派生 基本という用語がでているが
UML命名規則に従って統一しないか
派生する, 継承, 拡張 -> 汎化
派生 -> サブクラス
基本 -> スーパークラス
メンバ変数, フィールド, プロパティ -> 属性( 注 : C#の属性と間違えないように !)
メンバ関数, メソッド, サブルーチン -> 操作