アカウント名:
パスワード:
向き不向きがあるからな。(分野的に)どちらかというと、不向きなものの方が相当程度に多いにも係わらず、最近は、闇雲に採用したがるア○が多くて困ります。
そのせいかどうかしらんが、ア○PGがおおくなった。
不向きって例えば?
個人的には、Perlでプログラムを書くときなんかはごく小規模なものとか書き捨てで将来絶対改修や再利用しないとわかってるようなものはOOpで書かないけど。処理内容に比してなんだか大げさな書き方になってしまうから。
あと思いつくのはパフォーマンスが優先されるような分野だけどそういうところではOOpはまだ忌避されてるのかな。
> オブジェクト指向が不向きというりゆうが分からない。
ピュアなオブジェクト指向ではifやwhileのような制御構文がなく、メッセージングで代わりをさせる必要があります。それでは不便なのでJavaなどでは手続き指向言語から制御構文を借りてきているわけです。
> パズルって。
例につっこむのもどうかしていると思いますが、実世界では制約解消系のアプリケーションはとても重要なのです。配線やスケジューリングなど。
> これは「とにかくドメインスペシフィックなものはなんでもオブジェクト指向は不向きなのっ」っていう主張だと受け取って良い?
そうです。ピュアなオブジェクト指向はドメインスペシフィックなものをほとんど取りこぼします。ですから実際の言語ではハイブリッドなのです。(太字筆者)
例えば、a + b + cという数式をメッセージングによって表現すると、加算の可換性や結合性を取りこぼしてしまいます。
わかってて住んでる世界が違う(定義がちがう)話をしているなんていけずなACですね。世間ではオブジェクト指向言語って、ピュアオブジェクト指向ではなくて、データ隠蔽とかデータ・手続きのカプセル化とかその程度のハナシだというのも、わかってて言ってるでしょ。
アカデミア (と一部のソフトウェア工学者が対象としている「実世界」) とプラクティショナーの会話が成立しない、っつーのがこの分野の不幸の一つだと思う。
# 社会人学生なのでどっちの事情もちょっとわかる
ここでの違いは、プラットフォームの切り替えの責任を誰が負っているかです。JavaであればGraphicsFactoryオブジェクトであり、Cであればコンパイルする人です。純粋なオブジェクト指向は「コンパイルする人」というメタなものの扱いが苦手だということがおわかりかと思います。
機種依存を排除するためのJava VMとJITですから、バイトコードが機種依存というのでは、Javaを使うメリットが半減します。そもそもOSを意識しなくても書けるようになっているので、Cなら機種ごとに書かなければいけない部分も、Javaでは書く必要がないことが多いと思います。
Javaでも環境を意識する必要はありますが、Cでも、コンパイル時に解決できない(or しない)環境依存の部分は動的に解決するしかないですよね。動的に決定するものは、オブジェクト指向の方が楽だと思いますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
オブジェクト指向言語は (スコア:0)
向き不向きがあるからな。(分野的に)
どちらかというと、不向きなものの方が相当程度に多いにも係わらず、
最近は、闇雲に採用したがるア○が多くて困ります。
そのせいかどうかしらんが、ア○PGがおおくなった。
Re: (スコア:0)
不向きって例えば?
個人的には、Perlでプログラムを書くときなんかは
ごく小規模なものとか
書き捨てで将来絶対改修や再利用しないとわかってるようなものは
OOpで書かないけど。
処理内容に比してなんだか大げさな書き方になってしまうから。
あと思いつくのはパフォーマンスが優先されるような分野だけど
そういうところではOOpはまだ忌避されてるのかな。
Re: (スコア:0)
手順が重要なもの(数値演算やシーケンサーなど)
関係や制約が重要なもの(パズルなど)
アスペクト的なもの、ドメインスペシフィックなもの一般
Re: (スコア:0)
オブジェクト指向が不向きというりゆうが分からない。
オブジェクト指向じゃなくても作れるじゃんっていう主張ならわかるけど。
> 関係や制約が重要なもの(パズルなど)
パズルって。
学校の授業や趣味プログラミングじゃないんだから。。。
> アスペクト的なもの、
アスペクト的なものをオブジェクト指向で表現するのが難しいのはその通り。
ただ、アスペクト指向とオブジェクト指向は対立するものじゃないから。
> ドメインスペシフィックなもの一般
これは「とにかくなんでもオブジェクト指向は不向きなのっ」っていう主張だと受け取って良い?
Re: (スコア:0)
> オブジェクト指向が不向きというりゆうが分からない。
ピュアなオブジェクト指向ではifやwhileのような制御構文がなく、メッセージングで代わりをさせる必要があります。
それでは不便なのでJavaなどでは手続き指向言語から制御構文を借りてきているわけです。
> パズルって。
例につっこむのもどうかしていると思いますが、実世界では制約解消系のアプリケーションはとても重要なのです。配線やスケジューリングなど。
> これは「とにかくドメインスペシフィックなものはなんでもオブジェクト指向は不向きなのっ」っていう主張だと受け取って良い?
そうです。ピュアなオブジェクト指向はドメインスペシフィックなものをほとんど取りこぼします。ですから実際の言語ではハイブリッドなのです。(太字筆者)
例えば、a + b + cという数式をメッセージングによって表現すると、加算の可換性や結合性を取りこぼしてしまいます。
Re: (スコア:1, 参考になる)
わかってて住んでる世界が違う(定義がちがう)話をしているなんていけずなACですね。
世間ではオブジェクト指向言語って、ピュアオブジェクト指向ではなくて、データ隠蔽とかデータ・手続きのカプセル化とかその程度のハナシだというのも、わかってて言ってるでしょ。
アカデミア (と一部のソフトウェア工学者が対象としている「実世界」) とプラクティショナーの会話が成立しない、っつーのがこの分野の不幸の一つだと思う。
# 社会人学生なのでどっちの事情もちょっとわかる
Re: (スコア:1, 興味深い)
そういうハナシも認識はしていますが、せっかくのオブジェクト指向がデータ抽象化に退化しちゃっているのも、オブジェクト指向が向いていない領域がある証左だと思います。
たとえばJavaではオブジェクトがあるから構造体は不要として排除していますが(そういう意味ではピュアなオブジェクト指向っぽい)、不便だと思いませんか?
よりモダンなC#にもDにもGoにもあります。
Cでマクロと分割コンパイルでプラガブルモ
Re: (スコア:0)
#オブジェクトの生成はファクトリが行うというのを原則としてしまうのは
#デザパタに毒されすぎじゃないかと。
Re: (スコア:1, 参考になる)
べつにGraphisクラスでも構いませんが、実行時に何らかのオブジェクトが描画主体のGraphicsオブジェクトを生成するする必要があります。(大文字にしてしまいましたが、意図としてはファクトリーオブジェクトです)
Cではソースに手を入れなくてもコンパイルオプション-DWIN32などで切り替えられます。もちろん動的に変更することはできませんが、同一のソースで異なるプラットフォーム用にコンパイルしたいいうことであればこれで十分でしょう。
ここでの違いは、プラットフォームの切り替えの責任
Re: (スコア:0)
機種依存を排除するためのJava VMとJITですから、バイトコードが機種依存というのでは、Javaを使うメリットが半減します。そもそもOSを意識しなくても書けるようになっているので、Cなら機種ごとに書かなければいけない部分も、Javaでは書く必要がないことが多いと思います。
Javaでも環境を意識する必要はありますが、Cでも、コンパイル時に解決できない(or しない)環境依存の部分は動的に解決するしかないですよね。動的に決定するものは、オブジェクト指向の方が楽だと思いますよ。
Re: (スコア:0)
> 動的に決定するものは、オブジェクト指向の方が楽だと思いますよ。
オブジェクト指向のほうが楽なことが多いことは否定しません。オブジェクト指向が苦手な動的なことがらもあると主張しています。
ただのフックや関数ポインタやデレゲートが欲しいときでも、Javaなどではオブジェクトをでっちあげる必要がありますよね。
Smalltalkのブロックなどは、インプリシットに規定される「環境」を持ち、メッセージパッシングから外れた不純物です。
Re:オブジェクト指向言語は (スコア:0)
Re: (スコア:0)
なぜならループは逐次的な制御ですが、関数型パラダイムでは逐次実行という概念がありませんから、状態をすべて引数で受け渡す必要があります。俺はこんなことがしたいんじゃないんだ感はバリバリですよ。
むろん再帰がフィットする局面も多いです。
Re: (スコア:0)
しかしモナドといえば難解で有名ですから、お世辞にも「Haskellは逐次処理が得意」とは言えないでしょう。
(できるから偉いと言い出せばアセンブリ言語最強になってしまいます)
マップのような非ループ的なもので方がつくことのほうが多いでしょうけどね。
Re: (スコア:0)
両者ともJavaより新しい言語であり、そういう非オブジェクトが「やっぱり必要」だと判断されたわけでしょう。
ですからJavaでは非オブジェクト的なものをオブジェクトで書かざるを得ないがためのオブジェクトのでっち上げといって差し支えはないでしょう。