【オブジェクト指向】言語学習が先？概念学習が先？

【オブジェクト指向】 ..

545:デフォルトの名無しさん
06/06/27 23:18:21
向き不向きは人じゃなくて対象分野のほうが大きいとおもうな。
（まあ、人にも多少はあるだろうけど。）

C言語で、

struct window w;
window_open( w );
window_setsize( w, 100, 100 );

とかやってた人間は、

Window w = new Windows();
w.setSize( 100, 100 );

ってかけるようになったら「やっとなるべき形になった」としか思わないんじゃないかな。
「window_setsize( w, 100, 100 );　のほうがいい」と思う人は少ないと思う。

546:544
06/06/28 00:10:45
>>545
まさか、おいらが「人」の話をしていたと勘違いしますたか？
もちろん、作る「物」の話ですよ。

547:デフォルトの名無しさん
06/06/28 13:26:17
>>541
> オブジェクト指向の定義が１つじゃないのは問題

しかしそれが実際ですからねぇ…。それらを混同して（あるいは勝手に組み合わせた俺定義を
ふりかざして）トラブルになるケースは多いですし。逆に、誰の「オブジェクト指向」かを
明らかにするよう心がければ、議論の入り口でのありがちなループを回避できるのもまた確かなことです。
とにかく、教科書レベルの記述で混乱に拍車をかけるような書き方は避けて欲しいです。

あえて問題があるとすれば、オブジェクトが本質じゃないものに「オブジェクト指向」と名付けたケイか、
すでにケイのオブジェクト指向があるのに、あえて“抽象データ型のスーパーセット”あるいは
“クラス（継承）によるプログラミング”という別の切り口に同じ「オブジェクト指向」と
名付けてしまったストラウストラップが諸悪の根源か…。まあ、どっちもどっちかなと。

548:デフォルトの名無しさん
06/06/28 18:14:55
>>547
「オブジェクトを如何にして使用するか」　なケイと、
「オブジェクトを如何にして定義するか」　なストラウストラップの対立のような気が。

549:デフォルトの名無しさん
06/06/28 18:39:45
>>545
その例は、あまり魅力的な差に見えないね。
もうちょっと派手で、いかにもOOがよろしげに見える例を出せないの？

550:デフォルトの名無しさん
06/06/28 19:34:51
>>549
>その例は、あまり魅力的な差に見えないね。
それは、（君が現場の苦労を知らない）
坊やだからさ。

551:デフォルトの名無しさん
06/06/28 19:47:36
ありゃ、煽られちゃったよ…
しかし、現場の苦労はどうでもいいから、もうちょっとマシなの
おながいしまつ>>550

552:デフォルトの名無しさん
06/06/28 19:57:23
>>551
現場の苦労がどうでもいいなら、そんなのなくてもどうでもいいじゃん？

553:デフォルトの名無しさん
06/06/28 20:17:46
>>548
しらないならかかなきゃいいのに。

554:デフォルトの名無しさん
06/06/28 20:18:15
なんか言い逃れぽい返しばかりだなあ…
漫才したい訳じゃないんで、もうちょっとマシなの
おながいしまつ>>552

555:デフォルトの名無しさん
06/06/28 20:28:18
>>548
そもそも両者は対立なんかしていない。対立以前に名前以外、本質的部分に接点がない。

利用者が勝手な文脈でそれぞれのエッセンスをまぜこぜにして混乱を助長するから
発案者のほう（とくにストラウストラップ）が困惑しているくらいのことはあるだろうけど。

URLﾘﾝｸ(www.research.att.com)
URLﾘﾝｸ(www.purl.org)

556:デフォルトの名無しさん
06/06/28 20:39:55
>>554(535?)
ストラウストラップのオブジェクト指向の例でいいならば、複素数の計算とかは？
複素数という新しい型を定義せずに、複素数演算を自然に記述するのは難しいと思う。

557:デフォルトの名無しさん
06/06/28 20:48:06
>>556
それは >>545 のように対比できる対象例がありますか？

ちなみに>>535 は別の人ですけど。

558:デフォルトの名無しさん
06/06/28 21:42:20
オブジェクト指向ってプログラムのしやすさより設計のしやすさじゃない？
オブジェクト指向言語は設計＞コードの変換の手間が少なくて使いやすいと思う

559:デフォルトの名無しさん
06/06/28 22:36:20
テストのしやすさもあるよ。単純な話じゃない。

560:デフォルトの名無しさん
06/06/28 22:38:24
自分は一部のソースに変更があっても、他への影響が少ないぐらいしか利点が分からない。

561:デフォルトの名無しさん
06/06/28 23:23:28
>>557
Ｃ（non oop）版はアンチが書いてくれ。

class complex {
　double re, im;
public:
　complex(double r, double i) { re=r; im=i; }
　complex(double r) { re=r; im=0; } // float->complex conversion
　friend complex operator+(complex, complex);
　friend complex operator-(complex, complex); // binary minus
　friend complex operator-(complex); // unary minus
　friend complex operator*(complex, complex);
　friend complex operator/(complex, complex);
　// ...
};

complex operator+(complex a1, complex a2)
{
　return complex(a1.re+a2.re,a1.im+a2.im);
}
// ...

complex a = 2.3;
complex b = 1/a;
complex c = a+b*complex(1,2.3);
// ...
c = -(a/b)+2;

562:デフォルトの名無しさん
06/06/29 01:46:10
>>554
「現場の苦労はどうでもいい」なんて言ってる人間にとって、
「魅力的」なコードなんて、とりあえず俺には何の意味も無い。

プログラミングは座敷芸じゃない。

563:デフォルトの名無しさん
06/06/29 02:13:41
>>561
新しい型を自然に記述するのは、新しい型の振る舞いと定義が可能で、
元の言語仕様と同様に、新しい型を取り扱える処理系であれば可能な
事だと思います。
それは処理系依存の問題でoopとは関係ないような気がしますが、それ
とも、新しい型の振る舞いと定義が可能で、元の言語仕様と同様に、新
しい型を取り扱える事こそがoopだと言う事ですか？

564:デフォルトの名無しさん
06/06/29 02:15:05
>>562
ここは、マ板じゃなくてム板なんだから、そゆのもありじゃね？

