854コメント333KB

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

■ このスレッドは過去ログ倉庫に格納されています

0001うつつつつ

NGNG

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

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

0002デフォルトの名無しさん

NGNG

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

0003デフォルトの名無しさん

NGNG

クソすれたてんな　ボケが

0004デフォルトの名無しさん

NGNG

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

だから書いてる。

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

0005糞スレ

NGNG

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

0006デフォルトの名無しさん

NGNG

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

0007デフォルトの名無しさん

NGNG

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

0008デフォルトの名無しさん

NGNG

>>1=4

00094

NGNG

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

00109

NGNG

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

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

001110

NGNG

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

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

よろしく。

0012デフォルトの名無しさん

NGNG

ん。

0013デフォルトの名無しさん

NGNG

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

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

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

0014デフォルトの名無しさん

NGNG

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

0015デフォルトの名無しさん

NGNG

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

0016デフォルトの名無しさん

NGNG

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

0017デフォルトの名無しさん

NGNG

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

0018デフォルトの名無しさん

NGNG

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

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

0019デフォルトの名無しさん

NGNG

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

0020　

NGNG

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

0021デフォルトの名無しさん

NGNG

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

0022776

NGNG

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

0023　

NGNG

>>22
ではないです。

0024デフォルトの名無しさん

NGNG

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

１、ギコ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

0025デフォルトの名無しさん

NGNG

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

002624

NGNG

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

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

0027デフォルトの名無しさん

NGNG

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

0028デフォルトの名無しさん

NGNG

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

0029デフォルトの名無しさん

NGNG

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

0030　

NGNG

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

0031デフォルトの名無しさん

NGNG

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

0032デフォルトの名無しさん

NGNG

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

0033デフォルトの名無しさん

NGNG

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

0034デフォルトの名無しさん

NGNG

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

0035デフォルトの名無しさん

NGNG

りょーかい>34

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

0036デフォルトの名無しさん

NGNG

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

で、関数ポインタとメタプログラミングの関係って何？　関数ポインタを使うと書けて
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
いわゆるメタ構造かな？
関数ポインタ無いと静的プログラムしか書けない。
---

0037デフォルトの名無しさん

NGNG

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

0038デフォルトの名無しさん

NGNG

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

0039デフォルトの名無しさん

NGNG

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

特に COM なんかは

　OLE, ActiveX, COM, DCOM, COM+

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

0040　

NGNG

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

0041デフォルトの名無しさん

NGNG

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

004224

NGNG

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

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

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

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

0043　

NGNG

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

0044デフォルトの名無しさん

NGNG

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

0045デフォルトの名無しさん

NGNG

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

0046デフォルトの名無しさん

NGNG

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

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

っつー感じなのか。

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

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

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

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

0047デフォルトの名無しさん

NGNG

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

004824

NGNG

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

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

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

継承は使われていますよ

0049デフォルトの名無しさん

NGNG

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

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

005024

NGNG

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

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

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

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

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

0051デフォルトの名無しさん

NGNG

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

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

0052デフォルトの名無しさん

NGNG

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

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

005324

NGNG

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

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

0054　

NGNG

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

0055　

NGNG

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

0056デフォルトの名無しさん

NGNG

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

0057　

NGNG

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

005824

NGNG

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

0059デフォルトの名無しさん

NGNG

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

0060　

NGNG

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

0061デフォルトの名無しさん

NGNG

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

ただ

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

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

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

0062デフォルトの名無しさん

NGNG

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

0063　

NGNG

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

006449

NGNG

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

006524

NGNG

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

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

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

0066　

NGNG

>>65
他にいるかよ。

0067デフォルトの名無しさん

NGNG

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

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

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

006824

NGNG

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

0069デフォルトの名無しさん

NGNG

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

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

0070デフォルトの名無しさん

NGNG

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

007124

NGNG

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

0072　

NGNG

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

0073デフォルトの名無しさん

NGNG

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

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

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

0074デフォルトの名無しさん

NGNG

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

0075デフォルトの名無しさん

NGNG

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

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

007624

NGNG

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

>>73-74

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

007724

NGNG

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

　まあ２CHだからいいか

0078デフォルトの名無しさん

NGNG

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

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

0079デフォルトの名無しさん

NGNG

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

0080あるベンチャーの風景

NGNG

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

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

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

0081デフォルトの名無しさん

NGNG

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

008224

NGNG

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

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

0083デフォルトの名無しさん

NGNG

>>75
禿同。

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

008424

NGNG

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

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

0085デフォルトの名無しさん

NGNG

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

0086デフォルトの名無しさん

NGNG

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

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

008724

NGNG

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

0088デフォルトの名無しさん

NGNG

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

0089デフォルトの名無しさん

NGNG

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

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

0090デフォルトの名無しさん

NGNG

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

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

009180

NGNG

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

0092デフォルトの名無しさん

NGNG

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

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

0093デフォルトの名無しさん

NGNG

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

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

0094デフォルトの名無しさん

NGNG

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

009590

NGNG

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

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

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

009680

NGNG

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

0097デフォルトの名無しさん

NGNG

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

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

0098デフォルトの名無しさん

NGNG

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

0099デフォルトの名無しさん

NGNG

>>97

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

010080

NGNG

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

010124

NGNG

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

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

0102　

NGNG

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

0103デフォルトの名無しさん

NGNG

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

0104デフォルトの名無しさん

NGNG

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

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

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

010524

NGNG

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

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

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

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

0106デフォルトの名無しさん

NGNG

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

0107　

NGNG

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

0108デフォルトの名無しさん

NGNG

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

0109デフォルトの名無しさん

NGNG

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

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

0110デフォルトの名無しさん

NGNG

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

0111　

NGNG

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

0112デフォルトの名無しさん

NGNG

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

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

0113デフォルトの名無しさん

NGNG

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

0114デフォルトの名無しさん

NGNG

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

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

0115　

NGNG

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

011624

NGNG

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

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

011736じゃないが

NGNG

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

ＣとＪＡＶＡを比較した場合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のことだよね？
文字列を実行する、しかも呼ばれた側呼び出し元の環境を参照でき
る、ってことでいいんですよね？

0118　

NGNG

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

0119デフォルトの名無しさん

NGNG

evalってなんれすか？

0120デフォルトの名無しさん

NGNG

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

eval("print 1+2");

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

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

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

0121デフォルトの名無しさん

NGNG

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

0122デフォルトの名無しさん

NGNG

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

軍事板逝けドアホウ！

0123デフォルトの名無しさん

NGNG

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

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

0124デフォルトの名無しさん

NGNG

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

そうなんだよね。

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

0125デフォルトの名無しさん

NGNG

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

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

0126デフォルトの名無しさん

NGNG

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

0127デフォルトの名無しさん

NGNG

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

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

0128124

NGNG

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

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

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

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

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

0129デフォルトの名無しさん

NGNG

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

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

0130デフォルトの名無しさん

NGNG

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

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

0131　

NGNG

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

0132デフォルトの名無しさん

NGNG

>>131
たとえば?

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

0133デフォルトの名無しさん

NGNG

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

0134デフォルトの名無しさん

NGNG

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

0135デフォルトの名無しさん

NGNG

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

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

0136　

NGNG

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

0137　

NGNG

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

0138デフォルトの名無しさん

NGNG

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

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

0139　デフォルトの名無しさん

NGNG

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

0140デフォルトの名無しさん

NGNG

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

0141デフォルトの名無しさん

NGNG

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

0142デフォルトの名無しさん

NGNG

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

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

0143デフォルトの名無しさん

NGNG

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

0144　

NGNG

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

0145　

NGNG

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

0146デフォルトの名無しさん

NGNG

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

0147デフォルトの名無しさん

NGNG

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

0148デフォルトの名無しさん

NGNG

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

0149デフォルトの名無しさん

NGNG

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

0150デフォルトの名無しさん

NGNG

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

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

0151デフォルトの名無しさん

NGNG

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

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

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

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

0152デフォルトの名無しさん

NGNG

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

0153131

NGNG

>カプセル化＝情報隠蔽

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

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

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

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

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

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

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

0154131

NGNG

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

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

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

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

0155131じゃなかった

NGNG

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

それはそれとして、

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

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

0156デフォルトの名無しさん

NGNG

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

0157デフォルトの名無しさん

NGNG

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

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

というのが近いのかな。

0158155=135

NGNG

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

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

0159デフォルトの名無しさん

NGNG

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

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

0160デフォルトの名無しさん

NGNG

>>153

同意。

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

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

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

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

0161デフォルトの名無しさん

NGNG

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

スマソ

0162デフォルトの名無しさん

NGNG

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

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

0163160

NGNG

>>162

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

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

0164デフォルトの名無しさん

NGNG

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

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

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

0165デフォルトの名無しさん

NGNG

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

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

0166デフォルトの名無しさん

NGNG

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

0167デフォルトの名無しさん

NGNG

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

0168デフォルトの名無しさん

NGNG

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

0169デフォルトの名無しさん

NGNG

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

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

とかあるわけだし。

0170デフォルトの名無しさん

NGNG

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

0171糞

NGNG

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

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

0172デフォルトの名無しさん

NGNG

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

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

0173デフォルトの名無しさん

NGNG

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

0174デフォルトの名無しさん

NGNG

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

0175　

NGNG

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

0176デフォルトの名無しさん

NGNG

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

0177戦場では役に立たないと武蔵様も・・・

NGNG

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

0178デフォルトの名無しさん

NGNG

ﾜｹﾜｶﾗｿ

0179デフォルトの名無しさん

NGNG

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

0180デフォルトの名無しさん

NGNG

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

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

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

0181デフォルトの名無しさん

NGNG

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

0182デフォルトの名無しさん

NGNG

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

0183デフォルトの名無しさん

NGNG

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

0184デフォルトの名無しさん

NGNG

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

0185デフォルトの名無しさん

NGNG

>>175
このスレは

悲惨な「　」を晒すスレ

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

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

0186デフォルトの名無しさん

NGNG

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

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

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

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

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

0187デフォルトの名無しさん

NGNG

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

0188デフォルトの名無しさん

NGNG

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

0189デフォルトの名無しさん

NGNG

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

0190デフォルトの名無しさん

NGNG

OOPLの仕組み知らんの？

0191デフォルトの名無しさん

NGNG

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

0192デフォルトの名無しさん

NGNG

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

0193デフォルトの名無しさん

NGNG

>>192
それで？

0194デフォルトの名無しさん

NGNG

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

0195デフォルトの名無しさん

NGNG

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

0196デフォルトの名無しさん

NGNG

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

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

0197デフォルトの名無しさん

NGNG

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

0198デフォルトの名無しさん

NGNG

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

0199デフォルトの名無しさん

NGNG

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

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

0200デフォルトの名無しさん

NGNG

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

0201199

NGNG

あれ？　文字化けしてる？

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

0202デフォルトの名無しさん

NGNG

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

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

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

0203　

NGNG

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

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

0204デフォルトの名無しさん

NGNG

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

0205デフォルトの名無しさん

NGNG

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

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

0206デフォルトの名無しさん

NGNG

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

0207　

NGNG

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

0208デフォルトの名無しさん

NGNG

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

0209デフォルトの名無しさん

NGNG

手続き型でも同じです。

0210　

NGNG

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

0211デフォルトの名無しさん

NGNG

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

0212デフォルトの名無しさん

NGNG

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

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

0213デフォルトの名無しさん

NGNG

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

0214デフォルトの名無しさん

NGNG

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

0215デフォルトの名無しさん

NGNG

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

0216デフォルトの名無しさん

NGNG

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

0217デフォルトの名無しさん

NGNG

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

0218　

NGNG

ＶＣ＋＋は除外>>212

0219デフォルトの名無しさん

NGNG

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

0220旅の始まりの人

NGNG

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

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

0221デフォルトの名無しさん

NGNG

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

0222旅の始まりの人

NGNG

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

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

0223とあるダメ社員

NGNG

>>212

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

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

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

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

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

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

0224デフォルトの名無しさん

NGNG

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

ということらしいぞ。

0225デフォルトの名無しさん

NGNG

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

0226　

NGNG

横レスだが、

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

0227旅の始まりの人

NGNG

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

0228デフォルトの名無しさん

NGNG

COBOL -> COBOOL

(･∀･)ｲｲ!!

0229デフォルトの名無しさん

NGNG

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

0230旅の始まりの人

NGNG

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

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

0231たびの始まりの人

NGNG

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

0232とあるダメ社員

NGNG

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

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

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

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

0233旅の始まりの人

NGNG

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

0234デフォルトの名無しさん

NGNG

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

0235とあるダメ社員

NGNG

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

0236旅の始まりの人

NGNG

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

0237旅の始まりの人

NGNG

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

0238デフォルトの名無しさん

NGNG

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

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

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

0239　

NGNG

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

0240デフォルトの名無しさん

NGNG

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

0241旅の始まりの人

NGNG

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

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

0242デフォルトの名無しさん

NGNG

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

0243デフォルトの名無しさん

NGNG

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

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

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

0244デフォルトの名無しさん

NGNG

>>238 がいい事言った！

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

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

0245デフォルトの名無しさん

NGNG

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

0246デフォルトの名無しさん

NGNG

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

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

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

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

0247デフォルトの名無しさん

NGNG

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

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

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

0248246

NGNG

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

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

0249デフォルトの名無しさん

NGNG

