オブジェクト指向は戦場では必要無し その３
■ このスレッドは過去ログ倉庫に格納されています
0001うつつつつ
NGNG引き続きＯＯ厨とアンチＯＯ厨の血で知を笑う戦いきぼ。
その１ http://pc.2ch.net/test/read.cgi/tech/1011997945/
その２ http://pc.2ch.net/test/read.cgi/tech/1013266554/
0310デフォルトの名無しさん
NGNGせめて
(M)マクドナルド
にしてくだちい。
0311305
NGNG0312デフォルトの名無しさん
NGNG２週間まって書き込もう。
0313デフォルトの名無しさん
NGNG0314281
NGNG> そのあたりが、わたしがよく理解できていない部分なんです。
> クラスの実装とは、設計そのものに匹敵するような、構造を規定する部分ですよね。
> 従って、設計が悪いというのは程度問題ではあるのですが、実装が悪いのか設計が検討不足なのか
> わかりづらい部分です。
あくまで個人的な考えだが、OOPLで考えた場合、仕事のレベル的に
クラスなどの設計：プログラマーの仕事
クラスメソッドとかの実装：コーダーの仕事
ぐらいで考えてる。
実際JavaとUML使えばコーディングするのはメソッドの内容とかの
(純粋な意味での)コード実装部だけでしょ？
OO + XP的な考え方だと(要求仕様を満たすという点で)実装が悪いつーのはあり得ない。
要求仕様を満たせるようなソフト設計をしていることがあくまでも前提だと思うんだが｡
「とりあえず動けば」的な実装だとちゃぶ台返しの危険性があるから
そのリスクを回避するためのリファクタリング＆短期リリースなんじゃない？
0315246
NGNG>>248
>「数千から、MAX 1万行ぐらいのモジュール」の外向けのインタフェースと、
>それをどう組み合わせるかについては、さすがに文書化するけどさ。
「外向けのインタフェース」に関しては文書化すると書いている。
モジュールの「仕様」ってのは、外から見える部分のことでしょう。
で、外向けの仕様がちゃんと定義されていれば、ブラックボックス
テストはできる。だから、「仕様書」は書くよ。
でも、「設計書」と言ったら、そのプログラムの内部の設計のドキュメントの
ことを指すでしょう。こんなもんなくても数千行ぐらいヘッダファイル見ながら
書けるのが普通。
OOに限らず、手続き指向でもモジュールの内部的な実装は隠蔽するはずだから、
「仕様書」と「設計書」は明らかに別物でしょ。「設計書」がないとテスト
できないようでは、実装筒抜けのタコモジュールだということ。
# もっとも、ややこしい呼び方をしたときの挙動などが実装に依存してしまう
# ことはないわけではないが (藁
だいたい、元の発言が、
>まじめなお話で数千行（数万って…凄いなぁ）もあるプログラムを設計書も作成しな
>いで、作れるというのは信じ難いです。
こうなんだから、「できるよ」と答えたまで。
保守まで考えると設計書も必要なこともある。そういう場合、たいていは
コーディングの後で書く (^^;
0316246
NGNG「大規模」だと思っているフシがあるのがどうも…
1万なら小規模、数万〜十万ぐらいで中規模、大規模といったら…
もう果て無し、ってとこかなあ。WordやExcelだって、百万単位でしょ。
# だから、アンチMS連中が少々粋がったって、なかなかアレには
# 追いつけない...
で、世間で業務に使われているプログラムには、WordやExcelなんぞとは
比べ物にならないほど巨大なものもあるわけで。もちろん、そのソースには
思いっきりﾄﾞｷｭｿなものも含まれているけど(鬱
「数千」なんて、どう考えたって「ゴミ」。プログラマは現在、そういう世界に
住んでいる。
0317デフォルトの名無しさん
NGNG>>285 オブジェクト指向にこだわらず、
オートマトンとかペトリネットとかやればよいのでは...
状態をオブジェクトにせず、特定のオブジェクトが状態遷移するよーな
モデルを考えると、確かにはまるみたいですね.
アナパタ本解説ページの多重分類と動的分類の説明読んで、
「そこまでやらんとモデリングできないのぉー」と、
ちょっと面倒な感じがしましたです.
0318デフォルトの名無しさん
NGNG>UnitTestはやったことない（ｗ が、 似たようなことならみんな我流でやってるよね？
>Cとかなら#indef DEBUGにテストコード書いたりとか。
>XPはそれの拡大解釈くらいで考えてる。
全然解ってないのね。
XPについて語るならとりあえずxUnit使ってからにしてよ。
0319デフォルトの名無しさん
NGNG＞設計はさておき（ｗ、XPの概念的には実装されたコード(クラス)はUnitTestによって
＞すべてが正しいことが保証される。
要求仕様的に正しいかどうかはともかく、
単体で（そして統合しても）書いた人が意図したように動くことが保証される。
TestCase をきちんと書いてる限り、
どれだけコードを追加、修正しても保証されるのがポイント。
はっきりいってデバグがすげー楽。
0320とあるダメ社員
NGNGわたしの以前の意見を少し訂正します。
>>24の１行目のテキストをオフラインでちょっと見てみました。
ダイアルアップなので、オンラインだとお金が気になってしまいます。
｜>>293
｜293 名前：デフォルトの名無しさん ：02/03/01 21:22
｜とあるダメ社員さんye
｜>>24 の１，２のコードは千行前後あるけど 読める人は苦も無く読んでるでしょ？
｜あのコードはコメント多くとは言えないし、親切なコードでもない。
｜でも、Delphi知らない人でも平気で読んでるわけで、 それはどうしてだと思う？
＜略＞
回答として、私自身のスキルが足りない、と書きました。
｜304 ：293 ：02/03/01 23:14
｜とあるダメ社員さんye
｜ そういう事。 単純にスキル不足つまり経験の差。
｜ 設計図が無ければクラスライブラリも使えないなんて甘えた事じゃホントの経験は身につかないさ
読んでみましたが、まだまだ改造できるほど理解できている訳ではありません。デルファイ自体知らないこともあり、スキルが足りないことを改めて自覚しました。
しかし、２４の目的とする事は比較的明確ですね。読まなければ目的がわからないプログラムではない。
単にBASICを２ｃｈで使われているような言葉に置き換えて動作する言語を作ろう、という事だと思います。
つまり、ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のことであるように思います。
言ってみれば、ユーザが開発者を兼ねるようなケースですね。
プログラムの動作はわかる。しかし、意味がわからないという点が設計書（仕様書でも良いです）の必要性を端的に示す点だと思っています。
それが不要である例を使われてしまうと、議論が迷走してしてしまうように思うのですが、どうでしょうか。
0321デフォルトの名無しさん
NGNG・言語への知識
・クラスライブラリの対象ドメインへの知識
・クラスライブラリそのものへの知識
Java を知って、XML と DOM/SAX を知って、Xerces の使い方を知れば
Xerces が使えると。
>>298
＞このスレでは、「数千〜万程度のプログラムであれば、設計書はなくても作れ
＞る。ソースだけ。」といった趣旨の事が書かれています。
＞従って、ソースしかない、ソースで十分だよという前提の議論だと思っていて
＞それに対して設計書相当のモノが必要なのではないでしょうか？というのが書
＞いている趣旨だったのです。
一人で書くなら10万行でも設計書は要らない（納品に必要なけりゃ）。
何故ならそのプログラムを熟知してるから。
まあ、忘れっぽいので記憶の助けのためにメモ書きくらいはするかもしれん。
10人で作るとして、きちんとした形式の設計書は要らない。
何故なら設計は日々変わるし、結局コードを読まなきゃいけないので。
図や説明を手書きで書いて、質問されたらその都度答える。
形式にこだわった文書は取りこぼしが多い。
0322デフォルトの名無しさん
NGNGことないですか？ここで馬鹿されてるようなアンチOOにサーバー
はくられたとかそんなことあるんでしょうか？
0323デフォルトの名無しさん
NGNG＞それが不要である例を使われてしまうと、議論が迷走してしてしまうように思うのですが、どうでしょうか。
それが必要である例だけ使っても、議論にならなと思うのですが、どうでしょうか？
つか、設計書と仕様書の違いがわかっているように見えないので、なにを議論したいのか不明です。
0324281
NGNG> 全然解ってないのね。
> XPについて語るならとりあえずxUnit使ってからにしてよ。
XP使ってないとそれについて意見したりしちゃいけないの？
概念的にわかりやすいから例として挙げただけだが。
おれの場合は個人で概念だけを導入するくらいまでしかいってないんだが、
実働プロジェクトでXP導入してるとこってまだまだ少ないと思うんだが気のせい？
0325281
NGNG仕様書：ソフトウェアに要求される機能などを定義する(SEの仕事)
設計書：そのソフトウェアを実装するためのソフトウェア設計を文書化したもの(プログラマの仕事)
くらいだから、設計書がなくてもなんとかなるわな。
実際戦場だと設計書が実装のあとになることが多いし（ｗ
0326デフォルトの名無しさん
NGNG辻褄合わせの作業がいかにおおいことか。。
0327293
NGNG＞ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のこと
それはどうかな？
basicという用語を知ってたからコメントやソースを見て判ったのでは？
つまりそれを見る為の知識の一部があったからでしょ？
それとも使われてる再帰下降法から判ったの？
「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・勉強不足だよ。
社会常識や技術の常識は勉強しておくのは普通でしょ？
途中で欲しい出力のイメージさえ判れば入力画面もコードもデータベースも判るという話が出てた
けど、それが普通であって、 分析とか設計とか必要なのがプログラマとしては異常な事だと思うよ
もちろん会社全体としては経験不足の要員でも仕事が出来るよう色んな対策をしなければならな
い訳で、しかし開発要員が全員それじゃダメでしょ？
0328293
NGNG会社として 分析とか設計とかの工程を入れて、ドキュメントを残す事は必要な事だから
会社員なら それは無視してはいけないよ。
会社員の優先順位の一は会社の為に働く事だからね。
0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNGだってOOPLは有効だけど OO つまりOO設計や分析は必要無しが主題でしょ
0331デフォルトの名無しさん
NGNG分析設計工程が打ち合わせ中に終ってしまうんだよね
何年も同じ仕事してたらそういうふうになるのは当然では？
0332305
NGNGシステムの使われ方に関してユーザ（クライアント）よりも詳しくなってれば、「分析
は打ち合わせ中に終わってる」っつーのも有り得る話だな。ただ、普通はそんなこ
とはない。
金融でも医療でも教育でも、専門家はクライアントでこちらは素人、というケース
が圧倒的に多いもの。その場合には相手が物事をどう捉えているのか、クライア
ントがシステムに何を期待しているのか、そういったことを（断続的にで良いけど）
ある程度の時間をかけて話をして、お互いの理解を深める必要がある。それが分
析。
（専門家なしでやってる作業は「分析」ではなくて「分析まがい」でしかないよ）
0333318
NGNG>XP使ってないとそれについて意見したりしちゃいけないの？
>概念的にわかりやすいから例として挙げただけだが。
使ってくれと言ったのは"XPそのもの"じゃなくてxUnitだよ。
混同してる時点で理解度がかなり低いというのは判る？
>概念を導入
って言ってもどうやってイテレーションするの？
リファクタリングするフレームワークが無くちゃ3回目ぐらいのイテレーションで
設計変更に耐えられなくなるよ。
それにね、xUnit自体はXPを前提としなくても十分有効なツールだよ。
0334デフォルトの名無しさん
NGNG「戦場では」を前提にするのは虚しいような気がしてきた（W
だって、戦場になってからOO使うかどうか決めるわけじゃないでしょ。
「戦場にしないためにはオブジェクト指向は必要か？」のほうが
多少は意味がありそうな気がする。
ま、２ｃｈに意味を求めるのも何だかなーだが。
0335281
NGNG理解度が低いのはそのとーりだが
> って言ってもどうやってイテレーションするの？
> リファクタリングするフレームワークが無くちゃ3回目ぐらいのイテレーションで
導入してると言ったのは"XPそのもの"じゃなくてXPの概念だよ。
混同してる時点で理解度がかなり低いというのは判る？
と煽ってみるてすｔ
0336デフォルトの名無しさん
NGNG多分ね、xUnitと #indef DEBUG を同等と考えてるから、XPの概念が
導入できてないって思われてると思う。
0337デフォルトの名無しさん
NGNG> 「戦場にしないためにはオブジェクト指向は必要か？」のほうが
> 多少は意味がありそうな気がする。
多くの戦場ではオブジェクト指向は有効であろう。
でもオブジェクト指向は常に有効ではないし、必要でもない。
0338デフォルトの名無しさん
NGNGスレ違い、XP信者はXPスレにお帰り。
0339デフォルトの名無しさん
NGNG> 「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・
> 勉強不足だよ。
世の中、そんな簡単なプログラムばかりじゃないぞ。
DNA 解析のプログラムなんか、動作は分かるが意味がわからなかったりする
し。（聞いたら分子生物学の厚い本と論文渡された…。数学の話は専門だった
から分かるんだが、生物系の話は進展が早くてついていけん）
0340デフォルトの名無しさん
NGNGこの一文が見えてないのか？
｜ 何年も同じ仕事してたらそういうふうになるのは当然では？
> ある程度の時間をかけて話をして、お互いの理解を深める必要がある。
> それが分析。
何年も同じ仕事をしているならば、お互いの理解が深まっている為、
分析の工程を短縮、または省略しても良いとは考えないのか？
（考えなしでやってる工程管理は「工程管理」ではなくて「工程管理ごっこ」でしかないよ）
0341デフォルトの名無しさん
NGNG確かにそういうのはあるよね。 でもそういうのとは別の話のような気もするし
というか、そういうのいくら文章残したって結局 何やってるかの説明は”論文読め”になるような気もするし
0342デフォルトの名無しさん
NGNG見えてるけど、実際に「分析なし」で済んだ経験がないもの。
何年も同じクライアント相手に仕事をしてても、その間にクライアントが手がける
ビジネスやら環境だって変化していくから、常に勉強の連続だよ。変化がない場
合にはそもそもシステムに手を入れる必要はないから、保守要員で対応できる。
0343デフォルトの名無しさん
NGNGDNA 解析みたいな学術的な話に限らず、たとえば在庫管理システムなんかの
データベース設計にしても、業界ごとの支払いの慣習やら何やらが設計に反映
してこないか？ それってコードやスキーマを見ても分からないから、文書化し
てないと後任が困るでしょ。
（実際の企業でも、支払い関係は○○さんに聞け、で他は誰も理解してない場
合もあるけど）
0344デフォルトの名無しさん
NGNG> ｜ 何年も同じ仕事してたらそういうふうになるのは当然では？
これは危険は思い込み。
顧客が「今」システムを必要としている理由は、
その顧客しか知りえない。
そして顧客はその理由を知っているか又は断片を知っているが、
それを適切に記述できるとは限らない。
その「理由またはその断片」と「記述」を結びつけるのが分析。
0345とあるダメ社員
NGNG>>327
｜327 ：293 ：02/03/02 08:56
｜>>320
｜＞ほぼ業務知識が必要のないプログラムでは、プログラムを読めばわかるというのは当然のこと
｜それはどうかな？
｜basicという用語を知ってたからコメントやソースを見て判ったのでは？
｜つまりそれを見る為の知識の一部があったからでしょ？
｜それとも使われてる再帰下降法から判ったの？
名称と書かれた内容からです。また、わたし自身も未熟なプログラマではあるからです。
知識がある、といってもプログラマなんですから高級言語を使わない人はいないと思います。
プログラマならばほとんど誰でもある程度理解している分野と言って良いのではないでしょうか。
｜「プログラムの動作はわかる。しかし、意味がわからない」のはやっぱり経験不足・勉強不足だよ。
｜社会常識や技術の常識は勉強しておくのは普通でしょ？
ここはすでに339さんが言及していますが、常識や技術の常識と「業務スキル」はまったく別だと
思います。歴史的な経緯で特別な処理を行わなければならない例は沢山ありますし、業界のルール
のようなものであれば、まったく聞かなければわからないものも沢山あります。
339さんが仰っているような、学術機関での難しい例もありますし。
｜途中で欲しい出力のイメージさえ判れば入力画面もコードもデータベースも判るという話が出てた
｜けど、それが普通であって、 分析とか設計とか必要なのがプログラマとしては異常な事だと思うよ
それについては、わたしは否定的な見解を述べています。
アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、全部がわかるわけ
ではない、ということです。
0348デフォルトの名無しさん
NGNGないとは言わん。特にシステムはほとんど変わらず、帳票の形式だけ改修して
くれみたいな仕事だと、ほんとに出力見本だけで終わりだし。
0350とあるダメ社員
NGNGもちろん、そういう例もあるとは思います。
でも、そういう例ばかりではないことも、おわかりですよね。
さらに言うと、出力例だけ要求定義が十分であるような案件で、１００００行もの手続きを経なければならないようなプログラムがはたして本当に存在するのでしょうか？
0351デフォルトの名無しさん
NGNG0352デフォルトの名無しさん
NGNG財務分析用のアプリケーションを組むときに、最後にこんな感じのグラフと表を、
と言われて要件定義できるか？
0354とあるダメ社員
NGNG｜323 ：デフォルトの名無しさん ：02/03/02 06:39
｜つか、設計書と仕様書の違いがわかっているように見えないので、なにを議論したいのか不明です。
設計書・仕様書の呼び方は、その方の所属する文化に応じて変わるので、この場では特に使い分けし
ていません。という事をすでに書いていますが、仕様書として統一した方が良さそうですね。
今後は仕様書として記載します。
0355デフォルトの名無しさん
NGNG> アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、
> 全部がわかるわけではない、ということです。
「多くの」プロジェクトでは上記の通り。
しかし「全ての」プロジェクトではないことは同意してもらえるかな？
「多くの」場合、定石通りに物事を進めていれば無難に物事を進められるだろう
しかし、「ある場合」には定石を無視することも必要である。
------- 以降独り言 ツッコミ禁止 -------
# だが、これをやって失敗すると次から店員にマークされるという危険も伴う、諸刃の剣。
# 素人にはお薦め出来ない。
# まあお前らド素人は、定石を確実にこなせるようになりなさいってこった。
0356デフォルトの名無しさん
NGNG> しかし、「ある場合」には定石を無視することも必要である。
定石を敢えて無視するには、それなりの理由が必要だ。納期とか納期とか納期とか。
（違う？）
0357293
NGNGただ>>223 で知りたいというから教えてやろうかと思ったが
もしかして余計なお世話？
＞アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、全部がわかるわけ
とかさあ・・・そりゃ当然でしょ？
判る範囲でどんどん作って判らない部分は客に聞く。 ただし客だって希望をしっかり表現出来る
訳じゃないから、作って見せて どうよ？ と聞く
判らない場所は想像して、そのどの場合でもすぐ対応出来るように準備しとくだけの事でしょ？
もちろんこんなやり方は勉強したての新人じゃ出来ないよ。だから薦めてる訳じゃない。
それともこういうやり方で仕事なんてホントは出来ませんとでも言って欲しいのか？
0358とあるダメ社員
NGNG｜355 名前：デフォルトの名無しさん ：02/03/02 14:57
｜>>345
｜> アウトプットだけをもらったところで、客先の要求仕様の一部にはなりえても、
｜> 全部がわかるわけではない、ということです。
｜「多くの」プロジェクトでは上記の通り。
｜しかし「全ての」プロジェクトではないことは同意してもらえるかな？
もちろん、355ですでに書いたように同意はしています。
｜「多くの」場合、定石通りに物事を進めていれば無難に物事を進められるだろう
｜しかし、「ある場合」には定石を無視することも必要である。
どんな場合なのでしょうか。
また、定石を無視するようなケースが、ここでの議論する題材として適切なのでしょうか？。
なぜ、定石が成立しないような無茶（？）なケースをここで言及しなければならないので
しょうか？ 教えてください。
0359デフォルトの名無しさん
NGNG書いてる人間が想定しているシステムの規模やら参加者のスキルやらが
てんでバラバラだから、ある範囲でしか議論が成立しないのは仕方ない。
ま、別に回答は義務でもなんでもないし、ここで議論に負けたからといって
現実世界で悪影響があるわけでもなし（掲示板の議論なんて、最後まで
飽きずに書いたヤツが勝つだけだ）、飽きたら適当なところでストップして
良いって。
> もちろんこんなやり方は勉強したての新人じゃ出来ないよ。
あとは規模にもよるんだよな。システムが大きすぎると、とりあえず作って
みるといっても何百人月必要って話になって、あまり try & error を繰り返
すわけにもいかない。
人が増えると、情報を流すパスの整備とかも必要になるしさ。
0360デフォルトの名無しさん
NGNG> 定石を敢えて無視するには、それなりの理由が必要だ。納期とか納期とか納期とか。
例えばトム・デマルコの「デッドライン」という本の中では
要求仕様はどーせパクリ製品だからと理由で省略し、
バグはどーせでないんだからという理由で検査を省略している。
その代わりに設計は従来よりも多くの工数をかけている。
# なんかこう書くとドキュソ本のように見えるけど、一応良書だよ
0361デフォルトの名無しさん
NGNG本当に顧客の業務が顧客より理解できていると思うんなら
プログラマなんてやめて転職したほうが儲かるよ。（W
今は金融はイマイチだけどある意味チャンスだし、
医療は不況知らずだしな。
0362デフォルトの名無しさん
NGNG> 要求仕様はどーせパクリ製品だからと理由で省略し、
それは正しい判断だな、確かに。
> バグはどーせでないんだからという理由で検査を省略している。
これはかなりヤバそうだが、そのシステム固有の何か特別な要因があるの？
0363デフォルトの名無しさん
NGNG開発人員が少人数で、顧客自身がシステム化したい事を良く
わかっていなくて、コンピューターに疎い様な場合は、355氏の
書いている事にあてはまると思う。
0364デフォルトの名無しさん
NGNGワロタ。潔いな。
0365デフォルトの名無しさん
NGNGまったくだ。
ただ、プログラマも儲からんわけではないんだが。特にいわゆる上流工程と
言われてる範囲とか、コンサルかねたシステム屋さんとかだと、単価は高い
よ。コーディング屋さんだと、よほど特殊な技術がないと高が知れてるが。
…っつか、技術力ゼロでコード書けねーバカ SE が蔓延してるんだから、そ
いつら追えよ＞要件定義できてコード書ける現場のプログラマ
（その方が顧客も幸せだ、多分）
0366293
NGNGおっしゃる通り。 分野によって感覚は違うne
俺だって会計系なら一人で１万行/月程度のコードは書けるけど
組込用のCだと千行/月でも厳しい時があるし
そもそも始めての環境だと1ヶ月くらい助走期間が必要だしne
0367デフォルトの名無しさん
NGNG> どんな場合なのでしょうか。
このスレで書いてあるとおり
この判断は言葉で言えるほど簡単ではない
残念ながら勘と経験を積んで悟るしかない。
> また、定石を無視するようなケースが、ここでの議論する題材として適切なのでしょうか？。
ん、議論の為の議論はしたくないんじゃなかったっけ？
> なぜ、定石が成立しないような無茶（？）なケースをここで言及しなければならないので
> しょうか？ 教えてください。
ここは戦場だから。
昔の常識は今は非常識となる(例えば机上デバッグは今は非常識)
定石は「ある場合」にしか適用できない。
状況が激変するこの業界ではその定石を適用する場合、
常に現在の状況が「ある場合」かどうかを問い続けなければならない。
でないと進化に取り残され、戦死する可能性が高い。
0368デフォルトの名無しさん
NGNG規模として半年・５人くらいのプロジェクトだとどう？
分担とか工程管理のためにも 最初に分析・設計は必要でしょ？
0369293
NGNGだから、誰も設計無しを薦めていないって
>>223の数万行くらいを設計書も作成しないでどうして出来るのかって
質問の説明をしてるだけ。
その方がいいとかそういう話じゃない。
0370とあるダメ社員
NGNGうーん。なんだかお答えが全て、とても曖昧ですね。
｜> また、定石を無視するようなケースが、ここでの議論する題材として適切なのでしょうか？。
｜ん、議論の為の議論はしたくないんじゃなかったっけ？
御自身、為にする議論を振っている、という自覚があるのでしたら妙な話は控えていただければ
ありがたいのですが。367さんの記述したケースに言及する＝為にする議論であるという自覚を
お持ちなら。
それと、状況が激変するという書き方は、確かに日経の雑誌などでよく見かけますが、本当なの
でしょうか。わたし自身、不勉強をこのスレで感じましたが、それは状況の変化では
なくて、単に自身の不勉強であるように思います。
属している業界に応じた変化があるとは思いますが、「状況が激変するこの業界」とまで、ひと
くくりにするのは、ちょっと無理があるように思います。
0372デフォルトの名無しさん
NGNG議論がしたいだけなんだ。
ほっとけ
ほっとけ
0373デフォルトの名無しさん
NGNGつーかさ、「状況が激変するこの業界」はいいけどさ、
ほかの業界だって業務形態がどんどん変わってきてるのに
フォームだけ見てコーディングできるってのが不思議だよな。
4GLマンセーおじさんと同類に見えてくる。
>>372
プププププ…
0374デフォルトの名無しさん
NGNG> フォームだけ見てコーディングできるってのが不思議だよな。
「いつも」そうしていると誤解していない？
OO信者とアンチOOは同類のように思えてきた
両者とも「現在の状況」を無視して自分の定石が常に正しいと信じている。
0375デフォルトの名無しさん
NGNG結局下手に自分のスタイルを状況に合わせて変えるよりも力技で押し切った方がまじだと。
0376293
NGNG>>374 最初からそういうふうに聞けよ そしたら無視するだけで済んだんだからyo
お互い胸糞悪い思いしないですんだんだからsa
こっちは休みでも自分の子供の相手しながら勉強してんだ。
他人の子供のお守りまでやってられるか！
0378デフォルトの名無しさん
NGNG0379デフォルトの名無しさん
NGNG0380デフォルトの名無しさん
NGNG0381デフォルトの名無しさん
NGNG> このスレは議論するのが目的だから…
違うよ。
> 引き続きＯＯ厨とアンチＯＯ厨の血で知を笑う戦いきぼ。
途中で良スレになりそうな気がしたのは気のせい。
0382デフォルトの名無しさん
NGNG0383380
NGNG0384380
NGNG0385デフォルトの名無しさん
NGNG> けっ馬鹿馬鹿しい。
> >>374 最初からそういうふうに聞けよ そしたら無視するだけで済んだんだからyo
> お互い胸糞悪い思いしないですんだんだからsa
となるのか謎。何か誤解があるようにしか思えんのだが。
0386デフォルトの名無しさん
NGNG0387デフォルトの名無しさん
NGNG考え方だけが。
戦場では使えないけどね。
0388デフォルトの名無しさん
NGNG0389デフォルトの名無しさん
NGNGOOP特に OOPLはパラダイムレベルにあると思うけど OO設計分析はどうかなあ
0390デフォルトの名無しさん
NGNG設計は、手続き中心の構造化とオブジェクト中心の OO だとパラダイムシフトが
あるでしょう。分析は、OO でも RUP あたりだと
まずはユースケースの洗い出し
だから、手続きというか機能単位の分析ってことで、それほど差はない気がする。
0391デフォルトの名無しさん
NGNGC++を採用したプロジェクト→20.8%
JAVAを採用したプロジェクト→20.6%
Cを採用したプロジェクト→45.13%
http://www.gyve.org/~jet/lang2.txt
0392デフォルトの名無しさん
NGNGそのネタは、
だいぶ前に紹介されて
笑われて
捨てられた。
0393デフォルトの名無しさん
NGNGOOがね。
0394デフォルトの名無しさん
NGNGでもさ、>>373に対してとしても、373はとあるダメ社員さんじゃないでしょ。
やっぱ何か勘違いしてるよ。
まあ、別にどうでもいいけどさ、
それでも>>391みたいなのよりはましなネタが出てたからなあ、あの流れは。
0395デフォルトの名無しさん
NGNGOOP/OOPLはパラダイムと呼べるほど普及してるかもしれない。
戦場とか現場とかでも主に使われる道具レベルにあるし、
その用語も普及してると思うが、OO設計・OO分析はそうじゃないだろ
0396デフォルトの名無しさん
NGNGいまだにロートルアンチのふざけた仕事が横行しているせいです。
ところでロートルってなんとなく使ってみたけどどういう意味だろう？
けなし言葉だよね？とりあえずけなし言葉だと受け取ってくれ。
0397デフォルトの名無しさん
NGNG（中国語から）老人。としより。
Kokugo Dai Jiten Dictionary. Shinsou-ban (Revised edition) ｩ Shogakukan 1988/国語大辞典（新装版）ｩ小学館 1988
0398デフォルトの名無しさん
NGNG確かにユースケースやアクティビティダイアグラムは機能分析的ではあるが、
構造化分析では機能を分解していくのに対して、
OOAでは機能の主体を洗い出して主体間の関係を記述していく。
つまり、最初にやる事は同じだが、目的とその後の分析工程が全く異なる。
>>395
パラダイムはこの場合は「その手法の支配的なものの見方」と見たほうがいいと思う。
普及度については、確かに正しく実践されている例はまだ少ないかもしれない。
しかしOOPがSimulaから３０年かかって普及し始めたことから見ても、
まだこれから普及が加速していく可能性はある。
用語についてはOOA・OODの概念などは多くはOOPから取り入れられていると思う。
0399デフォルトの名無しさん
NGNG0400デフォルトの名無しさん
NGNGOOPはすでにずいぶんと普及していますが何か？
0401デフォルトの名無しさん
NGNGコンポーネント指向、エージェント指向、アスペクト指向、マルチパラダイム
0402デフォルトの名無しさん
NGNGもう普及し尽くしてるだろ、あとは衰退。
0403デフォルトの名無しさん
NGNG俺も、未だに OO を取り入れてないトコロに今後 OO が普及するとは思えんな。
そもそも OO が適さない分野というのも存在するし、OO によらず方法論を学ば
ずにデスマーチを繰り返してるところもあるし。
0404デフォルトの名無しさん
NGNGOOP"対応"言語はな。
0405デフォルトの名無しさん
NGNG0406デフォルトの名無しさん
NGNG再利用性が高まったという劇的な話を聞かないのは何故？
0407デフォルトの名無しさん
NGNGOO に限らんが、何らかの開発手法を導入して生産性が改善されたって話を
無料で同業者にアナウンスしても、ビジネス的に全く旨みがないから、どこも
やりたがらないだけ。
0408デフォルトの名無しさん
NGNG> 無料で同業者にアナウンスしても、ビジネス的に全く旨みがないから、どこも
> やりたがらないだけ。
ハッキリ言って同意。世界中のOO開発者、出版社、企業は
組織的にオブジェクト指向が効率的だという事実を隠しています。
その本部はエリア55の地下にあるといわれています。
0409デフォルトの名無しさん
NGNGあなたが、OOの良い話を聞こうとしないからです。
■ このスレッドは過去ログ倉庫に格納されています