|
|
|
|
|
||
|
||
Powered by dKingyo ソフトウェア開発技術者 | C++ | Ruby | 256倍使うための本 | Windows Server
http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
http://b.hatena.ne.jp/entry/http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
の記事が私が訪れている様々なブログや日記でいろいろと議論が巻き起こっているのですが･･･いやいや、なんか、荒々しいコメントが目立ってきてなんかちょっとな･･･って感じがする今日この頃です。
いやいや、OOP･･･確かに目的のソフトウェアを作る上では全く役に立たないと思いますよ。あくまで私の主観で経験上の話ですよ。（ってか、実際業務を行っているプロフェッショナルではない私が言うのもなんなんですけど･･･）
私自身、頑張ってOOPを自分なりに理解して覚えてきた訳ですが、実際、なにがなんだか分からないままにgoogle:glibのコーディングスタイル、データ構造、状態遷移関係がオブジェクト指向だと思い込んでいままでプログラムを組んできたわけです。目的の機能（ライブラリ）を作ったり、ライブラリを読んで構造を理解するのに私が学んできたOOPは素晴らしい考え方だと感じます。
特に、私が学んできたOOPという考え方は必要な機能を実装したらリライトをしないような形で表現する所が素晴らしいと感じるのです。
ですが、この考え方に凝り固まってソフトウェアをコーディングしてもさっぱりソフトウェアが完成に近づかないのです。
むしろ、何回もリライトすることになりソフトウェアが動くまでになかなか漕ぎ着けません。そんな経験が私からpureでtrueでrealなOOPでソフトウェアを作ることから遠ざけているような感じを受けます。
ですが、私が学んだOOPという考え方、好きなんです。なんというか、プログラミングする上で私の中での美徳というかPolicyにまでなってしまった考え方なんです。
なので、私はライブラリ製作にのめりこんでいったのではないか？と考えたりすることもあります。
しかしながら、私が学んできたOOPは真のOOPではないのかもしれませんし、真のOOPを使うと生産性が上がるのかもしれませんし、そうではないのかもしれません。
ですが、今の時代、大量のライブラリやAPIを使わないとソフトウェアが作れない時代になってきました。ライブラリや最近のAPIにはこのOOPが使われる傾向が多分にあります。これを考えるとオブジェクト指向という考え方は少なからずソフトウェアを作るのに必要な概念ではないかとは私は感じています。
それからこの記事の著者は「とりあえず、スキルアップのためにはコードを書くのだ！」的な事をとりあえず、OOPを引き合いに出して主張しているのかな？と感じました。確かに、このコードを書く = スキルアップの為の近道*1私の経験的にはこれは当たっていると思います。
また、「流行ってる技術＝役に立つ技術」ではない！！！というのもうなずけるような気がします。
UMLって昔、流行ったような気がしたのですが、役に立つような気がしません･･･。
XPというプログラミング手法の本も読んだのですが、役に立つような気もしません･･･。
JXTAってのもあったような気もしますし･･･。*2
（追記：「目的のソフトウェアを作る上では」と付け加えるべきでした。誤解を招いてしまいましたかもしれません。スミマセン。）
いやいや、ここにあげた概念を私はがんばって覚えて使って物言いしたわけではなりません。ただ、私がこの概念の概要を雑誌で読んだ第一印象を述べているだけです。
むしろ、私は経験的に古典的なFSM的考え方やポリシーが役に立つ技術のような気がしてなりません。*3
むしろ、
C言語による最新アルゴリズム事典
を読み倒して、どのアルゴリズムをどのようにして組み合わせると目的のソフトウェアが作れるか というような事の方が役立つ技術のような気がしてなりません。
むしろ、そのプログラムをどのように組み合わせると目的のソフトウェアを製作、完成させるのにメリットがあるかという事を経験していることの方が役立つ技術のような気がしてなりません。
ですが、私はプログラミングは独学ですので真の概念や真の考え方が分からないのにこういう文章を書いているので ちょっと(/ω＼) ハジカシー 感はぬぐいきれません･･･。プログラムかじっている学生の戯言と思っていただけると救われます。
glibを読もう!!!
VCでコンパイルできなくて困っているなら
http://www.dkut.flnet.org/DKUT/glib_vc_222.dgc
にバージョン古いけど置いておくから。とりあえず読んでみて欲しい。
やっぱりglibってOOPだよね！？（いや、真のOOPかどうかは確証は無いけど・・・）
また、私はまだ読んでいないのだが、
http://www.amazon.co.jp/exec/obidos/ASIN/4894716844/studiokingyo-22
という本のレビューがかなり評判が良いので読んでみることをオススメする。
出来れば上記のURLをクリックしてAmazonにアクセスして買ってくれると紹介料が私に入り、研究費、生活費として私の収入になるので是非クリックして買っていただきたい。
http://d.hatena.ne.jp/JavaBlack/20060612#p3
より。
JavaBlack氏によると私の学んできたOOPという概念はMSのVB方言によるものではないか？との事ですので真のオブジェクト指向と呼ぶには疑問が残るそうです。
よって、JavaBlack氏のブログによると
との事でした。
なるほど。プログラミングを生業にするにはこれらの概念理解や勘違いをしないようにしなくてはいけないことも大切にしなくてはならないようです。
*1：確証があるわけでもないし、証明もできないけれども
*2：追記：http://web.sfc.keio.ac.jp/~yoshiro/weblog/archives/2003/04/jaxta.htmlより JAXTAってスペルミスらしい。JXTAが正式な名称のよう。
新版 明解C言語 実践編
> リソースの再利用性を高めるためには、きっちりとした仕様書を
> 書く訓練や、他の開発者とのコミュニケーションスキルをUP
> した方がずっと実務的ですし、上司も評価してくれるでしょう。
多分、仕事をやったことがない人には理解しがたいところが
あるでしょうが、本当にこのひとことに集約されます。
社会人になってこの方、仕事が早かったり、ソフトウェアの
品質が高くて評価されることはありますが、オブジェクト指向を
理解していて評価されたことはありません。これば社風だけで
なく、部署や上司によって大分違うと思いますが。自分も
この件に対して記事を書きましたが、誤解を招く書き方のような
気がしてきたので、また記事を書く予定です。
ついでに言うと「C言語による最新アルゴリズム事典」を
この程度の本という人もいますが、この本一冊内容をすべて
理解できたら職場では超一人前です。って職業プログラマで
この1/3も理解できている人がどれだけいることか(自分も
人のことは言えない)。確かに仕事では本の内容プラスアルファ
が必要ですが、この本を理解できる力があれば絶対大丈夫です。
>本当にこのひとことに集約されます。
まだ、そのような業務経験が無い学生が今までの体験から妄想を働かせて青臭いことを書いてしまったわけなんですけど、現実、現場ではそうなんですか。なるほど。
事実、自分は未だにその世界に触れてはいなくて現場ではどのくらいの知識、経験が必要でどのような行動が必要かといった事が未だに分からなくて不安でした。
ですが、kmt-tさんからアドバイスをいただけると先行きが見えたような感じがして安心します。ありがとうございます。
それでは。
まず
> 目的のソフトウェアを作る上では全く役に立たない
ですが。そうですねぇ「初手に作るとき」にはあんまり意味がない可能性があるのですが。保守をしなければいけないときに、OOで作るか否かは大きな違いがあります。
で、多分ここが違うんだろうなぁと思うのですが。
> 特に、私が学んできたOOPという考え方は必要な機能を実装したらリライトをしないような形で表現する所
明示的に「違う」と反論できます。
OOやOOP(やOOSE)の便利なところは「なんぼでもリライト出来る」ところが一つの利点です。
つまり、OOPで作成すると
・とりあえずなんとなく動いているっぽいけど本当に動いてるのかこれ？
みたいな、かなり曖昧なものをとりあえず作れます。
で、必要な部分だけ「ちゃんと」作ると、そのうちある程度動くものが作れます。
ってなくらいに、オブジェクトって曖昧で適当で大雑把でいい加減なものだと私は考えてます :-P
そのあたりは、手前味噌で恐縮ですが、
http://www.m-fr.net/study/object/index.html
をご覧頂くと「理論的背景とか学術的思想を無視した実用一点張りの考え方」の一端が見ていただけるかと思います(苦笑
UMLは…私も使いません(苦笑
XPは「どの部分を使うか」にもよるのですが。テストファーストは必須。早いリリースもかなり不可欠。教育的側面も考慮したうえで、ペアプログラミング重要。なので、少なくとも「きちんとしきれる人間がいる」状態で業務で開発するかぎりにおいて、非常に重要です。
# ちなみにXPは「開発手法」ですね。プログラミング手法よりはもうちょっと広い守備範囲になります。
あと
> コードを書く = スキルアップの為の近道*1私の経験的にはこれは当たっていると思います。
には明示的に反論を。
スキルアップするのは、書いた上で「修正したり考察したりして反復して学ぶ」からスキルアップするものです。
ただ書くだけでスキルが上がるというのは、本質的にありえないです。
多分、studiokingyo さんは「書いている時や書いた後に考えたり見直したり修正したりすることをほぼ無意識になさっている」から、なんだとは思うのですが。
以上、ちょいと気になったので書き込みしてみました。
suma君の紹介で以前から日記を読ませていただいていました。
OOPの考え方で、私も以前勘違いをしていまして、
http://d.hatena.ne.jp/NIES/20041126
昔はOOPに従わなくちゃいかんのだ・・とか、ここはOOP(もしくはデザインパターン)の考え方だとこうだから、こうしなくちゃいかんのだ・・という考え方でした。
>アルゴリズムを理解、暗記
>アルゴリズムを自分で考えて製作することが出来る
>その先にオブジェクト指向云々があり
>さらにその先にXPの美学を理解することが出来るようになる。
これにすごく共感しました。
やっぱり、情報学の分野でこれまで積み重なって考えられてきたものは、そのまま土台になってるんですね。
コーディング前のレビューとか若い衆に説明するには便利だと思うんだけど...
あと、OOP慣れしてない奴に書かすと面白いし。
昔からフレームワークばっかり作ってるからかな。
おいらも、一人で作ってレビューする必要が無い場合や、ビジネスロジックの設計には使わないもんね。
dkutilとか見せてもらったことあるんですが、少なくとも私はd金魚さんがOOわかってないように見えませんでした。MS方言なんてのがあるのはVB触ったこと無いので知りませんでしたが、私にはd金魚さんのコードは普通のC++/Java/C#タイプのOOのコードに見えます。
あとglibはOOだと思います。
個人的にはd金魚さんがプログラムのレベル的には今すぐ働いても問題ないっていうのは疑いの余地が無いように見えますし、学んだことがどう仕事に生きるか、なんてのはいざ仕事する時にでも考えることにしても遅くはないとは思います。