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

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

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
＞継承も、カプセル化・隠蔽もきちんと使ってたぜ
っていうかその人は概念を持っているんじゃないの？

771:デフォルトの名無しさん
07/01/20 23:21:23
>>769
っていうか、オレが見た人をおまいが知ってるんかよｗ

772:デフォルトの名無しさん
07/01/20 23:24:55
大体において、物事に理解度には個人差があるからなぁ
概念を特別に勉強しなくたって自然と習得できる人もいるだろうし、
そうでない人もいるだろうねぇ
特定の人間が出来るからって万人が出来るとは限らん。

773:デフォルトの名無しさん
07/01/20 23:27:21
>>770

コードを書く上での観念だけだよ。
OOの哲学なんてのは、まったく教えてない。
不必要な情報は出さない。同じ役割の物は、
抽象クラスを作ってインターフェイスを同じにする。
書き方が違うだけで、構造化でも同じだと言ってたよ。

774:デフォルトの名無しさん
07/01/20 23:28:23
例えば俺はポインタの概念に戸惑いなどまったくなかったが
同じくC言語に熟練した同僚と違いOOPにも戸惑わなかった。
何に違いがあるのか考えてみると、
俺は普段からそういう思考で過ごしているからだという結論に落ち着いた。

言語適正＝生活習慣。これだね。

775:デフォルトの名無しさん
07/01/20 23:32:57
>>773
オレもＣとかＣＯＢＯＬしかやったことの無い人にはそう教えるよ

776:デフォルトの名無しさん
07/01/20 23:35:09
つい極論に走ってしまったが、
言語学習と言うか実際にコード書かせて学習させるのが
一番だと思う。良いコードを見せてこうやったほうが安全とか
便利とか、実例で学ばせてゆく、英語とかでも文法いくらやっても
話せる様にはならないじゃん

777:デフォルトの名無しさん
07/01/20 23:35:54
大体、手続き型の言語しかやったことの無い人が、すんなりＪａｖａとか出来るようになるか？
そんなの見たこと無いけどな。

778:デフォルトの名無しさん
07/01/20 23:38:08
>>776
なぜソコでクラスを分ける必要があるのか？とか
そういう素朴な疑問にはどうやって答えるの？
概念の説明無しで

779:デフォルトの名無しさん
07/01/20 23:40:22
クラスとは物凄く小さな単位のライブラリ。
最初はこれくらいで教えておくのが楽。

780:デフォルトの名無しさん
07/01/20 23:43:46
>>777

Cやってた人は、早い場合は異様に早いよ
３日もしない内に、実務で使ってみたいから、
適当な仕事無い？とか聞いてくる

まぁ、それで頼んだ結果をみると、
Cのヘッダみたいな定数クラスがあったり
ツッコミ何処それなりにあったりするけど。
動くことはキチンと動く

781:デフォルトの名無しさん
07/01/20 23:46:03
言語仕様だけならテンプレートまでで1週間で覚えられるんじゃね？

782:デフォルトの名無しさん
07/01/20 23:46:04
それでオブジェクト指向が理解できるの？
プログラムが書けるようになるだけなのでは？

783:デフォルトの名無しさん
07/01/20 23:47:39
このスレの趣旨って、オブジェクト指向を学習するにはどうすべきか？っていうことでしょ？ｗ
プログラムが書けるようになることがゴールじゃないだろｗ
スレ違いもいいところｗ

784:デフォルトの名無しさん
07/01/20 23:48:19
>>782

オブジェクト指向が理解できてると言える条件を
教えてもらわないと、なんとも言えない。

785:デフォルトの名無しさん
07/01/20 23:50:49
>>784が言いたい事は、

>>784自信はオブジェクト指向が理解できてて、
それはプログラムが書けさえすれば達成できるものだ、

という理解でいいの？

786:デフォルトの名無しさん
07/01/20 23:56:59
>>785

微妙に違う、オブジェクト指向の理解できてるかどうか
なんかは誰にもわからない。ので実質、
保守性の生産性が高い設計、及び、プログラムが書ける事のみが
重要と言いたい

787:デフォルトの名無しさん
07/01/20 23:58:10
>>784
基準といえるか判らんが、
デザインパターンの知識が無くて設計しても、デザインパターンにマッチした設計が出来るようなら
割とオブジェクト指向を理解しているといえるのでは？

788:デフォルトの名無しさん
07/01/20 23:59:39
>>786
だがそれはスレの趣旨とあってないだろ？

789:デフォルトの名無しさん
07/01/21 00:03:27
構造体があるクラスのメンバの参照をもったりしなければおおむねOOPは成功してる。

