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

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

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個のカード絵オブジェクトをスートとナンバーと一緒に入力してそれが何のカードかを決める。
トランプカードクラスは入力されたカード絵オブジェクトを実体ではなく参照で保持する（つまりポインタで保持する）。
トランプカード集合クラスでトランプカードの裏の絵と５４枚の表の絵計５５個のカード絵オブジェクトを生成した後５４個のトランプカードオブジェクトを生成する。
七並べゲームクラスはトランプカード集合オブジェクトを保持する。

ってどうよ？

827:デフォルトの名無しさん
07/01/22 14:18:41
花札は大袈裟な気もするが
トランプゲーム詰め合わせへの路線変更や
絵柄切替機能付けろって仕様追加はありそうだな

828:デフォルトの名無しさん
07/01/22 15:03:10
花札云々は皮肉だろ

829:デフォルトの名無しさん
07/01/22 15:47:02
>>825
D言語は知らない。

オブジェクト指向を習いたいならJavaからした方がいいと思う。
オブジェクト指向系の書籍は、Javaで例を挙げているのが多いから。

自分もRubyを習おうと思って始めたけど、結局Javaの方を先に習得していたし。

830:デフォルトの名無しさん
07/01/22 18:01:34
>>827
なぜかそのトランプゲーム詰め合わせ仕様書にはトランプタワーが入っていたり

さあ物理エンジンを作ろうｗ

831:デフォルトの名無しさん
07/01/22 19:45:05
ム板にしては進みが早いな。

やぱ分け分かんなくなってる奴が多いのか？

832:デフォルトの名無しさん
07/01/22 20:36:43
俺ならトランプカードクラスを派生して
七並べ用トランプカードクラスも作る

833:デフォルトの名無しさん
07/01/22 20:50:46
>>823
標準クラスにも
使い道の分からないのはあるぞ？

834:デフォルトの名無しさん
07/01/22 21:27:54
ISOにカードクラスの標準化を提唱する

835:デフォルトの名無しさん
07/01/22 23:46:24
いきなり実装っぽい考えをしてるところがあかんな
ちゃんとモデリングセーや

836:デフォルトの名無しさん
07/01/23 00:07:37
>>835

そう思うならモデリング例を上げれや。
批判だけなら猿でもできる。

837:デフォルトの名無しさん
07/01/23 17:38:20
>>823
より YAGNI 感を醸すために、トランプと花札を同じコンテナに格納できないように template にするべきだと思う

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

便利といって何でもご都合主義で入れていけばいいならそもそも
オブジェクト指向でなくてもいいということにもなるが

オブジェクト指向であるのにオブジェクト的ならぬ存在に支えてもらわないと、
実際に本当には便利にならない、、

という現実があるのだ、という風にとらえないと、物事の限界や長所と短所
という考え方の意味がなくなる

イデアや普遍法則があっていつでも自由に適用できるようになってないと
不便な現物世界になる、つまり現物は機能的に不全だといえるかもしれない

839:デフォルトの名無しさん
07/01/24 21:44:56
どうでもいいよ

840:デフォルトの名無しさん
07/01/25 21:07:55
C言語でも、関数ポインターと構造体を使えば、クラスを作れるよね？

841:デフォルトの名無しさん
07/01/25 21:21:12
>>840
それがクラスなら、お前がクラスと呼ぶものは全てクラスだよ。

842:デフォルトの名無しさん
07/01/25 21:22:02
>>840
継承どうするんですか？まクラス使いたいのなら、すなおにC#に汁

ところで、住人様方
VBやVC#でさくさくプログラミングしようかなーと思ってるんですが
オブジェクト指向理解してないと、やっぱりプログラミングむりぽですか？

843:デフォルトの名無しさん
07/01/25 21:23:00
>>842
やれんことは無いらしい。
URLﾘﾝｸ(www.sage-p.com)

844:デフォルトの名無しさん
07/01/25 22:38:11
>>841
.> それがクラスなら、お前がクラスと呼ぶものは全てクラスだよ。

　それがクラスなら、プログラムと呼ばれるもの全てクラスだよ。

こっちの方がいいよ。

