- - PR -
OOPがよくわかりません
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-12-09 18:36
unibon です。こんにちわ。
開発フェーズが、分析段階か、それともそれよりも後ろの段階かで、観点が違うのかもしれません。 私は、分析より後の、クラス図を書く段階やリファクタリングするあたりを考えていますが、 sakitoさんは分析に重点を置かれているようにも感じますが、いかがでしょうか。
メソッドが存在するのは、クラスが属性(フィールド)を持っているからであり、 フィールドの操作のために必要だからメソッドがあるのだと考えています。 極端な話としては、カプセル化しなくてすべてのフィールドを public にすれば、 メソッドは持たなくてもよいかもしれません。 ＃ちなみに、主体(subject)と客体(object)については、少し分かっているつもりです。
私も、分析段階では、クラスがおぼろげで属性も見えてこないことも多いので、 操作の分析が最初に必要になるのもうなずけます。 そして、操作を決めた後に属性が決まるのもうなずけますが、 属性を決めた後、もう一度操作を見直す必要があると思っています。 すなわち、最初に決めた操作は、属性を決める目的のための、仮の操作の決定であり、 属性を決定した後に、はじめて、操作が本決定になると思います。 属性がきっちりと決まらないまま、操作を決めたとしても、 クラス間の関係があいまいなままになるし、 操作も最終的に何に対する操作なのかがあいまいになってしまうように感じます。 なお、私のメタ的な大きな疑問としては、 ・このような属性や操作の決めの順序はやはりあるのか、 ・それとも、属性と操作は交互に繰り返し決めるものであり絶対の順序はないのか、 ということがあります。 | ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-09 19:04
ぼくの立場は最初の方に書いたと思いますが 「オブジェクト指向開発とはオブジェクト指向分析手法により分析しオブジェクト指向設計手法により設計し、オブジェクト指向言語により開発すること」という物です。 そして、分析・設計をかなり重要視しています。 というか極端にいえば、分析・設計こそがオブジェクト指向そのものであるという物です。 分析・設計さえオブジェクト指向でなされていればコードはそれを実装するのみです。 よって当然のようにCであろうともオブジェクト指向プログラミングは可能です。 ＃ただしここでの「可能」は東京から四国まで歩いていくことは可能の可能と ＃同じぐらいの意味ですが。。
それはオブジェクト指向ではないです。ぼくはあくまでも「OOPとは」という事を記述しているにすぎません。 属性（データ）の操作のためのメソッド（関数）というとらえ方はオブジェクト指向のものではないです。 これは関数プログラミングのものです。 ＃lispやSchemeをさわれば意味がわかるでしょう。
オブジェクト指向分析・設計手法においては一方的な流れはありえません。 分析し、設計し、さいど分析し、設計し、そして実装し・・・という流れです。 このあたりにかんしてはオブジェクト指向分析・設計手法の話になり書ききれないのでやめておきます。 あと操作こそが関係です。操作があれば関係は曖昧にはなりえません。属性が関係なのではないです。 クラスとクラスの関係は一方のクラスがもう一方のクラスを操作するというただ一点のみによりたもたれています。 その関係を集約とするかどうかは属性決定段階の分析によります。 つまりは関係が曖昧に見えるのは操作の分析が不十分だからです。 属性に関係がしばられるとクラスの再利用性が極端に低下します。 このあたりの詳細は、パターンなどを分析してみればよくわかるようになります。
分析設計においては操作が先です。 そして分析・設計の段階は一定方向に流れるものではありません。 とうぜんのように交互な繰り替えしが発生します。 それでも最初に決定されるのはつねに操作です。 属性にあまりこだわるとクラスの再利用性が低下するので、属性は外部から認識できないという分析・設計のスタンスが必要です。 参考になれば。 | ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-09 20:17
>ぼくの立場は最初の方に書いたと思いますが
>「オブジェクト指向開発とはオブジェクト指向分析手法により分析しオブジェクト >指向設計手法により設計し、オブジェクト指向言語により開発すること」という物です。 私は，オブジェクト指向プログラミングと，オブジェクト指向開発とは全く 別物だと考えています．これは，割と珍しくない見方だと思います． なんせ「オブジェクト指向」と一言に言っても様々ですから． それこそ，「並列オブジェクト指向モデル」なんてのもありましたが，OOPとは 別物でしょう．最近は誤解を招かないために「アクタモデル」という言い方の 方が主流になりつつあるようです． >それはオブジェクト指向ではないです。ぼくはあくまでも「OOPとは」という事を >記述しているにすぎません。 オブジェクト指向の名を冠したものは多々あります．それこそ，VBでさえも 自称オブジェクト指向言語だそうですから．．．．． | ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-09 21:41
こんにちは。とても面白い議論ですので参加させていただきます。
＞というか極端にいえば、分析・設計こそがオブジェクト指向そのものであるという物です。 そうですね。私もオブジェクト指向とはアイディオロジーであり、どんな言語で書いたとしても同じものだと信じています。実際、オブジェクト指向はプログラミング以外の所でも使われていますし。 ＃小僧さんが言われたようにJavaはピュアなOO言語ではないですしね。 話題の「メソッドか？データか？」ですが、これは一概に言えないかと。データとそれを利用・操作するメソッドをカプセル化されたモノがオブジェクトであり、どちらがより重要化というのは状況によると思います。例えば、インターフェイス的なモノはメソッドが命です。対照的にJavaBean的なものだと属性の方に重要点が置かれるはずです。まぁ、将来的計画や設計段階で言えばメソッドの方をきちんと固めた方が安全ですけどね。
う〜ん。分析の段階で大まかなメソッドや属性を両方とも洗い出しませんか？その後の設計や開発過程で洗い出したメソッドや属性を固めると思うのですが・・・。分析だからこっちで、開発だからこっちだけというのはしないような。 jackさん、 フレーム等を使ったGUI部分はJavaBeanなコンポーネントにすると良いですよ。ロジック部分とGUIを分けるのは基本です。研究がんばってくださいね。 
| ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-09 21:52
ぼくとは異なりますね。 ぼくとしてはオブジェクト指向開発の一部としてのオブジェクト指向プログラミングという解釈をしています。 オブジェクト指向設計・分析なくしてオブジェクト指向プログラミングは不可能だと思うからです。 だいたい分析・設計なしで実装って可能な物だとはおもえませんし。 また「オブジェクト指向」の包含する意味というか概念は各論では議論がある物の基本的な大意は一つに収束するはずです。様々なのは解釈者の無理解にすぎません。
勘違いされているようですが、「アクタモデル」という用語はそれなりに古い用語です(1970年代?)。それは「並列オブジェクト指向モデル」の源流となったモデルです。 概念的に別のモデルです。 また「並列オブジェクト指向モデル」というのはオブジェクト指向を実践する場合ほとんどの場合オブジェクトは並列に動作する、という概念をモデル化した物であり、一部はスレッドで可能です。しかしその概念すべてをスレッドで実装する事は不可能な概念です。 「並列オブジェクト指向モデル」は「モデル」ですから当然OOPとは別です。 #そもそもまったく別層の概念というか用語です。 OOPはオブジェクト指向モデルの実装化の事だと思います。
VB6と7ではやや異なりますが、VBは最低限ですがオブジェクト指向の概念を実装可能です。 よってオブジェクト指向言語といっても問題はありません。 当然何割オブジェクト指向の概念を実装可能であればオブジェクト指向言語であるという定義はぼくには不可能ですが、、 # そもそもオブジェクト指向の概念には何割とかはないので、 # Javaはオブジェクト指向言語ではない、という理論も成立します。 VBがオブジェクト指向言語として認識されないのは、オブジェクト指向分析・設計の手法を取り入れている人が小数だからにすぎません。 とうぜんまともなオブジェクト指向分析・設計があればVBをまともなオブジェクト指向言語として利用できないわけでもないです。 概念と、実装と、とにかくいろんな側面があるので、分けてかんがえないと混乱の元な気がします。 参考までに。 | ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-09 22:12
こんばんわ、YKIDです。
＃いい具合に議論が白熱してますね 
「オブジェクト指向開発」と「オブジェクト指向プログラミング」はまったく別の物だとおっしゃっていますが、その差ってなんですか？ 私の認識だと、 プログラミング ： 詳細設計 -> 実装 -> 単体テスト 開発（デベロップ） ： システムを構築する上で、運用に至るまでの全ての行為 なので『開発＞＝プログラミング』の図式になるのですが、それらの頭に「オブジェクト指向」がつくと、まったく別の方法論になっちゃうんですか？（なぞだ） ＃それはともかく、多くの人が使う「クラスを分ける」って表現が気になります。 ＃そもそもクラスって「振る舞い」や「値」を纏めたモノなのに「分ける」ことを主体に ＃置くと、纏まらないと思うんですが 
| ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-09 23:22
オブジェクト指向というのは原点的にも理論的にも現実のシミュレーションという概念なので、プログラム以外の方向に利用されるのはより普通の利用のされ方なのだと思います。
ぼくのここでの意見はやや極端な記述をしています。 実際の分析・設計においてメソッドが先とかデータが先とかをそれほど重要視しているわけではないです。 ただ分析・設計の過程において先に確定するのはいつもメソッド、という感じです。 そもそも属性に関しては、変更されてもあまり影響のない設計をしようと努力しているので、重点が低いという意識なのかもしれません。
ぼくの認識に近似ですね。ちょっとちがいますが。 ぼくは「開発⊃プログラミング」な感じです。
クラスは分ける物ぢゃないです。抽出という方が当ってるのかもしれませんが、、 ううーーん。説明しずらい。 #説明が下手なのが問題やもしれず(^_^； | ||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 03:17
はじめまして。
私はあまり語彙力がないのでヘタレな文章になってしまうかもしれませんが。。 例として「車」クラスがあります。車クラスは2000行ほどの巨大なクラスです。 車として動作する機能メソッドやメンバを持っています。 この時点でもオブジェクトといえばオブジェクトだと思いますけど、この状態だとメンテナンスが大変ですよね。メンテナンスするには車の仕組み全体を知ってないといけません。 単純に車体の色を変えたい場合も2000行あるコードのうち関連する部分を探さなくては駄目ですよね。 そこで、クラスを「分け」たいと思います。 私は基本的には対象を見る視点を変えて、変えた視点で見えるオブジェクトに再配置（再構成）することがクラスを分けることだと思っています。 たとえば、車クラスをハンドルクラスやアクセルクラス、ブレーキクラス、エンジンクラス、車体クラス、タイヤクラスといった部品に分けるとします。 そしたら、それぞれのコード量は少なくなり、役割や状態がシンプルになると思います。 # そのかわり関連が増えるので、振る舞いは複雑になりますが。 そういった分析や設計を行うことこそオブジェクト指向だと思います。 対象を物として捉え、モデリングする。 モデリングした結果が膨大なコードのクラスなのか、シンプルなクラスやコードなのかはケースバイケースだと思います。要求にあっていれば問題ないかと。 思想的にはいろいろあると思いますが、私はシンプルで構築が簡単で、プログラムを作るのが楽しい、というのをモットーにできればなぁと個人的に思います。 # デスマーチはそれはそれで心躍る、とかは抜きにして(汗 スレッドの流れから微妙にずれて駄文になってしまいました。。。 | ||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。