790:デフォルトの名無しさん
07/01/21 00:04:44
そういうもんだいじゃないんじゃ・・・・

791:デフォルトの名無しさん
07/01/21 00:09:49
>>787

デザパタ＝OOなのか？
それこそ実装よりの技術でOOの概念とは違う気がするが

それはともかく教えれば、適切に使う様になる
場合が多いけど、教えずに使ってるのは、無いかも
TemplateとかVisitorとかは、継承の説明で教えちゃうしなぁ
これは、実装の話だから、設計だとどうだろうな、
実装おしえてから設計教えるからわからん。

792:デフォルトの名無しさん
07/01/21 00:11:15
あと、オブジェクト指向の理解度を測る基準としては、メトリクスも使えるか？

１クラスはpublicメソッド数が１０個以内
１メソッドのコード行数が１００行以内
１クラスの行数が２００行以内

この条件でプログラムを作れるかどうか？

793:デフォルトの名無しさん
07/01/21 00:17:06
>>791
デザインパターンは役割の関係の雛形
これに近い適切な役割の関係が導出できるかどうかが問題
それには役割自体が適切に割り当てられているか？っという事も含まれてる

794:デフォルトの名無しさん
07/01/21 00:18:29
>>792

本当にそんな実装よりの評価で良いのか。

しかも、その条件で、たぶんOO的で無い
クラスを幾らでも作れるし、設計できるよ。

795:デフォルトの名無しさん
07/01/21 00:22:36
>>793

デザパタが自然に使えてるかと言えば使えてるな。

だいたいデザパタって機能レベルの関係でもつかえるから
このスレ的には、OOとあまり関係ないんじゃないか？

796:デフォルトの名無しさん
07/01/21 00:22:36
>>794
ある側面からの機械的な評価でしかない。
でも、ＯＯ的な考えを持ってない人はこの基準に収まる、”意味のあるプログラム”はかけないと思うね。

797:デフォルトの名無しさん
07/01/21 00:26:14
>>796

そんな事はないぞ、メソッドの長さは、Cでも短い方が良いし
モジュールもそうだから、極論すればCのモジュールを
そのままクラスにしたような物でもとおるよ。

798:デフォルトの名無しさん
07/01/21 00:30:22
それは意味のあるプログラムになるの？

799:デフォルトの名無しさん
07/01/21 00:31:56
ここでいってる”意味”とは、何でそういうクラス構成にしたか？って言う問いに対する答えで、
メトリクスをクリアするため、ってのは問題外ｗ

800:デフォルトの名無しさん
07/01/21 00:35:09
まぁ要するに、オブジェクト指向を理解する＝ＯＯＰＬを理解するってことではないってことは
はっきりしたんじゃないｗ

801:デフォルトの名無しさん
07/01/21 00:35:09
＞１クラスの行数が２００行以内
こんなもんJDKのクラスライブラリだけ見ても該当しないコードだらけやん

802:デフォルトの名無しさん
07/01/21 00:37:07
>>798

モジュールをそのままクラスにしたのだから
機械的にモジュール分割を行わなっていなければ
当然、例えば、ネットアクセスモジュールとか
意味はあるだろう。

>>799

たとえば、上の例だと
ネットアクセスする関数郡って意味はあるよね。

803:デフォルトの名無しさん
07/01/21 00:39:44
>>802
class NetAccessMethods1
class NetAccessMethods2
class NetAccessMethods3

とか作ってそれぞれメソッド１０個ずつ？ｗ

804:デフォルトの名無しさん
07/01/21 00:47:21
>>803

それは、機械的な訳かただから違う

NetAccessToA_Machine
NeTAccessToB_Machine
NetAccessCommon
Aマシンへの、アクセス用
Bマシンへの、アクセス用
上記の共通部分

って感じのモジュール

805:デフォルトの名無しさん
07/01/21 00:48:49
>>804
ｗ

class Connection
class Protocol
class Message

見たいなクラスくらい作って欲しいもんだ

806:デフォルトの名無しさん
07/01/21 00:50:39
あと、Ａｄｒｅｓｓもいるかｗ

807:デフォルトの名無しさん
07/01/21 00:52:00
>>804
このクラス設計を見て、オブジェクト指向を理解しているとはお世辞にもいえんなｗ
申し訳ないけどｗ

808:デフォルトの名無しさん
07/01/21 00:52:31
ゴメン、
理解しているとはいっていなかったね

809:デフォルトの名無しさん
07/01/21 00:53:08
もう寝るぜｗ
おやすみー