565:デフォルトの名無しさん
06/06/29 02:22:14
>>564
ありだろうけど、逆にいうとそれに付き合う義理もないんじゃね？
とりあえず、>>545　は「そういう意味で」「魅力的」と主張してる
わけじゃないから、それは別の話題の話題として話せばいい。

566:デフォルトの名無しさん
06/06/29 02:39:51
擬似コードで恐縮だけど、例えば　C　ライクなコードで

[オブジェクト生成]
obj01　=　window_new();
obj02　=　button_new();
obj03　=　checkbox_new();
obj04　=　listbox_new();

[表示]
window_show(obj01);
button_show(obj02);
checkbox_show(obj03);
listbox_show(obj04);

とかやってた人間は、　

[オブジェクト生成]
obj01　=　new　window();
obj02　=　new　button();
obj03　=　new　checkbox();
obj04　=　new　listbox();

[表示]
obj01->show();
obj02->show();
obj03->show();
obj04->show();

になる。

567:デフォルトの名無しさん
06/06/29 08:08:15
>>563
ストラウスストラップのオブジェクト指向の文脈では、そう。
より正しくは、それに継承を加えたもの。
別の言い方をすると、抽象データ型(ユーザーが新しい型と振る舞いを…)を
Simulaのクラスを使ってやる、というのが彼の(そして´90年代以降主流の、
今でいう、カプセル化・多態性・統承の)オブジェクト指向。

念のため書き添えると、この文脈では「メッセージ」(ケイのオブジェクト指向の
キー・コンセプト)は関係ない。

568:デフォルトの名無しさん
06/06/29 08:13:51
>>567
統承× → 継承〇　　スマン。手書きなもんで…。

569:デフォルトの名無しさん
06/06/29 10:08:20
手書き？w

570:デフォルトの名無しさん
06/06/29 10:38:42
そう。手書き入力。

571:デフォルトの名無しさん
06/06/30 00:42:06
>>567
ありがとう、やっと、自分の理解していた事が、言葉と結びつきました。

572:デフォルトの名無しさん
06/06/30 07:01:09
>>571
何かのお役にたてたのでしたら、さいわいです。

573:デフォルトの名無しさん
06/07/03 21:37:41
オブジェクト指向そのものは意見が分かれるが、「オブジェクト指向言語は
便利だ」でOK？

574:デフォルトの名無しさん
06/07/03 21:52:16
>>573
使いどころによって便利か不便かが決まる。

575:デフォルトの名無しさん
06/07/03 22:01:33
別にOOPLだからって
がんじ絡めにOOPしなくても良いんだから不便ってこたぁないだろ

それが自分のせいであれ、会社のせいであれ
OOPLが不便って思う人はOOPLに振り回されてると思う

大きなコードになるとOOPの方が良いが
小さなコードで無理してOOPすると余計に混乱するぞ

576:デフォルトの名無しさん
06/07/03 22:18:23
>>573
もっと謙虚に、プログラミングにおける支配的パラダイムだ、でいいと思う。

577:デフォルトの名無しさん
06/07/03 22:21:21
「支配的パラダイム」ｶｯｺｲｲー。ｽｹﾞｰ。感動して涙出てきた。

578:デフォルトの名無しさん
06/07/04 13:18:16
ニュートン力学は物理学における支配的パラダイムだった。相対性理論の発表までは。
相対性理論は物理学における支配的パラダイムだった。量子力学の誕生までは。
いや
端的に「支配的パラダイムは歴史と共に変遷する」と表現した方がわかりやすいか？

そして
パラダイムのシフトは旧来のパラダイムを支持する人間が死滅するまで完了しない
という歴史的な事実も書いておこう

579:デフォルトの名無しさん
06/07/04 20:23:57
その考えは面白いかもしれない。
ニュートン力学も相対性理論も量子力学も、世界の一部分を切り取った姿を提示しているだけだから、
これをプログラミングに直すと　『ひとつの方法』　を提示しているってことになるな。

580:デフォルトの名無しさん
06/07/04 21:57:56
2500年程前に孔子がいいことを言っている。
「学びて思わざれば則ちくらし、思うて学ばざれば則ちあやうし」

これにてこのスレ終了。

581:デフォルトの名無しさん
06/07/14 14:08:32
理系馬鹿で文系センスがない人はオブジェクト指向がわからない

582:デフォルトの名無しさん
06/07/14 16:56:04
という貧弱脳の文系が言い出した都市伝説

583:デフォルトの名無しさん
06/07/15 15:32:30
文系＞＞＞＞＞＞理系

584:デフォルトの名無しさん
06/07/15 16:09:41
文系か理系かなんてのは瑣末な属性にすぎない。
大事なのは振る舞いだ。

585:デフォルトの名無しさん
06/07/15 16:25:35
大盤振る舞い

586:デフォルトの名無しさん
06/07/15 16:51:44
わお、584が振舞ってくれるヨ！

587:デフォルトの名無しさん
06/07/15 16:52:52
俺、最近思うんだ。
勉強すればするほど馬鹿になってるんじゃないかって。

588:デフォルトの名無しさん
06/07/15 19:42:42
理系馬鹿はそうだね

589:デフォルトの名無しさん
06/07/15 21:05:10
人生、楽しい事は多くは無いけど、勉強は辛さをちょっとガマンすれば楽しくなれる近道だと二十年来の劣等生の俺は思う。

590:デフォルトの名無しさん
06/07/16 00:49:33
辛いと思っているなら負け組み。

591:デフォルトの名無しさん
06/07/16 04:35:58
>590の言葉が沁みる

592:デフォルトの名無しさん
06/08/21 11:04:09
大学は概念しかないから、せいぜいおもちゃシステムをこねくりまわして
能書き垂れてる。

やはり、言語学習で慣れるのが先では？
でも言語学習だけで終わると薄っぺらな人生と同じで虚しい。

１の質問に対しては｢両方とも必要｣という穏当かつ中途半端な
回答しかないと思う

593:デフォルトの名無しさん
06/08/27 18:34:37
恐レスだけど、鬱本はさすがに内容が古すぎるよ。
オブジェクト指向設計技術はここから何度も刷新されている。
今から購入するんなら、
「デザインパターンとともに学ぶオブジェクト指向のこころ」を
お勧めしたい。

