コンポーネント指向って、どのような理念の元に作られたものですか？？ 何が聞きたいのかというと、例え

コンポーネント指向って、どのような理念の元に作られたものですか？？

何が聞きたいのかというと、例えばオブジェクト指向に関して。
オブジェクト指向とは、オブジェクトを中心にデーター（フィールド,etc…）、メソッドをまとめクラスで定義したうんぬん…とプログラミング入門書に書いてあります。まぁ、わかるんですが。でも一番素晴らしいなと思ったのは、こんな感じの以下の説明でした。（参考　スッキリわかるJava入門）
オブジェクト指向とは、メモリ上にあたかも実体が存在するように再現すること。つまり、現実世界を模するバーチャルの世界をよりリアルにする手法。
そんな感じの、理念がかかれてました（様な解釈をしました）。
何かロマンチックだなと思いました。メモリ空間上にあたかも命があるようなインスタンスを生成しちゃえる様な夢のある考え方の理念があるなと。

コンポーネント指向も、こんな夢のある話がさらに進化した話なんですか？
それってどんな話ですか？
なんかうまく質問できなくてすみません。

質問者からの補足コメント

• 注:回答は回答で待ってますw

    補足日時：2016/07/26 04:57

No.21 回答者： lv4u 回答日時： 2016/07/28 23:56

No.1です

>>それはともかく、自分が聞きたいのは、オブジェクト指向でリアルを模しても失敗するケースです。
オブジェクト指向の理念に拘っているのではなく、理念に沿っているのに矛盾が生じておかしくなるケースです。

リアルを模していって失敗するケースは、開発中、あるいは、機能拡張によって、それぞれの部品というか、クラスモジュールが複雑に影響しあうようになるケースが思いつきます。

いわゆるスパゲッティ・プログラムみたいになってしまう。
本来は、別個のものであるはずなのに、互いに影響しあって、答えを得るのが難しくなるケース。

たとえば、レジのおばちゃんのケースでいえば、商品が売れて在庫が減る。それで発注をする。でも、運転資金を考えると、発注するのはいいけど、売れないと仕入代金が払えない。
だから、資金繰り機能との連携が必要となる。さらに、金融機関の追加融資が受けられるかどうか？の判断も必要になる。
さらに、世間の流行、ご近所の流行なども加味して、売れ行き予想をする必要もある・・・。

まあ、現実のプログラムでは、ここまで広がることはない気もしますが、開発途中に判明した問題を解決する過程において、あるいは、ユーザの要望に対応していく過程で、絡み合いが増えて、それにより、思わぬ副作用が生まれ、矛盾らしきものとなる・・・とか。

そして、本来、リアルをプログラムで摸すのは、難しいものですから。

この回答へのお礼

回答ありがとうございます。
確かに、仰ってる通りの機能を足すのは複雑怪奇で現実に即しているかどうかは判断できない様になりますね。また、即しているかどうかが重要で無くなる気がします。役割分担がきっちりしていれば、商品が最終決済のハンコを押してもなんらおかしくない様に思います。

お礼日時：2016/07/29 05:01

No.20 回答者： tknakamuri 回答日時： 2016/07/28 00:22

だいぶ良くなりましたが、

＞おばちゃんクラスは何でもできるとします。

「何でもできる」というのは集中管理の考え方の
名残なんですよね、これは。

基本、オブジェクト指向ではトップレベルモジュールというのは
置かないことが多いのです。同列のモジュールのコラボという
発想が大切です。

例えばバーコードを読み取ると、こんな流れになります。
＃あくまでちょっと作ってみた例です。

■「バーコードリーダー」が「バーコードリーダーコントローラ」
　のメソッドを呼び出す。
■「バーコードリーダーコントローラ」は「商品」を作成し、
「領収書」＃商品追加メソッド　を呼び出す。

つまり

「バーコードリーダー」はあくまでバーコードを読み取る単一機能を
提供する。

「バーコードリーダーコントローラ」はバーコードデータの
受信イベントから適切な業務処理手順を実行する。

