アカウント名:
パスワード:
ふるーいオブジェクト指向なんてない頃のPGなんで、JAVA詳しくないが、これはできるだろう(正確にはできた(変えた)ように見せかける)
上司「このメソッド名分かりにくいから分かりやすい名前にして」僕「そのメソッドは親クラスのメソッドをオーバーライドしてて変えられないんです」上司「あっそうなんだ…ふーん」
継承した子どものクラスで新しく別の名前メソッド作って、その新メソッドから、自分の親クラスから継承したメソッド呼べばいいんでないの?同じ内容のメソッド2つできちゃうけど。
出来ないんだっけ?
オーバーライドは親クラスのメソッドの動作を置き換えるということ。シグニチャーが異なるのでは意味がない。
>シグニチャーが異なるのでは意味がない。オーバーライドは手段であって目的ではないだろうに。
>このメソッド名分かりにくい時点である程度親クラスの設計間違てるんだし。
>シグニチャーが異なるのでは意味がない。なんて言ってる時点で手段と目的勘違いしてないかい?目的はオーバーライドする事でなく目的の動作をするメソッド作ることだろうに。
子クラスでオーバーライドした元の名前と同じままのメソッドを別の名前のメソッドから呼ぶ。位の機転がなぜ効かないのかね。
これから書くことは「そうあるべきではない」事案であることは重々、承知の上で
オーバーライドは手段であって目的ではないだろうに。
話の種として、「オーバーライドが目的になっていた事案」を見かけたことがある。
具体的には某大手メーカーが、.NET Frameworkベースのソフトを、自社のとある部門向けに、結構なコストをかけて改修した。認証周り等のクラスをオーバーライドして、自社内インフラと連携させた感じ。ここまではいい。オーバーライドの正しい使い方だ。
問題はその次の開発で発生した。同社内別部門向けのソフト開発だ。「既に予定以上の工数をかけているので、前述のソフトの改修は禁止」「前述のソフトでオーバーライドした部分はそのまま使え(前述のソフトから更にオーバーライドすれば工数を抑えられる、という理由で社内で工数を確保したので)」という政治的縛りが加わった。
で、問題が発生したのが「元ソフトと、オーバーライドされたソフト、両方の機能を使い分ける場所」クラス設計は変更できないし、オーバーライドされたソフト(クラス)にはbase.hogehogeでアクセスできるが、更にその基底クラスにはアクセスできない。(イメージ的にはbase.base.hogehogeだが、そんな書き方できない)担当の協力会社のプログラマーが力業で解決してたが、色々と大変そうだった。
こういう技術以外の縛りでオーバーライドが目的になっちゃうことは、それはレアケースだし、クソったれな状況だけど、ないわけじゃないんだよなあ、ってことで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
リンク先で。。。 (スコア:0)
ふるーいオブジェクト指向なんてない頃のPGなんで、
JAVA詳しくないが、これはできるだろう(正確にはできた(変えた)ように見せかける)
上司「このメソッド名分かりにくいから分かりやすい名前にして」
僕「そのメソッドは親クラスのメソッドをオーバーライドしてて変えられないんです」
上司「あっそうなんだ…ふーん」
継承した子どものクラスで新しく別の名前メソッド作って、その新メソッドから、自分の親クラスから継承したメソッド呼べばいいんでないの?同じ内容のメソッド2つできちゃうけど。
出来ないんだっけ?
Re: (スコア:0)
オーバーライドは親クラスのメソッドの動作を置き換えるということ。
シグニチャーが異なるのでは意味がない。
Re: (スコア:0)
>シグニチャーが異なるのでは意味がない。
オーバーライドは手段であって目的ではないだろうに。
>このメソッド名分かりにくい
時点である程度親クラスの設計間違てるんだし。
>シグニチャーが異なるのでは意味がない。
なんて言ってる時点で手段と目的勘違いしてないかい?
目的はオーバーライドする事でなく目的の動作をするメソッド作ることだろうに。
子クラスでオーバーライドした元の名前と同じままのメソッドを別の名前のメソッドから呼ぶ。
位の機転がなぜ効かないのかね。
Re:リンク先で。。。 (スコア:0)
これから書くことは「そうあるべきではない」事案であることは重々、承知の上で
オーバーライドは手段であって目的ではないだろうに。
話の種として、「オーバーライドが目的になっていた事案」を見かけたことがある。
具体的には某大手メーカーが、.NET Frameworkベースのソフトを、自社のとある部門向けに、結構なコストをかけて改修した。
認証周り等のクラスをオーバーライドして、自社内インフラと連携させた感じ。
ここまではいい。オーバーライドの正しい使い方だ。
問題はその次の開発で発生した。同社内別部門向けのソフト開発だ。
「既に予定以上の工数をかけているので、前述のソフトの改修は禁止」
「前述のソフトでオーバーライドした部分はそのまま使え(前述のソフトから更にオーバーライドすれば工数を抑えられる、という理由で社内で工数を確保したので)」
という政治的縛りが加わった。
で、問題が発生したのが「元ソフトと、オーバーライドされたソフト、両方の機能を使い分ける場所」
クラス設計は変更できないし、オーバーライドされたソフト(クラス)にはbase.hogehogeでアクセスできるが、更にその基底クラスにはアクセスできない。
(イメージ的にはbase.base.hogehogeだが、そんな書き方できない)
担当の協力会社のプログラマーが力業で解決してたが、色々と大変そうだった。
こういう技術以外の縛りでオーバーライドが目的になっちゃうことは、それはレアケースだし、クソったれな状況だけど、ないわけじゃないんだよなあ、ってことで。