プログラミング設計の基礎について勉強しているのですが、どうしても、オブジェクト指向とモジュール設計の違いがわかりません。
どちらも、システム(プログラム全体)を機能ごとに分割して各パーツごとにプログラム設計~テストまでを行ない、完成させたパーツを組み合わせてシステムを完成させると言う解釈をしているのですが、オブジェクト指向とモジュール設計のちがいがみつけられません。
この解釈自体が間違っているのでしょうか?

このQ&Aに関連する最新のQ&A

A 回答 (3件)

オブジェクト指向設計の特徴は以下の通りです。



(1) データとその処理方法(メソッド)をひとまとまりのものとして扱います。データは原則として
  直接外部からアクセスされるのではなく、必ずメソッドを使って処理されます。
  [情報隠蔽・カプセル化・抽象データ型]
(2) 従来のやり方では、あるデータが他のデータを持っている、あるデータが他のデータに
  含まれるという関係(HasA関係)に着目して構造化を図るのが普通でしたが、オブジェクト指向設計
  では、それに加えて、あるデータというか概念が他の概念の一種特別な場合であるという関係
  (IsA関係)に着目して構造化を図ります。特別な概念は一般的な概念の持っている性質を継承します。
  [継承・導出クラス・フレーム理論]
(3) 従来のやり方では、処理の一部分、共通な処理などをサブルーチンとして独立させることにより、
  処理の構造化を図っていました。オブジェクト設計では、焦点が処理ではなくオブジェクトに
  なりますから、ある処理(メソッド)の共通部分を独立させるというよりも、その中で他の
  オブジェクトのデータの処理に関わる部分を他のオブジェクトに委託するという形になります。
  (厳格なオブジェクト指向の考え方では、オブジェクトから他のオブジェクトに送られる
  メッセージと、メッセージを送られたオブジェクトが実際に処理するメソッドを区別しますが、
  最初はそこまで意識する必要はないかもしれません。)
  [メッセージ・アクター理論]

あまり分かりやすい説明になってないですね。[]内に関連するキーワードを挙げておきましたから、
参考にして下さい。
    • good
    • 0
この回答へのお礼