594:デフォルトの名無しさん
06/08/27 21:21:10
仮説だが、プログラミングの「プ」も知らない人に教える方法として、
上から下に処理が実行されることを教えた後ですぐに
継承とかインターフェースとか教えて、
デザインパターンのいくつか、例えばテンプレートメソッドとかを覚えさせて、
その後で、繰り返し文とか配列とか教えたら、
なかなか面白いことになるのではなかろうか。
誰か新人に試してみれ。

595:デフォルトの名無しさん
06/09/06 17:34:59
日本語の学習が先。横文字を使って得意がるようになったらオシマイ。

596:デフォルトの名無しさん
06/09/07 22:20:38
>>595
確かに横文字で得意がるタイプは居るな

しかし敢えて>>595の言う横文字が
何処までを指すのか知りたい

少なくともここ一週間のこのスレのログには
得意がる程の横文字は見当たらないんだが…

597:デフォルトの名無しさん
06/09/07 22:55:32
>>596
そんなの>>595の虫の居所次第じゃね？

598:デフォルトの名無しさん
06/09/30 17:35:03
「脱オブジェクト指向のススメ」
URLﾘﾝｸ(blogs.itmedia.co.jp)

599:デフォルトの名無しさん
06/09/30 18:26:43
>598
それ糞だから

600:デフォルトの名無しさん
06/09/30 20:28:44
オブジェクトだけに､先に実践してからの結果として学ぶ（＝分かる)でエエんやないか?

601:デフォルトの名無しさん
06/09/30 21:34:09
Is some of the design pattern , for instance, the method of the template
made to teach succession or the interface at once after processing is
taught to be executed on below as a method of teaching to the person who
doesn't know "P" of the programming though it is a hypothesis, and to be
remembered, and if the for statement or the array is taught afterwards,
it not interesting? easily
It is tried by the new figure.

602:デフォルトの名無しさん
06/10/01 11:17:48
アプローチの違う複数の言語、たとえばSmalltalkでもclosでもC++でも通用する
オブジェクト指向の概念、ちゅーのは、果たしてありうるんだろうか？

603:デフォルトの名無しさん
06/10/01 12:56:09
>>602
“オブジェクト指向的な設計”と“オブジェクト指向言語の使い方”を混同してるだけにしか見えない
設計から実装にいたる間は幾つかの層に分けられるのだから、より抽象的な所では同じでも良いが実装に近づくにつれ分化していくって所

604:デフォルトの名無しさん
06/10/01 22:38:55
言語によるオブジェクト感覚の違い
C++ と Smalltalk

605:デフォルトの名無しさん
06/10/01 22:41:28
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
「新たな感覚　・・・　それはオブジェクト感覚だ！」　の巻～

606:デフォルトの名無しさん
06/10/02 04:51:36
>>603
チミが本気でそう思うなら、チミの「オブジェクト指向」は漠然としすぎていて
童話のようなお話だってことだ。
たとえばアランとビアルネのオブジェクト指向は、根本から明らかに違う。

607:デフォルトの名無しさん
06/10/02 12:18:48
>>606
チミが本気でそう思うなら、チミの「オブジェクト指向」は漠然としすぎていて
童話のようなお話だってことだ。

以下ループ

608:デフォルトの名無しさん
06/10/02 14:28:01
オブジェクト指向なんて簡単なモノすらわからないやつって・・・

609:デフォルトの名無しさん
06/10/03 07:46:13
オブジェクト指向の簡単な部分だしか知ないうちは、オブジェクト指向が簡単だと感じる。
統一した概念として説明しようとすると、共通のキーワードを抜き出して、大雑把に
説明するくらいしか出来ないけど、それはオブジェクト指向についての説明にぜんぜんならない。
ネコクラスが哺乳類クラスを継承するような説明は、こういう勘違いから始まるんだろう。

610:デフォルトの名無しさん
06/10/04 13:24:27
オブジェクト指向の簡単な部分だしか

オブジェクト指向の簡単な部分だしか

だ・し・か

611:デフォルトの名無しさん
06/10/04 13:25:27
誤字脱字するやつってイージーミス多いヘボグラマだろうな・・・・

612:デフォルトの名無しさん
06/10/04 16:52:17
誤字脱字をいちいち指摘する奴って、完ぺき主義者なんだろ？
神経質とも言うか・・・

613:デフォルトの名無しさん
06/10/04 16:53:10
そこに突っ込むしか無いのか？

614:デフォルトの名無しさん
06/10/04 16:58:44
>>612
この神経質はこの板によく出てくるん奴だろう。
どこに行っても友達少ないんだし、ほっとけよ。
リアルでも避けられて、こいつはもう既にうつ病が始まってるんだからさ。

615:デフォルトの名無しさん
06/10/04 17:02:14
>>614
ああそうだな。
うつ病の奴って、迷惑だから早く自殺して欲しいよな…

616:デフォルトの名無しさん
06/10/04 21:50:36
>>612
他人の小さなミスをネチネチ言う奴いるよね
そんな奴って、だいたい嫌な香具師で、スネ夫みたいな感じの香具師

617:デフォルトの名無しさん
06/10/05 02:04:56
オマイラ暇すぎなんだな

とりあえず一片真で濃い

618:デフォルトの名無しさん
06/10/05 18:00:36
誤字脱字の指摘なら、せめて
誤字の部分示してコンパイルエラーと書けば良いのに
単なる指摘しか出来ない奴の頭の構造ってどうなってだろな

619:デフォルトの名無しさん
06/10/05 18:26:10
>>618
何が書いてあるのか読めないのだが？
もう一度書き直してくれ。

620:デフォルトの名無しさん
06/10/06 00:10:07
情報処理技術者試験の問題集にこんなのあったんですが[f]の回答が納得いきません。
問題集の回答には「ヒープ」って書いてあったんですが、

この問題文から読み取れる情報から回答するとすれば「処理系依存」だと思うんですが皆様的にはどうでしょう？

オブジェクト指向プログラミングに関する次の記述中の[a]～[g]に入れる適切な字句を答えよ。