845:デフォルトの名無しさん
07/01/25 23:04:07
関数ポインターと構造体を使ったものが継承できたらクラスなのか？

846:デフォルトの名無しさん
07/01/25 23:05:38
C++ のクラスのバイナリ構造の事をいってるんだろ？

847:デフォルトの名無しさん
07/01/25 23:31:24
C言語を用いてクラスは実装できる
オブジェクト指向言語はC言語で開発できる
C言語 is King of プログラム言語ｓだ！

848:デフォルトの名無しさん
07/01/25 23:37:43
で？

849:デフォルトの名無しさん
07/01/26 01:36:17
>847
その理論だとアセンブラ最強な件

850:デフォルトの名無しさん
07/01/26 01:40:04
>>849
機械語最強です

851:デフォルトの名無しさん
07/01/26 01:40:36
ほんたまがでてきそう

852:デフォルトの名無しさん
07/01/26 01:43:12
じゃあ貼っておこう
URLﾘﾝｸ(hp.vector.co.jp)

853:デフォルトの名無しさん
07/01/26 01:45:24
>>852
反応すんなほんたま

854:デフォルトの名無しさん
07/01/26 02:32:48
よーわからんのだけど奇介護っつーのはオブジェクト指向でかけるのかい？

855:デフォルトの名無しさん
07/01/26 02:36:48
あたりまえじゃん

856:デフォルトの名無しさん
07/01/26 08:08:50
機械語でかけない物は PCで実行できんからな。

857:デフォルトの名無しさん
07/01/26 08:40:22
>>844
いや、>840 は一応 vtable くらいは用意するつもりなんだろうから。

858:デフォルトの名無しさん
07/01/26 12:23:19
構造化最強

859:デフォルトの名無しさん
07/01/26 16:48:26
オブジェクト指向は、ソース書いてる内に、ほぼ勝手に身に付いていくものでしょｗ
参考書によってはそうでもないけど。

860:デフォルトの名無しさん
07/01/26 21:45:36
だな

861:デフォルトの名無しさん
07/01/26 22:36:24
ほんとかよ。
4000行あるようなクラス書いてないか？
やたらif分がネストしてないか？

862:デフォルトの名無しさん
07/01/26 22:43:21
それでもイーンダヨー

863:デフォルトの名無しさん
07/01/26 22:56:24
>>861
プログラムは内部が糞であっても、要求を満たしてれば合格
逆に内部がどんなに素晴らしくても、要求を満たしていなければ不合格
よって、
4000行あるようなクラスで、且つ、やたらif分がネストしてたとしても
要求を満足していればOK

864:デフォルトの名無しさん
07/01/26 22:57:38
最低だ

865:デフォルトの名無しさん
07/01/26 22:59:03
>>863
こういうセリフはよく職業プログラマが使うが
職業プログラマほど使ってはいけない言葉

866:デフォルトの名無しさん
07/01/26 23:00:44
>>863
そして保守・運用作業が困難な事が目に見えているため、転職。

867:デフォルトの名無しさん
07/01/26 23:07:07
いいや、顧客から言われた。
ついでに、要求を満たしてない物に金は払えない、とも言われた

868:デフォルトの名無しさん
07/01/26 23:08:20
>>867
そんなの当たり前だハゲ

869:デフォルトの名無しさん
07/01/26 23:09:54
マトモに動くもの作れないくせに給料もらってんじゃねーｗ

870:デフォルトの名無しさん
07/01/26 23:11:13
言語がコボルからjavaに変っただけで同じ書き方してる奴多いよなぁ。

クラス名がDF000001とか（ｗ

871:デフォルトの名無しさん
07/01/26 23:19:16
プログラムは要求通りに動いてはいたんだが、なまじっか、慣れてないオブジェクト指向使ったら納期が遅れちまって...
>>863, >>867を言われたってわけよ、納期も大事な要求事項だからな

872:デフォルトの名無しさん
07/01/26 23:21:36
>>871
それは単にお前がオブジェクト指向に慣れていないのが原因なだけでは

873:デフォルトの名無しさん
07/01/26 23:22:46
だいたい、その時になってから勉強を始めようって姿勢がいかんのじゃ

