Hatena::ブログ(Diary)

今日の役に立たない一言 − Today’s Trifle! −

2004-07-07

[]012 012を含むブックマーク 012のブックマークコメント

012。この数字を見て思った。なんとなく orz に似てる。

[]7月7日 7月7日を含むブックマーク 7月7日のブックマークコメント

神さんの両親のお友達に7月7日生まれの双子の女性がいる。七さんと夕さん。お誕生日おめでとうございます。

[]jude-users ML での議論 jude-users ML での議論を含むブックマーク jude-users ML での議論のブックマークコメント

ことの発端。

従来の手続き型プログラミングでのフローチャート(処理の流れ(データ+ロジック)を忠実に2次元平面に表現する図)は、UMLでは何の図で表現するのですか?

これに対してある人がアクティビティ図と回答。その回答に対して

アクティビティ図が、一番FlowChartに近い事は、私も判るのですが、要するに、従来の素晴らしいプログラミング技術で在った、ストラクチャードプログラミング(階層的な構造化)に変わる部分が無いと言うか落っこちて居るのです。(笑)

との意見があった。

オブジェクト指向ではデータはそのままで存在せずに、オブジェクトの属性として現れると言うことを理解しておく必要がある。UML図にはデータという形では出てこないのだ。。。というような内容を書いてメールを出そうとしてたところだった。構造化プログラミングについては以下。

[]jude-users ML での議論の続き jude-users ML での議論の続きを含むブックマーク jude-users ML での議論の続きのブックマークコメント

メールしようと思ってたところ、平鍋さんからMLの主目的にあわない話は慎め!とのメールが来たので出すのをやめた。

で、疑問その壱。

ストラクチャードプログラミング時代のCOBOLでは、パターンなど無くても、誰でもがどインデントなアプリを少しの勉強で、組めた。

「インデントなアプリ」ってどういうもの?誰か教えてー。ぐぐってたらこんなのに当たった。

http://www.geocities.co.jp/SiliconValley/5634/t82B1_0001.html

こうぞうかぷろぐらみんぐ
構造化プログラミング

【プログラミング】
COBOLプログラマの間では、IF〜END-IF、PERFORM〜END-PERFORM等のたびにインデントをつけていく事。

は?COBOLプログラマの間では「インデントをつけていくこと」が構造化プログラミングなの???これが疑問その弐。

まぁ、それはおいといて。

思うに、オブジェクト指向ってのは構造化プログラミングに基づいていて、決して相反するものではない。構造化プログラミングの基本要素は順接・反復・分岐であって、これはオブジェクト指向でも必須だ。

オブジェクト指向ってのは、構造化プログラミングの利点を保持したまま、さらに認知科学の見地に基づいてプログラムを分割する方法についての指針を示してくれている。(しかし、指針があるからといって誰もがうまくやれるわけではない。) それに対して、構造化プログラミングでは大きいものを小さく、さらに小さく、と言う程度でしかなく、分割する指針はない(よね)。

たぶん、

    (構造化プログラミング + 新しい概念 + 新しい方法論) ⊂ オブジェクト指向

    新しい概念:パッケージ、クラス、インタフェース、継承、多態などなど
    新しい方法論:全体をパッケージやクラスに分割する方法

って感じなんだろう。

minusyyさんとtyamaguchiさんのコメントを受けて追加
構造化プログラミングでは、機能で分割してプログラムを細分化していく。これはオブジェクト指向でも似たようなもの。機能面以外のプログラム分割のマクロな指針としては、アーキテクチャとかフレームワークなどが考えられる。これらもオブジェクト指向に特有なことではないので、構造化プログラミングと併用することも可能だし、併用することでよりよい設計が可能になる。

[][]UML本の紹介 UML本の紹介を含むブックマーク UML本の紹介のブックマークコメント

jude-users ML でも話題に上がったので、4月21日の日記でも紹介したけど、改めて紹介。

      

minusyyminusyy 2004/07/07 16:20 一連の機能群をオブジェクトで表現し、その群同士でもっとマクロな機能を表現したいときはどうすれば良いのでしょう?「構造化」の話題はそういう疑問かなと受け止めています。パッケージが近いのかなとも思いますが、それはなんとなく実装テクニック上のまとめ方のようにも思えます。(Java に引きずられた勘違いかもしれません)。かつての DFD ツール上では、機能群をクリックすると群内の詳細機能がズームアップしたような気がします。オブジェクト群でもそういうことができるといいなと思っています。

tyamaguchityamaguchi 2004/07/07 16:30 構造化プログラミングにおいても機能で分割しなさいという指針はあります。その意味では構造化プログラミングの経験のある技術者はクラス設計等できちんとした設計を行ってくれます。

satoshissatoshis 2004/07/07 16:44 一連の機能群=パッケージでしょう。で、複数の機能群を使ってマクロな機能を表現するのもパッケージかな、と思います。Facadeパッケージというのが適切かもしれません。

satoshissatoshis 2004/07/07 16:48 機能で分割って当然ありますね。忘れてました。

komurokomuro 2004/07/07 17:02 C++でオブジェクト指向を覚えた時は 「オブジェクト」=「特定型のデータ」+「データ型固有の処理」でした。BasicやCの経験だけがあり「継承???」な私にはこう理解するのが馴染み易く感じられました。後から継承とポリモーフィズムを勉強しなおして感動しました。