オブジェクト指向プログラミングでは、[a]化の概念を用いて[b]を介してデータを扱う。
これによって、オブジェクト内部の[c]構造に変更があっても、
呼び出し側のプログラムを変更する必要がなく、保守性の向上が期待できる。
スーパークラスで定義した操作をサブクラスで再定義することもできる。これを[d]という。
操作の再定義によって、同じ名前でも違った実装をもつことになる。
実装が異なっても、それを呼び出すプログラムが違いを意識しなくても良いことを[e]という。
プログラムによって生成されるオブジェクトの実体は、[f]領域に確保される。
使用されなくなったオブジェクトの管理をプログラムで行うのは困難なので、
[g]によって領域内の不必要なオブジェクトの整理を行い、領域の再利用を図る言語処理系がある。

621:デフォルトの名無しさん
06/10/06 00:14:50
>>620
過去問から出題したのかなぁ
もし[b]がメンバ関数ならすごくC++臭くて鼻つままないと近寄れねーです

622:デフォルトの名無しさん
06/10/06 03:04:20
カプセル、メソッド、データ、オーバーライド(メルトダウンを起こすやつではない)、
多態、f、ガベージコレクション、かな？

fはスタックの場合もあるよね。

623:デフォルトの名無しさん
06/10/06 05:29:27
Javaはスタックマシンだっけ？

624:デフォルトの名無しさん
06/10/06 06:35:10
JVMならスタックマシンだ。

625:デフォルトの名無しさん
06/10/07 16:38:54
実装の仕方によってヒープ、スタックのどちらもあるうるなら、
それらのスーパークラスであるメモリを答えにすればいいのでは？

626:デフォルトの名無しさん
06/10/07 17:03:40
>>625
実装にばかり気をとられてそこまで気がつかきませんでした。

「プログラムによって生成されるオブジェクトの実体は、[メモリ]領域に確保される。」

なに当たり前のことを言ってるの？的な部分もありますが、
同じ文章が試験に出題されたらこれでいきます。

627:デフォルトの名無しさん
06/10/07 22:04:11
メモリ領域かぁ、なんか収まり悪いな。
コード領域の対してのデータ領域とかはどう？

628:デフォルトの名無しさん
06/10/08 02:50:49
ヒープだろ

629:デフォルトの名無しさん
06/10/08 10:08:52
C++でTestClassという名前のクラスが定義されているとして

foo(){
TestClass class;
TestClass *p_class = new TestClass;
}

前者はスタック、後者はヒープに領域が取られるんじゃなかったっけ？
規格書で動作まで規定されてるかわからんけど。

630:デフォルトの名無しさん
06/10/08 10:34:40
初めてスタックとヒープという言葉を覚えて嬉しくてしょうない厨かな。

631:デフォルトの名無しさん
06/10/08 13:33:59
君はいろんなスレでなんとか厨といい続けてるよな
もう何年にもなるんじゃないか
コテハンを厨厨にすればいいじゃないかな

632:デフォルトの名無しさん
06/10/08 13:54:56
ちゅうちゅうねずみさん＾＾

633:デフォルトの名無しさん
06/10/08 13:59:12
厨厨たこかいなでどう？（なにが？）

634:デフォルトの名無しさん
06/10/09 03:57:23
漏れはてっきり

ヒープ ⊃ スタック

だと思ってたよ

635:デフォルトの名無しさん
06/10/13 23:12:06
かいな様はどうだろう？（なにが？）

636:デフォルトの名無しさん
06/10/20 12:05:52
>>594
それ、オレの大学のコンピュータサイエンスⅠのクラスでまさにやってるとこだよ。
ベーシックしか知らなかった友人Ｃは今クラッシュして苦しんでる。
概念学習より言語学習が先だとおもう

637:デフォルトの名無しさん
06/10/21 20:09:11
だがそういう奴が仕事ができる。

638:デフォルトの名無しさん
06/10/22 04:05:03
>>1
言語を習得したらその言語で書かれたサンプルを読みまくり、自分でもコードを書いてみる。
そうすればオブジェクト指向の考え方も自然と身に付く。
オブジェクト指向の概念本はやたら話の内容を大きくしてるだけの糞本が多いので要注意。

639:デフォルトの名無しさん
06/10/22 05:46:57
問題はオブジェクト指向を使えるかどうかよりも
でかいプロジェクトを自分で設計出来るかどうか、

640:デフォルトの名無しさん
06/10/22 08:44:38
>>639
でかいプロジェクトを設計出来る
　・OOは心強い武器になる
　・近頃はOO分析とか言われてる
　→OO使える
> 問題はオブジェクト指向を使えるかどうかよりも
少なくとも、オブジェクト指向は使えなきゃ困る

/*
…てかOOなんて”指向”だから、思想と同じ意味だよ！
そんなに神聖化する必要なんて無いんだよ！
って言いたかっただけです
*/

641:デフォルトの名無しさん
06/10/22 10:24:48
自分もずっとVB厨だったけどC#に初めて入ったときは感動した。
ソースの可読性がよく、とてもこざっぱりしていて。

もともとVBやってたときも、exe開発はせず、ほとんどdll開発。
データ取得クラスを作って、
普通にvb5.0のときから、そのクラスをnewして、プロパティをセットして
get（）メソッドでデータ取得。

みたいなことをしていた。
おそらくそれ作ったのがC上がりの人だったのかもしれないが。

今思うとサーバにｄｌｌを配置して、各画面のｅｘｅをクリックしたと同時に
サーバのdllとクライアントのdllのバージョンを比較し、新しくなっていたら、サーバから取り直す、という
処理も入れていた。

そんなことを３年間やって客先とか出向いたりいろいろしていて、いざ次にVBやりましょう、と他のプロジェクトに入ったとき
非常にわかりづらかった。
その後javaをへてC#に入ったけど、実は今とってもピッタンコと思える言語をみつけてうれしくなってる。

642:デフォルトの名無しさん
06/10/24 01:53:59
>>641
そういう奴なら暇が出来たら関数型言語とか弄ってみな
すげえおもしれえよ

643:デフォルトの名無しさん
06/10/26 13:13:33
C#なんてウンコだからJavaをやってみなよ。感動する。

644:デフォルトの名無しさん
06/10/26 13:23:33
Javaなぁ・・
あれはもうダメだ。

645:デフォルトの名無しさん
06/10/26 22:33:19
Javaは言語仕様よりも、周辺のクラスライブラリが評価の対象になってるからなぁ
言語仕様事態はとくに面白くもなく、醜いわけでもなく・・・

