オブジェクト指向は戦場では必要無し　その３

前スレがめでたく止まったようなので、その３
引き続きＯＯ厨とアンチＯＯ厨の血で知を笑う戦いきぼ。

その１　http://pc.2ch.net/test/read.cgi/tech/1011997945/
その２　http://pc.2ch.net/test/read.cgi/tech/1013266554/

2のようだな(*´ー｀)フフフ・・。

クソすれたてんな　ボケが

言えない……、前スレの >615 ですとは……。
口が裂けても言えない……。

だから書いてる。

すぐに「その４」ができたら嫌だなぁ…

　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　/　　　この糞スレは無事に　/
　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　/　　　　モナーより　　　　　 /
　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣/
　 ∧＿∧　　/　　　　　　　　　　　　　　　　/∧＿∧
　（　^∀^）　/　　　　　　　　　　　　　　　　/（^∀^　）
　（　　　　）つ　　　　　　　　　　　　　　　⊂（　　　　）
　｜ ｜ ｜　　　　　　　　　　　　　　　　　　 ｜ ｜ ｜
　（_＿）＿）　　　　　　　　　　　　　　　　　　（＿（＿_）

とりあえず前スレ使い切るまで封印。

>>6
前スレを使い切る前にログ落ちするという罠。

>>1=4

>>8
ちがう、そもそもこの話のはじまりは「俺は自作自演なんかしない」だ。
それに so-net のアクセスポイントが最近、市単位から県単位(神奈川)に
変わったらしくて、ほとんど常に「スレたてすぎです」がでるんだよ。
今の俺にはスレは立てられないの！

アクセスポイントじゃなかった。
ホスト名か？

とりあえず無事再開したみたいだから前スレ逝ってくれ。
http://pc.2ch.net/test/read.cgi/tech/1013266554/-615

思いっきり書き間違えました。

http://pc.2ch.net/test/read.cgi/tech/1013266554/615-

よろしく。

ん。

　オブジェクト指向に限らず、　結局はこういう問題がある

■一生賢明勉強する->人の数倍は効率的に仕事してると他人も認めるようになる->しかし、給料は同じ　
　結果、独立したり、移動してしまう
　独立したら色んな雑事が増えるし仕事のかけもちも増えるしで外から見た能力は下がるし
　移動しても仕事より新しい環境への適応に失敗してしまうのが優秀なプログラマ程多い

そんなわけで、若い＝廉い優秀な人材が集まってるような職場でなければ、勉強が必要な技術は使い難い。

アンチ死ね。これがそんなに言って欲しいのか？

>>13
> 勉強が必要な技術は使い難い。
勉強なんて必要ありませんよ、って言ってほしいのかなあ。

>>13
突っ込みドコロは数あれど、取り敢えずマ板逝け。

オブジェクト指向を使えますという人の殆どはよく聞いてみるとクラスライブラリを使えるだけの事が多いのだが
それはオブジェクト指向の成果を使っているのであってオブジェクト指向を使っているか？

>17
クラスライブラリを派生して使ってるので、オブジェクト指向を使っていると言える。

オブジェクトを生成して、１メソッドコールして、オブジェクトを破棄する、
だけの使い方の人は存在しません。
それはｺﾎﾞﾗｰであって、人ではありません。

>>18
そうか、ならVBuserでもオブジェクト指向使いなんだな　なら戦場でもつかえるわ

>>18はアフォ。
信じるな>>19

なんでドコモはJava採用したの？

>>18
> オブジェクトを生成して、１メソッドコールして、オブジェクトを破棄する、
> だけの使い方の人は存在しません。
オブジェクトを生成して、１メソッドコールして、オブジェクトを破棄する、
だけの使い方の例
class HelloWorld {
　　public static void main (String args[]) {
　　　　System.out.println("18はアホ");
　　}
}
このプログラムはオブジェクト指向プログラムではないのでしょうか？

>>22
ではないです。

では以下のプログラムを見てそれぞれオブジェクト指向が使われているかどうか判定してみて

１、ギコBASICクラス
http://www.geocities.co.jp/SiliconValley-Oakland/8522/data/ugikoscr.txt


２、矢印とかを描けるコンポーネント
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/file/1004530597_1/MyDraw.pas


３、復活！ Delphi で Olion モドキ！！
http://www5.tok2.com/home/luminel/Pleiades02.lzh


４、VCLを使わない窓クラス
http://pc.2ch.net/test/read.cgi/tech/1009080085/87-88

>>22
サーバーサイド組んで見ろ

Delphiばかり選んだのは、
Delphiはオブジェクト指向言語であり
　　　　　しかもお堅い構造化言語でもあり　という意味からです

同じような性格のC++だとテンプレート使う場面があって余計に悩ましいでしょうから

19が一番アホだな。
VBにクラスライブラリは付いてない。

変わりにコントロールやオブジェクトライブラリがついている。
違いは・・・？

>>27
御言葉ですが、クラスなぞ無くてもＯＯＰできます。

いきなり痛いプロＯＯの方の登場で始まりましたが、アンチの自作自演では
ありません。あしからず。

>29
マイクロソフトがVBはオブジェクト指向出来なくてコンポーネント指向だと申しております。
VBはオブジェクトベースのOOPとも関係ありません。

>>31
VB でも Implements キーワードを使えばインターフェースの継承（多態）は
できるそうだ。

１．MSのアナウンス：委譲がOOであり、継承はOOの本質でない。だからCOM使え
↓
２．MSの次の言動：Delを作ったヘジを裁判沙汰になってまで引き抜き。
↓
３．MSのアナウンス：「VB-COMはコンポーネント指向」
↓
４．MSのコラム：「VBはオブジェクト指向の海を渡りきれない」
↓
５．MSの次の言動：Delと区別つかない実装継承の.NET作成。

もうVBは過去の異物となりました。
そんな話を持ち出さないでください。

りょーかい>34

NGワード:VB、ﾌﾞﾋﾞﾁｭｳ、ｺﾞｷﾌﾞﾋﾞ

まだ「　」が居るようなんで、前スレから引っ張ってきました。

で、関数ポインタとメタプログラミングの関係って何？　関数ポインタを使うと書けて
Java の interface では実現できないメタプログラミングの実例を出して下さいな。

---
832 名前：　 投稿日：02/02/23 22:28
>>821
Javaが補助輪付きだっつうのは当たってるわな。
悔しかったら俺に関数ポインタを返せ！

836 名前：デフォルトの名無しさん 投稿日：02/02/23 22:29
>>832
> 悔しかったら俺に関数ポインタを返せ！
interface 使え Yo!

839 名前：　 投稿日：02/02/23 22:36
>>836
アフォか！インターフェースじゃ関数ポインタの変わりにならんわ！
せめてリフレクションと言え。
つうか携帯java担当なんでどっちも使えないがな。

841 名前：デフォルトの名無しさん 投稿日：02/02/23 22:37
>>839
関数ポインタでなにがしたい？

845 名前：　 投稿日：02/02/23 22:51
>>841
いわゆるメタ構造かな？
関数ポインタ無いと静的プログラムしか書けない。
---

>>33
MSは言っていることがコロコロ変わるから信用ならんね。

MSにもいろんな人いるし、
社内の技術的見解の統一は難しいんでしょうね...

>>38
MS の場合、マーケティング用の用語はコロコロ変わるけど、技術的な基盤は
一度作り始めたら諦めが悪いのも確か。

特に COM なんかは

　OLE, ActiveX, COM, DCOM, COM+

と Win3.1 のころから未だに引きずっていて、ようやく .net で裏に隠れたって感
じ。Windows DNA とかマーケティング用語を真に受けて勉強すると泣くから、
その当たりを見極める目が必要だわな。

>>36
粘着は相手にしたくありません。
教えて欲しいのなら態度を改めなさい。
そして改心してアンチＯＯに転向しなさい。

>>40
残念だったな dat 落ちしてなくて（ｗ

あれ？　誰も>>24 へのコメントないね

　たぶんOO派だとしても境界は曖昧な筈、

俺は前に、OO言語を効率的に使ったとしてもオブジェクト指向ではないとかさ
そんなふうに言われてからアンチOO派
　OO言語は道具として便利に使うけど、OOは嫌い

　というよりOOがどうとか商売してる奴が嫌いなんだけどね
　結局失敗してやがるし

>>42
予備知識がないと意味不明なのでわ？

>>42
そのインデントには、何か深い意味がある？　（いや、微妙に読みづらいなーと
思っただけなんだが）

>>42
Delphiだから読むのがめんどくさい。

>>42
俺は Delphi はよく知らんのだが、GikoBasic をざっと読んだ感じだと

- プログラムは一つのクラス TGikoScr
- 各トークンは GetSym で読み出して Variant 型として管理

っつー感じなのか。

状態を管理しているのは TGikoScr だけだし、これは OO というよりは典型的な
手続き型プログラミングだと思うけど。OO で設計するなら

- 入力ストリーム
- 字句解析
- 構文解析
- シンボルテーブル
- 構文木／そのノード
- 最適化
- 出力ストリーム

あたりをオブジェクトに切り出すと思うが、そもそも GikoBasic の規模だと、そ
こまでやらずに済ませてる今のコードも悪くないと思うよ。

これが、たとえば変数やラベルにスコープの概念が入っくるとシンボルテーブル
は分けた方が良いし、中間コードを作ることにすると構文木も分けたほうが管理
が楽になる。

アセンブラでOOP出来ますか？

>>46
そうですね。　OO言語の機能は使われているけどOOでは設計されていないと思います。
ただ、元のギコBASICはこれを継承してテキストスクリプトでグラフィック描画が出来る
コンポーネントになっていました。


それではこちらのコードは如何ですか？
ギコBASICとエンジンは同じで、TmNum 　という基本クラスに対してスクリプトは作られ
整数型・浮動小数点型・１００進数型などが継承されています。

http://www.geocities.co.jp/SiliconValley-Oakland/8522/data/mformula.txt

継承は使われていますよ

>>48
もう Pascal 読むのいやです（ｗ

（人のコードを 2000 行って、まじめにレビューしようとしたら一日がかりだし。
せめてクラス図とかあれば見る気にもなるけどさ）

>>49
　Delphiを使えば、IDEが助けてくれるので読むのもそう苦労はしないのですが
そうでなければ苦しいとは思います。

たぶん読めば　これもOO言語を有効に使ってるけど、OOではないという結論になるでしょう
もっともDelphi6で拡張されたVariant機能を知っていれば無駄な事をしてるように思えてしまうでしょうが

結局、OO言語機能を適切に使っていても、　それだけではOOではないのです

しかし、チョッとしたスクリプト機能を組み込むならそれで問題ありませんし
そういうふうに作られたDelphiのコンポーネントを組み合わせればアプリは作れます。
コンポーネントを作れば再利用性も抜群です。

Delphiに限らず、VBでも同じでしょう。　
OO言語の機能を便利に使えば、OOは現場で無理に使う必要など感じません

>>50
言いたかったのは
> OO言語の機能を便利に使えば、OOは現場で無理に使う必要など感じません
これ？

あらゆる場合に OO 使え、と主張しているヤツは（たまに出てくるが）このスレでは
多数派ではないと思うが。むしろ「OO は、あらゆる場合に使う価値なし」と言ってる
アンチが目立つ。

>>51
「OOを使わない」と言っている人を無理に
「OOを使えない人」にしてがっている人の方がよく見かけますが．．．

多分、そういう人の頭は1bitの情報しか詰め込めないので
「OOを使える人」と「OOを使えない人」にしか分けられないのでしょう。

>>51
　そうです。　オブジェクト指向しなくても、OO言語は便利に使えます
もっと言えば、オブジェクト指向しなければ書けない人よりも便利に
有効に使ってるでしょう。

　設計のないクラスなんてとよくOO派は言いますが、
たとえ突貫工事で作ったコンポーネントでも再利用は簡単に出来ます。
実際、ギコBASICのDelphi版はわずか数時間で作られたものだし、上のugikoscr.txt
はそれをコピペして修正したものだけど、1時間程度で修正出来ました。

>>53
あきらかにコミュニケーション能力に欠陥あり。
相手が何を把握しているか管理する脳内の対人情報中枢に問題あり。
自分の知識と他人の知識の区別がついていなく、話の前に共通の知識の土台を
築こうとする動機が発言しません。
あなたは病気です。

発言しません　Ｘ
発現していません　○

>>54
…ﾈﾀがやりたいならマ板逝け。

ネタじゃないってば。
マジだよ。
おまえおかしいよ。

ええと　一応自分の発言には 24と書いてますのでお間違えなく >>57

>>54
自分の理解できないこと言われると他人に問題があると考えるお前の方が異常

悪い事はいわないから>>54の文章を良くかみ締めて、自己治療してから
出なおしなさい。

>>53
そうですね。そもそも SmallTalk のような純 OOPL は珍しくって、現在の主流は
C++, Java, Delphi といった、OO を含む複数のパラダイムを支援する言語だし。

ただ

- OOPL は OOA/OOD しなくても、非OOPL よりも便利に使える。
- OOA/OOD は有効である。

というのは、また別の関係ない話なんで、スレの趣旨からするとどうでも良い
気もするけど。

（それを言ったら、そのスレ自体どうでも良いか（ｗ）

>>60
その前に関数ポインタの話に答えとけよ（ｗ

あのね、人と会話する時は、まず相手に理解してもらえるか
相手の思考をシミュレートしながら話すの。
その土台になる相手の知識を想像しながら話し、共通の知識を築いてから
話すの。
「ギコＢＡＳＩＣ」なんて普通の人は知らないだろ？
扱ってる言語も皆違うだろ？
自分とは違う知識を持った人に理解してもらおうとするなら、
相手の持ってない知識の説明から入らないと。

>>63
> 「ギコＢＡＳＩＣ」なんて普通の人は知らないだろ？
ソース読めば一目瞭然だけど :-P　おれは Delphi は使ったことないけど、
ざっと読んで構造を理解するぐらいなら、それほど手間じゃなかったぞ。

>>61
　あんまり前スレから追いかけてる訳じゃないけど、新スレになったみたいだから前から
思ってた事書いてみました。

42でも少し書いたけど、オブジェクト指向は　OOだ　OOだ言ってる人が嫌いだったので
今でも嫌いです。　でもDelphiやC++はもちろん使います。
嫌いだからオブジェクト指向がどうとかいう仕事は逃げようと思ってたけど
個人でお客さんから直接仕事貰って一人で書いてれば近寄る事ないですね

>>63さん
　もしかして私に書いています？

>>65
他にいるかよ。

>>61
> - OOA/OOD は有効である。
戦場になる前なら有効かも知れないと言っておこう。

OOA/OODは戦争で言えば戦略に当たる部分だろ？
戦闘中に戦略を変更しても余計な混乱をもたらすだけ。

よって、戦場ではOOA/OODは有効ではない。
最後に孫子を引用しておこう
「勝兵はまず勝ちて而る後に戦いを求め、敗兵はまず戦いて而る後に勝を求む。」

では、僭越ながら申し上げます >>66　オマエモナー！

>>65
> オブジェクト指向は　OOだ
それは OO = Object Oriented ですから、訳語そのままかと。

>>67
俺も「戦場」＝「火のついたデスマーチプロジェクト」だと思ってたんだが、
どうも >>1 の定義だと「戦場」＝「現場」らしいよ。

>>63
> その土台になる相手の知識を想像しながら話し、共通の知識を築いてから
> 話すの。
で、メタと関数ポインタの話はどうなったんだ？　自分のことを棚に上げて何を
言ってるんだか。

ごめん
○（OOだ　OOだ言ってる人が嫌いだったので ）　今でも　オブジェクト指向は嫌いです
という意味だった

>>68
真面目に言ってるんだけどね。

>>71
なるほど。なんでもかんでも「OO じゃなきゃダメだ」と言ってるやつね。

それは俺も嫌いだけど、そこから OO 自体を嫌いになるのは技術者としては
どうかと思うけど。バカが回りにいようが、役に立つモノは取り入れないと（OO
だろうが UNIX だろうが MFC だろうが）。

取り巻きでモノの価値が決まるわけじゃなし、活用できるかどうかは自分次第
ということで。

>>42
>というよりOOがどうとか商売してる奴が嫌いなんだけどね
>結局失敗してやがるし
あまりにも偏見、曖昧さに満ちた発言で、ＯＯ，ＯＯ言ってる奴と大差ない気がするが。

>>69
> 「戦場」＝「現場」らしいよ。
「戦場」＝「現場」ならば、
　　「有効かどうか判んないんだったら使うな」だな。
普通、パイロットプロジェクトみたいに失敗しても被害がない(少ない)
プロジェクトで試すだろ？

新薬を動物実験をせずにいきなり人体実験をするようなものだ

>>72 アリガト
　でもさ、25で、Delphiを例にあげた理由は書いたよね？
　それから、コードを示したのは　これはOOかどうかと問うてから
　OO言語の機能を使ってるけどOOではないと結論が欲しかったから
　ついでに言うと、示したコードの少なくとも２つは俺がUPしたコード　どれとは言わないけどね
　だからOOでないという結論には自信を持ってたわけ

>>73-74

　まあ　動機はそんな所からだけど、OOを活用しなくてもOOPは活用出来れば仕事は出来るよ
　という事に気付いちゃったし、実際問題ないと思ってるよ

ああ 25じゃない >>26だ
　あちこちミスがあるから読みにくいんだろけど、なんか病気みたいに言われるのはちょっと心外

　まあ２CHだからいいか

>>76
> OOを活用しなくてもOOPは活用出来れば仕事は出来るよ
まぁ、OOP 使わなくても出来る仕事は出来るし。それで満足してるのなら
良いんじゃないの。ただ OOA/OOD でやってる仕事を請けられなくなるだ
けで。

で、結局 OOA/OOD してないことに不安を感じていて、誰かに「大丈夫だ
よ」といって欲しかっただけ？

２４氏は大規模なプロジェクトも経験してるんか？
>OOを活用しなくてもOOPは活用出来れば仕事は出来るよ
↑これってよく意味わからんが、単にクラスライブラリ使ってるだけ、コンポーネントぺたぺた張ってるだけの
プログラムのような気がするんだが。

OOP言語でプログラム組んでると、OOってええなあ、と思うけど…

OOAだのOODだのという話になるとあっちこっちから本読んだだけで
全てを分かった気になってるような勘違い馬鹿が集まってきて毒霧
吐きまくってプロジェクトを泥沼化させるんだよなあ。
そいつら同士で俺様ルール押し付けあって埒があかなくなること
ばかり。ちゃぶ台返しとかも平気でやるし。アホか。

OOでも問題ないように進むなら別にいいけど、あの勘違い馬鹿
連中はどうにかできないもんかな。俺らはリミットのある仕事
をこなさなきゃならんのに。

はい、
> 「OOを使わない」と言っている人を無理に
> 「OOを使えない人」にしてがっている人の方がよく見かけますが．．．
ご登場です。

>>78
　まあ、OOA/OODより、自分のスタイルの方が効率的だよ　どうだ
　と言いたかった　といえば恥ずかしいし　　そんな所でもいいよ別に

このタイトルと前スレの１に共感する所があるから書いたんだけどさ

>>75
禿同。

別にOOに限った話ではないが
自分が戦場で使えると思ったら使うっつースタンスでいいんでわ？

>>79　大規模ってどの程度が大規模なの？

今は一人で　数年前にそれなりの人数でやってた規模の仕事を書いてるけどさ

>>82
> 　まあ、OOA/OODより、自分のスタイルの方が効率的だよ　どうだ
それなら、分析／設計フェーズの話もしないと比較にならんやん。

> 「OOを使わない」と言っている人を無理に
> 「OOを使えない人」にしてがっている人の方がよく見かけますが．．．

「OOを使えない人」のほうが多そうにみえるがｗ

>>80 それ！　まったくもって同感。　やっぱり、いまもそうなんだね

>>87
いつまでも、レベルが低い人間を飼ってる職場にいるからだよ。個人的には、
早めに職場を変えること推奨するが。

>>79
> ２４氏は大規模なプロジェクトも経験してるんか？
大規模プロジェクトでも OO 使わない事例は多いでしょ、今でも。

それに小規模だと OO の長所が活かせないかというと、そんなことはない
訳だし。規模の大小を持ってくるのは、ちと違うんじゃないかと思う。

みんなの周りにはOO覚えたて勘違いDQNが多いのか？

私の周りは構造化ですべてを語るロートルしかいませんが、なにか？

>>90
大企業ですね。
うちはベンチャーです。

うちはみんなＯＯで上手くいくともいかないとこもあるけど大抵順調ですけど？

昔はＯＯ大好き人間がプロジェクトをぶち壊すことが多かったかもしれんが、今はいまだにＯＯになじ
めない人間がついていけずに(行かずに？)ぶち壊すことも多いと思われる。

>>91
ベンチャー＝技術力が低い

と思ってる？　単に規模が小さい零細企業なだけだろ。

>>80
ウチの会社では技術的な会話なんかあまりしませんねえ。
会議のときくらいかな？
ところで、ちゃぶ台返しってなんだろう？
激しく気になるのですが・・・。

>>90
零細ﾄﾞｷｭｿソフトハウスみたいなとこです。

個人的なスタンスだと「便利なやつ使えば楽できるじゃん」つー考えなんで
OOとかは積極的に使ってる(つもり)

しかし勉強しないロートルが打ち合わせの話についてこれなくなる罠

>>93
そちらは良い環境のようで、羨ましいです。
うちは普通じゃないと思います。

>>95
> しかし勉強しないロートルが打ち合わせの話についてこれなくなる罠
ちゃんと人を「育てる」ような体制は作ってあるの？

放っておいても育つような優秀な人間は少数で、勉強して技術力を上げるような
機会を作らないと、なかなか会社全体の技術力なんて上がらないよ。（そして、
足を引っ張られる）

前スレと雰囲気が違う・・・・
キモイ・・・・。

>>97

大抵そういうロートルが教育担当になっている罠

>>99
教育専任のひとって、要するに使えない奴の飼い殺し用ポジションだよね。

>>96　心配いらない　少なくとも自分が見た範囲では　そっちが普通の環境だと思う

やっぱりOOに限らず、分析や設計を事前にするなら　した奴が責任持たないとダメさ

ばかもん！
「勉強」なんてのは他人が勝手に考えたのを有り難がって覚える事だ。
そんなのは技術者としては敗北だ！
勉強より発明せよ！
そして他人に有り難がらせ、覚えさせるのだ。
よって勉強など不要。
ましてや無意味に造語を乱発するＯＯなぞ持っての外！

> やっぱりOOに限らず、分析や設計を事前にするなら　した奴が責任持たないとダメさ
責任持たさせてもらえない、って状況もあるけどな。
あっちこっちたらい回しというか片足だけ突っ込まさせられるとか…
(うぉ、日本語禿げしく変だ)

>>102
「学ぶ」は「真似ぶ」由来だが。

> 勉強より発明せよ！
そういうヤツに限って、とうの昔に常識になってることを再発見して自分の新発見
のように喜んだり、知識の欠落を指摘されるという罠。

でだ、関数ポインタとメタの関係は何なんだ？　C 言語だと関数ポインタを使っ
て実現できるのに Java の interface だとできない何かなんだよな（ｗ

>>102
勉強というのは、他人が考えたものでも自分に再発明させる行為だと思ってたよ

造語については、どんなものでも概念を共有する為には必要なものだと思う
むしろ、造語の概念が、スマートでない点が問題だと思うけどね

>>103
　責任をとる人に権限が与えられるべきだ
　権限を正しく使う人に報酬が与えられるべきだ　とやっぱり思うな

　日本は、天皇がお飾りだから　総理大臣もお飾りで、
　トップはいつもお飾り

