アカウント名:
パスワード:
オブジェクト指向の理解があればこそこ書ける言語仕様。そういったモノであれば個人的に何でもいいです。読めるコードを書くのがプロの仕事(またコードを読むのもプロの仕事)。
余談ながら読めないコードを書く人は、文法の理解だけでオブジェクト指向的な考えがない人だと思います。「オブジェクト指向の真髄は再利用性にあり」と個人的に考えておりますので。
「オブジェクト指向の真髄は再利用性にあり」と個人的に考えておりますので。
そのために抽象化やインターフェースによるカプセル化が多用されます。 抽象化することによって、それぞれの結合を疎にし、再利用性を高める。 特にデザインパターンは、まさにその真骨頂ですよね。
オブジェクト指向でも再利用性を利点と考えるのはもちろん御意なのですが、それが一番重要とは思っていません。
なんとなく、「コンポーネント指向⊂オブジェクト指向」という雰囲気がしますが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Java屋の一言 (スコア:2, すばらしい洞察)
オブジェクト指向の理解があればこそこ書ける言語仕様。そういったモノであれば個人的に何でもいいです。読めるコードを書くのがプロの仕事(またコードを読むのもプロの仕事)。
余談ながら読めないコードを書く人は、文法の理解だけでオブジェクト指向的な考えがない人だと思います。「オブジェクト指向の真髄は再利用性にあり」と個人的に考えておりますので。
コードより設計じゃないの? (スコア:2, 興味深い)
「汚い設計」で読めるコードを書くのは難しいと思いますし、Java/C++でも汚い設計をする自称プロは大勢います。
VBでも「美しい設計」であれば、読めるコードは簡単に書けると思います。
まあ、オブジェクト指向的で美しい設計が出来る人は少ないと思いますが…
問題なのは「美しい設計」であっても読めないコードを書く人です。
ある程度賢くて腕力の強い人はそうなりがちです。どう教えたら良いのやら…
Re:Java屋の一言 (スコア:1)
Re:Java屋の一言 (スコア:1)
私も真髄は再利用性だとおもいますね。
そのために抽象化やインターフェースによるカプセル化が多用されます。
抽象化することによって、それぞれの結合を疎にし、再利用性を高める。
特にデザインパターンは、まさにその真骨頂ですよね。
まあ、それをコンポーネント指向というのかどうかはしらないが
コンポーネント指向とオブジェクト指向ってどう違うんですか?
なんとなく、「コンポーネント指向⊂オブジェクト指向」という雰囲気がしますが
Re:Java屋の一言 (スコア:1)
オブジェクト指向でも再利用性を利点と考えるのはもちろん御意なのですが、それが一番重要とは思っていません。
はい、その意味で使っています。Re:Java屋の一言 (スコア:1)
良い設計が結果として高い再利用性をもたらすことはありますが、それはかならずしも主ではないと思います。
抽象化やカプセル化によって、エントロピーの増大に歯止めをかけられるというのがオブジェクト指向の嬉しいところでしょう。
Re:Java屋の一言 (スコア:1)
私はいろんなところに飛ばされてるプログラマなので、プロジェクト間で再利用できるような コードはほとんどありません。
再利用できる状況でも作り直します。
たいてい、最初に作ったものは、設計上の不満とか、心残りになっている部分が 必ずあります。似たような状況があれば、前の経験によって問題領域のパターン がはっきりしているので、すぐに単純で美しい設計が描けます。
互換性を気にせず1から作り直せる機会を得るのは精神衛生上も非常にいいです。
再利用するコードといえば、一仕事する間に溜まった、ちょっとした検証用の ジャンクコードとか簡易ツールのほうが後々役に立つことが多いです。
> 抽象化とかカプセル化の方が重要だと思います。
> その場限りの使い捨てのクラスがないとリファクタリングしにくいと思うのですが...。
その通りだと思います。
納期間近でも部屋の模様替えをするような感覚でリファクタリングできるのは きれいな抽象化・カプセル化のおかげです。
実装の継承 (スコア:1)
> クト指向だと必ずしもそうとはいえません。抽象化とかカプセル化の方が重要だと
> 思います。
ですね。
少なくとも C++ や Java では、元のコードを一切変更しないで機能を拡張するような「実装の継承」を実現するのは困難ですね。
結局、オブジェクト指向が
・ソースコードレベルでの再利用性を前提とした。
・継承を行うことで、継承元の動作を変更することが可能だった。
というのが敗因でしょうね。
私は、オブジェクト指向の反省にたって
・オブジェクトコードレベルでの再利用を想定
・コンポーネントと外部のデータ・メッセージのやり取りはインターフェイスに限定して、自律性を確保
したのがコンポーネント指向の特徴だと考えています。
# オブジェクト指向言語でも aggregation の手法を用いれば、
# ソースコードレベルでのコンポーネント指向ができるのですが、、、
コンタミは発見の母
Re:実装の継承 (スコア:1)
>> クト指向だと必ずしもそうとはいえません。抽象化とかカプセル化の方が重要だと
このスレッドのような(よく有る)話を聞くたびに、
どうして皆、Object指向という題目の下で、Object指向じゃなくClass指向の話をしているのだろう?と
不思議に思うんですが…。
OOP言語としてC++/Java系の言語の世界しかやったことがないと、こうなるんでしょうかね。
とりあえず有名どころのrubyあたりをいじっていると、OOPと隠蔽とは
実はそんなに切っても切り離せない概念では「ない」のだ、ということが
だんだん実感されてくるようになります。 (OOPと抽象化の関係についても同じ。)
そして、自分が欲しかったものが、実はOOPなのか、それとも隠蔽なのか、が
判ってくる(区別がつく)ようになります。(の筈です(^^;)。
もちろん、自分がどっちが欲しい人であっても構いません。自分を理解してさえいなければ。
#蛇足ですが、俺は90%くらいの状況において、隠蔽よりもObjectが欲しくなるタチです。
#Objectはもともと、情報を「隠蔽する」単位じゃなくて、「ぶらさげる」単位なんだよね。
#情報をかばんにつめるんじゃなくて物干し竿に吊るす感じ。
#竿を多数用意して使い分けるのがObject指向。
まあ、区別が出来なかったからといって、プログラムを書けなくなるわけじゃないですが、
そういう処があやふやになったままの人にClassを作らせたりObjectを使わせたりすると、
動くけど微妙に変な(それこそ美しくない)ものを書いたりするんで…
>結局、オブジェクト指向が
>・ソースコードレベルでの再利用性を前提とした。
>・継承を行うことで、継承元の動作を変更することが可能だった。
>というのが敗因でしょうね。
最近出てきたらしい、アスペクト指向とかいう奴は、どうでしょうか?
アスペクトは、ModuleやClassやMethodという単位を「横断」するようなコードまとめ単位を
提供してくれるそう(俺も使ったこと無いんで…)なので、もしかしてお望みの理想に近いかも。
>私は、オブジェクト指向の反省にたって
>・オブジェクトコードレベルでの再利用を想定
>・コンポーネントと外部のデータ・メッセージのやり取りはインターフェイスに限定して、自律性を確保
>したのがコンポーネント指向の特徴だと考えています。
「十分に」案件非依存に作られたClassは、他所でも再利用できます。(の筈です(^^;)。
問題は、どこが十分のラインなのかを判定する能力(の不足)と、
その能力を発揮する時間(^^;を案件が許してくれるか(が怪しい)、という二点によって、
そういうClassを作ることがしばしば事実上制限されるっていう点じゃないかな。
時間のあるときに(^^;、VBやDelphiのGUI部品みたいなClassを自分で作ってみれば
(GUIであることは本質ではなく、ここで問題なのは「どんなプログラムでも使える」点。
だから作るのはRAD環境専用のClassである必要はありません)、なにかが判ると思います。
あと、人を統べる側の立場の人には、可能な限り、「Componentを」作ろうとすることをやめさせないで欲しいな(^^;。
今直接は役立たないかも知れないけど、そういう方向を志向することは、プログラマとしての腕を上げる効果はあると思うので。
案件非依存化(ある種の抽象化)ってのは重要な(鍛えさせるに値する)能力だと思う。
なおComponentの定義については、俺は上記に加えて、ComponentのClassやObjectの側から
「自己紹介」する能力も、必須として欲しいと思っています。コード上でメタ機能が使えるのが望ましい。
いくつかの言語では最初から備え付けの機能なので、いちいち意識しなくてもいいかも知れませんが。
Re:実装の継承 (スコア:1)
> >> クト指向だと必ずしもそうとはいえません。抽象化とかカプセル化の方が重要だと
>
> このスレッドのような(よく有る)話を聞くたびに、
> どうして皆、Object指向という題目の下で、Object指向じゃなくClass指向の話をしているのだ
> ろう?と不思議に思うんですが…。
> OOP言語としてC++/Java系の言語の世界しかやったことがないと、こうなるんでしょうかね。
隠蔽(カプセル化)は抽象言語がはじめた(はず)。
オブジェクト指向型言語と抽象言語を区別しているのは、多態性がありなしですね。
つまりオブジェクトによって異なる振る舞いをするメッセージ応答機構があること。
また オブジェクトの多態性を効率よく実現するために、継承やそれに似た機能を持ちますね。
抽象化は多態性と隠蔽の機能を組み合わせて実現するものですね。
問題になっている「オブジェクト指向型言語はコードの再利用性が高くない」と言説は、オブジェクト指向型言語がコードの書き方によって多態性がかえって再利用性を下げることが多いためだと思います。
これは多態性を実現する継承機構の中に、インターフェイスのためのものと、実装を継承するための機構が混ざっているのが原因です。結局、C++ などで再利用性の高い class を書くためには、プログラマがこの 2種類を区別して、設計・実装を進める必要があります。
ただ、この区別をプログラマのみに任せにする危険なので、コンポーネントという枠組みを用意して、コンポーネントを越えて実装のための継承を行うことを禁じてしまったのがコンポーネント指向なのではないでしょうか?Java のイメージで言えば、interface と class を切り分けて、interface のみを外部にさらせるようなイメージですね。
# 実装を継承したかったら aggregation して forwarding せよと...
> なおComponentの定義については、俺は上記に加えて、ComponentのClassやObjectの側から
> 「自己紹介」する能力も、必須として欲しいと思っています。コード上でメタ機能が使えるのが
> 望ましい。
この説明 [waseda.ac.jp]では、RAD ツールとの連携も必要といっています。
#「部品市場の形成」を挙げるのはご愛嬌。
> いくつかの言語では最初から備え付けの機能なので、いちいち意識しなくてもいいかも
> 知れませんが。
C++ 以外の現代的なオブジェクト指向は reflection というか introspection の機能を大概持っていますね。
> 最近出てきたらしい、アスペクト指向とかいう奴は、どうでしょうか?
>
> アスペクトは、ModuleやClassやMethodという単位を「横断」するようなコードまとめ単位を
> 提供してくれるそう(俺も使ったこと無いんで…)なので、もしかしてお望みの理想に近いかも。
私もコーディングしたことがないので実感は掴めていませんが、
アスペクト指向はコンポーネント指向とは、反対(135°ぐらい?) を向いているようなイメージを
持っています。
アスペクト指向 ← オブジェクト思考 → コンポーネント指向
コンタミは発見の母
Re:実装の継承 (スコア:1)
>私は、オブジェクト指向の反省にたって
>・オブジェクトコードレベルでの再利用を想定
>・コンポーネントと外部のデータ・メッセージのやり取りはインターフェイスに限定して、自律性を確保
>したのがコンポーネント指向の特徴だと考えています。
コンポーネント指向の目的はおっしゃるとおりで、それが実現すれば幸せだなぁ、と思うのですが
本当に再利用可能なコンポーネントを作るのは再利用可能なオブジェクトを作るよりも
現段階でははるかに難しいような気がしています。
完全にブラックボックスなコンポーネントだと、柔軟性が無さ過ぎて、プラットフォームの多様性を吸収しきれません。
かといってホワイトボックスなコンポーネントだとソースコードレベルで変更ができてしまい
自律性が著しく下がってしまいます。
なので、コンポーネントをグレーボックスにしてメタインターフェースを通じて
様々な状況に柔軟に対応できるコンポーネントを作れれば、再利用性も上がるし、自律性も保たれて幸せ。
のはずなんですが、そんなコンポーネントを作るのは凄く難しいです。
作った、と思っても実は再利用性が無かったという自体も少なくないでしょう。
こんな事態を解決できる新しいパラダイムはないもんですかね。
大学での教育 (スコア:1)
それまでコードを書いたことのない大学一年生に、いきなりオブジェクト指向云々を言っても理解不能ですので、結局アプレットで遊んで終わってるのが実状じゃないでしょうか。その後の研究で何かしら使うことを考えると、
個人的には何か一つやるんだったらCやPascalでやればいいのに、と思います。
# 二つ目の言語からは使い物になる(可能性がある)のでJavaプログラマーの平均レベル上がるかも。
# 間口が狭くなるっておまけつきだけど…。
Re:Java屋の一言 (スコア:1)
今ならもちっとマシなコードが書けます。
すらど宴会SNS開放中 [e-meet.jp]