5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

オーバーロードって必要?

1 :デフォルトの名無しさん:02/06/27 22:55
引数にデフォルト値が設定できる言語の場合オーバーローディングって必要?


2 :shige:02/06/27 22:56
Ruby >>>>>>>>>>>>>>>> C++

3 :デフォルトの名無しさん:02/06/27 22:56
>>1
ちょっと思うな。

ところで、くだ質あればこのクソスレって必要?


4 :デフォルトの名無しさん:02/06/27 22:59
親インターフェースの場合無難な対応をして子インターフェースの場合より気の利いた対応をしたい場合は必要。

5 :デフォルトの名無しさん:02/06/27 23:01
>>4
オーバーライド + オーバーロードな場合?

6 :デフォルトの名無しさん:02/06/27 23:05
むしろ俺はポリモーフィズムって必要なのか知りたい。
インターフェースもなー

7 :デフォルトの名無しさん:02/06/27 23:05
void hoge(SuperClass a) {
a.someMethod();
}
void hoge(SubClass a) {
a.anotherMethod();
hoge((SuperClass)a);
}
という場合。食べ物が与えられた場合ただ口に入れてとんかつが与えられた場合はソースかけてから食べたいときとか。

8 :デフォルトの名無しさん:02/06/27 23:07
>>7
うまい事言うね。

9 :1:02/06/27 23:10
ふむ。じゃあ親子関係にないクラスの場合は不必要? 共通のインターフェイスを持っていないということは別の概念を表しているわけで別の概念を対象とするメソッドは別の名前がつくべきでは?


10 :デフォルトの名無しさん:02/06/27 23:12
>>9
オーバーロードは別の概念のメソッドをまとめるためのものじゃないじゃん。

11 :10:02/06/27 23:13
そもそも親子関係でもなく、そのクラス自身でもない場合にオーバーロードはない。

12 :1:02/06/27 23:13
>10
だからいらないっていってるんですが。

13 :デフォルトの名無しさん:02/06/27 23:14
オーバーワークは体に毒です。

14 :デフォルトの名無しさん:02/06/27 23:15
>>12
文字列操作クラスを使いたいとき、

CStringとcharがどっちも使えれば便利だね。
CStringで渡したときはCStringで帰ってくると便利だね。
CString渡した場合は長さを表す引数はいらないね。


15 :デフォルトの名無しさん:02/06/27 23:15
演算子オーバーロードはどうよ?

16 :1:02/06/27 23:15
>10
言い方があいまいだった。12は11読む前に書いた。ごめそ
interface A {
void b(C obj);
void b(D obj);
}

CとDが関係ないクラスの場合は必要ないんじゃないってこと

17 :デフォルトの名無しさん:02/06/27 23:16
いるんじゃない?(Java)

18 :デフォルトの名無しさん:02/06/27 23:17
>14
charの配列を文字列として使うのってオブジェクト指向的には邪道では?

19 :デフォルトの名無しさん:02/06/27 23:19
省略可能な引数があるとき、呼ぶほうは楽だろ?

20 :デフォルトの名無しさん:02/06/27 23:21
演算子オーバーロードはもっといらん

21 :デフォルトの名無しさん:02/06/27 23:24
オーバーロードは必要。
いちいちメソッド名考えるのもめんどくさいし、
メソッドごとにドキュメントを書くのもイヤだ。

すべて do(...) でいいよ。