874:デフォルトの名無しさん
07/01/26 23:34:54
>>870
移植作業なんてものはそういうものだ。
読みやすくするのはリファクタリング作業。

875:デフォルトの名無しさん
07/01/26 23:48:25
>>874
構造化設計のままリファクタリングなどできない。

876:デフォルトの名無しさん
07/01/26 23:51:40
そりゃリビルディングの方がいいだろ

877:デフォルトの名無しさん
07/01/26 23:56:39
構造を変更するのはリストラクチャリングっていうんじゃなかったっけ？

878:デフォルトの名無しさん
07/01/26 23:58:34
それがでてこなかったｗ

879:デフォルトの名無しさん
07/01/27 00:00:22
どっちも同じ事だよ。
リストラクチャリングはリファクタリングの部分集合。

880:デフォルトの名無しさん
07/01/27 00:02:35
ここ嫁
URLﾘﾝｸ(capsctrl.que.jp)

881:デフォルトの名無しさん
07/01/27 00:02:53
リストラクチャリングを検索したら政治用語としての方がよく使われるみたいだが、ソフトウェアの世界でも一般的に使うのか？
あまり聞かないねぇ。こういう事はリファクタリングというんだよ。おぼえとけ

882:デフォルトの名無しさん
07/01/27 00:10:26
>>880
要するに、Martin Fowlerは、リファクタリングの粒度の事で言い方を変えたいだけじゃないの？
そんな短絡的な趣味に付き合いたくもない。

883:デフォルトの名無しさん
07/01/27 00:17:47
>>882
あほなの？

884:デフォルトの名無しさん
07/01/27 00:22:35
>>882
まあ、この手の連中は用語作って商売するからな

885:デフォルトの名無しさん
07/01/27 10:57:24
構造化指向からオブジェクト指向に移った方が一番大変そう。
ある意味SUNの陰謀だｗ

886:デフォルトの名無しさん
07/01/27 11:07:39
構造化にもオブジェクト指向言語の機能は有効だと思うが

887:デフォルトの名無しさん
07/01/27 11:13:51
構造化って簡単に言うと、

１．条件分岐と反復文のみを用い、基本的に上から下へと制御が進む
２．類似した処理は関数としてまとめる

だよね？

888:デフォルトの名無しさん
07/01/27 11:24:54
構造化でも、とりあえずDIPさえ満たしていればリファクタリングは可能かな。

889:デフォルトの名無しさん
07/01/27 11:27:53
すまん、俺はオブジェクト指向が確立してからプログラミングはじめたから
実は、構造化指向は参考書の中で聞いたことがあるだけで実際には
あんまり知らない。ただ構造化指向が染み付いた人はオブジェクト指向に脳みそ
切り替えるのは厳しいかな。と

890:デフォルトの名無しさん
07/01/27 11:42:39
>>889
「構造化志向」って何？

いや、
そんな細かな書き間違いの話なんかよりも、
むしろ　>>889　の言う「志向」が、
何を指すのかを聞きたいな。

・・・いやいや、
そんな細かな書き間違いの話なんかよりも、
むしろ　>>889　の言おうとしたであろう「指向」が、
何を指すのかを聞きたいな。

例えば、「オブジェクト指向」でいう「指向」とは何なのか？
とかさ。

891:デフォルトの名無しさん
07/01/27 11:49:26
正直、オブジェクト指向は
「デザインパターン」の一種だと思う。

892:デフォルトの名無しさん
07/01/27 12:06:12
>>891
デザインパターンはオブジェクト指向のサブセットだろ

893:887
07/01/27 12:12:48
だから、オブジェクト指向においても、メソッドは、（２．の関数）の考えに近く、実際の処理
の記述は、（１．制御の流れ）に相当するよね？

オブジェクト指向は主に全体を見通しての設計技法であり、構造化は実際の制御文を書く
ときの技術って感じで、別に相反するものでもないと思うんだけど。

で、構造化しか知らない人は、全体の設計も構造化（制御中心）でしてしまうと。

894:デフォルトの名無しさん
07/01/27 12:14:14
>>892
いや、逆だと思う。

要するに「デサインパターン　has-a　オブジェクト指向」。

GoF　に「オブジェクト・パターン」なんてのが載っていても
全然おかしくないような気がする。

