教えて下さい☆

分かり易く教えるつもりが、また冗長的な文章となってしまいました。

まあ、それぐらい奥の深い概念ということで。

銀行などに行けば、「通帳」や「キャッシュカード」などを用いて、「お金」の「お預け入れ」や「引き出し」に、「振り込み」などのようなサービスが利用できますよね。これをオブジェクト指向では以下のように捉えます。

「属性」（オブジェクトが持つ性質や状態）
→口座番号、支店名、銀行名、残高、振込金額、・・・

「操作」（オブジェクトの機能や振る舞い）
→お預け入れ、引き出し、振り込み、・・・

上記の各事柄を、「クラス」と呼ばれる、オブジェクトの属性や操作を定義するためのひな型みたいなものに、分類していきます。そして、いくつかのクラスが様々な『関係』を保ちながらサービスを提供していく、といった感じです。

（上記の文章内に出てくる、『関係』というのは、厳密には、「関連」や「集約」に、「汎化」などのような事をいい、いろんなクラス間の関わりを総称したもの、と捉えてください。）

よく、オブジェクト指向プログラミングと対比して使われるものの一つに、構造化プログラミングというのがあります。もちろん、Javaでもあまりオブジェクト指向の技術を利用せずに、構造化プログラミングだけで処理をしていくことは可能です。（イメージ的には、上記のような複数のクラス間の構成などではなく、でっかいクラスの中にいろんな処理が詰め込まれている、といった感じでしょうか？）ただ、それだとオブジェクト指向の利点である、「抽象化」や「再利用性」などを活かすことができなくなってしまいます。ここで一端、オブジェクト指向の手段と目的を以下にまとめておきます。

オブジェクト指向の手段→カプセル化、継承、多態性、デザインパターン、UML

オブジェクト指向の目的→抽象化、再利用性、保守性、信頼性

ここでもう一度、さっきの銀行の話に戻ります。先程では、主にATMや窓口などを想定したものでしたが、それ以外にも、最近身近なものとなった、インターネットバンキングやモバイルバンキングなどを想定した場合はどうでしょうか？取引の際の形態が多少違う位なので、それくらいでしたら、いくらかの修正や機能の追加などによって、何とか対応できるかもしれません。ただ、それとは別に今度は、株式売買や各種保険の取扱いに、クレジットカードなどのような、その他の金融サービスが出てきたらどうでしょう?それほどまでになってくると、もはやソフトウェアとしても、別のものとして作った方が良さそうですね。

そして、そのような金融関係の業務に精通した、SEの方々などが新規サービスの為の仕様を決め、分析、設計等をしていくわけですが、そこでふと、ある人がある事に気が付くんですね。

「あれっ、ちょっとまてよ。これって確か、以前にも似たようなことをしていたような覚えが・・・。」

もちろん、これはデジャブでも何でもなく、実際に以前、似たようなことをしていたのです。そして、いろいろと話し合った結果、既存システムと新規システムとの間で、共通している部分を抽象化によって抜き出せば、以前と同じように一から作り直す必要がなくなり、その一般化された共通部分を再利用することができるのではないか、という結論に至ったのです。（そのような共通部分に、もっと汎用性を持たせたのが、かの有名なGoFパターンですね。）

その共通部分を敢えて書くとすれば、以下のようになると思います。

// お金の出し入れをするだけの簡単なJavaBeans
class Kinyuu{
　private int kingaku; // 金額フィールド

　public void setKingaku(int m) { kingaku = m; } // setterメソッド
　public int getKingaku() { return kingaku; } // getterメソッド
}

実際には、業務内容とソフトウェアの規模などにより、共通部分のクラスと、特殊的な働きをするクラスのどちらも、複雑で大きなものになったりしますが、基本的にはそのようなクラスのやりとりを、上記に挙げた様々なオブジェクト指向の技術によって処理し実現していくわけです。そして、もしどこかのクラスに修正等が発生したとしても、それに該当するクラスだけを修正すればいいことにより、保守性が向上しますし、ひいてはシステム全体の信頼性も高まるということです。

システムの分析／設計の手法のひとつです。

「データと処理手続きを一体化させること」
というのは手段であって目的ではありません。


簡単にいうと、、、

従来の手法というのは、コンピュータの立場からの分析／設計でした。
しかし、仕様変更を発生させるのは人間であり、人間はコンピュータの
立場では物事をみていません。

その食い違いの結果「～の変更をしたい」というときに、「できません」とか「難しい」
といったことが起こってきます。
（システム的にそのようには出来ていない等の理由による）

そこで最初の段階から人間の観点で物事をとらえ、それをシステム化していく手法が
考え出されました。


それがオブジェクト指向です。

詳しく書くと、本が１冊出来てしまう量になってしまいますので、
詳細は入門書などを読んでください。

参考にして下さい

日本人のためのSqueakサイトの歩き方
http://www.mars.dti.ne.jp/~umejava/smalltalk/squ …

What's "Squeak"?
Dan Ingalls, Alan Kayなど、古のSmalltalk-80を開発したメンバが、今再び歴史の表舞台に立つべく集結! 既存のプログラミングの概念を飛び越える全く新しい環境を作り出してくれました。それがSqueakです
http://www.mars.dti.ne.jp/~umejava/smalltalk/squ …

オブジェクト指向とは、プログラム(システム)を作る時の考え方の一つだと考えています。

従来、システムを作る時には、その処理の流れやデータ構造を中心に考えていました。
つまり、「この処理が終わって、次にこの処理を行い・・・」とか
「データがここでこうなって、次にああなって、それで・・・」など。
ただ、そのように作られたプログラムはどうしても「プログラム的」であり、素人には分かりづらいものです。
設計書を作っても、やっぱりシステムの人間しか分からないようなシロモノでした。

で、そのような問題を解決するために、オブジェクトという「現実世界にある(ありそうな)モノ」
を中心に考えよう、という考え方が登場しました。
システムを、現実世界のモノや言葉で表すことで、より人間的に、直感的に把握しやすくなります。
そして、いろんなオブジェクトを作り、それらの連携でシステムを組み立てて行こう、ということです。

オブジェクト指向が設計にも反映されれば、素人目に見ても、理解しやすくなります。
そうすれば開発する側も、開発を依頼する側もシステムの見通しがよくなり、
効率的にシステムが作れるはずだ、という具合です。
(現実はそうも行かないようですが・・・)

オブジェクト指向としては、「現実のモノには『属性』と『機能』がある」というスタンスを取っており、
それが、プログラム要素の「データ」と「処理手続き」に置き換えられているのです。
なのでこれらが一体化されているのです。

あとは、この考え方を支えるために、「カプセル化」や「継承」なんかの概念が出てくるワケです。
この辺の細かい話は、書籍などで詳しく解説されています。

以上が、個人的な見解です。
独学で理解していったので、もしかしたら間違っているかもしれないのですが、
参考になればと思います。

入門書をお読みになるのが手っ取り早いと思います。

（例）
「いちばんやさしいオブジェクト指向の本」
井上樹著 技術評論社 技評SE新書007 \882