トップページ⇒tech
1001コメント409KB

OOP 2

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん2010/11/10(水) 22:51:25
前スレのあらすじ

OOPってよくわかんないよね

http://hibari.2ch.net/test/read.cgi/tech/1284115490/
0809デフォルトの名無しさん2010/12/12(日) 17:55:45
>>805
スクリプト言語って？当時はAWKとか？
0810デフォルトの名無しさん2010/12/12(日) 19:09:11
>>808
そうやって欲張った結果、非常に使いにくく、わかりにくい言語になってしまったんではないかと。
0811デフォルトの名無しさん2010/12/12(日) 21:17:26
そお？単にC++人口がでかいから頂点が高く底辺も大きいてだけじゃ。
C++で挫折した人間がSchemeやHaskellを使えるとは思えない。
0812デフォルトの名無しさん2010/12/12(日) 21:39:23
話は聞かせてもらったぞ！
C++で挫折した人類は滅亡する！
0813デフォルトの名無しさん2010/12/12(日) 22:05:17
コンピュータプログラミング言語がこんなに複雑である必要があるわけないだろ。
何かがおかしいのは間違いない。
きっと先入観が邪魔してるんだ。
0814デフォルトの名無しさん2010/12/12(日) 22:22:15
> C++で挫折した人間がSchemeやHaskellを使えるとは思えない。
そお？ あの結構な量の変態構文覚えるより簡単なんじゃ？
0815デフォルトの名無しさん2010/12/12(日) 22:49:52
言語の文法は「身につける」ではなくて「覚える」ものと考えるプログラマは存在して欲しくない。
0816デフォルトの名無しさん2010/12/12(日) 23:12:48
これは恥ずかしい…

大辞林 第二版 （三省堂）
おぼえる 【覚える】
(2)技術を身につける。習得する。
0817デフォルトの名無しさん2010/12/12(日) 23:13:44
体得と丸暗記の違いの話をしてるんじゃないの。
0818デフォルトの名無しさん2010/12/12(日) 23:19:44
誰が丸暗記の話をしてるんだ？
0819デフォルトの名無しさん2010/12/12(日) 23:20:10
>>813
言語が単純だと作成するプログラムが複雑になる件について
0820デフォルトの名無しさん2010/12/12(日) 23:22:58
多分おちこぼれがなんか言ってるんだよ。
0821デフォルトの名無しさん2010/12/12(日) 23:25:46
>>819 lispあたりはおもいっきり単純だけど、なにか？
0822デフォルトの名無しさん2010/12/12(日) 23:27:30
>>820
何言ってんの？
0823デフォルトの名無しさん2010/12/12(日) 23:32:56
C++0xで、関数っぽい仕組みが一体どれだけあることか。
しかもしれぞれ型が違う。その意味で抽象度が落ちてる。
機械語からアセンブリ、Cと、どんどん抽象度を高めていったはずなのに、
何でこうなったんだろうな。
0824デフォルトの名無しさん2010/12/12(日) 23:35:20
需要と供給です
※だたし非英語圏は除く
0825デフォルトの名無しさん2010/12/12(日) 23:49:38
型て。テンプレートは型どころじゃないと思うんだが。ほんとにC++やってんの？
0826デフォルトの名無しさん2010/12/12(日) 23:52:08
>>823
確かに
・関数とメソッドは違う
・コンストラクタとメソッドは違う
こういう思考は抽象度を落としているな
0827デフォルトの名無しさん2010/12/13(月) 16:51:18
>>823
その｢関数っぽい仕組み｣の内容は?

それがOOPにどう影響を与えるの?

あと型云々の所は何を指してるの?

質問ばっかりで悪いけどよろしく
0828デフォルトの名無しさん2010/12/14(火) 13:00:23
>>815=>>817
0829デフォルトの名無しさん2010/12/14(火) 22:06:51
アクセサって必要？
0830デフォルトの名無しさん2010/12/14(火) 22:23:22
必要だ/必要でない　と聞かれたら必要だ！
0831デフォルトの名無しさん2010/12/14(火) 22:24:26
>>829
アクセス制御や内部データの隠蔽、抽象化をしたいなら必要
0832デフォルトの名無しさん2010/12/14(火) 23:25:46
>>829
別に必要無い
ただし馬鹿が弄るかもしれないような現場では仕方なく使ってるだけだろ
0833デフォルトの名無しさん2010/12/14(火) 23:29:18
>>832
こういうバカが、身の程を知らずにデスマを確定させる。
0834デフォルトの名無しさん2010/12/14(火) 23:44:08
966 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/14(火) 14:31:28
getterってカプセル化的によくないの？