お答えありがとうございます(^^
関連キーワードまであげていただいてありがとうございます。関連キーワードに注意し、キーワードについても改めて資料の読みなおし、調べなおしもしたいと思います。一応目的もあって、今勉強しているのですが、資料・概念の丸覚えよりもなるべく自分の中で理解していきたいので、キーワードはとても助かりました。

お礼日時:2001/09/20 15:46

 少なくとも単なるモジュール化には「継承」の概念はないと思います。



 もっと重要な違いは,オブジェクト指向ではデータ構造(=クラス)とアルゴリズム(=メソッド,メッセージ)が密結合している点(これを「encapsulation」と呼ぶのかな?)でしょうか。単なるモジュール化では,分割を意識して作ることはできても強制することはできませんから。
    • good
    • 0
この回答へのお礼

お答えありがとうございます(^^ お礼が遅れてすみません。
おそらく、そんな意図はなかったと思いますが、、、ちょうど一番最初にお答え頂いたymmasayanさんの「いきいきとしている」という言葉とあいまってなんとなく自分の中で霧の奥の影が濃くなってきた気がします。

お礼日時:2001/09/20 15:38

> オブジェクト指向とモジュール設計のどちらも、システム(プログラム全体)を機能ごとに分割して各パーツごとにプログラム設計~テストまでを行ない、完成させたパーツを組み合わせてシステムを完成させると言う解釈をしています。


この解釈自体が間違っているのでしょうか?

表面的に見たらよく似ていますから、解釈が間違っているわけではありません。しかし大きな違いは、「オブジェクトの特性」にあります。
オブジェクトは、あくまでも自然界(人工界も可)に存在している個体に対応して定義されたものです。だから個々のオブジェクトが生き生きと活動できます。
ところがモジュールと言うのは、設計の都合上、人間の意思で分割されたに過ぎません。モジュールは自然界の「物:オブジェクト」に対応していないのです。

この「自然界に存在する個体を忠実に表現する」「それぞれのオブジェクトが生き生きと個人主義で活動出来る」と言うのが「オブジェクト指向」です。・・・私の勝手な思い込みです。済みません。
    • good
    • 0
この回答へのお礼

お答えありがとうございます(^^ 御礼が遅くなってすみません。
うーん・・・大きな違いは「オブジェクトの特性」ですか?生き生きとしている・・・オブジェクト指向型のプログラム言語といわれるjavaとかを勉強して簡単なプログラムを組む・・・とか経験をしてみたら、なんとなくわかるようになるかなぁ。。。机上の空論をやっている今現在、なかなか感覚的なトコロが追いつけないデス。私にもっと、経験さえあれば、きっと感覚的に言ってくださった分より飲みこみやすかったとは思えるのですが、何分私自身のレベルがまだ低くて。なんだか申し訳ないです。。。

お礼日時:2001/09/20 15:32

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Qオブジェクト指向全般、及び、クラス設計について。

オブジェクト指向全般、クラス設計についての質問です。

当方、C#の日曜プログラマであり、数年まえから趣味のプログラミングを楽しんでおりました。
これまではあまりOOPに関する深い部分の理解をしないままなんとなくプログラミングをしてきましたが、このほど、そこらへんの理解を深めるべく名著と呼ばれる以下の書籍を買い漁って理解を深めようと模索しておりましたが、どうも、しっくりきません。

リファクタリング プログラミングの体質改善テクニック(マーチンファウラー)
オブジェクト指向でなぜつくるのか(平澤章)
デザインパターンとともに学ぶ オブジェクト指向のこころ(アラン・シャロウェイ)
(これ以外に名前は失念してしまいましたが、UNLの書籍も読みました)

それぞれの書籍を読んで「うん。なるほど。」というある程度の理解はできているつもりですが、如何せん、自分のコードで・・・となると、ちょうど作文の最初の一文が見つから無いときのような、そんな感覚に襲われてしまします。

これまでの自分のプログラミングというのは、「動けば良い」という部分が最優先であり、かつ、それのみにしかこだわって無かったことも原因としてはありそうです。

その中でも、特に戸惑ってしまうのが、「何をクラスにするのか」という最も基本的な部分です。

今習作として、2ch用ブラウザのコードを書いていますが
クラス候補としていくつかのものを、確信の無い状態で挙げてはみますが
ワード及び原則としての「責務」「単一責任の原則」「高凝集度」「疎結合」・・・
(それぞれの用語や原則の意味は、ある程度理解しているつもりですが)
これらの用語の海で溺れてしまっている感覚で、何をクラスとすればよいのか?という部分で
すでにアップアップしているような感じとなってしまいます。

また、個々のオブジェクトの関連において、あるオブジェクトを保持するのはどのオブジェクトである
べきか?また、あるオブジェクトにメッセージパッシングするのはどのオブジェクトであるべきなのか?等など・・・このあたりについても、一向に頭の中の霧が晴れてくれません。

このような、悩みを解消する考え方、方法、その他おすすめの書籍でも構いませんが、ご助言いただけませんでしょうか?

よろしくおねがいします。

オブジェクト指向全般、クラス設計についての質問です。

当方、C#の日曜プログラマであり、数年まえから趣味のプログラミングを楽しんでおりました。
これまではあまりOOPに関する深い部分の理解をしないままなんとなくプログラミングをしてきましたが、このほど、そこらへんの理解を深めるべく名著と呼ばれる以下の書籍を買い漁って理解を深めようと模索しておりましたが、どうも、しっくりきません。

リファクタリング プログラミングの体質改善テクニック(マーチンファウラー)
オブジェクト指向でなぜつく...続きを読む

Aベストアンサー

私も質問者さんと同じように、原則だの設計手法だのに振り回されてコードが書けなくなった経験があります。今でもたまに手が止まってしまいます。
>ちょうど作文の最初の一文が見つから無いときのような、そんな感覚に襲われてしまします。
というのは痛いほどよくわかります。
作文で手が止まってしまうのは、そもそも文章を書き慣れていないと、どうすれば相手に自分の考えが伝わるのか、それ以前に自分が何を伝えたいのかもわからない、読んだ相手がどう思うのか想像出来ないからではないでしょうか。「何を求められているのか」という判断基準そのものが無いが故に手の付け方もわからない状態です。
ソフトウェアの設計も似たようなもので、どんな機能が必要で、どんな問題が起こりうるのか、何処が頻繁に変更され、どんなコードなら自分や他人が把握しやすく、保守しやすいか、みたいなのは、最初のうちは見当つかないものです。熟考すれば出てくるものでもありません。


知識をつけると、最初は問題ではないものまで問題に見えてきます。
そうした段階で分析を行っても、書いていてモヤモヤする、何となく気持ち悪い、違和感がある、みたいな理由しかでてきません。しかし、それは本当に取り組むべき問題ではありません。
実作業に支障を来していないコードを、問題に仕立て上げようとしているだけです。
経験豊富なプログラマなら納得出来る理由を説明し、より良い解決策を提示して設計を見直すかもしれません。
しかし、改善すべき明確な理由も方向性も見えていないのなら、手のつけようがありません。
恐らく何処まで経験を積んでもそういう霧は晴れません。そもそも何が必要になるか、何が問題になるのか、みたいな予知を完全に行うことはできないからです。常に不安はつきまといますし、想定外の仕様変更なんていくらでも出てきます。具体的な形になって使い方が解ると、新たな使い道が見える事も少なくありません。そうしてソフトウェアは進化していっています。
拭いきれない違和感との戦いは終わりがないのも問題です。これこれを達成すればひとまずOKという基準を作るのも設計の一環です。
ならば、真っ先に取り組むべき問題は、書いていてイライラする、実作業に支障が出ているところです。
ある機能を呼び出すのに長~いコード何度も書かなければならなかったり、機能を追加するたびにプロジェクト中の修正を必要としたり、一見関係ないコードを修正すると頻繁にバグったり…。


私が今のところこういう状態に陥ったとき、一番巧くやれている方法は、本やネットで得た知識は一旦シャットアウトして、形にする。そして実際に使い続けてみる。また、複数の方法で作ってみて比較する、です。
そうして問題点を洗い出し、再設計を行います。
これを何度も繰り返します。
いわゆるスパイラルモデルというやつですが、「想定される問題」ではなく、プロトタイピングで「顕在化された問題」に対して取り組むのが重要だというのが私の現在の結論です。勘のきかない経験の少ないコードほどそう感じます。逆に何度も組んだことがあるコードは、繰り返し回数が減り、結果的にウォーターフォールになります。


あるオブジェクトを何処が持つべきか、見当がつかなければ、とりあえずグローバルな場所に置いておきます。
C#ならシングルトンとして作ってクラスメソッドで取得させるとか、メインフォームに置いとくとかです。
作り込んでいくうちに、全く関与しないクラス、殆ど全ての機能からアクセスされるオブジェクトなど、関連性はある程度明確になりますし、グローバルにアクセス出来るオブジェクトの問題点もそのうち直面します。
そのとき、再び本を開いてみてください。書いてある意味がまるで違うことに気がつきます。それを何回も何回も繰り返して、ようやく理解したことになるんだと思います。


だらだらとした長文で「結局経験っすよー」みたいな話ばかりで申し訳ありません。
ですが、少しでも切っ掛けが掴めれば幸いです
参考URLは私が以前した、似たような質問のURLです。ご参考までに。

参考URL:http://oshiete.goo.ne.jp/qa/4167313.html

私も質問者さんと同じように、原則だの設計手法だのに振り回されてコードが書けなくなった経験があります。今でもたまに手が止まってしまいます。
>ちょうど作文の最初の一文が見つから無いときのような、そんな感覚に襲われてしまします。
というのは痛いほどよくわかります。
作文で手が止まってしまうのは、そもそも文章を書き慣れていないと、どうすれば相手に自分の考えが伝わるのか、それ以前に自分が何を伝えたいのかもわからない、読んだ相手がどう思うのか想像出来ないからではないでしょうか。「何を求...続きを読む

Qオブジェクト指向開発とコンポーネント指向開発の違いに関して

オブジェクト指向開発から派生した開発としてコンポーネント指向開発というのがあると思いますが、それらの違いがあまりはっきりわかりません。粒度がコンポーネントの方が大きい、プラットホームに限定されない、継承などの難しい(?)概念が省かれ簡略化された部品、再利用を前提としたプラグアンドプレイができるような開発とありますが、その他にどのような特徴があるのでしょうか?わかりやすく教えてください。

Aベストアンサー

あなたのお書きになっていることで、オブジェクト指向とコンポーネント指向の違いは十分だと思いますが、まだ何か具体的な疑問点がおありでしょうか?

Qオブジェクト指向プログラミング学習向けのサンプルプログラム

「これは参考になるよ」というような、
オブジェクト指向プログラミング学習向けのサンプルプログラムを教えていただけませんか?
言語はDelphiです。
Delphiに限らず、他言語(Java、C#、C++あたり)でも結構です
(移植しますので、出来ればCUI、GUIが少ないものが理想です)
よろしくお願いいたします。

Delphiにてオブジェクト指向プログラミングを学んでいます。
書籍等で、基本的なことは学びました。
理解度およびスキルを上げるために、実際にプログラミングしたいと思います。
(入門書を利用してや、
自分で考えながらのテスト的なプログラミングには限界を感じてまして^^;)

Aベストアンサー

回答がついていないようなので、一応回答します。
残念ながら、そのような目的に最適なサンプルプログラムなるものには心当たりがありません。

しかしながら、そもそもオブジェクト指向プログラミングを学ぶ為に実際のプログラミングをしたいのであれば、サンプルをいくら見ても無駄だと思います。

オブジェクト指向において、一番重要なのは、ある問題を解決する為に、その問題領域をいかにオブジェクトとして表現できるようになるかです。
従って、学習用のテーマを自分で決めてというのではなく、そもそも実際に役にやつものや、作ってみたいものを決めて、それを実現する為にコーディングしてみるというのでなければ、何ら有用なものは身につかないのではないかと思います。
そして、行き詰まったときにこそ、他人の作ったプログラムというのが、初めて意味を為すのだと、私は思います。

こういう処理をする際のサンプル、こういう結果を出す為のサンプルというのであれば、多分あげてくれる人はたくさんいたのでしょうが、ここまで回答がついてないのは、そもそもオブジェクト指向を学ぶのに最適なプログラムなんていう漠然としたものが非常にあげにくいのもあるでしょう。

私は、Delphi(というよりObjectPascal)については良く知らないのですが、同じオブジェクト指向といっても、言語仕様によるできること出来ないことの差はことの他大きいです。Javaで作ったプログラムを、C++へ移植するとか、その逆とかは、不可能ではありませんが、そう簡単でもありません。
クラスとインスタンスの基本的な概念は良く似てても、Javaでは多重継承はできません。Perlのオブジェクト指向対応は、(あくまで個人的な主観では)中途半端で、わかりにくく、少なくともクラス思考の他の言語とは、共有できるノウハウが少ないような気がします。VisualBasic6も、表向きにはオブジェクト指向対応なる文言がありましたし、クラスを定義してインスタンス化できたからといって、私の中ではあれば、オブジェクト指向言語とは到底呼べないと思っています。私は普段Rubyを使ってますが、仕事ではJavaもC++も使う機会があります。場面によって言語の選択は変わりますが、選択はそれなりに慎重に行います。理由は、一度作り始めてしまったら、他言語への移植はとても大変だからです。

さて、私の知る限りPascalは手続き型言語の代表格です。
後付けのオブジェクト指向化は、言語仕様を破綻させないように実装するのが非常に難しいのは、PerlやVBを見るまでも無く明らかなんですが、どの程度の表現力があるか分からない以上(質問者さん自身、オブジェクト指向初心者である以上、その評価は無理でしょうし)、他言語のサンプルをいきなり使うのはとてもリスキーだと思います。

まずは、具体的に作りたいものを考えましょう。何かユーティリティの類でもいいし、ゲームでもいいです。そして、それを自分なりにオブジェクト指向チックに設計して、作ってみることです。そして、デザインパターンの本を一冊買ってきて、設計に詰まったら、それを読んでもう一度考えましょう。順番は前後しても問題ありませんが。一般的なデザインパターンの実装も、JavaにはJavaのC++にはC++なりのやり方があります。DelphiにはDelphiなりのやり方があるのではないでしょうか。

※個人的なお奨めは、目的がオブジェクト指向プログラミングなのであれば、一度JavaかRubyに浮気することです。お手軽さ感ではRubyの方がいいかもしれませんが。その上でDelphiに戻ってくれば、より広がった視野でDelphiという言語を見ることが出来るのではないかと思います。

回答がついていないようなので、一応回答します。
残念ながら、そのような目的に最適なサンプルプログラムなるものには心当たりがありません。

しかしながら、そもそもオブジェクト指向プログラミングを学ぶ為に実際のプログラミングをしたいのであれば、サンプルをいくら見ても無駄だと思います。

オブジェクト指向において、一番重要なのは、ある問題を解決する為に、その問題領域をいかにオブジェクトとして表現できるようになるかです。
従って、学習用のテーマを自分で決めてというのではなく、そも...続きを読む

Qイベントドリブンとオブジェクト指向

現役S.E.です。イベントドリブンとオブジェクト指向のことを説明する必要に迫られています。しかし、私自身知識が混乱してしまい、説明に自信がないので教えてください。

オブジェクト指向は、構造化プログラミングに変わって登場してきた考え方ですよね。クラスを設計してイベントやプロパティ、メソッドを実装してインスタンスを派生していくプログラミング方法であると認識しています。

それから、イベントドリブンはマウスでのクリックとかキーの押下などのイベントに応じて、様々なアクションを起こすという考え方だと認識しています。

それで、ちょっと考えるとイベントドリブンを実現するためには、アクションやメソッドがないと動かせないと思うので、オブジェクト指向でないと実現できないと思うのですが、構造化プログラミングなのにイベントドリブンで動かすみたいなケースってあるのでしょうか?

イベントドリブンという考え方を、オブジェクト指向と組み合わせて開設してしまっていいのかどうかがよく分からなくなってしまいました。
どんな風に解説したらいいか、アドバイス頂ければ幸いです。

現役S.E.です。イベントドリブンとオブジェクト指向のことを説明する必要に迫られています。しかし、私自身知識が混乱してしまい、説明に自信がないので教えてください。

オブジェクト指向は、構造化プログラミングに変わって登場してきた考え方ですよね。クラスを設計してイベントやプロパティ、メソッドを実装してインスタンスを派生していくプログラミング方法であると認識しています。

それから、イベントドリブンはマウスでのクリックとかキーの押下などのイベントに応じて、様々なアクションを起こす...続きを読む

Aベストアンサー

自分の回答を見直してみると分かりにくかったので補足します。

オブジェクト...
発想の出発点はデータと操作を一まとめにすることですが、さらに抽象化を進めて、とにかく何らかの機能を持ち、外部との交流手法(インターフェース)を備えたものですね。
つまり、自動車もオブジェクトです。また自動車のエンジンもオブジェクトです。

イベントドブリンは、もともとあった割り込みという概念をさらに進めて、イベントをいちいち調べて、処理の実行を行うのではなく、イベントに対する処理をあらかじめ用意しておく。
つまりイベント→処理という流れを基本とする考え方ですよね。

もちろんこの処理に対してオブジェクトを使うことはかまいませんけど、普通の関数でもいいわけですね。

私の言いたかったことはそういうことです。

Qオブジェクト指向言語について

オブジェクト指向言語における、クラス継承の動作について
ご教授ください。

クラスを継承する場合、extendsなどといったキーワードで継承の動きを
実現させるとおもいますが、継承とは、Aというクラスを丸々包含したBというクラスを作成することをいうのでしょうか?
それとも、Aというクラス内にあるpublicやprotectedメンバのみをBというクラスに引き継ぐことをいうのでしょうか?

書籍にやサイトによっては【継承とは継承もとのprivateおよびprotecetd(に準じた)メンバを派生クラスに引き継がせる】という風に解釈できる文面で記述されているものがあります。

継承とは親クラスを拡張した子クラスを作成する

と解釈できるような文面で記述された文献もあります。


伺いたいのは、クラス丸ごとを継承するのかそれともpublicおよびprotectedに準じたメンバのみを
継承するのかです。

OOPの思想や、ちょっと詳しいからといってこまごましたことを
こたえてくるような方はご遠慮ください。

Aベストアンサー

クラスを丸ごと継承します。
その中で、サブクラスからオーバーライドできるのはpublic、protectedといった
スコープのもの、というだけです。

しかしながら、継承とはコピーと同義ではありません。


人気Q&Aランキング

おすすめ情報