895:デフォルトの名無しさん
07/01/27 12:19:05
>>894
ばかですか？

896:デフォルトの名無しさん
07/01/27 12:33:17
>>895
勘違いしないでほしいが、俺は別に「デサインパターン」が凄い！
なんて思っていない。
あれはプログラミング上で頻出する、枯れたイディオムを羅列したものだ
（ただし形式上、「OOP　による」という条件付、だがね）。

OOP　も所詮は「プログラミング上のイディオム」だよ。

897:デフォルトの名無しさん
07/01/27 12:42:02
>>896
>>895は誰のカキコも読まないただの荒らしだからレスを返さなくてもいいよ

898:デフォルトの名無しさん
07/01/27 12:44:08
っていうか、ほとんどスレの趣旨にあっていない書き込みばかりじゃねーかｗ

899:デフォルトの名無しさん
07/01/27 12:45:40
オブジェクト指向の話だから、合ってない事もない

900:デフォルトの名無しさん
07/01/27 13:48:39
>>893
よくいるんだが、構造化定理と構造化技法がごっちゃになってる。
構造化技法ってのは、特定のパラダイムというよりは、いろんな宣教師が各人勝手なことを吠えてただけに近い（これはオブジェクト指向○○も一緒だけど）。
シンプルな設計をするためのイディオム集みたいなかんじ。
データフローグラムなんてのもあったりして、データ中心の分析設計も構造化時代からあった。
データ + アルゴリズム = プログラムなんてのも構造化時代からのものだし。
モジュール化の話題では、pimpl に似た技法を使っての実装隠蔽の話などもあった。

OOが設計で構造化がコーディングと断絶したものではない。
OOは方針の違う構造化のスーパーセットみたいなもんだ。

901:デフォルトの名無しさん
07/01/27 13:52:10
どうやら、ソフトウェア工学をまともに研究した経験がある人間は俺以外いないようだ。

902:デフォルトの名無しさん
07/01/27 13:55:30
>>901
ああ、そうだな。
それと、現代において
まともなソフトウエア工学なんてものがあると
思っているのもお前だけだよ。

903:デフォルトの名無しさん
07/01/27 14:02:30
（；＾ω＾）

904:デフォルトの名無しさん
07/01/27 14:10:56
>>1
答えを言ってやろう
電子工学の基礎→ディジタル回路→チューリングマシン→コンピュータの仕組み→機械語→アセンブラ→C言語→構造化設計→Pascal→C++→オブジェクト指向設計技法→Java→Lispと平行してラムダ計算を勉強→MLと平行してコンパイラを設計→Haskell

905:デフォルトの名無しさん
07/01/27 14:22:36
工学というよりは数学に近い。
つきつめれば最も実践的な宗教かな。
一つの世界観を創造してしかもそれを実装しているんだから。

906:デフォルトの名無しさん
07/01/27 17:42:14
要するにオブジェクト指向についていけていないコボラーが
オブジェクト指向＝構造化にしたいってことを言いたいスレに変ったって事か

907:デフォルトの名無しさん
07/01/27 18:00:15
>>904
算数→数学→物理→量子→電気→電子工学の基礎→ …

908:デフォルトの名無しさん
07/01/27 18:19:34
→情報理論→.......→宗教論→カルト宗教に入信→

909:デフォルトの名無しさん
07/01/27 18:29:50
>>887
構造主義って哲学が大流行した時代があって、哲学以外の分野でも新しい概念や
手法の頭に「構造化～」って言葉をとりあえず付けるのが流行ってたってだけで、
お前さんのいうダイクストラの構造化プログラミングとはまったく関係ないよ。

910:デフォルトの名無しさん
07/01/28 15:23:38
ダイクストラは
「類似した処理は関数としてまとめる」
なんてことは言っていない。
あえて換言すれば
「全論理を構造化する」
かと

911:デフォルトの名無しさん
07/01/28 17:03:47
ほにゃああ
へっけんろぴゅろぴゅ～

あわ～
へっけんあわ～

912:デフォルトの名無しさん
07/01/28 22:33:57
↑鬼才現る

913:デフォルトの名無しさん
07/01/30 01:05:35
こんなの見つけた。