967 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/14(火) 14:33:37
使い方により

968 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/14(火) 14:36:38
>>967
本来そのクラスが処理するのがカプセル化だよね

969 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/14(火) 14:37:44
10年以上前にこんなやり取りあったよね

970 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/14(火) 14:38:51
まだオブジェクト指向が浸透してないってことよ

971 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/14(火) 14:45:25
プロパティなんて普通に使われてるだろ。
今時OOP原理主義なんてはやんねーよ。
0835デフォルトの名無しさん2010/12/14(火) 23:58:03
フィールドを直接晒すべきではないので、その場合は必ずアクセサでラップするべき。

しかし、アクセサを使っても、オブジェクトの内部実装に依存したインタフェースを
外部に晒していることには変わりはない。
したがって、より抽象度の高いメソッドを用意するのがより望ましい。
その意味ではアクセサは推奨されない。
0836デフォルトの名無しさん2010/12/15(水) 00:02:02
なんかを返すメソッドって使う側がそのなんかと依存する事になるのでどうしたらいいんだろう
0837デフォルトの名無しさん2010/12/15(水) 00:02:47
cmで入力したいのにアクセサがインチしか対応してなかったら不便だもんね。
内部的には尺でも良いんだけど。
0838デフォルトの名無しさん2010/12/15(水) 00:04:31
「そのなんか」に依存するのは、それ自体は別に悪いことではない。
0839デフォルトの名無しさん2010/12/15(水) 00:36:29
二つのアホがある。
1．唯の構造体的なもので、内部で何の整合性も取る必要ないのに、いちいちsetter/getterつける奴。
2．そのクラスの内部実装依存のオブジェクトを返す奴。
どっちもアホだ。何も分かっちゃいねぇ。
と思ういつもの人でした。

でも結構見かけるでしょ。困るよね。
この手のスパゲッティーは本当に手におえないよ。
0840デフォルトの名無しさん2010/12/15(水) 01:04:49
フィールドを使うのは、getは引数無し・setは引数1個と決め打ちするようなもの。
メソッドは引数を自由に決められる。

もちろん自由があっても活用する機会がなければ効果はない。
これは抽象化全般に言える。
効果が出る保証はないが費用は確実に前払いさせられる。
0841デフォルトの名無しさん2010/12/15(水) 01:48:27
単体テストすることを前提にするならアクセサで異常値全部はじけるから
開発効率は上がるんじゃね
0842デフォルトの名無しさん2010/12/15(水) 02:22:48
それほど言語の種類は知らんけど、結構文法によると思う。
Rubyの文法やC#のプロパティは好きだな。
public int Property {get;private set;}
とか、まぁ無くても良いんだろうけど、よく使う。
この構文が追加されて大分楽になった。

とりあえずフィールドアクセスとアクセサの呼び出し構文が違う言語は
あとでの変更がメンドイし、辛いわ。
0843デフォルトの名無しさん2010/12/15(水) 04:37:07
あくまで自分で書くクラスの話だが…
getterは割と使うけど、getterが扱うのはそのオブジェクト自身の属性ではないことが多いかな。
どっちかっつーと、所持(has a)してるオブジェクトの属性であることのが多い。