minusyyminusyy 2004/07/07 17:13 Facade ってパターンの名前なんですね。ありがとうございます。Jude で少し試してみたんですが、やはり疑問が。その1:やっぱりパッケージと違う切口が欲しいかも。端的な例として socket を使う機能群はパッケージをまたぎますよね。その2:クラス図でパッケージを初めて置いてみましたが、便利そうです。このパッケージを開いたり閉じたりという概念は(Jude に限らず)あるのでしょうか?それが構造化の階層ニュアンスかも。

satoshissatoshis 2004/07/07 17:43 1は最初の質問と同じで、socket関連機能をまとめたパッケージを別のパッケージから使えばよい。例えばJavaでは、socket関連のクラスはjava.netパッケージにあり、socketを使うRMIはjava.rmiパッケージにあります。(パッケージ間の依存) 2の階層の話ですが、パッケージの深いネストはお勧めできません。経験からするとパッケージとサブパッケージの2階層で十分です。java.netとjava.rmiのようにパッケージを設計すればOKでしょう。

nakamuranakamura 2004/07/07 22:56 パッケージはあんまり関係ないような気がします。オブジェクト群を構造なり機能なりでグループ化したいという要望については、Facadeが肝かなと思います。Facade以外の細かいObjectを隠蔽する(したのだと見なすことにする)という感じで使うんだと思います。//ところでFacadeというか隠蔽を多用すると、今度は再利用性が落ちて困ったりします。色々悩ましい…

araiarai 2004/07/07 23:10 Judeのメーリングリスト入ってて、飛んできたものの一人です(^^)。ちなみに構造化プログラミングの分割指針だとSTS分割法(入口部分と変換器部分と出口部分で分割する)だとかTR分割法(いわゆるトランザクション単位に分割する)だとかジャクソン法(名前だけ覚えてた(笑))だとかがあったと思います。その辺の理屈からすると、GoFのFacadeパターンなんかの方が言ってる事はあいまいな気はしますね。ただ、考え方があいまいだからオブジェクト指向の分析がダメだというのはお門違いで、そもそも問題領域を抽象的(ある意味あいまいに)に捕らえてトータルでいろんな視点から俯瞰的に分析していこうというのが、オブジェクト指向分析のねらいだと解釈しています。UMLもその線のはずです。だから、そこを捕まえてUMLが発展途上だ的な考え方ってなんか違うなあって印象をうけました。やっぱり銀の弾丸はないんだから、特定の方法論の不備をあげつらった所であまり意味無いんぢゃないかなあと(フローチャート書きたいのに書けないっていうもどかしさは痛いほど伝わるのですが)。

habuakihirohabuakihiro 2004/07/07 23:14 あの・・・その用語辞典って皮肉ってますので(^^; 決して本気で受け止めないでくださいね。元COBOLプログラマより(^^;;

satoshissatoshis 2004/07/08 01:37 この用語辞典サイトってはぶさんが書いたんですか?

nakamuranakamura 2004/07/08 06:09 いや、曖昧なのはOOP全体の性質かと。曖昧だけど直感的または経験的にOKってのがOOPの通奏低音だと思います。事象の海の中からどうObjectを分割(==認識)するかは美意識に依存するぞと。//(手続きの)構造化では分割の軸が1次元しか無かったと思います。そのぶん形式化し易いのでしょうね。OOPだとそれに少なくともObject(Data)の分割の軸が1つ追加されるし、合わせワザで他の色々な分割軸も見えてくる(ような気がする)。//なお抽象と曖昧との間も無関係かと思います。厳密な抽象とか曖昧な具象とかも有るもん。//ところでFlowchartってData見れるんでしたっけ?OOPはDataを曖昧にせずObjectという凄く鋭いFocusで観測する思考形態だと思います。

nakamuranakamura 2004/07/08 07:19 ここ→オブジェクト脳オンライン→ http://www.wingnest.com/blog/index.php?itemid=82 の「「動き」は、 ロジックで 「存在(構造または構図)」は、ものの見方(アートとそれを支えるいくらかの思想と哲学)」というのを見つけて、さっき書いたのと同じじゃんorzと思った次第です。// http://d.hatena.ne.jp/satoshis/20031027#p1 で「構造化プログラミングに慣れ親しんだ人がオブジェクト指向を学ぼうとする」話を既に書いてらっしゃったんですね。

tpircstpircs 2004/07/08 08:02 >用語辞典。 他の項目とかいくつか読むとわかるんですが、皮肉もたくさん入ってますよって意味だと。

sugasuga 2004/07/08 10:05 一部で有名なネタ辞典です>真。「バージョン管理ツール」とか見ると分かります。

nakamuranakamura 2004/07/09 10:57 皮肉ではあるけど、正鵠では?>バージョン管理ツール(の悩み)

satoshissatoshis 2004/07/09 11:40 いくつか拾い読みしてみましたが、皮肉はあってもウソは書かれて無いように思います。

guionguion 2004/07/10 09:59 COBOLと構造化の関係については、例のパターンで「COBOLerの中でもレベルの低いほう」が対象者なのでは?>habuakihiroさん

kimukimu 2004/07/10 23:37 Judeのメーリングリストを読んでこっちに来ました。思ったのですが、構造化プログラミングを無理にUMLで表す必要は無いのではと思いますが・・・



10000番ポートがブロックされている環境ではこちらのカウンターは表示されません2004/02/29に値が壊れたすごいカウンター
←はてなカウンター