アカウント名:
パスワード:
A:それを書いた事があるとその言語の経験者を名乗れるから。
と思っていた事もありました。今じゃ「書いた」じゃなくて「読んだ」ぐらいで経験者を名乗る奴もいるからなあ。
# せめてホワイトボード上で書けるぐらいには知っておけよ…
せめてFizzBuzzで
> # せめてホワイトボード上で書けるぐらいには
えーと、パブリック、ステイティック、ヴォイド、メインだっけ?
main関数の戻り値はintかvoidかで喧嘩が起こるからそういうことは不用意に言わないでほしい。
public static void main(string[] args) {} なので、Javaの話かと。C言語だとANSI準拠だとint mainでしたっけ？
自立処理系なら何でもありです。
召喚呪文ってやつですか？
召喚呪文なら「mallocしたメモリは、プログラム終了前にfreeしなければならない」じゃないの?
そういう話しなのですね
static /stˈæṭɪk/ をステイティックと表記するのか……
ディスクトップみたいに、日本語的な読みをアレンジしちゃう派かな
中華料理屋丸テーブル上の回転台？
# あれ本国には無くて、日本で発明されたそうです。
status から類推したのだろうか。
マーマー、チャント、プレイ、インボーク！でしょ？
「世界と挨拶できる習熟度」とか書けば非ITな人には大物に見えるかもしれない。
オブジェクト指向で書いてるけどオブジェクト指向を説明しろっていわれたら各処理を部品化して交換可能にすることとしか出てこなくって体で理解しているのであって頭で理解できてねぇって気がついた
構造体に関数がくっついてるだけでしょ。
現実世界を「抽象化」してモデリングすることだよ！Σ(ﾟДﾟ；≡；ﾟдﾟ)
迷著 「憂鬱な（以下省略）
最初はそのように考えて頭を悩ませていましたが、そんなのは実現困難な理想論で役に立たない。現実のモデルとは無関係に、ソフトウェアの構築を効率良く行う使い方をするのが理想的。デザインパターンなんて、ソフトウェア実装の都合の塊で、現実のモデルとはかけ離れていますしね。
SOLID原則を持っている人間はなににでもSOLID原則で回したがる、みたいな？
そりゃあ、SOLID原則を言いたい人間にとっては「ポリモーフィズムこそ必須成分」なんでしょうけれど、それは本末転倒でしょ。
適用するのに必要な場合（適用する場合がかなり限られている）に原則は使うべきで、常に原則を使いたいから、その原則の前提は必須だというのは倒錯です。
原則って言うからには、デフォルトで適用するものであって適用しないことが必要である場合にのみ、例外を検討するべきものですよそうすることによって検討のコストを下げることができるから、原則と呼ぶに値するのですいちいち「この原則は適用が必要だろうか」なんて考えるようでは、それこそ本末転倒でしょうね
まぁそのこととSOLID原則が原則足りうるかどうかは別の話ですが
ポリモーフィズムはオブジェクト指向の必須要素ではないと思うなあ。最低限、構造体に関数がくっついていればオブジェクト指向できると思うが。（データ構造とアルゴリズムの非分離）カプセル化はさらに必須ではないな。カプセル化できないC++がオブジェクト指向を標榜してたりするし。
構造体に関数がくっついて実現されるのはデータ抽象化というやつです。カプセル化もそうです。
オブジェクト指向というからには、データ抽象化でないなにか(ポリモーフィズム)があるということなんですよ。
オブジェクト指向プログラミングは、オブジェクト指向言語を使わなくても可能ですし、オブジェクト指向言語を使ったからといってオブジェクト指向プログラミングになるとは限らないというのが世間の常識です
そのとおりですが、何の反論にも同意にもなってませんね。何が言いたいのだろう?
オブジェクト指向「言語」の話なんて誰もしてないよ。オブジェクト指向とかデータ抽象化の話をしています。
ポリモーフィズムって言語の話でしょうが
> オブジェクト指向プログラミングは、オブジェクト指向言語を使わなくても可能ですし
止めて。絶対に止めて。それでどれだけ死にそうになった事か。
ポリモーフィズムが多くの場合、強い有害だと分かったからの話です。継承をするとは、構造を継承するのですが、圧倒的大多数の設計では、変更とは構造の変更で有り、ミスマッチが生じます。たいていの場合、同じ外見のクラスを複製して別名にするのがベストプラクティスです。 実用上、「近所」を一級の存在としたことだけで十分だと言え、それ以上は、言い過ぎの有害と分かったのです。 ポリモーフィズムではリスコフさんは先駆者でしょうけれど、そうで無い、たいていの場合のベストプラクティスのパターンでは、もっと前に先行の影響力のある研究がなされており、その内容は単なる専門学校で前から教えられていると思います。
横から失礼しますが、すくなくとも似たようなクラス間でのコード共通化のためだけにポリモーフィズムを使うのは間違いですよね。現にinterfaceではコードは排除されてます。
そんなのは継承を選ぶべきではない場面で、継承を選んだという設計ミスでしょ。継承で機能拡張することを前提に設計してないクラスを、無理に継承しようとした場合の問題。親クラスの設計が悪いなら、親クラスを先ず修正するべきです。
継承を使うべき場面なんてほとんど無いということです。継承は汎用性の高いクラスライブラリの設計で用いるべき技術であって、一般のアプリレベルで使っても、良くて自己満足、悪けりゃ大怪我ですよ。一般のアプリで継承をメンテするコストは割に合いません。
それは流石にない。単純にあなたの環境に、まともな設計ができる普通のレベルのエンジニアがいないだけ。レベルの低過ぎる初学者しかいないような環境を持ち出して、それが一般的かのように話されても困る。
interfaceは問題ありません。コード共有の手段として継承を用いることが問題なのです。
継承より移譲を用いるべきだという話を聞いたことがありませんか？
IFの実装しかできないVB6がぼこぼこにたたかれてたしなぁ
その認識は間違っていると断言します。カプセル化こそオブジェクト指向の本質です。
ソフト部品の作り手と使い手の責務を実装のレベルで分割してソフトの共同開発を可能にしたのがオブジェクト指向の本質です。
誤解を恐れずにいうとアクセサこそオブジェクト指向の本質であり、いわゆるオブジェクト指向言語でなくてもできることです。
ポリモーフィズムは応用レベルの話であり必須ではありません。
そうなんだけど、まず「構造体」を知らないからそこの説明から必要になる
そういや確か、C++の構造体はCの構造体そのままじゃなくて、Cの構造体を拡張した新概念「クラス」の特殊な例、って感じで定義し直されていなかったっけ。「構造体」の定義の仕方次第ではオブジェクト指向とで循環定義になる危険性がありそう。
＃C++をそもそも引き合いに出すなってご指摘は百も承知の上で
つまり、理解しなくてもコード書けちゃうって言いたいんだね？
いや、型で覚えてるこれはこうでこうだからこうしとくとこことここの変更に強くなるからこうしておこうここにこれをこうすると変更に弱いからやめようここをこうしてしまうとテストがやりづらいからこうしておこうSOLID原則的な、そういう原則論で考えているだけで
オブジェクト指向って何よって言われたら部品化でしょ？データと処理とを分離してって話でしょ？みたいなの
目的思考があっていいんじゃないのwww目的を見失って、オブジェクト指向的に正しいからって無駄な作業増やしてる人も多いからなぁ
このコメントやここに連なるコメントみて思ったstaticおじさんって特定個人に限らないんだなと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
Q:なぜ世の中にHello Worldが存在するのか (スコア:1)
A:それを書いた事があるとその言語の経験者を名乗れるから。
と思っていた事もありました。
今じゃ「書いた」じゃなくて「読んだ」ぐらいで経験者を名乗る奴もいるからなあ。
# せめてホワイトボード上で書けるぐらいには知っておけよ…
Re:Q:なぜ世の中にHello Worldが存在するのか (スコア:1)
せめてFizzBuzzで
Re: (スコア:0)
> # せめてホワイトボード上で書けるぐらいには
えーと、パブリック、ステイティック、ヴォイド、メインだっけ?
Re: (スコア:0)
main関数の戻り値はintかvoidかで喧嘩が起こるからそういうことは不用意に言わないでほしい。
Re: (スコア:0)
public static void main(string[] args) {} なので、Javaの話かと。
C言語だとANSI準拠だとint mainでしたっけ？
Re: (スコア:0)
自立処理系なら何でもありです。
Re: (スコア:0)
召喚呪文ってやつですか？
Re: (スコア:0)
召喚呪文なら「mallocしたメモリは、プログラム終了前にfreeしなければならない」
じゃないの?
Re: (スコア:0)
そういう話しなのですね
Re: (スコア:0)
static /stˈæṭɪk/ をステイティックと表記するのか……
Re: (スコア:0)
ディスクトップみたいに、日本語的な読みをアレンジしちゃう派かな
Re: (スコア:0)
中華料理屋丸テーブル上の回転台？
# あれ本国には無くて、日本で発明されたそうです。
Re: (スコア:0)
status から類推したのだろうか。
Re: (スコア:0)
マーマー、チャント、プレイ、インボーク！でしょ？
Re: (スコア:0)
「世界と挨拶できる習熟度」とか書けば非ITな人には大物に見えるかもしれない。
Re: (スコア:0)
オブジェクト指向で書いてるけどオブジェクト指向を説明しろっていわれたら
各処理を部品化して交換可能にすることとしか出てこなくって
体で理解しているのであって頭で理解できてねぇって気がついた
Re:Q:なぜ世の中にHello Worldが存在するのか (スコア:1)
構造体に関数がくっついてるだけでしょ。
Re: (スコア:0)
現実世界を「抽象化」してモデリングすることだよ！
Σ(ﾟДﾟ；≡；ﾟдﾟ)
迷著 「憂鬱な（以下省略）
Re: (スコア:0)
最初はそのように考えて頭を悩ませていましたが、そんなのは実現困難な理想論で役に立たない。
現実のモデルとは無関係に、ソフトウェアの構築を効率良く行う使い方をするのが理想的。
デザインパターンなんて、ソフトウェア実装の都合の塊で、現実のモデルとはかけ離れていますしね。
Re: (スコア:0)
ポリモーフィズムこそ必須成分。
それがなければ単なるカプセル化、モジュール化に過ぎない。
Re: (スコア:0)
SOLID原則を持っている人間はなににでもSOLID原則で回したがる、みたいな？
そりゃあ、SOLID原則を言いたい人間にとっては「ポリモーフィズムこそ必須成分」
なんでしょうけれど、それは本末転倒でしょ。
適用するのに必要な場合（適用する場合がかなり限られている）に原則は使うべきで、
常に原則を使いたいから、その原則の前提は必須だというのは倒錯です。
Re: (スコア:0)
原則って言うからには、デフォルトで適用するものであって
適用しないことが必要である場合にのみ、例外を検討するべきものですよ
そうすることによって検討のコストを下げることができるから、原則と呼ぶに値するのです
いちいち「この原則は適用が必要だろうか」なんて考えるようでは、それこそ本末転倒でしょうね
まぁそのこととSOLID原則が原則足りうるかどうかは別の話ですが
Re: (スコア:0)
ポリモーフィズムはオブジェクト指向の必須要素ではないと思うなあ。
最低限、構造体に関数がくっついていればオブジェクト指向できると思うが。（データ構造とアルゴリズムの非分離）
カプセル化はさらに必須ではないな。カプセル化できないC++がオブジェクト指向を標榜してたりするし。
Re:Q:なぜ世の中にHello Worldが存在するのか (スコア:1)
構造体に関数がくっついて実現されるのはデータ抽象化というやつです。
カプセル化もそうです。
オブジェクト指向というからには、データ抽象化でないなにか(ポリモーフィズム)が
あるということなんですよ。
Re: (スコア:0)
オブジェクト指向プログラミングは、オブジェクト指向言語を使わなくても可能ですし、オブジェクト指向言語を使ったからといってオブジェクト指向プログラミングになるとは限らないというのが世間の常識です
Re: (スコア:0)
そのとおりですが、何の反論にも同意にもなってませんね。
何が言いたいのだろう?
オブジェクト指向「言語」の話なんて誰もしてないよ。
オブジェクト指向とかデータ抽象化の話をしています。
Re: (スコア:0)
多くの技術力に乏しいソフトウェア開発の現場ではそれを指してオブジェクト指向と呼んでいる。
オブジェクト指向いらないおじさんの本当の主張は、
オブジェクト指向をしたくないということでない(そもそもオブジェクト指向が何かよく分かんないし)。
オブジェクト指向言語を使わなくてもデータ抽象はできるし、データ抽象の原則を崩したいときに言語仕様がその障害になるからオブジェクト指向言語(またはそのような言語の機能)を使いたくない
ということ
Re: (スコア:0)
ポリモーフィズムって言語の話でしょうが
Re: (スコア:0)
> オブジェクト指向プログラミングは、オブジェクト指向言語を使わなくても可能ですし
止めて。絶対に止めて。それでどれだけ死にそうになった事か。
Re: (スコア:0)
構造体に関数がくっついてるのは関数テーブルを動的に変更したいからでしょ
例えば、Cで構造体の頭に関数テーブル置いて関数ポインタ入れておいて自力でポリモーフィズムするってのは、まれによくあるデザインパターンではあるけど
ポリモーフィズムがいらないならそんな面倒臭いことせず、関数と構造体の定義を近所に置いとくだけにして普通に関数呼んだ方がずっと分かりやすい。
Re: (スコア:0)
ポリモーフィズムが多くの場合、強い有害だと分かったからの話です。
継承をするとは、構造を継承するのですが、圧倒的大多数の設計では、変更とは構造の変更で
有り、ミスマッチが生じます。
たいていの場合、同じ外見のクラスを複製して別名にするのがベストプラクティスです。
実用上、「近所」を一級の存在としたことだけで十分だと言え、それ以上は、言い過ぎの
有害と分かったのです。
ポリモーフィズムではリスコフさんは先駆者でしょうけれど、そうで無い、たいていの
場合のベストプラクティスのパターンでは、もっと前に先行の影響力のある研究が
なされており、その内容は単なる専門学校で前から教えられていると思います。
Re: (スコア:0)
横から失礼しますが、すくなくとも似たようなクラス間でのコード共通化のためだけにポリモーフィズムを使うのは間違いですよね。現にinterfaceではコードは排除されてます。
Re: (スコア:0)
そんなのは継承を選ぶべきではない場面で、継承を選んだという設計ミスでしょ。
継承で機能拡張することを前提に設計してないクラスを、無理に継承しようとした場合の問題。
親クラスの設計が悪いなら、親クラスを先ず修正するべきです。
Re: (スコア:0)
継承を使うべき場面なんてほとんど無いということです。継承は汎用性の高いクラスライブラリの設計で用いるべき技術であって、一般のアプリレベルで使っても、良くて自己満足、悪けりゃ大怪我ですよ。一般のアプリで継承をメンテするコストは割に合いません。
Re: (スコア:0)
それは流石にない。
単純にあなたの環境に、まともな設計ができる普通のレベルのエンジニアがいないだけ。
レベルの低過ぎる初学者しかいないような環境を持ち出して、それが一般的かのように話されても困る。
Re: (スコア:0)
interfaceは問題ありません。コード共有の手段として継承を用いることが問題なのです。
継承より移譲を用いるべきだという話を聞いたことがありませんか？
Re: (スコア:0)
IFの実装しかできないVB6がぼこぼこにたたかれてたしなぁ
Re: (スコア:0)
その認識は間違っていると断言します。
カプセル化こそオブジェクト指向の本質です。
ソフト部品の作り手と使い手の責務を実装のレベルで分割してソフトの共同開発を可能にしたのがオブジェクト指向の本質です。
誤解を恐れずにいうとアクセサこそオブジェクト指向の本質であり、いわゆるオブジェクト指向言語でなくてもできることです。
ポリモーフィズムは応用レベルの話であり必須ではありません。
Re: (スコア:0)
そうなんだけど、まず「構造体」を知らないからそこの説明から必要になる
Re: (スコア:0)
そういや確か、C++の構造体はCの構造体そのままじゃなくて、Cの構造体を拡張した新概念「クラス」の
特殊な例、って感じで定義し直されていなかったっけ。
「構造体」の定義の仕方次第ではオブジェクト指向とで循環定義になる危険性がありそう。
＃C++をそもそも引き合いに出すなってご指摘は百も承知の上で
Re: (スコア:0)
C++のクラスが仮想関数を持つ場合に限り、先頭要素にvtableが勝手に挿入される、というだけ。
Re: (スコア:0)
つまり、理解しなくてもコード書けちゃうって言いたいんだね？
Re: (スコア:0)
いや、型で覚えてる
これはこうでこうだからこうしとくとこことここの変更に強くなるからこうしておこう
ここにこれをこうすると変更に弱いからやめよう
ここをこうしてしまうとテストがやりづらいからこうしておこう
SOLID原則的な、そういう原則論で考えているだけで
オブジェクト指向って何よって言われたら部品化でしょ？
データと処理とを分離してって話でしょ？みたいなの
Re: (スコア:0)
目的思考があっていいんじゃないのwww
目的を見失って、オブジェクト指向的に正しいからって無駄な作業増やしてる人も多いからなぁ
Re: (スコア:0)
このコメントやここに連なるコメントみて思った
staticおじさんって特定個人に限らないんだなと