setterに至っては自分で書くことはほとんど無いなあ、最近。
本当に、値を代入するっていう感じがしっくり来る場合と
既に構造体的な扱いでコードを書いちゃって、それを弄る場合だけだな。
それにしたって、getterと同じく内部構造との乖離はするんだけど。
0844デフォルトの名無しさん2010/12/15(水) 07:43:35
>>843
なんだかな…
自分語りになっちゃってるあたり、どこか抜けてるし内容的にもおかしいぞ
プログラマとしての自負だけは強そうだけど
なんか>>815と同じ匂いを感じる
0845デフォルトの名無しさん2010/12/15(水) 07:53:28
隠蔽したフィールドのスコープ平気で広げまくる人間と一緒にやってるのでもう諦めた。好きにしてくれ。
0846デフォルトの名無しさん2010/12/15(水) 07:56:23
>>843
has aも晒す必要がないなら晒さない方がいいと思うけど。
0847デフォルトの名無しさん2010/12/15(水) 08:10:03
>>839
>1．唯の構造体的なもので、内部で何の整合性も取る必要ないのに、いちいちsetter/getterつける奴。

内部の構造が変更になったときのためにsetter/getterつけるんだよ
0848デフォルトの名無しさん2010/12/15(水) 08:30:54
内部構造が変更になろうとインターフェイスが変わらない限り他に影響が及ばないというのがOOPのはずだが。
0849デフォルトの名無しさん2010/12/15(水) 09:45:46
構造体という一つの単位ができあがる程度の情報量があるのに
何のラッピングも無く直に触ろうってのが問題なんじゃね。
内部とはいったってその構造体の値にアクセスする箇所が何箇所もあるわけでしょ。
アクセス方法の整合性をその箇所ごとに毎回人手でチェックしないといけなくなるよ。
0850デフォルトの名無しさん2010/12/15(水) 09:54:00
Composite パターン使うんならsetが欲しいよね。
いろんなレベルから、自由自在にsetかます。
0851デフォルトの名無しさん2010/12/15(水) 11:07:23
>>849
整合性は型でチェックすると息巻いてる連中に聞かせてやりたい
型がいかに頼りにされてないか、これでよく分かる
0852デフォルトの名無しさん2010/12/15(水) 16:44:32
まあ、構造体にgetsetは要らんと思うが。
がしかし、構造体その物が滅多にないからな。
あっても、ほんの一握りの小さなデータのみ、例えばVECTORとか
0853デフォルトの名無しさん2010/12/15(水) 16:55:35
>>848
統一形式アクセスの原則を守ってる言語は別だけど
フィールドを直接触さわるのとメソッド呼び出しで記法が変わる場合（C++とか）は
顧客側でコード書き換えが発生するから、それの防止

>>851
よこからすまんが>>851は
アクセス方法の整合性の話をしてるんであって型の話じゃないでしょ
0854デフォルトの名無しさん2010/12/15(水) 16:56:15
訂正
よこからすまんが>>851は
↓
よこからすまんが>>849は
0855デフォルトの名無しさん2010/12/15(水) 18:13:55
>>853
内部の話をしてるんであって顧客側の話じゃないでしょ
0856デフォルトの名無しさん2010/12/15(水) 18:22:26
>>852
そうかな。
構造体は結構使うぞ。
いつもの人は普通の思考回路だから、
管理関係の無いクラス同士のコミュニケートのさいに、メソッドにオブジェクトを渡したりはしない。
依存関係が強くなるだけだからな。
必ず基本型か、もしくはそれに準じるstringなどの基本的なクラスに分解してから渡す。
ただ、そうすると引数が多くなるから、それらの引数を構造体に纏めたりもする。
と言うことで、構造体は結構使うな。
機能を持った賢いクラスと、
それらのクラス同士でコミュニケートをする際の、データを受け渡しするためのみに使われる構造体と、
そういうわけ方。何でもクラスだけでやろうとはしないのさ。
0857デフォルトの名無しさん2010/12/15(水) 18:29:38
だから、Win32なんて物凄い引数のAPIとかゴロゴロあるけど、
あれはあれで賢いと思う。
今のMSよりも昔のMSの方が優秀だったと思うね。
今はなんか受け狙いというか短絡的というか。
釣りしてるように見える。ほら便利でしょう！！って。
0858デフォルトの名無しさん2010/12/15(水) 18:33:46
>>856
う〜〜ん、私の場合、その様な連絡用のデータもクラスにしてるな。
その場合はどちらでもいいと思うけど。
本体のオブジェクトをむやみに渡したりはしない。
同じだと思うけど？　
C++の場合だけどな。　C++の構造体はフリーすぎるから。
ここまで来ると、単に好みの問題かもしれん。
0859デフォルトの名無しさん2010/12/15(水) 18:48:35
>>855
アクセサやインターフェースの話をしてるんだから
顧客も当然含まれるよ
0860デフォルトの名無しさん2010/12/15(水) 19:27:54
構造体使うんならクラス使うのもそんなに変わらんと思うけど
0861デフォルトの名無しさん2010/12/15(水) 20:45:02
なんか論点がズレてるな。
>>839の「構造体的なもの」はPoEAAでいう「バリューオブジェクト」のことで、その実装方法が
クラスか構造体かどうかは（アクセサに関しては）関係の無い話。
問題は「内部で整合性を取る必要がない場合であってもアクセサを作成するべきかどうか」だろ。