「オブジェクト指向の概念の発明者は誰ですか？」
URLﾘﾝｸ(d.hatena.ne.jp)

3番目のクックのオブジェクト指向に興味があるんだが、
いまいち理解できずorz

914:デフォルトの名無しさん
07/01/30 09:35:35

おまえのせいじゃないから
原文を当たった方がいいよ
引用者が日本語を扱うのが下手だとしか思えん

↓

抽象データ型が「型」による抽象化なのに対して、
オブジェクト指向は「手続き」によりそれを行なう対極の手法
（つまり“2”のオブジェクト指向の言うところとは違い、
両者はサブセット／スーパーセットの関係にはない）と位置づけていて興味深いです。
この文脈においては、もし“オブジェクト指向”したいと思うならば、
けっして this（や、self）の型を見て条件分岐をするような仮想関数
（や、メソッド）を書いてはいけない…ということが、よりはっきりと認識できるはずです。

915:デフォルトの名無しさん
07/01/30 13:02:58
>>913
>>914 の言うように論文を当たるのがベストだけれど、端的には…

データの「型」を見て、相応しい「手続き」をするよう条件分岐みたいな処理をする
関数を書かないといけないのが、「型」による抽象化（クックの言う抽象データ型）。

「型」ごとに同名の関数を定義できて、それぞれその「型」に相応しい「手続き」を
記述するだけでいいのが、「手続き」による抽象化（クックの言うオブジェクト指向）。

前者だと、既存の「型」にかかわる「手続き」を新たに追加するときに、新しい
関数をひとつ定義すればよく、既存の関数にはいっさい手を加える必要がないので有利。
この場合、後者では、各「型」に追加した「手続き」に対応する関数を追加しないといけない。

逆に、既存の「型」と同じインターフェイスを備えた新しい「型」を追加したいとき、
後者が有利。前者では、すべての既存の関数に新しい「型」に対してどのような
「手続き」をするのかの判断を追加しないといけないから。

説明しようとすると、けっこう難しいな。ｗ

916:デフォルトの名無しさん
07/01/31 01:25:12
手続き”の”抽象化、という解釈でいいなら非常に自分のスタイルとあっててシックリ来る考え方だなー
オブジェクト指向の”オブジェクト”＝状態って言うのは、いまひとつ手狭な感じがして仕方が無い

917:デフォルトの名無しさん
07/01/31 01:28:08
”オブジェクト”≠状態ではなくて、
それだけではない、という意味

918:デフォルトの名無しさん
07/01/31 01:45:17
抽象データ云々はﾓｳ秋田

919:デフォルトの名無しさん
07/03/20 01:23:42
やれやれ

920:デフォルトの名無しさん
07/03/28 01:37:45
もはやオブジェクト指向なんて言葉すら青カビ臭いし・・・

921:デフォルトの名無しさん
07/04/17 23:49:25
ｳﾎｯ

922:デフォルトの名無しさん
07/04/19 23:32:18
>>920
そうだな。たしかにいい感じに熟してきた頃合。
でも、これは材料としてであって、まだまだ料理の工夫が必要だろうけど。

923:デフォルトの名無しさん
07/04/20 15:15:14
枯れてきたからこそ身につける価値が出てくると言うもの

924:デフォルトの名無しさん
07/04/21 14:37:23
たしかに踏みならされた道のほうが楽でいいよな
開拓者は開拓者の道を歩んでもらわなきゃ困るけど

925:デフォルトの名無しさん
07/04/21 14:47:46
自称開拓者の中には自分の手を動かさず左から右へ物を動かすだけの偽者も紛れ込んでいるけどな。

926:デフォルトの名無しさん
07/04/21 15:12:02
それで名誉が手にはいるなら楽勝やん

927:デフォルトの名無しさん
07/04/21 15:26:58
偽者は早く消えろ

928:デフォルトの名無しさん
07/04/21 21:25:12
日本の思想を否定するな

929:デフォルトの名無しさん
07/04/23 03:14:46
世阿弥と義満の間で川の字になって寝られるぜ

930:デフォルトの名無しさん
07/04/25 06:08:56
URLﾘﾝｸ(www.microsoft.com)

