OOP
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/09/10(金) 19:44:500685デフォルトの名無しさん
2010/10/11(月) 22:35:42可能であれば他に一切変更を加えずに自動的にボッコシ穴あけてアクセスできるような仕組みが
（ようするにそれによって依存関係が崩壊しない保証ができるような機構が）
存在すればOOPももう一歩価値が高まるのに、って話では
0686デフォルトの名無しさん
2010/10/11(月) 22:53:32>継承するってことは、多態が必要
なにそれ初耳。どこの情報？
>Dと似た振る舞い
何が？
Eがということなら、なに当たり前(ry
>DやEを継承したクラスが他に存在
Dが継承されてるなら、慎重にやる必要があるな。
でも、Eが他のクラスに継承されてたとしても、Dには何の関係も無いだろう。
ところでこれは>>680に対する反論なのか？
0687デフォルトの名無しさん
2010/10/11(月) 22:56:10そんな行き当たりばったりなコーティング、オブジェクト指向じゃなくても有害だわwww
0688デフォルトの名無しさん
2010/10/11(月) 23:09:27つ 読解力
0689デフォルトの名無しさん
2010/10/11(月) 23:11:10依存関係が崩壊しない保証があればどれだけ行き当たりばったりでもそれは問題にならない
OOは依存関係を整理するためにあるんだから
0690デフォルトの名無しさん
2010/10/11(月) 23:17:44>>684から他に何を読み取れと。
説明も何もないぞ。
0691デフォルトの名無しさん
2010/10/11(月) 23:21:26いままでの話を無視すんな><
そもそも、依存関係が崩壊しない保証を確認してコーティングするのは、行き当たりばったりじゃなくね？
0692デフォルトの名無しさん
2010/10/11(月) 23:31:59これをチーム開発にしたとたんわけわからんイベントが多数発生する。
この原因を理解して言葉にしたいんだが。
0693デフォルトの名無しさん
2010/10/11(月) 23:50:41つジョエルテスト
最近知ったやつだけど、チームの問題を探る役に立つかも？
0694デフォルトの名無しさん
2010/10/11(月) 23:58:350695デフォルトの名無しさん
2010/10/12(火) 00:29:14だからそういう保証が簡単に取れる仕組みがあれば良いねって話でしょ
0696デフォルトの名無しさん
2010/10/12(火) 00:35:12チームに居ると割と複雑なバグだしよる
0697デフォルトの名無しさん
2010/10/12(火) 00:41:22横からで悪いが、お前はオブジェクト指向が分かっていない。
いい加減、自分だけレベルが低いことに気付け。
0698デフォルトの名無しさん
2010/10/12(火) 00:43:360699デフォルトの名無しさん
2010/10/12(火) 00:44:58いや、そんな話しはしてなかった。
>>603の例の設計は駄目だねって、俺が始めた話し。
0700デフォルトの名無しさん
2010/10/12(火) 01:15:33別に提案自体はそんなに悪筋じゃないし、そういう言い方せんでも良いのでは。
0701デフォルトの名無しさん
2010/10/12(火) 06:39:29分かってないのはお前だ。
どうせOOの一番の特徴は再利用性とでも思っているのだろう。
0702デフォルトの名無しさん
2010/10/12(火) 11:00:35>差分プログラミングとOOPの区別が付いてないから厄介
差分プログラミングとOOPが別物だと言う人間は始めて見たな。
これはどんな根拠なんだ？ 誰か教えてくれ。
0703デフォルトの名無しさん
2010/10/12(火) 11:14:58馬鹿な人間が考えることは、普通の人間には解らん。
まっ天才が考えることも普通の人間には解らんが。
0704デフォルトの名無しさん
2010/10/12(火) 12:06:09差分プログラミングはあくまでOOPが広めた一要素でしかないのであって
OOP＝差分プログラミングでは無いんだが
何故かやたらと差分プログラミングのための継承を乱発する奴が居る
という意味だと思う
0705デフォルトの名無しさん
2010/10/12(火) 19:13:53最近の考え方では誤りを含んでいる可能性が高いとされる。
0706705
2010/10/12(火) 19:15:54考えてみた方が良いと思う。
0707デフォルトの名無しさん
2010/10/12(火) 19:32:540708デフォルトの名無しさん
2010/10/12(火) 21:50:07設計は問題あるかもしれないけど
これって別に悪いことじゃないよね？
OOPというかカプセル化は上記のようにするのが目的だと思うんだが
0709デフォルトの名無しさん
2010/10/12(火) 22:20:31その意味だと”区別”とは言わない。
0710デフォルトの名無しさん
2010/10/12(火) 22:29:33同じ基本クラスAを継承したクラスBとクラスCがあったとして
クラスAが使われている部分を全部クラスBやクラスCに置き換えても正常に動作しなければならない
つまり多態を必要としていなければ継承は使うべきでない
0711デフォルトの名無しさん
2010/10/12(火) 23:29:43クラス図を書いて見たけど、全然悪くないと思う。
例えばMVCのビジネスロジックDクラスがCクラスを管理して
そのCクラスをViewでコンポジションするなど普通に行なう。
Dクラスがスーパークラスを持っていてもおかしくないし
そのクラスが別のクラスを持つことも普通にある。
駄目だと言っている人間は本当に実践でOOPを使えているのか？
0712デフォルトの名無しさん
2010/10/12(火) 23:38:10俺が何を駄目と言ったかちゃんと見た？
まあ、その文の様子だと見てないんだろうけど。
0713デフォルトの名無しさん
2010/10/12(火) 23:48:190714デフォルトの名無しさん
2010/10/12(火) 23:49:48>>659です。
0715デフォルトの名無しさん
2010/10/12(火) 23:54:55お前C++房だろう。OOPを勉強して出直せ
他の言語を知っている人間ならそんなバカなこと書かないぞ。
0716デフォルトの名無しさん
2010/10/12(火) 23:57:320717デフォルトの名無しさん
2010/10/13(水) 00:00:130718デフォルトの名無しさん
2010/10/13(水) 00:03:15それ、単なるLSPじゃねーの
0719デフォルトの名無しさん
2010/10/13(水) 00:07:05まじで OOP って声高にさわぐ奴って何なのよ?
理屈、説明しても分からない
要求仕様を渡しても自分の都合のいいように改変してくる
数式渡しても全然別のものを作ってくる
まともな頭もってる奴って OO って叫ばないぞ
0720デフォルトの名無しさん
2010/10/13(水) 00:11:12659を読んだから実践でOOPが使えない人だと思ったけど。
0721デフォルトの名無しさん
2010/10/13(水) 00:12:41OOは知らんが、OOPは言語によって形態が違うな。
共通してるのはカプセル化ぐらいだ。
0722デフォルトの名無しさん
2010/10/13(水) 00:18:02本当かよww
一応言っとくけど、俺は>>711の、全く悪く無い、ってところ以外は同意してるぞ。
>>659もそれが前提になってるし。
0723デフォルトの名無しさん
2010/10/13(水) 00:18:540724デフォルトの名無しさん
2010/10/13(水) 00:21:33メリットがないときは使わないほうがいいでしょう。
0725デフォルトの名無しさん
2010/10/13(水) 00:23:38継承やらテンプレートやら。
0726デフォルトの名無しさん
2010/10/13(水) 00:41:19そんなこと言ってるんじゃないんだな, これが…
たとえばの話なんだが,
MPEG シリーズってのは、規格書の書式含めて、ある意味 OO の産物なわけだ
これをふまえて, この規格書のここからここまでを何とかしたいとか言うわけ
で、連中、プログラム書いてくるんだが、
規格書に書いてあることに堂々と違反する
規格書中の数式を理解できないんだろうけど, アルゴリズムがおかしい
わかりやすく数式書き直してあげても数式通り動かない
でも, 「うちは OO してますから， 大丈夫なはずです！！！」と声高に言う
つか、 OO ってやってるふりしてりゃ許してもらえる隠れみのになってるだろw
0727デフォルトの名無しさん
2010/10/13(水) 00:46:02それOO以前の問題じゃねwww
プログラマに必要な技能が備わって無いwww
0728デフォルトの名無しさん
2010/10/13(水) 00:46:18「思考の限界は言語の限界」だと言っている。
まっ思考には非言語的要素もあるから、これが全て正しい訳じゃないが
しかし、ほとんどの思考は言語で考え、言語で表現する。
だからC++房は駄目なんだよ。C++言語の限界が思考の限界になっている。
C++に無い部分が理解出来ない。
0729デフォルトの名無しさん
2010/10/13(水) 00:52:17そだよ！ じゃなくって、
「OO してますって言えば世間が許してくれる」
と思う、その感性ってどぉよ？？？
0730デフォルトの名無しさん
2010/10/13(水) 00:55:06そいつらはきっと、世間から無視されるだけだからほっとけ。
0731デフォルトの名無しさん
2010/10/13(水) 00:59:22相手に仕様が伝わらないのは、お前の日本語が”変”だからじゃないのか。
0732デフォルトの名無しさん
2010/10/13(水) 01:02:22>>726は、説明書が読めないやつが居る、って言ってるんだよ。
0733デフォルトの名無しさん
2010/10/13(水) 01:02:36なんで日本語しゃべらんとあかんの？
数式読めないみたいだから、数式を高校生でも読める数式に書き換えただけなのに
0735デフォルトの名無しさん
2010/10/13(水) 01:17:05>なんで二重に管理する必要があるんだ、どうせ機能は同じようなものなんだからまとめてしまえ。
そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。
>そもそもDはEを継承しているんだから、Bも直接管理できるはずだろう。（出来ないならそれは継承するべきではない）
>基本クラスのEを気にする必要は無い。
Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。
0736デフォルトの名無しさん
2010/10/13(水) 01:23:43>説明書が読めないやつが居る、って言ってるんだよ。
説明書ｗ お前が読めていない。
0737デフォルトの名無しさん
2010/10/13(水) 01:24:020738デフォルトの名無しさん
2010/10/13(水) 01:25:24>なんで日本語しゃべらんとあかんの？
何語で喋っているの？
0739デフォルトの名無しさん
2010/10/13(水) 01:35:27＞そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。
百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
データの整合性ちゃんととれるのか？
そもそもそれはプログラム的に自然なのか？
＞Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。
コンポジションを知らなかったので、wikipediaで調べた。
＞コンポジションは、両クラス間に強いライフサイクルの依存がある場合に使用する。
＞つまり、コンポジション関係にあるクラスの集約しているオブジェクトが削除されると、必ず集約されている側のオブジェクトはすべて削除される。
Privateフィールド関係なくね？ というのは置いといても、
全く関係ないこと言ってないかこれ。
0740デフォルトの名無しさん
2010/10/13(水) 01:36:17比喩も認めない頭の固い人か。
0742デフォルトの名無しさん
2010/10/13(水) 02:17:35>百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
603が正しく理解出来ていないのか？ 管理しているのはDなんだから
Dが所有物CをAが参照(委譲)しているよ考えるだろう。
何をもって干渉やデータの整合性と言っているのか分からないが
オブジェクト指向はオブジェクト内で完結するように作るものだ。
>Privateフィールド関係なくね？ というのは置いといても、
>全く関係ないこと言ってないかこれ。
まぁコンポジションでも集約でもどちらでもいいんだが
Eが管理クラスだから生成・破棄を制御するのが普通だと思ってコンポジションにした。
俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。
>基本クラスのEを気にする必要は無い。
だからこれは間違い。
0743デフォルトの名無しさん
2010/10/13(水) 02:27:34喋れるのは中国語か韓国語だと思ったよ。
>そだよ！ じゃなくって、
そだよｗ
まぁこれ以外にもおかしな日本語いっぱい使っているし大丈夫かｗ
0744デフォルトの名無しさん
2010/10/13(水) 02:30:24なぜそこで比喩を使う？ 言い訳が苦しいなｗ
0745デフォルトの名無しさん
2010/10/13(水) 11:35:24wikipediaのMVC項目、「MVCのシナリオ」で、下記の疑問をもちました。
・Vにイベントハンドらを関連付ける人はこのモデルの上位に当たるオブジェクトが担当する？
・Cはオブザーバー的な役割を持っている？
・VはMを参照として持っている？なのでVが直接Mからデータを参照するのだろうか？
・Cは入力のオブザーバー的な役割のようだが、出力は担当しないのだろうか？
記事の下部にありますシナリオですが、
私としては以下のように読み取りました。
1. ユーザがviewに入力を行う
2. viewからの入力により、Vに登録したcontrollerのイベントハンドラやコールバック等がよばれる。
3. controllerが必要に応じたmodelのメソッドを呼び、ステータスを更新する。
4. 3の結果を表示する為にviewがmodelから必要なデータを取得し出力する。
また、概念図では相互残照を行っているように見受けられます・・・。
0746デフォルトの名無しさん
2010/10/13(水) 11:56:59特にシナリオの部分は酷い、出典が書いてないオレオレ脚注とか付いてるレベルだよ
要出典タグつけたの俺だし
>また、概念図では相互残照を行っているように見受けられます・・・。
あの図はUMLではないし、Observerパターンがわかってれば別に変でもない
0747デフォルトの名無しさん
2010/10/13(水) 12:44:45＞管理しているのはDなんだから
＞Dが所有物CをAが参照(委譲)しているよ考えるだろう。
ふーん。>>742はそう見ているのか。
まあ、実はどっちでもいいんだけどｗ
＞何をもって干渉やデータの整合性と言っているのか分からないが
え？ ・・・え？
干渉はまだしも、データの整合性が分らないとな・・・？ お前それ本気で言ってる？
どんなプログラムでも、二つ以上の別々の場所から参照されてるデータは、
データの整合性の問題が付きまとうものなんだがなあ・・・
＞俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
＞Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。
ああ、そうか。 それだと直接管理することは出来ないな。
確かに、Eは気にする必要がある。
と言っても、protectedやpublicなメンバから管理することは出来るが。
で、これだとまた別の問題として、継承する意味はあるのか？と言うのはある。
委譲以上のメリットを見いだすなら、
protectedなメンバからそれなりに自由な管理が出来る、と言うのがメリットになるか。
直接管理するのと同じくらいの自由度でね。
・・・あとは、>>742の用語の理解度は大丈夫か？ と言うのは、まあ置いとこう。
0748デフォルトの名無しさん
2010/10/13(水) 13:23:39レス、ありがとうございました。
あの記事は当てになりませんが・・・。
出直してまいります。
0749デフォルトの名無しさん
2010/10/13(水) 15:06:51結局603を間違いじゃないと認めたな。
しかし、>>659は酷いな、お前Privateフィールドも分からないとは
オブジェクト指向でプログラム作ったことないだろう。
0750デフォルトの名無しさん
2010/10/13(水) 15:30:06いや、半分だけだぞ？
つーか、お前プログラム実装したこと無いだろ？
0751デフォルトの名無しさん
2010/10/13(水) 19:35:550752デフォルトの名無しさん
2010/10/13(水) 20:40:52設計は別に悪くないけど設計者(と開発体制)が悪い。
0753デフォルトの名無しさん
2010/10/13(水) 21:17:50AとかBとかCとかDとか頭沸いてるんじゃね。マトモな会話しやがれ。
原文は、やりたいことが素直に書けないから嫌だ、そういってるだけだろ。
やりたいことってのはつまりは手続きで、まぁアルゴリズムや制御構造や関数の類だな。
それが素直にかけない・・・まぁ当たり前だわな。
だってOOPは制御構造をオブジェクト単位でぶつ切りにしてパッパラパーにしちゃうからな。
だから、その指摘自体は何も間違っちゃいないんだぜ？
よくそんなことでこんな長文合戦が続くもんだな。
0754デフォルトの名無しさん
2010/10/13(水) 21:24:27こんなことになってるんだな。OOPもそうなんだけど、クラス云々言ったときに何目的ベースの話なのかが見え無いと言う。
ポリモとカプセル化と差分プロの話がごっちゃになって展開される。だから意味解らん。
もうね、構文わけときゃいいと思うよ。
カプセル化はカプセル化専用の構文なり機構なり作ってそれで固めると。
その固めたオブジェクトをどうコミュニケーションさせるかは、
また別の構文なり機構なりですると。
Unixだと、プログラムはプログラムで閉じてて、
それをシェルを使ってどう組み合わせるかはまた別の話だったりして。
だから解りやすいんだよ、設計するのも、こう言うところで会話するのも。
何使ってるかで目的が明確だから。
0755デフォルトの名無しさん
2010/10/13(水) 21:29:510756デフォルトの名無しさん
2010/10/13(水) 21:29:59プログラムってのは、その名の通り、手続きのことだろ。
俺らそれ書きたいだけなのに、現状データやオブジェクトに振り回されているという。
この逆転劇はどこかで終わるんだろうけど、楽しみだね。
0757デフォルトの名無しさん
2010/10/13(水) 21:39:33だんだんOOPに疑問を抱くようになってきて、そんで、やっぱ物中心の思考ってのは無いなーとか、
そんで、他との関係が物の性質を決めるんだって気づいてからは、
だんだん行間を飛ばすようになってきて、あーやっぱ「間」って大事なんだなぁって。
行と行の間には行間があって、それが行と行との関係で、そこに本当に言いたいことがあったりして。
だから段落って重要だよね。どういう構成になってるかで言いたい事が大体分かると言う。
日本語も面白くて、漢字をひらがなで繋いでいるのな。言うなら漢字がデータでひらがなが関数って。
こうやって人は成長して大人になっていくんだなぁって。仕事ってほとんど後片付けだしね。
0758デフォルトの名無しさん
2010/10/13(水) 21:41:070759デフォルトの名無しさん
2010/10/13(水) 21:44:05漢字って一字一字が意味を持っていて、まるでOOPで言うところのオブジェクトみたい。
一方、ひらがなは一字一字には意味は無く、「いってきます」って流れて意味が出る。
まるで手続きみたいだ。
0760デフォルトの名無しさん
2010/10/13(水) 21:45:420761デフォルトの名無しさん
2010/10/13(水) 21:55:46抽象的なことばかり言ってないでさ
0762デフォルトの名無しさん
2010/10/13(水) 22:24:14現状、大概のOOPが単一オブジェやクラスにメソッドがくくりついているから、
オブジェクトがメソッド(機能)を所有しているとかって変な感覚が沸いてくる。それが泥沼の原因なんだと思う。
だから、オブジェクトからメソッドを切り離してさ。
func( obj1, obj2 );
こんな感じで普通にかければ気持ちいいだろうと。
データにはただのデータでいてもらってさ。機能なんか持たずにね。
データやらオブジェクトやらをどう使うかは、型の作成者じゃなくて、利用者が決めるというね、Unixの思想ね。
ただ、カプセル化は必要だろうから、それ用の何らかの機構は必要だと思うけど。
なんかアクセス権とか適当につけて頑張ってって感じ。
0763デフォルトの名無しさん
2010/10/13(水) 22:30:27わかったから行間を開けて段落を作れ馬鹿
0764デフォルトの名無しさん
2010/10/13(水) 22:32:40関数は引数のオブジェクトの型情報を使ってどう処理するかをマルチメソッドする。
これは、whatとhowの分離で、とても有用。
昔からバカはwhatとhowの区別が解らないもんだと決まってて、whatで聞いてるのにhowで返してきたりする。
だから、whatとhowを分離することは、マトモになることへの第一歩かなぁと。
画像ファイルを見れば解るけど、ヘッダに「フォーマットが何か」が書いてあるだけで、「どう使うか」までは書いてないんだよね。
だから、展開用コードが内包されていたりはしないし、用途も使う人次第。
オナニーには使わないでくださいでは困るんだよ。そんなことは指定しないで欲しいんだよね。
0765デフォルトの名無しさん
2010/10/13(水) 22:37:05例えば、C++のvtableみたく、データの先頭にヘッダみたいに型情報をおいて置くのも一つの方法なんだけど、
それだとオフセットがずれるし、個人的にキモイ。データは単にデータであって欲しいんだよね。
だから、オブジェクトの型が何であるかは、ポインタや参照が覚えていれば良いと思う。
だから、32bit環境ではポインタや参照のサイズが実アドレスと型値で64bitになるね。
ちょうどC++のshared_ptrがそんな感じの実装になってて、ありかなぁと。
0766デフォルトの名無しさん
2010/10/13(水) 22:39:52struct pointer{ void *address, int type };
こんな感じかね。その辺は適当に。
0767デフォルトの名無しさん
2010/10/13(水) 22:42:19「,」→「;」
やっちった。これはかっこ悪いぞ俺。頑張れ。
0768デフォルトの名無しさん
2010/10/13(水) 22:48:35クラスの粒度の違うだけな気がするな
単純にデータとして扱えるのは最初の方だけで
最終的にはOOPと同じような形になるんじゃないかな
0769デフォルトの名無しさん
2010/10/13(水) 22:49:45それから、型値のマルチメソッドへの最適化。
ポインターの宣言都度都度で変換テーブルを用意せにゃならん。
それも、他ポインターからの代入を洗いざらい全部調べて、組み合わせ爆発的にな。
コンパイル時にはユニークな型値を割り振っておいて、そっから最適化で詰めていくってのがやりやすそうなんだが、
動的にモジュールを読み込んだときはどうなるんだって。そこまで考えると盛り上がるなー。
0770デフォルトの名無しさん
2010/10/13(水) 22:55:31そうはさせないような仕組みも考え中。
オブジェクトがこんがらがるのは、オブジェクト中に他のオブジェクトの参照を持ってたりするからで、
だから、そういうことはさせないようにしようと。
なんか、そういった依存関係は別の構文で何とかならんかと。
例えば、
relation( "なんかの関係", obj1, obj2 );
とすると、"なんかの関係"とobj1とobj2との間で関係が定義されて、
後で引っ張り出せるような何か。
データ構造にも抜本的にメスを入れたい
0771デフォルトの名無しさん
2010/10/13(水) 22:59:580772デフォルトの名無しさん
2010/10/13(水) 23:03:17>"なんかの関係"とobj1とobj2
これもデリゲートで片がつくのでは？
デリゲートじゃだめな理由を聞きたいね
0773デフォルトの名無しさん
2010/10/13(水) 23:07:40それは、今ここで説明した理由ではなくて、
型と関数を同列に扱いたいと言う要望からだけど。
型は型だけど、関数はインスタンスだからね。
同列に扱うには、型とインスタンスの区別をなくす必要があって、
文法をどう纏め上げるか、どういう解釈、トリックにするか、悩み中。
ただ、C言語のノリが一つのヒントになると思ってる。
int i;
int func(){}
変数と関数は全然別物だけど、ただ、どちらも、
identifierを評価すると、前に書いてある型へ落とし込まれて評価されることには
変わりないんだよね。そこつかってなんかできんかと。
0774デフォルトの名無しさん
2010/10/13(水) 23:11:59デリゲートは何処に保存しとくんだっていう。
でも実際迷ってんのよ。関係を別途保存しますってもうそれDBだし、それするなら、構造体とか・・。
関係を定義したんだから、関数に纏められんかとか。う〜ん。
文法としては統一したいんだけど、用途としてはばらして置きたいという。
0775デフォルトの名無しさん
2010/10/13(水) 23:21:25なんか関数型言語じみてきたな
>>774
>デリゲートは何処に保存しとくんだっていう。
>relation( "なんかの関係", obj1, obj2 );
このrelationを呼び出すとこで管理しとけばいいんじゃない
0776デフォルトの名無しさん
2010/10/13(水) 23:47:54そそ、関数型言語風。だけど手続き型で、バリバリメモリやインスタンス意識した何か。
そういう中途半端な按配の妙な、しかし、妙にフィットして使いやすいC言語みたいな、そういう。
関係に関してなんだけど、関係を言語環境でサポートしたいんだよね。インデックスとかも割り振って高速に列挙できるような。
そういうの書くのもう面倒でしょ。逆参照がどうとか、一対多だとか。RDBに任せるったって、インピーダンスミスマッチするし。
リストとか配列とか、もう面倒だし、本質じゃないしなぁ。関係の一言で片付けたい。
C言語、あれ面白いんだよ。知ってのとおり、C言語って論理型が無いんだよね。
そのくせ、C言語の企画書みると、標準関数の〜は〜のとき真を返します、とかしれっと書いてあんのな。
でも文法上は論理型も真偽値も無いと言う。
プログラマも会話や企画書で真とか偽とか普通に使うのに、
でも文法上はそんなもんねーっつー。
俺もそういうのが作りたいなぁって。
型も関数もインスタンスも文法上区別はないし、組み合わせ爆発がないから文法もシンプルだし、
なんだけど、使ってる奴は、型とか関数とかインスタンスとか区別してるし、会話にも出てくるしっていう。
まさにミラクル。
0777デフォルトの名無しさん
2010/10/13(水) 23:52:370778デフォルトの名無しさん
2010/10/13(水) 23:52:45まず多態性の対象はメソッドにいして（オブジェクトを後で）
実装方法はインターフェース・継承ぐらいから話そう。
最初はインターフェース・継承それぞれの利点・欠点ぐらいから。
俺的にはインターフェースしか使わないと言う奴はバカだと思う。
インターフェースは使うのは
結びつき弱いクラス同士のIFを揃える時ぐらいしか使わないのが正しい。
0779デフォルトの名無しさん
2010/10/13(水) 23:56:02だから頃合見計らって次スレ立てよろしくな。キリ番だし。
0780デフォルトの名無しさん
2010/10/14(木) 00:01:45日本語でおｋ
0781デフォルトの名無しさん
2010/10/14(木) 00:30:040782デフォルトの名無しさん
2010/10/14(木) 00:37:38〜はバカだって言っといてその根拠は挙げないし、
〜は正しいって言っといて、その根拠も挙げないし。
ばかなのしぬの。
でももう書き込まなくて良いからね。
0783デフォルトの名無しさん
2010/10/14(木) 00:41:010784デフォルトの名無しさん
2010/10/14(木) 01:04:56何となくjavaしかやったことないとみた。
■ このスレッドは過去ログ倉庫に格納されています