22 :デフォルトの名無しさん:02/06/27 23:26
>>21
それはダメ!(w

23 :デフォルトの名無しさん:02/06/27 23:26
>>18
コンストラクタの引数に渡して文字列に変換するんだから,
いいんでないの?

24 :デフォルトの名無しさん:02/06/27 23:27
馬鹿ですか?

25 :10:02/06/27 23:27
>>16
CとDに意味的関連性のないオーバーロードなんて普通はしないだろ。
>>1の投稿ではそんなこと言ってないし。

関係ないのにオーバーロードにしてるとしたら、そいつがセンスないだけ。


26 :デフォルトの名無しさん:02/06/27 23:28
>>20
あればあったで便利だす

27 :デフォルトの名無しさん:02/06/27 23:28
>>18
似たような性質のクラスでも、
継承関係にあるとは限らないしなあ。

28 :デフォルトの名無しさん:02/06/27 23:29
オーバロードが〜ひらかーれた〜

29 :10:02/06/27 23:30
25に追記。
例えばRectangleとInt4つとか不要か?意味は一緒。
どちらかのパターンしか用意してないと、
使う人に使い方を強制するし、不便だぞ。

引数にデフォルト値を設定できるだけでカバーできない。

30 :デフォルトの名無しさん:02/06/27 23:30
>>28
オーラロードかよっ

31 :デフォルトの名無しさん:02/06/27 23:34
オーバーライドって必要か?

32 :デフォルトの名無しさん:02/06/27 23:35
オーバーロード〜第2章〜

33 :1:02/06/27 23:37
>25
意味的に関係あるなら共通のインターフェースを持っているべきだからメソッドは1つでいいからオーバーロードは必要ないという主張なのですが?


34 :デフォルトの名無しさん:02/06/27 23:37
>>32
13章ぐらいいっとけー。

35 :デフォルトの名無しさん:02/06/27 23:39
トラブルー

36 :デフォルトの名無しさん:02/06/27 23:39
class Rectangle
{
Rectangle (Point LeftUpper, Point RightBottom);
Rectangle (Point LeftUpper, Size size);
}
は?

37 :25:02/06/27 23:40
>>33
君のいうインターフェースとは?
普及してる言語で、現実的に継承とかインタフェース(例えばJavaのinterface)の実装
とかをやってる場合、関係があるからといって同じ継承関係にあるとは限らないのでは?

38 :デフォルトの名無しさん:02/06/27 23:41
オーバーロードのまま放置プレイすると、
CPUがこんがり焼ける罠。

39 :33:02/06/27 23:42
>37
たとえば?

40 :25:02/06/27 23:42
また追記。
>>19のような場合はどうするのさ?


41 :25:02/06/27 23:44
>>39
例えは>>40の通り
いちいち、
new Rectangle(int, int, int, int)とかまさないといけないとしたら、
かなり不便だと思う。

42 :デフォルトの名無しさん:02/06/27 23:46
>>1 を見ると、Javaは眼中にないな...

43 :デフォルトの名無しさん:02/06/27 23:48
>>1
Smalltalk が合ってると思われ。

44 :40:02/06/27 23:50
>40
引数にデフォルト値を指定できる場合って言ったけど。



45 :デフォルトの名無しさん:02/06/27 23:51
>>36
それは名前を区別してホスイ
RectanglePointToPoint (Point LeftUpper, Point RightBottom);
RectanglePointBySize (Point LeftUpper, Size size);

46 :36:02/06/27 23:53
どっちもRectangleを作るのに名前は別なの〜?

47 :25=40:02/06/27 23:54
>>40の19じゃなくて29(^^;;;;;;すまそ


48 :デフォルトの名無しさん:02/06/27 23:54
ん? 44は39の発言?

49 :デフォルトの名無しさん:02/06/27 23:55
48あ、そうです。ごめそ

50 :デフォルトの名無しさん:02/06/27 23:57
オーバーライドは完全に必要ねぇな。

51 :デフォルトの名無しさん:02/06/27 23:58
>>50
ということは抽象クラスもインタフェースも不要っとφ(. .)

52 :デフォルトの名無しさん:02/06/27 23:58
>>50
あんたにゃpolymorphismは必要ないな

53 :デフォルトの名無しさん:02/06/27 23:59
29は矩形を2点で表すのは数学でよく使うしRectangle渡してもどうせ頂点の座標しか使わないってわかりきってるからInt4つで渡したくなるという特別な場合だからいいとしてむしろ俺は39のほうが問題だと思うぞ。

54 :デフォルトの名無しさん:02/06/28 00:00
知ったかうざいよ。

55 :デフォルトの名無しさん:02/06/28 00:01
オーバーライドこそ必要。

56 :デフォルトの名無しさん:02/06/28 00:04
オーバーロードもオーバーライドもあれば使うしなければ使わない。
あればあったで便利だが、必ず必要なものじゃない。

おまえらもプログラマならこのくらい割り切っていこうぜ。ざっくばらんにな。


57 :デフォルトの名無しさん:02/06/28 00:04
>>53
動的型付の OOPL しか使ったことないとか。

58 :デフォルトの名無しさん:02/06/28 00:07
そいやオーバーロードのないOOPLってあるけどオーバーライドのないOOPLってあったっけ

59 :デフォルトの名無しさん:02/06/28 00:09
継承がない OOPL なら。

60 :デフォルトの名無しさん:02/06/28 00:19
そもそもCLOSみたいな言語の場合オーバーライドとオーバーロードの違いが無いぞ。

61 :デフォルトの名無しさん:02/06/28 00:29
function a(MoeCharactor moe)
kill(moe)
end

function a(Chobits chii)
fuck(chii)
end

62 :デフォルトの名無しさん:02/06/28 06:19
必要だと思います

63 :shigeファン:02/06/28 22:48
ヴァリアントに型を知ってるオブジェクトなら、Overloadは必要ないよね。
そもそもOverloadする言語が型を知らない言語からextendsしてOOPにしているから、
Overloadは必要なんだよ。
そうだよな、shige兄貴!!そういえばRyuuBee!にはoverloadあるんかいな?

64 :デフォルトの名無しさん:02/06/28 23:02
>>63
引数の数が激しく違う場合は?

って言うか様々な引数取るのは良いけど受け取る側のメソッドって悲惨だね・・・。

65 :デフォルトの名無しさん:02/06/28 23:08
>>64
自分が作る分は必要最小限しか用意しないけど、
ライブラリにはいろんなオーバーロードを望む罠だね。


66 :デフォルトの名無しさん:02/06/28 23:09
SmallTalker手をあげて。
3がウィンドウを出すってほんと?

67 :デフォルトの名無しさん:02/06/28 23:12
>>65
確かに。w



68 :shigeファン:02/06/28 23:21
メソッドの引数を構造体渡しに統一するという方法は?


69 :デフォルトの名無しさん:02/06/28 23:22
>>68
構造体の参照渡し

じゃ無いとダメっす。

だからそれやるとウケ側のメソッドがswitchの嵐に・・・。

70 :shigeファン:02/06/28 23:27
メンバーってMethodだけじゃないような気もするけど、fieldとか
method以外のメンバー使って解決できないもんなのかねえ?


71 :デフォルトの名無しさん:02/06/28 23:38
ポリモーフィズムって必要なのか?意味わかんね。

72 :デフォルトの名無しさん:02/06/28 23:42
>>63
言語仕様にはない。mutimethod 対応に改造した人はいたな。
似たような機能のライブラリ。
http://www.ruby-lang.org/en/raa-list.rhtml?name=overload

変に型を制限されると、
インタフェイス(メソッド)は互換性がある独自クラスのオブジェクトを投げられなくなってしまう。
動的型言語は、ライブラリ側で抽象クラスや interface を用意しなくとも
多態性が確保できるのが特徴なわけだし。

73 :デフォルトの名無しさん:02/06/29 01:34
例えばClass Aがあって、そのメンバを全部純粋仮想関数にして
それから派生した Class BとClassCを作る。
んでもって、
A b = new B;
A c = new C;
みたく定義すればbとc区別無く画一的な操作が可能。
基本だがこういう使い方をすれば
オーバーライドにも意味が出てくる。
まあ大概はそんなうまくいかないけどね。

俺は何は無くとも演算子オーバーロードはスゲエ必要だと思う。
STLコンテナに自作クラス入れる場合、
これが無いとポインタ入れるしかなくなる。

74 :デフォルトの名無しさん:02/06/29 01:45
ハゲドウ

75 :デフォルトの名無しさん:02/06/29 01:48
C++ってへぼいな。簡単なことをするためにテンプレートなんか使わなくちゃいけない。

76 :デフォルトの名無しさん:02/06/29 01:50
そうか・・・C++を使ったことがないから
いまいち演算子オーバーロードの恩恵に

いや、JavaでもStringだけは特別だったな
確かに無いと困るな

困りはしないか
でも面倒くさくなるな

やっぱり必要

77 :デフォルトの名無しさん:02/06/29 01:54
>>73
ファクトリーメソッド?

78 :デフォルトの名無しさん:02/06/29 01:54
低級プログラマは使いこなせないからねぇ、C++は

79 :デフォルトの名無しさん:02/06/29 02:05
>>78
頑張って少しずつ覚えていってくださいね。

80 :デフォルトの名無しさん:02/06/29 02:07
おれも応援するよ。 >>78、くじけるなよ!

81 :デフォルトの名無しさん:02/06/29 02:12
>>77
ごめん、ファクトリーメソッドって何?

まあSTLは演算子を変えなくても
他にやりようはあるんだけど、
例えば、ClassAがClass Xの配列のポインタを持ってたとして
void A::operator=( const A& other)
{
Class Xの配列をコピー
}
と定義すれば、
A a1;
A a2;
a1 = a2;
ってな具合に、不整合なくコピーすることが出来る。
やっぱ、あると便利。

82 :デフォルトの名無しさん:02/06/29 03:07
C++で、構造体の比較が面倒なので、
クラスにして比較演算子を定義した。
違う構造体どうしの比較ならまだしも、
同じ構造体の比較演算子くらい、
自動生成しろといいたい。
(演算子が定義できるだけましか?)

83 :デフォルトの名無しさん:02/06/29 03:08
(´-`).。oO(コピー先のインスタンスのclass Xへのポインタが挿す先はどうなるんだろう…)

84 :デフォルトの名無しさん:02/06/29 03:10
>>82
単純にバイナリレベルで比較すりゃ良いものでも無いからだろ。
構造体が char** 型のフィールド持ってたらどうすんの?

85 :82:02/06/29 03:14
>>84
デフォルトのコピーコンストラクタや、
代入演算子と、同じ問題だろ。

86 :デフォルトの名無しさん:02/06/29 03:14
(´-`).。oO(構造体同士のビットパターンの比較なんて…)

87 :82:02/06/29 03:16
>>86
パディングがあるんだから、
ビットパターンなんていうわけない。

88 :デフォルトの名無しさん:02/06/29 03:33
>デフォルトのコピーコンストラクタや、
>代入演算子と、同じ問題だろ。
つまり、「デフォルトの比較演算子は危険だから、忘れないうちに定義しとけ」っつー問題に行きつくわけだ。

89 :デフォルトの名無しさん:02/06/29 03:48
そういや初期のObjectPascalってオーバーロード無かったけど、いつのまにか
実装されたな。

90 :82:02/06/29 03:53
>>88
デフォルトのコピーコンストラクタも、
代入演算子も、俺は便利に使わせてもらってる。
あんたはどうよ?
多少危険でも、利便性を優先し、
必要なら自分で定義しなってスタンスは、
俺の性に合っている。

91 :ワードル:02/06/29 03:58
オーバードライブ
波 紋 疾 走 + 「ロードローラーだッ!」 = オーバーロード

92 :88:02/06/29 04:11
>>82
そもそも俺の書くソースには、コピーコンストラクタや代入演算子の呼ばれるところ、
ほとんど無いわ。

93 :デフォルトの名無しさん:02/06/29 04:12
コピーしまくるコードって美しくないと思うのは俺だけ?

94 :82:02/06/29 04:13
>>92
なんじゃそりゃ(藁)
いや、ばかにしてるんじゃないぞ。
落ちもついたようなので、俺も落ちる。

95 :デフォルトの名無しさん:02/06/29 04:20
>>83
AのメンバであるX*が単に参照なら
X*をコピーするだけでいいです。
それがA専用のXのインスタンスを指すポインタなら
X自体もコピーする訳です。
当然、Xにも=のオーバーロードを定義します


96 :デフォルトの名無しさん:02/06/29 09:54
単純に使用頻度が低いからじゃないのだろうか。デフォルトの==演算子が
用意されなかったのは。==があれば!=も無い訳にはいかないだろうし、
使わないのに余計なコードが増えるの何だかいやだ。

97 :デフォルトの名無しさん:02/06/29 14:32
>>93
意味違い

98 :デフォルトの名無しさん:02/06/29 16:55
継承は使える。
カプセル化も使える。
しかしポリモーフィズムだけは必要がない。

99 :デフォルトの名無しさん:02/06/29 17:26
>>98
なんで継承とカプセル化は「使える」なのに、
ポリモーフィズムだけは「必要がない」なんだ?

100 :デフォルトの名無しさん:02/06/29 17:34
!=は!(==)だから増えないんじゃないの?
比較は==と<だけありゃいいじゃん。


101 :デフォルトの名無しさん:02/06/29 18:12
>>99
使える局面にぶち当たってないんだろうね。

102 :デフォルトの名無しさん:02/06/30 00:05
ポリモーフィズムは必要でしょ?

103 :デフォルトの名無しさん:02/06/30 00:09
継承はなくても言いがポリモーフィズムだけは
絶対つけてくれ。ポリモーフィズムがないと何も出来ん。

104 :デフォルトの名無しさん:02/06/30 00:57
継承無しでポリモーフィズムって、ダイナミックなダイナミックタイピングの言語限定ですね

105 :デフォルトの名無しさん:02/06/30 02:02
ポリモーフィズム使えなかったらフレームワーク作れません。

106 :デフォルトの名無しさん:02/06/30 02:06
ダイナミックタイピングなんてーのがあるんだ。
継承あってのポリモフィズムだと思ってた。

107 :デフォルトの名無しさん:02/06/30 02:27
動的型付けの言語なら、継承が無くてもポリモーフィズムは可能。
selfがそーでなかったかな?


108 :107:02/06/30 02:28
動的な動的型付けの言語ね。

109 :デフォルトの名無しさん:02/06/30 02:42
型クラスのある言語なら、継承が無くてもポリモーフィズムは可能。


110 :デフォルトの名無しさん:02/06/30 02:58
凡化せずに、ポリモーフィズムをうたってみても、
単に関係ないものをいっしょくたに扱っているだけと
区別できないように思うんだけど、その辺どう?

111 :デフォルトの名無しさん:02/06/30 03:05
>単に関係ないものをいっしょくた
無意味な継承をするのと同じかと。

クラス階層という枠組みがあったほうが把握しやすいのは確かだけど、
区別してやるのは結局人間だからねえ。

19 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)