07/04/03 22:38:06
は？ 俺は>>196じゃないよ。
おじゃばのあの口調こそ自演をカモフラージュするためのものかもな。
201:仕様書無しさん
07/04/03 22:39:12
「俺と高弘の間をジャマするな」が主張だからねー
誤解の無いように。
202:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/03 22:46:43
どっかからソースをコピペしてきてちょちょいと書き換えて使うのを何パターンつうの？
代表的なプログラミング技術なのに どの本見ても載ってないの
203:仕様書無しさん
07/04/03 22:49:22
>>202 ココ電球パターン。最近2chで知られるようになった。
204:仕様書無しさん
07/04/03 22:55:30
ココ電とおじゃば以外は、全部伊賀の人です。
205:仕様書無しさん
07/04/03 23:00:05
age進行？いいねぇ
206:仕様書無しさん
07/04/03 23:07:09
,.――-､
ヽ /￣￣￣｀ヽ、
| | （・）｡（･）|
| |＠＿,.--､_,> 甲賀者には負けられないでござる
ヽヽ＿＿＿ノ の巻
207:仕様書無しさん
07/04/03 23:10:41
そろそろ法則追加だな
208:仕様書無しさん
07/04/03 23:43:32
ファイルを読んでDBに書き込む
この場合クラスにするのはどれですか？
教えてエロい人
209:仕様書無しさん
07/04/03 23:53:19
ファイルを読んでDBに書き込むクラス
210:仕様書無しさん
07/04/03 23:53:51
おじゃばの中身のカスに詫び入れさせてきたｗ
奴はデスマ関係者にも詫び入れるべきだと思うけど
211:仕様書無しさん
07/04/03 23:56:51
>>209
真面目に答えれ。
212:仕様書無しさん
07/04/04 00:38:10
デスマ先生スレ
213:仕様書無しさん
07/04/04 00:48:37
たかひろ、たかひろ
うるさい奴等ウザイ
氏ね
214:仕様書無しさん
07/04/04 00:54:25
デスマ先生ご乱心？
215:仕様書無しさん
07/04/04 01:14:51
>>214
いちいち、くだらない事書き込むな
氏ね
216:仕様書無しさん
07/04/04 01:23:49
法則発動しまくりんぐ
もしかしてこれﾌｧﾋﾞｮｰﾝ ？
217:仕様書無しさん
07/04/04 01:41:42
御本人様火病り中ですか・・・
218:仕様書無しさん
07/04/04 02:10:37
デスマ先生がまだ頑張ってるぞ
おまいら応援行ってこい
ｽﾚﾘﾝｸ(tech板)l50
219:仕様書無しさん
07/04/04 02:24:08
#define private public
#define protected public
220:仕様書無しさん
07/04/04 02:27:30
>>178
俺が言っていたのは「方針と実現の分離」だ。
ビジネスロジックを疎結合に構成する方法として、
マイクロカーネルパターンの特徴「方針と実現の分離」を採用すれば良い
という文脈で、それを出したのだ。
おまえはいい年をして初心者騙して
醜態晒すんじゃねぇ。
221:仕様書無しさん
07/04/04 02:28:23
成り済ましって、だいたいこんな感じでおｋ？
222:仕様書無しさん
07/04/04 07:46:47
いつまでたっても、負けると将棋板ひっくり返すジジィだな高弘
223:仕様書無しさん
07/04/04 11:51:11
>>184
>みんなばらばらのこと話して分散の研究か？
ｗﾜﾛﾀ
224:おじゃばさま
07/04/04 19:58:49
>223
いや面白くない。
アーキテクチャパターンがオブジェクト指向と直接の関係がないと言う事が分かって、
たかひろが意図的に話題をずらしているだけだ。
225:仕様書無しさん
07/04/04 20:15:07
>>224＝おじゃばさま＝高弘
自問自答乙
226:おじゃばさま
07/04/04 20:42:30
>225
何だ俺を「たかひろ」や「伊賀知己」にして、自分はいなかった事にしたいのか？
俺は俺以外に人がいるのは分かるし、俺は他人に自作と思われようと全く気にしないから無意味だぞ。
で、もういいのか？
アーキテクチャパターンとOOは直接は関係ないと言うのは分かったか？
227:仕様書無しさん
07/04/04 20:43:45
ヒント：おじゃば知性90%ダウン
228:仕様書無しさん
07/04/04 20:44:49
ヒント：この子はおじゃばの役回りを理解できていない
229:ﾜﾛﾀ
07/04/04 20:47:40
ﾜﾛﾀ
230:仕様書無しさん
07/04/04 21:14:15
>>227 やあ、伊賀知己
相変わらず、すばやい粘着レスだな感心するよ
231:仕様書無しさん
07/04/04 22:54:07
マジメな質問で恐縮なんだけど、大体、main関数自体がOSの提供する
スレッドん中で動いてんのに、OSやライブラリの提供するスレッド機
能使わないってどういうこと？ ユーザプロセスでレジスタとか、ス
タックとか切り替えられんの？ ま、知らんで聞いてるが。できても
えらい面倒くさそうだな。こんなん簡単にできたらマジ尊敬するよ。
232:仕様書無しさん
07/04/04 22:54:57
あ、まちがった。おさんスレの方だった。ま、いっか・・・
233:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/04 22:56:44
Ｊａｖａの場合はＪａｖａのグリーンスレッドのほうが安定してるから。
234:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/04 23:25:00
ああ、あと、スレッド自作するのは
各スレッドを１：１で平行動作させたい場合だな。
235:とおりすがり・おさん
07/04/04 23:32:12
>>231
マルチスレッド・プログラミングではまった人が居ると聞いたので、
内部機構を考えてもらうネタとして考えた。
まずは安全牌の解。
デバッガのステップ実行割り込みのメカニズム使えば、
任意のポイントとタイミングで、レジスタ退避/復帰と実行ポイント変更と
スタック切換ができる。(こっちは概要調べただけで書いた事はない)
今なら例えばcygwin のgdbソースでも追っかけりゃ判るはず。
欠点は、gdbには詳しくなれるけど、マルチスレッド勉強には重過ぎる点。
次はもっと簡単だけど、かなりいい加減な方法。
後で書く。
236:とおりすがり・おさん
07/04/04 23:42:48
後で書く、とかいうとまた腐れが騒ぎ出して鬱陶しいんで、
要点だけ書いとくと、
・ノンプリエンティブ・マルチスレッドにする。(都合のいい時にしか切り替えない)
・レジスタ変数は一切使わないオプションでコード吐かせて(要コード・チェック)
レジスタ退避の事は一切忘れる。
(直前の実行ポイントは必ず、タスク切換関数の呼び出しスタックに保存される)
・スタック切換は、アセンブラで複数のスタック切換を書いてもいいんだけど、
それ以外のやり方として、スタックは一本にして、それを分割して使うやり方がある。
スタックポインタの操作は、alloca()関数とreturn駆使すればCで記述できる。(要コード・チェック)
237:とおりすがり・おさん
07/04/04 23:47:22
一番重要なポイント書き忘れてた。
・自作スレッドで実行させる関数上では、外部ライブラリ/OS機能は一切使わない。
(動作検証が面倒になって、「原理を学ぶ」という主旨に反するから)
238:仕様書無しさん
07/04/04 23:48:12
ほぇ～、なんか難しそうだけど、要はできるっつうことね。
そういえば、デバッガでもレジスタ弄れるもんなぁ。
メリットがいまいち分からんが、こんなん書ける奴はよっぽど
のマゾだな。コリャ。
239:仕様書無しさん
07/04/04 23:48:28
要コードチェックって何のコード？
240:とおりすがり・おさん
07/04/04 23:53:15
>>239
アセンブラのコード見て、
・「レジスタ変数退避が不要」にちゃんとなってるか （コンパイラオプションが正しいか）
・「スタックポインタの操作」が意図どおりちゃんと書けてるか (プログラマ側の責任)
をチェックしる
241:とおりすがり・おさん
07/04/04 23:55:31
言い忘れ。
簡単なレジスタ退避なら、setjump()使えばできるでしょ。
なんか32bit化の時に入った、OS向けの特殊なフラグは取れないかもだけど。
242:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/05 00:58:44
アセンブラで書けばいいだろ。
器用なことするな
243:仕様書無しさん
07/04/05 06:33:37
OOはどこいった？
244:仕様書無しさん
07/04/05 07:26:57
「奴」は当分、２ちゃんを見る気がしねぇんじゃねぇのか？
245:とおりすがり・おさん
07/04/05 08:15:47
>>236補足
・スタック切換～ベースポインタ操作だけは、Cじゃなくアセンブラを使う必要がある。
246:おじゃばさま
07/04/05 09:51:00
とりあえず、Cスレッドの話はおさんスレに任せるとして、OOの話に戻るか。
247:仕様書無しさん
07/04/05 12:46:14
また詐欺師か
248:仕様書無しさん
07/04/05 14:09:28
>>226
お前が誰かなど (一部の粘着ｸﾝを除いて) 興味などない。
ただ、
莫 迦 は 黙 っ て ろ。
249:おじゃばさま
07/04/05 18:59:51
>248
じゃ結局何が言いたいんだ？煽りとかじゃなくて、マジわかんね。
これだけ説明しても変わらないって事は、自分の意見が正しいと思っているって事だよな？
で、馬鹿な俺から皆を守り、正しい道に導くために戦ってると言うなら、その行動も納得出来る。
で、アーキテクチャパターンとOOの関係について、まともな回答をもらってないのだが。
方針と機能は違うとか、例を示しただけだとか。
248の断片的な主張を強引につなぐと、
「アーキテクチャパターンにある設計で作ることが、オブジェクト指向である」
と言うように聞こえるのだが、そう言いたいのか？
250:248
07/04/05 19:06:06
>>249
新ｽﾚになって初めて書き込んだ俺に訊くことか？
いつも思うことなんだが、
「自分以外はすべて同一人物として扱う」って
一種の心の病だよなあ。
251:仕様書無しさん
07/04/05 19:15:47
日本語でおｋ
252:仕様書無しさん
07/04/05 19:17:23
また、コテ忘れてるよオイ。
253:おじゃばさま
07/04/05 19:52:18
>250
誰？新スレで最初に書き込んだ内容が248？うーむ、なんだかわからんな。
まあいいや、248は見なかったことにするから、249も忘れてくれ。250も忘れるから。
254:仕様書無しさん
07/04/05 19:55:15
コテつけたり外したり、おじゃばさまも忙しいな。
255:仕様書無しさん
07/04/05 19:57:05
２ちゃんの荒しには三種類居る。
Type1. 池沼。
スレの議論内容を一切理解できないにも関わらず
昼夜を問わず延々何ヶ月もスレに常駐し、スレとは無関係な話や
目的不明な自作自演、成りすまし、罵倒発言や落書きを繰り返す、
一種の精神異常者だ。
[対策]スルー、コテハン化、ID制導入
Type2. 撹乱者(天然系、愉快犯系、etc.)
スレの内容や議論の目的をある程度は理解した上で、
瑣末な間違いや疑問でいちいち揚げ足取りをとったり、
参加者が同意している筈の議論の大前提を否定する事で、
議論を空転させ参加者を疲弊させ、最終的に議論の目的達成を阻む。
天然系の無意識発言が原因となる事もあるが、
その多くは、議論好き人種の愉快犯系的犯行である。
[対策]議論の前提/目的/経過/マナー等の再確認
Type3. 利害関係に基づくコミュニティ破壊者(嫉妬系、確信犯系、etc)
これが一番性質が悪い。
コミュニティの情報交換と価値創造に嫉妬心を抱いたり、
自らのハッタリ商売が成立しなくなるのを異常なまでに恐れて、
参加者を撹乱し/疲弊させ/やる気を失くさせ、コミュニティ崩壊を画策する輩。
Type3犯は手段としてType2, Type1を行って潜在荒しを扇動するが
動機と目的の邪悪さ・悪質さによって他と判別される。
256:仕様書無しさん
07/04/05 20:01:08
Type3犯罪者の発言事例
535 名前： 仕様書無しさん 投稿日： 2007/03/26(月) 22:56:55
みんな文句言って叩いていいものが出てこないかと待っている感じが滲み出ていて
笑える
俺としては、なぜ只で教える必要がある？って感じだ
まして２ｃｈでとかありえない
このスレが発端で２ｃｈネラーがOO得意になったりしたら市場価値は台無しだ
中には少しはわかっている奴もいるようだが、そこのところよく考えて発言するように
540 名前： 仕様書無しさん 投稿日： 2007/03/26(月) 23:05:25
>>538
違うな、『発言したいなら市場価値が上がるような権威のある場所でしろ』ってことだ
お前らはOOと2chが結びついて幸せなのか？
そこんとこよくドメイン分析するように
257:仕様書無しさん
07/04/05 20:14:55
python関連スレで2月中旬～3月下旬に沸いたデザパタ荒し厨、
こいつはType2～Type3だ。
隔離前後の本スレでのやりとりや、
中断後のやりとり(>>274-275,>>484,>>488-545)を見れば、
必然性や合理性に欠いており、その真意の程が図りかねる。
Haskellスレで3/31～4/1に沸いた実用言語厨も
同様にType2～Type3だ。
258:仕様書無しさん
07/04/05 20:46:28
147 ：仕様書無しさん ：2007/04/03(火) 18:56:31
>>145の書き込み 2007/03/09(金) 02:02:26
>>146の書き込み 2007/03/26(月) 15:32:13
わずか16日間の間に、このスレにどのような劣化が発生したのか？
誰か説明よろ
148 ：仕様書無しさん ：2007/04/03(火) 19:04:36
・アホコテ2匹＋αが荒らしまくった
・>1がアホだった
いじょ
152 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/04/03(火) 19:23:45
俺がいつ荒らしたよ
議論に負たＯＯちゅが「荒らしだ荒らしだ」って騒いでるだけだろ
153 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/04/03(火) 19:26:24
基幹コテがいなくなると寂れちゃうし
259:仕様書無しさん
07/04/05 20:49:06
皆スルーしてんだからいちいち触るな
260:仕様書無しさん
07/04/05 20:52:09
>258
わざわざあぼ～んされてる文章掘り返すなよ…にしても
> 基幹コテがいなくなると寂れちゃうし
寂れっつーか、落ち着いた議論であって欲しいのだがな。
261:仕様書無しさん
07/04/05 20:53:40
じゃあ皆様、そろそろオセロ作りに戻りましょうか
262:仕様書無しさん
07/04/05 21:00:28
おじゃば、ココとか伊賀（版画？）、どいつも
名無しに向かって同一人物扱いするところが異常だ。
２ちゃんの流儀は連続して話したいときのみコテなりレス番つけるんだから
勘ぐりで話を続けるのが異常。
複数レスの発言者の同一性なんてはなからないのに、
なんで脳内で作るかなぁ
263:仕様書無しさん
07/04/05 21:12:27
Type3荒しの発言事例
--------------------------------------------------------------------
535 名前： 仕様書無しさん 投稿日： 2007/03/26(月) 22:56:55
みんな文句言って叩いていいものが出てこないかと待っている感じが滲み出ていて
笑える
俺としては、なぜ只で教える必要がある？って感じだ
まして２ｃｈでとかありえない
このスレが発端で２ｃｈネラーがOO得意になったりしたら市場価値は台無しだ
中には少しはわかっている奴もいるようだが、そこのところよく考えて発言するように
--------------------------------------------------------------------
540 名前： 仕様書無しさん 投稿日： 2007/03/26(月) 23:05:25
>>538
違うな、『発言したいなら市場価値が上がるような権威のある場所でしろ』ってことだ
お前らはOOと2chが結びついて幸せなのか？
そこんとこよくドメイン分析するように
--------------------------------------------------------------------
python関連スレで2月中旬～3月下旬に沸いたデザパタ荒し厨、
こいつはType2～Type3荒しだ。
隔離前後の本スレでのやりとりや、
中断後のやりとり(>>274-275,>>484,>>488-545)を見れば、
必然性や合理性に欠いており、その真意の程が図りかねる。
--------------------------------------------------------------------
Haskellスレで3/31～4/1に沸いた実用言語厨も
同様にType2～Type3荒しだ。
--------------------------------------------------------------------
同様にデザパタスレで行われた議論妨害もType3荒しだ。
264:仕様書無しさん
07/04/05 21:12:43
そうすると自分の仮想敵のイメージを固定しやすいからでそ
265:仕様書無しさん
07/04/05 21:15:44
今日も平和だな～
266:ﾜﾛｽ
07/04/05 21:19:11
-憂鬱なプログラマによるオブジェクト指向日記 過去ログ-
ＤＱＮのなかにも、どうしようもないＤＱＮというものがいる。
満足に食事すら与えなかったり、虐待を繰り返したりと、
親としての素質に欠ける人が確実にいる。
「親資格」なんてものを作って、親になれる人間を選別すれば、
残酷な家庭内での事件も減るだろう。
しかし、それは危険な思想だし、別な意味で残酷な世界だ。
ＤＱＮに生まれても、途中でＤＱＮから脱出できるような教育を施せる社会が、
今のところは現実的で、そして効果のある方法だろう。
ＤＱＮから子どもを産む権利を剥奪すれば、ＤＱＮ再生産を防ぐことはできる。
267:仕様書無しさん
07/04/05 21:33:14
ひょっとしてアンテナ100本立ってる？
268:ﾜﾛｽ
07/04/05 21:35:05
ネタがワンパターン
しょーもねぇガキだな
269:仕様書無しさん
07/04/05 21:44:02
面白い？
270:仕様書無しさん
07/04/05 21:58:38
スレタイのｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの
からすると、未だに非ｵﾌﾞｼﾞｪｸﾄ指向開発が主流ってことかな
お舞ら、OODなんてやってないのか？
実はお舞らって、DQN指向開発まんせーじゃね
271:仕様書無しさん
07/04/05 22:06:04
面白い？
272:仕様書無しさん
07/04/05 22:10:46
今日は、伊賀知己はまだか
273:仕様書無しさん
07/04/05 22:17:02
ＶＢってさ、一部、オブジェクト思考でないの？
テキストボックスとか、ラベルとか。
274:仕様書無しさん
07/04/05 22:23:52
ありゃ、コンポーネント嗜好を追求してんじゃね
別名ポトッペッタ嗜好とも言う
275:仕様書無しさん
07/04/05 22:31:24
ＪＡＶＡとＶＢ系って、どっちが勝ちますかね？
１０年後・２０年後、どっちが残ってるでしょうか？
276:仕様書無しさん
07/04/05 22:41:34
２～５年後
JAVAがメジャーになりすぎて
VBの開発とかメンテとか移植ができるひとの希少価値が高まる。
１０年後。
別言語にJAVAの資産は受け継がれる。
VBのサポートは打ち切られるが、VBerの希少価値は高まり続ける。
２０年後
VBerは国宝級に崇拝される。
277:仕様書無しさん
07/04/05 22:45:13
補足
１０年後はC#が帝王として君臨
２０年後、しらね
278:仕様書無しさん
07/04/05 22:59:28
C丼はないだろ
279:仕様書無しさん
07/04/05 23:02:01
Ｃ丼
Ｃ＃
Ｃ♯
280:仕様書無しさん
07/04/05 23:12:15
イベントドンブリ
281:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/05 23:15:19
ＪａｖａはＭＳに捨てられてサーブレットと携帯アプリに特化して生き残ってるだけ
ＪＡＶＡアプリケーションの案件なんてあるの？
282:仕様書無しさん
07/04/05 23:25:23
>>281
現状しかみえてないお前は１０年後乞食になっている。
283:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/05 23:27:28
じゃあなんで５年前のＯＯ厨誰も生き残ってないんだよ？
284:仕様書無しさん
07/04/05 23:28:18
クラスのインスタントを生成するとだな、それがオブジェになるわけだ。
285:仕様書無しさん
07/04/05 23:45:34
さびれて温泉街のようなうらぶれっぷりだな。
286:仕様書無しさん
07/04/05 23:46:43
ＶＢ系(VB/VB.NET)のエキスパートになるべきか、
それとも、他の言語(java/c#)にも手を出すか？
皆さんは、どっち選ぶ？
287:仕様書無しさん
07/04/05 23:52:21
二者択一かよ
288:仕様書無しさん
07/04/05 23:55:33
VBでエキスパートってかｗ
289:仕様書無しさん
07/04/05 23:58:14
JavaとUMLが好きなやつって何であんなにキモいんだろう？
290:仕様書無しさん
07/04/06 00:09:44
ＩＴﾄﾞｶﾀって何であんなにキモイんだろう？
291:仕様書無しさん
07/04/06 00:11:50
JavaとUMLが好きなＩＴﾄﾞｶﾀって何であんなにキモいんだろう？
292:仕様書無しさん
07/04/06 00:14:20
ここに常駐してる人って理由抜きでｷﾓｲ。
293:仕様書無しさん
07/04/06 00:16:28
>>286
両方できて当然。各１日でマスターできなければこの先道はない。
294:仕様書無しさん
07/04/06 00:16:46
>>292
ここに常駐し、かつ、JavaとUMLが好きなＩＴﾄﾞｶﾀよりマシだろ
295:仕様書無しさん
07/04/06 00:17:23
ねえ、マスター作ってやってよ
296:仕様書無しさん
07/04/06 00:21:05
話題が貧困なちゃねらーほど存在価値の低いものはない。
297:仕様書無しさん
07/04/06 00:31:50
これって本当？
URLﾘﾝｸ(jibun.atmarkit.co.jp)
298:仕様書無しさん
07/04/06 00:35:31
話題が飛躍しすぎててつまんねーよ。
299:仕様書無しさん
07/04/06 00:36:45
コテハンさんもコテハン叩きさんも
そろそろ落ち着いて建設的な話しましょう。
300:仕様書無しさん
07/04/06 00:42:47
つ URLﾘﾝｸ(www.amazon.co.jp)
301:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/06 00:44:32
じゃあマジックナンバーとラベルの誤謬について
302:仕様書無しさん
07/04/06 00:47:49
むしろこっちに詳しく書いてある
つ URLﾘﾝｸ(www.amazon.co.jp)
303:仕様書無しさん
07/04/06 01:07:16
どうも底辺の人が来ちゃってるようだな
304:仕様書無しさん
07/04/06 01:10:23
おまいらループしすぎ
まずはユースケースの有効性について
305:仕様書無しさん
07/04/06 01:12:24
まずは嫁
つ URLﾘﾝｸ(www.amazon.co.jp)
306:仕様書無しさん
07/04/06 11:06:20
ＶＢ系しか知らない男は、
今後、どういう風にスキルアップしていくのが理想？
307:仕様書無しさん
07/04/06 11:15:51
伊賀知己のアホはオサンスレで引き受けるから
おまいらゆっくり楽しめな。たまにはジャワぽんのためになる事をしようと思う。
308:仕様書無しさん
07/04/06 11:59:23
>>304
アクターに目や口を書いて笑いをとる
309:仕様書無しさん
07/04/06 12:41:10
>>307
つ URLﾘﾝｸ(www.amazon.co.jp)
310:おじゃばさま
07/04/06 18:59:14
そういえば誰かがOO型クラス分割の利点を説明しろとか言っていたな。説明しておく。
C言語で非OOプログラミングでコーディングしていて、ずっと仕様変更を繰り返していると、
ソースコードがぐちゃぐちゃになって、結局あるタイミングで作り直しになったという経験はないか？
なんでそうなるのかと考えてみよう。
a()
b()
c()
と関数があり、それに機能で関数を作って、
d()
を追加したとする。
a()、b()でこの機能を使用する場合、多くの場合、a()とb()にはif文が入ってd()を呼び出すことになる。
ここで問題なのは、if文を追加した時点で以前のa()、b()とは処理が違ってしまっていて、
前のようには使えなくなっているという事である。
それにより、別の場所からa()をd()の機能無しで使いたい場合、またa()に新たにif文を追加する事になる。
かくしてこのプログラムはスパゲッティーの道をたどる事になる。
311:仕様書無しさん
07/04/06 19:21:34
ﾊﾟﾛﾊﾟﾛ
312:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/06 19:48:59
物事を自分で考えられる人はＯＯ厨にならない。
いま残ってるのは教条主義者だけだ
313:仕様書無しさん
07/04/06 19:49:53
で？
314:おじゃばさま
07/04/06 20:03:13
ではどうすればいいか？
理想的なのは、a()はd()の機能有りでも無でも使えて、さらにa()には修正が入らない事である。
もしこれが実現出来れば、スパゲティーコードとはオサラバである。
まあ、OOを知っている人なら分かると思うが、OOではa()の拡張、機能のオーバーライドで実現出来る。
ここがオブジェクト指向の最重要点である。やりたいことは単純なのである。
しかし問題がある。
今までの非OOでの組み方でこれをやろうとすると、出来ないのである。
もう少し正確に言うと、出来るのだが間違えても気が付きにくい。
最初は問題なく見えても、変更を繰り返すうちにまた破綻する。
どう組めば破綻しないかと言うと、これがOOを知らない者には理解しにくい。
一言で言えば、抽象化なのだが、これを聞いて分かる人などいないだろう。
まあ、組み方は後で説明するとして、オブジェクト指向の利点は分かってもらえただろうか？
315:仕様書無しさん
07/04/06 20:10:58
だめだこりゃ
316:おじゃばさま
07/04/06 20:14:36
ところで電球はCコードに修正を繰り返して破綻したコードを見た事がないのか？
どうすればこれをなくせるかと考えた事はないのか？
317:仕様書無しさん
07/04/06 20:15:23
誰かどうにかしろよ
この自己主張禿しすぎな勘違いコテ2匹
318:仕様書無しさん
07/04/06 20:15:44
ヒント：モジュール機構さえあればその件はおｋ
319:仕様書無しさん
07/04/06 20:16:12
とりあえずsageろ＞アホコテ共
320:仕様書無しさん
07/04/06 20:16:19
>>317
任せた
321:仕様書無しさん
07/04/06 20:17:09
勘弁してくれよ
こんなの触りたくねーし
322:仕様書無しさん
07/04/06 20:17:28
|＼＿＿＿／|
| .|
| Θ Θ | ／￣￣￣￣￣￣￣
| .| ＜
∈AA∋ ∧∧ ＼＿＿＿＿＿＿＿
（ﾟ‥ﾟ ） （ ﾟДﾟ）
∪∪|＿＿_⊃ ⊃
／|＿_.| |＿_|＼
| | | | ＼_|
| ﾉ ﾉ ＼＿|
＼_ノ| |
| |
323:仕様書無しさん
07/04/06 20:18:35
Haskellの代数的データ型で、クラスインスタンスをメンバ（？）にするにはどうすればいいんですか？
324:仕様書無しさん
07/04/06 20:25:00
トリがついてるだけココ電のほうがましな気がする。
おじゃばってひょっとしてトリップ知らないんじゃないのか。
325:仕様書無しさん
07/04/06 20:26:56
>322
どっちがココでどっちがおじゃば？
326:仕様書無しさん
07/04/06 20:44:55
オブジェクト開発は俺みたいに頭がよくないとできない
327:仕様書無しさん
07/04/06 20:47:54
機能変更のたびに継承しろってか？
どういう覚え方したらこんな独りよがりの考え方になるんだ。
328:仕様書無しさん
07/04/06 21:00:52
|＼＿＿＿／|
| .|
| Θ Θ | ／￣￣￣￣￣￣￣
| .| ＜ OOとは機能変更のために継承をすることである
∈AA∋ ∧∧ ＼＿＿＿＿＿＿＿
（ﾟ‥ﾟ ） （ ﾟДﾟ）
∪∪|＿＿_⊃ ⊃
／|＿_.| |＿_|＼
| | | | ＼_|
| ﾉ ﾉ ＼＿|
＼_ノ| |
| |
329:仕様書無しさん
07/04/06 21:01:04
粘土みたいに手でさわって作れるプログラム言語作ってくれ
330:おじゃばさま
07/04/06 21:02:29
>324
トリ知らない。教えてくれ。
>326
OO出来ますって言う人は多いが、「変更にたびに完成度が増していく」ってのを実感している人は少ない。
これを話しても、仕事が出来て大量にソース組んでいる人しか同意を得られない。
才能だけでも、努力だけでもダメだって事だろ。
>327
それは誤解だ。全ての継承でやれって話ではない。
その方法が状況によって違うから、難しいんだよ。
331:仕様書無しさん
07/04/06 21:09:25
トリップの付け方もわからん
挙げ句付け方をぐぐって調べることも出来ん
そんなアホが説教してもなぁ
332:OJAVAさま ◆Fj1.051clU
07/04/06 21:12:37
|＼＿＿＿／|
| .|
| Θ Θ | ／￣￣￣￣￣￣￣
| .| ＜ 鳥つけてみたよ、すごいだろ
∈AA∋ ∧∧ ＼＿＿＿＿＿＿＿
（ﾟ‥ﾟ ） （ ﾟДﾟ）
∪∪|＿＿_⊃ ⊃
／|＿_.| |＿_|＼
| | | | ＼_|
| ﾉ ﾉ ＼＿|
＼_ノ| |
| |
333:仕様書無しさん
07/04/06 21:39:45
>>323
class Animal a where
call :: a -> String
data Dog = Dog
instance Animal Dog where
call _ = "bowwow"
data Sparrow = Sparrow
instance Animal Sparrow where
call _ = "cheep"
data AnimalH = forall a. Animal a => AH a
animals = [AH Sparrow, AH Dog, AH Sparrow]
main = mapM_ (putStrLn . (\ (AH x) -> call x)) animals
334:仕様書無しさん
07/04/06 21:41:42
・・・まあ確かに構造化言語においては
仕様変更に対応するために、そのプログラムの構造から変更しなくてはならないケースはある。
そうしないと（このスレ流行の言葉で言うと）破綻するからね。
でも継承とか委譲（とか「なんちゃらパターン」）の使い分けがわからない。
>>330
「状況によって違う」というのは、
「確立した方法論は無い」とか「経験則しかない」と解釈してよいのか？
335:仕様書無しさん
07/04/06 21:43:59
ヒント：その件はモジュール機能導入でおｋ
336:仕様書無しさん
07/04/06 21:45:35
>>323
存在量化(existential quantification)を使わない方法。
data Animal = Animal { animalCall :: String }
dog :: Animal
dog = Animal { animalCall = "bowwow" }
sparrow :: Animal
sparrow = Animal { animalCall = "cheep" }
animals :: [Animal]
animals = [sparrow, dog, sparrow]
main = mapM_ (putStrLn . animalCall) animals
クラス階層が必要ないなら、こっちが扱いやすいと思う。
337:333
07/04/06 21:47:24
animals :: [Animal]
animals = [AH Sparrow, AH Dog, AH Sparrow]
-- www
338:仕様書無しさん
07/04/06 23:00:47
このスレには実は3人の住人しかいない
339:仕様書無しさん
07/04/06 23:04:16
その３人とは>>338、>>338の脳内のお友達、>>338の別人格、の事である
340:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/06 23:25:21
かわいそうなＯＯ厨の人たち・・・
341:仕様書無しさん
07/04/06 23:50:36
自覚が無いって恐ろしいな
342:仕様書無しさん
07/04/07 00:59:56
>>341 おまいもしっかり自覚するように
343:仕様書無しさん
07/04/07 01:55:37
１つのファイルに数種類のレコードが１行以上存在するとした場合、
そのファイルを解析して３つのテーブルを更新するものとする。
この条件に最適なクラスとインターフェースを全て挙げよ。
IT/○ro課題より
344:仕様書無しさん
07/04/07 06:20:45
オブジェクト指向以前に、利用する掲示板のFAQも読まない奴が
技術者面して他人に教えをたれようとすんな。糞。あげ。
>URLﾘﾝｸ(info.2ch.net)
345:仕様書無しさん
07/04/07 06:52:26
使いこなせず負け犬の遠吠えを繰り返すアホコテが1匹
使いこなしたつもりで勘違い講釈を続けるアホコテが1匹
何をやらせてもアホはアホのままって見本みたいな奴らだったな
346:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/07 09:37:41
>>343
なにその糞問題
作ったやつ馬鹿じゃねーの？
347:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/07 09:44:26
問題は３行目だ
作るのか？作るんだったら俺クラスあげたって名前みんな違うからしょうがないし
ライブラリ引っ張ってくるだけのものを言ってるのなら それだけのやつって事だな。
この条件に最適 ってのもＤＱＮ的に意味不明だな
「この条件でプログラムを組む場合使うクラス」なら判るが
さらに「最適」っておまい決められるのかよ
348:仕様書無しさん
07/04/07 11:16:44
>>343
俺はOODはイマイチよく解らんが
思い付く限りでやってみる。
数種類のレコードってことは
複数のレコード形式が雑じったファイルかな？
テーブル３種は甲乙丙と名付けたとして…
このファイル形式を扱うクラス
レコードインターフェース
各レコード形式のクラス
テーブル基底クラス
甲クラス
乙クラス
丙クラス
349:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/07 12:13:30
テーブルと１：１でクラス作るのは、初めて組んだときやったけど
効率悪いわ、結合が増えてモジュールが破綻しそうになるわでやってないな。
Ｊｏｉｎ文なんかつかえないわなー
おこちゃまプログラミング
350:仕様書無しさん
07/04/07 12:20:06
テーブルとクラスを１：１にしていいのはASP.NETだけ
351:仕様書無しさん
07/04/07 13:11:17
TableModuleとかいうパターンだな
352:仕様書無しさん
07/04/07 19:55:33
再利用は不効率だから
353:仕様書無しさん
07/04/07 19:56:29
不幸率ってなんだよ非効率だろ
354:仕様書無しさん
07/04/07 20:12:29
非行率ってなんだよ国公立だろ
355:仕様書無しさん
07/04/08 02:30:28
ねえねえココ電球～～
356:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 03:40:55
はい？
357:仕様書無しさん
07/04/08 04:06:03
>>356
/＼＿＿_／＼
／'''''' ''''''::＼
|（へ）, 、（へ）、.| ふふ、呼んでみただけ♪
| ,,ノ(、_, )ヽ、,, .:|
| ｀-=ニ=- ' .:::::|
＼ ｀ニニ´ .＿／
（｀ー‐--‐‐―/ ）.|´
| | ヽ|
ゝ ノ ヽ ノ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
358:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 05:10:46
うー
359:仕様書無しさん
07/04/08 09:58:22
電球は、徹夜だったのか？
歳なんだから無理するなよ
360:仕様書無しさん
07/04/08 10:51:21
さぁ、ザリガニのスーパークラスは、カニか？エビか？ どっち？
361:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 11:37:51
Ｃだと多重継承が許されるのです
362:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 11:44:20
思い出したが、結合の概念はずっと前から持っていた。
自分の頭の中で連結と読んでいたけど、
データベースのデータには確率的にぼやけているデーターがある。
量子力学の電子の雲の図を思い浮かべてもらうといい。
不確定性状態のデーターを参照しているデーターも不確定となる。
リレーショナルＤＢがＯＯと相性が悪いのはＯＯが不確定性データーを扱えないからともいえると思う。
363:仕様書無しさん
07/04/08 11:57:55
nullってあるじゃん
364:仕様書無しさん
07/04/08 12:01:45
不確定な仕様しか出せないから不確定要素とかいう表現が出てくる
要件が確定してたらザリガニはエビかカニかなんていうどうでも良い名詞並べたいだけの考え方なんて出てこないよ
365:仕様書無しさん
07/04/08 12:05:20
SQLのNULLは「不明(unknown)」「非適用(not applicable)」の意味で使われます。
366:仕様書無しさん
07/04/08 12:25:42
今のOOではクラスの構造は設計時に決まってしまうため、
AクラスとBクラスから、両方の属性を併せ持つCクラス
を動的に生成できないからな。
SQLでは結合や射影を使って何通りものオブジェクトを動
的に生成できる。所謂パラダイムミスマッチ。
367:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 13:04:53
ちげーよ
マルチクライアントだと常に誰かがデーターを変更している可能性があるから
今読んだデーターが次の瞬間もデータベース上のデーターと一致しているとは限らないということ。
368:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 13:07:35
Ｊａｖａでも動的生成はできる。
プログラムでソースコード吐き出してコンパイラ呼んでＣｌａｓｓクラスで取り込むんだったとおもう たしか
369:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 13:08:21
ＪＩＴってのもあったな。
わすれたが
370:仕様書無しさん
07/04/08 13:46:24
データベースの排他処理はOOとは別問題
371:仕様書無しさん
07/04/08 13:51:54
>>361
Cだと継承できねーよ
C++だろ。正確になっ。ココナッツ電灯。
372:仕様書無しさん
07/04/08 14:49:56
どうでもいいけど
「データー」はねーって
↑
変な読み方スレ逝け屑コテ
373:仕様書無しさん
07/04/08 15:22:28
>>367
ダーティリード、反復不可読み取りの例か。
更新ロックで回避しても、他が待ちになってつかえるから、
中間表でもマスタでもいいが、タイムスタンプカラム、更新フラグカラムを作るわけだな。
374:仕様書無しさん
07/04/09 13:15:09
昔から「データー」という椰子にハイスキル無しは有名
375:仕様書無しさん
07/04/09 17:21:44
昔から揚げ足取りにハイスキル無しは有名
376:仕様書無しさん
07/04/09 17:27:16
>>375
はつみみです。
377:仕様書無しさん
07/04/09 18:35:51
昔からOO厨にハイスキル無しは有名
378:おじゃばさま
07/04/09 19:03:07
>334
最初は継承だけ知っていればいい。委譲だのデザインパターンなどは知らなくてもいい。
継承すら最初に継承を考慮して設計する必要もない。変更修正すると継承が必要になってくるので、
そこで使えばいい。
デザインパターンに当てはめればOOだと言うのは間違いだ。いまだにそう考えている人がいるが、
それは耐震素材を使えば、耐震建築物になると言っているのに等しい。
確立した方法はないとか、経験則しかないと言うのもちょっと違う。
重要なのは抽象化なのだが、確かに確立した方法（こうすべき）と言うのは俺も見つけていない。
しかしOOの方針（こうした方が良い）と言うのはあり、それで十分だ。
なぜならOOは修正範囲が狭いので、ある程度間違えていても後から修正が効く。
修正を繰り返せば抽象化が進み完成度が増す。だから「方法」より緩い「方針」で十分だ。
方針は説明しても「OOを理解している人にしか分からない」事が多くて意味がない。
だから俺は学習手順を教えている。内容は前にも言ったが、また今度説明しよう。
379:仕様書無しさん
07/04/09 20:46:33
だからトリつけてこいよ。おじゃばさま何人もいるとわかったんだろ。
えらそうに講釈たれる前にそっからだ
っても、おじゃばさま、がJava厨の共同コテならしかたないわなｗ
380:仕様書無しさん
07/04/10 06:49:05
オブジェクト指向ができてきた理由も価値もわからずオブジェクト指向オブジェクト指向と言ってるだけだからだよ。
かつての構造化プログラミングのときのgotoのようだ。
結局、頭を使って組んでるやつは、なにを使っても保守性汎用性の高いプログラミングをしている
381:仕様書無しさん
07/04/10 09:31:17
で、「ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？」については、OO語りは寝言ばっかりだからなのか？
382:仕様書無しさん
07/04/10 13:43:59
そもそも手法の一つとして使うものなのに
流行る流行らないで見てる時点でおかしいわな
383:仕様書無しさん
07/04/10 14:06:10
毒デムパコテ常駐スレ
詳しくは >>196
384:仕様書無しさん
07/04/10 23:05:14
ただいまおまいら！
思った以上に伸びててびっくりしたよ。
書いた事以外にも新人の信じられない行動はあるんだ。これを書いたところでネタとしか思われないと思って書かなかったけど書いてみる。
新人の力試すため一番最初にとりあえず基礎的な事をやらせてみてたんだ。
Hello Worldを出力、メソッド分け、条件分岐記述、ループ記述とかやらせて見て、どこまでできてどこからできないってのがわかったら教えなきゃいけない部分がわかると思って。
んでやらせてみたら怪しい書き方ながらもなんとかHello World出力は書けた。
俺「んじゃあ…今のちょっと怪しかったから自分の名前と年齢出力する記述を改行も使って書いてみ。」
新「えっと、よくわからないんすけど、なにからやるんすか？」
俺「とりあえずメソッド書いて」
新「はい」
カタカタカタ…
新「書きましたけど」
俺は愕然とした。そいつのディスプレイにはソース内にもろにカタカナで「メソッド」と打鍵されていたんだ。
Eclipseから露骨に赤文字で指摘されてるんだ。
そこで俺はこいつが前職でJAVAをやってたのが嘘だと確信した。
これを読んだおまいらの中には「それ絶対ネタだろ」とか思う奴もいるだろうが、
紛 れ も な い 実 話
385:仕様書無しさん
07/04/11 00:27:43
新人の概要が先に欲しかった
初心者ならそんなもんだろとおも
386:仕様書無しさん
07/04/11 11:16:04
派遣でJava経験ありでそういうのが来ることもないとはいえないのがこの業界
387:おじゃばさま◇jpaavsas
07/04/11 20:46:31
>380
まさにその通りだ。
>381
OOは説明できなくても、感覚的にマスターしている人は多い。
そのため、流行っていると言うよりは、普及していると言えるだろう。
寝言が多いのは、引退SEや営業が偽コンサルをやっているためだろう。
>382
その通りだ。
仕様が明確で変更が少ないシステムなら、非OOの方が効率がいい場合も多い。
388:おじゃばさま◇jpaavsas
07/04/11 20:48:57
新人についてならこんな伝説を聞いた事がある。
上司「今日から新人が来る。パソコンは得意と言う話だ。」
先輩「そうですか楽しみですね。」
次の日----------------------------------------------------
新人「よろしくお願いします。」
先輩「これが君のマシンだよ。」
10分後----------------------------------------------------
新人「あのー、これどうやって電源入れるのでしょうか？」
先輩「え、電源ボタンはこれだけど．．．パソコン得意なんじゃないの？」
新人「スーパーマリオなら得意なんですけど。」
先輩「．．．それってファミコンじゃん。」
389:仕様書無しさん
07/04/11 21:11:08
なぁ、コイツこれでトリつけたつもりなの？
流石に笑えんのだが。
390:おじゃばさま ◆Fy0HoitUDw
07/04/11 22:13:14
偽者出現か。
しようがない奴だな。
>>387
身分詐称で通報しますた。
391:仕様書無しさん
07/04/11 22:44:32
おじゃばさまは身分なのか
392:仕様書無しさん
07/04/11 22:52:22
＞おじゃば、他エロい人
OOでのDBテーブル操作方法を初心者な漏れに教えてちょ
１．テーブル１つに対してクラスを１つ作った方がいいの？
２．結合の場合はどうすんの？
３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
393:仕様書無しさん
07/04/11 22:58:49
＞１．テーブル１つに対してクラスを１つ作った方がいいの？
>>350
＞２．結合の場合はどうすんの？
場合による
＞３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
使うな
394:仕様書無しさん
07/04/11 22:58:52
１．日本では一夫一妻制です。
２．感染症予防に気をつけましょう。
３．組み手は48手あります。あまり追求しないようにしましょう。
395:仕様書無しさん
07/04/11 23:52:28
>>391
ｗｗ
396:仕様書無しさん
07/04/11 23:53:40
>>393
>使うな
その理由を、説明できるもんなら説明願います。
397:仕様書無しさん
07/04/11 23:58:15
>>396
じゃあ使え
398:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/12 00:12:37
>>396
１） 遅い。 劇重。 重さ１０倍。（当社比）
使ったシステムは後で必ず後悔しているが、変更箇所が膨大になるので直せない。
２） テーブル名をキーワードに探したりすると漏れる。メンテナンスが把握できない場合がある。
399:仕様書無しさん
07/04/12 01:11:07
>>392
OOでのDBテーブル操作方法を初心者な漏れに教えてちょ
Ｑ１．テーブル１つに対してクラスを１つ作った方がいいの？
Ａ１．違う。パラダイムに沿ってクラスを作る。
テーブルが１つになることもあるし複数になることもある。
Ｑ２．結合の場合はどうすんの？
Ａ２．お好きに。
Ｑ３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
Ａ３．呼び出し元言語でハードコーディングしなくて良いようにするのがよい。
400:おじゃばさま
07/04/12 14:36:32
>392
まず、オブジェクト指向とSQLデータベースは相性が悪いと言う事を認識しておく必要がある。
そのため効率の悪い実装をしなければならない所があるが、そこは割り切る必要がある。
>１．テーブル１つに対してクラスを１つ作った方がいいの？
結果から言うと、テーブル1つに対してクラスは2個にするのが無難だ。
クラス2個と言うのはSQL実行用のクラスと、1レコード格納用のクラスだ。
OOの基本から言えばクラスは誰かが言っていた「パラダイム毎」になり、SQL実行用とレコード格納用
クラスは分けるべきではないだろう。しかし「パラダイム毎」と言うのは分かりにくく、
SQL実行用とレコード格納用クラスが1つになった物は、別の所で使いにくい。ここが相性の悪い所だ。
ここは割り切って、次のように設計する。
401:396
07/04/12 14:36:39
>>398
あー、あんたは答えなくていい。
402:仕様書無しさん
07/04/12 14:38:43
>>400
>SQLデータベース
なんだこりゃ。
403:おじゃばさま
07/04/12 14:51:45
「厳密なオブジェクト指向ではないではないか！！」と言われれば、確かにその通りだ。
実際にはもっとオブジェクト指向の書き方もあるが、実用性を考えて妥協している。
// レコード格納用
class RecUser{
private int id;
String name;
public int getId(){return id;}
public void setId(int i){id = i;}
public String getName(){return name;}
public void setName(String n){name = n;}
};
// SQL実行用
class ExeUser{
public int executeInsert(RecUser rec){...}
public int executeUpdate(RecUser rec){...}
public int executeDelete(RecUser rec){...}
// 検索用
public boolean executeSelect(...){...}
public RecUser next(){...}
// 一括検索用
public List executeList(...){...}
};
DBのopenやcommitなどはクラスを作成し、SQL実行用クラスのベースクラスにするといい。
検索に「検索用」と「一括検索用」があるのは、メモリ使用量を考慮しての事だ。
本来なら一括検索で全部リストに格納したいが、検索結果が数万件になったり、大量に同時アクセスが
想定される場合は、内部でResultSetを保持した「検索用」を使う。
404:おじゃばさま
07/04/12 14:55:09
>402
SQLのような文章解析型の制御を使ったDBを、SQLデータベースとした。
OOと「文章解析型の制御」は相性が悪い。同様の物にprintfなどがある。
405:仕様書無しさん
07/04/12 14:56:39
Factory+TableでDIパターンだろ
406:仕様書無しさん
07/04/12 15:18:14
うん、そーやって自分自身のフレームワークを作る努力は大切だ。がんばれ
407:仕様書無しさん
07/04/12 15:30:20
おじゃばさま製O/Rマッパに期待わくわく。
おじゃばさま ◆Fy0HoitUDwとは違うおじゃばさまなのか？
408:仕様書無しさん
07/04/12 15:34:55
>>404
俺用語使うな間抜け。
つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。
409:仕様書無しさん
07/04/12 15:58:21
結合に関しては、例えば100(record)×100(record)の検索より
100の中間表(もしくはview)を2つ作ってからスキャンかけたほうが、元のデータベースのパフォも総合的にみたパフォもいい(viewは大雑把に言うとメモリ上だから)。
更に、
begintrans→中間表作成→検索→更新→commit(rollback)
とやると、他のアクセスが詰まったりするので、
元表に更新(中)columnと、更新クライアント名column、(場合によって、更にタイムスタンプcolumn)。そして、
begintrans→中間表作成→元表の更新columnに更新フラグを立て、更新クライアント名columnに自分の番号(名前)を入れる→ここで一旦commit→あとはゆっくり中間表検索&更新処理→終わったらフラグを下ろす。
(更新フラグが立っているので他は更新できないルール(トランザクションのロックではない))。
この一回トランザクションを切るやり方はデッドロック回避にも使える。
また、別のやり方として、更新フラグ表(マトリックス表)見たいな表を作っておいたて似たような動作をさせたり、更にこれを自動化できるレプリケーションを使う手もある。
(そういえば、wait for graph(待ち合わせグラフ)とかいうデッドロック検出用のマトリックスを積んだDBもあるとかないとか)
410:仕様書無しさん
07/04/12 17:11:59
動作が糞遅い。
411:仕様書無しさん
07/04/12 17:59:59
誰も聞いてくれない話をここに放出して、気持ちよかったか？
412:おじゃばさま
07/04/12 18:22:37
>407
上記構造は実用的だが理想には遠い。個人でさらに良い方法を研究することを望む。
また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。
>408
>つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。
すまんが、何を言いたいのか分からない。
>409
OOの話とは関係ないが、巨大な中間表の結果から更新をするような設計自体が間違いの可能性が高い。
WEB等で途中に人の入力が介在する場合は、更新日時によるチェックを行うが、それ以外でフラグ等による
更新チェックを行う場合は少ない。まあ実際の使用例を聞いてみないと分からないが。
適切に正規化されている場合は、検索結果で更新する事はまれだし、適切にテーブル分けしてあれば、
レコードロックによる更新で影響を受ける範囲は少ない。
413:おじゃばさま
07/04/12 19:15:00
>392
>２．結合の場合はどうすんの？
簡単な結合の場合は、格納クラスと実行クラスをそれぞれextendsして、ベースクラスに項目を追加して
使用する。複雑な結合の場合は、新たにそれ専用のクラスを作る。
>３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
まずストアドを使う意味を確認しておこう。
ストアドの利点としては、大量の検索を伴う集計処理や更新処理で使用する事により、
ネットワーク上を流れる大量の検索結果やSQL文を軽減する事にある。
参考までに、欠点はデバックが困難だということだ。
ちなみに、現代の高速ネットワークの上では、ストアドの利点はあまりない。
誰かが使うなと言った人はそのためだろう。
使う場合は、大量のまとまった処理に使う。数個のパラメータを渡して、ストアド内部で処理を行い、
ロールバックやコミットも内部で行い、結果をOK/NGで返すぐらいにするのが望ましい。
そうなると呼び出し側は1つの普通のクラスで構わない。
414:仕様書無しさん
07/04/12 19:45:59
なんだよ。また口だけか
415:仕様書無しさん
07/04/12 21:48:35
オラクルのストアドの作り方って、
SQLサーバーと似たようなもの？それとも、全然違うの？
416:仕様書無しさん
07/04/12 22:41:25
インスタンスとオブジェクトの違いってなんすか？
417:仕様書無しさん
07/04/12 22:53:56
>>409
バージョンカラム使った楽観的排他と比べてどうなん？
418:仕様書無しさん
07/04/13 00:16:14
＞また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。
まあ、いろいろまずいからごまかしてる、でおｋ？
パスワードｗとやらは変えればいいじゃないか？
同一人物では困る事情でもあるならべつだけどねｗ
で、O/Rマッピングはうまくできたのかな？
419:仕様書無しさん
07/04/13 01:24:31
>416
オブジェクト：
オブジェクト指向における基本単位。「もの」の意味。
文字列だったり、リストだったり、型だったり、数値だったり
ボタンだったり、テキストボックスだったり
クラスだったり、メソッドだったり、何かのデータだったりする。
インスタンス：
あるクラスを基にして作られたオブジェクト。
「文字列クラスのインスタンス」なんて言ったりする。
420:仕様書無しさん
07/04/13 01:41:33
オブジェクト指向以外禁止だからキツイ。
最近になって解ってきたけど多態性がポイントだな
421:仕様書無しさん
07/04/13 06:55:25
>>392
データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア
開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で
データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が
数多く巻き起こっている。
アプリケーション開発者の多くはRDB のことを裏側に隠しておくのにちょうどいいストレージ
装置だと思いがちだ。
URLﾘﾝｸ(capsctrl.que.jp)
422:仕様書無しさん
07/04/13 06:57:31
> 同一人物では困る事情でもあるならべつだけどねｗ
同一人物だけど、同一人物ではないと思ってほしいだけだろ。
素性はバレバレだがｗ
423:仕様書無しさん
07/04/13 07:04:25
マーチンの言うトランザクションスクリプトには、
ピン(凝ったＳＱＬやストアドプロシージャ使いまくり)から
キリ(構造化プログラミングで処理を書きまくり)まで
いろいろなケースが含まれる。
424:仕様書無しさん
07/04/13 08:32:41
>>423
そだね、今はSQLJとかC#ストアードプロシージャとかパススルーあるしね、Martin Fowlerは
あらかじめOOPSにバイアスを掛けた見方（偏った？）を前提に、あの文章を書いてると思う
手続き型プログラミングでも問題が無いところを、わざわざロジックとデータロード操作と
切り分けて同一ソースへのアクセスの際の利便性を強調しているが、1度しか使用され
ないデータ抽出と集計するロジックを別クラスとした場合、見る人により不明瞭だろう
>>413
OODの問題として捕らえると1：1もしは1：Nとした場合の爆発的なクラス増加と、継承を
使用する前提とした場合の見通しの悪さがある、一般的にプログラマーは同じ処理を他人
より短く速く短時間で書ける事を誇りにするから、継承を使いたがる気持ちが分からないでもない
確かにいまどきは1：1で設計するのがほとんどであろう、ただ結合の場合においてはそのやり方では
疑問が残る、パフォーマンスとソースのメンテナンス性はトレードオフではないのだからOOP以外の策も
今後考慮されるべきであろう
>>398
簡潔すぎると一般の人には分かりませんよ・・
425:仕様書無しさん
07/04/13 09:16:07
きみの文章はヘタクソだ
要点を簡潔に書く訓練をしたまえ
426:仕様書無しさん
07/04/13 09:19:14
妄想を暗黙の了解事項として書くから
主旨の読み取れない意味不明な文章になるのだと思う
427:仕様書無しさん
07/04/13 09:34:59
いいから藻前ら句読点つけろ。
428:おじゃばさま
07/04/13 09:41:32
>416
広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。
オブジェクト=クラス=型
インスタンス=値
つまりクラスがオブジェクトで、クラスをnewしてメモリ確保したのがインスタンス。
429:仕様書無しさん
07/04/13 11:53:17
まだ鳥の付け方もわからんのか
流石アホコテ
430:おじゃばさま ◆Fy0HoitUDw
07/04/13 12:10:48
私は愚か者です
首吊ってきますｗ
431:仕様書無しさん
07/04/13 12:14:26
>URLﾘﾝｸ(rina.nadenade.com)
＞中には「クラス=オブジェクト」というなかなか理解しがたい解釈をされる方もいて、
＞この人がまたソフトを飯の種にしているっぽいので頭が痛いです(笑)。
w
432:仕様書無しさん
07/04/13 12:21:44
>>415
も答えてください。
オラクルの現場、何故か、当たった事ないのです。
433:仕様書無しさん
07/04/13 12:30:35
あるひとは「もの」の本質は「おなじようなものを集めた集合」にあるといい
また別のあるひとは「もの」は「おなじようなものを集めた集合に属する要素」だという。
どちらも正しい。
しかし、「もの」とは「おなじようなものを集めた集合」そのものに等しいなどという戯言は
笑止千万
434:おじゃばさま ◆Fy0HoitUDw
07/04/13 12:31:21
愚かですいません
435:仕様書無しさん
07/04/13 12:45:42
ラッセルもﾋﾞｸｰﾘ
436:仕様書無しさん
07/04/13 13:35:12
>URLﾘﾝｸ(book.geocities.jp)
＞前出のようにクラスを具現化したものはオブジェクトですから
＞インスタンスはオブジェクトを指して使う言葉という事になります。
本当にあ(ry
437:仕様書無しさん
07/04/13 14:32:09
URLﾘﾝｸ(www.google.com)
438:仕様書無しさん
07/04/13 14:32:20
「クラスを具現化したもの」なら「インスタンス」の方が適切だな
439:仕様書無しさん
07/04/13 14:32:47
>>436
お前があ（ｒｙ
440:仕様書無しさん
07/04/13 14:37:57
>>438同意
おバカさまはクラス・オブジェクトが存在するような言語では
クラス⊂オブジェクト
なのを知って、クラス＝オブジェクトという妄念を得たのではないか？
441:仕様書無しさん
07/04/13 15:06:14
>>415
シカト？
442:仕様書無しさん
07/04/13 15:15:10
しょうがねえな。
>>415
おまえもｽﾚﾀｲ100回音読の刑に処す。
443:仕様書無しさん
07/04/13 16:54:02
>>おじゃば
おじゃばさまはようやくコテの付け方を覚えたか
おじゃばさまが愚か者であることは皆知ってるから謝る必要は無い
それより、俺愚かだからお舞ら教えろと言った方が良いぞ
444:仕様書無しさん
07/04/13 17:57:05
おいおじゃば、また名前付け忘れてるだろ
445:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/13 21:58:45
>>401
死ねよ
てめーわよ
446:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/13 22:02:25
>>431
じつはＭＳのＶＣ＋＋初期のライブラリのマニュアルではクラスとインスタンスをごっちゃにしてる。
ＭＳのマニュアル読むべし。
ＭＳ自体判ってなかった。
447:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/13 22:07:45
それからＭＳのＶＣ＋＋でコントロールなどを自動生成すると
呼び出し元の情報が埋め込まれてしまって部品化されていない。
そのコントロールをおいたダイアログ上からしか呼び出せなかったりする。
これはクラスの親子関係と呼び出しの親子関係をごっちゃにした結果である。
448:仕様書無しさん
07/04/13 22:24:02
なんつーか詭弁もいいとこだな
449:おじゃばさま
07/04/13 22:31:08
>424
クラスの爆発的増加はシステムによっては発生する。
継承を用いた方式では古典的な名前を用いた分類で対応する。
つまり、クラス名をRecUserExとかRecUserAndProductなどにして、関連性を見せる。
また複雑な結合に対しては、Viewを作成し、そのView名に関連したクラスを作る事でメンテナンス性を
確保する。ただそれほど良い方法でないのも認めているので、OO以外の考慮に対しては異存はない。
>432
SQLサーバの方は詳しくは知らないので、他の人に聞いた方がいい。
ただSQLサーバの方はデバッカも充実していて、他のMS製品とも相性がいいので、PL/SQLほど避ける
必要はないと思う。
>リンク厨
広い意味ではクラスもインスタンスも、オブジェクトなので解釈が分かれる。
だから誰かが間違っていると言うつもりはない。それぞれの意見にはそれなりの主張がある。
ただ、リンク張って満足している輩は、もう少し頭を使う訓練をしたほうがいいと思う。
450:仕様書無しさん
07/04/13 22:50:31
バカ
451:仕様書無しさん
07/04/13 22:59:10
だいたい思い出した、おまえさんの方法論。
ただそれがなんでここまで崩れてボロボロになってるのか、
それはよく判らない。
おまえ結局、大きなトラウマを持っていて、
ネットワーク上で暴れないと気が済まないんだろ。
もうやめておけ。こんな戯れ文書き散らかしても
おまえ自身がボロボロになるだけだ。
452:仕様書無しさん
07/04/13 22:59:31
バカ
453:仕様書無しさん
07/04/13 23:00:18
ﾁﾝﾎﾟ
454:おじゃばさま
07/04/13 23:08:45
>451
誰に言っているのだ？
俺か？リンク厨か？
455:仕様書無しさん
07/04/13 23:10:24
バカ
456:仕様書無しさん
07/04/13 23:11:34
おバカさまﾀｲｰﾎ
457:仕様書無しさん
07/04/13 23:19:33
＿
＼.＼ バカでもチンポでもいいから勝手にやってくれ
|＿|
／ ＼ ／＼＿
| ／ ／ ♯＼＿＿
| ./ / ※ ♯ ※＼＿＿＿＿
／ ,＼＿/ / ♯ ※ ♯ .／ ／
／＿＿＿/ ￣￣￣￣￣￣￣￣￣ ／
458:仕様書無しさん
07/04/13 23:22:39
めんどくせーから全部グローバル変数でいいよ
459:仕様書無しさん
07/04/14 01:20:00
DLLってCとC＋＋（OOスタイル）のどっちで書いた方がいいの？
今の現場でC＋＋わかる人いないんだけど、
できるならC＋＋でもいいよ（保守性などをふまえてて、物ができればなんでもいいよ）、って言われてて。
教えてｴﾛい人
460:仕様書無しさん
07/04/14 01:32:18
アセンブラ
461:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/14 01:33:38
自分の得意なほうでいいんじゃない？
462:392
07/04/14 01:40:19
高度すぎるのかなんなのか分かりませんけど、
ココ電球さんは言ってる忌みがよく分かりません。（何が言いたいのかもなぞです、すみません）
おじゃばさんは叩かれてるけど言ってる忌みは分かります。
＞おじゃばさん、他ヒント頂いたｴﾛい方々
ヒントありがとうです。
まだ迷い中・考え中ですけど、
方向性が見つかったのでうれしいです。
でもストアドはデバッグが大変なのか・・・（知識不足で申し訳）
一度に４万件ぐらいのレコードあるんですが、う～ん・・・
つか、これはスレ違いだからいいっす！サンキューです！
463:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/14 04:37:12
おじゃば自演すんなよ おまい
464:仕様書無しさん
07/04/14 07:50:13
クラス＝オブジェクト、であれば
hogeクラスのfugeオブジェクト
とかいう書き方が日本語としておかしいことになります。簡単ですね。
ひょっとして、おじゃばさまは職場で
boke(クラス名)オブジェクトのkasuインスタンス
などと説明してるんでしょうか･･･それは恥ずかしいんじゃ･･･
465:仕様書無しさん
07/04/14 11:18:06
>>459
俺はC++で書いてラッパー関数作って extern "C" でレギュラーDLLとしてエクスポートしてる。
466:仕様書無しさん
07/04/14 22:35:41
だいたい、「狭い意味でクラス＝オブジェクト(型)」とか言い切って
つっこまれたら「広い意味で全部オブジェクト」かよ。
Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。
「おじゃばさま」って名前はもうやめたら？馬鹿なんだし。
467:仕様書無しさん
07/04/14 22:41:46
あいつあれでも、業務コンサル会社のCEOだそうです。
全然評判聞かないけどｗ
468:仕様書無しさん
07/04/14 22:42:59
は？Javaのクラスはオブジェクトだろ普通に。
Object o = String.class;
469:仕様書無しさん
07/04/14 22:52:18
暇暇コンサル
470:仕様書無しさん
07/04/14 22:53:11
特技：初心者教育
471:仕様書無しさん
07/04/14 23:03:09
知能および性格が著しく劣悪な池沼が
誰かに構ってほしくて暴れているようです。
スルーでお願いします。
472:仕様書無しさん
07/04/15 19:40:36
ロジックのセンスがない椰子がほとんどの業界で
オブジェクト指向など100年早いね。
473:仕様書無しさん
07/04/16 12:55:43
暴れるぞ＾
474:おじゃばさま
07/04/16 12:56:17
>463
自演してない。
一応、電球の発言を簡単に説明しておくと、
446の発言趣旨は言語開発元のMSですら、オブジェクトとインスタンスの定義が曖昧だと言うことで、
447でその例して、オブジェクトの親子関係と、呼び出し元先関係を混同していると言っているのだろう。
>464
何が恥ずかしいのか分からない。
>466
>Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。
466の言うオブジェクトの定義が分からない。俺も468と同意見。
475:仕様書無しさん
07/04/16 16:56:35
それが属しているのがobjectクラスを基底にするクラスであることと、
その属しているクラスがオブジェクトであることは違うだろうよ･･･
本気でわかんないんだな、おじゃば。>468はどーみても釣りだろ。
476:仕様書無しさん
07/04/16 18:33:45
は？Java知ってっか？
Object o1 = new String();
Object o2 = String.class;
477:おじゃばさま
07/04/16 18:55:48
>475
オブジェクト指向の「オブジェクト」を最も良く表した物が、Javaの「Object」だと思うが。
釣りじゃないんじゃね？476でも言っているし。
478:仕様書無しさん
07/04/16 19:38:50
オブジェクト指向は理想と現実のギャップが大きいよ。
479:仕様書無しさん
07/04/16 19:41:52
たとえば？
480:仕様書無しさん
07/04/16 22:39:35
オブジェクト指向におけるオブジェクトの定義が
"コンピュータ上におけるクラスのインスタンス"なんだが。
コンピュータとは無関係に定義される抽象的な対象もオブジェクトって言われるから紛らわしいけど、
まともな本や論文ならオブジェクトはクラスのインスタンスの意味で使われてるよ。
481:仕様書無しさん
07/04/16 22:52:22
クラスもメタクラスのインスタンスなんだぜ
482:仕様書無しさん
07/04/16 22:59:51
Javaで例えるとこうか？
Object o1 = new String();
Object o2 = String.class;
Class c = String.class;
483:仕様書無しさん
07/04/16 23:00:36
実際にプログラミングあんまりしないからわからんが
カプセル化しないとバグ増えたりするのかね
484:仕様書無しさん
07/04/16 23:06:29
ただ単にカプセル化すりゃいいってもんじゃあないな。
オブジェクトがぶっ壊れないように、アクセッサでガードしなきゃ。
485:仕様書無しさん
07/04/16 23:56:12
だからよ。つくんのに、じかんがかかりすぎんだよ。プログラムなんて糞だぜ。
1年かけて作っても、独りよがりのものしか作れ無かったよ。
とっととやめちまえ。
486:仕様書無しさん
07/04/16 23:57:57
>>484の人気に早くも嫉妬
487:仕様書無しさん
07/04/17 00:02:54
遠慮せず突っ込みたまえ。
488:仕様書無しさん
07/04/17 00:05:38
>485
時間が掛かる時に使うと良い感じ。
OOに速さはあんまり求めない方がいいよ。
処理速度も開発速度も。
489:仕様書無しさん
07/04/17 00:20:27
処理速度も開発速度も、現実問題OOとあんまり関係ないよ。
手続き型で書いたRubyと、OOで書いたC++の
どっちが速い？
OOで書いたRubyと、手続き型で書いたC++の
どっちが早くできる？
490:仕様書無しさん
07/04/17 00:23:25
スクリプト言語と・・・
もう帰っていいよキミ
491:仕様書無しさん
07/04/17 00:31:05
>>490
おまえ国語力ないな
492:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/17 00:43:12
アクセッサなんか９９％使わない。
疲れて書かなくなったころ書いたのに必要だったり、上位層で書くの忘れてたのに必要だったりする。
必要になってから書いても遅くない。
493:仕様書無しさん
07/04/17 00:50:14
じゃあRubyでアクセサ無しでコード書いてくれ
494:仕様書無しさん
07/04/17 00:53:10
>>493
グローバル変数【これを君にあげましょう。】
495:仕様書無しさん
07/04/17 00:54:02
>>492
必要になってから書いても遅くないってことは、無いよりあったほうがいいってことか？
496:仕様書無しさん
07/04/17 00:57:12
＞アクセッサなんか９９％使わない。
使わないっておかしいだろ。
フィールドがprivateなら使わざるを得ない。
フィールドをpublicにしても９９％問題ない、ならまだ意味はわかるが。
497:仕様書無しさん
07/04/17 00:59:03
相変わらずOOの「設計」についてはスルーされてんだな
498:仕様書無しさん
07/04/17 01:00:47
だから、
広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。
クラス=型(+メソッド）
オブジェクト=インスタンス=実体（値+メソッド参照)
つまりクラスをnewしてメモリ確保したのがインスタンスでありオブジェクト。
499:仕様書無しさん
07/04/17 01:02:33
オブジェクト指向に設計と実装を隔てる垣根など無い。
500:仕様書無しさん
07/04/17 01:03:36
とりあえずnewしとけばおｋなスレはここですか？
501:仕様書無しさん
07/04/17 01:06:08
SDP原則により、自作クラスはnew禁止な。よく覚えとけ。
502:仕様書無しさん
07/04/17 01:06:20
>>499
とりあえずクラス図ぐらいは書いとけよな
「ソースが最新です」な奴はOOの利点捨てとるやろ
503:仕様書無しさん
07/04/17 01:08:16
>>501
全部クラスメソッドっすかｗ
504:仕様書無しさん
07/04/17 01:08:23
OOの利点って？
505:仕様書無しさん
07/04/17 01:13:49
メッセージ・UML・モデル化
506:仕様書無しさん
07/04/17 01:16:17
>>505
利点か？どうみてもなんかの手段だろ
なんの手段なんだ？
507:仕様書無しさん
07/04/17 01:21:20
OO＝手段じゃん
499が設計をそんまま実装概念に落とせるって話なら
それでいんじゃね？
あんまかみつくなよ。茶でものもうや
508:仕様書無しさん
07/04/17 01:24:24
>>507
わりい。噛み付いたつもりはない。
クラス図書くと何がいいのか、単純な興味から聞いてみただけ。
509:仕様書無しさん
07/04/17 01:30:14
しっかりしたクラス図があった場合、
メンテ・拡張が入る場合にクラス図を見れば、
どこに手を入れればいいかそれなりに分かる。
ソースをいきなり見るような無駄は無くなる。
なんでもかんでもpublicなんてことをやると手間がかかってしょーがない
つか、良識のあるPGはそんなことせんし
510:仕様書無しさん
07/04/17 01:38:56
クラス図メンテのコスト＜ソース見るコスト
って常に成り立つかなあ。ちょっと懐疑的。
オプソなんてクラス図ついてないのばっかだけど、
どこ拡張すればいいかなんてすぐわかるし。
511:仕様書無しさん
07/04/17 01:44:50
そりゃソース見るのに慣れてるだけの話
512:仕様書無しさん
07/04/17 01:50:21
ついでに言えば、OOは手段なだけ。
オブジェクト間をメッセージでつなげる。これが本質。
この分析をモデル化するだけなんやし。
コーディングも設計の一環でコンパイルが製造って言うならまあありかもしれんけど。
513:仕様書無しさん
07/04/17 01:56:09
ケイのほうのオブジェクト指向のメリットはいまだにわからん。
514:仕様書無しさん
07/04/17 01:57:03
さらに寝る前のついでに言えば、
たとえば地図とかのシステム作る場合なんかだと、
地図にもいろいろ種類あって、道路地図・地形地図・分布地図？とかあると思うんやけど
それぞれがクラス化されてればソース見なくても
「地図に信号足して」
なんて話になれば道路地図クラスやな、となんとなく分かる。
grepもいいけどソースだけで業務概念が分かるかどうかは微妙やね。
515:仕様書無しさん
07/04/17 06:06:36
ところで、Java ってスクリプト言語みたいに
MyClass obj = new MyClass();
Class klass = obj.class;
MyClass obj2 = new klass();
みたいな事って出来たっけ？
516:仕様書無しさん
07/04/17 08:59:18
真性のバカと判定
517:仕様書無しさん
07/04/17 10:17:35
>>516
だがBakaクラスのインスタンスにis_baka()をしても「バカじゃない！」って文字列が返ってくるんだろうな
518:仕様書無しさん
07/04/17 13:02:33
>>513
これは読みましたか？
URLﾘﾝｸ(www.purl.org)
キーコンセプトはメッセージングを介した徹底した動的性の追求です。
（現在主流のオブジェクト指向では、意味も分からず「オブジェクトへのメッセージ送信」と
お題目化されたり、ポロモルフィズムに包含されたりひどいことになっていますが…）
他の言語では（動的性に関しては）LISPのそれに近いですね。
言語以外では生物のしくみやネット（特にインターネット）に似せています。
変化に強いシステム（たとえば、止めることなしに走らせつつ拡張したり、
修正できたりする…など）を実現できる…というのが、まあ、メリットでしょう。
たとえば、これを実践しているSmalltalkは30年来、再起動ということを
数えるほどしかしていません。生命、インターネットもしかりですね。
519:仕様書無しさん
07/04/17 14:18:15
手段って。
何を実願するための手段なの？
520:仕様書無しさん
07/04/17 14:53:48
>>515は何でも発想してみるのはいいけど、
そんな簡単なコードは実際に実行してくれ。
少なくとも、newのオペランドは基本型かクラス（又はその配列）であって、
インスタンス（ここではklass）ではない。
521:仕様書無しさん
07/04/17 16:03:35
>>520
もしJavaでクラスがオブジェクトだと言うなら
コレもできるか？と思ってね。
PythonやRubyだと完全にクラスはオブジェクトだから
そういうことが出来てしまう。
そもそもクラス定義文自体が単に
クラス型のオブジェクトが変数や定数に入るだけだし。
522:おじゃばさま
07/04/17 19:21:04
俺はクラス図とかUMLを保守資料として残す意味はないと思っている。
仕様変更が入った場合、最も効率のいい方法は、作った本人に修正させる事だ。その場合、クラス図は不要だ。
「当たり前だ、作った人がいないから問題なんだ！！」と言う抗議が聞こえてくるが、その通りだ。
ここで他人が修正する上で、注意しなければならない点は2つある。
・最初から作るより、ある物を修正する方がスキルが必要。
・知らないシステムを修正する場合は、修正量にかかわらず、ある一定の時間（コスト）が必要。
上記の内容を、ぶっちゃけて言い替えると以下のようになる。
・ソース読めない奴には修正させるな。
・作者とは別の人に修正させる場合は、解析期間を十分に取れ。
と言う事で、結果的にクラス図は不要になる。
ちなみにメンテナンスされない保守資料は不要どころか有害である。
UMLやクラス図はコーディング完了時に破棄するのが望ましい。
523:仕様書無しさん
07/04/17 19:37:38
>>521 リフレクション使えば
MyClass obj2 = klass.newInstance();
という書き方はできる。
524:おじゃばさま
07/04/17 19:42:51
ところでオマエラ、
「要求仕様聞いただけでソースコードが人」とか、
「ソースコード見ると、脳内で実行が始まる人」とかいない？
そういう事ってあるよな？
525:おじゃばさま
07/04/17 19:44:00
「要求仕様聞いただけでソースコードが見える人」な。、
526:仕様書無しさん
07/04/17 19:49:53
Doxygen使えよ。ソースからきれいなクラス図をつくってくれるぞ。ソースから
作るから、当然ドキュメントとしては最新状態が反映されたものになる。
ソースだけ読んで構造理解するよっか、クラス間の関連を掴むには便利。
527:仕様書無しさん
07/04/17 20:06:20
>>523
こうな
MyClass obj2 = (MyClass)klass.newInstance();
528:仕様書無しさん
07/04/17 20:07:44
>>526
それだと細かすぎんだよな。結局ソースみたほうがはやかったりする。
529:仕様書無しさん
07/04/17 20:19:08
クラスが何百もあるシステムの全体掴むのに一からソース読んでると辛くね？
530:仕様書無しさん
07/04/17 20:20:05
>>おじゃば
おじゃばが設計書読まない口頭主義なのは良く分かったが、
UMLはあくまでも分析なんよ。
顧客からの承認はどうすんだよ。結局なんちゃら仕様書ってのを作るんだろ
その一つがUMLなだけ。
それとも何か？いきなりコーディングか？
＞・ソース読めない奴には修正させるな。
＞・作者とは別の人に修正させる場合は、解析期間を十分に取れ。
＞と言う事で、結果的にクラス図は不要になる。
「ということで」、の意味がわからん
要はUMLを使いこなせて無いだけじゃん
531:仕様書無しさん
07/04/17 20:24:28
ソース＝仕様書と言ってるJava厨がいるスレはここですか？
532:仕様書無しさん
07/04/17 20:35:40
オブジェクト指向開発はなぜ流行らないの？スレで
UMLを使いこなせて無いだけじゃん
はないだろ。常識的に考えて。
533:仕様書無しさん
07/04/17 21:31:41
UMLは実装前の設計時「のみ」で使うべき「モデリング」
実装が始まったらどうでもいいです
実装が終わったらrationalやらroseやらdoxygenで抽出
実装と同時にuml書くなんて馬鹿、大馬鹿、死ねって感じｗ
534:仕様書無しさん
07/04/17 21:58:28
死ね。
535:仕様書無しさん
07/04/18 00:32:58
C++って変体言語だろ。
javaかdelphiにしろ。
536:仕様書無しさん
07/04/18 00:35:52
今日は基地が沸いてるな
537:仕様書無しさん
07/04/18 01:25:36
今日は？ 今日もだろ
538:仕様書無しさん
07/04/18 01:36:02
こっちの板はもちろんそれがデフォ。
539:仕様書無しさん
07/04/18 09:42:13
>>533
ラウンドトリップしないの？
540:仕様書無しさん
07/04/18 10:09:16
>>530
相手するだけ無駄。
541:仕様書無しさん
07/04/18 11:07:43
>>530
>おじゃばが設計書読まない口頭主義なのは良く分かったが、
自分は単に「ソースコード至上主義」と読みましたが
542:仕様書無しさん
07/04/18 14:12:33
>>541
>>おじゃばが設計書読まない口頭主義なのは良く分かったが、
>自分は単に「ソースコード至上主義」と読みましたが
自分は単に「統合失調症」と思ってましたが
543:仕様書無しさん
07/04/18 22:43:50
おじゃば、悲惨だな・・
530にあっさり論破され、基地にからかわれ・・
まあ、実力以上の無理せんでガンガレ
544:仕様書無しさん
07/04/18 23:13:43
流行ってるだろ。
545:仕様書無しさん
07/04/18 23:35:00
むしろ大流行かと
546:仕様書無しさん
07/04/19 00:01:17
むしろ大発生だろ おじゃばみたいなしったかが
547:仕様書無しさん
07/04/19 00:11:43
オブジェクト指向のメリットがあるないで未だにもめてるこのスレで
UMLのメリットを自明であるように語るのは明らかに違うだろ。
クラス図を読むのはソース読むことよりかなり難しいのだが、おそらく
それすら知らないで、クラス間の関連がソース読まなくても視覚的に
わかるよわーいなんてレベルの奴らがUMLゆってるだけと感じてしまう。
具体的にUMLのメリットを示すべし。
548:仕様書無しさん
07/04/19 01:03:43
ソースより読みにくいクラス図なんて、むしろいらない。
549:仕様書無しさん
07/04/19 08:39:12
いるいる！>>547や>>548みたいな偽装連中！
自分の勉強不足を棚に上げて「分からない！分からない！」と連呼
ってアランケイがゆってた
550:仕様書無しさん
07/04/19 08:50:22
>>547
クラス図だけ見てわかるような気にさせてしまうのが、問題なのかも。
551:おじゃばさま
07/04/19 09:41:54
>530
顧客からの了承でUMLなんか見せない。
顧客に見せるのは画面仕様書や画面遷移図などになるが、それもサンプル画面を作った方が正確で早い。
まあ、提出書類は決まっている場合も多いから、作らなければならない事も多いが、コーディング先でも
全然問題ないな。
UMLは新人や新しく入った人にプログラムを説明する時とか、複雑な処理を整理して考える時などに
使っている。UMLで顧客に説明？クラス図とかシーケンス図とか見せて説明するのか？
逆に聞きたいのだが、画面仕様ならともかく、顧客にクラス図やシーケンス図見せて分かるのか？
>531
「ソース＝仕様書」だよ。
何かおかしいのか？
>533
同意
552:仕様書無しさん
07/04/19 09:59:20
沖縄県の方へ（命に関わる注意事項です）
沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度 沖縄」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…
※一国二制度
簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
そして中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。
今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。
553:仕様書無しさん
07/04/19 10:10:07
>>549
>自分の勉強不足を棚に上げて「分からない！分からない！」と連呼
>ってアランケイがゆってた
kwsk
554:仕様書無しさん
07/04/19 11:46:00
>551
お前読解力ねーな・・・マジで
あとトリップつけろって
何回言われてもできないとかアホの典型か
555:仕様書無しさん
07/04/19 16:14:51
「ソース＝仕様書」
は正しい。
しかしながらその正論が通るところは少ないね。
556:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/19 19:06:39
ソースに仕様を全部書く
557:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/19 19:07:13
贅沢は言わないからマジックナンバーにコメントふってくれや
558:仕様書無しさん
07/04/19 19:57:12
お前は今すぐ死んでくれや
559:おじゃばさま
07/04/19 20:59:59
>554
理解力？何が言いたいのか分からないな。
俺が保守ドキュメントにUMLは不要だと言ったのを、554が全てのドキュメントが不要だと言ったと
勘違いしたのか？
ところでOOでメッセージがどうのとか言っていた人がいたが、何の事？
560:仕様書無しさん
07/04/19 21:13:55
むかしむかし、あるところに、OOでメッセージがどうのとか言っていた人
がおったそうな。
561:仕様書無しさん
07/04/19 22:23:44
オブジェクト同士のメッセージのことだろ
普通じゃん
さすが仕様書読まない奴だけあるなｗｗ
562:仕様書無しさん
07/04/19 22:42:35
>>551
うちは顧客にもUML（PJ内での拡張版）で説明する。
確かにサンプル画面は見てくれだけなら速いが、詰めが甘い。
そこでUMLで業務分析をした上で了承を取らんと。
コーディングが先でUMLを後で作るって時点で、おかしいだろ。
なんで分析ツールがあとで出てくるんだ？後だしならいらんし。そんなもん見らんわ。
つかさあ、担当者変わったあとでカスタマイズが入る度にソース全部追っかけてんのか？
めんどくない？
ソース＝仕様書ってのはオッケーだと思うが、
そのソース（仕様書）の分析をせずにコーディングするんだろ？
そこが謎。
あと他の奴も言ってるが、偽者うっとーしいからトリつけてくれや
563:仕様書無しさん
07/04/19 22:57:29
要求仕様書→UMLモデリング→顧客へ確認OK？→実装→だろ？
564:仕様書無しさん
07/04/19 22:57:53
クラス図でも、分析モデルと実装モデルとは用途がちがうぞ。
565:仕様書無しさん
07/04/19 23:01:11
UMLって描くのめんどいね
566:仕様書無しさん
07/04/19 23:02:40
>>563
スレタイ【OOD/P】の意味わかるか？
567:仕様書無しさん
07/04/19 23:03:36
話題沸騰ポットを知ってるか？
568:仕様書無しさん
07/04/19 23:08:39
>>566
OOAの話題はおいや？
569:仕様書無しさん
07/04/19 23:11:38
>>568
どうぞ
570:仕様書無しさん
07/04/19 23:15:49
OOD⊇OOAなんだけど？
571:仕様書無しさん
07/04/19 23:16:44
ポットの水とかお湯とかって本質的に不要だろｗ
572:仕様書無しさん
07/04/19 23:29:57
全然おもしろくないｗ
573:仕様書無しさん
07/04/19 23:31:13
ｗついてるやん
574:仕様書無しさん
07/04/19 23:35:01
>>559
お前まさか読めんのか？
「読解力」だよ
575:仕様書無しさん
07/04/20 11:41:34
>>559
>何が言いたいのか分からないな。
ばかだからでは？
576:仕様書無しさん
07/04/20 12:44:32
核心を突いてやるなってｗ
577:おじゃばさま ◆GxjxF3yEw6
07/04/20 22:53:29
>575
575の意見を思考停止という。
575はただの煽りとしても、思考停止を確信と核心する576には脱力だな。
まあ馬鹿じゃないんだろうけど、考えない癖がついているんだろうな。
でも何も考えない方が幸せになれるから、それはそれでいいのかもしれない。幸せになれよ。
578:仕様書無しさん
07/04/20 22:55:46
厨房だな・・・・
579:仕様書無しさん
07/04/20 22:57:15
アドレナリン中毒の愚かな野生動物だからな。
580:仕様書無しさん
07/04/21 00:38:13
>577
おもしろくありません
もうすこしがんばりましょう
581:仕様書無しさん
07/04/21 01:18:03
何だかんだ言って、技術ってすぐに過去のものになっちまうよな
582:仕様書無しさん
07/04/21 01:26:46
とはいえ今ある技術について行かなきゃ、次の技術が理解できないしな
583:575
07/04/21 01:42:47
>>577
そう、ただの煽りです。
でも、見たままの感想ですよ。
自分では気づいていない (莫迦故に) でしょうけれど。
>思考停止を確信と核心する
ほら。
584:仕様書無しさん
07/04/21 01:46:12
つまらん
585:仕様書無しさん
07/04/21 01:52:40
鳥付けてんのは偽もんだろ
モノホンは鳥も付けれんほど馬鹿だから
586:仕様書無しさん
07/04/21 02:02:47
アドレナリンからかうと面白いな。
アフォな事言い出してる所に水を向けると
10も20もレスを返してくる。
心にゆとりがないというか、
愚かで劣等感に苛まれている可哀想な人というかｗ
587:仕様書無しさん
07/04/21 02:06:05
おじゃばが食いつけそうなネタふることさえ出来なくなっちゃったの？
かわいそうにｗ
588:仕様書無しさん
07/04/21 02:46:25
・基本的にスルー力が足りないのだと思う。
・「荒しに反応するのは荒し」という経験則が、
荒し検出に非常に有効である事が再確認できた。
・同様に「キ○○○という単語に過剰反応を示す奴は、
たいてい本人がキ○○○」という経験則が得られた。
589:仕様書無しさん
07/04/21 03:12:24
オブジェクト指向で説明せよ
590:仕様書無しさん
07/04/21 03:19:09
猫はにゃーにゃーと鳴き
犬はわんわんと鳴き
蝙蝠は黙して語らなかった
591:仕様書無しさん
07/04/21 10:40:03
キチガイ、キチガイ、キチガイ、これがオブジェクト思考でつ
592:仕様書無しさん
07/04/21 11:03:19
VIPと間違えた。
593:仕様書無しさん
07/04/21 17:30:29
オブジェクト指向での製造方法を学ぶためには、
どういう点に注意したらいいですか？
クラスやインスタンスや継承など言語技術は理解していますが、
どうしても機能重視になってしまいがちで、
本質的に間違ってるという気持ちがあります。
594:仕様書無しさん
07/04/21 17:36:46
ほんとにやる気あるなら、メイヤーのオブジェクト指向入門よめ
595:仕様書無しさん
07/04/21 17:38:56
>>593
使う言語に応じてチームが使いやすいように設計すればいいよ
オブジェクト指向に本質とか意味ないし
但し一人よがりな設計はやめよう。チーム全体で理解出来るようにね
って書くと口だけで実践ともなってない奴とかがしゃしゃりでてくるんだろうけどなww
596:仕様書無しさん
07/04/21 19:04:00
なんだ似非コンサルの事か。
自覚症状があるならさっさと引退すればいいのに。
597:仕様書無しさん
07/04/22 07:56:46
>>581
技術って集中を分散の間を
ぐるぐる回っているだけだから、
止っていたら戻ってくるよ。
598:仕様書無しさん
07/04/22 09:31:34
シンプルに考えることを常に心掛けること。
デザインパターンが素晴らしいのもシンプルな考え方だからだね。
流行りものは、そこから概念だけを見切って、自分のフォースに取
り込むこと。がんばれ。
599:仕様書無しさん
07/04/22 09:45:26
「概念だけを見切って、自分のフォースに取り込む」＝半島人が俺様解釈でパクる行為のこと
600:仕様書無しさん
07/04/22 10:06:34
俺様解釈が新しいパラダイム生む。
601:仕様書無しさん
07/04/22 10:30:46
池沼の戯言
602:仕様書無しさん
07/04/22 11:37:15
最初からＯＯで入るからでしょ。
ＯＯが生まれた理由も価値もわからず、ＯＯを習うから結局、ＯＯが生まれることになった原因と同じような
ことを繰り返している。
gotoレスが叫ばれた時代と同じ。なにも考えずなにも疑問に思わないやつが使ってるから結局、元の木阿弥。
603:仕様書無しさん
07/04/22 15:13:56
価値が分かるの４０代？
604:仕様書無しさん
07/04/22 16:41:40
そんなことないだろ、新興会社でなきゃ、古い顧客も抱えてるから自然に触れるだろ過去のシステムも
605:仕様書無しさん
07/04/22 17:23:46
ウインドウ＝スレッドと思ってる香具師。
606:仕様書無しさん
07/04/22 20:05:01
モードレスダイアログのウィンドウプロシージャって別スレッドだっけ？
607:仕様書無しさん
07/04/22 20:31:16
だめりゃコリャｗ
608:仕様書無しさん
07/04/22 21:15:29
>>602
なんで伏字なんだよ。
と誤解されるのが日本で流行らない理由だな。きっと。
609:仕様書無しさん
07/04/22 21:16:48
せめて半角英数で書けばいいものを
610:おじゃばさま ◆GxjxF3yEw6
07/04/23 09:50:46
>593
言語仕様を理解しているなら次は「物をクラスで表現する事」だ。
まあ概念を説明しても今までと同じになってしまうので、実装方法から説明しよう。
機能で考えるてしまうと言うので、非OOでのC言語は理解していると仮定する。
まず構造体の要素を、クラスのprivateのフィールド変数に定義する。
次にそれぞれの変数のゲッターセッターを作る。そして機能毎に考えていた関数を分解して、
ゲッターとセッターの中に入れ込む。ちなみに機能毎に考えていた関数と、入れ込むゲッターは1:1に
なるとは限らない。どうしても入らない部分は、適当なメソッドを作って入れておく。
すべてのクラス分けが終わったら、一旦休憩した後に、もう一度クラスを見直す。
この時にクラスに相応しくないフィールド変数やメソッドがないか確認する。
例えば「商品クラス」に「顧客」の情報が入っていないかなどの確認だ。
ここで相応しくないと思った変数やメソッドは、相応しいクラスに移動する。適切にメソッドを作って
あれば、フィールド変数と関連するメソッドの移動だけで済む。ここでメソッドを移動しようとすると
別の変数を参照していて移動出来ないとか発生するが、これがうまくメソッド分けされていない部分である。
もう一度その部分を考え直して分離する。分離した時に前より複雑にならないように心掛ける。
611:仕様書無しさん
07/04/23 10:09:54
堕ちコン
612:おじゃばさま ◆GxjxF3yEw6
07/04/23 19:30:33
次に重要なのは「仕様変更を繰り返す」事だ。仕様変更を行う度にクラスを見直す事になるが、
正しく抽象化されていると、変更を繰り返しても構造が悪化しない。
悪化どころか、仕様変更の度に抽象度が増して、洗練されて行くのを感じるようになるだろう。
まあ、これを体感出来るようになるのは、普通の人で1～2年ぐらいかかるから焦る必要はない。
ちなみにデザインパターンや専門書は、上記の抽象化をマスターしてから見た方がいい。
抽象化も知らずにいきなりデザインパターンや専門書を見て、OOを理解出来る人などいないと思う。
613:仕様書無しさん
07/04/23 21:25:09
で？
このコテの文章って冗長なだけで
主観ばっかで何が言いたいかわからん
614:仕様書無しさん
07/04/23 22:28:40
作文だろ。文章能力を2chを使って養ってんだと思う。
素養の無さからくる整合性の欠落や、曖昧さ、そして中々上達
しないその様は見ていて痛々しいが、本人も一生懸命らしい。
ま、ほっといておいてやれ。
多分、この人の周りには、彼以上に優秀な人がいないのだろう。
そういう環境に長年浸って、自分を人一倍優秀だと勘違いして
しまったのだと思う。ある意味可哀想ではある。
615:仕様書無しさん
07/04/23 23:53:44
>>610
private変数のゲッターやセッターを作るんだったら
最初からpublicにすればいいと思ったのですが、
何か間違っているでしょうか？
ゲッター・セッターメソッドがづらづらと並ぶことにもなりますし、
変数が直接触れない以外、メリットがよく分かりません。
616:仕様書無しさん
07/04/23 23:55:51
>>610
アクセッサにロジック入れるのかよ(゜д゜)
617:仕様書無しさん
07/04/24 00:01:57
>>615
いやそうじゃない。private変数にはカプセル化の利点がある
いまさらそんな事言うまでもないがな。
つまりだ、お前は根本的に考え方が間違っている
りかい出来るまでは、オブジェクト指向の本を読みあさるんだ。
だんかいを踏んで、徐々に理解した方が今後の為にもなる。
なん度も繰り返しオブジェクト指向で考えれば必ず身に付くから。がんがれ
618:仕様書無しさん
07/04/24 00:06:43
>>617
レスありがとうございます。
ゲッターとセッターはprivate変数１個に対して１つずつ書くのですか？
これはカプセル化はカプセル化ですが、必要性がよく分からず・・・
private
int a;
int b;
public
getA();
getB();
setA();
setB();
619:仕様書無しさん
07/04/24 00:11:14
オブジェクト指向の本を読みあさった俺でも、
setter、getterをづらづら並べ、それをカプセル化言うのは何かが違うと感じる。
620:仕様書無しさん
07/04/24 00:20:08
気分的にはもうちょっと壊滅的に壊れてほしいな
ずいぶん手間隙かけたんだし
621:仕様書無しさん
07/04/24 00:23:39
つーか、どこの莫迦が getter/setter なんて発想をし始めたんだろう。
インスタンスの「状態」を戻す、あるいは変更するのが目的なんだから
内部変数と対応している必要なんざこれっぽっちもないってのに。
622:仕様書無しさん
07/04/24 00:27:58
>>621
入れ物として使われ始めたのはbeansからじゃね？
623:仕様書無しさん
07/04/24 02:59:00
極論すれば、Publicにするのは、インターフェースに限定するのが理想的。
内部変数はPrivateにして、公開しないのが原則。しかし場合によっては、
クラス内部でカウントされた値や、集計値などを公開する必要があるだろう。
その場合は、その値を、ゲッターとして実装し公開する。セッターはそのク
ラスの要件として必要な場合に限り公開する。
セッターは、グローバル変数に匹敵するぐらい危険な要素を孕んでいるこ
とを認識するべき。常に外部からの変更の可能性を考慮しないとならない
ため、人がコードを読む際にかかるストレスも大きくなる。private変数は
クラス外部からの変更の可能性は排除できるので、スコープを絞って集中
してコードを追うことができる。またメンバ変数は、そのクラスの機能を実現
するための必要最低限のものだけにするべき。当たり前だが、計算に使う
一時変数等をメンバ変数にしてはいけない。これもコードの可読性に関わっ
てくる。不要な情報は極力排除し、クラスのメンバとするべきではない。
OOの手法は開発時というより寧ろ、変更や保守性、拡張性といった方面での
貢献が大きいものだと思う。ゲッター、セッターを使うことで、値の代入に
対する仕様の変更があった場合に、その対応ロジックを１箇所に集中するこ
とができる。ゲッター、セッターを使わず直接代入していた場合、その代入
箇所すべてを変更しなければならないかもしれない。いわば事前にかけてお
く保険みたいなものだ。変更や保守がされないソフトウェアというものはな
いのだから。
624:仕様書無しさん
07/04/24 03:24:29
つーか、そんなに直代入使うか？
OOPやってると、セッタ自体滅多に使わないと思うんだが。
625:624
07/04/24 03:45:06
ちと言葉足らずか。
単に値チェックして代入するだけのセッタなんて使うか？
って訂正しとく。
626:仕様書無しさん
07/04/24 09:15:50
様々な言語で提供されるほとんどの文字列クラスにセッターがないことに気づいているか。
文字列長？ そんなもの内部で適切に管理されている。中身を変更したい？ copy-on-writedだ。
つまりよい設計とはそういうものだ。必要の無いものは提供しない。よく分からないけどこの
メソッドはPublicにした方がいいかなぁ。と思うならPublicにするな。公開する時は信念をもって
公開しろ。無計画にメソッドやプロパティを公開してはならない。徒に混乱の種をばらまくような
ものだ。
627:おじゃばさま ◆GxjxF3yEw6
07/04/24 09:51:46
>615
ちょっと説明が足りなかったようだ。
確かに値を設定／取得するだけのメソッドなら、publicにしたのと変わらないと思うかもしれない。
しかしそれは慣れないうちは最初にそうした方がいいと言う事で、作った後から要らない物は削除したり
統合したりして構わない。
例えば、セッターが10個あるとしよう。もし文字列を読み込んで分解して、それぞれを設定する場合しか
なかったとする。その場合いはセッター10個を削除して「void setRecord(String rec)」の1つにしてもいい。
また、設定ファイルを表すPropertyFileと言うクラスを作ったとする。
内容は「No:RECORD」が数十行続くレコードだったとしよう。
読み込みはファイル、取得はNoを指定してRECORDを取得するだけだとする。
その場合、セッターを全て廃止して「boolean read(String fname)」にして、ゲッターを
「String getRecord(int no)」の1つに集約してもいい。
慣れているならゲッターやセッターを作らずに、最初からこれでも良い。
これが進むと変数が隠蔽され、抽象化が進む。
628:仕様書無しさん
07/04/24 10:32:35
腐れコテがコテを付けたり外したりしながら独り言を書くスレ
629:仕様書無しさん
07/04/24 11:51:28
相変わらず主観だらけで冗長なだけ
挙げ句どっちかっつーと個人の感想止まりやんｗ
630:おじゃばさま ◆GxjxF3yEw6
07/04/24 19:16:08
>629
うるせーバカ。少しは頭使え、カス。
と、簡潔に書いてみた。
631:仕様書無しさん
07/04/24 19:19:37
de?
632:仕様書無しさん
07/04/24 19:25:47
>>630
うるせーバカ。少しは頭使え、カスキチオジャバ
633:仕様書無しさん
07/04/24 19:30:43
>>627
そのような”機能分類”したメソッドが存在するのは
すでに今まで自分でもうやってた手法です。
レコード文字列渡して必要なところだけセットする、とか。
もちろんprivateにするべきところ（と思ったところ）はそうしていました。
でも、これってオブジェクト指向って言うのでしょうか？
構造化プログラムとの違いがよく分からなくって・・・
違いといえばクラスと構造体ぐらいで、
構造体自体が関数持ってますよ（クラスで操作しますよ）、
ってぐらいしか違いが無いように思えるんです。
634:仕様書無しさん
07/04/24 19:34:01
>>630
昔の口調に戻ったな。うんうん。
やっぱりお前の知能程度にはそれくらいが丁度いい。
635:仕様書無しさん
07/04/24 19:37:21
>>633
もう1段階上の抽象化があるのだよ
636:仕様書無しさん
07/04/24 20:21:27
ちゅうしょーかっ！ ってタカアンドトシもゆってた。
637:仕様書無しさん
07/04/24 20:29:03
>>628
要するに基地害の寝言スレ
638:仕様書無しさん
07/04/24 22:43:03
つまりは良く考えて作りなさいよ。ということだな。
639:仕様書無しさん
07/04/24 22:58:18
そうそう。お前の親に言っとけ
640:仕様書無しさん
07/04/24 23:03:48
ほんとになぁ・・・
641:仕様書無しさん
07/04/24 23:16:26
setter,getter作るだけでカプセル化とか、setter,getterを必ず作るとかいうアホが湧いとるな
とくにわけの分からんクソコテ
痛い突っ込みされてまたわけのわからんこと言うとる
中途半端にOOを知ってる奴が一番タチが悪い
642:仕様書無しさん
07/04/24 23:17:09
でも構造化設計が最高！ソースも見やすいしね。
オブジェクト指向は、部品だらけで、組合せがソースから見えないよ！
643:仕様書無しさん
07/04/24 23:20:18
ソースをテキストで作るのはもう古いのでは？！
644:仕様書無しさん
07/04/24 23:33:45
>643
これからの時代はパンチカードだな
645:仕様書無しさん
07/04/25 00:31:55
縦読みが３０分も放置されてる・・・
646:仕様書無しさん
07/04/25 03:34:45
>645
どれ？
647:おじゃばさま ◆GxjxF3yEw6
07/04/25 09:28:37
>633
メソッドが機能になるのは正しい。次に問題になるのが「クラスが物を表しているか」だ。
これがオブジェクト指向と呼ばれる所以になる。誰かが言っていたもう一段階の抽象化も多分これだろう。
落ち着いてクラスを見て、クラスが「商品」や「利用者」などの物になっていて、それらに関連する
フィールド変数とメソッドで構成されているればOKだ。
そして前にも書いたが、そうなるように変数やメソッドを移動する。
構造化の考えだと機能重視になって、クラスが「書き込み」や「計算」などの機能になって、単に書き込み
メソッドを集めたメソッド集や、計算を集めたメソッド集になってしまう事がある。これはNGだ。
ただし分かりにくいのは、「物」と言ってもまれに目に見えない物をクラスにする必要があると言う事だ。
前のオセロの例で言うと、「ゲームのルール」などである。
またまれに、機能なのか物なのか微妙な物や、ある場合では物になる機能などもある。
例えば先ほどの「書き込み」もWriter（書き込む人）などにして、物として扱う場合もある。
まあこのあたりは最初から考えると分からなくなるので、そういう場合もまれにあるという認識だけあればいい。