本ブログは更新を停止しました。Aerieをよろしくお願いいたします。
投稿カレンダーはJavaScriptが有効でない環境では使用できません。
αετο? / aetos / あえとす
シャノン？ 誰それ。
埼玉を馬鹿にする奴は俺が許さん。
基本的に知ったかぶり。興味を持った技術に手を出して、ちょっと齧りはするものの、それを応用して何か形にするまでは及ばずに飽きて放り出す人。
ご意見頂戴。こういうオーバーライドはできたらいいと思う？
class X; class Y : X; class Base { public virtual void Hoge( X x ); } class Derived : Base { public override void Hoge( Y y ); }
投稿日時 : 2007年2月14日 12:39
オーバライドじゃなくてオーバロードになっちゃうぞっと。ってことで機能的にはあるので無問題。 void Hoge( X x );側が隠れるとOOPとして成り立たないからメリットが見えないっす。
「できたらいいと思う？」な話なので、C#によく似た架空言語だと思ってください。よってオーバーロードにはならず。 例えば、XとBaseは常にセットで使うこと、かつ、それぞれが派生クラスで拡張されることを意図して設計されているとする（Derived.Hogeの引数は常にYであることがわかっているとする）。 C#で同じことをやろうとすると、Derived.Hogeの引数はXでなければならないが、そこに渡される型は常にYなのでキャストが必要になる。 Hoge(X)をHoge(Y)でオーバーライドできればキャストが要らなくなるというメリットがある。 代償として、Base.Hogeの宣言だけを見ても引数に何を渡せばいいか分からなくなるというデメリットがある。 が、これはC#でも存在する問題で、Derived.Hogeの中でキャストしているのでどのみち落ちる。 それとも、こういう場合のDerived.Hogeは、引数がYでないことも想定してプログラムを組まなければならないのだろうか？
んとんと、 Base object = new Derived(); X argument = new X(); object.Hoge(argument); こんとき Derived.Hoge が呼ばれるけども 引数は本来のYじゃなくXが引き渡されますな...ヤバいっすよねー 引数X,Yの継承関係が逆転していれば、Yの方がより'狭い'ので問題なさげですけども。
> ヤバいっすよねー うん、それがヤバいのは承知の上。 けれど、Derived.Hoge が引数に Y を期待して、 public override void Hoge( X x ) { Y y = ( Y )x; // ... } ってやってると、それはそれで落ちる。 どちらにせよ、Base.Hoge の宣言だけからは、引数に渡すべき正確な型がわからない以上、キャストが要らないだけマシかな、と。 「宣言上は X を取るのに、実際には Y しか取れない」という Derived.Hoge の設計がマズい気もする。 すると、そもそもからして、 > 例えば、XとBaseは常にセットで使うこと、かつ、それぞれが派生クラスで拡張されることを意図して設計されているとする という設計がまずい？ こういう場合のいい方法はありますかね？
なるほどBaseとして使われるんですな。 そうなるとキャストじゃなくオーバライド側で引数チェックでしょうねぇ。is or AssignableでダメならArgumentExceptionを投げると。
> そうなるとキャストじゃなくオーバライド側で引数チェックでしょうねぇ。is or AssignableでダメならArgumentExceptionを投げると。 うむ。 で、そういう設計ってどうなのよ？ と。それって LSP の破壊だよねと。 どうせ破壊するなら、キャストない方がいいんじゃない？ と。 ただ、そこで、こういうオーバーライドができた方が嬉しいという結論に達したとしても、C#がそうなる望みはないので、それは一旦忘れるとする。 ちょっと考えを変えて、LSPを破壊しない設計を考えると、どういう風にするのがいいのかな。
Powered by: Copyright © αετος / aetos