【Java叩き?】なぜ年寄りはOOを受け入れないのか 3
>>951
C++はOO言語だがプロジェクトに新人が交じってると安全じゃない。
Java以外のOO言語はメンバーが集まらない。
寄せ集めのメンバーでそこそこ安全な（サイズの大きい）システムを
組むとすると、OO以前にJava環境に慣れた人間を集めるのが順当。
OOパラダイムは開発効率を損ねずに安全性を確保するのには適当。
漏れ自身は「いま、（商業システムの開発環境として不安の残る）Javaで
積極的にJavaの可能性を広げようとしている奴は、とりあえず
使えそうな気がする」という理由で（暫定的に）受け入れる。
個人的にはCが一番強力だと思うが、だからこそ知らん奴が書いた
Cのコードを盲目的に信じる気には絶対ならん。
C++はOO言語だがプロジェクトに新人が交じってると安全じゃない。
Java以外のOO言語はメンバーが集まらない。
寄せ集めのメンバーでそこそこ安全な（サイズの大きい）システムを
組むとすると、OO以前にJava環境に慣れた人間を集めるのが順当。
OOパラダイムは開発効率を損ねずに安全性を確保するのには適当。
漏れ自身は「いま、（商業システムの開発環境として不安の残る）Javaで
積極的にJavaの可能性を広げようとしている奴は、とりあえず
使えそうな気がする」という理由で（暫定的に）受け入れる。
個人的にはCが一番強力だと思うが、だからこそ知らん奴が書いた
Cのコードを盲目的に信じる気には絶対ならん。
C++の場合、熟練CプログラマがOOを完璧に理解してたと
してもなお、絶対安全じゃないからなぁ・・・
してもなお、絶対安全じゃないからなぁ・・・
954 ：仕様書無しさん：2005/10/23(日) 18:50:29
Javaってlispの劣化版だよね
955 ：仕様書無しさん：2005/10/23(日) 19:17:38
LISPのどこがOOなんだよ。このemacs厨が
え？
今まで「OOPLとしても使えるC」だと思っていたよ
まあCは「高級マクロアセンブラ」だからあながち違うとも断言出来ないかもｗ
今まで「OOPLとしても使えるC」だと思っていたよ
まあCは「高級マクロアセンブラ」だからあながち違うとも断言出来ないかもｗ
Object-Oriented
ttp://www.sg-sogo.co.jp/product/bunasimeji/image/seiikusitu.jpg
ttp://www.sg-sogo.co.jp/product/bunasimeji/image/seiikusitu.jpg
>「OOっぽい高級マクロアセンブラ」です。
「OOふうの記述ができるようにするプリプロセッサ」
だと思ったが……
「OOふうの記述ができるようにするプリプロセッサ」
だと思ったが……
> いつの時代だ
今日の午後五時くらいだな(-_-!)
cc が、ソースに .cpp ファイルを指定すると、プリプロセッサで
C のソースに展開してからコンパイルしてくれていた。
ちなみにC のコンパイラのデフォルトはK&R の初版互換で、
プロトタイプ宣言が使えん。さらに笑えることに、ANSI準拠モードで
コンパイルをかけても、
for (int cnt= 0;cnt < n;cnt += 1) {
というコードが、int の宣言が不正だといってエラーになる。
今日の午後五時くらいだな(-_-!)
cc が、ソースに .cpp ファイルを指定すると、プリプロセッサで
C のソースに展開してからコンパイルしてくれていた。
ちなみにC のコンパイラのデフォルトはK&R の初版互換で、
プロトタイプ宣言が使えん。さらに笑えることに、ANSI準拠モードで
コンパイルをかけても、
for (int cnt= 0;cnt < n;cnt += 1) {
というコードが、int の宣言が不正だといってエラーになる。
>>961
そ、そうか。すまん…
そ、そうか。すまん…
963 ：仕様書無しさん：2005/10/27(木) 14:51:35
javaって糞だよな。
Ｃ言語は出始めのが一番良かった。
Ｃ言語は出始めのが一番良かった。
>>959-961
それは、プリプロセッサと言わずにトランスレータと言うのでは？
それは、プリプロセッサと言わずにトランスレータと言うのでは？
>>965
C++ とか RATFOR みたいに、部分的に元ソースが残っている奴は
プリプロセッサという気がするが。
とはいえCコンパイラも「Cのコード→アセンブラのコード」だから、
トランスレータという気がせんでもない。
C++ とか RATFOR みたいに、部分的に元ソースが残っている奴は
プリプロセッサという気がするが。
とはいえCコンパイラも「Cのコード→アセンブラのコード」だから、
トランスレータという気がせんでもない。
966 ：仕様書無しさん：2005/11/04(金) 22:12:56
967 ：仕様書無しさん：2005/11/04(金) 22:15:48
どっちにしろどうにもならんJavaはなにしても無駄
>>900
煽りとしては相変わらずレベルが低いな
Webアプリの定義というものがどういうものかも解らず、
Java＝Webアプリ開発専用言語という恥ずかしい勘違いをするとは
さすがC言語厨だ。
PHPやPerlなどのような言語ASPのようなものと同じことしかJavaにはできないと
勘違いしていることがあまりにも恥ずかしいことだと言うことに気づくんだな。
必死に煙に巻こうとしているのは
お前のようにそのようなレスをするC言語厨のほうではないかな？
はては、図星かな(藁
煽りとしては相変わらずレベルが低いな
Webアプリの定義というものがどういうものかも解らず、
Java＝Webアプリ開発専用言語という恥ずかしい勘違いをするとは
さすがC言語厨だ。
PHPやPerlなどのような言語ASPのようなものと同じことしかJavaにはできないと
勘違いしていることがあまりにも恥ずかしいことだと言うことに気づくんだな。
必死に煙に巻こうとしているのは
お前のようにそのようなレスをするC言語厨のほうではないかな？
はては、図星かな(藁
>>878
違うな。
オブジェクト指向は数学の一つの分野である
代数学、ベクトル解析、数論に
似ている。
抽象化という概念がな。
世界を抽象的なものに置き換えるところが
まさにオブジェクト指向と似ている。
超平面という面は実在しないがn次元ベクトル空間の中では存在する。
4次元時空(=三次元空間 + 時間)は現実世界に存在しても
4次元空間は実在しない。
宇宙には10次元宇宙というものが考えられているが
あれは10次元空間ではなく、4次元時空 + 6の高度自由度として10次元宇宙が成り立っているのだ。
オブジェクト指向というものは何かに置き換えて考え設計するものだ。
そこが数学的だともいえる。
C++を使わずに、Javaだけでも、数学で使われる抽象化の概念を容易に
実現することができる。
違うな。
オブジェクト指向は数学の一つの分野である
代数学、ベクトル解析、数論に
似ている。
抽象化という概念がな。
世界を抽象的なものに置き換えるところが
まさにオブジェクト指向と似ている。
超平面という面は実在しないがn次元ベクトル空間の中では存在する。
4次元時空(=三次元空間 + 時間)は現実世界に存在しても
4次元空間は実在しない。
宇宙には10次元宇宙というものが考えられているが
あれは10次元空間ではなく、4次元時空 + 6の高度自由度として10次元宇宙が成り立っているのだ。
オブジェクト指向というものは何かに置き換えて考え設計するものだ。
そこが数学的だともいえる。
C++を使わずに、Javaだけでも、数学で使われる抽象化の概念を容易に
実現することができる。
971 ：仕様書無しさん：2005/11/04(金) 22:33:00
>>878がオブジェクト指向を数学じゃないと否定するよりも
数値計算、数値解析、デジタル信号処理は工学であって数学じゃないと
否定した方が説得力があるのではないかな？
大抵、オブジェクト指向を否定する人間は数学好きと言うよりもむしろ数学嫌いで
工学が大好きな人なんだろう。
数値計算、数値解析、デジタル信号処理は工学であって数学じゃないと
否定した方が説得力があるのではないかな？
大抵、オブジェクト指向を否定する人間は数学好きと言うよりもむしろ数学嫌いで
工学が大好きな人なんだろう。
972 ：仕様書無しさん：2005/11/04(金) 22:35:50
オブジェクト指向は抽象数学の一つか
なるほど
なるほど
973 ：仕様書無しさん：2005/11/04(金) 22:39:01
>>880
> 組込み系の連中ってCしか知らない奴も多い。OOPの利点がどうもよく理解できないらしい。
> そういう連中相手にOOPを普及させなきゃならんのだが、どういうアプローチが良いかなぁ？
> 結局OOって設計思想みたいなもんだから、Cでも似たような感じで書けちゃうんだよねぇ。
> C++とか使った方がより自然に書けるだけで。
まずはUMLでも覚えさせてみてはどうだろう？
テスト駆動開発とかテストファーストとか、
アジャイル開発とかいっても彼らは混乱するだけだと思うから
まずはUMLから。
> 組込み系の連中ってCしか知らない奴も多い。OOPの利点がどうもよく理解できないらしい。
> そういう連中相手にOOPを普及させなきゃならんのだが、どういうアプローチが良いかなぁ？
> 結局OOって設計思想みたいなもんだから、Cでも似たような感じで書けちゃうんだよねぇ。
> C++とか使った方がより自然に書けるだけで。
まずはUMLでも覚えさせてみてはどうだろう？
テスト駆動開発とかテストファーストとか、
アジャイル開発とかいっても彼らは混乱するだけだと思うから
まずはUMLから。
974 ：仕様書無しさん：2005/11/04(金) 22:43:06
>>886
> >>883
> 組み込み分野ってOOP適用し辛いんですよ。
> 対象がハードだったりすると、OO的な表現し辛いんです。
そりゃメモリ容量が制限されていればな。
携帯電話開発でも同様にな。
それからシステム系やデジタル信号処理系の香具師らは
オブジェクト指向の利点が理解できない連中が多い。
ブロック線図書いただけの適当なアルゴリズムを作っただけで
満足してるような連中が多いからな。
解析程度のものしか作れない。
> 荒っぽい言い方すると、極限まで抽象化するのがOOでしょ？
> ベタでいいもん。
実に荒っぽいな。極限はやりすぎだ。
> >>883
> 組み込み分野ってOOP適用し辛いんですよ。
> 対象がハードだったりすると、OO的な表現し辛いんです。
そりゃメモリ容量が制限されていればな。
携帯電話開発でも同様にな。
それからシステム系やデジタル信号処理系の香具師らは
オブジェクト指向の利点が理解できない連中が多い。
ブロック線図書いただけの適当なアルゴリズムを作っただけで
満足してるような連中が多いからな。
解析程度のものしか作れない。
> 荒っぽい言い方すると、極限まで抽象化するのがOOでしょ？
> ベタでいいもん。
実に荒っぽいな。極限はやりすぎだ。
975 ：仕様書無しさん：2005/11/04(金) 22:51:58
>>904
ふむふむ、どうみてもおまえさんのようなきちがいな年寄り
がオブジェクト指向をわかってないから盛り上がってるんじゃないかな。
>>903
確かにそうなのかもな。
でなきゃあんなにムキになってオブジェクト指向を否定するバカはいないよな。
日本だけじゃね？こんなにオブジェクト指向技術に遅れを取ってるどうしようもない連中が
多いのは。C言語厨はもっとしっかりすべきだと思うんだがな。
ソフトウェア産業を甘く見た製造業関係者の影響かねえ。
ふむふむ、どうみてもおまえさんのようなきちがいな年寄り
がオブジェクト指向をわかってないから盛り上がってるんじゃないかな。
>>903
確かにそうなのかもな。
でなきゃあんなにムキになってオブジェクト指向を否定するバカはいないよな。
日本だけじゃね？こんなにオブジェクト指向技術に遅れを取ってるどうしようもない連中が
多いのは。C言語厨はもっとしっかりすべきだと思うんだがな。
ソフトウェア産業を甘く見た製造業関係者の影響かねえ。
976 ：仕様書無しさん：2005/11/04(金) 22:54:47
>>931
> Java全般を理解していれば、洗脳されることもないだろうに。
> 両方とも目指すものは一緒。結局はユーザ様の「決め」だよ。
> まぁ、年寄りがＯＯを受け入れない理由は、基本設計からクラス設計をしたくない（できない、する気がない）だけだと思う。
駄目オヤヂだなそりゃ。
俺の考えでは営業とかが「短いせっかちな納期」を使って邪魔をして
設計する暇も余裕も無いん状態を延々と作り上げているからじゃないかと思う。
> Java全般を理解していれば、洗脳されることもないだろうに。
> 両方とも目指すものは一緒。結局はユーザ様の「決め」だよ。
> まぁ、年寄りがＯＯを受け入れない理由は、基本設計からクラス設計をしたくない（できない、する気がない）だけだと思う。
駄目オヤヂだなそりゃ。
俺の考えでは営業とかが「短いせっかちな納期」を使って邪魔をして
設計する暇も余裕も無いん状態を延々と作り上げているからじゃないかと思う。
>>952
Cが強いと思っているか。C++ではなくか？
将来的にはJavaやC#により似ている言語で、
C++と同じように使えるD言語が強力になってゆくだろう。
C++は経験の浅い新人が使うとたしかに
とんでもないことに陥る。
そこでD言語だな。
Cが強いと思っているか。C++ではなくか？
将来的にはJavaやC#により似ている言語で、
C++と同じように使えるD言語が強力になってゆくだろう。
C++は経験の浅い新人が使うとたしかに
とんでもないことに陥る。
そこでD言語だな。
>>944 , >>945
制御工学、デジタル信号処理系の
人間はなぜオブジェクト指向を受け入れず高をくくって
オブジェクト指向を学習する力が弱いのか
その答えが見えてきそうだな。
以前、ビッグサイトで6月頃だろうか、
産業用バーチャルリアリティ展、
設計・製造ソリューション点というのがあって、
そこでいかにも制御系な人間があつまっている会社の
ブースを見に行ったんだ。
ハードウェア開発と、そのハードウェアを動かすために
C言語を使ってソフトウェアを開発していた。
そこに白髪の50,60代と思われる男がいて、
C++は使っていないのか？
と聞くと一切つかっていなかった。
オブジェクト指向について聞くと、
ちゃんと前もってやればCだけでも十分問題なくできると言い張っていた。
複雑怪奇な大規模設計開発ではどうするんだ？ と聞いても
答えは同じだった。その会社は自社開発でやっており特許や著作権や
盗まれたくないという願望が強いのか、他社に委託することはやっていなかった。
制御工学、デジタル信号処理系の
人間はなぜオブジェクト指向を受け入れず高をくくって
オブジェクト指向を学習する力が弱いのか
その答えが見えてきそうだな。
以前、ビッグサイトで6月頃だろうか、
産業用バーチャルリアリティ展、
設計・製造ソリューション点というのがあって、
そこでいかにも制御系な人間があつまっている会社の
ブースを見に行ったんだ。
ハードウェア開発と、そのハードウェアを動かすために
C言語を使ってソフトウェアを開発していた。
そこに白髪の50,60代と思われる男がいて、
C++は使っていないのか？
と聞くと一切つかっていなかった。
オブジェクト指向について聞くと、
ちゃんと前もってやればCだけでも十分問題なくできると言い張っていた。
複雑怪奇な大規模設計開発ではどうするんだ？ と聞いても
答えは同じだった。その会社は自社開発でやっており特許や著作権や
盗まれたくないという願望が強いのか、他社に委託することはやっていなかった。
>>979より続き
>>944, >>945
そのとき、まさに年寄りがオブジェクト指向を否定し、
受け入れない姿を垣間見たと思ったよ。
ほかに、大学院で信号処理系の研究室でも同じ光景をみることができた。
信号波形を見て計算し、たたみ込み、フーリエ変換、間引き、内挿、
ローパスフィルタ、ハイパスフィルタなどをかけるアルゴリズムを
組み立てるのは得意だがオブジェクト指向とかはまるっきりだめって
香具師らが多かった。
彼らは複素数配列や行列を大量に扱うプログラムは作れるのに、
それをクラスとして、型を自作して抽象化するというプログラミングはできなかった。
計算そのものに時間がかかるのも多いけど簡単なものもある。
彼らは他人が作ったプログラムを解析することも苦手だった。
だから、先輩から貰ったプログラムはまったく解析できず、
誰もが他人から貰ったプログラムを再利用するよりも
「一から自分で作った方が早い」という言葉が新しい卒論性に贈る口癖だった。
普段は解析ばかりでプログラムの使い捨てが多く、大規模開発をすることがないのも
彼らがオブジェクト指向を理解できない原因のひとつなのかもね。
こんなんだから制御工学の人間にはオブジェクト指向の有り難みがりかいできないのかもね。
>>944, >>945
そのとき、まさに年寄りがオブジェクト指向を否定し、
受け入れない姿を垣間見たと思ったよ。
ほかに、大学院で信号処理系の研究室でも同じ光景をみることができた。
信号波形を見て計算し、たたみ込み、フーリエ変換、間引き、内挿、
ローパスフィルタ、ハイパスフィルタなどをかけるアルゴリズムを
組み立てるのは得意だがオブジェクト指向とかはまるっきりだめって
香具師らが多かった。
彼らは複素数配列や行列を大量に扱うプログラムは作れるのに、
それをクラスとして、型を自作して抽象化するというプログラミングはできなかった。
計算そのものに時間がかかるのも多いけど簡単なものもある。
彼らは他人が作ったプログラムを解析することも苦手だった。
だから、先輩から貰ったプログラムはまったく解析できず、
誰もが他人から貰ったプログラムを再利用するよりも
「一から自分で作った方が早い」という言葉が新しい卒論性に贈る口癖だった。
普段は解析ばかりでプログラムの使い捨てが多く、大規模開発をすることがないのも
彼らがオブジェクト指向を理解できない原因のひとつなのかもね。
こんなんだから制御工学の人間にはオブジェクト指向の有り難みがりかいできないのかもね。
さて、次スレの準備を
982 ：仕様書無しさん：2005/11/05(土) 00:08:21
>>979
昔の知識しかない漏れがレスしてみる。
制御系こそオブジェクト指向や”オブジェクト思考”の
恩恵を受けやすいと思うんだけど、以下のルール、都合がある会社が多い。
１．ある程度機能が出来上がったプログラムは必要以上の改変が許されなくなる。
酷い所になると、ソースも弄れなくなり（バイナリの固定）、
直接バイナリを弄って修正する）
２．ソースが見られない標準テンプレートは使わず、必要な物は自前で作る。
３．１に付随して、改変した所は最初の段階から評価し直す。
４．アセンブラレベルでのデバッグがしづらい。
そして（構造化プログラミングでの）モジュール単位で作りこんで行くので、オブジェクト指向の
開発をした場合広範囲に使われている基底クラスの修正をすると”幾つかのモジュール”
を弄った事になり、評価を多数やり直すハメになる。
昔の知識しかない漏れがレスしてみる。
制御系こそオブジェクト指向や”オブジェクト思考”の
恩恵を受けやすいと思うんだけど、以下のルール、都合がある会社が多い。
１．ある程度機能が出来上がったプログラムは必要以上の改変が許されなくなる。
酷い所になると、ソースも弄れなくなり（バイナリの固定）、
直接バイナリを弄って修正する）
２．ソースが見られない標準テンプレートは使わず、必要な物は自前で作る。
３．１に付随して、改変した所は最初の段階から評価し直す。
４．アセンブラレベルでのデバッグがしづらい。
そして（構造化プログラミングでの）モジュール単位で作りこんで行くので、オブジェクト指向の
開発をした場合広範囲に使われている基底クラスの修正をすると”幾つかのモジュール”
を弄った事になり、評価を多数やり直すハメになる。
983 ：仕様書無しさん：2005/11/05(土) 00:14:50
Java（J2EE)はCOBOLなんかのレガシー既存資産と共存できるように
設計されている。
最近COBOLが復権してるのもレガシー資産の再活用という発想が
JAVAなんかにあるからだろｗ
Cみたいな否定的言語よりもJAVAのほうがCOBOLと仲良くできるのだが
設計されている。
最近COBOLが復権してるのもレガシー資産の再活用という発想が
JAVAなんかにあるからだろｗ
Cみたいな否定的言語よりもJAVAのほうがCOBOLと仲良くできるのだが
>>982
それって最初に作った奴が
オブジェクト指向を使わずに設計したことが
発端になっていることと、
効率よいテストのやり方を知らず、
過剰テストが多くなっているために破綻しているんだと思う。
自動化ツールの使い方とか
テストの自動化とか知らない香具師らがあつまってる会社っぽい。
ソースコードの信頼性を高めるXUnitの使い方も知らない香具師多いしねこの業界。
しかも全部自分で作ることに拘っていることが危ないね。
テストを何度も行って信頼と実績を積んでいるオープンソースAPIですら拒絶しそうだw
それって最初に作った奴が
オブジェクト指向を使わずに設計したことが
発端になっていることと、
効率よいテストのやり方を知らず、
過剰テストが多くなっているために破綻しているんだと思う。
自動化ツールの使い方とか
テストの自動化とか知らない香具師らがあつまってる会社っぽい。
ソースコードの信頼性を高めるXUnitの使い方も知らない香具師多いしねこの業界。
しかも全部自分で作ることに拘っていることが危ないね。
テストを何度も行って信頼と実績を積んでいるオープンソースAPIですら拒絶しそうだw
985 ：仕様書無しさん：2005/11/05(土) 00:27:42
>>983
> Java（J2EE)はCOBOLなんかのレガシー既存資産と共存できるように
> 設計されている。
それは初耳。ソースは？
COBOL.NETのようにドトネトと共存できるってことなら聞いたことがあるけど。
わざわざCOBOLをドトネト化する理由は既存のCOBOL資産を再利用したい
からなんだってさ。
COBOL事態、言語仕様に問題があるから本当は
さっさと切り捨てて鞍替えした方がいいんだけどね。
> 最近COBOLが復権してるのもレガシー資産の再活用という発想が
> JAVAなんかにあるからだろｗ
ちょっと違うなー。銀行ですでに使われているからだろうね。
というか復権してるかw COBOL.NETとしてどうにか凌いでいるだけだろw
しかも昔のCOBOLとまったく互換性無いしw
言語使用上、Javaのようにはうまくはいかないなw
> Cみたいな否定的言語よりもJAVAのほうがCOBOLと仲良くできるのだが
この最後の一文意味がわからないな。
C言語厨の匂いがするぞw
> Java（J2EE)はCOBOLなんかのレガシー既存資産と共存できるように
> 設計されている。
それは初耳。ソースは？
COBOL.NETのようにドトネトと共存できるってことなら聞いたことがあるけど。
わざわざCOBOLをドトネト化する理由は既存のCOBOL資産を再利用したい
からなんだってさ。
COBOL事態、言語仕様に問題があるから本当は
さっさと切り捨てて鞍替えした方がいいんだけどね。
> 最近COBOLが復権してるのもレガシー資産の再活用という発想が
> JAVAなんかにあるからだろｗ
ちょっと違うなー。銀行ですでに使われているからだろうね。
というか復権してるかw COBOL.NETとしてどうにか凌いでいるだけだろw
しかも昔のCOBOLとまったく互換性無いしw
言語使用上、Javaのようにはうまくはいかないなw
> Cみたいな否定的言語よりもJAVAのほうがCOBOLと仲良くできるのだが
この最後の一文意味がわからないな。
C言語厨の匂いがするぞw
負け犬C言語厨はJava厨に対するコンプレックスがあるため
悔しそうにCOBOLを引き合いに出して必死に何かを言おうとしているだけですよ
悔しそうにCOBOLを引き合いに出して必死に何かを言おうとしているだけですよ
987 ：仕様書無しさん：2005/11/05(土) 00:29:59
988 ：仕様書無しさん：2005/11/05(土) 05:18:19
>> それは初耳。ソースは？
java.sun.comを尋ねて、Ｊ２ＥＥの目標、コンセプトを理解してください。
結局、Ｊ２ＥＥも.NETも目指す所は一緒だよ。
ところで、.NETは、流行りそうですか？
まぁ、マイクロソフトはパソコンのソフトつくってりゃいいんだよな。
java.sun.comを尋ねて、Ｊ２ＥＥの目標、コンセプトを理解してください。
結局、Ｊ２ＥＥも.NETも目指す所は一緒だよ。
ところで、.NETは、流行りそうですか？
まぁ、マイクロソフトはパソコンのソフトつくってりゃいいんだよな。
989 ：仕様書無しさん：2005/11/05(土) 13:51:27
COBOLと共存するという考えをもっているのは
富士通とか日立とかの社員だとおもうがなw
EclipseのCOBOL開発環境を使ってなw
富士通とか日立とかの社員だとおもうがなw
EclipseのCOBOL開発環境を使ってなw
990 ：仕様書無しさん：2005/11/05(土) 13:52:33
コンセプト = 絵に描いた餅ってことかな。
絵に描いた餅でもうまそうと思わせれば価値があるんだよ。
でも本当に価値があるのは
うまい餅をつくるレシピだよ。
でも本当に価値があるのは
うまい餅をつくるレシピだよ。
１０年前、大学でオブジェクト指向の講義を聴いたことがある。
そのとき直感的に「重そう」と感じた。
しかし実際に重くなったのは脳内でのイメージ作業で
プログラムの処理自体は遅くならなかった。
大事なのはプログラムを作ることではなく
想像してたデータの流れを紙上で具現化すること。
それはけっして絵に描いた餅ではなく
うまい餅をつくるためのレシピになった。
なるほどこれがＯＯかと思った。
そのとき直感的に「重そう」と感じた。
しかし実際に重くなったのは脳内でのイメージ作業で
プログラムの処理自体は遅くならなかった。
大事なのはプログラムを作ることではなく
想像してたデータの流れを紙上で具現化すること。
それはけっして絵に描いた餅ではなく
うまい餅をつくるためのレシピになった。
なるほどこれがＯＯかと思った。
しかし最近のＯＯ論者は考えることを他人にまかせ
うまい餅をたらふく食うことしか考えてない。
うまい餅をたらふく食うことしか考えてない。
オブジェクト指向という言葉はなかったが
スーパーマリオはオブジェクト指向だと思う。
スーパーマリオはオブジェクト指向だと思う。
ＯＯをだまって一人で実践してるのはむしろ年寄りだと思う。
ＯＯは頭で考えることだから
頭数が多いほど指向統一に時間がかかる
よって作業は遅れる
頭数が多いほど指向統一に時間がかかる
よって作業は遅れる
モニターの前で考え込むんじゃなくて、
紙の上で考え終わってから
プログラミングをする。
ある人はそれをオブジェクト指向と呼ぶ。
紙の上で考え終わってから
プログラミングをする。
ある人はそれをオブジェクト指向と呼ぶ。
１０００ならｵﾚはＯＯマスター
＼（OO）／
■
＜ ＞
＼（OO）／
■
＜ ＞
>992
言いたいことは分かるんだけどね、それでは今、何かを
作らなければいけない人は全く救われないのよ。
言いたいことは分かるんだけどね、それでは今、何かを
作らなければいけない人は全く救われないのよ。
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。