>>102
頑張って新しいこと発明しろよ。
おまえが知らないことはたくさんある。
勉強せずにいつ追いけるかな。

創造力のないＰＧが必死だなｗ
大抵の事はすでに自分で発見してるよ。

>>107
あきらかにコミュニケーション能力に欠陥あり。
自分の能力と他人の能力の区別がついていなく、
また話の前に共通の知識の土台を 築こうとする
動機がみられず、主に自己顕示欲だけが先行しています
あなたは軽い病気です。

>>107
そんな実の無い自慢話ふくよりよお

自分の能力を見せたかったら　ギコBASICを 好きな言語に移植してみせろよ
http://pc.2ch.net/test/read.cgi/prog/961558082/
ここ見るかぎりC->Delphiの移植に数時間しかかかっていないんだから
こんなスレに粘着する時間あんならお前なら半日でコンパイラに出来るだろうよ

>>105
> 　日本は、天皇がお飾りだから　総理大臣もお飾りで、
>　トップはいつもお飾り
電波？

>>109
ああ、わるいな。プログラミングはそんな速くないんだ。

>>111
早いのは２ちゃんねるのレスだけかよ。おめでてーな。

（事前に言っておくがｵﾚﾓﾅｰ）

>>100
仕事ができる奴は仕事をする
仕事ができない奴は教師になる
教師にもなれない奴は芸人になる

>>113
ほんとに教えるのが上手いインストラクターってのも業界によっては存在する
んだが、この業界ではあまり見かけん気がする。もしかしたら大手だと存在す
るのかなぁ。

人に教えるのは、場合によっては自分で理解するよりも大変なんだけど。そ
こに仕事の出来ないやつを押し込んでたら、教わる方も災難だよな。

教えるってのは概ね知識だけど、プログラミングは知識じゃないからねえ。

ふう・・・ 嫌なDSPのコードやっとデバック終ったからもう寝る

この手のDSPにゃ絶対にOOは導入されないなと思いつつ

まだ「　」が居るようなんで、別スレからも引っ張ってきました。

ＣとＪＡＶＡを比較した場合Cの良いとこと悪いとこ
http://pc.2ch.net/test/read.cgi/tech/1009707596/

16 ：　　　 ：01/12/30 23:18
Javaでは動的なプログラムは作れません。
プラグインや動的関数ポインタは無理。
死んで欲しい。

151 ：　 ：01/12/31 22:55
<略>
ＪＡＶＡの短所
１）厨房が大量に集まってしまった。（しかも、えばってるし）
２）プリプロセッサが無い
３）ポインタが無い。特に関数ポインタ

169 ：　 ：02/01/01 01:01
>>166
定義済みで既知のクラスでないと呼べないでしょ。
Ｊａｖａはどこまで行っても固定プログラム。
手を変え品を変え、関数ポインタがあるように書かれてるけど、
同じ材料が形を変えているだけ。

焼きそばとたこ焼きとお好み焼きみたいな物。

391 ：　 ：02/01/02 01:25
未知の、コンパイル時に情報交換を行わないプログラムは
Javaでは実行できませんよ。

リフレクションとかその他もろもろのは全部既知のプログラムしか
扱えない。つまり静的。

395 ：　 ：02/01/02 01:30
コンパイル時点では走らせるプログラムに関する情報をいっさい持たない
任意のプログラムを走らせる事が出来る＝動的。としとく。

406 ：　 ：02/01/02 01:50
Class forName(String className)ね・・・。

classNameはどこから持ってくるの？

416 ：　 ：02/01/02 02:04
>>411
もちろん静的ですよ。

つうか、最初に明示した条件に反してるでしょう。アフォですか？
論破されたからって「こいつ」呼ばわりですか？

これはおまけ:
417 ：410 ：02/01/02 02:06
いまの流れでいうと、動的っていうのは、ようするにevalのことだよね？
文字列を実行する、しかも呼ばれた側呼び出し元の環境を参照でき
る、ってことでいいんですよね？

ｶﾗｯﾄｲｺｳﾖｶﾗｯﾄ
　　　　∧∧,..,､､.,､,､､..,_　　　　　 　／i
　　　;'ﾟДﾟ、､:、.:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i
　　　'､;: ...: ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ ￣ ￣ 　　　　
　　　　｀"∪∪''`ﾞ ∪∪´´

evalってなんれすか？

>>119
インタプリタ系の言語でよく実装されてる、文字列でプログラムを与えると、
それを実行する命令。

eval("print 1+2");

で print 1 + 2 を実行する、と。

動的にプログラムコードを生成して実行できるので、上手く使うと柔軟性が
高いコードが簡単に書ける（特にマクロっぽい機能が必要な場合に、簡易
言語を自分で実装せずに済むのが楽）。

ただし、下手に使うとデバッグできずに死ぬ。

>>114
教えるのが巧いくらい優秀な奴は、仕事やらせたほうが
会社が儲かるので、教えるなんていう仕事はさせないの
よん。役立たずで首にするわけいにいかない奴を、なんか
偉い肩書き与えてその地位においとくのよん。

>>1
ゴルァ！
板違いだぁ！

軍事板逝けドアホウ！

>>120
はあ、ﾈﾝﾁｬｸさんは関数ポインタがないとそれができないのか…
コンパイル作業を実行時まで遅らせればいいだけじゃん。
つうか、どこで関数ポインタが必要なの？

ブートストラップのインターフェイスだけ決めておいて、
実行時にソース渡してコンパイルしてそのインターフェイス
コールすればJavaでも同じじゃん。

>>120
>ただし、下手に使うとデバッグできずに死ぬ。

そうなんだよね。

Javaでもクラスローダ使ってバイトコードを読み込めば「動的プログラミング」は
可能だが、そんなことしたらデバッグで死ぬから普通しない。
まして C では、機械語コードを生成することになるから、よっぽどのバカ以外
そんなことしないだろ。

>>123
実行環境にコンパイラが存在することを仮定するのは何だから、ふつー
インタプリタを書くよね。

いずれにせよ、なんで C だと関数ポインタがあるから実現可能で、Java
だと実現不可能なのかは謎。

>>122
軍事板でプログラム板に逝けっていわれたＹＯ！

>>124
> まして C では、機械語コードを生成することになるから、
加えて、実行時に eval される側から、eval する側の環境を参照する、と言っ
てるわけでしょ？