という役割分担になるでしょう。
＃あくまで一例です(^^;

最初に「何でもできる」モジュールを想定するのは
意味ないんです。そういうものを想定しただけで役割分担が
不透明なクラスが必ず出来上がります。

必要な業務処理の一覧を作っておいて、
どんな単機能モジュールが必要になるかを考え、
各処理をどのモジュールの組み合わせで行うか考えてゆくのが
設計ということになります。

この回答へのお礼

なるほど、ちょっとわかった気がします。
ただ、やりたいことの要素を列挙した場合、私が列挙する要素では、その要素要素に下位モジュールが出来てしまいます。
ここら辺が素人とプロの見方の違いなんですかね。
うーむ、難しい…。
でも、当初の現実を模していく考えとは、違った見方が備わった気がします。ありがとうございました。

お礼日時：2016/07/28 01:49

No.19 回答者： tknakamuri 回答日時： 2016/07/27 21:52

>うーん、ちょっと、頭がこんがらがってきました。

>実際のスクリプトを見比べないと比較できません。

げげ、このくらいでオーバーフローしてしまうのですか。

それではちょっとまとめを。

ソフト開発において、エンジニアの夢は、適切な分割統治。
独立性が高くて相互に依存性が少ないモジュールに
ソフトを分割できることです。

ソフトの開発方法論というのはそれが目的であって、
現実をシミュレートすることでは全然ないんです。
オブジェクト指向がシミュレーションから出発したことが
誤って伝わったんでしょうね。これは古代の妄想として
もう誰も相手にしていません。

独立性が高くて相互に依存性が少ないモジュールとは
すなわち、ソフトウェアの作りを集中から分散に
するということです。会社組織作りと同じで、部下や部門の
仕事の詳細は判らなくても、概要が分かっていて指示と
報告があれば組織は動かせます。ソフトもそういう形にできるのが
理想ですし、そうなっていないとソフトが大きくなると
設計が破たんしてしまいます。そうするにはデータや処理の詳細を
より末端のオブジェクトが持つようにしなければならないのです。

レジプログラムのケーススタディで、おばちゃんクラスや
レジクラスをまず作ってそこに必要な実装を置くというのは、
集中管理の発想です。
何でもできるクラスは俗に God Class(神のクラス) と揶揄されて
決してやってはいけないこととして
教科書によく載っています。気を付けましょう。
1クラス1責任(役割)がオブジェクト指向の基本です。
＃これも教科書に載ってます。

仕事の役割分担を考えてどういうクラスを作ってどう
割り振りをするかというのがオブジェクト指向の
最も困難な部分です。正解はありませんが、こういう場合は
こうするとうまくゆくという断片的なものはたくさんあります。
単純な法則の組み合わせでは解決できない問題なんです。
＃いくつかの守るべき重要な原則はありますが・・・

そういうものを少しずつ学んでゆくのがオブジェクト指向を
学ぶということです。

現実をシミュレートすれば自然に何もかもうまくゆく
という、古代のバラ色な妄想はきれいに忘れた方が良いです。

この回答へのお礼

あ！何となくピンと来ました。
要は上位の仕事を減らす様に設計すればいいと。
まずおばちゃんクラスがあるとします。←ぉ

最初は
おばちゃんクラスは何でもできるとします。

でも段々面倒になってきたんで
おばちゃんクラスは「計算、賞味期限管理」をレジクラスに任せるとしました。
レジクラスは計算、賞味期限管理のメソッドを持ち処理をします。←現実の世界はここ

レジが意志を持ったとして、レジのくせに計算が面倒になりました。レジは、計算を商品自体に行わせることとしました。
商品クラスは自身の値段を持ち、かつ、レジに持って行ったときに自分たちの型の合計金額を出すメソッドを実装しました。
合わせて、自身が賞味期限から外れている場合、レジから離れる機能を実装しました。
結果的に、レジクラスはレジのある位置情報だけ持てば、計算や賞味期限管理のメソッドが必要なくなりました。
また、おばちゃんクラスは、レジにある位置情報と同じ場所の商品に値段を聞けばよくなり、また、賞味期限切れの商品は処理をしなくても勝手に除外されているといった状況になりました。
また、レジクラスは、メソッドを必要としなくなったため消去されました。変わりに、商品に会計の時に向かうべき位置情報だけがコンストラクタとして、実装されました。
結果的におばちゃんメソッドは、商品に合計を聞くだけで良くなりました。←リアルではありえないが、良いプログラム

つまりこういうことですかね？

お礼日時：2016/07/27 22:42

No.18 回答者： tknakamuri 回答日時： 2016/07/27 20:50

>商品毎に修正するなら、マカロニサラダ、ポテトサラダ、

>…等の無数のオブジェクトの値段を値段を
>書き直さないといけない。

なんで？　タグで識別するかは実装次第なので
やり方次第ですが、商品クラスのインスタンスにそのタグがあるなら
商品#getPrice()がタグと時計と割引前価格を見て、
価格を計算して返すだけでは？

別の選択肢として、商品コードから商品クラスのインスタンスを
作るとき、タグを見て商品クラスのサブクラス(サラダ)を返すという
手段もあります。これが一番スマート。

以上を踏まえてどっちが楽ですか？

この回答へのお礼

うーん、ちょっと、頭がこんがらがってきました。
実際のスクリプトを見比べないと比較できません。

多分、経験値に圧倒的差があって付いていけてないのだと思います。

何年後かにこの文読み返して納得できたら、謝罪のお礼しますw

お礼日時：2016/07/27 21:01

No.17 回答者： tknakamuri 回答日時： 2016/07/27 20:02

＞印刷機と計算機を継承したクラスにレジクラスも作って、

＞おばちゃんクラスはレジクラスに委託すれば良いのかもしれません。

しぶといですね(^^;　これは実は最悪に近い選択なんです。

では、ある日営業から、ある商品(サラダとか)は 18:00 を過ぎたら
半額で売るように通達があったとします。
おそらくこんな感じの要望は日常茶飯事でしょう。
日々レジソフトの改造が必要です。

あなたの案と、私の案ではどちらが直しやすいですか？

何でも解決してくれそうなレジクラスを直すのが良いですか？
それとも商品の価格に関して全責任を負っている商品クラスを
getPrice()メソッドを直すのがよいですか？

そもそもこういう観点からソフトウェアの良し悪しを
考えたことがありますか？

この回答へのお礼

すみません、私の頭では、レジクラスを治す方がやりやすい様な…。
サラダという内訳が出てきた以上、商品のフィールドには、サラダという情報あるいはtagが付いてるはずです。
商品毎に修正するなら、マカロニサラダ、ポテトサラダ、…等の無数のオブジェクトの値段を値段を書き直さないといけない。
でも、レジクラスを治すなら、サラダというtagのついた物は半額ってすれば一回で済みます。

すみません、仰ってる便利さが今一理解できないです。。。

お礼日時：2016/07/27 20:28

No.16 回答者： tknakamuri 回答日時： 2016/07/26 20:32

>私なら、まずレジおばちゃんクラス（領収書を渡すメソッド、

>商品の内包する情報を領収書に記録するメソッド、
>金額を計算して領収書に記録するメソッドを持つ）を作成します。

うーん、これはオブジェクト指向のモデリングの教科書で
間違いの例として紹介される典型的なものです。
上位にいるレジおばちゃんクラスは何でもできちゃいけないんです。
上位は何も知らないおバカさんでも仕事ができるように設計しないと
いけないんですよ。

基本、レジおばちゃんクラスは他のオブジェクトに命令するだけ。
仕事をするのは「領収書」だったり、「商品」
だったりします。

単価の計算は、「商品」に行わせるのが一般的ですね。
単価は商品のことを一番よく知る「商品」が
やるべきだからです。

データベース上に単価や、特売期間や値引き率があって
そこから「商品」が単価を計算します。おばちゃんはやりません。

「領収書」は「商品」を使って単価を取得し、自身で総合計を
計算するでしょう。
「領収書」は自身を紙に印刷するメソッドを持つでしょう。

おばちゃんの主な仕事は、商品コードと数量を「領収書」に
セットして印刷メソッドを呼ぶだけ。

これだけが正解とは申しませんが、典型的な
良い設計のひとつです。

これはリアルワールドをどの程度模していますか？

何故この設計が良いのか・・・・　という話をやっていると
きりがないので、オブジェクト指向設計の教科書を読みましょう。

先人が答えをもう見つけているのですよ。

この回答へのお礼

リアルを全く模してませんね。リアルでは、商品はフィールドに値段を持つだけで計算をしませんし領収書は自身を印刷しませんからね。
計算するのは、計算機クラス（おばちゃんクラスは計算できないなら、計算機クラスを作るしかない。）し、印刷するのは印刷機クラス（これも同様）。
印刷機と計算機を継承したクラスにレジクラスも作って、おばちゃんクラスはレジクラスに委託すれば良いのかもしれません。
私が考えるならこんな感じで泥臭くなると思います。

一方で、仰ってる設計も目的を達成するのに良いと思います。
商品が自身と同じクラスの情報をまとめて計算すれば便利だし、領収書自身が自身を印刷できれば便利ですものね。何せクラスが少なくて済む分、合理的だと思います。これが、ダメな具体的理由は見つかりません。敢えて言うなら理念に反するからダメな気がするってだけです。私の頭ではダメな具体的理由は思いつきません。何でダメか具体的理由が無い限り、合理的なこちらの設計の方が優れているのでしょう。

つまり、私がダメだと思う設計の方が、現実的には一般的で合理的で役に立つということですね。

何故？と聞きたいのですが、その疑問は不勉強という理由があってわからないのでしょう。聞くのは失礼なので辞めておきます。

予想として、泥臭く考えると物量問題に直面するからという答えになる気がしていますが。

お礼日時：2016/07/26 22:25

No.15 回答者： tknakamuri 回答日時： 2016/07/26 18:50

>自分が聞きたいのは、オブジェクト指向でリアルを

>模しても失敗するケースです。

ではケーススタディしてみては。例えばよくある演習ですが
----------
スーパーのレジのプログラムを作るとします。
客に渡されたいくつかの商品の商品コードをバーコードリーダーで
読み取って領収書(商品名、数量、単価、全商品の合計額)を
印刷するとします。
いくつかの商品は期間限定の特売があるとします。
何をオブジェクトにしますか？
単価を計算するのはどのオブジェクトがよいですか？
----------
現実を模すなら一瞬でモデリングできるはずですよね。
そんなことできますか？

この回答へのお礼

確かに扱う変数が多いですね（素人感覚で）。私なら、まずレジおばちゃんクラス（領収書を渡すメソッド、商品の内包する情報を領収書に記録するメソッド、金額を計算して領収書に記録するメソッドを持つ）を作成します。

お礼日時：2016/07/26 19:21

No.14 回答者： tknakamuri 回答日時： 2016/07/26 12:06

＞つまり、そもそもオブジェクト指向が使えていないだけな

＞気がします。

あ～、聞く耳持たないって感じですね。
こりゃー心配だな～。
「理念」とかがオブジェクト指向といかに不整合な言葉か
一度考えて方がよいと思いますよ。宗教にしちゃいけません。

オブジェクト指向は妥協とトレードオフが必要になる設計手法の
集まりであり、モジュールの独立性と疎結合を実現するための
武器程度に考えないと。

取りあえずお勧めする参考文献です。リアルワールドの模倣より
遥かに大事なことがたくさんあることが判ると思いますよ。

オブジェクト指向分析からオブジェクトの構造を決めてゆく手法を
紹介した2冊です・

「オブジェクト指向のこころ」（原題はデザインパターンの説明）
https://www.amazon.co.jp/%E3%82%AA%E3%83%96%E3%8 …

「アジャイルソフトウェア開発の奥義」
https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%8 …

この回答へのお礼

いや、聞く耳を持たないわけではないです。
現段階の自分の能力では、現実を模することで不都合が生じるケースを想像できないのです。
ここで言う不都合とは、効率性を指していません。
現実を模さないが、より便利な設計も、プロジェクトによっては有ると思います。残念ながら、私にはそれを想像するのは遙かに経験不足です。そもそも草鞋が違うので出会う機会も無いかも知れません。

それはともかく、自分が聞きたいのは、オブジェクト指向でリアルを模しても失敗するケースです。
オブジェクト指向の理念に拘っているのではなく、理念に沿っているのに矛盾が生じておかしくなるケースです。

お礼日時：2016/07/26 18:07

No.13 回答者： tknakamuri 回答日時： 2016/07/26 09:51

>リアルに模すなら、券売機にカウンターがあるべきです。

>で、券売機が複数あるなら、それを取りまとめる
>管理者オブジェクト一つ有って、その管理者オブジェクトが
>券売機クラスのカウントメソッドを用いるのでは…。

これはもう券売機の内部設計に完全に立ち入ってしまって
いますよね。そこも含めてどう設計するかという話なんで。

例えば特急券だったら、予約などの絡みで切符を個別に識別する
必要が生じて、1万枚売ったら1万枚のオブジェクトを作る方が
合理的になります。そこを見極めるのもプログラマの仕事です。

つまり管理/処理方式が決まるまではオブジェクトの役割の分担が
決められないということです。そこを先走ってしまうと
恐ろしい量の手戻りが発生してしまいます。

この回答へのお礼

うーん、つまり、先走って矛盾した役割分担をすると手戻りになると。矛盾したというのは、リアルに即してない設計。数学的に言えば虚数解を扱うような設計。

それはオブジェクト指向の理念に反しているので、オブジェクト指向の限界を示すわけでは無いのでは…。
つまり、そもそもオブジェクト指向が使えていないだけな気がします。

お礼日時：2016/07/26 10:34

No.12 回答者： negativeomg 回答日時： 2016/07/26 09:41

2進数が14ビット単位なっちゃてるのが気になる。

せめて8ビットにしてほしい。

✳君しか出来ない。期待できる。