646:デフォルトの名無しさん
06/10/26 22:55:00
>>645 とすると、C#も話がだいぶ近いが、C#はどう思う？

647:デフォルトの名無しさん
06/10/26 23:06:54
>>646
横レスするけど、Java と違って野良フレームワークがあまり無いから
楽なような気がする。あとMSが勝手にガンガン突っ走るんでJavaより
ダイナミックで面白いよね。2.0 だの 3.0 だの。

648:デフォルトの名無しさん
06/10/26 23:16:09
>>647
Javaは携帯やサーバー用途に広がったけど、
C#はいくら面白くてもWindows関係だけでは？
突っ走っていてもMSやC#は一体何がしたいんだろう？
そこが明確じゃないからC#よりJavaに流れるのかもしれない。

649:デフォルトの名無しさん
06/10/26 23:19:33
Windows のデスクトップアプリを作ってね！

650:デフォルトの名無しさん
06/10/26 23:22:03
Java最高！

651:デフォルトの名無しさん
06/10/26 23:22:22
まぁそうなんだけどその「Windowsだけ」の部分もかなりのボリュームがあるわけで。
（漏れはPC用のソフト作る会社で働いてるから、かなりバイアスがかかってる）

652:デフォルトの名無しさん
06/10/26 23:24:11
>>645
Javaの言語仕様をじっくりみていくとその奇怪さがよくわかるよ

653:デフォルトの名無しさん
06/10/26 23:28:49
>>652
ｋｗｓｋ

654:デフォルトの名無しさん
06/10/26 23:29:03
>>652 を？　たとえばどんな所が？

655:デフォルトの名無しさん
06/10/26 23:51:06
>>651
具体的に言えば、Windowsのさらに.Netのところのみってこと。
いまだに世界は狭いよね。
結果は同じだし、それよりもJavaの方に目が向いてしまうもんじゃないか。

656:デフォルトの名無しさん
06/10/26 23:57:11
並行にという概念がないのんかこの＞１は
なんでどっちかが先に生まれないいかんねん。同時に生んだらええねん

657:デフォルトの名無しさん
06/10/27 00:00:09
>>653
>>654
いやね、↓の本をちょっと娯楽で読んでいたらJavaって変だなぁって改めて思わされたから。
URLﾘﾝｸ(www.amazon.co.jp)

658:デフォルトの名無しさん
06/10/27 01:10:48
とりたててJavaが変なんじゃなくて、
プログラミング言語って人が普通に生活する感覚からは大きく外れてるよね
って感じな。

659:デフォルトの名無しさん
06/10/27 08:08:48
>>657
もしC++で同じような本があったら10倍くらいの厚さになるだろうなｗ

660:デフォルトの名無しさん
06/10/27 10:59:39
>>657
BASICは５～６倍でC言語でも３倍位の厚さになるな。
その位Javaはシンプル

Windowsの特定のバージョンのC言語だけやってると気が付かないと思うけど
良い意味でMSに囲いこまれてるってだけ

661:デフォルトの名無しさん
06/10/27 11:08:21
>>660
> BASICは５～６倍でC言語でも３倍位の厚さになるな。
納得できる定義ではない

よって
> その位Javaはシンプル
の帰結は論理的ではない

と言ってみる

662:デフォルトの名無しさん
06/10/27 11:15:55
Schemeなんかは、M式無くした事で多少変なところも出てきたけど、おおむねきれいなんじゃない？

663:デフォルトの名無しさん
06/10/27 11:19:24
>>660
古典言語を引き合いにだしたら、そりゃ変なところもあるでしょうよ。

664:デフォルトの名無しさん
06/10/27 15:35:59
C#は変態的キモヲタ専用言語か。Javaは爽やかな一般人用で。

665:デフォルトの名無しさん
06/10/27 15:53:47
C#のどこがキモイの？

666:デフォルトの名無しさん
06/10/28 14:08:05
#って表記からしてキモイ #って何#って

667:デフォルトの名無しさん
06/10/28 14:16:25
MSにネーミングセンスをもとめちゃいかんよ
彼らはわざわざ検索しにくい言葉を使うのが習性らしい
.Net、Word、.doc....実に迷惑千万だろ

668:デフォルトの名無しさん
06/10/28 14:42:48
#=++　++

669:デフォルトの名無しさん
06/10/28 17:45:27
#=ちょっとしか進化してないという感じがしてキモい、というか情けない。

670:デフォルトの名無しさん
06/10/28 18:09:18
半音上がる程度ですから、

671:デフォルトの名無しさん
06/10/28 20:13:40
おまえら、#ごときで何を盛り上がって・・

672:デフォルトの名無しさん
06/10/28 21:19:37
使う人間が♭、それがC#。

673:デフォルトの名無しさん
06/10/28 21:36:16
>667
「COM」を追加。

674:デフォルトの名無しさん
06/10/28 23:05:58
2 名前：仕様書無しさん投稿日：2006/10/28(土) 12:51:58
関連リンク

哲学者ならばプログラム言語を勉強したまえ
ｽﾚﾘﾝｸ(philo板)

675:デフォルトの名無しさん
06/10/29 21:30:21
>>673
Windowsも追加しといてー

676:デフォルトの名無しさん
06/11/06 11:36:22
>>667 >>673 >>675
おまいらSOAPを忘れてる

677:デフォルトの名無しさん
06/11/06 15:10:56
拡張子.doc はどうよ

678:デフォルトの名無しさん
06/12/14 03:24:41
Rっていう統計ソフトには勝てまい

679:デフォルトの名無しさん
06/12/25 07:17:48
あげ

680:デフォルトの名無しさん
06/12/26 04:21:52
S でゲーム作ってた使途がいたなぁ

681:デフォルトの名無しさん
06/12/26 05:55:05
>>664
Javaのどこにさわやかなイメージがあるんだ？
携帯アプリ製作現場しか思い浮かばんぞ？

682:デフォルトの名無しさん
06/12/26 19:34:45
NetScape

683:ココ電球（∩T∀T)　 ◆tIS/.aX84.
06/12/26 19:36:21
オブジェクト指向逝ってよし

684:デフォルトの名無しさん
06/12/30 02:18:49
何でこんなところにココ電がｗｗ