もっとも、最近の言語では何らかの仕組みが用意されていることが多いから、もう終わった話題
だとは思うが。
0862デフォルトの名無しさん2010/12/15(水) 21:04:24
>>861
制約付けたい時とかのためにメソッドでラップしておく、とか？

まぁ、最近の言語は統一形式アクセスをサポートしてたりするし、
AOPコンテナを使うという手も無いわけではない、か。
0863デフォルトの名無しさん2010/12/15(水) 21:14:38
>>862
ん？何か誤解してるかな、「何らかの仕組み」と言ったのは>>842のこと。
なぜAOPコンテナ？
0864デフォルトの名無しさん2010/12/15(水) 21:39:57
まとめ

Q.内部で整合性を取る必要がない場合であってもアクセサを作成するべきか

A.統一形式アクセスがサポートされているか？
　　されている→必要なし
　　されていない→必要
0865デフォルトの名無しさん2010/12/15(水) 21:42:30
>>864
＞＞Q.内部で整合性を取る必要がない場合であってもアクセサを作成するべきか
すまん、意味がわからん
整合性を取る？？どういうことでしょうか？

A.統一形式アクセスがサポートされているか？
統一形式？？？
0866デフォルトの名無しさん2010/12/15(水) 21:55:58
>>865
>整合性
簡単に言うと
2つのフィールドの値の合計が100じゃなければだめとか
相反するフラグが同時にTrueになっちゃだめとか
こんなの、適当な例で申し訳ない

>統一形式アクセス
あるモジュールによって提供されるサービスはすべて統一された表記によって
利用できなければならない。その表記はサービスが記憶領域によって実装され
るか計算によって実装されるかにかかわらず一定でなければならない。
--「オブジェクト指向入門」
0867デフォルトの名無しさん2010/12/15(水) 21:57:10
>>865
>整合性
フィールドにint型の変数があったとして、
その変数はint型のとりうる範囲なら何でもいいなんて場合は極まれ。
正の数でなければならないとか、n〜mの範囲でなければならないとか条件を絞れるはず。
アクセサをかませば異常値ははじけるし、毎回ifで確認する手間がはぶける。

>統一形式
そのオブジェクトの利用者はアクセス対象が変数かメソッドかを意識しなくても良い様にする仕組み。
少なくともC++とJavaには無い。
0868デフォルトの名無しさん2010/12/15(水) 21:58:56
>>866-867
ありがとうございます。理解しました
0869デフォルトの名無しさん2010/12/15(水) 22:05:03
まあ、なんだかんだ言ってもローカル変数にはプリミティブな型に直アクセスするんですけどね^^
0870デフォルトの名無しさん2010/12/15(水) 22:11:35
それで何の問題もないけど？
まさかローカルなプリミティブ変数にまで、アクセッサーをｗ
まあ、変数総てがクラスという言語もあるからｗ
0871デフォルトの名無しさん2010/12/15(水) 22:18:46
もういっそのこと動的型付けでも何の問題もないけどな
0872デフォルトの名無しさん2010/12/15(水) 22:21:42
いや、動的型付けはいや！　
0873デフォルトの名無しさん2010/12/15(水) 22:28:07
アクセサをかませば異常値ははじける
動的な意味で
0874デフォルトの名無しさん2010/12/15(水) 22:43:37
>>873
異常値をはじくのは呼び出し側の仕事のような気がする
DbC的な意味で
0875デフォルトの名無しさん2010/12/15(水) 23:21:30
>>874
やっぱバグは残るんで、契約破りで例外ぐらい飛んでくれないと困る
フェイルセーフ的な意味で