そうなるとシンボル情報をどうやって eval される側に公開するんだって話も
でてくるし (VC あたりだと PDB ファイルの詳細は非公開だし、リリース版に
実質的にソースコードと同等の情報をもつ PDB ファイルは加えたくない）
謎は深まるばかりだ。

>>123
俺は「機械語コードをメモリ上に生成して関数ポインタで呼び出す」と
いうのを想像してたんだけど。でも、>>124 に書いたとおり、保守や
移植を考えたらそんなことしないよな。

で、Javaでもバイトコード生成すればそういうことはできるけど、
どっちにしても保守で死にそうだから、もしどうしても「動的プロ
グラミング」をしたければ

>実行時にソース渡してコンパイルしてそのインターフェイス
>コールすればJavaでも同じじゃん。

この辺が落しどころじゃないかな。そして、こういうことは、
ダイナミックリンクが言語標準の機能でできるJavaの方がやりやすい。

JSPは実際そうやってるわけだし。

>>102
> 勉強より発明せよ！
> そして他人に有り難がらせ、覚えさせるのだ。
ふーん…

> ましてや無意味に造語を乱発するＯＯなぞ持っての外！
は？新しい用語を発明しちゃいけないってことか？
言ってることバラバラじゃん。

>>118
スレふたつにわたって見当外れの説を延々と主張しつづけるようなバカこそ、
粘着の名にふさわしいと思われ。

# 悲惨な「　」を晒すスレになりつつあるな。

ＯＯ用語は従来の用語の言い換えが多いよ

>>131
たとえば?

# クラス = ファイル分け、とか言い出しそうだな(藁

「　」が OO 用語とかいったところで、どうせその用語を理解してないだろう事は
想像がつくわけで（ｗ

多分、関数ポインタが無いって騒いでる人は、
内部イテレータとかを簡潔に書きたいんだろう。
こういうのはコールバックを除けば構文の問題なんだよね。

>>134
ここまでの流れからすると、少なくとも「　」はそういう主張はしてないと
思うが。

ま、それはさておき、内部イテレータとかを簡潔に書きたければ、
コールバックのためには関数を作らなければならずしかも関数のネストが
できないCに比べれば、無名クラスでクロージャもどきができるJavaの方が
簡潔じゃないかな。

回数で言うとコールバックとインタプリタ内のコールで困った
ことが多かったな。
（イテレータはあんまり使わない。）

それに、経験上だけど、クラスーインターフェースよりか
関数ー関数ポインタの方が再利用率が高かった。
分割単位が小さければ小さい程応用範囲が広いのが原因だと思う。

この期に及んで、まだコテハンを使いつづける「　」って一体…

Kusakabe 並みの面の皮の厚さだな（ｗ

内部イテレータを簡潔に書くのと関数ポインタとどう関係あるの？
普通によく分からないのだが…

>138
Kusakabeﾀﾝは衝撃だったよね。

>>131
> たとえば?
カプセル化＝情報隠蔽
メソッド≒関数
クラス⊃構造体

>>141
それを見ると日本人にとってはいいニュースに聞こえるね。
怪しい漢語からカタカナ語への切り替えにちょうどいいタイミングだったと思われ。

でも多態とか新たな似非中国語を産んだか…。

>>136-137
馬鹿が己の経験論を自身たっぷり述べるほど、傍で
見ていて間抜けな話はないと思う。

文句があるなら、こんな底の方で吼えてないで堂々と上げましょう。
また、反論があるなら論理的に願います。

と思ったけど、例の粘着君は御断りだよ。

>>141
C++ の実装に依存してる考えだね

>>146
きっと C++ やって OOP やった気になってるんでしょう。

ここにも被害者が一人...

粘着でもやっぱり、粘着は嫌いらしい・・・

>>143
ここは、そんな痛々しい「　」を眺めて愉しむスレです。

素直に間違ってたといえば良いのに、いい加減な知識にいい加減な言い繕いを
重ねてるから遊び道具にされちゃうんだよね（ｗ

>>150
「　」は明らかな間違いを延々と主張していながら、その間違いを認めてすら
いないわけだからね。

しかもいまだに関数ポインタがどうのこうのと言い続けている。

粘着もここまで来ると、おもちゃにするより、正直、寒いな。

2ちゃんならどうでもいいけど、たとえばこんな奴と電車で乗り合わせたり
したときのことを想像するとね…

カプセル化を情報隠蔽とするのはどうかと思う。
隠すのが主目的ではないから。
どこかにも書いてあったが透明カプセルだってある。

>カプセル化＝情報隠蔽

そもそもOOの普及以前には「情報隠蔽」という概念はあまり一般的ではなかったと
思うんだが。

とはいえ、OOでなくても(たとえばCとか使っても)大規模なプログラムなら
なんらかの方法で情報隠蔽を図るから、情報隠蔽は別にOOに特有の概念では
ないわな。

>メソッド≒関数
>クラス⊃構造体

このふたつについては、少なくとも「似て非なるもの」なんだから、別の名前を
割り当ててもいいんじゃなかろうか。

とはいえ、たかが「メソッド呼び出し」を、「メッセージ送出」と呼ぶのはやめて
欲しいが。このスレにいるアンチOOは、そういうわけのわからない言い回しに
翻弄されてアンチになっちゃったような気がする。

てなわけで、アンチOO連中もかわいそうな被害者なんだから、あんまりいじめ
ないでいてあげようよ。(w

もちろん、「　」は例外でいいけど。

>>146
>C++ の実装に依存してる考えだね

かもしれんが、そう考えて何か不都合が?

Smalltalkerを相手にするのに比べたら、C++のスタンスはずっと
「実利的」だと思うがな。

C++の仕様を全部理解しようと思うと大変だけど、OOの「サワリ」を
つかむには C → C++という流れはむしろ悪くないと思う。

ごめん、俺、131じゃなくて >>132 だった。>>141の引用見て誤爆。

それはそれとして、

>>139
C++(STL)やJavaのイテレータは使用者側が++したりnext()呼んだりするけれど、
これが「外部イテレータ」。「内部イテレータ」ってのは、使用者側はそういう
ところに手を出せず、逆に、イテレータによって決められた処理が駆動される
ことになる。Rubyのイテレータはこっち。

で、こういうのを、CやJavaで実現しようとすると、関数ポインタなり
インタフェースなりを使うことになる(要はコールバックだからね)。

メンバ関数をメソッドと呼ぶのはやめて欲しい。
Javaがそう定義しちゃったみたいだから、我慢してるけど。

>>155
内部イテレータは、C++ だと

　関数オブジェクトを for_each などの traverse アルゴリズムに渡す

というのが近いのかな。

>>157
ですな。あとはVisitorパターンとか。
# 「Javaの格言」にちょっとだけ説明がある。

んで、そういうときに、Javaだと無名クラスが使えるから、わざわざ
外に関数を定義しなければならないCより簡潔なんじゃない? というのが
>>135 の意図。

>>158
話が逸れるけど、C++ で無名関数オブジェクトを定義できるようにするライブラリを
書いてる人がいるみたい。boost.org の ML で Review Request が出てた。

(Boost Lambda Library, 略称 BLL だそーだ）

>>153

同意。

OOの利点で語られることの殆どはOOをサポートしない環境でも
結構頻繁に使われるよね。

Netscapeなんて構造体のメンバにに関数ポインタを入れといて
メソッド的な使い方する方法を多用してたし、
これだって一種の多態だね。

別にOOの概念全部を必ず使わないとならないわでないのだから
そこは設計次第でしょ。

OOならできてOOでないとできないことなんて無いんだから・・・

やヴぇ・・・
ageちまった。

スマソ

>>160
> OOならできてOOでないとできないことなんて無いんだから・・・
まぁそうだが、OO で設計したら素直に OOPL 使え、とは思うけど。

インターフェースの多重継承なんかは、OOPL の力を借りないとやってられん
でしょ（関数呼び出しのたびに this 相当のポインタの offset を再計算、とか自
前でやってたら死ぬ）

>>162

確かに多重継承はOOPL使ったほうが合理的だと思う。
できる/できない
で語ったのはちと良くなかった

っていうか
Cで多重継承（と似たようなこと）をやるのが痛い
それこそOOのためにコードを書かされる

OOが便利に使えるところならOO使えばいいし、そのためには
(使えるなら)OOPL使えばいいよね。

でも、犬::鳴く、猫::鳴く 的な説明でOOを語る奴はやっぱうざいし。

打ち合わせのときなどに、「その設計はOO的じゃないですよ」なんて
言う奴って結構いないか?

>>164　色んな意見があるよね　OOPLは便利に使うし使えるけどOOは嫌いとか

「その設計はOO的じゃないですよ」って言う奴はたいてい設計出来ない奴だから無視するのが吉
「こういう設計を提案します」って言う奴を信用しろ

結局オブジェクト指向ってプログラマがTechに走らないようにする縛りなんだな。
縛りの法則なんてプログラム出来なくたって覚えられる。
だがそんな状態の人が出来ることはせいぜい設計時のダメ出しぐらいで、
代替案なんてありゃしないから邪魔なだけなんだよな。

>>166
> 結局オブジェクト指向ってプログラマがTechに走らないようにする縛りなんだな。
そうなの？

この場合のＴｅｃｈ＝ひとりよがりのトリッキーな方法

>>168
それにしても、オブジェクト指向を導入すればトリッキーなコードがなくなるかと
言えば、全然関係ないと思うけど。とくに C++ なんかはキャスト使えばなんでも
アリアリだし、

　private なメンバにアクセスしたい
　→ friend にしちゃえ　（まだマシ）
　→ 継承しちゃえ（ダメダメ）
　→ #define private public （最悪）

とかあるわけだし。

その辺は XP の出番だろうな。
トリッキーなコードを書いたらペアプロでダメだしされるだろう。

吉川英治 歴史時代文庫17
宮本 武蔵４

p48
無知はいつでも、有知よりも優越する。相手の知識を、テンと
して無視し去ってしまう場合に、無知が絶対につよい。生半可
な有知は誇る無知へ向かって、施すに術(すべ)がないという格
好になってしまう。

知らないふりをするのと、知らないのを比べたら
知らないほうがいいっていうことかな？

関係ないけど、有知って言葉を辞書で調べたら
「有知無知三十里」って言葉が出てきた。

無知の知
ムチムチ (;´Д`)ﾊｧﾊｧ

>>172 >>173
無知はDQNと言っているらしい。

ああ、このような名スレがこんなに沈んでるなんて・・・。
sage誘導してるのがいるなー。
てことでage!

>>175
名スレと思うならほっとけＹＯ

-------------------------------------------------------
が武蔵には、間髪のまに、処する方法が立っていた。
兵法によらず、すべての理は、それを理論するのは平常の事で、
実際にあたる場合は、いつも瞬間の決断を要するのであるから、
それは理論立てて考えてすることではない、ひとつの「勘」であった。
平常の理論は「勘」の繊維をなしてはいるが、その知性は緩慢であるから、
事実の急場には間に合わない知性であり、ために、敗れることが往々にある。
--------------------------------------------------------------
（吉川英治　宮元武蔵　吉川英治文庫　８巻９６ページより引用）

ﾜｹﾜｶﾗｿ

往々って辞書引くと「ときどき物事が起こるさま」って書いてあるね。

>>177の説明
理論だけでは戦場には役に立たない。
戦場には”勘”というのが重要。
その”勘”を養うには繊維となっている理論が重要であるが
それだけではまだ足りない。

つまり、戦場で勝つには”勘”を作っている理論とそれ以外（実践？）を
身に付けろってこと。

ちなみに、文章をよく読むと分かるが、平常の理論は事実の急場には間に
合わないと書いてあるが役に立たないとは書いてないので勘違いしないように。

負けたら即死な戦場では、「往々」は、一度でおしまいってことだ。

「本当の空とは知識や体験を経て達する迷いなき境地であり、空の心に善はあっても悪はない。
『知恵』と『道理』、そして人としての『道』があって初めて心は空となる…」宮本武蔵

え〜と、何やらありがたいような、
板違いなような、デムパなような…

なんだ、武蔵って兵法の理論書き残してるじゃん。
やっぱ理論の重要さを分かっているんだね。
さすが武蔵。

>>175
このスレは

悲惨な「　」を晒すスレ

なんだけど、本人はわかってないと見える (w

で、関数ポインタはどうなったのかね?

だいたい、「　」って、前スレで

ファイル分け >>>>>>> クラス

なんて、わけのわからない主張してたんだよな。
もともと直交している概念を比較してどうするよ。

思うに「　」って、根本的に「インスタンス」がわかってないんじゃないかな。

こいつは(恐ろしいことに)携帯Javaのプログラマだそうだが、こいつの書く
プログラムはstaticの塊なんじゃないかと想像してみる。

> こいつは(恐ろしいことに)携帯Javaのプログラマだそうだが
どうせ妄想でしょ（ｗ

えーと、「　」が晒しあげられる経緯を読んでないんだが
>>186を見る限りとんでもないｱﾌｫだと見受けられる。
つーか、携帯ってi-modeだろ？
あれはOOなんて言ってたらメモリが足りないだろ。
8ビットマイコンのBASICプログラムみたいな感覚じゃないのか？

>>188
> あれはOOなんて言ってたらメモリが足りないだろ。
OO だと消費メモリが増えるという根拠は？

OOPLの仕組み知らんの？

なんでもかんでも一つのクラスに突っ込んじゃうほうがメモリ効率がいいとか、
変数はstaticにしといた方がメモりを食わないとか。

>>190
もちろん、代表的な Java VM に関する論文とか Inside the C++ Object Model
ぐらいは読んでますが。

>>192
それで？

>>193
繰り返しになるけど
> あれはOOなんて言ってたらメモリが足りないだろ
は根拠がない、もしくは何か勘違いしてると思ったので、根拠を聞いてみた。

根拠もなにも、10kだぜ？
俺は勘違いしてるか？

>>195
- メモリが足りない
- OO だからメモリが足りない

言ってることが別ってことでしょ。

>>196
下らんことでつっかかるな。
そんなん説明するのはめんどくさい。

下らんというか、このスレの趣旨ってそーゆーことじゃなかったのか？　ま、俺は
何でもいいけど。

メモリが足りない＝　メモリが足りる為に最大限の努力をしなければいけない
そオブジェクト指向は基本的に、おぶ

つまり、途中で出た話のように　OO言語を有効に使っていてもOOではないのと同じで
言語の機能は最大に利用しなければいけないけど、注目点は違うという事だ

>>199
日本語で書いてくれよ

あれ？　文字化けしてる？

まあそんな書き直すほどの事じゃないけど
　ようするに、
それよりも優先すべき事があるんだから
そっちをoriented 出来ないって単純な話だよ

>>201
> あれ？　文字化けしてる？
うん。

> そオブジェクト指向は基本的に、おぶ
> つまり、
こんな感じになってるので、何が「つまり」なのか謎。

> それよりも優先すべき事があるんだから
優先も何も、そもそも OO とメモリ使用効率が相反するのかって話じゃなかったの？

携帯Javaでクラスを作れないのはその世界では常識。
空のクラス1個宣言するだけで７００バイト消費するんで使えません。

１０K以内に納めるテクニック
http://www.atmarkit.co.jp/fmobile/rensai/doja07/doja07.html
プログラムの基本は「非オブジェクト指向」で

結局ちょっとしたプログラムにOOを適用する奴なんざぁ、
意味が無いことなんだよな。

>>204
なにから話がつながって「結局」なのか謎だが。

まぁ数千行程度の小規模なプログラムなら OO だろうが手続き型だろうが、設計
なんざしなくても作れるっつー気はするけど。

ハッキリ言って世界中の70％のプログラムにOOはイランと思う。

>>205
ＯＯＰＬでは最初にちゃんと見通しを立てて設計しておかないと、
小規模でも行き詰まります。

>>207
OO じゃなくて OOPL なのか？

手続き型でも同じです。

手続き型なら部分変更で済む場合が多い。

ＯＯなら部分変更で済む場合が多い。

>>207
俺、数千行どころか数万行でも最初に設計なしに作れるよ。　と言ったらどうする？

もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ
使うのは主にDelphiかVC++で、つまりはOOPLだけど
別にオブジェクト指向してるわけじゃない。

ハッキリ言って世界中のプログラムの70％にOOは必要だと思う

>>213
でも世の中のプログラマの70％は、一生ＯＯを理解できない
脳みその持ち主だと思う。

それをプログラマとよんじゃぁいけない。

>>212 それは単に設計が早いだけと申し上げておきます

多態があればＯＯは必要ない

ＶＣ＋＋は除外>>212

ＯＯとか言っても実際、かりそめのクラス作ってるやつばっかりだと思う。

クラスとして静的に定義しなければいけないものと、
パラメータとして実行時に動的に決めるものとの設計時の
切り分けがよく分かりません。後々後悔する事が多いっす。
完成してみたら、存在意義のない間抜けなクラスがあったり
無茶なパラメタライズがあったり。

どうやって設計段階で判断するんでしょうか？

同時進行だ
設計とコーティングは。
そしてリファクタリングを繰り返す。
そうしないと良いプログラムはできない

リファクタリングですかー。

変更管理が面倒くさくないですか？
下位レイヤを変更したりすると、上位でそれ使ってるところを
みんな修正する羽目になるし。

>>212

Ｃ言語ばかり使用していて、やっとＯＯの勉強を始めたばかりですので幼稚な
質問かもしれません。

｜212 名前：デフォルトの名無しさん ：02/02/28 23:32
｜>>207
｜俺、数千行どころか数万行でも最初に設計なしに作れるよ。　と言ったらどうする？
｜もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ

まじめなお話で数千行（数万って…凄いなぁ）もあるプログラムを設計書も作成しな
いで、作れるというのは信じ難いです。
ま、白髪三千丈の類の冗談なんでしょうけど。

ちょうど２２０の人が書いているようにクラスを考えてみたりする必要もあるわけで
すよね、ＯＯなら。
まして、合計で数千もの手続きを経なければならない機能を作り上げるのに、どうし
たら設計が手軽ですむのか、ちょっと教えて欲しいです。

個別のノウハウとか、そういうものを書いてみてください、といっている訳ではな
くて一般論で構わないので。

どうして、こういう物凄い発言が出来るのか知りたいのです。

>>222
その労力を極力軽減するのが OO だ。

ということらしいぞ。

>>223
212は１行もコード書いたことない妄想野郎だからさ

横レスだが、

ＤＢからデータ拾ってきて表示して変更してセーブするだけで、
画面数がやたらに多いのだと軽く逝くけどね・・・。

>>224
本当かなあ…後々静的定義と動的定義を交換するような修正は、
レイヤ間のインターフェイスを変えずに実装だけ変えて済ます
なんてことは不可能だと思うんだけど…

COBOL -> COBOOL

(･∀･)ｲｲ!!

>>227
固定概念を取り払えよ

>>226
そういうのは、1画面分の処理を通せば、後はコピペ(OOPなら実装継承？)
でちょいちょいと変更したのをいっぱい作っていけばいいだけですもんね。

私も、そういうのは設計なしで3万行というのを今書いてるところですよ。
コアだけちゃんと作れば、後は単調な作業が続くんですよねー。

>>229
なにか目のさめるようなアイデアが書いてあるWebページとか本とか
知りませんか？

>>230
うーん。どうにもよくわからないです。もうちょっと教えて欲しいです。

｜そういうのは、1画面分の処理を通せば、後はコピペ(OOPなら実装継承？)
｜でちょいちょいと変更したのをいっぱい作っていけばいいだけですもんね。
｜私も、そういうのは設計なしで3万行というのを今書いてるところですよ。

あの、そういう作り方って、本当にやってらっしゃるのですか？。
似たような処理ばかりで、トータル３万行も？

継承したら、３万行にもなるわけないような気がするのですが、素人の考えなのでしょうか？

>>232
インピーダンスミスマッチの吸収には、どうしても多量の
同じようなコード（あるいはパラメータ）が必要なんですよ…
RDBMSを扱うのは、もういやになりますねー。

>>233
俺もTemplateやら継承やら独自言語作ろうとして失敗した。
まあコードジェネレータ作るのが一番。

>>233
それは、基本的に同じだけど違う部分を手直しする、という意味ですよね、きっと。
Ｃでやっても同じ事ですから、その部分についてはわかります。
でも、なぜそんなに大量に同じようでちょっと違うものを作り込まなければならな
いのかわからないのです。

>>234
RDBMSをなるべく使わない、というのを最近考えるんですけどね。
OODBとか、キー値でハッシュテーブルにしたXMLテキストで永続化とか。
暇な時にトライ中です。

>>235
GUIとRDBMSをつなげて100画面も作ると、そうなるんですよ。

RDBMSを扱うのに、コード生成するようなスクリプトを用意して
モデル記述の言語からすべて生成されるような仕組みにするのが、
よく使う逃げですね。

プログラマーの持つ最大にして唯一の能力は機械に仕事をやらせることで
す。
医者の不養生といいますが、プログラマーは、お客サンのためだけでなく、
自分のためにもめんどくさがりや精神をもっと発揮すべきなんですよね。

美学からいくと、生成したものは、Artではない気がする。そこの
プログラマーの心理的な抵抗がある気がする。
きっと、生成すらしなくてよいようなフレームワークがあるんだろうな。
なんだろう？

いやいや、御客の要望。見た目などで自動生成ではなかなか済まない。
（済まないと予想される）
例えば、同じアイテムなのに、
ある画面では「氏名」
ある画面では「あなたの名前」
ある画面では「姓」「名」だったり・・・。

俺より頭がいいやつは全員氏ね

>>238
高速に動作する複雑な構造化問い合わせの機能が必要なければ、
RDBMSを使用しないというのは、かなり良い解決策だと思うん
ですよ。

検索のパターンだけ洗い出しておいて、RDBMSのスキーマ定義を
単純化して(可変長バイナリのカラムを用意する)、問い合わせ結果
をプログラム側で動的に解析するというのも、メモリとCPUパワー
に余裕があるなら、いける、かな？どうでしょう？

同一パタンならバルク転送しろよ

>>241
オブジェクトのストアとしてRDBMSを使っちゃえ、ということでせうか。

>>239
失礼しました。ほんとに使いごごちの良いアプリってモデル記述
言語をがんばってもそれが複雑になる一方というか、、、
モデルとビューとコントローラーは果たして分離できるのか。
それすら怪しい。。「オブジェクト」指向じゃだめなんでしょう。

なんかこう、多態で、可変で、そんな生き物みたいなもの、、
幽玄指向でいきましょう。

>>238 がいい事言った！

> 医者の不養生といいますが、プログラマーは、お客サンのためだけでなく、
> 自分のためにもめんどくさがりや精神をもっと発揮すべきなんですよね。

優れたプログラマは皆面倒くさがり屋である。
面倒くさがり屋であるが故に何でも自動化しようとし、プログラム技術が上達する。
しかし、面倒くさがり屋なので脳内設計が多く、上に立つ人間には向かない;->

>>244
↓ここのうけうりです。
See -> http://www.pragmaticprogrammer.com
邦訳は達人プログラマーね。

>>223
>まじめなお話で数千行（数万って…凄いなぁ）もあるプログラムを
>設計書も作成しないで、作れるというのは信じ難いです。
>ま、白髪三千丈の類の冗談なんでしょうけど。

俺、212じゃないけど、数千行程度なら「設計書」なんぞ書かなくても
楽勝で書けるよ。これぐらいなら当たり前じゃなかろうか。
別にコピペの塊じゃない。

C/C++なら、ヘッダファイルが十分「設計書」の役割を果たすと思う。
数千行程度のゴミプログラムで、それもひとりで書いてるんならね。

1関数で数千行書く奴もちょくちょくいるが(鬱 そういう話をしている
のでもない。

>>223
マジメに聞いてるようなんで　マジメに答えましょう
好きな道具はDelphiです。
DelphiはOOPLですが設計にクラスわけなんてオブジェクト指向してる訳じゃないんで
別に最初に考えたりしません。　クラスは再利用したりしません。ただコンポーネントは
再利用出来ますが。
　まあ具体的な話の方がいいでしょう

慣れれば、会計処理なんて定型ですから必要な印刷物が判れば必要な入力画面もわかります
仕事貰ったら、印刷イメージ見ながら、どんどん入力画面作ります。画面作りながら SQLのCREATE文
書いてゆきます。　　画面できたら客に使わせて入力させてゆきます。
それから印刷にかかりますが、印刷はお客さんにはコダワリが必ずあるので、貰ったイメージ通りに
作ればOKとはゆきません。
簡単なテキストスクリプトを作って現場で微調整できるように用意しておきます。
入力画面の要望聞きながら１ヶ月後には印刷部も出来上がります。
それで印刷させては客先で調整します。
　だいたいこれでコードは数千行です。

その後、色々細細と客の注文を聞いて便利機能を付け足します。
便利機能は手間がかかりますから、最初の状態から、だいたい２〜５倍のコードになります。
それは客の予算によってという事です
予算があれば最終的に数万行になるというだけです

だから数千から、MAX 1万行ぐらいの単位でモジュール分割して
(このモジュールはクラスではない。Javaならpackage相当)、
それを組み合わせて全体のプログラムを作るって感じかな。

「数千から、MAX 1万行ぐらいのモジュール」の外向けのインタフェースと、
それをどう組み合わせるかについては、さすがに文書化するけどさ。

まるでランボー(w

映画ではヒーローだけど
戦場ではちょと迷惑ね

>>246
数千行程度ならあたり前のゴミプログラムとか言ってるお前、
プログラム下手すぎだな。（ﾜﾗ
上手いコードほどコード量は少なくなるはずなんだが。

>>250
ちょっとしたスクリプト作れば簡単に数千行いくだろ
そうじゃないというなら見せて貰いたいもんだ。どうせ見せられないだろうがな（ﾜﾗ

普通にちょっとしたコントロール一つ書いても千行は必要だぞ

>>24の
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/lounge/file/1004530597_1/MyDraw.pas
このコードすごいな・・・コードものすごいというかさっぱり判らんけど走らせたら・・・

>>251>>252
そもそも何行かかるかなんて言語にもよるってのは置いといて、
そのちょっとしたスクリプトだかコントロールだかで
数千行かかってしまったという痴態をここで晒してみそ？

>>246〜
どうもありがとうございます。

会計処理や事務処理分野は、私はよくわかっていませんので「定型的」と
言われてしまうと「そうなんですか」としか答えられませんが、「C/C++
なら、ヘッダファイルが十分「設計書」の役割を果たすと思う。」という
ような事が、本当にあり得るのか、わかりません。

２４６さんや２４７さんのやられている分野でも、試験の工程は必ず存在
しますよね。

設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
品質の確保をどのように行っていくのかがわかりません。

また、無理に再利用をしなくても良いとは思いますが、なんらかの修正
・機能追加を後日行わなければならなくなった時に、頼りになるのがソ
ースだけというのは、非常に効率が悪いと思いますが、ＯＯの開発環境
では１万行にも及ぶプログラムでも大丈夫なのでしょうか？

>ちょっとしたスクリプト作れば簡単に数千行いくだろ
Perlで数千行・・・悪夢

各自の“ちょっとした”の基準が統一されてないんだから、
話がかみ合わなくて当たり前。

2chでよく見る光景。

ちょっとしたスクリプトで数千行も書いてしまう馬鹿は
まずは構造化プログラミングから学習してください。

久しぶりにこのスレを見たので
ちょっと２４に意見を書いてみる。
ちなみに、リンク先のコードは読んでいません。

最近、３つのサーバーが相互作用するプログラムを設計しました。
（まだコーディングは終わってません）
驚いたことに、OOのメリットはほとんど出てきませんでした。
サーバーを３つに分けてること自体がOODという見方もできるかもしれませんが、
個人的にはカプセル化とポリモーフィズムこそがOOだと思っています。
そして、カプセル化とポリモーフィズムを基盤とした設計こそがOODだと思っています。
だから、サーバーを３つに分けたのは単なるモジュール化ですね。
話しがそれましたが、プログラム（のコンセプト）によってはOOのメリットが見えずらい物が
あるようです。

>ただ、元のギコBASICはこれを継承してテキストスクリプトでグラフィック描画>が出来る
>コンポーネントになっていました。
この発言はOOを勘違いしているように思えるのですが、
完成したプログラムはコンポーネントに必ず成ると思います。
OOで設計されたプログラムは、簡単にキーワード（予約語（intとかの事))を追加して
機能拡張できるといった具合になってるはずです。

最初から仕様がしっかり決まっていて、
アルゴリズムを変更する可能性が０で・・・
といった単純なプログラムであれば、どんなに大きくても
OOのメリットはあまりないですね。
でも、そんなプログラム書いてる人って
いわゆるコーダーなんですかね。

４層構成とか逝って、ベースになるクラス・ライブラリからアプリまで、
全部手書きすれば、予想外の分量になる事もあるかもね...

んでも、既存のクラス・ライブラリやフレームワーク探さずに
手書きしてたら、「勉強中の人」か「DIY趣味の人」て感じかな。

> 最初から仕様がしっかり決まっていて、
> アルゴリズムを変更する可能性が０で・・・
それは、PMやSEが余程有能ならそういうプロジェクトもあるかもしれんが、
現実にあんのか？

> でも、そんなプログラム書いてる人って
> いわゆるコーダーなんですかね。
わけわからん。
「そんな」って、上に挙げたのはプログラムの質ではなく、
プロジェクトの質では？

>>259
へいへい、自分のスレにお帰り

>>261
程度の問題ね。
端的な表現で悪かった。

でもさ、なんでもプロジェクトで考えるのはよくないよ。
プログラムといえば、使い捨てスクリプトから複雑怪奇な人工知能とかまであるわけでしね。

>>263
ならなんで
> いわゆるコーダーなんですかね。
こんな台詞が出てくるのか？

> といった単純なプログラムであれば、どんなに大きくても
> OOのメリットはあまりないですね。

> 驚いたことに、OOのメリットはほとんど出てきませんでした。
つまり、今のあなたは単純なプログラムを書いている

> いわゆるコーダーなんですかね。

>>262
John と書いてなければ、もう少しまっとうな回答も期待できたものを…（ｗ

>>255
>設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
>品質の確保をどのように行っていくのかがわかりません。

UnitTest使えば簡単。

だけど品質管理部門が許可してくれないかもしれないという罠。
設計書なんぞ飾りです。
偉い人にはそれが解らんのです。

ちょっとしたスクリプトは　 >>24の１
ちょっとしたコントロールは　>>24の２　を基準にすればいいだろう

これらをまともに仕事で使えるようにしたら少なくとも倍にはなると思うぞ
それにヘタにOO設計でもすれば1桁サイズが大きくなると思うが
そうじゃないというなら書いてみたらどうだ？

>>255
　ヘッダファイルが仕様書になるように作るという事でしょう

＞機能追加を後日行わなければならなくなった時でも
RADツールでの開発品だと、プロパティやイベントが解読の手助けになる事が多いですね

>>268
> それにヘタにOO設計でもすれば1桁サイズが大きくなると思うが
ならんて。

OO だと、確かに手続き型に比べてサイズが大きくなる傾向はある。特に C++
だとコンパイル時の依存関係を減らすために pimpl イディオムを使っったり、
メッセージの転送を行うだけのメソッドを書くことが多いから。

それでも一桁も差は出ないよ。

> そうじゃないというなら書いてみたらどうだ？
さすがに同一仕様のスクリプトを OO, 非OO で書いたことはないけど、これまで
Perl, C, C++ あたりでスクリプトを作った経験から。

一番短かったのは Perl でした。字句解析は、組み込みの正規表現パターンマッ
チングと hash で済ませて、構文解析は内部で Perl スクリプトを作って eval() で
済ませた（ｗ

>>259
複数のサーバがやりとりするような場合はオブジェクトより
もっとデータ中心で考えないといけないからね

「データ指向」とか呼んでる人もいるから検索して読んでみたらどう？

>>270
　たぶんそのコードをこのスレでさらしたら「それはオブジェクト指向じゃない」
といわれるだろうな

正直 >>24 の３以外は　オブジェクト指向してると俺は思うけどなぁ

>>270　オブジェクト指向信者はスクリプトもオブジェクト指向でないと納得しないから
勝手にやらせたら１０倍どころじゃない事に・・

>>272
っつか、このスレで「GikoBasic はオブジェクト指向じゃない」と言った本人だったり
するわけだが。

>>24
　 　 　 　 │＼
┌───┘　 ＼
│　 　 　　　　　　＞
└───┐　 ／
　 　 　 　 │／　　こんな矢印

ﾜﾗﾀ

>>276 スゲー　単に矢印ひくだけかと思ったら　CADみたいにグリグリ動かせる

この矢印コンポをオブジェクト指向してないと言い出すと　VCLもクラスライブラリじゃないという事に・・・

>>270
> さすがに同一仕様のスクリプトを OO, 非OO で書いたことはないけど、これまで
> Perl, C, C++ あたりでスクリプトを作った経験から。
桁が増えるかどうかはライブラリやコンポーネントが充実しているかどうかで決まらないか？

例えば、C++でC言語の標準関数並のライブラリだけでOOしたら簡単に1桁は突破しそう

なるほどなるほど、ちょっとづつわかってきました（？）。
みなさんの話題は、コーディングや実装と、モジュールレベルの単体試験と
いった工程に話を限っているのですね、きっと。

だから、私は、みなさんの話に付いていけずに、？？？となるのでしょう。

｜267 ：デフォルトの名無しさん ：02/03/01 12:35
｜>>255
｜>設計書相当のものがなくて、どうして試験仕様が作れるのかという点と、
｜>品質の確保をどのように行っていくのかがわかりません。
｜UnitTest使えば簡単。
｜設計書なんぞ飾りです。

できあがったクラスの試験では、それで十分なのかもしれませんね。
でも、クラス自身の設計が適正であるか、全体の動作が正しいか、異常ケース
検証は出来ないですよね。
そのへんが知りたいです。

｜269 ：デフォルトの名無しさん ：02/03/01 14:23
｜>>255
｜　ヘッダファイルが仕様書になるように作るという事でしょう

それは、理解しています。
ですが、「わかる」「やさしい」という定性的な表現は、なかなか難しい
ですし、クラスの動作自体がわかったところで「なぜそれをするのか」が
わからなければ、結局「わかった」とは言えないのは誰でも理解できると
ころですよね。

まして、ここで話題になっているのは万単位のステップ数にもなる大きな
プログラムです。
数千、数万もの手順を踏まなければ機能しないプログラムで、個別の動作
を知るだけでは、理解できたとはなかなか言えないのではないでしょうか。

クラスの設計そのものがまだよくわかっていませんので、ヘッダファイル
にすべてが記載されていないＯＯのプログラムは、論外の品質である、と
いうようなものであるならば、また話は別になると思いますが。

引用前後してしまったが

>>280
> まして、ここで話題になっているのは万単位のステップ数にもなる大きな
> プログラムです。
> 数千、数万もの手順を踏まなければ機能しないプログラムで、個別の動作
> を知るだけでは、理解できたとはなかなか言えないのではないでしょうか。
それがカプセル化の一部であってOOの利点の一つだと思う。
すべてを理解出来なくても(知らなくても)コーディングが出来ると。

で、
> できあがったクラスの試験では、それで十分なのかもしれませんね。
> でも、クラス自身の設計が適正であるか、全体の動作が正しいか、異常ケース
> 検証は出来ないですよね。
> そのへんが知りたいです。
設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
すべてが正しいことが保証される。
バグのないクラスをいくら組み合わせてもバグは発生しないっつー考え方だと思うが。

だからといって総合テストでバグが出ないわけではないが（ｗ

>>280
> まして、ここで話題になっているのは万単位のステップ数にもなる大きな
> プログラムです。
いや、数万ステップ程度だと「大きなプログラム」とは言わないんだけど。

ただ、数万程度でも「ヘッダに書いてあるでしょ」で理解できる規模は超えてる
けど。

>>281
追記

ソフト全体を見渡したとき、API的な関数すべてが並列に存在してるものを理解するよりも
オブジェクト単位で考えたほうが見通しはいいと思うんだが。

非OOでもソースの見通しをよくするためにファイル分割するんでしょ？

ようはあれだ、アンチもUMLは最低読めるようにしとけってことだ。
会話が成り立たないからな。

この人のOOが理解できず構造化手法原理主義者への道は内の学校では有名.
ttp://members.tripod.co.jp/aspara_2000/
一緒の会社にならない事を祈るばかり.(藁

>>280
>みなさんの話題は、コーディングや実装と、モジュールレベルの単体試験と
>いった工程に話を限っているのですね、きっと。
>
>でも、クラス自身の設計が適正であるか、全体の動作が正しいか、異常ケース
>検証は出来ないですよね。

もしかしてUnitTestの事を"単体テスト"と直訳したのかな。
xUnitとかTesting Frameworkって書けば良かったか。
とにかく、OOやってるならXPの事もちょっとは知っておいた方が良いよ。

>>285
構造化手法原理主義というよりはソフト工学絶対主義という感じね。
それにしてもこれだけ偏った思考をする人もめずらしい。

>>281,2,3
どうもありがとうございます。

｜> 数千、数万もの手順を踏まなければ機能しないプログラムで、個別の動作
｜> を知るだけでは、理解できたとはなかなか言えないのではないでしょうか。
｜それがカプセル化の一部であってOOの利点の一つだと思う。
｜すべてを理解出来なくても(知らなくても)コーディングが出来ると。

カプセル化の利点は仰るとおりですね。
しかし、利用しようとするクラス・関数の目的と適用範囲を知らないと
いけないですよね。メーカ配布のクラスライブラリ（ＭＦＣ等でもいい）
を使用する場合は、それでも構わないと思いますが、社内の別プロジェ
クトで制作したようなものの場合は、やはり「設計書」が必要なのでは
ないでしょうか。

すべてを理解する必要はなくとも、使うに当たって必要な動作確認はし
なければならないわけですし。

｜設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
｜すべてが正しいことが保証される。
｜バグのないクラスをいくら組み合わせてもバグは発生しないっつー考え方だと思うが。
｜だからといって総合テストでバグが出ないわけではないが（ｗ

ご自分で書かれている通り、バグを含まないモジュールを組み合わせても、不具合は出ますよね。
だから、わからないな、と思っているのです。

また、一万ステップが大きい・小さいというのは感性評価なので、どちらでも結構ですが、いず
れにせよ、隅から隅まで覚えていられる分量は超えていますよね。

>>288
｜設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
｜すべてが正しいことが保証される。

すべてのテストコードを書くの難しいんだよね。
みんなちゃんと書いてる？

>>288
なぜメーカ配布のクラスライブラリは設計書は無くても構わなくて、
社内だと設計書が必要なの？

まさか結合テストでホワイトボックステストをやろうとしているのか？

>>286
｜もしかしてUnitTestの事を"単体テスト"と直訳したのかな。
｜xUnitとかTesting Frameworkって書けば良かったか。
｜とにかく、OOやってるならXPの事もちょっとは知っておいた方が良いよ。

一応、直訳したわけではありません。恥ずかしながら、不勉強でちゃんと
理解したとはとても言えませんが、エクストリームプログラミングは講習
を一度受けた程度で、なかなか興味深い開発手法ですが、開発体制を根本
から変えなければならないため、思案しているに留まっています。

>>290
｜なぜメーカ配布のクラスライブラリは設計書は無くても構わなくて、
｜社内だと設計書が必要なの？
｜まさか結合テストでホワイトボックステストをやろうとしているのか？

うーん、文章力がなくてすみません。
ブラックボックステストをやろうとすると、設計書が必要ではないですか
といいたい訳です。

中身の詳細はともかく、このクラス・関数群は何をするものなのか、いち
いちソースを読まなければならないのであれば、非常に効率が悪いのでは
ありませんか？　という疑問です。

メーカの配布のライブラリを使用するのに制約をつけないのは、一つ
目には、設計書相当の文書・市販の解説書が存在するからです。
必要があれば、講習会を受講する、サポート契約を結ぶなどなど理解
するための補助手段も豊富に存在します。

また、マイクロソフトほど大きな会社では、すぐに対応してくれると
は思えませんが、基本的には市販品を購入した場合には、バグがあれ
ば、メーカに対応してもらえることも、理由となります。あんまり関
係ありませんが。

とあるダメ社員さんye
>>24　の１，２のコードは千行前後あるけど　読める人は苦も無く読んでるでしょ？
あのコードはコメント多くとは言えないし、親切なコードでもない。
でも、Delphi知らない人でも平気で読んでるわけで、　それはどうしてだと思う？

>>293
> でも、Delphi知らない人でも平気で読んでるわけで、　それはどうしてだと思う？
俺に限って言えば、過去に同じようなプログラムを作ったことがあるから。コンパ
イラ／インタプリタを一回作ったことがあれば、コードを読むポイントはC だろうが
Delphi だろうが、あまり変わらん（と思う）。

現場を見据えつつ書いたつもりなんだが

>>288
> ご自分で書かれている通り、バグを含まないモジュールを組み合わせても、不具合は出ますよね。
> だから、わからないな、と思っているのです。

それはソースの実装が悪いのではなくて、設計がわるいからでわ？
それがOOの欠点なんだろうが、設計が完璧であれば(たぶん)そういう問題は発生しないと思われ。
完璧な設計でバグのないクラスを実装させるわけだから。
このへんが「XPってあくまで理想論なんでしょ」って煽られるとこだと思うが。

>>289
UnitTestはやったことない（ｗ　が、　似たようなことならみんな我流でやってるよね？
Cとかなら#indef DEBUGにテストコード書いたりとか。
XPはそれの拡大解釈くらいで考えてる。

>>292
設計書と仕様書を混同していないか？

> ブラックボックステストをやろうとすると、設計書が必要ではないですか
> といいたい訳です。
仕様書があればブラックボックステストはできるはずです。
また、マイクロソフトではMSDNなどのメソッドの解説は仕様レベルであり、
設計まで公開したものは見たことありません。
# 仕様から設計が推測できるのはいくつかあるが

>>295
> UnitTestはやったことない（ｗ　が、　似たようなことならみんな我流でやってるよね？
達人プログラマの「容赦ないテスト」とかね

>>296
理解力がなくてすみませんが、文脈上、あなたが何を仰りたいのかわかりません。

設計書とか仕様書という単語は、その方の属している文化による方言があるの
で、この場では私は区別して使っていません。
強いて言えば、プログラムそのものではなく、その機能の説明・目的などが書
かれた文書、プログラム群全体の目的や機能が書かれた文書といった程度にな
ります。

このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
る。ソースだけ。」といった趣旨の事が書かれています。

従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
いている趣旨だったのです。

ここでなぜ、設計書・仕様書の区別が問題となるか、わかりません。

296 ：デフォルトの名無しさん ：02/03/01 21:39
設計書と仕様書を混同していないか？
> ブラックボックステストをやろうとすると、設計書が必要ではないですか
> といいたい訳です。
仕様書があればブラックボックステストはできるはずです。
また、マイクロソフトではMSDNなどのメソッドの解説は仕様レベルであり、
設計まで公開したものは見たことありません。
# 仕様から設計が推測できるのはいくつかあるが

俺の問いかけは無視かい・・・

設計図なしに作れる秘密はそこにあるのにね

>>298
> このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
> る。ソースだけ。」といった趣旨の事が書かれています。

はて？このことか
｜俺、数千行どころか数万行でも最初に設計なしに作れるよ。　と言ったらどうする？
｜もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ

> 従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
> それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
> いている趣旨だったのです。
この発言ならば、「設計なしに」とは書いてあるが、「設計書なしに」とは
書かれていないし、「必要な帳簿のイメージのFAXは貰う」と言っている
# なお、この発言をしたのは私ではない。

この場合、「必要な帳簿のイメージのFAX」が
「その機能の説明・目的などが書かれた文書」に当たると思うが？

>>293
｜293 名前：デフォルトの名無しさん ：02/03/01 21:22
｜とあるダメ社員さんye
｜>>24　の１，２のコードは千行前後あるけど　読める人は苦も無く読んでるでしょ？
｜あのコードはコメント多くとは言えないし、親切なコードでもない。
｜でも、Delphi知らない人でも平気で読んでるわけで、　それはどうしてだと思う？

今、２４のリンク先を見てきましたが、うーん、私のスキルが足りないのでよくわかり
ませんでした。でも、仰る通り、読める人は読んで、短時間の内に改造まで加えられる
ようですね。単純に自分のスキル不足を恥じるばかりです。

>>295
｜295 名前：281 ：02/03/01 21:38
｜現場を見据えつつ書いたつもりなんだが
｜>>288
｜> ご自分で書かれている通り、バグを含まないモジュールを組み合わせても、不具合は出ますよね。
｜> だから、わからないな、と思っているのです。
｜それはソースの実装が悪いのではなくて、設計がわるいからでわ？

そのあたりが、わたしがよく理解できていない部分なんです。
クラスの実装とは、設計そのものに匹敵するような、構造を規定する部分ですよね。
従って、設計が悪いというのは程度問題ではあるのですが、実装が悪いのか設計が検討不足なのか
わかりづらい部分です。

>>296
MFC のクラス階層図は、あきらかに「設計」の範疇だと思うが。個々のメソッドの
リファレンス以外に、暮らすライブラリのフレームワークの概要を記述した文書も
MSDN Library には入ってるぞ。

（MFC の出来／不出来はともかく）

>>300

為にする議論は、あまり好きではありません。

｜300 名前：デフォルトの名無しさん ：02/03/01 22:32
＜略＞
｜俺、数千行どころか数万行でも最初に設計なしに作れるよ。　と言ったらどうする？
｜もちろんユーザから必要な帳簿のイメージのFAXは貰うけどさ
｜> 従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
｜> それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
｜> いている趣旨だったのです。
｜この発言ならば、「設計なしに」とは書いてあるが、「設計書なしに」とは

設計せずに設計書が出来るわけはないのは、自明ですよね。
あまりといえばあまりな発言だと、わたしは思います。

｜書かれていないし、「必要な帳簿のイメージのFAXは貰う」と言っている
｜# なお、この発言をしたのは私ではない。
｜この場合、「必要な帳簿のイメージのFAX」が
｜「その機能の説明・目的などが書かれた文書」に当たると思うが？

仰る通り、設計書の一部にはなりますね。客先からの要求仕様とでも呼ぶモノの一
部ではあると思います。しかし、アウトプットのイメージだけ見せられても、客先の要
望がすべてわかるはずもないと思っていますが違いますでしょうか。

とあるダメ社員さんye
　そういう事。　単純にスキル不足つまり経験の差。
　設計図が無ければクラスライブラリも使えないなんて甘えた事じゃホントの経験は身につかないさ

>>304
まさか。

クラス階層図ぐらいはないと話にならんし、template method を使ってるような
場合 (MFC でも PreTranslate ウンチャラとかで使ってる) には

- そのメソッドがフレームワークから呼ばれるタイミング
- 呼ばれるメソッド中でやって良い事 (pre-condition, post-condition)

なんかは明確にドキュメント化してないと、危なくて使えないでしょう。MFC だと
最悪「ソースを読め」なんだが、ソースコードがないライブラリも存在するわけで。

とあるダメ社員の丁寧な発言ぷりにちょっと感服
あとでじっくり読んでみようかな。

>>271
データ指向調べてみます。

>>285
なんかすごそう。
あれで２年生ってすごいな。
掲示板に書き込みたいんだけど、どうやって書き込むんだ？
ここ見てたら教えてくれ。
それと、一回会ってみたいな。
学校どこだろ。

話は変わるけど、MFCはOOじゃないっていうのが定説なんだっけ？

>>307
それはどこで定説になったんだ? まさか2ちゃんではあるまいな?

(M)マッキントッシュ・(F)フライド・(C)チキン

>>309
せめて
(M)マクドナルド
にしてくだちい。

MFC といったら、個人的には MS のヤツか Merge From Current だが。

>>306 やぼようで書き込み禁止にしているって書いてるじゃない。
２週間まって書き込もう。

(M)ﾏﾀｰﾘと・(F)風呂入って・(C)チチ揉み

>>301
> そのあたりが、わたしがよく理解できていない部分なんです。
> クラスの実装とは、設計そのものに匹敵するような、構造を規定する部分ですよね。
> 従って、設計が悪いというのは程度問題ではあるのですが、実装が悪いのか設計が検討不足なのか
> わかりづらい部分です。

あくまで個人的な考えだが、OOPLで考えた場合、仕事のレベル的に
　クラスなどの設計：プログラマーの仕事
　クラスメソッドとかの実装：コーダーの仕事
ぐらいで考えてる。

実際JavaとUML使えばコーディングするのはメソッドの内容とかの
(純粋な意味での)コード実装部だけでしょ？

OO + XP的な考え方だと(要求仕様を満たすという点で)実装が悪いつーのはあり得ない。
要求仕様を満たせるようなソフト設計をしていることがあくまでも前提だと思うんだが｡
「とりあえず動けば」的な実装だとちゃぶ台返しの危険性があるから
そのリスクを回避するためのリファクタリング＆短期リリースなんじゃない？

数千行ぐらいなら「設計書」はなくても書ける、と言ったのは俺なんだけど、

>>248
>「数千から、MAX 1万行ぐらいのモジュール」の外向けのインタフェースと、
>それをどう組み合わせるかについては、さすがに文書化するけどさ。

「外向けのインタフェース」に関しては文書化すると書いている。

モジュールの「仕様」ってのは、外から見える部分のことでしょう。
で、外向けの仕様がちゃんと定義されていれば、ブラックボックス
テストはできる。だから、「仕様書」は書くよ。

でも、「設計書」と言ったら、そのプログラムの内部の設計のドキュメントの
ことを指すでしょう。こんなもんなくても数千行ぐらいヘッダファイル見ながら
書けるのが普通。

OOに限らず、手続き指向でもモジュールの内部的な実装は隠蔽するはずだから、
「仕様書」と「設計書」は明らかに別物でしょ。「設計書」がないとテスト
できないようでは、実装筒抜けのタコモジュールだということ。
# もっとも、ややこしい呼び方をしたときの挙動などが実装に依存してしまう
# ことはないわけではないが (藁

だいたい、元の発言が、
>まじめなお話で数千行（数万って…凄いなぁ）もあるプログラムを設計書も作成しな
>いで、作れるというのは信じ難いです。

こうなんだから、「できるよ」と答えたまで。
保守まで考えると設計書も必要なこともある。そういう場合、たいていは
コーディングの後で書く (^^;

あとさ、「とあるダメ社員」さんが、数万行やそこらのプログラムを
「大規模」だと思っているフシがあるのがどうも…

1万なら小規模、数万〜十万ぐらいで中規模、大規模といったら…
もう果て無し、ってとこかなあ。WordやExcelだって、百万単位でしょ。
# だから、アンチMS連中が少々粋がったって、なかなかアレには
# 追いつけない...

で、世間で業務に使われているプログラムには、WordやExcelなんぞとは
比べ物にならないほど巨大なものもあるわけで。もちろん、そのソースには
思いっきりﾄﾞｷｭｿなものも含まれているけど(鬱

「数千」なんて、どう考えたって「ゴミ」。プログラマは現在、そういう世界に
住んでいる。

ちょっと遡るけど、
>>285 オブジェクト指向にこだわらず、
　　　オートマトンとかペトリネットとかやればよいのでは...

　　　状態をオブジェクトにせず、特定のオブジェクトが状態遷移するよーな
　　　モデルを考えると、確かにはまるみたいですね.

　　　アナパタ本解説ページの多重分類と動的分類の説明読んで、
　　　「そこまでやらんとモデリングできないのぉー」と、
　　　ちょっと面倒な感じがしましたです.
　　　

>>295
>UnitTestはやったことない（ｗ　が、　似たようなことならみんな我流でやってるよね？
>Cとかなら#indef DEBUGにテストコード書いたりとか。
>XPはそれの拡大解釈くらいで考えてる。

全然解ってないのね。
XPについて語るならとりあえずxUnit使ってからにしてよ。

>>289
＞設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
＞すべてが正しいことが保証される。
要求仕様的に正しいかどうかはともかく、
単体で（そして統合しても）書いた人が意図したように動くことが保証される。
TestCase をきちんと書いてる限り、
どれだけコードを追加、修正しても保証されるのがポイント。
はっきりいってデバグがすげー楽。

>>304
わたしの以前の意見を少し訂正します。

>>24の１行目のテキストをオフラインでちょっと見てみました。
ダイアルアップなので、オンラインだとお金が気になってしまいます。

｜>>293
｜293 名前：デフォルトの名無しさん ：02/03/01 21:22
｜とあるダメ社員さんye
｜>>24　の１，２のコードは千行前後あるけど　読める人は苦も無く読んでるでしょ？
｜あのコードはコメント多くとは言えないし、親切なコードでもない。
｜でも、Delphi知らない人でも平気で読んでるわけで、　それはどうしてだと思う？
＜略＞

回答として、私自身のスキルが足りない、と書きました。

｜304 ：293 ：02/03/01 23:14
｜とあるダメ社員さんye
｜　そういう事。　単純にスキル不足つまり経験の差。
｜　設計図が無ければクラスライブラリも使えないなんて甘えた事じゃホントの経験は身につかないさ

読んでみましたが、まだまだ改造できるほど理解できている訳ではありません。デルファイ自体知らないこともあり、スキルが足りないことを改めて自覚しました。

しかし、２４の目的とする事は比較的明確ですね。読まなければ目的がわからないプログラムではない。
単にBASICを２ｃｈで使われているような言葉に置き換えて動作する言語を作ろう、という事だと思います。
つまり、ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のことであるように思います。
言ってみれば、ユーザが開発者を兼ねるようなケースですね。

プログラムの動作はわかる。しかし、意味がわからないという点が設計書（仕様書でも良いです）の必要性を端的に示す点だと思っています。
それが不要である例を使われてしまうと、議論が迷走してしてしまうように思うのですが、どうでしょうか。

3段階だな
・言語への知識
・クラスライブラリの対象ドメインへの知識
・クラスライブラリそのものへの知識

Java を知って、XML と DOM/SAX を知って、Xerces の使い方を知れば
Xerces が使えると。

>>298
＞このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
＞る。ソースだけ。」といった趣旨の事が書かれています。

＞従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
＞それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
＞いている趣旨だったのです。

一人で書くなら10万行でも設計書は要らない（納品に必要なけりゃ）。
何故ならそのプログラムを熟知してるから。
まあ、忘れっぽいので記憶の助けのためにメモ書きくらいはするかもしれん。

10人で作るとして、きちんとした形式の設計書は要らない。
何故なら設計は日々変わるし、結局コードを読まなきゃいけないので。
図や説明を手書きで書いて、質問されたらその都度答える。
形式にこだわった文書は取りこぼしが多い。

どうでもいいんですが、OMGのサイト落ちっぱなしになってる
ことないですか？ここで馬鹿されてるようなアンチOOにサーバー
はくられたとかそんなことあるんでしょうか？

>>320
＞それが不要である例を使われてしまうと、議論が迷走してしてしまうように思うのですが、どうでしょうか。
それが必要である例だけ使っても、議論にならなと思うのですが、どうでしょうか？

つか、設計書と仕様書の違いがわかっているように見えないので、なにを議論したいのか不明です。

>>318
> 全然解ってないのね。
> XPについて語るならとりあえずxUnit使ってからにしてよ。
XP使ってないとそれについて意見したりしちゃいけないの？
概念的にわかりやすいから例として挙げただけだが。

おれの場合は個人で概念だけを導入するくらいまでしかいってないんだが、
実働プロジェクトでXP導入してるとこってまだまだ少ないと思うんだが気のせい？

普通(っていうのもびみょーだが)

仕様書：ソフトウェアに要求される機能などを定義する(SEの仕事)
設計書：そのソフトウェアを実装するためのソフトウェア設計を文書化したもの(プログラマの仕事)

くらいだから、設計書がなくてもなんとかなるわな。

実際戦場だと設計書が実装のあとになることが多いし（ｗ

>>325
辻褄合わせの作業がいかにおおいことか。。

>>320
＞ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のこと
それはどうかな？
basicという用語を知ってたからコメントやソースを見て判ったのでは？
つまりそれを見る為の知識の一部があったからでしょ？
それとも使われてる再帰下降法から判ったの？


「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・勉強不足だよ。
社会常識や技術の常識は勉強しておくのは普通でしょ？

途中で欲しい出力のイメージさえ判れば入力画面もコードもデータベースも判るという話が出てた
けど、それが普通であって、　分析とか設計とか必要なのがプログラマとしては異常な事だと思うよ
もちろん会社全体としては経験不足の要員でも仕事が出来るよう色んな対策をしなければならな
い訳で、しかし開発要員が全員それじゃダメでしょ？

ああ、勘違いされそうだから言っとくけど
会社として　分析とか設計とかの工程を入れて、ドキュメントを残す事は必要な事だから
会社員なら　それは無視してはいけないよ。
会社員の優先順位の一は会社の為に働く事だからね。

【設計書は戦場では必要なし】スレってここですか？

>>329
　だってOOPLは有効だけど OO つまりOO設計や分析は必要無しが主題でしょ

分析設計工程が無いんじゃなくて、
分析設計工程が打ち合わせ中に終ってしまうんだよね

何年も同じ仕事してたらそういうふうになるのは当然では？

>>331
システムの使われ方に関してユーザ（クライアント）よりも詳しくなってれば、「分析
は打ち合わせ中に終わってる」っつーのも有り得る話だな。ただ、普通はそんなこ
とはない。

金融でも医療でも教育でも、専門家はクライアントでこちらは素人、というケース
が圧倒的に多いもの。その場合には相手が物事をどう捉えているのか、クライア
ントがシステムに何を期待しているのか、そういったことを（断続的にで良いけど）
ある程度の時間をかけて話をして、お互いの理解を深める必要がある。それが分
析。

（専門家なしでやってる作業は「分析」ではなくて「分析まがい」でしかないよ）

>>324
>XP使ってないとそれについて意見したりしちゃいけないの？
>概念的にわかりやすいから例として挙げただけだが。

使ってくれと言ったのは"XPそのもの"じゃなくてxUnitだよ。
混同してる時点で理解度がかなり低いというのは判る？

>概念を導入

って言ってもどうやってイテレーションするの？
リファクタリングするフレームワークが無くちゃ3回目ぐらいのイテレーションで
設計変更に耐えられなくなるよ。
それにね、xUnit自体はXPを前提としなくても十分有効なツールだよ。

なんか、
「戦場では」を前提にするのは虚しいような気がしてきた（W
だって、戦場になってからOO使うかどうか決めるわけじゃないでしょ。
「戦場にしないためにはオブジェクト指向は必要か？」のほうが
多少は意味がありそうな気がする。
ま、２ｃｈに意味を求めるのも何だかなーだが。

>>333
理解度が低いのはそのとーりだが

> って言ってもどうやってイテレーションするの？
> リファクタリングするフレームワークが無くちゃ3回目ぐらいのイテレーションで

導入してると言ったのは"XPそのもの"じゃなくてXPの概念だよ。
混同してる時点で理解度がかなり低いというのは判る？

と煽ってみるてすｔ

>>335
多分ね、xUnitと #indef DEBUG を同等と考えてるから、XPの概念が
導入できてないって思われてると思う。

>>334
> 「戦場にしないためにはオブジェクト指向は必要か？」のほうが
> 多少は意味がありそうな気がする。
多くの戦場ではオブジェクト指向は有効であろう。
でもオブジェクト指向は常に有効ではないし、必要でもない。

OO信者を撃退したと思ったら今度はXP信者かよ
スレ違い、XP信者はXPスレにお帰り。

>>327
> 「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・
> 勉強不足だよ。
世の中、そんな簡単なプログラムばかりじゃないぞ。

DNA 解析のプログラムなんか、動作は分かるが意味がわからなかったりする
し。（聞いたら分子生物学の厚い本と論文渡された…。数学の話は専門だった
から分かるんだが、生物系の話は進展が早くてついていけん）

>>332
この一文が見えてないのか？
｜ 何年も同じ仕事してたらそういうふうになるのは当然では？

> ある程度の時間をかけて話をして、お互いの理解を深める必要がある。
> それが分析。
何年も同じ仕事をしているならば、お互いの理解が深まっている為、
分析の工程を短縮、または省略しても良いとは考えないのか？

（考えなしでやってる工程管理は「工程管理」ではなくて「工程管理ごっこ」でしかないよ）

>>339
確かにそういうのはあるよね。　でもそういうのとは別の話のような気もするし

というか、そういうのいくら文章残したって結局　何やってるかの説明は”論文読め”になるような気もするし

>>340
見えてるけど、実際に「分析なし」で済んだ経験がないもの。

何年も同じクライアント相手に仕事をしてても、その間にクライアントが手がける
ビジネスやら環境だって変化していくから、常に勉強の連続だよ。変化がない場
合にはそもそもシステムに手を入れる必要はないから、保守要員で対応できる。

>>341
DNA 解析みたいな学術的な話に限らず、たとえば在庫管理システムなんかの
データベース設計にしても、業界ごとの支払いの慣習やら何やらが設計に反映
してこないか？　それってコードやスキーマを見ても分からないから、文書化し
てないと後任が困るでしょ。

（実際の企業でも、支払い関係は○○さんに聞け、で他は誰も理解してない場
合もあるけど）

>>340
> ｜ 何年も同じ仕事してたらそういうふうになるのは当然では？

これは危険は思い込み。

顧客が「今」システムを必要としている理由は、
その顧客しか知りえない。
そして顧客はその理由を知っているか又は断片を知っているが、
それを適切に記述できるとは限らない。
その「理由またはその断片」と「記述」を結びつけるのが分析。

すでに339さんが言及していますが。
>>327

｜327 ：293 ：02/03/02 08:56
｜>>320
｜＞ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のこと
｜それはどうかな？
｜basicという用語を知ってたからコメントやソースを見て判ったのでは？
｜つまりそれを見る為の知識の一部があったからでしょ？
｜それとも使われてる再帰下降法から判ったの？

名称と書かれた内容からです。また、わたし自身も未熟なプログラマではあるからです。
知識がある、といってもプログラマなんですから高級言語を使わない人はいないと思います。
プログラマならばほとんど誰でもある程度理解している分野と言って良いのではないでしょうか。

｜「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・勉強不足だよ。
｜社会常識や技術の常識は勉強しておくのは普通でしょ？

ここはすでに339さんが言及していますが、常識や技術の常識と「業務スキル」はまったく別だと
思います。歴史的な経緯で特別な処理を行わなければならない例は沢山ありますし、業界のルール
のようなものであれば、まったく聞かなければわからないものも沢山あります。
339さんが仰っているような、学術機関での難しい例もありますし。

｜途中で欲しい出力のイメージさえ判れば入力画面もコードもデータベースも判るという話が出てた
｜けど、それが普通であって、　分析とか設計とか必要なのがプログラマとしては異常な事だと思うよ

それについては、わたしは否定的な見解を述べています。
アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、全部がわかるわけ
ではない、ということです。

>>336
そうですか。ｽﾏｿ。

つか、おれも理系だが周りの人はバリバリの理系だな。
文系の人みたいにもうちょっと行間読んでYO!

と愚痴ってみるてｓｔ

出力見本だけで仕様のほぼ全部が判ってしまうくらいの案件は結構多いよ？

>>347
ないとは言わん。特にシステムはほとんど変わらず、帳票の形式だけ改修して
くれみたいな仕事だと、ほんとに出力見本だけで終わりだし。

つうか、企業システムの仕様決定でも出力見本でかなり決まってしまいますが
なにか？

>>347
もちろん、そういう例もあるとは思います。
でも、そういう例ばかりではないことも、おわかりですよね。

さらに言うと、出力例だけ要求定義が十分であるような案件で、１００００行もの手続きを経なければならないようなプログラムがはたして本当に存在するのでしょうか？

脊髄反射の反論を繰り返してるだけで、論点が全然見えてこないようなのって、やっぱ、このスレに似合ってる（ｗ

>>349
財務分析用のアプリケーションを組むときに、最後にこんな感じのグラフと表を、
と言われて要件定義できるか？

>>351
だなｗ

ｵﾚﾓﾅｰ

>>323
｜323 ：デフォルトの名無しさん ：02/03/02 06:39
｜つか、設計書と仕様書の違いがわかっているように見えないので、なにを議論したいのか不明です。

設計書・仕様書の呼び方は、その方の所属する文化に応じて変わるので、この場では特に使い分けし
ていません。という事をすでに書いていますが、仕様書として統一した方が良さそうですね。

今後は仕様書として記載します。

>>345
> アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、
> 全部がわかるわけではない、ということです。
「多くの」プロジェクトでは上記の通り。
しかし「全ての」プロジェクトではないことは同意してもらえるかな？

「多くの」場合、定石通りに物事を進めていれば無難に物事を進められるだろう
しかし、「ある場合」には定石を無視することも必要である。

------- 以降独り言 ツッコミ禁止 -------
# だが、これをやって失敗すると次から店員にマークされるという危険も伴う、諸刃の剣。
# 素人にはお薦め出来ない。
# まあお前らド素人は、定石を確実にこなせるようになりなさいってこった。

>>355
> しかし、「ある場合」には定石を無視することも必要である。
定石を敢えて無視するには、それなりの理由が必要だ。納期とか納期とか納期とか。
（違う？）

なんかねえ・・・別に議論なんかしたいわけじゃない。
ただ>>223 で知りたいというから教えてやろうかと思ったが
もしかして余計なお世話？

＞アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、全部がわかるわけ
とかさあ・・・そりゃ当然でしょ？
　判る範囲でどんどん作って判らない部分は客に聞く。　ただし客だって希望をしっかり表現出来る
　訳じゃないから、作って見せて　どうよ？　と聞く
　判らない場所は想像して、そのどの場合でもすぐ対応出来るように準備しとくだけの事でしょ？

もちろんこんなやり方は勉強したての新人じゃ出来ないよ。だから薦めてる訳じゃない。

それともこういうやり方で仕事なんてホントは出来ませんとでも言って欲しいのか？

>>355
｜355 名前：デフォルトの名無しさん ：02/03/02 14:57
｜>>345
｜> アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、
｜> 全部がわかるわけではない、ということです。
｜「多くの」プロジェクトでは上記の通り。
｜しかし「全ての」プロジェクトではないことは同意してもらえるかな？

もちろん、355ですでに書いたように同意はしています。

｜「多くの」場合、定石通りに物事を進めていれば無難に物事を進められるだろう
｜しかし、「ある場合」には定石を無視することも必要である。

どんな場合なのでしょうか。
また、定石を無視するようなケースが、ここでの議論する題材として適切なのでしょうか？。
なぜ、定石が成立しないような無茶（？）なケースをここで言及しなければならないので
しょうか？　教えてください。

>>357
書いてる人間が想定しているシステムの規模やら参加者のスキルやらが
てんでバラバラだから、ある範囲でしか議論が成立しないのは仕方ない。

ま、別に回答は義務でもなんでもないし、ここで議論に負けたからといって
現実世界で悪影響があるわけでもなし（掲示板の議論なんて、最後まで
飽きずに書いたヤツが勝つだけだ）、飽きたら適当なところでストップして
良いって。

> もちろんこんなやり方は勉強したての新人じゃ出来ないよ。
あとは規模にもよるんだよな。システムが大きすぎると、とりあえず作って
みるといっても何百人月必要って話になって、あまり try & error を繰り返
すわけにもいかない。

人が増えると、情報を流すパスの整備とかも必要になるしさ。

>>356
> 定石を敢えて無視するには、それなりの理由が必要だ。納期とか納期とか納期とか。
例えばトム・デマルコの「デッドライン」という本の中では
要求仕様はどーせパクリ製品だからと理由で省略し、
バグはどーせでないんだからという理由で検査を省略している。
その代わりに設計は従来よりも多くの工数をかけている。

# なんかこう書くとドキュソ本のように見えるけど、一応良書だよ

つーかさ、医療にしても、金融にしても、
本当に顧客の業務が顧客より理解できていると思うんなら
プログラマなんてやめて転職したほうが儲かるよ。（W
今は金融はイマイチだけどある意味チャンスだし、
医療は不況知らずだしな。

>>360
> 要求仕様はどーせパクリ製品だからと理由で省略し、
それは正しい判断だな、確かに。

> バグはどーせでないんだからという理由で検査を省略している。
これはかなりヤバそうだが、そのシステム固有の何か特別な要因があるの？

>>356
開発人員が少人数で、顧客自身がシステム化したい事を良く
わかっていなくて、コンピューターに疎い様な場合は、355氏の
書いている事にあてはまると思う。

> 要求仕様はどーせパクリ製品だからと理由で省略し、
ワロタ。潔いな。

>>361
まったくだ。

ただ、プログラマも儲からんわけではないんだが。特にいわゆる上流工程と
言われてる範囲とか、コンサルかねたシステム屋さんとかだと、単価は高い
よ。コーディング屋さんだと、よほど特殊な技術がないと高が知れてるが。

…っつか、技術力ゼロでコード書けねーバカ SE が蔓延してるんだから、そ
いつら追えよ＞要件定義できてコード書ける現場のプログラマ

（その方が顧客も幸せだ、多分）

>>359
おっしゃる通り。　分野によって感覚は違うne
俺だって会計系なら一人で１万行/月程度のコードは書けるけど
組込用のCだと千行/月でも厳しい時があるし
そもそも始めての環境だと1ヶ月くらい助走期間が必要だしne

>>358
> どんな場合なのでしょうか。
このスレで書いてあるとおり
この判断は言葉で言えるほど簡単ではない
残念ながら勘と経験を積んで悟るしかない。

> また、定石を無視するようなケースが、ここでの議論する題材として適切なのでしょうか？。
ん、議論の為の議論はしたくないんじゃなかったっけ？

> なぜ、定石が成立しないような無茶（？）なケースをここで言及しなければならないので
> しょうか？　教えてください。
ここは戦場だから。
昔の常識は今は非常識となる(例えば机上デバッグは今は非常識)
定石は「ある場合」にしか適用できない。

状況が激変するこの業界ではその定石を適用する場合、
常に現在の状況が「ある場合」かどうかを問い続けなければならない。
でないと進化に取り残され、戦死する可能性が高い。

でも、その設計無し(瞬時設計？)は一人で出来る時の話でしょ？

規模として半年・５人くらいのプロジェクトだとどう？
分担とか工程管理のためにも　最初に分析・設計は必要でしょ？

>>368
だから、誰も設計無しを薦めていないって

>>223の数万行くらいを設計書も作成しないでどうして出来るのかって
　　質問の説明をしてるだけ。

その方がいいとかそういう話じゃない。

>>367
うーん。なんだかお答えが全て、とても曖昧ですね。

｜> また、定石を無視するようなケースが、ここでの議論する題材として適切なのでしょうか？。
｜ん、議論の為の議論はしたくないんじゃなかったっけ？

御自身、為にする議論を振っている、という自覚があるのでしたら妙な話は控えていただければ
ありがたいのですが。367さんの記述したケースに言及する＝為にする議論であるという自覚を
お持ちなら。

それと、状況が激変するという書き方は、確かに日経の雑誌などでよく見かけますが、本当なの
でしょうか。わたし自身、不勉強をこのスレで感じましたが、それは状況の変化では
なくて、単に自身の不勉強であるように思います。
属している業界に応じた変化があるとは思いますが、「状況が激変するこの業界」とまで、ひと
くくりにするのは、ちょっと無理があるように思います。

>>370　でさあ、ボクチャンどういう結論が欲しいの？

初心者だから教えて欲しかったんじゃないのか？
そんな業界判った人ならそんな聞きかたするなよ紛らわしい

結論が欲しいんじゃないだろ。
議論がしたいだけなんだ。

ほっとけ
ほっとけ

>>370
つーかさ、「状況が激変するこの業界」はいいけどさ、
ほかの業界だって業務形態がどんどん変わってきてるのに
フォームだけ見てコーディングできるってのが不思議だよな。
4GLマンセーおじさんと同類に見えてくる。

>>372
プププププ…

>>373
> フォームだけ見てコーディングできるってのが不思議だよな。
「いつも」そうしていると誤解していない？

OO信者とアンチOOは同類のように思えてきた
両者とも「現在の状況」を無視して自分の定石が常に正しいと信じている。

弾が飛び交う激しい戦場で頭出して戦況を把握してる奴は手を休めてるサボリとして即死。
結局下手に自分のスタイルを状況に合わせて変えるよりも力技で押し切った方がまじだと。

けっ馬鹿馬鹿しい。
>>374　最初からそういうふうに聞けよ　そしたら無視するだけで済んだんだからyo
　お互い胸糞悪い思いしないですんだんだからsa
　こっちは休みでも自分の子供の相手しながら勉強してんだ。
他人の子供のお守りまでやってられるか！

>>376
この程度で「胸糞悪い」思いをするのは、ちと修行が足りんと思われ（ｗ

相手を「バカだなこいつ」と思ったら、さっさと見限って議論はやめて良いんだって。

偵察もせずに勝手に突っ込んで戦端を開くやつは銃殺。

切腹申し付ける

このスレは議論するのが目的だから…

>>380
> このスレは議論するのが目的だから…
違うよ。
> 引き続きＯＯ厨とアンチＯＯ厨の血で知を笑う戦いきぼ。

途中で良スレになりそうな気がしたのは気のせい。

なんか急にマターリしちゃったね。

議論が目的で、結論を出すのが目的じゃないよ、っていう意味でっす。

あ、そか、議論になってなくてもいいのか。

>>376が>>374に対してなぜ

> けっ馬鹿馬鹿しい。
> >>374　最初からそういうふうに聞けよ　そしたら無視するだけで済んだんだからyo
>　お互い胸糞悪い思いしないですんだんだからsa

となるのか謎。何か誤解があるようにしか思えんのだが。

>>385 単純にレス番がズレたんじゃないの？

オブジェクト指向って本当にすばらしいですよね。
考え方だけが。
戦場では使えないけどね。

↑使えない人

>>387
OOP特に OOPLはパラダイムレベルにあると思うけど OO設計分析はどうかなあ

>>389
設計は、手続き中心の構造化とオブジェクト中心の OO だとパラダイムシフトが
あるでしょう。分析は、OO でも RUP あたりだと

　まずはユースケースの洗い出し

だから、手続きというか機能単位の分析ってことで、それほど差はない気がする。

オープンソースプロジェクトの成功率
C++を採用したプロジェクト→20.8%
JAVAを採用したプロジェクト→20.6%
Cを採用したプロジェクト→45.13%

http://www.gyve.org/~jet/lang2.txt

>>391
そのネタは、

だいぶ前に紹介されて
　笑われて
　　捨てられた。

>>392
OOがね。

>>386
でもさ、>>373に対してとしても、373はとあるダメ社員さんじゃないでしょ。
やっぱ何か勘違いしてるよ。
まあ、別にどうでもいいけどさ、
それでも>>391みたいなのよりはましなネタが出てたからなあ、あの流れは。

パラダイムは　その時代の支配的な物の見方って事だから

OOP/OOPLはパラダイムと呼べるほど普及してるかもしれない。
戦場とか現場とかでも主に使われる道具レベルにあるし、
その用語も普及してると思うが、OO設計・OO分析はそうじゃないだろ

> OO設計・OO分析はそうじゃないだろ

いまだにロートルアンチのふざけた仕事が横行しているせいです。

ところでロートルってなんとなく使ってみたけどどういう意味だろう？
けなし言葉だよね？とりあえずけなし言葉だと受け取ってくれ。

ロートル【老頭児】
（中国語から）老人。としより。

Kokugo Dai Jiten Dictionary. Shinsou-ban (Revised edition) ｩ Shogakukan 1988/国語大辞典（新装版）ｩ小学館 1988

>>390
確かにユースケースやアクティビティダイアグラムは機能分析的ではあるが、
構造化分析では機能を分解していくのに対して、
OOAでは機能の主体を洗い出して主体間の関係を記述していく。
つまり、最初にやる事は同じだが、目的とその後の分析工程が全く異なる。

>>395
パラダイムはこの場合は「その手法の支配的なものの見方」と見たほうがいいと思う。
普及度については、確かに正しく実践されている例はまだ少ないかもしれない。
しかしOOPがSimulaから３０年かかって普及し始めたことから見ても、
まだこれから普及が加速していく可能性はある。
用語についてはOOA・OODの概念などは多くはOOPから取り入れられていると思う。

OOが普及するまでに別のパラダイムが登場するに10000ｵﾌﾞｼﾞｪｸﾄ

>>399
OOPはすでにずいぶんと普及していますが何か？

>>399
コンポーネント指向、エージェント指向、アスペクト指向、マルチパラダイム

>まだこれから普及が加速していく可能性はある。
もう普及し尽くしてるだろ、あとは衰退。

>>402
俺も、未だに OO を取り入れてないトコロに今後 OO が普及するとは思えんな。
そもそも OO が適さない分野というのも存在するし、OO によらず方法論を学ば
ずにデスマーチを繰り返してるところもあるし。

> OOPはすでにずいぶんと普及していますが何か？
OOP"対応"言語はな。

それで十分ジャン。それ以外何を望む？

実際OOを使用して開発期間を短縮できたとか、
再利用性が高まったという劇的な話を聞かないのは何故？

>>406
OO に限らんが、何らかの開発手法を導入して生産性が改善されたって話を
無料で同業者にアナウンスしても、ビジネス的に全く旨みがないから、どこも
やりたがらないだけ。

> OO に限らんが、何らかの開発手法を導入して生産性が改善されたって話を
> 無料で同業者にアナウンスしても、ビジネス的に全く旨みがないから、どこも
> やりたがらないだけ。

ハッキリ言って同意。世界中のOO開発者、出版社、企業は
組織的にオブジェクト指向が効率的だという事実を隠しています。
その本部はエリア55の地下にあるといわれています。

>>406
あなたが、OOの良い話を聞こうとしないからです。

そしてオブジェクト指向が効率的だということを
外部に漏らした者はこの世から抹殺されます。
あのケネディもその一人でした。
このようなことからオブジェクト指向が効率的で
生産性が高いうことは一切外部のものは知ることが
できないのです。

>>406
生産性や再利用性とOOは直接関係ない。
どっちかというとコンポーネント思考での利点だな、それ。

語り尽くされてるから類似スレよんどけ。

> 生産性や再利用性とOOは直接関係ない。
ﾊｧ？　OOの利点は生産性や再利用性を謳っているんだろーが。

また馬鹿が一人..

つーことはOOは生産性や再利用性にそれほどいい
わけじゃないと認めるということでいいんだな。

その通りだが俺は使い続ける。
もっといいもんが出てくるまではね。

>>414
２ちゃんねらーが「認める」と発言することに、いかほどの意味が（ｗ

ま 414 が「認めたことにしたい」なら、それで良いんじゃないの。俺は困らないし。

OO信者がこの質問に対する解を持っていないところを
見るとOOはやはりクズってことだな。

>実際OOを使用して開発期間を短縮できたとか、
>再利用性が高まったという劇的な話を聞かないのは何故？

ここ一応技術板なんだからさぁ
プログラマとして使える・使えない、
使いたい・使いたくないって
議論したいんだったらマ板でやりなよ。

非OOがふさわしいものは非OOの方が生産性や再利用性は高い。
OOがふさわしいものはOOの方が生産性や再利用性は高い。
生産性や再利用性を常に高くしたいならどっちもやっておけってことだ。

OOで開発期間を短縮できたとか、
再利用性が高まったという話は技術にからむ話ではないのか？

>>418
このスレがプログラマー板の「隔離スレ」です。ここがあるおかげで、他のスレで
「使いたい／使いたくない」の議論が出ずに済んでるので、冷たい視線で見守っ
てやって下さい。

s/プログラマー板/プログラム技術板/

実際OOを使用して開発期間を短縮できたとか、
再利用性が高まったという劇的な話を聞かないのは何故？

>>423
聞かないのでは聞こうとしないのではないのか？

>424
なに煽りに混じれ酢しとんの?ｱﾌｫ?

つーか、煽りにすらなってない。
開発期間短縮がOO使っただけで実現できるなんてどこの誰が言ったんだよ。
銀の弾丸じゃねーっての。

>>425
マジレスしても問題無いと思うけど?ｱﾌｫ?

生産性や再利用性がそれほどいいわけじゃないとしたら、
OOの利点はいったい何だ？

>>428
OOにふさわしい問題では生産性も再利用性も高いって。

＞＞４２９
じゃあOOにふさわしい問題・ふさわしくない問題って何だ？
銀の弾丸は期待してないが、適用範囲が狭すぎるのだったら
結局役に立たないのと一緒でしょう。

その辺に転がってるやっつけ仕事には役に立たない、というのは同意。

OOにふさわしい問題とやらが、現実問題から乖離しているように見えるのはそのせいか？

ちょっと質問なんだけど>430は
どの程度OOについての知識･経験があるの？

>>392
は完全なデタラメ。
今まであれを論理的に否定した奴はいない。

>432
ん？それが何か関係ある？デザパタ本くらいは全部読んだけど。

>>433
関数ポインタと動的プログラミングの関係を、論理的に証明したヤツもいないけ
どな（ｗ

>>433
そうか？理論的に否定されまくってるが･･･
第一、分子と分母の元が一致してない。

>>436
「　」は構ってクンなんだから、放置して寂しがらせとけよ。餌をやると懐くぞ。

どっちかっていうと交換可能性の方が好きだなあ、ぼかあ。
結果的に生産性や再利用性に結びつくんだけどね。

>>437
そこであえて餌をやって反応を楽しむスレだと思っていたが(藁

で、関数ポインタと動的プログラミングの関係と、
ファイル分けとクラスの関係はどうなったね?

>>438
どっちかっていうと「直接的にモデリングできる」ことの方が好きだなあ。ぼかあ。
結果的に生産性や再利用性や交換可能性に結びつくんだけどね。

ところが、肝心のモデリングの段階で、

犬::鳴く、猫::鳴く

レベルの説明を真に受けて痛い目に遭う人がいる。アンチ連中は、
そのなれの果てでしょ。

これは、むしろOOを説明しようとする側の失敗だと思う。
個人的には、Smalltalker逝ってよし! と思ってるがな。
C++屋の方が、ずっと話が通じるぞ。

>>440
それはあなたの心がC++に束縛されているからです。
Smalltalkerの心がSmalltalkに束縛さえているようにね。
＃まあ俺も、今現在の問題を検討している所に突然昔話を始めて
＃「正しいSmalltalkは」なんて言い出すOldtalkerには、
＃逝ってよし！と思うがな。

>>440
その説明のどこが問題なの？
あまりに簡単すぎて説明が不足してるって事？

いっその事、オブジェクト指向は　OOPLを効率的に使う事と　逆定義すれば　お互い幸せになれそう

とオブジェクト指向を理解出来ない者が申しております。

が、如何致しましょう？　賛成？反対？放置？

ＳＵＮのライブラリだって非ＯＯ的なのがあるよ。
ＪＤＢＣなんかかなり手続き型寄りだしね。

http://www.njk.co.jp/otg/Study/OOPrinciple/
1970年のゼロックスパロアルト研究所で開発されたSmalltalkによってオブジェクト指向の技術体系が確立された
30年前にアイデアが確立され、最近になってようやく実用的な技術として使われるようになった
が現状では、オブジェクト指向メソドロジーはよちよち歩きの幼児期

で、理解の歴史と効率について

第一段階 　理解に手間取っている段階
第二段階 　オブジェクト指向プログラミングのテクニックを習得した段階。
　プログラミング能力が一挙に向上したような気がするだろう。
　しかし、この能力をチームコンピューテイングの中で発揮する知識がなく、
　自己満足から抜け出せないために伸び悩んでしまう時期でもある。

第三段階 　オブジェクト指向方法論に対する関心度が高まる段階。
　オブジェクト指向のテクニックをチームの共有技術としようと努力し始める。

第四段階 ・・・略・・・


だそうだ。　まずはチームの共有技術にしようと努力する所まで行かないと　使い物にならないらしい

結局　、　
　数千行は１日で書け、1ヶ月1万行程度のコードがコンスタントに生産出来、出力フォーマットさえ見れば入力画面から
データベース設計まで一瞬で出来てしまう人は、　自分なりの方法論というかその人の能力に頼ったを開発手法を持って
いるのだと思う。しかし、たぶんその手法は他人には使えられないものなのだろう。

しかしオブジェクト指向による方法論はそうではなく他人に伝えられ習得してもらう事が出来る。
その意味では有益な手法（特にこれから成長しようとする人にとって）である事は間違いない。

第一段階
　他人を見下す方法を探している厨房が書店でＯＯ関連本をハッケソし、
　「これだ！」と思ってしまう時期。
　厨房必死だな。つう感じでＯＯ入門書を睨むが、内容を検討する
　だけの基礎知識が無く、本の内容をそのままに洗脳されてしまう。
第二段階
　この段階にくると、あたかも自分のプログラミング能力が
　一挙に向上したような気がするだろう。
　しかし、実務で使った経験が無く２ＣＨで煽るだけの、
　粘着から抜け出せない為に 伸び悩んでしまう時期でもある。
第三段階
　自作 （･∀･）ｼﾞｴｰﾝのテクニックに対する関心度が高まる段階。
　オブジェクト指向派が優性であるかのように小細工を始める。

>>448
> しかし、たぶんその手法は他人には使えられないものなのだろう。

人に自分の手法をきちんと説明できない奴は、
結局は自分の手法をきちんと確立できていない奴だろ。
あるいは「手法」なんていう代物ではなくて、
単なる「惰性」だったりすることも多い。

>>448
＞数千行は１日で書け、1ヶ月1万行程度のコードがコンスタントに生産出来、出力フォーマットさえ見れば入力画面から
＞データベース設計まで一瞬で出来てしまう人は、　自分なりの方法論というかその人の能力に頼ったを開発手法を持って
＞いるのだと思う。

凄そうに見えて、実はただのルーチンワークという壷

> 第一段階
> 他人を見下す方法を探している厨房が書店でＯＯ関連本をハッケソし、
> 「これだ！」と思ってしまう時期。
> 厨房必死だな。つう感じでＯＯ入門書を睨むが、内容を検討する
> だけの基礎知識が無く、本の内容をそのままに洗脳されてしまう。
> 第二段階
> この段階にくると、あたかも自分のプログラミング能力が
> 一挙に向上したような気がするだろう。
> しかし、実務で使った経験が無く２ＣＨで煽るだけの、
> 粘着から抜け出せない為に 伸び悩んでしまう時期でもある。
> 第三段階
> 自作 （･∀･）ｼﾞｴｰﾝのテクニックに対する関心度が高まる段階。
> オブジェクト指向派が優性であるかのように小細工を始める。
第四段階
　２ｃｈでもプログラミング能力でも相変わらず厨房であることが
　晒される。
第五段階
　自分のような「被害者（W」がこれ以上増えないようにアンチに転向。
　２ｃｈでセコセコと煽ってばかりの毎日。

> 実際OOを使用して開発期間を短縮できたとか、
> 再利用性が高まったという劇的な話を聞かないのは何故？
で、結局この質問に答えられるできるソースさえもないのね。
OO玉砕！

>>453
あなたはOOに何を期待しているのですか？
即物的な効果を期待しているのですか？
OOを信じなさい。OOの愛であなたは救われます。
そしてあなたもOOの愛で皆を幸せにしましょう

オブジェクト指向も　設計が終ればルーチンワークだよ
　そのうち、その設計＝コーデングになるようなツール(真の4GL)が出たら
　その設計もルーチンワークに

OOにふさわしい問題・ふさわしくない問題って結局、何なんですか？

>>453
少なくとも、ボーランドのVCLはWindowsのプログラミング作業を
かなり楽にしてくれていると思うのだが。

methodologyてのがなんだか分からんのです。
方法論と訳すとなんか分かったような気にもなるんですが、
boochの本なんか読むと、methodはmethodologyのインスタンスだ
なんて書いてあってよく分からんのです。
UMLの4layerのmethodologyはどんな関係があるの？

>>456
　あなたが従来法を使って　ソフトウェアシステムを把握できる限界を越えたかどうか

>>457
　しかし >>24　のコードはOOではないらしい

訂正
4layerの
4layerと

> Smalltalkの基本的なアイデアは「幼児にもプログラミングできる言語を目指し
> た」ものであり、そのためには人間が実世界を頭の中で理解する単位にならう
> ことが必要とされた。その手法としてソフトウェア仮想世界に「もの」という
> 単位を作りだしたのである。「もの」に命令して仕事を進めていくというプロ
> グラミングスタイルは、人間にとって理解しやすいものであった。

OO マンセーだが、この目標は今の OOP では到底達成できなさそうだね。
むしろ基礎勉強は多くなってるもん。

基礎が身についた後はパラダイスが待っているんだけど。

>>448
> 数千行は１日で書け、
月 1 万行は内容によってはコンスタントに書けるが、数千行を一日は有り得ないっ
て。仮に 3000 行で実稼働時間 10 時間としても

　毎分 5 行
　シンタックスエラー一切なし

だぜ？　集中力が続かんよ。（コピペの場合を除く）

一週間に精々3,4000行だな。
単純なものならもっといくかもしれないが、
そういったのはC/C++を使わないで、
スクリプト使うだろうし。

>>450
そうか？　RUP の解説書を読んでも、それで明日から OOA のプロになるのは
無理だろ。

プログラミングの方法論というのは、経験の裏づけがあって初めて適用できるも
ので、マクドナルドのマニュアルのように

　誰にでも通じる言葉で説明できて、
　聞けばすぐに分かる

とはいかんだろ。（プログラミングに限らず、物理学の実験だろうが数学の勉強
方法でも同じだが）

OOとマルチ商法の違いを教えてください。

>>458

methodology … 手法に関する理論
method … 実際に個々に適用する手法

売れること、それのみが価値を実現します。
売れないものは価値がないのです。

by 信者

一日でずいぶん進んでしまいましたね。
>>448

｜448 ：デフォルトの名無しさん ：02/03/03 12:36
｜結局数千行は１日で書け、1ヶ月1万行程度のコードがコンスタントに生産出来、出力フォーマットさえ見れば入力画面から
｜データベース設計まで一瞬で出来てしまう人は、　自分なりの方法論というかその人の能力に頼ったを開発手法を持って
｜いるのだと思う。

それを、一般論の形でよいので、少しでも知りたかったのですが、残念ながら私の理解力不足とコミ
ュニケーション能力不足もあって、わかりませんでした。
個人的なスキル自体が足りない、というのはわかるのですが、それだけで差を埋められるものなのか
わかっておりません。

>>467
UMLとどうかかわりあってるのかが知りたいです。

＞人の能力に頼ったを開発手法
を、どうやって一般論にしろというのだろう・・・

「一般的に、一般論には例外があります」とでも？

明文化されていないようなものは方法とは言わない

　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　|　　はいはい
　|　　取り壊しの邪魔だから出てった出てった
　＼＿＿＿　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　　　　 |／＿＿___
　　 , --､　　　 |　 |.＿ |　　　OOはやっぱクソだったな！　　　　　まったくだ
　　f＝+=l.　 　 |　 ||.O|.|　　　　　　　 ∧＿∧　　　　　　　∧＿∧
　　(,,ﾟДﾟ).　　　|　 ||.O|.|　　　　　　　（　・∀・）　ﾆﾔﾆﾔ　（・∀・　）
　 ⊂　　つ .　　|　 ||長||　　　　　　　（　　　　つ　　　　　（　　　　）
　〜|　　|　彡 　|　 ||編||　　　　　　　｜ ｜　| 　　　　　　｜ ｜　|
　　 し`Ｊ　　　　|　 |￣ .|　　　　　　　（_＿）＿）　　　　 　（＿（＿）
　~~　　　　　　　￣￣￣　　　　　~~
　　　　　　　　　　　　　　　　　　　　　　　　　　　~~

　　　ｺﾞｺﾞｺﾞｺﾞｺﾞ

　　　　　　/ゝ　　　　 ┌―┐ <--OO
　　　　　 /　●.　　┌┘品└┐
　　{{　[]台　　　　　 |　ﾛﾛ　ﾛﾛ.|
　￣￣ﾟﾟﾟﾟﾟﾟ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


　　　　　　　　　＼＼あぼ――ん／　／
　　　　　　　　　　　　(´;)
　　　　　　　　/＼　 (;)┌―┐
　　　　　　　 /　<<●(´;;;)　└┐ }}
　　　　　　 []台　　 (;;⌒);;;) ﾛﾛ.|
　￣￣￣￣ﾟﾟﾟﾟﾟﾟ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　　　　　　　　　　　　　　　　　　―OO完―

>>470

｜470 ：デフォルトの名無しさん ：02/03/03 15:51
｜＞人の能力に頼ったを開発手法
｜を、どうやって一般論にしろというのだろう・・・
｜
｜「一般的に、一般論には例外があります」とでも？

人の能力＝個人のスキルだけならば、単に「勉強しろ」で終わるのかもしれませんね。

しかしながら、スポーツでのコツのような非常に言語化しずらい（出来ない？）分野
であるならばともかく、なぜ「一般論化出来ない」と考えるのか、理解に苦しみます。

せいぜい、「複雑であり、詳細に説明するのは難しい」といったところではないでしょ
うか？

448さんも言及しておられるように、
｜自分なりの方法論というかその人の能力に頼ったを開発手法を持って
方法論的なものが知りたいのです。ノウハウといっても良いのかもしれません。

もちろん、お答えくださる方の善意に寄りかかっているだけですので、ここで
伺えるかどうかはわかりませんが。

またこの流れか。
もうお前らDQNにOO教えるの止めたくなってきた。
お前らOOで分析したらｶｺｲｲ?、とかOOPLで作ったらﾗｸﾁﾝ？
とかそんなことしか考えてねーだろ。
OO分析は顧客の要望と仕様をすり合わせるツール。
OOPLは仕様とプログラムをツライチにしやすい言語。
これだけだ。種も仕掛けもね-よ。

>>474
誰もおまえに教えてくれなんざ頼んじゃいないよ
イヤなら顔出さなきゃいいじゃん

引っ込みな

>>474
え？教えてるつもりだったのか？
どうりで議論にならないわけだ。
納得納得。

念のため逝っとくが、俺はアンチOOじゃないぞ。
分析設計実装全てでOO使ってる。

٠٩٧٣هخخخخخخعف٤٣صضسيسسسسسغ

>>473
囲碁や将棋のプロのような部分もあるんだと考えればいいんじゃないの？
経験で鍛えられる人間の直観力のような部分が

いまどきOOも分からん奴は
PG廃業してスパゲッティ屋に転職したらどうであろうか。
伊太利亜にでも逝ってｸﾀﾞﾁｬｲ。

>>479

スパゲッティなら日々生産してますが、何か？

('-`)。o○（今度は明文化と一般化の区別がついてないよ…）

OO信者撤退中！
　　　　　　　　　　　　　　　　┌─┐
　　　　　　　　　　　　　　　　　｜も.｜
　　　　　　　　　　　　　　　　　｜う　|
　　　　　　　　　　　　　　　　　│来│
　　　　　　　　　　　　　　　　　│ね│
　　　　　　　　　　　　　　　　　│え .|
　　　　　　　　　　　　　　　　　│よ .|
　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│
　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ
　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д）
　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U
〜 〜　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎−>┘◎

OO信者がついに負けを認めたか。。。ッフ。

もし万が一盲目的なOO信者ってのが居るならば、
そんなのは消えてよし、と。

んで、アンチは何を言いたいの。
要点を押さえて簡潔に言ってね。

>OOスーパユーザ
ﾌﾟｯ

>>485 すかしっ屁臭いよ

>>485 アンチは屁たれ、と。

>>447
ふうん、オブジェクト志向にも30年余りの歴史があるんですね。
CやUnixと同じじゃじじい。
この辺のことをうまく書いたパソコン現代史といった本はないもんですかね。

ぁ、>>447 参考になりました。H本さん良い解説ありがとうございます。

＞この辺のことをうまく書いたパソコン現代史といった本はないもんですかね。
どうでしょ、私は寡聞にして存じません。
OOPSLA とか、ACMあたりで、
良いまとめを出してるんかもしれないですけど...。

なんかOO方面って、まだまだ流動的で、
歴史を書くほど確定していない気もする...。

はっきり言ってOOは歴史はあるが実績が無い。

ここで、ウィンドウシステムとか、Webシステムとか、
例を挙げても、きっと>>490は納得してくれないだろうなぁ。

「部品化」とか「再利用性」というお題目のようにいう人は、
いま、そのクラスが利用しやすいか？　使いやすいか？という「利用性」
のことを忘れてることが多い、という言葉に最近じーんときてます。
未来も大事ですが、もっと大事なのは今ですよね。

再利用可能なものって、作成にはとても手間ひまかかるしコストがかかります。
たとえばC++,Java,SmallTalk,...のクラスライブラリのような性質のもの、
かける価値のあるものには、コストをかけられますが。

極端な話、再利用性なんて普段は意識しなくてもいいんじゃないでしょうか。

>>492
例えばmp3プレイヤーを作ったとする。
次に、wmaもサポートしようと思ったとき、簡単にプログラムできると
すごくいいと思わない？

たとえばwebブラウザを作ったとする。
次に、タブブラウザを作ろうと思ったとき、簡単にプログラムできるけど
いちいちセキュリティーホールを引き継ぐの、すごくいいと思わない?

>>493
Strategyパターンみたいに、可換に作るのが自然で、モデル的にも
シンプルになるものはいいと思いますよ。

意図がうまく説明できなくてすんません、(←ってことはまだよく
わかってないんだろうな、ワシ)

客が機能Aが欲しいといったときに、抽象化、一般化したほうが楽なときは
一般化するけど、Aだけつくるほうが安上がりのときはAしかつくらない、
みたいな感じなんです。

みんな最初は
ooってものを
知らなかったわけだが
理解できたきっかけは？

>>496
JavaのコーディングとGofの本。

>>496
タートルグラフィックス

>>498
懐かしいな。小学生のとき、LOGOでrobot動かして遊んだなぁ。
FOWARDとか、BACKとか、
でも、おばかだたので、パパートさん(でしたっけ？)が期待したように
再帰で、へんてこりんな、パターン動かしたりはできなかったし、思いつきも
しなかった。

大昔のOh!MZの記事。

>>496
Smalltalk

>>496
２０年くらい前の月刊ＡＳＣＩＩのアドベンチャーゲームの製作記事

>>502
表参道？

プログラミングとしてのOOはJavaで色々と勉強させて
もらったけど、それよりもインパクトのでかかったのは
RUPとかXPなんかのソフトウェアプロセスを勉強しだして
からかなあ。対象物は全てオブジェクトとみなして同一に
扱うっていうフラットな考え方は目鱗だったよ。

>>503
だったか、南青山だったか忘れた。
「持ち上げるとか、投げるとか、使うとか、そういうコマンドの結果を、
　アイテムごとに定義するんじゃなてく、もっと効率のいい方法無いかな？」
っていう話題からSmalltalkの話になるような記事だったと思う。

データ指向とオブジェクト指向の世界の衝突
http://www-6.ibm.com/jp/developerworks/components/010629/j_co-tipdiv.html

★(EJB) 開発チームの重大な問題
★オブジェクト指向開発者とデータ指向開発者が一緒に作業する場合に味わう難しさ
★オブジェクトとデータの対立の悪影響を受けている組織は一般に、
「策略に明け暮れる」ことに対し開発者のフラストレーションがたまり、 転職が増える傾向

ttp://www2j.biglobe.ne.jp/~sakuchan/it/20000614.txt
プロセス指向という用語もあるんだね

プロセス指向 VS データ指向　VS オブジェクト指向

どっちかいうとうちはプロセス指向かな

>>506 をぉー、気になるテーマだ、ありがとござますー

>>462 なんとなく>>448 は、
自前で「データ中心アプローチ」方法論構築しちゃった井の中の蛙ーって感じがする。
＃海は広いよ

1日に３千行か、対戦５目並べで書いた事はあるな　・・・それだけ

データ指向で検索してヒットするページだけど

ttp://member.nifty.ne.jp/yamazaki/doc_data02.html

ちょっと　上の2ページとは用語が違うようだ

>Strategyパターンみたいに、可換に作るのが自然で、モデル的にも
>シンプルになるものはいいと思いますよ。
なんかよくわからないけど、例がわかりずらかったのかも。
例えば、サーバーの状態をセキュリティーの会社の報告するプログラム。
プロトコルAで送信していたけど、理由があってセキュリティーの会社を
変えたとする。
するとプロトコルBで送信しなくてはいけない。
ただ、ここでプロトコルAでの送信機能が失われるような
変更を加えるのは、頭悪いでしょ？
他は何も変えず、プロトコルBでの送信機能を追加するには・・・
一般的な表現をするなら、
ファクトリーメソッドがあれば十分、充分？。
とりあえず、デザパタは無視していいと思うよ。
デザパタから入ると、柔軟な発想ができなくなりそうな気がする。

話がそれるが、Gof本ってなんでGof本っていうの？

Gang Of Five

ttp://www.momonga.org/~manabu/public/se/mozilla/build.html
より、mozillaの例を挙げてみる…

クラス・ブラウザ
・C++ や Java など, いわゆるオブジェクト指向言語のソース・ファイルは 理解が難しい
・・継承により, どのようなメソッドがどこで定義されているか把握しずらい
・・メソッド (関数) は クラス名::メソッド名 と 呼び出されるが, クラス名が省略される場合があり,
・・また, メソッドは引数の組み合わせによって選択されるため, 同じ名前のものがたくさん定義される
・動的な解析ツールを駆使する - デバッガでトレースをとる
・・イベント駆動ループからの呼び出し
・・ストリームなどの非同期イベントからの呼び出し
・・マルチスレッド実行時のオブジェクト間通信
・結論: できのよいクラスブラウザを持っていないと手に追えない

OOに異を唱えるわけではないんだが、(とゆうかかなりはまっている私
こんな現実もあるのでは。
ってか優秀なクラスブラウザってないかな？
できたらフリー/学生に手が出る値段で

>514いちおうGang Of Fourとつっこんでおく。

しかしSmalltalkのクラスブラウザはかなり便利。
あれを他の言語でもできないものか。

>>517
そんな貴方にVisualAge for Java

mozillaの場合は、そこそこ便利で出来が良くかつ無償でなければ
ならない条件があるから難しいのでは

>>515
前半は、UML あたりで図を書いとけよ、という話だと思うが。規模が大きくなると、
コードだけ見て理解するのは辛いよ。

あと C++, Java でなくとも、動的なフレームワークにすると理解が難しくなるのは
世の常。OO の真髄は「インターフェースに対してプログラミングする」ことだけど、
そうなると、これまでの

- caller / callee

だけではなく

- caller / interface / callee

と、途中に interface が挟まる分だけ、全体像を把握するのは難しくなる。おもい
きり OO っぽい設計にすると、インターフェースの多重継承なんてしょっちゅうだ
から、caller / callee 間が蜘蛛の巣のようにつながるし。

ただ、interface について明確にドキュメント化してあれば、蜘蛛の巣で迷子にな
らずに済むはず。caller も callee も interface について知っていれば十分だか
ら。

（C でも OO っぽい「インタフェースに対してプログラミングする」のは、最近の流
行りではあるよな。*BSD のデバイスドライバのフレームワークなんかも、マクロ
や関数ポインタを多用して、同じようなことやってる）

後半のイベントドリブン、マルチスレッドは OO とは関係ないな。素の C で組ん
だ Win32 アプリケーションやら OS やらでも、そこは把握に苦労する部分。な
んかうまい表記方法が発明されると嬉しいんだけど、ねぇ。

>>520
>OO の真髄は「インターフェースに対してプログラミングする」ことだけど、
ちょっとまて。「インターフェースに対してプログラミングする」なんてCにstatic関数が
出来たときから(きっとそれ以前だろう)いわれてることじゃないか。

これはOOの神髄ではなくプログラミングの神髄だ。

OOっていうのはこうした方がいい設計、いいプログラム、へのガイドラインじゃないかと。
だからやってることっていうのは実は昔から変わっていないんじゃないか？。
OOがワカラン、OOは糞、というやつは実はOO以前のスタイルでもまともな設計、プログラミングが
できていないんじゃないかと思う。

>>516
それは、Erich,Rich,Ralph,Johnの四人がGangってこと？

>>521
ADT の進化系が OO と認識してるけど。

C だと

　インスタンスの管理がめんどくさい（明示的に this を渡す必要があり、vtbl も
　自前で初期化しないとダメ）
　継承関係の管理を自分で行う必要がある
　インターフェースの多重継承は事実上無理
　インターフェースを追加した場合に、コンパイラがエラーチェックしてくれない
　（純粋仮想関数の定義し忘れとか）

なのが C++ あたりだと、すっきりかける。

C++ は C に「インターフェースに対してプログラミングするために便利な／必要
な機能」を付け加えた処理系っつーのは、一面としては間違ってないと思うんだ
が、どうよ？

>>522
> OOっていうのはこうした方がいい設計、いいプログラム、へのガイドラインじゃないかと。
その通り、単なる「ガイドライン」に過ぎないのにそれを絶対視する奴が多すぎる

例えばDBのテーブル設計の場合、パフォーマンスを出すために
あえて正規化を崩す場合がある。
構造化プログラミングでも状況によりgotoを使う場合もあるし、
グローバル変数を使う場合もある。

常に「gotoを使わない」「グローバル変数を使わない」奴は素人。
常に「OOを使う」ことしかできない奴は素人

「OOを使えない奴」は素人以前の問題

>>524
インターフェースへのプログラミング、という捕らえ方は正しいと思う。

ただAlan Kay的なOOの定義に従って考えると、
ADTの延長にOOがあるんじゃなくて、
OOの実装で現状使える技術要素の１つがADTなんだろうな。

つまり、何かを聞けば反応を返すのがオブジェクトであって、
ADTはそれを実装するのに都合がいい概念の１つに過ぎない。
ADT以外にinterfaceを明確にできるソフトウェア構成単位があれば
そっちに移ればいい。

>>525
UMLを書き上げただけでシステムできると誤解してない？
現実的なソフトウェアはそれだけじゃできないよ。
だけど可能な限り設計段階でUMLで表現しておくことが
無意味になることを意味するわけじゃない。

多数のボランティアが必要なプロジェクトで UML図を誰がどう作成してメインテナンスするのか
というかそういう作業を好んでやる人はいるのか？

OOの欠点は、何かにつけ大げさになる点。ただそれだけ。

OO信者の欠点は、それが致命傷になるケースであってもゴリ押しする点。これ激しく迷惑。

で結論は？と言ってみるテスト。

でも厨房の漏れには両者の喧嘩は意外と勉強になったYO!

みんながんばれ。(･∀･)!!

>>528
プログラマはプログラムで自己表現するんじゃなくて、
設計レベルで自己主張すべき。じゃないといつまで
たっても職人仕事の域を出ない。
だからUMLは管理するものという発想は間違ってる。

>プログラマはプログラムで自己表現するんじゃなくて、
>設計レベルで自己主張すべき。じゃないといつまで
>たっても職人仕事の域を出ない。
船頭おおくて船山にのぼる

プログラマがプログラムで自己主張できなくっちゃ
つまらねえよなあ、おい。

プログラムって楽しいもんじゃねえか。
いくら仕事だからって楽しんじゃいけねえのかい？

そうか、そうだよなあ。
職人が生きにくい世になったんだなあ。ちぇ。

設計とコーディングをもっとシームレスに考えれ。

職人仕事でいいじゃん。一流の職人なら。

>>530
> で結論は？と言ってみるテスト。
結論：
　テストを先に書くこと。（XPマンセー）
　UMLや設計は後からついてきます。

>>536
XP も ストーリー→タスク→テスト と
その都度設計してるんだけどね。
設計そのものの成果物を残さないだけで。

>>524
インターフェイスっていうのはものすごい一般的な言葉なわけで､

printf関数を使っているときにはprintfインターフェイスに対して
プログラミングしているといえる。プログラム言語が関数を手に入れたときに
最初のインターフェイスが誕生した。

同じように自作のモジュールでも公開関数に対してだけプログラミングすれば
実装を容易に変更できるようになる。Cがstatic関数を手に入れたときに次世代の
インターフェイスが生まれた。

OOPLはいくつかの関数とデータを硬く結びつける文法を用意してより強力な
インターフェイスが誕生した。

きっとクラスの数が増えてくればそれらをいくつかまとめて次世代のインターフェ
イス概念が生まれるのであろう。

>>538
> インターフェイスっていうのはものすごい一般的な言葉なわけで､
あの文脈だと「シグネチャが一致するメソッドの集合」と読めるかな。

>>526
賛同。Smalltalker?

526=Smalltalker

協調性の無い職人ほど邪魔なモノは無い

同化を強要するボーグみたいでキモいよ、OO厨。

業務としてコード書くんだから我慢しる

>>542
激しく同意
特にOO職人と勘違いしているOO信者は協調性がない邪魔者
COBOLerと同じくらいタチが悪い

＞勘違いしているＯＯ信者
それって、職人じゃ無いじゃん。

>>546
職人じゃないんじゃなくて、信心のたりないOO信者ってとこだろ。
OOPLは好きだがそれ以外のものをメンドクセーとか思ってる奴。

そういう奴がXPマンセー！と言ってるのだと思うが間違ってる？
OOSEやRUPじゃカバーできないプロジェクトがあるとか
いいながら、内心そんなところに理由があるんじゃないかと思うんだけど。

どっちかと言えば実践を中心に考えてるXPの方がマシだと思う。

>多数のボランティアが必要なプロジェクトで
>UML図を誰がどう作成してメインテナンスするのか
>というかそういう作業を好んでやる人はいるのか？

そうそう、そんなことしてる奴は周りから間違いなく異端視されるし。

絶対必要あげ

JavaSoftの J2EE patternsでわ、
パターン抽出と、ベスト・プラクティスの広報を通じて、
開発者のレベルアップにちっとは貢献してるでしょ。

だから、オープン・ソース・プロジェクトの
ドキュメント整備と同じ位重要な場合もありそう。

Apache Avalon, Struts とか、
フレームワークを前面に押し出したプロジェクトなら、
開発前から UML使ってても、不思議ではないんでわ？
んで、
と同じ

>>549
> そうそう、そんなことしてる奴は周りから間違いなく異端視されるし。
FreeBSD だと最近の大きなプロジェクトとして SMPng, KSE なんてのがあったが、
あれは paper 出したり、主要なメンバーで集まって設計方針を話し合ってたりした
ぞ。

OO じゃないから UML で図を書いてたわけじゃないけが、いずれにせよ大規模な
システムのコア部分を作る場合には、やっぱり何らかの形で設計を形にして、参
加者に伝達することは必須だと思われ。

アンチOOよりXP信者の方がウザイ。
アンチは教育してやれば理解するようになるが、
XP信者は永遠にプロセスを理解することは無理だな。

理解してないと思いたいのですね：)

大規模プロジェクトをOOでやるのは危険です。
その理由は以下に↓

なっちありがとう

http://pc.2ch.net/test/read.cgi/tech/1012484747/

なっち怒ってます（● ´ へ ｀ ●）

>>543
激しく同意

>>553
>アンチは教育してやれば理解するようになるが、
>XP信者は永遠にプロセスを理解することは無理だな。

XPってのはOOを理解した上での原点回帰だと思うが、その口ぶりだと553はOOを理
解せずにXPやってる現場ってのをどこかで見てきたようだな。
非常に希少な例だと思うんで紹介してもらえないか？

>>560
つーか、XP自体がプロセスを極端に調整した例だということを
理解してないようですな。
XPをちゃんと運用するためにはソフトウェア工学、特に方法論を
教科書憶えただけでなくしっかり身につけている人が必要で、
その上でその極端な例としてのXPを実行するもんだと思うのだが。
型無しと型破りの違いだな。

XPやってる奴って、ゴシック様式の建築物みたいなOOの方法論に
嫌気がさしてやってるもんだと思ってるけど。オレモナー（藁

訂正
×XPやってる
○XPに興味もってる

>>562
うん。そういうゴシック様式というか、セレモニー的な部分を
極端に減らしているのがXPだよね。
で、その分、リファクタリングやユニットテストで補なっているわけだし
ストーリーとユースケースも深い関係がある。
上に挙げた用語はどれもソフトウェア工学の用語だし、その背後にある
相互関係や危険サインや監視の仕方や対処法なんかを理解する必要がある
と思うけど、どうよ？

>>564
RUP、つーかラショナルが嫌なんだよね。結局プロセス実行するには
ツール買わせるように出来てる。この辺りの巧妙な手口は正直好かん。

理論としてはヘーゲルの「歴史」を想起させるぐらい立派な
ものを目指してるのかもしれないけどさ。その裏にある動機が
いやらしい形で見えてくるのがｷｼｮｲ。

>>565
あ、それは俺もある (藁
なんだよ、そのRはよぉ、って。

その一方で、プロセスってのはそのまま適用するものじゃなくて
各プロジェクト毎に改変して応用すべきものだとも思うんだよね。
だから、あんまり1つの方法論にベッタリなツールも嫌いだったりする。
俺にとってはツールに期待するのはUMLであってRUPじゃないんだな。

>>567
一応教科書読む限りじゃ、プロセスはプロジェクトにテンプレートを
与えるものっていう位置付けになっていて、ツールはプロジェクト
じゃなくてプロセスに対応するものという位置付けになってる。
だからツールはかなりの汎用性を持たせてあるんじゃないかな？

おれはRationalナントカなんて触ったこともみたこともないから
詳しいことはしらないｗ。教科書読んだだけのヘタレだから。
ただ一つ言えるのは、RUPなんていったところで彼らが仕様を無償で
公開してるのは方法論のモデリングに関する成果だけで、実務を
遂行するにあたり必要となるツールに関してはおそらく特許で
ガチガチになっているものと思われます。危険です。
彼らの言うプロセスとはイコール、ツールのことですｗ。


この濡れ衣を脱がせる人、なんか書き込んでください。

上の567は>>566の間違い

http://acd.nabunken.go.jp/Nabunken-Doc/chousa/international/Angkor/sites/PreRup/PreRup.html

>>567
＞ツール
というか、RUP にすら満足に使えない

必要かどうかは別として

結果として出したプログラムのレベルは
OOできない人＝アンチ<<<<<<<<<<<<<<<<<OOできる人
だと思うけど、どう？

>>571　そのプログラムのレベルって何で測るの？

>>572
if文のネストの深さで

>>571
必要かどうかは別として

「レベル」とか「○○>>>××」とか言ってる奴は
厨房だとだと思うけど、どう？

>>574
プログラムには、実装・設計とも良し悪しはある。みんな平等ということはない。

ただ、

　プログラマをOO派・非OO派に色分けしたときに、このスレで出てきたプログラ
　ムでそれぞれの能力を測る
　
ことには全く意味がないし、そんなことをして喜んでるのは厨房だと思う。

>>573　つまり　OOできる人ほどネストは深いと？

>>576 ソフトウェア・メトリクスの勉強汁

俺より頭がいいやつは全員氏ね

おとなしく学歴板にかえんな

非OOで書いたレベルの高いプログラムキボーン

>>577
cccc以外の使いやすいメトリクスツールを紹介してくれ。

BSD

>>581
http://osb.sra.co.jp/Smalltalk/ObjectOrrery/Japanese/manual/index.htm

>>エセsmalltalker
http://www.sra.co.jp/people/aoki/Jun/Main.htm

>>582
どのバージョンの？

4.4BSD 以降だと VM の設計なんかは、言語こそ C だがかなり OO っぽい
と思うぞ。newconfig とか new-bus も然り。

>>580
ＰＣ８８板アルフォス（by森田）

>>583
エセSmalltalkerって誰のことだ？
春になってきたのかなぁ…

>>567
ラショナル製品を買えないほどの貧乏会社で
働いてるんだね。プ

あんなの予算おりるか？
まあ、予算取ることはできても活用できなそうで乗り気にならない。

>>588
必要経費

>>589

不必要経費の間違いじゃネーノ？
買ったはいいが死蔵してる会社って結構多いぞ。

俺の私的メモ

ラショナル製品を導入後、継続して活用していますか?
・はい 5%
・いいえ 95%

つーかさ。
OOはプログラマなら誰でもかかる一種の麻疹みたいなもんなんだよ。
命を落とすほどの病気じゃないから、そう、目くじら立てるなって。

>>592

そう思わないと精神の安定が保てないCOBOLERさんですね。
構造化を1週間分処方しておきますので、薬局で受け取ってから帰宅して下さい。
理解できるまで来なくて結構です。

>>590
>買ったはいいが死蔵してる会社って結構多いぞ。

うちもだ (w

Rationalのツールを買って死蔵している会社の人は正直に手を挙げよう。
あ、ちゃんと使いこなしている人の数も知りたいな。

高くて買えないが統一プロセスの好きなやつ。
ラショナル製品を一通りそろえてもらって、
セミナーまで受けたのにさっぱりなやつ。

どっちが真実を現してる？

ＯＯ理解出来ないし難しいし挫折したから、役に立たないものだと
思い込みたいんだよね。
わかるよその気持ち。

あまりわかってないうちに、ＯＯに対して役に立たないと
いう早計な判断を下してしまった人も多そうだね。

>>596
ラショナル製品使いこなしてる人発見！

単純に工数が減ったのかどうかと顧客の満足度が知りたい。

設計なんて出来やしないのにRational Rose買いたがってる上司に
IIOSSくれて止めたよ（それだって猫に小判状態）。
そんな金あったら俺の給料あげてくれ。

IIOSSはJavaに特化されて手むかつく。

RUPやOOを信用してない人がこんなにいるのか、ってあるいみ
カルチャーショックですね。もしかしていきなり大きなこと
やろうとして失敗してしまってるんでしょうか。身近な簡単な
ことの積み重ねで、いいのに。日本人の得意なカイゼンでぜんぜん
おっけーですよ。

ワインバーグも、新しいことは必ず失敗するので、新しいことは
一つだけにとどめておくように薦めてますね。それに新しいやり方
というのは、3回目ぐらいにようやく成果がでるくらいの気持ちで
いるのがいいのでは。

あと結局道具じゃないっすよ。人ですね。
UMLだってコミュニケーションの道具に
すぎないんだから。状況に応じて、相手にあわせて、工夫はしないと。

今、3人のチームで仕事してますが、
RoseもVisioもつかってなくて、無印良品のらくがきちょうとホワイトボードが
一番役にたってる。

>>600
反復は実践してる？

>>601
仕事によります。仕様が綺麗に固まってる、固められるものなら長めです。
そうでないときは、2週間ぐらいを1iterationにすることが多いです。
今はお客さんが経費削減、経済状況の変化等々で、どうしても固まらないことが
おおく、1week単位に近くなることもあります。

今は小人数なので、あまり、重いことはしてません。XPに近いです。ペアプロも
してますし。

それはあんまりすごくないよ。

>>603
それより、君のすごい話キボーン

なんか言葉足らずだったみたいで誤解してる人がいるようだけど、俺が590で書い
た「死蔵」ってのはOOに挫折って意味じゃなくて、>>600が書いてるみたいに紙や
ホワイトボードを使ったミーティングで十分こなせるような規模の仕事が大多数で
、Rational製品を使うメリットが無いって事。
日本のソフトウェア受発注構造では厳格に管理されたプロセスよりも、仕様変更に
耐えられる機動力の方が要求されてるんだよな。

OOPLで工数が減るかは知らないが。
OOPLで非OOなコーディングをすると
工数が増えることだけは実感した26歳の春。

>>605
というかちゃんと管理できる人間がいない……

クラス宣言の情報 >>>>> UMLの情報 >>>>> UMLから読み取れる情報
UMLの冗長さ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> クラス宣言冗長さ
（オブジェクト指向はクラスベースだけじゃないが）

>>608
そりゃ、実装が一番詳細な情報だからな。

ただ木を見て森を見ずとか、実装の詳細に溺れる可能性も高い。

UMLなんてナニが重要なオブジェクトで、そいつがだれとどうか変わってるか、
そいつを変更するには、誰の了解を得なければいけないかがわかれば十分。

というわけでUMLからコードに落としたり、コードからUMLを生成したりすんのは
バカ。

そんな機能を売りにしてるツールは....
いやもっと、そんなもの買おうとする方が...

UMLのクラス図ってC++やJavaのキーワード、classとは直接の
関係はないんだよね？

>>611
少なくともトレーサビリティは大事だと思うが。

>610
どうい。ツールを売る方は金儲けから製品作ったんだろうが。

コードジェネレータによるコードが冗長で読み難い（←コード書いた人の考えが読み取れないんだよね）
という問題を解決するために、
クラスによる差分プログラミング開発（これがOOPかどうかは別にして）が行われるようになったんだよね。
だから、UMLによるコードジェネレータという考えはなんか外してると思った。

>>611
どのレベルのクラス図か、による。

分析段階で作ってるクラス図だと、動的分類／多重分類あたりまえなので、
C++ や Java のような静的分類／単一分類前提のクラスには一対一には
対応しない。

>>614
とりあえず、メモさせて頂きました。
元ネタはどこからですか？

>>615
UML モデリングのエッセンスとか、アナリシスパターンあたり。

distill本かanalysis本ですね。分かりました。
あまぞんにちゅもんしまう。

>614
最終的に実際にクラスになるものとそのメソッドを考えた方が
簡単ということは無いの？
実装上の問題も無いし。

というか同じことどっかで聞いたんだけど、
なに読めばいいのかわすれちったんだよね（ｗ

>>610,>>613
その手の言い切りが、技術の進歩をおくらせるんだよな。

>>620
そうかもな。

だがこのみちで飯を食う以上、最終的に金にならないと判断できたものは
それ以上使わなくても良いだろう。
UMLという記述言語は取り入れるがそれを取り巻くツールを使うかどうかは
全然別問題だしな。

>>618
場合によるな。

経験上、問題領域を素直にモデリングする場合には、動的分類／多重分類を
使った方が楽。どうも、その方が人間が物事を把握するフレームワークに近い
ような気がするんだわ。

じゃあ、常に「分析、設計、実装」レベルでクラス図を三種類作るかというと、そ
うでもない。そもそも図は

　コア部分だけ
　図に書いたほうが理解が深まる部分だけ

書けば十分だから図を書かない場合も多いし、結果的にいきなり設計レベル
図を書いて終わりってこともある。

>>621
>UMLという記述言語は取り入れるがそれを取り巻くツールを使うかどうかは
>全然別問題だしな。

OMGが推進してるMDAについてはどう思う？

まだ評価前

OOは少人数でしか使えん。
大人数でOOプロジェクトをまとめようとすると
宗教と同じで、戒律を作って各PGに守らせるよ
うにしないとだめ。つまり現実的な開発方法と
は言えない。

そして最初に戻る…

OOの話題は　シロウトというかクチだけ野郎でも口が出せるからなあ・・・

バランス木とかコルーチンとか実装の話になると黙るのに、そこだけ元気なもんで会議が踊る

>> バランス木とかコルーチンとか実装の話
それ自体OOと関係があるのか？

「ソフトウェア部品の再利用は夢なのか？ 」
@ITがついにこんなリンクタイトルで記事掲載
http://www.atmarkit.co.jp/fjava/devs/interview01/interview01.html

>>629
このおっさんが言ってるの再利用部品とはコンポーネントのことだね。

>>628
バランス木　・　オブジェクトをどう管理するのか
コルーチン　・　フィルターのようなオブジェクトをどう実装するか　

つーかさ、OO信者は早く得意のOOを駆使してOS作れや
無理だろうけどな（ｗ

Windowsがそうですが？

まとめ
１）オブジェクト指向は失敗した。
　　今後は以下ＯＯが失敗した以下の２点を目標にすべきである。

２）生産性の向上
　　この点について、Java等の一連のＯＯＰＬが失敗した最大の原因は
　　ユーザーライブラリを無視し、セミナー屋やマスコミを動員して
　　すでにあるソフトウエア資産の破棄に無理やり誘導したことである。

　　教訓として、ソフトウエア資産の破棄を迫るような言語は今後は
　　一種の詐欺と見なして良い。

２）再利用性
　　「まず言語構造・設計構造ありき」などという言語・構造原理主義を捨てて
　　再利用性を目標にすべきである。

>>633
WindowsはVisualBasicで作られてます。

>>634
コンポーネントってこと？

>>636
社内で使える物を作ろうとするとコスト高になるから違うな。

OOPL導入するときって、損益分岐点の見積もりがむつかしー。

どういう理由で？

難しくないよ。
導入しても生産性上がらないから、導入コスト分だけ無駄。
従って損益分岐点は存在しない。

>>640
あ…
納得。

OOPL使ってるからといってOOしてるわけでもないという理屈なら
OOPL入れたからといって OO しなければならない訳ではない

OOPLは好きだし使うけど OO嫌いな人もいるだろし

たとえば、

OOPL使いはじめたとして、ある程度わかってるヤツが解ってる範囲で使うのは、いい。
わかんないヤツが、従来の方法のまま、使うのもいい。
困るのは、解ってないのに、自分はもう極めたような勘違いして暴走しるようなやつ。
そういうやつの足の引っ張り力って、結構強いから、損益分岐点の遠のいていく速度が加速するんだよね。

俺に、そういうやつを説き伏せる力が無いのがいけないんだろうけど、
でも、こういうヤツに限って、周囲からはスゴイって評判だったりするんだ、往々にして。

グチになちたな、マ板逝こう…

コルーチンの話が出てるけど、OOの一つの課題と思ってる事があるんだ。
つまり、メッセージを送るって事は、送ると受けるという２つのオブジェクトがあるという事

例えば、データを入力する機能を持ったオブジェクトの実装では
A)InputDataというメソッドを呼び出して貰う
B)データが出来る都度　PutDataを呼び出す(最終的に外部のオブジェクトが呼ばれる)
という大きく分けて２つの方式があるけど、この２つの方式は切り替えられない。
もちろん、最初から設計してあれば、同期スレッドを使う事で可能だけど、スレッド切替
は比較的重い処理だから現実には選択肢にのぼらない。

当然使う方は Aの方式が楽で 作る方はBの方式が楽。圧縮とかの処理だと圧倒的にAが
難しくなるから、みなついBの方式で実装したがる。

あ長文になりそうだから、結論だけ書くと、
　つまりは、メッセージを送る方式の実装と　メッセージを受ける方式の実装が継承により
切替られるような仕掛けが OOPLに必要ではないかという事

長文きぼー

>スレッド切替は比較的重い処理だから現実には選択肢にのぼらない。
んなこたない
スレッド使った場合のオーバーヘッドの
全処理に占める割合をどのくらいに見積もってるんだ？

>>645 と言われて　喜んで書いたら叩かれそう

>>646　たとえばストリームのような1バイト単位のデータ送受で単なる
　　コルーチン切替ならメモリアクセスに隠れてしまう程度の負荷
　　だけど同期スレッドだとそうはいかない。

1バイト単位って・・・
お前fiber使ってみたいだけちゃうんかと(略
1kバッファリングすればオーバーヘッド1024分の1に減るだろ。
リアルタイム圧縮の話をしてるのか？

>>646
切り替えは重い。これ常識。

>>649
プロセッサや OS アーキテクチャにもよるけどな。

>>648
　そんな・・・・１KByte単位にバッファリングするなら　途中にFIFOオブジェクト経由して
　やればスレッドも不要、だいいちバッファリング出来るような処理なら >>644　分類A
　に書き換えるのもそんな手間じゃないよ

ちょと思いつきで書くのでつっこまれるだろーが

CORBA使ったやつとかだとOO使った大規模ってことにはならないかな？
にたよーなのでOSってわけではないがGNOMEとか

>だけど同期スレッドだとそうはいかない。
話がめちゃくちゃ・・・・

>>644　さん　　それで今はどうやってるの？

たとえば Bタイプで作った後で Aタイプに直さなければならない場合に

>>654
　色々かな。

　デバッグが終ったソースで弄るのがメンドクサイ時はアセンブラソース吐かせて、
　スタックフレーム弄ってコルーチンにしてる。
　　つまりクラス内にスタック用のエリアを取っておいて、BP/SPをそっちに切替えておく
　で、PutDataとかのメソッド内で　これをもう一度切替えるというか交換するようにする
　でも、API呼び出しがメソッド内であるとダメね

未デバックだとそんなこと毎回やってられないから　なんとか書き換えるけど

再利用ねー。
再利用なら昔からしてるよ。ライブラリとかいう形でね。
あとはパターンだね。考え方、テクニックの再利用。
ソースコードの再利用は考えないほうがヨシ
XPとかの本でも、そう言ってるし。

>>644
http://www.eiffel.com/doc/manuals/technology/concurrency/CONCURRENCY.html

マイクロソフトはOOで再利用できんかったから
新しいOSリリースするたびに一から作り直してたんじゃないのか？

>>658
> 新しいOSリリースするたびに一から作り直してたんじゃないのか？
Windows NT 3.x, NT 4.x, 2000, XP と全部スクラッチから書いたっつーことは
あるまい。

OSは基本的なデータ構造はあんまり変らないから
フルスクラッチなんてことはあるわけない。

.NET周りはフルスクラッチだろうけどね

JVMを流用してんじゃないの？

だとするとベンチマークは激速だな(藁

オブジェクト指向が登場するまで、プログラマーは再利用と言う事を知らず、
プログラムを組むたびに１から作りなおしていたのです。
オブジェクト指向の登場で初めてプログラムの部品化、再利用が可能となりました。

>>664 そんな夢を見たんですね？

プログラマーをオブジェクト指向に移行させようとすると大抵の場合
素直に受け入れてくれません。
多くのプログラマーは具体例で示しても
「そういう事は今の言語でもできる」などと躊躇して技術を学ぶ姿勢を
見せません。
何故こういう事態になるのでしょうか？
それは旧来タイプのプログラマーは職人気質の人が多く、
ソフトウエアの生産性・再利用には無関心だからです。
オブジェクト指向はやる気のある人間の居る会社でしか受け入れられないという
壁に突き当たっています。
日本のソフトウエア産業の振興の為にもこうした壁を取り払わなければ
なりません。



てな事をＯＯ初期のセミナー屋は言っていた。
詐欺だつうの。

フレームワークを利用する事を再利用と呼んでないか？
それなら clibを利用する事も再利用だぞ

>>667
再利用で生産性上がってないの。
ＦＷは商売になってないし。

>668
思いっきりなってんだろ
FW自体が無料と商売になってないはまったく別だぞ

>>666
本当の理由
1.既にシステムを作る方法を一つ手に入れていて、それを使えば
困らないのに、今更新しいものを覚えるのが面倒くさいから。
2.胡散臭いから

1はともかくとして、2は、今まで実務の実績も経験もないくせに
偉そうにOOを語っていた詐欺師紛いのエバンジェリストなヤツラ
の責任だよな。金だけ湯水の如く請求するくせに、コストパフォー
マンス悪すぎなヤツラ。さらに、成果が出ないのを客の能力の
せいにするアフォ。そんなのばっかり。

引っかかるのはあの程度の嘘が見ぬけないアフォばかり。

アセンブラは大変というけど　アセンブラもマクロを使ってライブラリをしっかり整備してれば
今の高級言語並の生産性はあった。　ただし熟練者ご用達って事。

ポータビリチーはどうすんだ?

>>873 ホントだよね　クラスライブラリに依存してるOOPLでどうするんだろ

ﾌﾟｯ

>>674
煽りにしても頭悪すぎ。

>>675-676

歩調乱すなよ！
もうちょっと我慢したらもっと大物が釣れたのにぃ。

>>672
>今の高級言語並の生産性はあった。
ネタ？

>>672
ライブラリをしっかり整備しないといけなくて、
なおかつ熟練者じゃないといけない
って生産性悪いって言わないか。

アセンブラ下<アセンブラ中<<<java下<=アセンブラ上<<java中<java上
こんな感じといいたいんだろう。
人数の分布は・・・・

OOの方が型からクラスと、考える対象の粒度が大きくなった分
考えやすくなったのでは？
あとOOならではテクニックあるし。

ライブラリに関しては昔も今も変わらずって感じがする

>>680
ありえない。
汗でhellowold書いてみればわかる。
汗のみでソフトウェア開発は無理。
特にx86は死ぬ。

汗でもマクロでごまかせる部分があるからじゃない？
でも上じゃないとねー

アセンブラでマクロを書いたら高級言語になりました。

そう言えばアセンブラは最初から隠蔽、カプセル化をサポートしてたね。>public

>>682
x86、asmでソフトウェア開発してます。但しwin32 + masm。
Cで書くのと殆ど差は無いです。

>>682
BIOS に文字列へのポインタ渡すだけだよ？

>>686
それは「私はＣが苦手です」と言っているのと同じ事では？

>>688
ヒューレットパッカのスタック電卓って知ってる？ 1+1を 1 ent 1 + って入力するやつ
会社の先輩にあれでなければ電卓使えない人がいるよ
Cのa=b+cで書くより アセンブラで考えた方が楽な人もいるって考えたらいいんじゃない？

アセンブラなら　上で出てる　メインーサブルーチン関係に縛られない書き方も自由だしね

>>688
どれ位で苦手って言うのか知らないけど、win32プログラムは
基本的にAPI叩くだけだから言語は何でもあまり関係無いのでは。
特にmasmはあまりにマクロが強力で、Cで書くのと差は殆ど感じないよ。

まあC++は苦手だけどね。

>689
私もその一人、逆ポーランドというの。forthなんて言語も同じね。
実は慣れると、(1+2)*(3+4)みたいな演算が、読んだとおりに入れればいいのよ（１に２足して3に４足したものをかける-> 1 ent 2 + 3 ent 4 + *）。実に楽。

「アセンブラで考えたほうが楽」とは別の話。あなたがHPの電卓の背景にある体系を知らないだけ。

>688
そもそもCは高級アセンブラっていうぐらいだから、基本的には素養は同じ。
アセンブラも高級言語化してるしね。逆にアセンブラもかけないCプログラマのほうが問題じゃないの。
ただ、Intel系の場合、レジスタの個性を知る必要があるので、その意味では大きく違うが。

スレ違いっぽいけど、どっかのホームページで見つけてきたもののコピペ。

「プログラミング言語でみる性格判断」

* C

他人のプログラムは決して信じない。ライブラリは自分でつくるものだと思っている。

* C++

自己主張がなく、まわりに流されやすい。

* Java

俗物。熱しやすく、冷めやすい。

* BASIC

間違った基礎教育を受けた。もうやり直しがきかない。

* Perl

おたく。変態。奇才。

* AWK

詩人。夢想化。複雑な仕事には向かない。

* SmallTalk

理想主義者。現実を認めようとせず、箱庭に楽しみを求める。

* Prolog

論理主義者。哲学者。地に足がついていない。

* LISP

変人。協調性がなく、常に自分が正しいと思っている。

* COBOL

がんこで融通がきかない事務屋。すぐ昔話をする。時代に取り残されていることに気がついているが、自分ではどうすることもできない。

* FORTRAN

実験派の研究者。数学的・物理的な美しさは求めるが、プログラミングの美しさは求めない。

* FORTH

人間的な美しさよりも、機械的な美しさを求める。

>>692
CもC++もJavaもPerlもAwkもPrologも使う漏れって・・・

* C＃　　よらば大樹の陰
* Delphi 独立独歩

>>693
他人のプログラムは決して信じずまわりに流されやすい俗物。おたく、変態で地に足がついていない。

>>693
他人のプログラムは決して信じず、まわりに流されやすい俗物。
複雑な仕事には向かず、おたく、変態で地に足がついていない。

awkが入ってなかったヨ。

というか　全てのコンパイラは　アセンブラの高級マクロだ

Ｃ＃　一発狙いの詐欺師だが、時代を読む能がない。

* DQN　C#を「Ｃ＃」と全角英数で書いてしまう。

＞* BASIC
＞
＞間違った基礎教育を受けた。もうやり直しがきかない。

これは性格診断か？（ｗ

* 妄想君　どうでも良い事を既成のルールだと主張してしまう。

* 顔が真っ赤なDQN　「ＤＱＮ」と全角で書いて欲しかったらしい。

>>692-702
asmが無いYO!

>>692
ここがマ板とム板に別れた頃にそんなスレッドあったよ。

asm
すべてを把握しないと気がすまない超管理主義者。付き合う人間は一苦労。

>>705
俺アセンブラ使いだけどOO的設計 管理が面倒だから
行き当たりばったりで思いついたところからかけるアセンブラが好き

>>706
>行き当たりばったりで思いついたところからかける

アセンブラなら許されるってもんじゃないと思うぞ。
OOPLだって行き当たりばったりにクラスを書くことは出来る。

行き当たりばったりプログラミングといえばXPだな。

その分テストファーストを徹底しますが、何か？

テストファーストを盾に行き当たりばったりを正当化されちゃったあ

リファクタリングも当然やりますが、何か？

テストファースト・リファクタリングを盾に行き当たりばったりを正当化されちゃったあ

過不足の無いプログラムが出来上がりますが、何か？

糞仕様でサッパリ使えないオナニー丸出しの
るーちん・くらす・こんぽーねんと
がでてきたあ

過不足の無いプログラムを盾に行き当たりばったりを正当化されちゃったあ…　あら？？

>>714
方法論ばっかやってる連中にありがちだねえ。
俺も一度見たことあるけど、全部捨てさせた。

>>715
藁

プロが一人でやったいきあがりばったりは　なかなかバカに出来ませんて

最悪なのは複数人とか　クロス開発でテスト環境がしっかりしてないとかで
　「この部分をブラックボックスとして」　
いきあたりばったりでやった場合だね。

二人で作業してくれとプログラム依頼されて、
一人がチンタラとクラス設計してるうちに俺がコーディング
始めて、結局おれがクラス設計が終わってないうちに
100％コーディングを済ませたことがある。

>>719

相方は719が作ったコードのクラス設計を理解した？

>>720
漏れのはクラスじゃない。
数千行程度のプログラムならサクサク書いたほうが
早いってことよ。

714の心配が現実のものになったわけか

>>721

今はそれで良くても仕様変更があったら719しかそのコードいじれなくなるよ。
そんなにサクサク作れるスキルがあるならペアプロとまでは言わないけど、相方に
設計を説明しながら作ればよかったのに。

>>721みたいなのは、ちょっとした使い捨てのツールを作らすのに、社内に１人くらい
いると便利。けど、よそ様にはお見せ出来ない。
作ってる暇があったら、先に仕様書書けｺﾞﾙｧ。

>>723　そんなもん仕様変更があったらまたサクサク作ればいいだろ？
　　俺はこれ作ればそれで終わり。
　　管理まで頼まれてねえや

>>692
SmallTalkじゃなくてSmalltalkね。

ところでSmalltalkもCもJavaもやる俺の場合は一体
俗物なのか理想主義者なのか、はっきりしてくれい。

>>726
> ところでSmalltalkもCもJavaもやる
ふつー、多言語を使う。

>>725

ところで、719がサクサクと作ってるのはどんな分野のプログラム？

SmalltalkとCとLispをやる俺は…
ただのプログラミング言語好きなだけじゃん

お答えします。
>>726
他人のプログラムは決して信じない俗物。
現実を認めようとせず、箱庭に楽しみを求める。

>>729
他人のプログラムは決して信じない変人。
協調性がなく、箱庭に楽しみを求める。

んで719が作るプログラムと同じように719自身も使い捨てられると。

一般的には731に同意。ちょっとましなマネージャなら使わないからね。
ただ、昔ファミコンのころのゲームのプログラムなんかは（今は知らないが）
売っちまったら二度と手入れられないので、中身はめちゃくちゃ。
とにかく納期に間に合わせてパッチ当てまくればよかった。
その時代なら719も生きる場所があったかも。
ちなみに開発はアセンブラ。

719じゃないけど、
まあ内容にもよるけど数千行ならクラス設計してやるような規模じゃないと思うが？

普通に構造化設計しながらコメント入れてはサクサクコード書いていけば
数千行ならデバックしながら7日もあれば書けるよ。
もちろんOOPL使えば構造化設計としてクラスも作るけどさ

行数だけでカタってる時点でアウト。

>>732
今だとプログラムの規模がでかくなっていて、プログラマだけでも最低 3 人、
多いと二桁って世界になってるから、

　中身めちゃくちゃ
　本人も把握してない

だと話にならんよ。

hello, worldを作るときに設計から始める奴はいないように、
数千行程度の小さなプログラムで設計をするのはどうかと思う。

まぁ新人ならば数千行程度の小さなプログラムでも
設計しといた方がいいと思うけど

>>733
数千行を仮に 5 千行としておくが、それで 7 日？　内容にもよるが、一日に
間違いのないコードを 700 行きっちり書き連ねていくのは、かなり辛いぞ。

設計を適当にすませるってことは、ある程度の行き戻りは覚悟することに
なるから、実質的に書くコードはもっと増えるし。

> 行数だけでカタってる時点でアウト。
全くその通りなんだが、まぁ、おおざっぱな話をするときには使える指標では
あるよな。（勤務評定で使ってはダメだが）

アプリケーションよりのコードで、同期やらなにやらが込み入ってない部分だ
と、俺は平均して一日 300 行（コメント、空行込み、修正や削減分は差し引い
て）ぐらいだよ。これがスレッドの同期が絡んだり、ハードウェアよりのプログラ
ムだと、さらに少なくなる。

>>733の「普通に構造化設計しながら」には、あるていど納得できる。
だけど、>>719のやり方とは、大きな差があると思う。

設計しないでダラダラ書いたら数千行になっちゃったプログラムと、
さらっとでも、しっかりした設計が出来てるから、数千行でコンパクトに
収まったプログラムの差、くらい大きな差かも。

まあ5千行だと7日は厳しいな。
千〜９千って事だから√(1000*9999)　でおよそ３千行程度を考えてたよ

俺の場合は1日に、だいたい２千行くらい書いて、3/4捨てるような感じかな
関数・クラス単位にデバックして、動かなかったらさっさと捨てては作り直してるし

あ！　でも俺の場合　1日って労働時間15〜6時間だった・・・鬱

>>741
納期直前はともかく、私は基本的に１日８時間しかコードは書かないなぁ。
それ以上は集中力が続かなくて、1 時間よけいにコードを書くと、翌日に
2 時間デバックする羽目になる（ｗ

あまった時間は集中力のいらない書類整理とか、Web やメールを読んで
技術動向をチェック、なんて方に回してます。

> 関数・クラス単位にデバックして、動かなかったらさっさと捨てては作り直してるし
何が問題なのかをつきとめないと、また同じミスを繰り返すぞ。人が書いた
コードを回収しているような場合には

　「腐ったモジュールは丸ごと捨てて、作り直しちまえ」

とすることはあるが、自分が書いたコードではさすがに無いよ。

>>742
> 私は基本的に１日８時間しかコードは書かないなぁ。
え？デバッグする時間は？
コードを書く時間ってそんなに必要ないでしょう。

プログラムを書く場合に必要な時間って多くの場合、
設計とデバッグ。

>>743
ああ、設計・実装・テスト・デバッグ含めての時間だよ。

最近は実装・テスト・デバッグはスパイラルにやってるから、個々の時間は
記録に残してないです。

１分で５行しかタイプしないとして 300行　は１時間もあれば
書けるんだから、そんなもんじゃないの？

まあ色んな方法があるよな　他人の仕事みてたらさ

デバッカで延々トレースしたり悩んでるの見たら　さっさと作り直した方が楽だろうにと思うし
こんだけ動いてるなら作り直すよりデバックした方が速いだろうにと思うし

あ、おれ、腐ってなくても捨てるコード、いっぱいあるなぁ。
でも、捨てる前に、ちゃんと動作することを確認してるけど。

抽象度の低い言語＝アセンブラに近いほど　デバックするよりコメント残して再構成する方が効率良くなるな

>>748
データフローを中心に考えるプログラムならば再構成でなんとかなる。
で、短いプログラムにはデータフロー中心で考えるものが多い。

>>745
実際にプログラミングして、作業記録をつけてみ。

>>745
タイピストとプログラマの仕事をごっちゃにしてないか？

漏れはアセンブラである程度の大きさの関数書くときは、途中で一息ついて
そこまでの条件書くようにしてる。たとえば、
# ここまででax,bxはフリー cxは処理済みのビット数　es:[di-1]までは処理済み
# ds:[si+bx]は全ビット処理済みでないことに注意
とか。
で、書きなおすときは、一息ごと（ｗ　にやるようにしてる。

> で、書きなおすときは、一息ごと（ｗ　にやるようにしてる。
その感覚は同感。

俺の場合は１日かけて完成できないクラスは
なんか間違っているということで、破棄することにしている。

俺は、インラインでないアセンブラで書く時はマクロで書くから、マクロ単位に一挙に書いてるな

>>753
俺は一日にはこだわってないけど、数日かけて１つのクラス実装してると、
たいがい途中で、「あ、これは別のクラスにしなくちゃだな」って思う。
思ってもそのまま実装しちゃうことも、よくあるけど。

>736
あんたがいなくなった後、メンテするやつにその数千行だけを読ませるの？
なんかドキュメント書くだろ。それって設計書を読ませるんでないの？
規模によって、設計書のレベルは変わるかもしれんが。

>>756
なんかタイトルと離れた話題だけど、
数千行（３千行程度）のプログラムとしての設計書はソース自身になるように作るのが普通では？
仕様書ならともかく、設計書を別に作らされてるってかわいそうとしか思えないのだが

「ソースが仕様書」は、作ったやつの一人よがりの場合が多い。
きちんとした書式の設計書でなくていいから、どんな作りになってるのか、メモくらいのこせ。

>>758
コメントで十分では? :)

十分だよなあ　いったい何が欲しいの？

設計の概念の無いやつのコメントなんて、信用できるかよ（ｗ
そんなやつのなら、だらだら書いてたら数千行になっちゃったようなクソコードだろ。

せめて、「どんな作りになってるのか」くらい書いとけ、ソースの先頭でもいいから。
それも必要無いようなのは、コメントもいらん。
一目でクソだとわかるほうが、捨てる判断もしやすいからな。

>>761　たった３千行なら、どんな作りになってるかくらい見たら判るだろ？
　どんな言語で開発してるんだ？　もしかして素のbasicか？

そんなキミにいいこと教えてやろう アセンブラなら ':' をgrepしろ
pascal　なら procedure / function で grepすればいい
cなら一度コンパイルしてマップファイルを見ればいい

>>762
数千行程度なら、いわゆる紙の仕様書は要らんと思うなぁ。

構造体とグローバル変数、それに関数の頭に簡単なコメントがつけてあれば
間に合う。それでは間に合わない腐ったコードもあるけど、それはコメントが
あってもやっぱりダメだし（ｗ

>>761 設計の概念が無いって変な言葉だね

結局　自分のスタイルと違う設計は解読し難いというだけだろ。それは結局勉強不足さ。

そして新人が育たないっ、と。

つか、設計についてのコメント残さないと、手離れ悪いから、いや。
参考になるＵＲＬだけ書いとく事もあるけど、勉強しろｺﾞﾙｧって
言うよりも、ソースの先頭に全部書いてあるから読めｺﾞﾙｧ
のほうが、手離れがいい。
勉強不足なやつに、いちいち聞かれるの、うざいし。

>>765-766
別に新人教育のためにプログラム書くわけじゃないし。

コメントなんて無くてもわかるようなプログラムを書け。

>>768　でも、ちょっと普通じゃない使い方してたらコメントは欲しいな

>>761
> 設計の概念の無いやつのコメントなんて、信用できるかよ（ｗ
> そんなやつのなら、だらだら書いてたら数千行になっちゃったようなクソコードだろ。
設計書を書かない奴と設計書を書けない奴を混同する奴の方が信用できない。
常に設計書を書かなければ気が済まない強迫観念をもったキチガイの方が信用できない。

設計書なんてエレベータみたいなもの。
　３階建ての民家にあるのは馬鹿
　５階建てくらいのマンションにはあれば便利だが、無くとも何とかなる。
２０階建て以上もある高層建築にないのも馬鹿

3000行ほどの小さなプログラムも組んだことのない
新人君 or 学生君ならば設計しといたほうがいいと忠告しておく。

設計書書けなんて言ってないんだけどなぁ。
どんな作りになってるかのメモくらい残せよって言ってるんだが。
物作りするとき、走り書きくらいするだろ。
それがあとでコード読む手がかりになるなら、残さない理由が知りたい。

あ、もしかして、３０００行程度のプログラムが脳内設計で書ける自慢？
ならしょうがないな。
おれがわるかったよ。

>>771
行数で語るから、話が混乱するんだと思うが。

べつに 1 万行でも単純なプログラムなら要らんし、百行でも複雑な
アルゴリズムを使ってるなら参考文献なり具体的な説明なりを残さ
ないと、後で自分が困る。

それだけだろ？

たとえば円を描くルーチンがあったとして、円を描くアルゴリズムまで説明を書くか？

3000行の円を描くルーチンなら、説明いるかも（ｗ

>>773
Win32 あたりで既存の API を呼び出すだけなら書かない。

そうではなく、整数中点円スキャン変換アルゴリズムを自前で実装してる
なら、関数の解説（これは引数で指定された点を中心とする半径 n の円
を描く、云々）と、アルゴリズムに関する参考文献か解説を書いておく。

>>770-771
記憶力が良いか頭がイーかたなんでしょう。
私は1月前に書いた自分のコードが
コメント無しでは読めません。

上の方にﾄﾞｷｭｿな奴がいると、やれ「全ての関数について」関数仕様書を
書けだの、その関数仕様書には「処理概要」とかいって、ソース見ればわかる
制御構造とか、下手すりゃフロチャートまで書けとか、そのくせ関数名は
命名規則で8文字以内とか、そんな経験があると、「ドキュメントなんかいらん!!」
と言いたくなるよな(藁

だけど、ここで出てるのは、そういう定型的なドキュメントじゃなく、
どこがどうなっているかの概略を説明する簡単な文書だろ?

もちろんどんなプログラムかによるけど、3000行なら、A4 1〜2枚くらいは
説明書があったほうがいいと思う。

コメントでいいという意見もあるようだけど、コメントはソースの
「その場所」に関する説明だから、全体を概観する文書は、やっぱ別に要るよ。

例え3000行程度の小さいプログラムであっても、例えばどこにトイレがあって
どこが居間でどこが台所なのか、台所から今に行くにはどうすればいいのか
という事くらいは、（後でメンテナンスするつもりなら）書いておいたほうが
いいと思われ。

その3000行を、クラスなりなんなりで分割したそれぞれが、ちゃんと「居間」
であったり「トイレ」であったりするなら、それ以上の詳細を説明する文章
までは要らないと思うが。

3000行がmain関数一本と言うアホなプログラムじゃなければ、そういった
メモには価値があると思われ。

>>776
これって結構本当。
詳細設計がちがちでなければ、書きながら
考えてるし。

777のいう「概略を説明する簡単な文書」はなんと呼べばいいんでしょう？このまま？
自分は大昔からこれを書くようにしているので、馴染み深いのですが、
他の人はそうでもないようです。

>>780
設計概要説明書。

3000行で文書が必要という人は、どの程度の文書を書いてるのか興味あるなぁ。
ソースと一緒に公開してくれる人はいないかな。。。

オブジェクト指向は結局何も超えられなかった。
これに尽きる。
この方向でさらに突つきまわしても何も出てこないだろう。
ＯＯブームを冷たい視線で眺めていた開発者達は今こそ見えてきた
頂上を目指す。

勉強始めた頃はメモを書いてからコードを書いていた
そのうちコードを書きながらメモを書くようになった
今は、行分割エディタでコメント部にメモを書きながらコードを書く

> 物作りするとき、走り書きくらいするだろ。
> それがあとでコード読む手がかりになるなら、残さない理由が知りたい。
C言語のプログラムだという前提で言うと
ディレクトリ構成でシステムの構成と階層を示している。
ファイルでモジュールを示している。
ヘッダコメントでそのモジュールの役割を示している。
includeで各モジュール間の依存関係を示している。
関数名で機能を示している。
ややこしい場所にはコメントを入れる

他に何が必要？GNUではこれで数万行を超えるプログラムが
何の問題もなく作られている。

もちろん、大規模なプロジェクトの場合、ドキュメントが一切ないのは
太平洋を横断するのに地図を持たずに航海するのと同じくらい無謀

だが、近所を散歩するのに地図を持って散歩する馬鹿はいまい

(´-｀).。oＯ(そんなに必死に自慢しなくても…)

(´-｀).。oＯ(>>786はなにをどんな自慢だと思ったんだろう…)

(´-｀).。oＯ(設計のメモ残す必要無しって自慢してるやつが１名、自作自演ごくろうさま…)

ついに論理的な発言ができなくなって
感情的な１行煽りしかできなくなった約１名に捧げる

「なんでこのスレにしがみついてるの？」
「なんでこのスレにしがみついてるの？」

(´-｀).。oＯ(まさに、オマエモナー)

俺は設計書が必要だとは一度も言ってないんだがなぁ。
作り始めに簡単なメモくらい書くだろ、それを残さない理由が知りたいって言ってるんだが。
無くても大丈夫とか、ＧＮＵでは大丈夫、は理由にならんだろ。
だから脳内設計で物作りが出来る自慢にしかならないのに…

ま、いいや、「あったほうがいい」っていう意見がいくつか出てるから。

>>788
小さなプログラムの設計のメモって何のために残すの？
読みにくいソースとコメント書いてしまった罰ゲーム？

>>789
時間がたってからソース読む時間を節約するため。
とくに、書いた人以外が読むとき。

>>791
> 無くても大丈夫とか、ＧＮＵでは大丈夫、は理由にならんだろ。
理由は以前に示したが、君の目がフシアナサンのようなのでもう一度書く
　　ディレクトリ構成でシステムの構成と階層を示している。
　　ファイルでモジュールを示している。
　　ヘッダコメントでそのモジュールの役割を示している。
　　includeで各モジュール間の依存関係を示している。
　　関数名で機能を示している。
　　ややこしい場所にはコメントを入れる
これ以上に何の情報が必要？
必要ないから書かないだけ。
必要ないのに存在する情報は必要な情報を隠す働きしかしない。
つまり有害無益

で、こちらからも質問？
作り始めの簡単なメモってどういう情報があるの？
モジュール構成やモジュールの役割以外の役に立つ情報って何？

>>793
> 時間がたってからソース読む時間を節約するため。
> とくに、書いた人以外が読むとき。
で、その「作り始めの簡単なメモ」のメンテナンスは
大幅な修正が発生したら忘れずに修正するんだよね？

その修正コストってソース読む時間を節約するコストよりも
十分に小さいの？特に小さなソースの場合。

２重管理するだけの価値が本当にあるの？

モジュール構成やモジュールの役割が１つにまとまってたら、それはりっぱに設計書として機能するだろ。
けど、それは分散してるより、まとまってたほうが見通しがいい。
3000行程度なら、最初に決めたとおりで作れるだろう。
（当然、規模が大きくなれば、ちゃんとした設計書の必要性が高くなるし、最初の設計のとおりに
　ならない確立も高くなる）
だから、モジュール構成やモジュールの役割の説明として、役に立つ。
（そのメモが実際の作りと違ってたときにどーするよ？っていう反論なら認めたんだがなぁ…）


ディレクトリ構成は、どんなモジュールがあるか、は示していても、モジュール間の依存関係
を必ず示しているとはかぎらない。
ファイルとモジュールも１対１に対応しているとは限らない。
もし、ファイル構成が、プログラムの作りを的確に反映しているのなら、
「モジュールの構成はファイルの構成に対応してる」
って事を書いたメモがあるのと無いのとでは、やはり、コードを読む時（特に読み始め）の効率が違う。

ちゅーことだ。

「大幅な修正」が発生したら、やっぱり、修正についてのメモは、書くんでないか？
したら、最初のメモに追加しとけばいい。

なんか、俺の言ってのは、「考えたことはメモする習慣つけとけ」　ってことみたいだな。

> （そのメモが実際の作りと違ってたときにどーするよ？っていう反論なら認めたんだがなぁ…）
そんなメモは想像もしてなかった。

> モジュール間の依存関係を必ず示しているとはかぎらない。
includeで示している

> ファイルとモジュールも１対１に対応しているとは限らない。
まぁそれは「全て大文字のシンボルはマクロとは限らない」と同じくらい
少ないと思うが。
特にJavaの場合、１ファイル１クラスに対応しているので、

> 「モジュールの構成はファイルの構成に対応してる」
とは、Javaの場合は絶対に必要ないし、
少なくとも俺がCでプログラムを書く場合はモジュール＝ファイル。

>少なくとも俺がCでプログラムを書く場合はモジュール＝ファイル。

どういう意味？

>>800
789じゃないけど、

関数を、機能単位で分類したものをモジュールと言うとして、
ひとつのソースファイルに、ちゃんと機能単位で分類したソースを入れると
いうことだろ。

下手な奴はわけのわからん分類をして関数を変なソースに突っ込むが、
俺はちゃんと機能単位で分類してるんだぜ、ってことだと思われ。
あと、staticで情報隠蔽したりとかね。

当たり前のことですわな。

俺もドキュメント書きは嫌いだし、3000行やそこらのプログラムなら、
ヘッダファイル見ながら楽勝で書ける… ってことをこのスレのずっと前の方に
書いたのは俺だ(w

「作り始めに簡単なメモ」も書かないなあ。書いてるときは、ちゃんと
わかってるから、メモなんか不要だよ。

でも、後で読む人のことを考えたら、やっぱり多少のメモは必要だと思う。
3000行だと微妙なとこだけどな。「まずどこから読み始めるか」なんて
情報は必要だよ。

>>795
>２重管理するだけの価値が本当にあるの？

マネージャクラスが書かせたがるような定型の仕様書の類は確かに
2重管理の弊害が大きい。

でも、「どこがどうなっているかの概略を説明する簡単な文書」と俺が
言ってるのは、それに変更が加わるようなときはプログラムを捨てる時だって
ぐらいに大まかなものなので問題なし。

コメントじゃ図がかけないしね。モジュール間の構造とか、データ構造とか、
図の方がわかりやすい事って多いだろ。