685:ココ電球（∩T∀T)　 ◆tIS/.aX84.
06/12/31 11:46:12
昔は逝ってよしの１というコテだった。

話は変わるが、会社でオブジェクト指向信者がサーバーに負担かけまくって
しばしばDB飛ばしてたのがいたが、首になったらしい。

686:ココ電球（∩T∀T)　 ◆tIS/.aX84.
06/12/31 11:48:53
たまんねえぜ。
こっちがチューニングで爪に火を灯すようにサーバーの負荷減らしてるのによお。
ドッカーンと、こっちがチューニングで減らした量の１００倍くらいの負荷作っちゃうからな。
示威行為なんだよな。
まったく信者ってやつは。

687:デフォルトの名無しさん
06/12/31 14:12:50
とりあえずNG登録まで読んだ

688:デフォルトの名無しさん
07/01/19 23:06:21
まず

オブジェクト指向における再利用と、関数による再利用

の違いを教えてくれ。

689:デフォルトの名無しさん
07/01/19 23:55:50
無い

690:デフォルトの名無しさん
07/01/20 00:46:15
オブジェクト指向のオブジェクトの概念は型理論で説明できる。

691:デフォルトの名無しさん
07/01/20 00:52:14
それは無い

692:デフォルトの名無しさん
07/01/20 00:52:45
関数もオブジェクト

693:デフォルトの名無しさん
07/01/20 00:57:37
オブジェクトも関数

694:デフォルトの名無しさん
07/01/20 01:18:46
>>691
検索してみろ

695:デフォルトの名無しさん
07/01/20 02:25:43
>>694
FJ　のことか？

696:デフォルトの名無しさん
07/01/20 03:21:36
「哺乳類を継承して犬と猫を作り、『鳴く』というメッセージを送ると犬なら『わん』、猫なら『にゃあ』と鳴く」

これがオブジェクト指向か？

697:デフォルトの名無しさん
07/01/20 08:35:09
>>696
その通り

698:ココ電球（∩T∀T)　 ◆tIS/.aX84.
07/01/20 09:42:36
「わん」とか「にゃあ」の音はモノじゃないのでオブジェクト指向で扱えませんね

699:デフォルトの名無しさん
07/01/20 11:08:26
は？

700:デフォルトの名無しさん
07/01/20 11:16:09
>698
class 音

701:デフォルトの名無しさん
07/01/20 11:42:28
>>698
わんクラス

　class 犬 interface　吠えるく{

　　鳴き声　bark（）{

　　　　return new わん（）；
　　}
}

702:デフォルトの名無しさん
07/01/20 11:44:17
>>698
オブジェクト指向で表現できないものは無いｗ
あほちゃうかｗ

703:デフォルトの名無しさん
07/01/20 12:14:34
まあ、オブジェクトは貧乏人のクロージャだしね。

704:ココ電球（∩T∀T)　 ◆tIS/.aX84.
07/01/20 12:26:51
インターフェイスもオブジェクトにできませんねえ

705:デフォルトの名無しさん
07/01/20 12:35:42
視野が狭い

706:ココ電球（∩T∀T)　 ◆tIS/.aX84.
07/01/20 12:51:10
犬とか猫はあつかえても高度な抽象的概念はあつかえませんね。

ハングルが世界最高の言語だって言ってる連中と同列ですね。

707:ココ電球（∩T∀T)　 ◆tIS/.aX84.
07/01/20 12:51:35
犬とか猫はあつかえても高度な抽象的概念はあつかえませんね。

ハングルが世界最高の言語だって言ってる連中と同列ですね。

708:デフォルトの名無しさん
07/01/20 13:03:45
マトモな頭を持った人間なら、Cなどの構造化言語をある程度使い
こなせるようになったら、OOP的なアプローチでロジックを組めば
綺麗に効率よくコーディングできることに気が付くはずだ。
（たとえそれがOOPとして既に広く周知されたものだと知らなくても）

そこでC++などを勉強すれば、綺麗で効率の良いスタイルのコードを
自然に書けて、さらに補強する機能があることは自然と受け入れら
れるはず。

要するに、概念学習なんて自然と思いついて然るべきもので、
わざわざ他人から教えられるようなものではない。
概念学習で苦労しているのは低脳。つーかマ向きの人間じゃない。

709:デフォルトの名無しさん
07/01/20 13:14:27
>702
流石に「表現」するには厳しいモノも無くはないだろう。OOが万能とは思わない。
それまでのプログラミングより表現の幅は大きいと思うけど。

710:デフォルトの名無しさん
07/01/20 13:23:45
オブジェクト指向狂詩曲って本で大体は理解した。

711:デフォルトの名無しさん
07/01/20 13:53:50
>>708
>要するに、概念学習なんて自然と思いついて然るべきもので、
>わざわざ他人から教えられるようなものではない。

どちらが効率的かということだろ。既に他人が知っていることを
わざわざ自分で再発見する必要はないと思うけどね。他人が考え
てくれたものはありがたくさっさと学んだ方がよほど効率的で
いいと思わないか？

712:デフォルトの名無しさん
07/01/20 15:11:42
最近まで、オブジェクト指向言語の
メリットが見出せなかった。

使えないとか、理解できないとかではなくて
非手続き型で十分じゃね？って感じで

でも.netやらJAVA系のエディタは便利だな
まあ、オブジェクト指向開発は
ツールありきってことかな

713:デフォルトの名無しさん
07/01/20 15:15:55
まあ、言いたい事はアレだ

ソースのインデント萌え～ってことよ。

714:デフォルトの名無しさん
07/01/20 16:22:42
>>706
扱えないと思うヤツには扱えない
オブジェクト指向は難しいと思うヤツには難しい

715:デフォルトの名無しさん
07/01/20 16:25:46
これはバイナリデータである、という抽象化すら出来ない奴がいるから困る。
データ毎に処理を分けるなよと思ったところで、がちがちの密結合でThe END

716:デフォルトの名無しさん
07/01/20 16:34:44
>>708
クラス＝構造化された単位
だったらそうなるがそれじゃただの機能分割だｗ
クラスが共通関数のまとめ役って言う考えはＯＯ的ではない

717:デフォルトの名無しさん
07/01/20 16:46:01
>>716

