アカウント名:
パスワード:
A:それを書いた事があるとその言語の経験者を名乗れるから。
と思っていた事もありました。今じゃ「書いた」じゃなくて「読んだ」ぐらいで経験者を名乗る奴もいるからなあ。
# せめてホワイトボード上で書けるぐらいには知っておけよ…
オブジェクト指向で書いてるけどオブジェクト指向を説明しろっていわれたら各処理を部品化して交換可能にすることとしか出てこなくって体で理解しているのであって頭で理解できてねぇって気がついた
構造体に関数がくっついてるだけでしょ。
ポリモーフィズムはオブジェクト指向の必須要素ではないと思うなあ。最低限、構造体に関数がくっついていればオブジェクト指向できると思うが。(データ構造とアルゴリズムの非分離)カプセル化はさらに必須ではないな。カプセル化できないC++がオブジェクト指向を標榜してたりするし。
ポリモーフィズムが多くの場合、強い有害だと分かったからの話です。継承をするとは、構造を継承するのですが、圧倒的大多数の設計では、変更とは構造の変更で有り、ミスマッチが生じます。たいていの場合、同じ外見のクラスを複製して別名にするのがベストプラクティスです。 実用上、「近所」を一級の存在としたことだけで十分だと言え、それ以上は、言い過ぎの有害と分かったのです。 ポリモーフィズムではリスコフさんは先駆者でしょうけれど、そうで無い、たいていの場合のベストプラクティスのパターンでは、もっと前に先行の影響力のある研究がなされており、その内容は単なる専門学校で前から教えられていると思います。
横から失礼しますが、すくなくとも似たようなクラス間でのコード共通化のためだけにポリモーフィズムを使うのは間違いですよね。現にinterfaceではコードは排除されてます。
そんなのは継承を選ぶべきではない場面で、継承を選んだという設計ミスでしょ。継承で機能拡張することを前提に設計してないクラスを、無理に継承しようとした場合の問題。親クラスの設計が悪いなら、親クラスを先ず修正するべきです。
継承を使うべき場面なんてほとんど無いということです。継承は汎用性の高いクラスライブラリの設計で用いるべき技術であって、一般のアプリレベルで使っても、良くて自己満足、悪けりゃ大怪我ですよ。一般のアプリで継承をメンテするコストは割に合いません。
それは流石にない。単純にあなたの環境に、まともな設計ができる普通のレベルのエンジニアがいないだけ。レベルの低過ぎる初学者しかいないような環境を持ち出して、それが一般的かのように話されても困る。
interfaceは問題ありません。コード共有の手段として継承を用いることが問題なのです。
継承より移譲を用いるべきだという話を聞いたことがありませんか?
IFの実装しかできないVB6がぼこぼこにたたかれてたしなぁ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
Q:なぜ世の中にHello Worldが存在するのか (スコア:1)
A:それを書いた事があるとその言語の経験者を名乗れるから。
と思っていた事もありました。
今じゃ「書いた」じゃなくて「読んだ」ぐらいで経験者を名乗る奴もいるからなあ。
# せめてホワイトボード上で書けるぐらいには知っておけよ…
Re: (スコア:0)
オブジェクト指向で書いてるけどオブジェクト指向を説明しろっていわれたら
各処理を部品化して交換可能にすることとしか出てこなくって
体で理解しているのであって頭で理解できてねぇって気がついた
Re: (スコア:1)
構造体に関数がくっついてるだけでしょ。
Re: (スコア:0)
ポリモーフィズムこそ必須成分。
それがなければ単なるカプセル化、モジュール化に過ぎない。
Re: (スコア:0)
ポリモーフィズムはオブジェクト指向の必須要素ではないと思うなあ。
最低限、構造体に関数がくっついていればオブジェクト指向できると思うが。(データ構造とアルゴリズムの非分離)
カプセル化はさらに必須ではないな。カプセル化できないC++がオブジェクト指向を標榜してたりするし。
Re: (スコア:0)
構造体に関数がくっついてるのは関数テーブルを動的に変更したいからでしょ
例えば、Cで構造体の頭に関数テーブル置いて関数ポインタ入れておいて自力でポリモーフィズムするってのは、まれによくあるデザインパターンではあるけど
ポリモーフィズムがいらないならそんな面倒臭いことせず、関数と構造体の定義を近所に置いとくだけにして普通に関数呼んだ方がずっと分かりやすい。
Re:Q:なぜ世の中にHello Worldが存在するのか (スコア:0)
ポリモーフィズムが多くの場合、強い有害だと分かったからの話です。
継承をするとは、構造を継承するのですが、圧倒的大多数の設計では、変更とは構造の変更で
有り、ミスマッチが生じます。
たいていの場合、同じ外見のクラスを複製して別名にするのがベストプラクティスです。
実用上、「近所」を一級の存在としたことだけで十分だと言え、それ以上は、言い過ぎの
有害と分かったのです。
ポリモーフィズムではリスコフさんは先駆者でしょうけれど、そうで無い、たいていの
場合のベストプラクティスのパターンでは、もっと前に先行の影響力のある研究が
なされており、その内容は単なる専門学校で前から教えられていると思います。
Re: (スコア:0)
横から失礼しますが、すくなくとも似たようなクラス間でのコード共通化のためだけにポリモーフィズムを使うのは間違いですよね。現にinterfaceではコードは排除されてます。
Re: (スコア:0)
そんなのは継承を選ぶべきではない場面で、継承を選んだという設計ミスでしょ。
継承で機能拡張することを前提に設計してないクラスを、無理に継承しようとした場合の問題。
親クラスの設計が悪いなら、親クラスを先ず修正するべきです。
Re: (スコア:0)
継承を使うべき場面なんてほとんど無いということです。継承は汎用性の高いクラスライブラリの設計で用いるべき技術であって、一般のアプリレベルで使っても、良くて自己満足、悪けりゃ大怪我ですよ。一般のアプリで継承をメンテするコストは割に合いません。
Re: (スコア:0)
それは流石にない。
単純にあなたの環境に、まともな設計ができる普通のレベルのエンジニアがいないだけ。
レベルの低過ぎる初学者しかいないような環境を持ち出して、それが一般的かのように話されても困る。
Re: (スコア:0)
interfaceは問題ありません。コード共有の手段として継承を用いることが問題なのです。
継承より移譲を用いるべきだという話を聞いたことがありませんか?
Re: (スコア:0)
IFの実装しかできないVB6がぼこぼこにたたかれてたしなぁ