まぁそれをアクセサがやるかアサート的な物がやるかは
どちらでも良いかな。
0876デフォルトの名無しさん2010/12/15(水) 23:31:05
何が何をどう持つかというデータ構造が重要なのかね
0877デフォルトの名無しさん2010/12/16(木) 00:28:16
>>867
上の例、アクセサでのチェックがなくても一応は型だけで弾けるよ。
あくまで一応は、だけどね。推奨はしない。
でも場合によっては一考の余地はある。

正の数でなければならないなら正の数クラスで受け取るようにする。
数値型もオーバーロードで受け付けるが、正の数クラスにラップして渡すだけ。

n〜mも、ほとんどの場合はn〜mに制限する理由があるはず。
それがトランプのカードに書かれた数値であるため1〜13であるなら
その数値はただの数値でなく、カードのランクだから1〜13なのだ。
だから「カードのランク」クラスにラップしてやる。

まあ、結局コンストラクタで値チェックすることになるんだけどさ。
0878デフォルトの名無しさん2010/12/16(木) 20:10:09
>>875
リリースするときは例外捕まえてこけないようにするけど
開発中は派手にクラッシュしてくれたほうがいいな
デバッグ的な意味で
0879デフォルトの名無しさん2010/12/17(金) 20:24:08
型推論
ダックタイピング
遅延束縛
動的束縛
解説みるとどれも似たようなこと書いてるんだが
どう違うのか教えてくれ
0880デフォルトの名無しさん2010/12/17(金) 20:30:15
型推論：静的に解決できるのがウリ
ダックタイピング ：型を介さないポリモ
遅延束縛 ：？
動的束縛 ：実行時に型などの情報を使ってメソッドをオーバーロード

反論は受け付ける。むしろ、誰か正しく突っ込んでくれ。
08818802010/12/17(金) 20:31:20
し、しまった。またやってしまった。
×オーバーロード
○オーバーライド
0882デフォルトの名無しさん2010/12/17(金) 20:54:00
遅延束縛はVBやってたころに見た記憶があるけど
内容は覚えてないな
0883デフォルトの名無しさん2010/12/17(金) 22:17:21
型推論って変数の型を推論するの？それともオブジェクト？
0884デフォルトの名無しさん2010/12/17(金) 22:28:01
>>883
変数の型とオブジェクトの型は必ず一致するのが普通
OOPが特殊なだけ
0885デフォルトの名無しさん2010/12/17(金) 22:36:50
Type class は OOP だけのもんじゃないんだが。
http://en.wikipedia.org/wiki/Type_classhttp://en.wikipedia.org/wiki/Type_class
0886デフォルトの名無しさん2010/12/17(金) 22:37:10
あっとミスった
http://en.wikipedia.org/wiki/Type_class
0887デフォルトの名無しさん2010/12/17(金) 23:06:31
>884
>変数の型とオブジェクトの型は必ず一致するのが普通
とか言っちゃうの恥ずかしくない？
0888デフォルトの名無しさん2010/12/17(金) 23:11:33
なんでいきなり型クラスが出てくるんだｗ
いつものパターンに引っかかってるだけなのかな俺

オブジェクトもクラスになりえるとかいうレベルの話と
型クラスは大分レイヤが違う話

>>886が思う型クラスを持つOOP言語の例を教えてくれ
0889デフォルトの名無しさん2010/12/17(金) 23:39:59
>>887
型クラスは型変数の制約。
型変数は推論できてない型をあらわす。