810:デフォルトの名無しさん
07/01/21 00:57:21
>>805

だから>>804みたいな明らかに駄目なクラス分けでも
メトリックス通ってしまうよって例だから

811:デフォルトの名無しさん
07/01/21 00:59:53
>>807

日本語ができない人だったのか。
気付かなかったよ。

812:デフォルトの名無しさん
07/01/21 01:06:29
>>810
あそっかｗ
ゴメンよｗ
ホイじゃホントにおやすみー

813:デフォルトの名無しさん
07/01/21 01:09:30
>>812

こちらこそ、眠いとこ煽って悪った

おやすみ

814:デフォルトの名無しさん
07/01/21 08:46:07
ざっと読んで下の童話を思い出しました！
Wikipedia項目ﾘﾝｸ

815:デフォルトの名無しさん
07/01/21 10:58:18
なんだこのｇｄｇｄ？

816:デフォルトの名無しさん
07/01/22 01:13:23
オブジェクト指向言語は、数学で言う集合論の応用といえると思う。

そしてそこから、集合に属するオブジェクト、インスタンスという考え方で
実体を形成してそれらを「扱う」体系を言語化した。

それらに、継承や抽象化などの性質を浮き彫りにして強調することで
「オブジェクト指向」という概念を改めて定義した、ということではない
でしょうか。

817:デフォルトの名無しさん
07/01/22 01:18:25
そういう指向からすると、Staticあるいはsharedなど静的、共有という
Globalメンバー（変数、関数）の方が特異な存在になっていると思う。

それらは型、集合に属するというものの、インスタンスではないから
スーパーな存在、実物存在に対する、神、あるいは法則、あるいは
イデア的な存在となっているため、

「オブジェクト指向」のなかでも「オブジェクト的でない」存在が結局
このStaticでsharedな存在ではないかと。

818:デフォルトの名無しさん
07/01/22 01:24:26
っていうか、言語学習と概念学習のどっちが先か？を考えるスレじゃハゲ

819:デフォルトの名無しさん
07/01/22 02:16:17
神とかイデアとかじゃなくって便利だからだお
staticなものをいちいちインスタンスにするのがバカバカしいからだお

バカは概念にこだわる
かしこいやつは目的を失わず、「言語」を学習する

820:デフォルトの名無しさん
07/01/22 02:22:56

バカは2chの煽りにこだわる
かしこいやつは目的を失わず、「成果」を持ち帰る

821:デフォルトの名無しさん
07/01/22 11:51:54
オブジェクト指向的にトランプの「七並べ」を作るなら

どのようにクラスを定義しますか？
「カード」クラスにはどんなメソッドを定義しますか？
カードを置く時、それはその場所に置けるのか否かの判定を
　どのクラスのどのメソッドで行いますか？
表示するカード絵はどのクラスが保持しますか？

822:デフォルトの名無しさん
07/01/22 12:00:35
カードはクラスにしない

823:デフォルトの名無しさん
07/01/22 12:07:08
オブジェクト指向原理主義者なら、まず作る予定もない花札ゲームのための拡張性を考えて
カードクラスをインターフェースにするところから始めるよ。

824:デフォルトの名無しさん
07/01/22 12:24:43
>>821
自分のもっている本を見ると、Cardクラスは

int getNumber();
int getSuit();
String toString();

の3つ。
ルールクラスがあって、

Card[] findCandidate(Hand hand, Table table);

で置ける場所の候補（トランプのスートとナンバー）を探すようになっている。

825:デフォルトの名無しさん
07/01/22 12:26:03
もしよろしければDで書いていただけませんか？

826:デフォルトの名無しさん
07/01/22 13:11:43
>>823
カードクラスを純粋クラスとしてカードの操作メソッドを定義。
カード絵クラスでカードの絵柄1枚と縦横サイズ等を保持。絵柄の読み込みもこのクラスにさせる。
トランプカードクラスはカードクラスを継承しコピーコンストラクタで裏のカード絵と表のカード絵の2個のカード絵オブジェクトをスートとナンバーと一緒に入力してそれが何のカードかを決める。
トランプカードクラスは入力されたカード絵オブジェクトを実体ではなく参照で保持する（つまりポインタで保持する）。
トランプカード集合クラスでトランプカードの裏の絵と５４枚の表の絵計５５個のカード絵オブジェクトを生成した後５４個のトランプカードオブジェクトを生成する。
七並べゲームクラスはトランプカード集合オブジェクトを保持する。

ってどうよ？

次ページ