まるでランボー(w

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

0250デフォルトの名無しさん

NGNG

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

0251デフォルトの名無しさん

NGNG

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

0252デフォルトの名無しさん

NGNG

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

0253デフォルトの名無しさん

NGNG

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

0254デフォルトの名無しさん

NGNG

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

0255とあるダメ社員

NGNG

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

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

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

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

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

0256John ◆0z.4Is5E

NGNG

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

0257デフォルトの名無しさん

NGNG

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

2chでよく見る光景。

0258デフォルトの名無しさん

NGNG

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

0259John ◆0z.4Is5E

NGNG

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

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

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

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

0260デフォルトの名無しさん

NGNG

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

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

0261デフォルトの名無しさん

NGNG

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

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

0262デフォルトの名無しさん

NGNG

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

0263John ◆0z.4Is5E

NGNG

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

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

0264デフォルトの名無しさん

NGNG

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

0265デフォルトの名無しさん

NGNG

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

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

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

0266デフォルトの名無しさん

NGNG

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

0267デフォルトの名無しさん

NGNG

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

UnitTest使えば簡単。

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

0268デフォルトの名無しさん

NGNG

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

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

0269デフォルトの名無しさん

NGNG

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

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

0270デフォルトの名無しさん

NGNG

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

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

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

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

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

0271デフォルトの名無しさん

NGNG

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

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

0272デフォルトの名無しさん

NGNG

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

0273デフォルトの名無しさん

NGNG

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

0274デフォルトの名無しさん

NGNG

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

0275270=46

NGNG

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

0276デフォルトの名無しさん

NGNG

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

ﾜﾗﾀ

0277デフォルトの名無しさん

NGNG

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

0278デフォルトの名無しさん

NGNG

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

0279デフォルトの名無しさん

NGNG

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

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

0280とあるダメ社員

NGNG

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

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

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

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

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

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

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

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

0281デフォルトの名無しさん

NGNG

引用前後してしまったが

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

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

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

0282デフォルトの名無しさん

NGNG

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

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

0283デフォルトの名無しさん

NGNG

>>281
追記

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

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

0284デフォルトの名無しさん

NGNG

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

0285デフォルトの名無しさん

NGNG

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

0286267

NGNG

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

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

0287デフォルトの名無しさん

NGNG

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

0288とあるダメ社員

NGNG

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

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

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

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

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

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

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

0289デフォルトの名無しさん

NGNG

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

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

0290デフォルトの名無しさん

NGNG

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

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

0291とあるダメ社員

NGNG

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

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

0292とあるダメ社員

NGNG

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

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

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

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

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

0293デフォルトの名無しさん

NGNG

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

0294デフォルトの名無しさん

NGNG

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

0295281

NGNG

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

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

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

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

0296デフォルトの名無しさん

NGNG

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

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

0297デフォルトの名無しさん

NGNG

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

0298とあるダメ社員

NGNG

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

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

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

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

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

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

0299293

NGNG

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

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

0300デフォルトの名無しさん

NGNG

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

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

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

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

0301とあるダメ社員

NGNG

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

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

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

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

0302デフォルトの名無しさん

NGNG

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

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

0303とあるダメ社員

NGNG

>>300

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

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

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

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

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

0304293

NGNG

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

0305デフォルトの名無しさん

NGNG

>>304
まさか。

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

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

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

0306John ◆0z.4Is5E

NGNG

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

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

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

0307John ◆0z.4Is5E

NGNG

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

0308デフォルトの名無しさん

NGNG

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

0309デフォルトの名無しさん

NGNG

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

0310デフォルトの名無しさん

NGNG

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

0311305

NGNG

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

0312デフォルトの名無しさん

NGNG

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

0313デフォルトの名無しさん

NGNG

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

0314281

NGNG

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

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

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

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

0315246

NGNG

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

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

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

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

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

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

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

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

0316246

NGNG

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

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

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

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

0317デフォルトの名無しさん

NGNG

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

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

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

0318デフォルトの名無しさん

NGNG

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

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

0319デフォルトの名無しさん

NGNG

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

0320とあるダメ社員

NGNG

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

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

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

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

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

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

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

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

0321デフォルトの名無しさん

NGNG

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

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

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

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

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

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

0322デフォルトの名無しさん

NGNG

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

0323デフォルトの名無しさん

NGNG

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

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

0324281

NGNG

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

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

0325281

NGNG

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

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

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

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

0326デフォルトの名無しさん

NGNG

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

0327293

NGNG

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

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

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

0328293

NGNG

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

0329デフォルトの名無しさん

NGNG

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

0330デフォルトの名無しさん

NGNG

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

0331デフォルトの名無しさん

NGNG

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

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

0332305

NGNG

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

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

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

0333318

NGNG

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

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

>概念を導入

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

0334デフォルトの名無しさん

NGNG

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

0335281

NGNG

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

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

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

と煽ってみるてすｔ

0336デフォルトの名無しさん

NGNG

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

0337デフォルトの名無しさん

NGNG

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

0338デフォルトの名無しさん

NGNG

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

0339デフォルトの名無しさん

NGNG

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

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

0340デフォルトの名無しさん

NGNG

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

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

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

0341デフォルトの名無しさん

NGNG

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

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

0342デフォルトの名無しさん

NGNG

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

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

0343デフォルトの名無しさん

NGNG

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

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

0344デフォルトの名無しさん

NGNG

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

これは危険は思い込み。

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

0345とあるダメ社員

NGNG

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

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

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

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

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

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

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

0346281

NGNG

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

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

と愚痴ってみるてｓｔ

0347　

NGNG

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

0348デフォルトの名無しさん

NGNG

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

0349　

NGNG

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

0350とあるダメ社員

NGNG

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

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

0351デフォルトの名無しさん

NGNG

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

0352デフォルトの名無しさん

NGNG

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

0353281

NGNG

>>351
だなｗ

ｵﾚﾓﾅｰ

0354とあるダメ社員

NGNG

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

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

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

0355デフォルトの名無しさん

NGNG

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

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

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

0356デフォルトの名無しさん

NGNG

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

0357293

NGNG

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

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

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

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

0358とあるダメ社員

NGNG

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

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

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

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

0359デフォルトの名無しさん

NGNG

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

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

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

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

0360デフォルトの名無しさん

NGNG

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

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

0361デフォルトの名無しさん

NGNG

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

0362デフォルトの名無しさん

NGNG

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

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

0363デフォルトの名無しさん

NGNG

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

0364デフォルトの名無しさん

NGNG

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

0365デフォルトの名無しさん

NGNG

>>361
まったくだ。

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

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

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

0366293

NGNG

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

0367デフォルトの名無しさん

NGNG

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

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

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

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

0368デフォルトの名無しさん

NGNG

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

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

0369293

NGNG

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

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

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

0370とあるダメ社員

NGNG

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

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

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

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

0371293

NGNG

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

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

0372デフォルトの名無しさん

NGNG

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

ほっとけ
ほっとけ

0373デフォルトの名無しさん

NGNG

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

>>372
プププププ…

0374デフォルトの名無しさん

NGNG

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

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

0375デフォルトの名無しさん

NGNG

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

0376293

NGNG

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

0377359

NGNG

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

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

0378デフォルトの名無しさん

NGNG

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

0379デフォルトの名無しさん

NGNG

切腹申し付ける

0380デフォルトの名無しさん

NGNG

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

0381デフォルトの名無しさん

NGNG

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

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

0382デフォルトの名無しさん

NGNG

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

0383380

NGNG

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

0384380

NGNG

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

0385デフォルトの名無しさん

NGNG

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

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

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

0386デフォルトの名無しさん

NGNG

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

0387デフォルトの名無しさん

NGNG

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

0388デフォルトの名無しさん

NGNG

↑使えない人

0389デフォルトの名無しさん

NGNG

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

0390デフォルトの名無しさん

NGNG

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

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

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

0391デフォルトの名無しさん

NGNG

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

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

0392デフォルトの名無しさん

NGNG

>>391
そのネタは、

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

0393デフォルトの名無しさん

NGNG

>>392
OOがね。

0394デフォルトの名無しさん

NGNG

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

0395デフォルトの名無しさん

NGNG

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

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

0396デフォルトの名無しさん

NGNG

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

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

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

0397デフォルトの名無しさん

NGNG

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

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

0398デフォルトの名無しさん

NGNG

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

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

0399デフォルトの名無しさん

NGNG

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

0400デフォルトの名無しさん

NGNG

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

0401デフォルトの名無しさん

NGNG

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

0402デフォルトの名無しさん

NGNG

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

0403デフォルトの名無しさん

NGNG

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

0404デフォルトの名無しさん

NGNG

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

0405デフォルトの名無しさん

NGNG

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

0406デフォルトの名無しさん

NGNG

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

0407デフォルトの名無しさん

NGNG

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

0408デフォルトの名無しさん

NGNG

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

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

0409デフォルトの名無しさん

NGNG

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

0410デフォルトの名無しさん

NGNG

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

0411デフォルトの名無しさん

NGNG

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

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

0412デフォルトの名無しさん

NGNG

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

0413デフォルトの名無しさん

NGNG

また馬鹿が一人..

0414デフォルトの名無しさん

NGNG

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

0415デフォルトの名無しさん

NGNG

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

0416デフォルトの名無しさん

NGNG

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

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

0417デフォルトの名無しさん

NGNG

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

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

0418デフォルトの名無しさん

NGNG

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

0419デフォルトの名無しさん

NGNG

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

0420デフォルトの名無しさん

NGNG

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

0421デフォルトの名無しさん

NGNG

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

0422421

NGNG

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

0423デフォルトの名無しさん

NGNG

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

0424デフォルトの名無しさん

NGNG

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

0425デフォルトの名無しさん

NGNG

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

0426デフォルトの名無しさん

NGNG

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

0427デフォルトの名無しさん

NGNG

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

0428素朴な疑問

NGNG

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

0429デフォルトの名無しさん

NGNG

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

0430デフォルトの名無しさん

NGNG

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

0431デフォルトの名無しさん

NGNG

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

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

0432デフォルトの名無しさん

NGNG

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

0433　

NGNG

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

0434４３０

NGNG

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

0435デフォルトの名無しさん

NGNG

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

0436デフォルトの名無しさん

NGNG

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

0437デフォルトの名無しさん

NGNG

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

0438デフォルトの名無しさん

NGNG

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

0439デフォルトの名無しさん

NGNG

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

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

0440デフォルトの名無しさん

NGNG

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

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

犬::鳴く、猫::鳴く

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

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

0441デフォルトの名無しさん

NGNG

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

0442デフォルトの名無しさん

NGNG

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

0443デフォルトの名無しさん

NGNG

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

0444デフォルトの名無しさん

NGNG

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

0445デフォルトの名無しさん

NGNG

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

0446　

NGNG

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

0447歴史

NGNG

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

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

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

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

第四段階・・・略・・・

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

0448デフォルトの名無しさん

NGNG

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

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

0449　

NGNG

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

0450デフォルトの名無しさん

NGNG

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

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

0451デフォルトの名無しさん

NGNG

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

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

0452デフォルトの名無しさん

NGNG

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

0453デフォルトの名無しさん

NGNG

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

0454デフォルトの名無しさん

NGNG

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

0455デフォルトの名無しさん

NGNG

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

0456デフォルトの名無しさん

NGNG

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

0457デフォルトの名無しさん

NGNG

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

0458デフォルトの名無しさん

NGNG

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

0459デフォルトの名無しさん

NGNG

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

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

0460デフォルトの名無しさん

NGNG

訂正
4layerの
4layerと

0461デフォルトの名無しさん

NGNG

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

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

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

0462デフォルトの名無しさん

NGNG

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

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

だぜ？　集中力が続かんよ。（コピペの場合を除く）

0463デフォルトの名無しさん

NGNG

一週間に精々3,4000行だな。
単純なものならもっといくかもしれないが、
そういったのはC/C++を使わないで、
スクリプト使うだろうし。

0464デフォルトの名無しさん

NGNG

>>450
そうか？　RUP の解説書を読んでも、それで明日から OOA のプロになるのは
無理だろ。

プログラミングの方法論というのは、経験の裏づけがあって初めて適用できるも
ので、マクドナルドのマニュアルのように

　誰にでも通じる言葉で説明できて、
　聞けばすぐに分かる

とはいかんだろ。（プログラミングに限らず、物理学の実験だろうが数学の勉強
方法でも同じだが）

0465デフォルトの名無しさん

NGNG

OOとマルチ商法の違いを教えてください。

0466デフォルトの名無しさん

NGNG

>>458

methodology … 手法に関する理論
method … 実際に個々に適用する手法

0467デフォルトの名無しさん

NGNG

売れること、それのみが価値を実現します。
売れないものは価値がないのです。

by 信者

0468とあるダメ社員

NGNG

一日でずいぶん進んでしまいましたね。
>>448

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

それを、一般論の形でよいので、少しでも知りたかったのですが、残念ながら私の理解力不足とコミ
ュニケーション能力不足もあって、わかりませんでした。
個人的なスキル自体が足りない、というのはわかるのですが、それだけで差を埋められるものなのか
わかっておりません。

0469デフォルトの名無しさん

NGNG

>>467
UMLとどうかかわりあってるのかが知りたいです。

0470デフォルトの名無しさん

NGNG

＞人の能力に頼ったを開発手法
を、どうやって一般論にしろというのだろう・・・

「一般的に、一般論には例外があります」とでも？

0471デフォルトの名無しさん

NGNG

明文化されていないようなものは方法とは言わない

0472デフォルトの名無しさん

NGNG

　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　|　　はいはい
　|　　取り壊しの邪魔だから出てった出てった
　＼＿＿＿　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　 |／＿＿___
　　 , --､　　　 |　 |.＿ |　　　OOはやっぱクソだったな！　　　　　まったくだ
　　f＝+=l.　　 |　 ||.O|.|　　　　　　　 ∧＿∧　　　　　　　∧＿∧
　　(,,ﾟДﾟ).　　　|　 ||.O|.|　　　　　　　（　・∀・）　ﾆﾔﾆﾔ　（・∀・　）
　 ⊂　　つ .　　|　 ||長||　　　　　　　（　　　　つ　　　　　（　　　　）
　～|　　|　彡　|　 ||編||　　　　　　　｜｜　| 　　　　　　｜｜　|
　　し`Ｊ　　　　|　 |￣ .|　　　　　　　（_＿）＿）　　　　　（＿（＿）
　~~　　　　　　　￣￣￣　　　　　~~
　　　　　　　　　　　　　　　　　　　　　　　　　　　~~

　　　ｺﾞｺﾞｺﾞｺﾞｺﾞ

　　　　　　/ゝ　　　　 ┌―┐ <--OO
　　　　　 /　●.　　┌┘品└┐
　　{{　[]台　　　　　 |　ﾛﾛ　ﾛﾛ.|
　￣￣ﾟﾟﾟﾟﾟﾟ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　＼＼あぼ――ん／　／
　　　　　　　　　　　　(´;)
　　　　　　　　/＼　 (;)┌―┐
　　　　　　　 /　<<●(´;;;)　└┐ }}
　　　　　　 []台　　 (;;⌒);;;) ﾛﾛ.|
　￣￣￣￣ﾟﾟﾟﾟﾟﾟ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　　　　　　　　　　　　　　　　　　―OO完―

0473とあるダメ社員

NGNG

>>470

｜470 ：デフォルトの名無しさん：02/03/03 15:51
｜＞人の能力に頼ったを開発手法
｜を、どうやって一般論にしろというのだろう・・・
｜
｜「一般的に、一般論には例外があります」とでも？

人の能力＝個人のスキルだけならば、単に「勉強しろ」で終わるのかもしれませんね。

しかしながら、スポーツでのコツのような非常に言語化しずらい（出来ない？）分野
であるならばともかく、なぜ「一般論化出来ない」と考えるのか、理解に苦しみます。

せいぜい、「複雑であり、詳細に説明するのは難しい」といったところではないでしょ
うか？

448さんも言及しておられるように、
｜自分なりの方法論というかその人の能力に頼ったを開発手法を持って
方法論的なものが知りたいのです。ノウハウといっても良いのかもしれません。

もちろん、お答えくださる方の善意に寄りかかっているだけですので、ここで
伺えるかどうかはわかりませんが。

0474デフォルトの名無しさん

NGNG

またこの流れか。
もうお前らDQNにOO教えるの止めたくなってきた。
お前らOOで分析したらｶｺｲｲ?、とかOOPLで作ったらﾗｸﾁﾝ？
とかそんなことしか考えてねーだろ。
OO分析は顧客の要望と仕様をすり合わせるツール。
OOPLは仕様とプログラムをツライチにしやすい言語。
これだけだ。種も仕掛けもね-よ。

0475デフォルトの名無しさん

NGNG

>>474
誰もおまえに教えてくれなんざ頼んじゃいないよ
イヤなら顔出さなきゃいいじゃん

引っ込みな

0476デフォルトの名無しさん

NGNG

>>474
え？教えてるつもりだったのか？
どうりで議論にならないわけだ。
納得納得。

念のため逝っとくが、俺はアンチOOじゃないぞ。
分析設計実装全てでOO使ってる。

0477デフォルトの名無しさん

NGNG

٠٩٧٣هخخخخخخعف٤٣صضسيسسسسسغ

0478デフォルトの名無しさん

NGNG

>>473
囲碁や将棋のプロのような部分もあるんだと考えればいいんじゃないの？
経験で鍛えられる人間の直観力のような部分が

0479デフォルトの名無しさん

NGNG

いまどきOOも分からん奴は
PG廃業してスパゲッティ屋に転職したらどうであろうか。
伊太利亜にでも逝ってｸﾀﾞﾁｬｲ。

0480デフォルトの名無しさん

NGNG

>>479

スパゲッティなら日々生産してますが、何か？

0481デフォルトの名無しさん

NGNG

('-`)。o○（今度は明文化と一般化の区別がついてないよ…）