推論できてなくても、変数と値の型は同じだという前提は崩さないと思う。
0890デフォルトの名無しさん2010/12/17(金) 23:48:54
> 変数と値の型は同じだという前提
lisp 辺りだと
変数に束縛される object は型を持つけど、変数は型を持たないんだが…
# 論点がちゃってたらごめん
0891デフォルトの名無しさん2010/12/18(土) 00:07:49
> 変数は型を持たない
持たないものは比較できないから、同じかどうかは論点にならない
0892デフォルトの名無しさん2010/12/18(土) 00:24:11
どうやら支離滅裂らしいです
0893デフォルトの名無しさん2010/12/18(土) 00:38:56
>>891
問題はそこじゃなくて、型推論の話で型の弱い言語の話が混ざってるところだろ
いわゆる型推論って言った時はHMとその派生をさしてると思うけど
これはかなり強い型システムが前提
なのでlispが例に出てくるのは変だし
その辺で混乱してそうな人に型クラスを持ち出すのも変
(型クラスを持つOOP言語って何よ)
そんで、型推論のあるシステムでは>>884は普通で
変数と値の型が違えばコンパイルエラー
(変数の型が命題、値が証明というカリーハワード対応関係というものが成り立つ)

>>883とか890はおそらく、動的なOOP言語を思い浮かべて混乱してると予想する
変数にクラスオブジェクトを入れてその変数経由でオブジェクトを生成して、みたいな
0894デフォルトの名無しさん2010/12/18(土) 01:59:32
>>893
俺の予想ではこうなった。

変数に型がなければ混乱しない。
変数に型があっても、オブジェクトの型と同じなら混乱しない。
変数に型があって、変数の型とオブジェクトの型とが異なると混乱する。
883は混乱している。
ゆえに、883は変数に型がある言語を思い浮かべている。
08958832010/12/18(土) 18:55:21
>>893-894
ぱっと思いついた疑問だったので細かいとこまで考えてなかったw

型推論は
静的型付け言語の概念で変数の型を推論してる
であってる？
0896デフォルトの名無しさん2010/12/21(火) 21:11:35
型推論（かたすいろん）とはプログラミング言語の機能の1つで
静的な型付けを持つ言語において、変数や関数の型を宣言しなくても
それを導くのに使われた関数の型シグネチャなどから自動的に型を決定
する機構のこと。主に関数型言語で用いられる。
http://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96

らしいから、たぶんあってる
0897デフォルトの名無しさん2010/12/25(土) 14:27:10
変数の型が束縛する値に合わせて静的に決定されるのが型推論
束縛する値が変数の型に合わせてキャストされるのは弱い型付け
0898デフォルトの名無しさん2010/12/29(水) 20:29:06
オブジェクト指向とFSMの関係について
0899デフォルトの名無しさん2010/12/29(水) 21:51:30
スパゲッティモンスターがオブジェクト指向と関連があるとはしらなかった
0900デフォルトの名無しさん2010/12/29(水) 22:22:15
オブジェクト＝ヌードル触手
0901デフォルトの名無しさん2010/12/30(木) 16:19:11
C++のテンプレートはOOP 的にはどうなの?邪道?
0902デフォルトの名無しさん2010/12/30(木) 16:34:04
総称性は欲しいので有り
0903デフォルトの名無しさん2010/12/30(木) 16:50:54
>>901
もちろん不要。テンプレートで頑張りすぎちゃって、
virtual付けたときに不安になっちゃう子を沢山見た。
目先の速度に縛られてるうちはOOPのメリット享受までは遠い。
0904デフォルトの名無しさん2010/12/30(木) 16:57:50
今時ジェネリックプログラミングができないとかありえないわー
0905デフォルトの名無しさん2010/12/30(木) 17:02:21
〜ないとありえないって言ってるやつのほとんどが
そいつの技量がありえない
0906デフォルトの名無しさん2010/12/30(木) 17:06:35
テンプレートで静的に解決！
あんなこともこんなことも！
boostのアレ使ってコレ使って。

凄くシンプルなはずのことを、
糞みたいに複雑に記述してるソースを見たことある。
お前等に見せてやりたかったよ。
0907デフォルトの名無しさん2010/12/30(木) 17:20:17
>>906
論点がずれてるよ。>>901は「OOP的にどうなの？」って聞いてんだから

C++でOOPするならテンプレートはいる
総称性が使えないと不便
0908デフォルトの名無しさん2010/12/30(木) 17:42:58
>>905 C言語でOOP、とか職人芸を「技量」と勘違いしてる老害乙
レス数が900を超えています。1000を超えると表示できなくなるよ。