クラス＝関連の強いデータと関数の塊と言うのは十分OO的
OOと言うのは結局、効率的な機能分割法にすぎない。

718:デフォルトの名無しさん
07/01/20 16:47:57
>>717
初期のＯＯの考え方に近いか
ただ、クラス＝役割だ

719:デフォルトの名無しさん
07/01/20 16:50:45
概念的はなっそうが出来てないと単なる機能分割で終わってしまって
クラスが単なる空間定義に終わってしまっているという良い例だなぁｗ
クラスは空間定義ではあるが、ＯＯ的というにはそれだけではたりない。

720:デフォルトの名無しさん
07/01/20 16:51:36
>>719
×概念的はなっそう
○概念的なアプローチ

721:デフォルトの名無しさん
07/01/20 17:00:47
>>719

それでは、その足りない部分を具体的に述べてくれ。

722:デフォルトの名無しさん
07/01/20 17:02:19
>>721
役割、意味論

723:デフォルトの名無しさん
07/01/20 17:04:02
>>722

分割時に当然、役割、意味単位で分けるが
それじゃ駄目なん？

724:デフォルトの名無しさん
07/01/20 17:07:32
役割は機能的な役割という意味ではない。
実社会における役割と等価。
意味論も機能的な意味論ではない。
実社会における意味論と等価。
構造化アプローチで設計していくとソコは必ずしも一致しない。
ただ、構造化＝役割の細分化という意味なら同意できるなぁ。

725:デフォルトの名無しさん
07/01/20 17:11:42
実社会という言葉は少々極端ではあるが。

726:デフォルトの名無しさん
07/01/20 17:12:12
>>724

すまんが、機能的な意味と役割と
実社会における意味と役割とが
解離してる。例をあげてくれないか？

727:デフォルトの名無しさん
07/01/20 17:29:38
>>726
実社会という言葉は適切ではなかったｗ

要するに、手続きからクラスを定義するのと
要件からクラスを定義するのでは、クラスの作られ方が違ってくるってこと。

ただそれもレベルの問題で、旨くできる人はそれでもうまくクラスが作れているから
厳密な違いは無いと思うけど、旨くない人が手続きからクラスを導出していくと
クラスのインターフェイスが違ってくる。

例）ある業務のシステムを作っています。

【手続き型の構造化手法】

手続きＡからクラスＢを導出しました。
その場合、クラスＢは多かれ少なかれ手続きＢに特化する。

後から手続きＣでもクラスＢが持つデータを使うことがわかりました。
でも、クラスＢのインターフェイスは手続きＢようなので、手続きＣ用のインターフェイスを
作りました。

【ＯＯ的手法】
業務の役割や意味からクラスＢを導出しました。
クラスＢには、業務を実行するインターフェイスＤがありました。
業務の手続きＡ、ＣはクラスＢのインターフェイスＤを使うように実装する事にしました。

728:デフォルトの名無しさん
07/01/20 17:40:24
>>727

ありがとう、なんとなくわかった、しかし
そういう話なら、もっと以前の構造化プログラムの
モジュールでも同じだと思うけど、モジュールBが手続きA、C
どちらでも、そのまま使えるような設計が構造化でも
良い設計のはず。

729:デフォルトの名無しさん
07/01/20 18:56:56
>>728
構造化とＯＯの決定的な違いは抽象化

730:デフォルトの名無しさん
07/01/20 18:57:59
まさかここまで引っ張ってきておいて
構造化がオブジェクト指向特有の手法だと思ってたとかいうオチじゃないよね・・・？

731:デフォルトの名無しさん
07/01/20 19:07:29
構造化でもクラスを作ることは出来る
だがそれだけでＯＯとはいえない

732:デフォルトの名無しさん
07/01/20 19:08:56
>>729

抽象化すれば、問題ないの？
なら、機能分割時に、役割に応じて
共通部分を親抽象クラスなりインターフェイス（Javaなもんで）
なり抽出して作成すればOK？

733:デフォルトの名無しさん
07/01/20 19:10:50
すまん。わんとかにゃあで説明してくれ。

734:デフォルトの名無しさん
07/01/20 19:12:12
>>732
手っ取り早くはデザインパターンとかを勉強してみるといいんじゃない？

735:デフォルトの名無しさん
07/01/20 19:20:55
>>734

デザパタは、実務で使ってるよ。
TemplateMethodとかVisitorとかFactoriyMeyhodとか、
良く使う。

736:デフォルトの名無しさん
07/01/20 19:39:04
ぶっちゃけ、デザパタとかクラスの動きとか、
実務レベルの話は、それなりにわかるんだが
その上のOO道みたいな、哲学的な部分がさっぱりわからん。

737:デフォルトの名無しさん
07/01/20 19:45:18
>>736
変に構えなくても良いんじゃね？
しょせん継承・カプセル化・情報隠蔽が出来てりゃ　C++　では　OO　なんだし。

738:デフォルトの名無しさん
07/01/20 19:52:20
>>737

やっぱり、構えなくて良いんかね。

でも、OO的で無いとか観念的なアプローチをしろとか
言われたんで気になってね。

739:デフォルトの名無しさん
07/01/20 19:55:02
ファイルから/データを読み込んで/パースして/溜めておいて/次の日になったら/配信する
File　　　　　　Input　　　　　　　　　　Parse　　　　Queue　　　　Timer　　　　　　　　Output

言葉と実装とでE-Rが変わらないようにすると管理しやすいんだよね。
OOに慣れると疎結合を意識しだす嬉しい恩恵も得られる。

C言語使ってるときでもOOは意識するもんだけどね。

740:デフォルトの名無しさん
07/01/20 20:13:30
>>727
図に描いてみたけど上の構造化手法の例の問題点がよく分からん
URLﾘﾝｸ(www.borujoa.org)

741:デフォルトの名無しさん
07/01/20 20:15:43
>>740
何でデータが手続きを参照してるの？ｗ

742:デフォルトの名無しさん
07/01/20 20:22:17
>>741
構造化手法からオブジェクトを導出するならこんな感じになるのかなってのを
想像して図にしてみただけだよ。
その矢印はデータの流れを表してると考えてくれ。

743:デフォルトの名無しさん
07/01/20 20:52:55
なんで構造化手法からＯＯで言うところのオブジェクトを導出しようとするのかがわからん