0482デフォルトの名無しさん

NGNG

OO信者撤退中！
　　　　　　　　　　　　　　　　┌─┐
　　　　　　　　　　　　　　　　　｜も.｜
　　　　　　　　　　　　　　　　　｜う　|
　　　　　　　　　　　　　　　　　│来│
　　　　　　　　　　　　　　　　　│ね│
　　　　　　　　　　　　　　　　　│え .|
　　　　　　　　　　　　　　　　　│よ .|
　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│
　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ
　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　（　`Д）
　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ヽ┐U
～～　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎－>┘◎

0483デフォルトの名無しさん

NGNG

OO信者がついに負けを認めたか。。。ッフ。

0484OO嫌いなOOスーパユーザ

NGNG

もし万が一盲目的なOO信者ってのが居るならば、
そんなのは消えてよし、と。

んで、アンチは何を言いたいの。
要点を押さえて簡潔に言ってね。

0485デフォルトの名無しさん

NGNG

>OOスーパユーザ
ﾌﾟｯ

0486デフォルトの名無しさん

NGNG

>>485 すかしっ屁臭いよ

0487デフォルトの名無しさん

NGNG

>>485 アンチは屁たれ、と。

0488デフォルトの名無しさん

NGNG

>>447
ふうん、オブジェクト志向にも30年余りの歴史があるんですね。
CやUnixと同じじゃじじい。
この辺のことをうまく書いたパソコン現代史といった本はないもんですかね。

0489デフォルトの名無しさん

NGNG

ぁ、>>447 参考になりました。H本さん良い解説ありがとうございます。

＞この辺のことをうまく書いたパソコン現代史といった本はないもんですかね。
どうでしょ、私は寡聞にして存じません。
OOPSLA とか、ACMあたりで、
良いまとめを出してるんかもしれないですけど...。

なんかOO方面って、まだまだ流動的で、
歴史を書くほど確定していない気もする...。

0490デフォルトの名無しさん

NGNG

はっきり言ってOOは歴史はあるが実績が無い。

0491デフォルトの名無しさん

NGNG

ここで、ウィンドウシステムとか、Webシステムとか、
例を挙げても、きっと>>490は納得してくれないだろうなぁ。

0492デフォルトの名無しさん

NGNG

「部品化」とか「再利用性」というお題目のようにいう人は、
いま、そのクラスが利用しやすいか？　使いやすいか？という「利用性」
のことを忘れてることが多い、という言葉に最近じーんときてます。
未来も大事ですが、もっと大事なのは今ですよね。

再利用可能なものって、作成にはとても手間ひまかかるしコストがかかります。
たとえばC++,Java,SmallTalk,...のクラスライブラリのような性質のもの、
かける価値のあるものには、コストをかけられますが。

極端な話、再利用性なんて普段は意識しなくてもいいんじゃないでしょうか。

0493John ◆0z.4Is5E

NGNG

>>492
例えばmp3プレイヤーを作ったとする。
次に、wmaもサポートしようと思ったとき、簡単にプログラムできると
すごくいいと思わない？

0494デフォルトの名無しさん

NGNG

たとえばwebブラウザを作ったとする。
次に、タブブラウザを作ろうと思ったとき、簡単にプログラムできるけど
いちいちセキュリティーホールを引き継ぐの、すごくいいと思わない?

0495492

NGNG

>>493
Strategyパターンみたいに、可換に作るのが自然で、モデル的にも
シンプルになるものはいいと思いますよ。

意図がうまく説明できなくてすんません、(←ってことはまだよく
わかってないんだろうな、ワシ)

客が機能Aが欲しいといったときに、抽象化、一般化したほうが楽なときは
一般化するけど、Aだけつくるほうが安上がりのときはAしかつくらない、
みたいな感じなんです。

0496ddd

NGNG

みんな最初は
ooってものを
知らなかったわけだが
理解できたきっかけは？

0497デフォルトの名無しさん

NGNG

>>496
JavaのコーディングとGofの本。

0498デフォルトの名無しさん

NGNG

>>496
タートルグラフィックス

0499デフォルトの名無しさん

NGNG

>>498
懐かしいな。小学生のとき、LOGOでrobot動かして遊んだなぁ。
FOWARDとか、BACKとか、
でも、おばかだたので、パパートさん(でしたっけ？)が期待したように
再帰で、へんてこりんな、パターン動かしたりはできなかったし、思いつきも
しなかった。

0500デフォルトの名無しさん

NGNG

大昔のOh!MZの記事。

0501デフォルトの名無しさん

NGNG

>>496
Smalltalk

0502デフォルトの名無しさん

NGNG

>>496
２０年くらい前の月刊ＡＳＣＩＩのアドベンチャーゲームの製作記事

0503デフォルトの名無しさん

NGNG

>>502
表参道？

0504デフォルトの名無しさん

NGNG

プログラミングとしてのOOはJavaで色々と勉強させて
もらったけど、それよりもインパクトのでかかったのは
RUPとかXPなんかのソフトウェアプロセスを勉強しだして
からかなあ。対象物は全てオブジェクトとみなして同一に
扱うっていうフラットな考え方は目鱗だったよ。

0505502

NGNG

>>503
だったか、南青山だったか忘れた。
「持ち上げるとか、投げるとか、使うとか、そういうコマンドの結果を、
　アイテムごとに定義するんじゃなてく、もっと効率のいい方法無いかな？」
っていう話題からSmalltalkの話になるような記事だったと思う。

0506デフォルトの名無しさん

NGNG

データ指向とオブジェクト指向の世界の衝突
http://www-6.ibm.com/jp/developerworks/components/010629/j_co-tipdiv.html

★(EJB) 開発チームの重大な問題
★オブジェクト指向開発者とデータ指向開発者が一緒に作業する場合に味わう難しさ
★オブジェクトとデータの対立の悪影響を受けている組織は一般に、
「策略に明け暮れる」ことに対し開発者のフラストレーションがたまり、転職が増える傾向

0507デフォルトの名無しさん

NGNG

ttp://www2j.biglobe.ne.jp/~sakuchan/it/20000614.txt
プロセス指向という用語もあるんだね

プロセス指向 VS データ指向　VS オブジェクト指向

どっちかいうとうちはプロセス指向かな

0508デフォルトの名無しさん

NGNG

>>506 をぉー、気になるテーマだ、ありがとござますー

0509デフォルトの名無しさん

NGNG

>>462 なんとなく>>448 は、
自前で「データ中心アプローチ」方法論構築しちゃった井の中の蛙ーって感じがする。
＃海は広いよ

0510デフォルトの名無しさん

NGNG

1日に３千行か、対戦５目並べで書いた事はあるな　・・・それだけ

0511デフォルトの名無しさん

NGNG

データ指向で検索してヒットするページだけど

ttp://member.nifty.ne.jp/yamazaki/doc_data02.html

ちょっと　上の2ページとは用語が違うようだ

0512John ◆0z.4Is5E

NGNG

>Strategyパターンみたいに、可換に作るのが自然で、モデル的にも
>シンプルになるものはいいと思いますよ。
なんかよくわからないけど、例がわかりずらかったのかも。
例えば、サーバーの状態をセキュリティーの会社の報告するプログラム。
プロトコルAで送信していたけど、理由があってセキュリティーの会社を
変えたとする。
するとプロトコルBで送信しなくてはいけない。
ただ、ここでプロトコルAでの送信機能が失われるような
変更を加えるのは、頭悪いでしょ？
他は何も変えず、プロトコルBでの送信機能を追加するには・・・
一般的な表現をするなら、
ファクトリーメソッドがあれば十分、充分？。
とりあえず、デザパタは無視していいと思うよ。
デザパタから入ると、柔軟な発想ができなくなりそうな気がする。

0513デフォルトの名無しさん

NGNG

話がそれるが、Gof本ってなんでGof本っていうの？

0514デフォルトの名無しさん

NGNG

Gang Of Five

0515S

NGNG

ttp://www.momonga.org/~manabu/public/se/mozilla/build.html
より、mozillaの例を挙げてみる…

クラス・ブラウザ
・C++ や Java など, いわゆるオブジェクト指向言語のソース・ファイルは理解が難しい
・・継承により, どのようなメソッドがどこで定義されているか把握しずらい
・・メソッド (関数) はクラス名::メソッド名と呼び出されるが, クラス名が省略される場合があり,
・・また, メソッドは引数の組み合わせによって選択されるため, 同じ名前のものがたくさん定義される
・動的な解析ツールを駆使する - デバッガでトレースをとる
・・イベント駆動ループからの呼び出し
・・ストリームなどの非同期イベントからの呼び出し
・・マルチスレッド実行時のオブジェクト間通信
・結論: できのよいクラスブラウザを持っていないと手に追えない

OOに異を唱えるわけではないんだが、(とゆうかかなりはまっている私
こんな現実もあるのでは。
ってか優秀なクラスブラウザってないかな？
できたらフリー/学生に手が出る値段で

0516515

NGNG

>514いちおうGang Of Fourとつっこんでおく。

0517515

NGNG

しかしSmalltalkのクラスブラウザはかなり便利。
あれを他の言語でもできないものか。

0518デフォルトの名無しさん

NGNG

>>517
そんな貴方にVisualAge for Java

0519デフォルトの名無しさん

NGNG

mozillaの場合は、そこそこ便利で出来が良くかつ無償でなければ
ならない条件があるから難しいのでは

0520デフォルトの名無しさん

NGNG

>>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 やらでも、そこは把握に苦労する部分。な
んかうまい表記方法が発明されると嬉しいんだけど、ねぇ。

0521デフォルトの名無しさん

NGNG

>>520
>OO の真髄は「インターフェースに対してプログラミングする」ことだけど、
ちょっとまて。「インターフェースに対してプログラミングする」なんてCにstatic関数が
出来たときから(きっとそれ以前だろう)いわれてることじゃないか。

これはOOの神髄ではなくプログラミングの神髄だ。

0522デフォルトの名無しさん

NGNG

OOっていうのはこうした方がいい設計、いいプログラム、へのガイドラインじゃないかと。
だからやってることっていうのは実は昔から変わっていないんじゃないか？。
OOがワカラン、OOは糞、というやつは実はOO以前のスタイルでもまともな設計、プログラミングが
できていないんじゃないかと思う。

0523513

NGNG

>>516
それは、Erich,Rich,Ralph,Johnの四人がGangってこと？

0524デフォルトの名無しさん

NGNG

>>521
ADT の進化系が OO と認識してるけど。

C だと

　インスタンスの管理がめんどくさい（明示的に this を渡す必要があり、vtbl も
　自前で初期化しないとダメ）
　継承関係の管理を自分で行う必要がある
　インターフェースの多重継承は事実上無理
　インターフェースを追加した場合に、コンパイラがエラーチェックしてくれない
　（純粋仮想関数の定義し忘れとか）

なのが C++ あたりだと、すっきりかける。

C++ は C に「インターフェースに対してプログラミングするために便利な／必要
な機能」を付け加えた処理系っつーのは、一面としては間違ってないと思うんだ
が、どうよ？

0525デフォルトの名無しさん

NGNG

>>522
> OOっていうのはこうした方がいい設計、いいプログラム、へのガイドラインじゃないかと。
その通り、単なる「ガイドライン」に過ぎないのにそれを絶対視する奴が多すぎる

例えばDBのテーブル設計の場合、パフォーマンスを出すために
あえて正規化を崩す場合がある。
構造化プログラミングでも状況によりgotoを使う場合もあるし、
グローバル変数を使う場合もある。

常に「gotoを使わない」「グローバル変数を使わない」奴は素人。
常に「OOを使う」ことしかできない奴は素人

「OOを使えない奴」は素人以前の問題

0526デフォルトの名無しさん

NGNG

>>524
インターフェースへのプログラミング、という捕らえ方は正しいと思う。

ただAlan Kay的なOOの定義に従って考えると、
ADTの延長にOOがあるんじゃなくて、
OOの実装で現状使える技術要素の１つがADTなんだろうな。

つまり、何かを聞けば反応を返すのがオブジェクトであって、
ADTはそれを実装するのに都合がいい概念の１つに過ぎない。
ADT以外にinterfaceを明確にできるソフトウェア構成単位があれば
そっちに移ればいい。

0527デフォルトの名無しさん

NGNG

>>525
UMLを書き上げただけでシステムできると誤解してない？
現実的なソフトウェアはそれだけじゃできないよ。
だけど可能な限り設計段階でUMLで表現しておくことが
無意味になることを意味するわけじゃない。

0528デフォルトの名無しさん

NGNG

多数のボランティアが必要なプロジェクトで UML図を誰がどう作成してメインテナンスするのか
というかそういう作業を好んでやる人はいるのか？

0529デフォルトの名無しさん

NGNG

OOの欠点は、何かにつけ大げさになる点。ただそれだけ。

OO信者の欠点は、それが致命傷になるケースであってもゴリ押しする点。これ激しく迷惑。

0530デフォルトの名無しさん

NGNG

で結論は？と言ってみるテスト。

でも厨房の漏れには両者の喧嘩は意外と勉強になったYO!

みんながんばれ。(･∀･)!!

0531デフォルトの名無しさん

NGNG

>>528
プログラマはプログラムで自己表現するんじゃなくて、
設計レベルで自己主張すべき。じゃないといつまで
たっても職人仕事の域を出ない。
だからUMLは管理するものという発想は間違ってる。

0532デフォルトの名無しさん

NGNG

>プログラマはプログラムで自己表現するんじゃなくて、
>設計レベルで自己主張すべき。じゃないといつまで
>たっても職人仕事の域を出ない。
船頭おおくて船山にのぼる

0533デフォルトの名無しさん

NGNG

プログラマがプログラムで自己主張できなくっちゃ
つまらねえよなあ、おい。

プログラムって楽しいもんじゃねえか。
いくら仕事だからって楽しんじゃいけねえのかい？

そうか、そうだよなあ。
職人が生きにくい世になったんだなあ。ちぇ。

0534デフォルトの名無しさん

NGNG

設計とコーディングをもっとシームレスに考えれ。

0535デフォルトの名無しさん

NGNG

職人仕事でいいじゃん。一流の職人なら。

0536デフォルトの名無しさん

NGNG

>>530
> で結論は？と言ってみるテスト。
結論：
　テストを先に書くこと。（XPマンセー）
　UMLや設計は後からついてきます。

0537デフォルトの名無しさん

NGNG

>>536
XP もストーリー→タスク→テストと
その都度設計してるんだけどね。
設計そのものの成果物を残さないだけで。

0538521

NGNG

>>524
インターフェイスっていうのはものすごい一般的な言葉なわけで､

printf関数を使っているときにはprintfインターフェイスに対して
プログラミングしているといえる。プログラム言語が関数を手に入れたときに
最初のインターフェイスが誕生した。

同じように自作のモジュールでも公開関数に対してだけプログラミングすれば
実装を容易に変更できるようになる。Cがstatic関数を手に入れたときに次世代の
インターフェイスが生まれた。

OOPLはいくつかの関数とデータを硬く結びつける文法を用意してより強力な
インターフェイスが誕生した。

きっとクラスの数が増えてくればそれらをいくつかまとめて次世代のインターフェ
イス概念が生まれるのであろう。

0539デフォルトの名無しさん

NGNG

>>538
> インターフェイスっていうのはものすごい一般的な言葉なわけで､
あの文脈だと「シグネチャが一致するメソッドの集合」と読めるかな。

0540デフォルトの名無しさん

NGNG

>>526
賛同。Smalltalker?

0541526

NGNG

526=Smalltalker

0542デフォルトの名無しさん

NGNG

協調性の無い職人ほど邪魔なモノは無い

0543デフォルトの名無しさん

NGNG

同化を強要するボーグみたいでキモいよ、OO厨。

0544デフォルトの名無しさん

NGNG

業務としてコード書くんだから我慢しる

0545デフォルトの名無しさん

NGNG

>>542
激しく同意
特にOO職人と勘違いしているOO信者は協調性がない邪魔者
COBOLerと同じくらいタチが悪い

0546デフォルトの名無しさん

NGNG

＞勘違いしているＯＯ信者
それって、職人じゃ無いじゃん。

0547デフォルトの名無しさん

NGNG

>>546
職人じゃないんじゃなくて、信心のたりないOO信者ってとこだろ。
OOPLは好きだがそれ以外のものをメンドクセーとか思ってる奴。

そういう奴がXPマンセー！と言ってるのだと思うが間違ってる？
OOSEやRUPじゃカバーできないプロジェクトがあるとか
いいながら、内心そんなところに理由があるんじゃないかと思うんだけど。

0548デフォルトの名無しさん

NGNG

どっちかと言えば実践を中心に考えてるXPの方がマシだと思う。

0549デフォルトの名無しさん

NGNG

>多数のボランティアが必要なプロジェクトで
>UML図を誰がどう作成してメインテナンスするのか
>というかそういう作業を好んでやる人はいるのか？

そうそう、そんなことしてる奴は周りから間違いなく異端視されるし。

0550盛岡電波

NGNG

絶対必要あげ

0551デフォルトの名無しさん

NGNG

JavaSoftの J2EE patternsでわ、
パターン抽出と、ベスト・プラクティスの広報を通じて、
開発者のレベルアップにちっとは貢献してるでしょ。

だから、オープン・ソース・プロジェクトの
ドキュメント整備と同じ位重要な場合もありそう。

Apache Avalon, Struts とか、
フレームワークを前面に押し出したプロジェクトなら、
開発前から UML使ってても、不思議ではないんでわ？
んで、
と同じ

0552デフォルトの名無しさん

NGNG

>>549
> そうそう、そんなことしてる奴は周りから間違いなく異端視されるし。
FreeBSD だと最近の大きなプロジェクトとして SMPng, KSE なんてのがあったが、
あれは paper 出したり、主要なメンバーで集まって設計方針を話し合ってたりした
ぞ。

OO じゃないから UML で図を書いてたわけじゃないけが、いずれにせよ大規模な
システムのコア部分を作る場合には、やっぱり何らかの形で設計を形にして、参
加者に伝達することは必須だと思われ。

0553デフォルトの名無しさん

NGNG

アンチOOよりXP信者の方がウザイ。
アンチは教育してやれば理解するようになるが、
XP信者は永遠にプロセスを理解することは無理だな。

0554デフォルトの名無しさん

NGNG

理解してないと思いたいのですね：)

0555デフォルトの名無しさん

NGNG

大規模プロジェクトをOOでやるのは危険です。
その理由は以下に↓

0556デフォルトの名無しさん

NGNG

なっちありがとう

0557デフォルトの名無しさん

NGNG

http://pc.2ch.net/test/read.cgi/tech/1012484747/

0558なっち怒ってます（○ ´ へ｀ ○）

NGNG

なっち怒ってます（● ´ へ｀ ●）

0559　

NGNG

>>543
激しく同意

0560デフォルトの名無しさん

NGNG

>>553
>アンチは教育してやれば理解するようになるが、
>XP信者は永遠にプロセスを理解することは無理だな。

XPってのはOOを理解した上での原点回帰だと思うが、その口ぶりだと553はOOを理
解せずにXPやってる現場ってのをどこかで見てきたようだな。
非常に希少な例だと思うんで紹介してもらえないか？

0561デフォルトの名無しさん

NGNG

>>560
つーか、XP自体がプロセスを極端に調整した例だということを
理解してないようですな。
XPをちゃんと運用するためにはソフトウェア工学、特に方法論を
教科書憶えただけでなくしっかり身につけている人が必要で、
その上でその極端な例としてのXPを実行するもんだと思うのだが。
型無しと型破りの違いだな。

0562デフォルトの名無しさん

NGNG

XPやってる奴って、ゴシック様式の建築物みたいなOOの方法論に
嫌気がさしてやってるもんだと思ってるけど。オレモナー（藁

0563デフォルトの名無しさん

NGNG

訂正
×XPやってる
○XPに興味もってる

0564561

NGNG

>>562
うん。そういうゴシック様式というか、セレモニー的な部分を
極端に減らしているのがXPだよね。
で、その分、リファクタリングやユニットテストで補なっているわけだし
ストーリーとユースケースも深い関係がある。
上に挙げた用語はどれもソフトウェア工学の用語だし、その背後にある
相互関係や危険サインや監視の仕方や対処法なんかを理解する必要がある
と思うけど、どうよ？

0565デフォルトの名無しさん

NGNG

>>564
RUP、つーかラショナルが嫌なんだよね。結局プロセス実行するには
ツール買わせるように出来てる。この辺りの巧妙な手口は正直好かん。

理論としてはヘーゲルの「歴史」を想起させるぐらい立派な
ものを目指してるのかもしれないけどさ。その裏にある動機が
いやらしい形で見えてくるのがｷｼｮｲ。

0566561

NGNG

>>565
あ、それは俺もある (藁
なんだよ、そのRはよぉ、って。

その一方で、プロセスってのはそのまま適用するものじゃなくて
各プロジェクト毎に改変して応用すべきものだとも思うんだよね。
だから、あんまり1つの方法論にベッタリなツールも嫌いだったりする。
俺にとってはツールに期待するのはUMLであってRUPじゃないんだな。

0567デフォルトの名無しさん

NGNG

>>567
一応教科書読む限りじゃ、プロセスはプロジェクトにテンプレートを
与えるものっていう位置付けになっていて、ツールはプロジェクト
じゃなくてプロセスに対応するものという位置付けになってる。
だからツールはかなりの汎用性を持たせてあるんじゃないかな？

おれはRationalナントカなんて触ったこともみたこともないから
詳しいことはしらないｗ。教科書読んだだけのヘタレだから。
ただ一つ言えるのは、RUPなんていったところで彼らが仕様を無償で
公開してるのは方法論のモデリングに関する成果だけで、実務を
遂行するにあたり必要となるツールに関してはおそらく特許で
ガチガチになっているものと思われます。危険です。
彼らの言うプロセスとはイコール、ツールのことですｗ。

この濡れ衣を脱がせる人、なんか書き込んでください。

0568デフォルトの名無しさん

NGNG

上の567は>>566の間違い

0569デフォルトの名無しさん

NGNG

http://acd.nabunken.go.jp/Nabunken-Doc/chousa/international/Angkor/sites/PreRup/PreRup.html

0570デフォルトの名無しさん

NGNG

>>567
＞ツール
というか、RUP にすら満足に使えない

0571デフォルトの名無しさん

NGNG

必要かどうかは別として

結果として出したプログラムのレベルは
OOできない人＝アンチ<<<<<<<<<<<<<<<<<OOできる人
だと思うけど、どう？

0572デフォルトの名無しさん

NGNG

>>571　そのプログラムのレベルって何で測るの？

0573デフォルトの名無しさん

NGNG

>>572
if文のネストの深さで

0574デフォルトの名無しさん

NGNG

>>571
必要かどうかは別として

「レベル」とか「○○>>>××」とか言ってる奴は
厨房だとだと思うけど、どう？

0575デフォルトの名無しさん

NGNG

>>574
プログラムには、実装・設計とも良し悪しはある。みんな平等ということはない。

ただ、

　プログラマをOO派・非OO派に色分けしたときに、このスレで出てきたプログラ
　ムでそれぞれの能力を測る
　
ことには全く意味がないし、そんなことをして喜んでるのは厨房だと思う。

0576デフォルトの名無しさん

NGNG

>>573　つまり　OOできる人ほどネストは深いと？

0577grrrrrrrrr....

NGNG

>>576 ソフトウェア・メトリクスの勉強汁

0578

NGNG

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

0579デフォルトの名無しさん

NGNG

おとなしく学歴板にかえんな

0580デフォルトの名無しさん

NGNG

非OOで書いたレベルの高いプログラムキボーン

0581　

NGNG

>>577
cccc以外の使いやすいメトリクスツールを紹介してくれ。

0582デフォルトの名無しさん

NGNG

BSD

0583デフォルトの名無しさん

NGNG

>>581
http://osb.sra.co.jp/Smalltalk/ObjectOrrery/Japanese/manual/index.htm

>>エセsmalltalker
http://www.sra.co.jp/people/aoki/Jun/Main.htm

0584デフォルトの名無しさん

NGNG

>>582
どのバージョンの？

4.4BSD 以降だと VM の設計なんかは、言語こそ C だがかなり OO っぽい
と思うぞ。newconfig とか new-bus も然り。

0585デフォルトの名無しさん

NGNG

>>580
ＰＣ８８板アルフォス（by森田）

0586デフォルトの名無しさん

NGNG

>>583
エセSmalltalkerって誰のことだ？
春になってきたのかなぁ…

0587デフォルトの名無しさん

NGNG

>>567
ラショナル製品を買えないほどの貧乏会社で
働いてるんだね。プ

0588デフォルトの名無しさん

NGNG

あんなの予算おりるか？
まあ、予算取ることはできても活用できなそうで乗り気にならない。

0589デフォルトの名無しさん

NGNG

>>588
必要経費

0590デフォルトの名無しさん

NGNG

>>589

不必要経費の間違いじゃネーノ？
買ったはいいが死蔵してる会社って結構多いぞ。

0591デフォルトの名無しさん

NGNG

俺の私的メモ

ラショナル製品を導入後、継続して活用していますか?
・はい 5%
・いいえ 95%

0592デフォルトの名無しさん

NGNG

つーかさ。
OOはプログラマなら誰でもかかる一種の麻疹みたいなもんなんだよ。
命を落とすほどの病気じゃないから、そう、目くじら立てるなって。

0593デフォルトの名無しさん

NGNG

>>592

そう思わないと精神の安定が保てないCOBOLERさんですね。
構造化を1週間分処方しておきますので、薬局で受け取ってから帰宅して下さい。
理解できるまで来なくて結構です。

0594デフォルトの名無しさん

NGNG

>>590
>買ったはいいが死蔵してる会社って結構多いぞ。

うちもだ (w

Rationalのツールを買って死蔵している会社の人は正直に手を挙げよう。
あ、ちゃんと使いこなしている人の数も知りたいな。

0595デフォルトの名無しさん

NGNG

高くて買えないが統一プロセスの好きなやつ。
ラショナル製品を一通りそろえてもらって、
セミナーまで受けたのにさっぱりなやつ。

どっちが真実を現してる？

0596デフォルトの名無しさん

NGNG

ＯＯ理解出来ないし難しいし挫折したから、役に立たないものだと
思い込みたいんだよね。
わかるよその気持ち。

あまりわかってないうちに、ＯＯに対して役に立たないと
いう早計な判断を下してしまった人も多そうだね。

0597デフォルトの名無しさん

NGNG

>>596
ラショナル製品使いこなしてる人発見！

単純に工数が減ったのかどうかと顧客の満足度が知りたい。

0598デフォルトの名無しさん

NGNG

設計なんて出来やしないのにRational Rose買いたがってる上司に
IIOSSくれて止めたよ（それだって猫に小判状態）。
そんな金あったら俺の給料あげてくれ。

0599デフォルトの名無しさん

NGNG

IIOSSはJavaに特化されて手むかつく。

0600デフォルトの名無しさん

NGNG

RUPやOOを信用してない人がこんなにいるのか、ってあるいみ
カルチャーショックですね。もしかしていきなり大きなこと
やろうとして失敗してしまってるんでしょうか。身近な簡単な
ことの積み重ねで、いいのに。日本人の得意なカイゼンでぜんぜん
おっけーですよ。

ワインバーグも、新しいことは必ず失敗するので、新しいことは
一つだけにとどめておくように薦めてますね。それに新しいやり方
というのは、3回目ぐらいにようやく成果がでるくらいの気持ちで
いるのがいいのでは。

あと結局道具じゃないっすよ。人ですね。
UMLだってコミュニケーションの道具に
すぎないんだから。状況に応じて、相手にあわせて、工夫はしないと。

今、3人のチームで仕事してますが、
RoseもVisioもつかってなくて、無印良品のらくがきちょうとホワイトボードが
一番役にたってる。

0601デフォルトの名無しさん

NGNG

>>600
反復は実践してる？

0602デフォルトの名無しさん

NGNG

>>601
仕事によります。仕様が綺麗に固まってる、固められるものなら長めです。
そうでないときは、2週間ぐらいを1iterationにすることが多いです。
今はお客さんが経費削減、経済状況の変化等々で、どうしても固まらないことが
おおく、1week単位に近くなることもあります。

今は小人数なので、あまり、重いことはしてません。XPに近いです。ペアプロも
してますし。

0603デフォルトの名無しさん

NGNG

それはあんまりすごくないよ。

0604デフォルトの名無しさん

NGNG

>>603
それより、君のすごい話キボーン

0605590

NGNG

なんか言葉足らずだったみたいで誤解してる人がいるようだけど、俺が590で書い
た「死蔵」ってのはOOに挫折って意味じゃなくて、>>600が書いてるみたいに紙や
ホワイトボードを使ったミーティングで十分こなせるような規模の仕事が大多数で
、Rational製品を使うメリットが無いって事。
日本のソフトウェア受発注構造では厳格に管理されたプロセスよりも、仕様変更に
耐えられる機動力の方が要求されてるんだよな。

0606デフォルトの名無しさん

NGNG

OOPLで工数が減るかは知らないが。
OOPLで非OOなコーディングをすると
工数が増えることだけは実感した26歳の春。

0607デフォルトの名無しさん

NGNG

>>605
というかちゃんと管理できる人間がいない……

0608デフォルトの名無しさん

NGNG

クラス宣言の情報 >>>>> UMLの情報 >>>>> UMLから読み取れる情報
UMLの冗長さ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> クラス宣言冗長さ
（オブジェクト指向はクラスベースだけじゃないが）

0609デフォルトの名無しさん

NGNG

>>608
そりゃ、実装が一番詳細な情報だからな。

ただ木を見て森を見ずとか、実装の詳細に溺れる可能性も高い。

0610デフォルトの名無しさん

NGNG

UMLなんてナニが重要なオブジェクトで、そいつがだれとどうか変わってるか、
そいつを変更するには、誰の了解を得なければいけないかがわかれば十分。

というわけでUMLからコードに落としたり、コードからUMLを生成したりすんのは
バカ。

そんな機能を売りにしてるツールは....
いやもっと、そんなもの買おうとする方が...

0611デフォルトの名無しさん

NGNG

UMLのクラス図ってC++やJavaのキーワード、classとは直接の
関係はないんだよね？

0612デフォルトの名無しさん

NGNG

>>611
少なくともトレーサビリティは大事だと思うが。

0613デフォルトの名無しさん

NGNG

>610
どうい。ツールを売る方は金儲けから製品作ったんだろうが。

コードジェネレータによるコードが冗長で読み難い（←コード書いた人の考えが読み取れないんだよね）
という問題を解決するために、
クラスによる差分プログラミング開発（これがOOPかどうかは別にして）が行われるようになったんだよね。
だから、UMLによるコードジェネレータという考えはなんか外してると思った。

0614デフォルトの名無しさん

NGNG

>>611
どのレベルのクラス図か、による。

分析段階で作ってるクラス図だと、動的分類／多重分類あたりまえなので、
C++ や Java のような静的分類／単一分類前提のクラスには一対一には
対応しない。

0615デフォルトの名無しさん

NGNG

>>614
とりあえず、メモさせて頂きました。
元ネタはどこからですか？

0616デフォルトの名無しさん

NGNG

>>615
UML モデリングのエッセンスとか、アナリシスパターンあたり。

0617デフォルトの名無しさん

NGNG

distill本かanalysis本ですね。分かりました。
あまぞんにちゅもんしまう。

0618デフォルトの名無しさん

NGNG

>614
最終的に実際にクラスになるものとそのメソッドを考えた方が
簡単ということは無いの？
実装上の問題も無いし。

0619617

NGNG

というか同じことどっかで聞いたんだけど、
なに読めばいいのかわすれちったんだよね（ｗ

0620デフォルトの名無しさん

NGNG

>>610,>>613
その手の言い切りが、技術の進歩をおくらせるんだよな。

0621デフォルトの名無しさん

NGNG

>>620
そうかもな。

だがこのみちで飯を食う以上、最終的に金にならないと判断できたものは
それ以上使わなくても良いだろう。
UMLという記述言語は取り入れるがそれを取り巻くツールを使うかどうかは
全然別問題だしな。

0622デフォルトの名無しさん

NGNG

>>618
場合によるな。

経験上、問題領域を素直にモデリングする場合には、動的分類／多重分類を
使った方が楽。どうも、その方が人間が物事を把握するフレームワークに近い
ような気がするんだわ。

じゃあ、常に「分析、設計、実装」レベルでクラス図を三種類作るかというと、そ
うでもない。そもそも図は

　コア部分だけ
　図に書いたほうが理解が深まる部分だけ

書けば十分だから図を書かない場合も多いし、結果的にいきなり設計レベル
図を書いて終わりってこともある。

0623デフォルトの名無しさん

NGNG

>>621
>UMLという記述言語は取り入れるがそれを取り巻くツールを使うかどうかは
>全然別問題だしな。

OMGが推進してるMDAについてはどう思う？

0624デフォルトの名無しさん

NGNG

まだ評価前

0625デフォルトの名無しさん

NGNG

OOは少人数でしか使えん。
大人数でOOプロジェクトをまとめようとすると
宗教と同じで、戒律を作って各PGに守らせるよ
うにしないとだめ。つまり現実的な開発方法と
は言えない。

0626デフォルトの名無しさん

NGNG

そして最初に戻る…

0627デフォルトの名無しさん

NGNG

OOの話題は　シロウトというかクチだけ野郎でも口が出せるからなあ・・・

バランス木とかコルーチンとか実装の話になると黙るのに、そこだけ元気なもんで会議が踊る

0628デフォルトの名無しさん

NGNG

>> バランス木とかコルーチンとか実装の話
それ自体OOと関係があるのか？

0629　

NGNG

「ソフトウェア部品の再利用は夢なのか？」
@ITがついにこんなリンクタイトルで記事掲載
http://www.atmarkit.co.jp/fjava/devs/interview01/interview01.html

0630デフォルトの名無しさん

NGNG

>>629
このおっさんが言ってるの再利用部品とはコンポーネントのことだね。

0631デフォルトの名無しさん

NGNG

>>628
バランス木　・　オブジェクトをどう管理するのか
コルーチン　・　フィルターのようなオブジェクトをどう実装するか　

0632デフォルトの名無しさん

NGNG

つーかさ、OO信者は早く得意のOOを駆使してOS作れや
無理だろうけどな（ｗ

0633デフォルトの名無しさん

NGNG

Windowsがそうですが？

0634　

NGNG

まとめ
１）オブジェクト指向は失敗した。
　　今後は以下ＯＯが失敗した以下の２点を目標にすべきである。

２）生産性の向上
　　この点について、Java等の一連のＯＯＰＬが失敗した最大の原因は
　　ユーザーライブラリを無視し、セミナー屋やマスコミを動員して
　　すでにあるソフトウエア資産の破棄に無理やり誘導したことである。

　　教訓として、ソフトウエア資産の破棄を迫るような言語は今後は
　　一種の詐欺と見なして良い。

２）再利用性
　　「まず言語構造・設計構造ありき」などという言語・構造原理主義を捨てて
　　再利用性を目標にすべきである。

0635デフォルトの名無しさん

NGNG

>>633
WindowsはVisualBasicで作られてます。

0636

NGNG

>>634
コンポーネントってこと？

0637　

NGNG

>>636
社内で使える物を作ろうとするとコスト高になるから違うな。

0638デフォルトの名無しさん

NGNG

OOPL導入するときって、損益分岐点の見積もりがむつかしー。

0639デフォルトの名無しさん

NGNG

どういう理由で？

0640　

NGNG

難しくないよ。
導入しても生産性上がらないから、導入コスト分だけ無駄。
従って損益分岐点は存在しない。

0641638

NGNG

>>640
あ…
納得。

0642デフォルトの名無しさん

NGNG

OOPL使ってるからといってOOしてるわけでもないという理屈なら
OOPL入れたからといって OO しなければならない訳ではない

OOPLは好きだし使うけど OO嫌いな人もいるだろし

0643638

NGNG

たとえば、

OOPL使いはじめたとして、ある程度わかってるヤツが解ってる範囲で使うのは、いい。
わかんないヤツが、従来の方法のまま、使うのもいい。
困るのは、解ってないのに、自分はもう極めたような勘違いして暴走しるようなやつ。
そういうやつの足の引っ張り力って、結構強いから、損益分岐点の遠のいていく速度が加速するんだよね。

俺に、そういうやつを説き伏せる力が無いのがいけないんだろうけど、
でも、こういうヤツに限って、周囲からはスゴイって評判だったりするんだ、往々にして。

グチになちたな、マ板逝こう…

0644デフォルトの名無しさん

NGNG

コルーチンの話が出てるけど、OOの一つの課題と思ってる事があるんだ。
つまり、メッセージを送るって事は、送ると受けるという２つのオブジェクトがあるという事

例えば、データを入力する機能を持ったオブジェクトの実装では
A)InputDataというメソッドを呼び出して貰う
B)データが出来る都度　PutDataを呼び出す(最終的に外部のオブジェクトが呼ばれる)
という大きく分けて２つの方式があるけど、この２つの方式は切り替えられない。
もちろん、最初から設計してあれば、同期スレッドを使う事で可能だけど、スレッド切替
は比較的重い処理だから現実には選択肢にのぼらない。

当然使う方は Aの方式が楽で作る方はBの方式が楽。圧縮とかの処理だと圧倒的にAが
難しくなるから、みなついBの方式で実装したがる。

あ長文になりそうだから、結論だけ書くと、
　つまりは、メッセージを送る方式の実装と　メッセージを受ける方式の実装が継承により
切替られるような仕掛けが OOPLに必要ではないかという事

0645デフォルトの名無しさん

NGNG

長文きぼー

0646デフォルトの名無しさん

NGNG

>スレッド切替は比較的重い処理だから現実には選択肢にのぼらない。
んなこたない
スレッド使った場合のオーバーヘッドの
全処理に占める割合をどのくらいに見積もってるんだ？

0647644

NGNG

>>645 と言われて　喜んで書いたら叩かれそう

>>646　たとえばストリームのような1バイト単位のデータ送受で単なる
　　コルーチン切替ならメモリアクセスに隠れてしまう程度の負荷
　　だけど同期スレッドだとそうはいかない。

0648デフォルトの名無しさん

NGNG

1バイト単位って・・・
お前fiber使ってみたいだけちゃうんかと(略
1kバッファリングすればオーバーヘッド1024分の1に減るだろ。
リアルタイム圧縮の話をしてるのか？

0649　

NGNG

>>646
切り替えは重い。これ常識。

0650デフォルトの名無しさん

NGNG

>>649
プロセッサや OS アーキテクチャにもよるけどな。

0651644

NGNG

>>648
　そんな・・・・１KByte単位にバッファリングするなら　途中にFIFOオブジェクト経由して
　やればスレッドも不要、だいいちバッファリング出来るような処理なら >>644　分類A
　に書き換えるのもそんな手間じゃないよ

0652デフォルトの名無しさん

NGNG

ちょと思いつきで書くのでつっこまれるだろーが

CORBA使ったやつとかだとOO使った大規模ってことにはならないかな？
にたよーなのでOSってわけではないがGNOMEとか

0653デフォルトの名無しさん

NGNG

>だけど同期スレッドだとそうはいかない。
話がめちゃくちゃ・・・・

0654デフォルトの名無しさん

NGNG

>>644　さん　　それで今はどうやってるの？

たとえば Bタイプで作った後で Aタイプに直さなければならない場合に

0655644

NGNG

>>654
　色々かな。

　デバッグが終ったソースで弄るのがメンドクサイ時はアセンブラソース吐かせて、
　スタックフレーム弄ってコルーチンにしてる。
　　つまりクラス内にスタック用のエリアを取っておいて、BP/SPをそっちに切替えておく
　で、PutDataとかのメソッド内で　これをもう一度切替えるというか交換するようにする
　でも、API呼び出しがメソッド内であるとダメね

未デバックだとそんなこと毎回やってられないから　なんとか書き換えるけど

0656デフォルトの名無しさん

NGNG

再利用ねー。
再利用なら昔からしてるよ。ライブラリとかいう形でね。
あとはパターンだね。考え方、テクニックの再利用。
ソースコードの再利用は考えないほうがヨシ
XPとかの本でも、そう言ってるし。

0657デフォルトの名無しさん

NGNG

>>644
http://www.eiffel.com/doc/manuals/technology/concurrency/CONCURRENCY.html

0658デフォルトの名無しさん

NGNG

マイクロソフトはOOで再利用できんかったから
新しいOSリリースするたびに一から作り直してたんじゃないのか？

0659デフォルトの名無しさん

NGNG

>>658
> 新しいOSリリースするたびに一から作り直してたんじゃないのか？
Windows NT 3.x, NT 4.x, 2000, XP と全部スクラッチから書いたっつーことは
あるまい。

0660デフォルトの名無しさん

NGNG

OSは基本的なデータ構造はあんまり変らないから
フルスクラッチなんてことはあるわけない。

0661デフォルトの名無しさん

NGNG

.NET周りはフルスクラッチだろうけどね

0662デフォルトの名無しさん

NGNG

JVMを流用してんじゃないの？

0663デフォルトの名無しさん

NGNG

だとするとベンチマークは激速だな(藁

0664　

NGNG

オブジェクト指向が登場するまで、プログラマーは再利用と言う事を知らず、
プログラムを組むたびに１から作りなおしていたのです。
オブジェクト指向の登場で初めてプログラムの部品化、再利用が可能となりました。

0665デフォルトの名無しさん

NGNG

>>664 そんな夢を見たんですね？

0666664の続き

NGNG

プログラマーをオブジェクト指向に移行させようとすると大抵の場合
素直に受け入れてくれません。
多くのプログラマーは具体例で示しても
「そういう事は今の言語でもできる」などと躊躇して技術を学ぶ姿勢を
見せません。
何故こういう事態になるのでしょうか？
それは旧来タイプのプログラマーは職人気質の人が多く、
ソフトウエアの生産性・再利用には無関心だからです。
オブジェクト指向はやる気のある人間の居る会社でしか受け入れられないという
壁に突き当たっています。
日本のソフトウエア産業の振興の為にもこうした壁を取り払わなければ
なりません。

てな事をＯＯ初期のセミナー屋は言っていた。
詐欺だつうの。

0667デフォルトの名無しさん

NGNG

フレームワークを利用する事を再利用と呼んでないか？
それなら clibを利用する事も再利用だぞ

0668　

NGNG

>>667
再利用で生産性上がってないの。
ＦＷは商売になってないし。

0669デフォルトの名無しさん

NGNG

>668
思いっきりなってんだろ
FW自体が無料と商売になってないはまったく別だぞ

0670デフォルトの名無しさん

NGNG

>>666
本当の理由
1.既にシステムを作る方法を一つ手に入れていて、それを使えば
困らないのに、今更新しいものを覚えるのが面倒くさいから。
2.胡散臭いから

1はともかくとして、2は、今まで実務の実績も経験もないくせに
偉そうにOOを語っていた詐欺師紛いのエバンジェリストなヤツラ
の責任だよな。金だけ湯水の如く請求するくせに、コストパフォー
マンス悪すぎなヤツラ。さらに、成果が出ないのを客の能力の
せいにするアフォ。そんなのばっかり。

0671　

NGNG

引っかかるのはあの程度の嘘が見ぬけないアフォばかり。

0672デフォルトの名無しさん

NGNG

アセンブラは大変というけど　アセンブラもマクロを使ってライブラリをしっかり整備してれば
今の高級言語並の生産性はあった。　ただし熟練者ご用達って事。

0673デフォルトの名無しさん

NGNG

ポータビリチーはどうすんだ?

0674デフォルトの名無しさん

NGNG

>>873 ホントだよね　クラスライブラリに依存してるOOPLでどうするんだろ

0675デフォルトの名無しさん

NGNG

ﾌﾟｯ

0676デフォルトの名無しさん

NGNG

>>674
煽りにしても頭悪すぎ。

0677デフォルトの名無しさん

NGNG

>>675-676

歩調乱すなよ！
もうちょっと我慢したらもっと大物が釣れたのにぃ。

0678デフォルトの名無しさん

NGNG

>>672
>今の高級言語並の生産性はあった。
ネタ？

0679デフォルトの名無しさん

NGNG

>>672
ライブラリをしっかり整備しないといけなくて、
なおかつ熟練者じゃないといけない
って生産性悪いって言わないか。

0680デフォルトの名無しさん

NGNG

アセンブラ下<アセンブラ中<<<java下<=アセンブラ上<<java中<java上
こんな感じといいたいんだろう。
人数の分布は・・・・

0681デフォルトの名無しさん

NGNG

OOの方が型からクラスと、考える対象の粒度が大きくなった分
考えやすくなったのでは？
あとOOならではテクニックあるし。

ライブラリに関しては昔も今も変わらずって感じがする

0682デフォルトの名無しさん

NGNG

>>680
ありえない。
汗でhellowold書いてみればわかる。
汗のみでソフトウェア開発は無理。
特にx86は死ぬ。

0683デフォルトの名無しさん

NGNG

汗でもマクロでごまかせる部分があるからじゃない？
でも上じゃないとねー

0684デフォルトの名無しさん

NGNG

アセンブラでマクロを書いたら高級言語になりました。

0685　

NGNG

そう言えばアセンブラは最初から隠蔽、カプセル化をサポートしてたね。>public

0686デフォルトの名無しさん

NGNG

>>682
x86、asmでソフトウェア開発してます。但しwin32 + masm。
Cで書くのと殆ど差は無いです。

0687デフォルトの名無しさん

NGNG

>>682
BIOS に文字列へのポインタ渡すだけだよ？

0688デフォルトの名無しさん

NGNG

>>686
それは「私はＣが苦手です」と言っているのと同じ事では？

0689デフォルトの名無しさん

NGNG

>>688
ヒューレットパッカのスタック電卓って知ってる？ 1+1を 1 ent 1 + って入力するやつ
会社の先輩にあれでなければ電卓使えない人がいるよ
Cのa=b+cで書くよりアセンブラで考えた方が楽な人もいるって考えたらいいんじゃない？

アセンブラなら　上で出てる　メインーサブルーチン関係に縛られない書き方も自由だしね

0690686

NGNG

>>688
どれ位で苦手って言うのか知らないけど、win32プログラムは
基本的にAPI叩くだけだから言語は何でもあまり関係無いのでは。
特にmasmはあまりにマクロが強力で、Cで書くのと差は殆ど感じないよ。

まあC++は苦手だけどね。

0691デフォルトの名無しさん

NGNG

>689
私もその一人、逆ポーランドというの。forthなんて言語も同じね。
実は慣れると、(1+2)*(3+4)みたいな演算が、読んだとおりに入れればいいのよ（１に２足して3に４足したものをかける-> 1 ent 2 + 3 ent 4 + *）。実に楽。

「アセンブラで考えたほうが楽」とは別の話。あなたがHPの電卓の背景にある体系を知らないだけ。

>688
そもそもCは高級アセンブラっていうぐらいだから、基本的には素養は同じ。
アセンブラも高級言語化してるしね。逆にアセンブラもかけないCプログラマのほうが問題じゃないの。
ただ、Intel系の場合、レジスタの個性を知る必要があるので、その意味では大きく違うが。

0692デフォルトの名無しさん

NGNG

スレ違いっぽいけど、どっかのホームページで見つけてきたもののコピペ。

「プログラミング言語でみる性格判断」

* C

他人のプログラムは決して信じない。ライブラリは自分でつくるものだと思っている。

* C++

自己主張がなく、まわりに流されやすい。

* Java

俗物。熱しやすく、冷めやすい。

* BASIC

間違った基礎教育を受けた。もうやり直しがきかない。

* Perl

おたく。変態。奇才。

* AWK

詩人。夢想化。複雑な仕事には向かない。

* SmallTalk

理想主義者。現実を認めようとせず、箱庭に楽しみを求める。

* Prolog

論理主義者。哲学者。地に足がついていない。

* LISP

変人。協調性がなく、常に自分が正しいと思っている。

* COBOL

がんこで融通がきかない事務屋。すぐ昔話をする。時代に取り残されていることに気がついているが、自分ではどうすることもできない。

* FORTRAN

実験派の研究者。数学的・物理的な美しさは求めるが、プログラミングの美しさは求めない。

* FORTH

人間的な美しさよりも、機械的な美しさを求める。

0693デフォルトの名無しさん

NGNG

>>692
CもC++もJavaもPerlもAwkもPrologも使う漏れって・・・

0694デフォルトの名無しさん

NGNG

* C＃　　よらば大樹の陰
* Delphi 独立独歩

0695デフォルトの名無しさん

NGNG

>>693
他人のプログラムは決して信じずまわりに流されやすい俗物。おたく、変態で地に足がついていない。

0696デフォルトの名無しさん

NGNG

>>693
他人のプログラムは決して信じず、まわりに流されやすい俗物。
複雑な仕事には向かず、おたく、変態で地に足がついていない。

awkが入ってなかったヨ。

0697デフォルトの名無しさん

NGNG

というか　全てのコンパイラは　アセンブラの高級マクロだ

0698　

NGNG

Ｃ＃　一発狙いの詐欺師だが、時代を読む能がない。

0699デフォルトの名無しさん

NGNG

* DQN　C#を「Ｃ＃」と全角英数で書いてしまう。

0700デフォルトの名無しさん

NGNG

＞* BASIC
＞
＞間違った基礎教育を受けた。もうやり直しがきかない。

これは性格診断か？（ｗ

0701デフォルトの名無しさん

NGNG

* 妄想君　どうでも良い事を既成のルールだと主張してしまう。

0702デフォルトの名無しさん

NGNG

* 顔が真っ赤なDQN　「ＤＱＮ」と全角で書いて欲しかったらしい。

0703デフォルトの名無しさん

NGNG

>>692-702
asmが無いYO!

0704デフォルトの名無しさん

NGNG

>>692
ここがマ板とム板に別れた頃にそんなスレッドあったよ。

0705デフォルトの名無しさん

NGNG

asm
すべてを把握しないと気がすまない超管理主義者。付き合う人間は一苦労。

0706デフォルトの名無しさん

NGNG

>>705
俺アセンブラ使いだけどOO的設計管理が面倒だから
行き当たりばったりで思いついたところからかけるアセンブラが好き

0707デフォルトの名無しさん

NGNG

>>706
>行き当たりばったりで思いついたところからかける

アセンブラなら許されるってもんじゃないと思うぞ。
OOPLだって行き当たりばったりにクラスを書くことは出来る。

0708デフォルトの名無しさん

NGNG

行き当たりばったりプログラミングといえばXPだな。

0709デフォルトの名無しさん

NGNG

その分テストファーストを徹底しますが、何か？

0710デフォルトの名無しさん

NGNG

テストファーストを盾に行き当たりばったりを正当化されちゃったあ

0711デフォルトの名無しさん

NGNG

リファクタリングも当然やりますが、何か？

0712デフォルトの名無しさん

NGNG

テストファースト・リファクタリングを盾に行き当たりばったりを正当化されちゃったあ

0713デフォルトの名無しさん

NGNG

過不足の無いプログラムが出来上がりますが、何か？

0714デフォルトの名無しさん

NGNG

糞仕様でサッパリ使えないオナニー丸出しの
るーちん・くらす・こんぽーねんと
がでてきたあ

0715デフォルトの名無しさん

NGNG

過不足の無いプログラムを盾に行き当たりばったりを正当化されちゃったあ…　あら？？

0716デフォルトの名無しさん

NGNG

>>714
方法論ばっかやってる連中にありがちだねえ。
俺も一度見たことあるけど、全部捨てさせた。

0717デフォルトの名無しさん

NGNG

>>715
藁

0718デフォルトの名無しさん

NGNG

プロが一人でやったいきあがりばったりは　なかなかバカに出来ませんて

最悪なのは複数人とか　クロス開発でテスト環境がしっかりしてないとかで
　「この部分をブラックボックスとして」　
いきあたりばったりでやった場合だね。

0719デフォルトの名無しさん

NGNG

二人で作業してくれとプログラム依頼されて、
一人がチンタラとクラス設計してるうちに俺がコーディング
始めて、結局おれがクラス設計が終わってないうちに
100％コーディングを済ませたことがある。

0720デフォルトの名無しさん

NGNG

>>719

相方は719が作ったコードのクラス設計を理解した？

0721デフォルトの名無しさん

NGNG

>>720
漏れのはクラスじゃない。
数千行程度のプログラムならサクサク書いたほうが
早いってことよ。

0722デフォルトの名無しさん

NGNG

714の心配が現実のものになったわけか

0723デフォルトの名無しさん

NGNG

>>721

今はそれで良くても仕様変更があったら719しかそのコードいじれなくなるよ。
そんなにサクサク作れるスキルがあるならペアプロとまでは言わないけど、相方に
設計を説明しながら作ればよかったのに。

0724デフォルトの名無しさん

NGNG

>>721みたいなのは、ちょっとした使い捨てのツールを作らすのに、社内に１人くらい
いると便利。けど、よそ様にはお見せ出来ない。
作ってる暇があったら、先に仕様書書けｺﾞﾙｧ。

0725デフォルトの名無しさん

NGNG

>>723　そんなもん仕様変更があったらまたサクサク作ればいいだろ？
　　俺はこれ作ればそれで終わり。
　　管理まで頼まれてねえや

0726デフォルトの名無しさん

NGNG

>>692
SmallTalkじゃなくてSmalltalkね。

ところでSmalltalkもCもJavaもやる俺の場合は一体
俗物なのか理想主義者なのか、はっきりしてくれい。

0727デフォルトの名無しさん

NGNG

>>726
> ところでSmalltalkもCもJavaもやる
ふつー、多言語を使う。

0728デフォルトの名無しさん

NGNG

>>725

ところで、719がサクサクと作ってるのはどんな分野のプログラム？

0729デフォルトの名無しさん

NGNG

SmalltalkとCとLispをやる俺は…
ただのプログラミング言語好きなだけじゃん

0730デフォルトの名無しさん

NGNG

お答えします。
>>726
他人のプログラムは決して信じない俗物。
現実を認めようとせず、箱庭に楽しみを求める。

>>729
他人のプログラムは決して信じない変人。
協調性がなく、箱庭に楽しみを求める。

0731デフォルトの名無しさん

NGNG

んで719が作るプログラムと同じように719自身も使い捨てられると。

0732デフォルトの名無しさん

NGNG

一般的には731に同意。ちょっとましなマネージャなら使わないからね。
ただ、昔ファミコンのころのゲームのプログラムなんかは（今は知らないが）
売っちまったら二度と手入れられないので、中身はめちゃくちゃ。
とにかく納期に間に合わせてパッチ当てまくればよかった。
その時代なら719も生きる場所があったかも。
ちなみに開発はアセンブラ。

0733デフォルトの名無しさん

NGNG

719じゃないけど、
まあ内容にもよるけど数千行ならクラス設計してやるような規模じゃないと思うが？

普通に構造化設計しながらコメント入れてはサクサクコード書いていけば
数千行ならデバックしながら7日もあれば書けるよ。
もちろんOOPL使えば構造化設計としてクラスも作るけどさ

0734デフォルトの名無しさん

NGNG

行数だけでカタってる時点でアウト。

0735デフォルトの名無しさん

NGNG

>>732
今だとプログラムの規模がでかくなっていて、プログラマだけでも最低 3 人、
多いと二桁って世界になってるから、

　中身めちゃくちゃ
　本人も把握してない

だと話にならんよ。

0736デフォルトの名無しさん

NGNG

hello, worldを作るときに設計から始める奴はいないように、
数千行程度の小さなプログラムで設計をするのはどうかと思う。

まぁ新人ならば数千行程度の小さなプログラムでも
設計しといた方がいいと思うけど

0737デフォルトの名無しさん

NGNG

>>733
数千行を仮に 5 千行としておくが、それで 7 日？　内容にもよるが、一日に
間違いのないコードを 700 行きっちり書き連ねていくのは、かなり辛いぞ。

設計を適当にすませるってことは、ある程度の行き戻りは覚悟することに
なるから、実質的に書くコードはもっと増えるし。

> 行数だけでカタってる時点でアウト。
全くその通りなんだが、まぁ、おおざっぱな話をするときには使える指標では
あるよな。（勤務評定で使ってはダメだが）

アプリケーションよりのコードで、同期やらなにやらが込み入ってない部分だ
と、俺は平均して一日 300 行（コメント、空行込み、修正や削減分は差し引い
て）ぐらいだよ。これがスレッドの同期が絡んだり、ハードウェアよりのプログラ
ムだと、さらに少なくなる。

0738デフォルトの名無しさん

NGNG

>>733の「普通に構造化設計しながら」には、あるていど納得できる。
だけど、>>719のやり方とは、大きな差があると思う。

0739デフォルトの名無しさん

NGNG

設計しないでダラダラ書いたら数千行になっちゃったプログラムと、
さらっとでも、しっかりした設計が出来てるから、数千行でコンパクトに
収まったプログラムの差、くらい大きな差かも。

0740733

NGNG

まあ5千行だと7日は厳しいな。
千～９千って事だから√(1000*9999)　でおよそ３千行程度を考えてたよ

俺の場合は1日に、だいたい２千行くらい書いて、3/4捨てるような感じかな
関数・クラス単位にデバックして、動かなかったらさっさと捨てては作り直してるし

0741733

NGNG

あ！　でも俺の場合　1日って労働時間15～6時間だった・・・鬱

0742737

NGNG

>>741
納期直前はともかく、私は基本的に１日８時間しかコードは書かないなぁ。
それ以上は集中力が続かなくて、1 時間よけいにコードを書くと、翌日に
2 時間デバックする羽目になる（ｗ

あまった時間は集中力のいらない書類整理とか、Web やメールを読んで
技術動向をチェック、なんて方に回してます。

> 関数・クラス単位にデバックして、動かなかったらさっさと捨てては作り直してるし
何が問題なのかをつきとめないと、また同じミスを繰り返すぞ。人が書いた
コードを回収しているような場合には

　「腐ったモジュールは丸ごと捨てて、作り直しちまえ」

とすることはあるが、自分が書いたコードではさすがに無いよ。

0743デフォルトの名無しさん

NGNG

>>742
> 私は基本的に１日８時間しかコードは書かないなぁ。
え？デバッグする時間は？
コードを書く時間ってそんなに必要ないでしょう。

プログラムを書く場合に必要な時間って多くの場合、
設計とデバッグ。

0744737

NGNG

>>743
ああ、設計・実装・テスト・デバッグ含めての時間だよ。

最近は実装・テスト・デバッグはスパイラルにやってるから、個々の時間は
記録に残してないです。

0745デフォルトの名無しさん

NGNG

１分で５行しかタイプしないとして 300行　は１時間もあれば
書けるんだから、そんなもんじゃないの？

0746デフォルトの名無しさん

NGNG

まあ色んな方法があるよな　他人の仕事みてたらさ

デバッカで延々トレースしたり悩んでるの見たら　さっさと作り直した方が楽だろうにと思うし
こんだけ動いてるなら作り直すよりデバックした方が速いだろうにと思うし

0747デフォルトの名無しさん

NGNG

あ、おれ、腐ってなくても捨てるコード、いっぱいあるなぁ。
でも、捨てる前に、ちゃんと動作することを確認してるけど。

0748デフォルトの名無しさん

NGNG

抽象度の低い言語＝アセンブラに近いほど　デバックするよりコメント残して再構成する方が効率良くなるな

0749デフォルトの名無しさん

NGNG

>>748
データフローを中心に考えるプログラムならば再構成でなんとかなる。
で、短いプログラムにはデータフロー中心で考えるものが多い。

0750デフォルトの名無しさん

NGNG

>>745
実際にプログラミングして、作業記録をつけてみ。

0751デフォルトの名無しさん

NGNG

>>745
タイピストとプログラマの仕事をごっちゃにしてないか？

0752デフォルトの名無しさん

NGNG

漏れはアセンブラである程度の大きさの関数書くときは、途中で一息ついて
そこまでの条件書くようにしてる。たとえば、
# ここまででax,bxはフリー cxは処理済みのビット数　es:[di-1]までは処理済み
# ds:[si+bx]は全ビット処理済みでないことに注意
とか。
で、書きなおすときは、一息ごと（ｗ　にやるようにしてる。

0753デフォルトの名無しさん

NGNG

> で、書きなおすときは、一息ごと（ｗ　にやるようにしてる。
その感覚は同感。

俺の場合は１日かけて完成できないクラスは
なんか間違っているということで、破棄することにしている。

0754デフォルトの名無しさん

NGNG

俺は、インラインでないアセンブラで書く時はマクロで書くから、マクロ単位に一挙に書いてるな

0755デフォルトの名無しさん

NGNG

>>753
俺は一日にはこだわってないけど、数日かけて１つのクラス実装してると、
たいがい途中で、「あ、これは別のクラスにしなくちゃだな」って思う。
思ってもそのまま実装しちゃうことも、よくあるけど。

0756デフォルトの名無しさん

NGNG

>736
あんたがいなくなった後、メンテするやつにその数千行だけを読ませるの？
なんかドキュメント書くだろ。それって設計書を読ませるんでないの？
規模によって、設計書のレベルは変わるかもしれんが。

0757デフォルトの名無しさん

NGNG

>>756
なんかタイトルと離れた話題だけど、
数千行（３千行程度）のプログラムとしての設計書はソース自身になるように作るのが普通では？
仕様書ならともかく、設計書を別に作らされてるってかわいそうとしか思えないのだが

0758デフォルトの名無しさん

NGNG

「ソースが仕様書」は、作ったやつの一人よがりの場合が多い。
きちんとした書式の設計書でなくていいから、どんな作りになってるのか、メモくらいのこせ。

0759デフォルトの名無しさん

NGNG

>>758
コメントで十分では? :)

0760デフォルトの名無しさん

NGNG

十分だよなあ　いったい何が欲しいの？

0761デフォルトの名無しさん

NGNG

設計の概念の無いやつのコメントなんて、信用できるかよ（ｗ
そんなやつのなら、だらだら書いてたら数千行になっちゃったようなクソコードだろ。

せめて、「どんな作りになってるのか」くらい書いとけ、ソースの先頭でもいいから。
それも必要無いようなのは、コメントもいらん。
一目でクソだとわかるほうが、捨てる判断もしやすいからな。

0762デフォルトの名無しさん

NGNG

>>761　たった３千行なら、どんな作りになってるかくらい見たら判るだろ？
　どんな言語で開発してるんだ？　もしかして素のbasicか？

そんなキミにいいこと教えてやろうアセンブラなら ':' をgrepしろ
pascal　なら procedure / function で grepすればいい
cなら一度コンパイルしてマップファイルを見ればいい

0763デフォルトの名無しさん

NGNG

>>762
数千行程度なら、いわゆる紙の仕様書は要らんと思うなぁ。

構造体とグローバル変数、それに関数の頭に簡単なコメントがつけてあれば
間に合う。それでは間に合わない腐ったコードもあるけど、それはコメントが
あってもやっぱりダメだし（ｗ

0764デフォルトの名無しさん

NGNG

>>761 設計の概念が無いって変な言葉だね

結局　自分のスタイルと違う設計は解読し難いというだけだろ。それは結局勉強不足さ。

0765デフォルトの名無しさん

NGNG

そして新人が育たないっ、と。

0766デフォルトの名無しさん

NGNG

つか、設計についてのコメント残さないと、手離れ悪いから、いや。
参考になるＵＲＬだけ書いとく事もあるけど、勉強しろｺﾞﾙｧって
言うよりも、ソースの先頭に全部書いてあるから読めｺﾞﾙｧ
のほうが、手離れがいい。
勉強不足なやつに、いちいち聞かれるの、うざいし。

0767デフォルトの名無しさん

NGNG

>>765-766
別に新人教育のためにプログラム書くわけじゃないし。

0768.

NGNG

コメントなんて無くてもわかるようなプログラムを書け。

0769デフォルトの名無しさん

NGNG

>>768　でも、ちょっと普通じゃない使い方してたらコメントは欲しいな

0770デフォルトの名無しさん

NGNG

>>761
> 設計の概念の無いやつのコメントなんて、信用できるかよ（ｗ
> そんなやつのなら、だらだら書いてたら数千行になっちゃったようなクソコードだろ。
設計書を書かない奴と設計書を書けない奴を混同する奴の方が信用できない。
常に設計書を書かなければ気が済まない強迫観念をもったキチガイの方が信用できない。

設計書なんてエレベータみたいなもの。
　３階建ての民家にあるのは馬鹿
　５階建てくらいのマンションにはあれば便利だが、無くとも何とかなる。
２０階建て以上もある高層建築にないのも馬鹿

3000行ほどの小さなプログラムも組んだことのない
新人君 or 学生君ならば設計しといたほうがいいと忠告しておく。

0771デフォルトの名無しさん

NGNG

設計書書けなんて言ってないんだけどなぁ。
どんな作りになってるかのメモくらい残せよって言ってるんだが。
物作りするとき、走り書きくらいするだろ。
それがあとでコード読む手がかりになるなら、残さない理由が知りたい。

あ、もしかして、３０００行程度のプログラムが脳内設計で書ける自慢？
ならしょうがないな。
おれがわるかったよ。

0772デフォルトの名無しさん

NGNG

>>771
行数で語るから、話が混乱するんだと思うが。

べつに 1 万行でも単純なプログラムなら要らんし、百行でも複雑な
アルゴリズムを使ってるなら参考文献なり具体的な説明なりを残さ
ないと、後で自分が困る。

それだけだろ？

0773デフォルトの名無しさん

NGNG

たとえば円を描くルーチンがあったとして、円を描くアルゴリズムまで説明を書くか？

0774デフォルトの名無しさん

NGNG

3000行の円を描くルーチンなら、説明いるかも（ｗ

0775デフォルトの名無しさん

NGNG

>>773
Win32 あたりで既存の API を呼び出すだけなら書かない。

そうではなく、整数中点円スキャン変換アルゴリズムを自前で実装してる
なら、関数の解説（これは引数で指定された点を中心とする半径 n の円
を描く、云々）と、アルゴリズムに関する参考文献か解説を書いておく。

0776デフォルトの名無しさん

NGNG

>>770-771
記憶力が良いか頭がイーかたなんでしょう。
私は1月前に書いた自分のコードが
コメント無しでは読めません。

0777デフォルトの名無しさん

NGNG

上の方にﾄﾞｷｭｿな奴がいると、やれ「全ての関数について」関数仕様書を
書けだの、その関数仕様書には「処理概要」とかいって、ソース見ればわかる
制御構造とか、下手すりゃフロチャートまで書けとか、そのくせ関数名は
命名規則で8文字以内とか、そんな経験があると、「ドキュメントなんかいらん!!」
と言いたくなるよな(藁

だけど、ここで出てるのは、そういう定型的なドキュメントじゃなく、
どこがどうなっているかの概略を説明する簡単な文書だろ?

もちろんどんなプログラムかによるけど、3000行なら、A4 1～2枚くらいは
説明書があったほうがいいと思う。

コメントでいいという意見もあるようだけど、コメントはソースの
「その場所」に関する説明だから、全体を概観する文書は、やっぱ別に要るよ。

0778デフォルトの名無しさん

NGNG

例え3000行程度の小さいプログラムであっても、例えばどこにトイレがあって
どこが居間でどこが台所なのか、台所から今に行くにはどうすればいいのか
という事くらいは、（後でメンテナンスするつもりなら）書いておいたほうが
いいと思われ。

その3000行を、クラスなりなんなりで分割したそれぞれが、ちゃんと「居間」
であったり「トイレ」であったりするなら、それ以上の詳細を説明する文章
までは要らないと思うが。

3000行がmain関数一本と言うアホなプログラムじゃなければ、そういった
メモには価値があると思われ。

0779デフォルトの名無しさん

NGNG

>>776
これって結構本当。
詳細設計がちがちでなければ、書きながら
考えてるし。

0780デフォルトの名無しさん

NGNG

777のいう「概略を説明する簡単な文書」はなんと呼べばいいんでしょう？このまま？
自分は大昔からこれを書くようにしているので、馴染み深いのですが、
他の人はそうでもないようです。

0781デフォルトの名無しさん

NGNG

>>780
設計概要説明書。

0782デフォルトの名無しさん

NGNG

3000行で文書が必要という人は、どの程度の文書を書いてるのか興味あるなぁ。
ソースと一緒に公開してくれる人はいないかな。。。

0783　

NGNG

オブジェクト指向は結局何も超えられなかった。
これに尽きる。
この方向でさらに突つきまわしても何も出てこないだろう。
ＯＯブームを冷たい視線で眺めていた開発者達は今こそ見えてきた
頂上を目指す。

0784デフォルトの名無しさん

NGNG

勉強始めた頃はメモを書いてからコードを書いていた
そのうちコードを書きながらメモを書くようになった
今は、行分割エディタでコメント部にメモを書きながらコードを書く

0785デフォルトの名無しさん

NGNG

> 物作りするとき、走り書きくらいするだろ。
> それがあとでコード読む手がかりになるなら、残さない理由が知りたい。
C言語のプログラムだという前提で言うと
ディレクトリ構成でシステムの構成と階層を示している。
ファイルでモジュールを示している。
ヘッダコメントでそのモジュールの役割を示している。
includeで各モジュール間の依存関係を示している。
関数名で機能を示している。
ややこしい場所にはコメントを入れる

他に何が必要？GNUではこれで数万行を超えるプログラムが
何の問題もなく作られている。

もちろん、大規模なプロジェクトの場合、ドキュメントが一切ないのは
太平洋を横断するのに地図を持たずに航海するのと同じくらい無謀

だが、近所を散歩するのに地図を持って散歩する馬鹿はいまい

0786デフォルトの名無しさん

NGNG

(´-｀).。oＯ(そんなに必死に自慢しなくても…)

0787デフォルトの名無しさん

NGNG

(´-｀).。oＯ(>>786はなにをどんな自慢だと思ったんだろう…)

0788デフォルトの名無しさん

NGNG

(´-｀).。oＯ(設計のメモ残す必要無しって自慢してるやつが１名、自作自演ごくろうさま…)

0789デフォルトの名無しさん

NGNG

ついに論理的な発言ができなくなって
感情的な１行煽りしかできなくなった約１名に捧げる

「なんでこのスレにしがみついてるの？」
「なんでこのスレにしがみついてるの？」

0790788

NGNG

(´-｀).。oＯ(まさに、オマエモナー)

0791788

NGNG

俺は設計書が必要だとは一度も言ってないんだがなぁ。
作り始めに簡単なメモくらい書くだろ、それを残さない理由が知りたいって言ってるんだが。
無くても大丈夫とか、ＧＮＵでは大丈夫、は理由にならんだろ。
だから脳内設計で物作りが出来る自慢にしかならないのに…

ま、いいや、「あったほうがいい」っていう意見がいくつか出てるから。

0792789

NGNG

>>788
小さなプログラムの設計のメモって何のために残すの？
読みにくいソースとコメント書いてしまった罰ゲーム？

0793788

NGNG

>>789
時間がたってからソース読む時間を節約するため。
とくに、書いた人以外が読むとき。

0794789

NGNG

>>791
> 無くても大丈夫とか、ＧＮＵでは大丈夫、は理由にならんだろ。
理由は以前に示したが、君の目がフシアナサンのようなのでもう一度書く
　　ディレクトリ構成でシステムの構成と階層を示している。
　　ファイルでモジュールを示している。
　　ヘッダコメントでそのモジュールの役割を示している。
　　includeで各モジュール間の依存関係を示している。
　　関数名で機能を示している。
　　ややこしい場所にはコメントを入れる
これ以上に何の情報が必要？
必要ないから書かないだけ。
必要ないのに存在する情報は必要な情報を隠す働きしかしない。
つまり有害無益

で、こちらからも質問？
作り始めの簡単なメモってどういう情報があるの？
モジュール構成やモジュールの役割以外の役に立つ情報って何？

0795789

NGNG

>>793
> 時間がたってからソース読む時間を節約するため。
> とくに、書いた人以外が読むとき。
で、その「作り始めの簡単なメモ」のメンテナンスは
大幅な修正が発生したら忘れずに修正するんだよね？

その修正コストってソース読む時間を節約するコストよりも
十分に小さいの？特に小さなソースの場合。

２重管理するだけの価値が本当にあるの？

0796788

NGNG

モジュール構成やモジュールの役割が１つにまとまってたら、それはりっぱに設計書として機能するだろ。
けど、それは分散してるより、まとまってたほうが見通しがいい。
3000行程度なら、最初に決めたとおりで作れるだろう。
（当然、規模が大きくなれば、ちゃんとした設計書の必要性が高くなるし、最初の設計のとおりに
　ならない確立も高くなる）
だから、モジュール構成やモジュールの役割の説明として、役に立つ。
（そのメモが実際の作りと違ってたときにどーするよ？っていう反論なら認めたんだがなぁ…）

ディレクトリ構成は、どんなモジュールがあるか、は示していても、モジュール間の依存関係
を必ず示しているとはかぎらない。
ファイルとモジュールも１対１に対応しているとは限らない。
もし、ファイル構成が、プログラムの作りを的確に反映しているのなら、
「モジュールの構成はファイルの構成に対応してる」
って事を書いたメモがあるのと無いのとでは、やはり、コードを読む時（特に読み始め）の効率が違う。

ちゅーことだ。

0797788

NGNG

「大幅な修正」が発生したら、やっぱり、修正についてのメモは、書くんでないか？
したら、最初のメモに追加しとけばいい。

0798788

NGNG

なんか、俺の言ってのは、「考えたことはメモする習慣つけとけ」　ってことみたいだな。

0799789

NGNG

> （そのメモが実際の作りと違ってたときにどーするよ？っていう反論なら認めたんだがなぁ…）
そんなメモは想像もしてなかった。

> モジュール間の依存関係を必ず示しているとはかぎらない。
includeで示している

> ファイルとモジュールも１対１に対応しているとは限らない。
まぁそれは「全て大文字のシンボルはマクロとは限らない」と同じくらい
少ないと思うが。
特にJavaの場合、１ファイル１クラスに対応しているので、

> 「モジュールの構成はファイルの構成に対応してる」
とは、Javaの場合は絶対に必要ないし、
少なくとも俺がCでプログラムを書く場合はモジュール＝ファイル。

0800デフォルトの名無しさん

NGNG

>少なくとも俺がCでプログラムを書く場合はモジュール＝ファイル。

どういう意味？

0801デフォルトの名無しさん

NGNG

>>800
789じゃないけど、

関数を、機能単位で分類したものをモジュールと言うとして、
ひとつのソースファイルに、ちゃんと機能単位で分類したソースを入れると
いうことだろ。

下手な奴はわけのわからん分類をして関数を変なソースに突っ込むが、
俺はちゃんと機能単位で分類してるんだぜ、ってことだと思われ。
あと、staticで情報隠蔽したりとかね。

当たり前のことですわな。

0802777

NGNG

俺もドキュメント書きは嫌いだし、3000行やそこらのプログラムなら、
ヘッダファイル見ながら楽勝で書ける… ってことをこのスレのずっと前の方に
書いたのは俺だ(w

「作り始めに簡単なメモ」も書かないなあ。書いてるときは、ちゃんと
わかってるから、メモなんか不要だよ。

でも、後で読む人のことを考えたら、やっぱり多少のメモは必要だと思う。
3000行だと微妙なとこだけどな。「まずどこから読み始めるか」なんて
情報は必要だよ。

>>795
>２重管理するだけの価値が本当にあるの？

マネージャクラスが書かせたがるような定型の仕様書の類は確かに
2重管理の弊害が大きい。

でも、「どこがどうなっているかの概略を説明する簡単な文書」と俺が
言ってるのは、それに変更が加わるようなときはプログラムを捨てる時だって
ぐらいに大まかなものなので問題なし。

コメントじゃ図がかけないしね。モジュール間の構造とか、データ構造とか、
図の方がわかりやすい事って多いだろ。

0803800

NGNG

>>801
それなら当たり前のことっつーのは良いんだけど、
799は、1ロードモジュール=1ファイルって読めた。
なぜそう読めたのかはわからん。

0804デフォルトの名無しさん

NGNG

>>785
GNU のコードが保守性に優れるかというと、俺は大いに疑問だが。
binutils とか読むと目が腐るぞ。

0805デフォルトの名無しさん

NGNG

「作り始めに簡単なメモ」なんて、仮に書いたとしたって
プログラムが完成する頃には役に立たなくなってるよ。

0806デフォルトの名無しさん

NGNG

コメントとしてファイルの最初に書いたりするだけでは足りないのかな。

0807デフォルトの名無しさん

NGNG

ファイルの最初に書いたコメントは、後から見るプログラマが
・読まない
・更新しない
・律儀なやつが自分の直したとこだけ更新する
とかでなんの役にも立たないカオスの渦になりますが何か？

0808デフォルトの名無しさん

NGNG

やっぱバージョン管理ツールが便利。

0809デフォルトの名無しさん

NGNG

>>740　世の中毎週平均５千行を１年間書きつづけている人もいるようです

http://www.zdnet.co.jp/news/0202/01/e_code.html
昨年，あるオーストラリア人男性がたった1人で.NETのGNU/Linux版のコードを書き始めた。
2001年元日から毎週平均5000行のペースでコードを書いてきた同氏1人の手によるものだ。
しかし，同氏は，クラスライブラリの構築に力を貸してくれるボランティアのプログラマーを探している。

0810デフォルトの名無しさん

NGNG

>>809

同じペースで書いてるとしたらそろそろ45万行ぐらいか。
5000行ずつ書き続けられるかどうかよりも、どうやってテストしてるのかという点
の方が気になる。

0811デフォルトの名無しさん

NGNG

再利用不能なクソコード４５万行か。

0812デフォルトの名無しさん

NGNG

どうしてプログラマーはコードしか書きたがらんのかなー。
仕事だろ。
サンデープログラマーはご自由に。

0813デフォルトの名無しさん

NGNG

>>812
だって、コードしかかきたくないんだもん
動くもんができりゃそれで満足さ

0814デフォルトの名無しさん

NGNG

数千行厨房のおかげで話が㌧㌦な。

0815デフォルトの名無しさん

NGNG

>813
それってあんたサンデーってこと？

0816デフォルトの名無しさん

NGNG

>>810
UnitTestじゃね―の？

0817デフォルトの名無しさん

NGNG

>>807
メモもカオスの渦に陥ると思うのですが？何か？

0818777

NGNG

>>817
だからさあ、プログラムを丸ごと書きなおすような時でなければ、
概略を説明するメモにまで変更が入ることはないだろ?

0819デフォルトの名無しさん

NGNG

OOかぶれの間ではリファクタリングという名目で、
今まで作ったドキュメントごと全部捨てて書き直すことを
推奨しています。

OOそのものとリファクタリングは直接関係はないですが、
ドキュメントごと一から作り直さないといけないことが
苦にならないのなら、シュレッダーを買いに行きましょう。

もちろんメモも、シュレッダーにかけます。
みじん切りです。
機密性が低いドキュメントなら安物のシュレッダーで幅1cm
くらいに切ってやるとよいでしょう。

0820デフォルトの名無しさん

NGNG

どうしてといわれても、下らない文書書くのはSEの仕事じゃなかったのか？
そこまで仕事奪っちゃうと可哀想でさ。

0821デフォルトの名無しさん

NGNG

>>819
…なんだこいつ。

今ここで話題になっている「メモ」は、多少のリファクタリングでは
変更されないものだろうに。

スレの流れに沿ってないし、そもそも文意がさっぱり取れないし。

愚痴か? それとも煽りのつもりか?

ｱﾌｫなのは間違いないところだが…

0822デフォルトの名無しさん

NGNG

仕事でプログラムしてんならドキュメント必須だろ。
アホなやつでも保守できるようにしとかなきゃいけないんだから。
3000行ならドキュメントいらんとかぬかしてる奴は腐ったドキュメントしか見たことないんだろ。

GNUみたいに自分の趣味でプログラムしてんならドキュメントなんていらん。

0823デフォルトの名無しさん

NGNG

>>822 仕事っていうより　労働でプログラミングしてるならでしょ

0824デフォルトの名無しさん

NGNG

>>823
仕事と労働、どうちがうの？

0825デフォルトの名無しさん

NGNG

労働契約でプログラムを生産しても　知的所有権には一切関与出来ない。
それらは全て雇用者のものであり、雇用者はあなたの代わりに誰にでもコードを
触らせる事が出来る。だからドキュメントを書く事も労働として要求される。

普通に仕事としてプログラムを作れば、知的所有権はあなたのものだ。
たとえば著作権は自動的に付与され、他人が勝手に改変する事は出来ない。

0826デフォルトの名無しさん

NGNG

>>825
普通に仕事、ってのがよくわからんのだが・・・
あんたはシェアウェア作家ってこと？

0827デフォルトの名無しさん

NGNG

>>825 形の上で請負契約でも同じようなもんだよ。　成果物は全て発注会社のもの。

個人で営業して仕事するしか今時　著作権が自分のものなんて契約はないよ
まあいつこんな道に迷い込んだのか　年寄りの一人としては責任も感じるけどね

0828デフォルトの名無しさん

NGNG

たしかに企業が占有するなら著作権法でプログラムを保護する必要ないよなあ・・・・単なる愚痴だけど

結局そんなこんなが、魅力的なプログラムを作ろうという動機みたいなのを摘んで、
結局は効率良く成果を上げる事を阻んでるような気がするな

それが結局　オブジェクト指向なんて戦場で必要無しの遠因かもね

0829デフォルトの名無しさん

NGNG

職業プログラマにはプログラミングを追求しようって人が少ないからねぇ。

0830デフォルトの名無しさん

NGNG

>>822
＞GNUみたいに自分の趣味でプログラム
それも立派な仕事だよ。

はたくというのはね　はた（他人）を楽にすることだよってうちのおかあちゃんは教えてくれました。

はたをらくにするとお金は自然についてくるから気にするなとも・・・・これってほんとかなあ

0831デフォルトの名無しさん

NGNG

>>830
こじつけです。

> ドウハタラク動の俗字なり。勞働、自働は勞働、自動なり。
> (大系漢字明解)

0832デフォルトの名無しさん

NGNG

>>831
　それは感じの語源では？
はたらくの語源じゃないでしょ

それを語源という説もあるし
ttp://www.geocities.co.jp/SweetHome-Green/9087/hataraku.html

畑をひらくという説もあるし

0833デフォルトの名無しさん

NGNG

たまにage

0834デフォルトの名無しさん

NGNG

CVS　と　JavaDoc　だと何が不都合？メモも全てJavaDocの流儀で書いているが
何か不満があるのだろうか・・・

0835デフォルトの名無しさん

NGNG

(´-｀).。oＯ(>>834は誰がJavaDocに不満を抱えていると思ったんだろう…)

0836デフォルトの名無しさん

NGNG

(´-｀).。oＯ(身近にいるやつじゃないかな…)

0837デフォルトの名無しさん

NGNG

(´-`).。oO(Javaなんてつかわねーからなあ・・・)