931:デフォルトの名無しさん
07/04/25 07:39:11
タイトル：【オブジェクト指向】言語学習が先？概念学習が先？
URL：ｽﾚﾘﾝｸ(tech板)
【糞スレランク：ＳＳ】
直接的な誹謗中傷：29/930 (3.12%)
間接的な誹謗中傷：650/930 (69.89%)
卑猥な表現：8/930 (0.86%)
差別的表現：7/930 (0.75%)
無駄な改行：1/930 (0.11%)
巨大なＡＡ：8/930 (0.86%)
by 糞スレチェッカー Ver0.72 URLﾘﾝｸ(kabu.tm.land.to)

932:デフォルトの名無しさん
07/04/25 11:04:58
>>920
最近ではマルチエージェント指向なんて呼ばれているらしいけど。

933:デフォルトの名無しさん
07/06/23 07:31:27
>>932の最近＝20年前

934:デフォルトの名無しさん
07/07/08 08:46:32
最近の奴らはオブジェクト指向プログラミングや
構造化プログラミング以前に、

入力-->処理-->出力

という古典的プログラムの概念すら無いから困る。

935:デフォルトの名無しさん
07/07/08 09:06:39
オブジェクト指向はそもそも理論的なバックグラウンドすら持たない
軽薄で内容の無いバブル的なスローガンだったな。

936:デフォルトの名無しさん
07/07/08 09:07:06
↑24時間粘着体制の引き篭もりトレーダ乙

937:デフォルトの名無しさん
07/07/08 09:11:49
おっ、なんだこの反応の速さｗ
このスレには初めて書き込むんだがな。

低脳なオブジェクト指向信者が監視してるのか、ご苦労さんｗ

938:デフォルトの名無しさん
07/07/08 09:47:19
「オブジェクト指向？」
「カプセル化による隠蔽、スレッドとの親和性によって、結果的に逐次的プログラミングのパラダイムを駆逐したんだよね」
「関数型言語の理想を部分的にであれ実用化したという点は評価に値するね」
「そうそう。安易に構造化プログラミングと対比するのは、情報処理の変化の本質を見ていないよ」
「まさに木を見て森を見ず！」
「コードの見た目だけに拘って議論するのは、悪しき唯物史観というべきだね」
「とはいえ、人間の貧弱なインターフェイスでは、階層的名前空間による隠蔽や静的型チェックの強化がもたらした即物的な影響も甚大なのでは？」
「タイプ数の減少はプログラマの限られた思考能力をより抽象的なレベルに振り向けるからね」
「じゃあ次はエージェント指向だ！」
「どうかな？スレッドさえ満足に扱えない人間に、協調的プログラミングのパラダイムが理解できるんだろうか」
「しばらくはオブジェクト指向のレベルにとどまるのかもしれないなぁ」

939:デフォルトの名無しさん
07/07/08 10:03:11
所詮手続き型言語

940:デフォルトの名無しさん
07/07/08 10:44:18
俺指向

941:デフォルトの名無しさん
07/07/15 16:19:09
>>934
そうそう。そうなんだ。
基礎がなくても、開発環境のお陰で、なんとなくプログラムが動くもんだから
それで満足してるみたい。
不具合は原因が突き止められないので、フラグ増やしてフタして終わり。
もう勘弁してほしい。

942:デフォルトの名無しさん
07/07/15 19:46:06
ループを知らずに
コピペ＋マジックナンバー書き換えしまくり
っつーソースを見た時はびっくりした

943:デフォルトの名無しさん
07/07/15 19:48:19
馬鹿は伝染るということ

944:デフォルトの名無しさん
07/09/23 18:43:16
>>913
通りすがりデスが、3クックの～はC/C++の関数のポインタの様な事の気がする。

945:デフォルトの名無しさん
07/09/23 21:47:30
>>944
そのblogで紹介されているPDFを適当に読むに、
関数ポインタではなく、Lisp(CLOS)の方が適切みたいだが。

946:デフォルトの名無しさん
07/09/24 10:44:04
まとめにCLOSはこのくくりでは分類不能って書いてないか？

ま、どっちも言いたいことは分かるしたぶん間違っていないとも思う。