>>727の問題点は、本来１つですむインターフェイスが手続きごとに複数実装しなければならんて事。
共通的に使われるものが、個別の要件に応じてインターフェイスを変更するのはおかしいんでは？

744:デフォルトの名無しさん
07/01/20 21:05:28
データが同じなら１つのクラスでメソッドで処理を分けるのがオブジェクト指向的にも
普通の設計だと思うけど、>>727の説明は何が言いたいのか理解しづらい。

745:デフォルトの名無しさん
07/01/20 21:13:12
>>744
＞データが同じなら１つのクラスでメソッドで処理を分けるのがオブジェクト指向的にも・・・
データとは？
この時点でＯＯではない
そういうのがわからないから概念から学ぶべきだといっている
ただ、判らないからといって実務で直接的に問題になるか？っと言われれば、状況による。
どんなに生産性が悪くても、それで成り立ってれば問題はないのでは？

746:デフォルトの名無しさん
07/01/20 21:15:16
ただ概念から・・・っといっても、実際には何らかの言語を通さない事には把握しにくいのも事実
両方同時に
がいいのでは？

747:デフォルトの名無しさん
07/01/20 21:25:14
>>745
IntegerやStringから、List、HttpRequest、Bitmap、Window、、、、。
世の中にはデータみたいなオブジェクトが腐るほど溢れてるけど、これらはOOじゃないのか？

748:デフォルトの名無しさん
07/01/20 21:29:41
いいからオブジェクト指向とは？から勉強しなさいな

749:デフォルトの名無しさん
07/01/20 21:30:51
>>748
分からないから説明してよ。あなた自身の言葉で。

750:デフォルトの名無しさん
07/01/20 21:32:03
データは全てオブジェクト。オブジェクトじゃないものなど存在しない。
intもオブジェクト、言語仕様に振り回されるな。

751:デフォルトの名無しさん
07/01/20 21:36:15
違う。オブジェクトであると定義した時点で、はじめて『それ』はオブジェクトになる。

752:デフォルトの名無しさん
07/01/20 21:41:43
ならintはオブジェクトだろ？

753:デフォルトの名無しさん
07/01/20 21:43:08
int　をオブジェクトと定義すれば　int　はオブジェクト
オブジェクトではないと定義すれば　int　はオブジェクトではない

754:デフォルトの名無しさん
07/01/20 21:43:45
オブジェクト指向は人を選ぶから、無理にわかろうとする必要は無い

755:デフォルトの名無しさん
07/01/20 21:43:46
言葉遊びに酔ってるだけの馬鹿だったか、邪魔したな。

756:デフォルトの名無しさん
07/01/20 21:44:41
自明なことすら分かってもらえないのか……(　´ー｀)y-~~

757:デフォルトの名無しさん
07/01/20 21:48:11
intはオブジェクトではないと定義したオブジェクトの参照をintは持つわけだ。

758:デフォルトの名無しさん
07/01/20 21:52:26
やはり言語から入ると、言語で表現できる範囲でしか物を考えられなくなるから
オブジェクト指向の学習としては概念中心に行うべきか？

759:デフォルトの名無しさん
07/01/20 21:58:16
観念論が役に立たないのは、
ここの、やりとりを見れば自明かと。
大体明確な解すらないのだから、
学者が研究でやれば良いレベル初心者には、まったく必要ない

760:デフォルトの名無しさん
07/01/20 21:58:45
モダン言語はプリミティブ型にもclassがある。
Javaですらint.classが存在する。ちなみにInteger.classとは別物。

761:デフォルトの名無しさん
07/01/20 22:11:04
>>759
そうそう
で、そういう奴らは指示されたようにコーディングだけしてれば良いのだｗ

762:デフォルトの名無しさん
07/01/20 22:15:45
概念論が役に立たない奴には元から概念がないだけというオチ。
OOは文系のための言語という考えがあるが、あながち間違っていない。

763:デフォルトの名無しさん
07/01/20 22:33:45
その前に日本語をきちんと学ぶこと。
プログラムが書けない奴は日本語もダメ。
もちろん、日本人の話なw

764:740
07/01/20 22:48:38
また懲りずに図を描いてみた。今度は構造化手法のDFDでスタックを表現した。
こうやって見るとオブジェクト指向っぽく見えない？
URLﾘﾝｸ(www.borujoa.org)

765:デフォルトの名無しさん
07/01/20 22:58:15
オレはＣ言語やＣＯＢＯＬしかやったことの無いメンバーしかいないチームで、
Ｃ＋＋やＪａｖａの開発を一緒にやったりする経験が多くあるが、オブジェクト
指向に背を向けている人は最後まで理解する事はできなかったね
結局その人たちは元の古巣へもどって逝ったよ。

766:デフォルトの名無しさん
07/01/20 23:04:49
>>765

それは、やる気や適正の問題で観念学習をしてないからじゃ
無いでしょう？俺の経験では言語学習だけで、使いものになる人は
いても、観念学習だけでまともな設計ができる様になった人は
見たことないな。

767:デフォルトの名無しさん
07/01/20 23:12:17
>>766
ちがう
言語は覚えようとしていた
だが概念を覚えようとはしなかった
だから結局何がなんだかわからなくて挫折した
概念がわからない状態でＯＯＰＬ使って作ったプログラムは
ただの手続き型プログラムだろ
Ｊａｖａを使ってＣ言語や、ＣＯＢＯＬを書こうとしているだけ

768:デフォルトの名無しさん
07/01/20 23:14:41
何らかのプログラムを書けるようになるためには概念はイラン
期限付きで結果を出さなきゃならないような状況では、
形はともかく動くものが出来ればいいからな
ただそれはオブジェクト指向技術を使って開発したプログラムではない

769:デフォルトの名無しさん
07/01/20 23:18:41
>>767

継承も、カプセル化・隠蔽もきちんと使ってたぜ
どのあたりがOOじゃ無いのか、さっぱりわからないんだが
OOの条件を書いてもらえないか？

770:デフォルトの名無しさん
07/01/20 23:20:18
>>769
＞継承も、カプセル化・隠蔽もきちんと使ってたぜ
っていうかその人は概念を持っているんじゃないの？

次ページ