0838デフォルトの名無しさん

NGNG

どうでもいいけど漏れは
BASIC → C → C++
と進むごとにコードが破錠しやすくなった。
今までの中で一番きれいに書けた言語はHSPかな(藁

0839デフォルトの名無しさん

NGNG

>>838

スレ違い。
こっち↓逝け。
http://pc.2ch.net/test/read.cgi/tech/1016715717/l50

0840838

NGNG

後場苦。
でももう逝かない。

0841デフォルトの名無しさん

NGNG

sage

0842デフォルトの名無しさん

NGNG

ファイル分けがやっぱ最強。
クラスは糞。

0843デフォルトの名無しさん

NGNG

世の中の2割の人は抽象的に考える力が劣っているといわれています。
悲しいことに、抽象的な思考が苦手な人にはオブジェクト指向は向きません。

0844デフォルトの名無しさん

NGNG

抽象的なクラスを作られても周りが迷惑です。

0845デフォルトの名無しさん

NGNG

一ファイルがやっぱ最強。
ファイル分けは糞。

0846john ◆0z.4Is5E

NGNG

まだこんな事やってるんだな（ｗ

0847デフォルトの名無しさん

NGNG

あんた誰？

0848デフォルトの名無しさん

NGNG

たぶんジョン=ジョバンニ

0849デフォルトの名無しさん

NGNG

>>847
http://pc.2ch.net/test/read.cgi/tech/1013995470/
ここの悲惨な>>1

0850デフォルトの名無しさん

NGNG

sage

0851デフォルトの名無しさん

NGNG

いつのまにか、新スレ？
http://pc.2ch.net/test/read.cgi/tech/1021468476/

0852デフォルトの名無しさん

NGNG

まだまだ使えるのに何故新スレができているんだろう。

0853デフォルトの名無しさん

NGNG

ここだって、その２が６００くらいの時に立ってるし・・・

0854デフォルトの名無しさん

NGNG

保守あげ

■ このスレッドは過去ログ倉庫に格納されています

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

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