パスワードを忘れた? アカウント作成
217235 story
プログラミング

「オブジェクト指向言語でオブジェクト指向っぽいプログラミングをしない」のはNG? 175

ストーリー by hylom
TPOを考えた実装を、 部門より

「オブジェクト指向言語でオブジェクト指向プログラミングをしない」というSEのブログ記事が一部で物議を醸しているようだ(タレコミその1タレコミその2argonの日記など)。

話題になっているのは、@IT内の「システムエンジニア 生き残りの極意」ブログの「実はオブジェクト指向ってしっくりこないんです!」という記事。

「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。

記事では多くのコメントが付いているものの、なかなか議論はかみ合っていない模様。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 質問が間違いですね (スコア:5, すばらしい洞察)

    by Deasuke (34806) on 2010年05月06日 20時53分 (#1759374) 日記
    オブジェクト指向でプログラミングしなければならないかどうかは言語に依存するものではないでしょう。実装対象/設計に依存するはずです。
    そもそも設計がオブジェクト指向でなければ実装だけオブジェクト指向になることもないですし、オブジェクト指向設計はプログラミング言語抜きに行うことも出来ますよね。
    (言語に対してある程度のオブジェクト指向的な機能は仮定するにしても)

    あと、もとの記事を見るとC++が挙がっていますが、C++は「オブジェクト指向にも書ける」言語であって「オブジェクト指向のための」言語ではありません。
    なので「C++を利用するならオブジェクト指向でプログラミングしなければならないか」というように質問を解釈したとすれば、「否」が答ですね。

    STLの実装を見てもらえば分かりますが、C++の機能をふんだんに利用して「オブジェクト指向でなく」書いていますね。
    各々のコンテナやアルゴリズムはできるだけ独立で直交するように設計されています。
    # STLをUMLで再設計してみようとすれば如何にSTLがオブジェクト指向でないかが分かります
    --
    Best regards, でぃーすけ
  • by s02222 (20350) on 2010年05月06日 19時47分 (#1759320)
    >ということ知ってからは、

    ということは、知らずにやってた時期があったわけですね。

    それはさておき、新たな技法を手に入れて過去の所行を見直したり、教科書に書いてある技をそれと知らず再発明したり、 逆についうっかりおっちょこちょいな独自の技法を編み出してしまったり、 「いやお前の考えはおかしい。エライ人が書いた教科書にもこっち方が正しいと書いてある」と言う実はもっともなアドバイスに反発してみたり、 後になって自らの過ちに気付いたり。 プログラマはそうやって、一歩一歩、成長を遂げるもんでしょう。

    このトピックの話題も、そういう階段を一段上がり損ねた一事例に過ぎないでしょうから、ほほえましく見守ってあげれば良いんじゃないでしょうか。

    # そうだそうだ!と言う賛同者をたくさん集めちゃって、階段の踊り場なんかが形成されたら嫌だけど
    • 構造体の可変長配列のメンバーに可変長配列があって・・・なんてことを昔にやってしまった人間としては、C++のコンストラクタ&デストラクタは福音でした。STLに至っては言うに及ばずです。 似たような構造体の定義が山ほどあって、こいつの整理に継承と多態が非常に有効であることを知ったときは目から鱗が落ちました。

      なぜ、ポインタが必要なのか。なぜ、仮想関数が必要なのか。スクリプト系言語の怠惰さとか、今まで理解できなかった事を理解できたときの喜びって最高だと思うんですけどね・・・。
      ぶっちゃけ、僕なんかその快楽を得るためにプログラマをやっているようなものですけど。

      親コメント
    • オブジェクト指向は戦場では役に立たない。
      そんなことふうに考えていた時期が俺にもありました。

      構造体の延長として作った set/get しまくりのクラス。
      関数ポインタで作ったオレオレ仮想関数。
      構造体を第一引数に渡した オレオレthis。
      継承をむやみに使いまくって、追いきれなくなったゴミコード。

      オブジェクト指向なんて誰も必要としていない。
      Bjarne Stroustrup インタビュー (?)をガチだと信じていた時期さえありましたw
      http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html [rim.or.jp]

      そんな風にOOをdisっていたら、とある恩師に、こんなこといわれました。
      キミがC言語を理解して使いこなすまでに何年かかった。
      そうか3年ぐらいかかったか。
      C++は、Cと似て異なる別の言語だ。
      だから、キミがC++を理解して使いこなせるようになるまでは3年ぐらいかかるよ。

      それから、いやいやC++を利用してゴミコードを量産していたのですが、3年ぐらいすぎたあるときから、
      急にOOで書くのがすごく楽になりました。

      恩師の言葉は事実だったんだなと思いますた。
      何がいいたいかというと、非OOの言語になれまくった人がOOを理解するのには、
      非OO言語を使いこなしたぐらいの時間がかかるんぢゃないのというお話ですた。

      めでたしめでたし。
      #3年もかかったのは馬鹿といわれそうですが、アホなんで許してください。

      --
      by rti.
      親コメント
    • by Anonymous Coward on 2010年05月06日 21時32分 (#1759398)
      > このトピックの話題も、そういう階段を一段上がり損ねた一事例に過ぎないでしょうから、ほほえましく見守ってあげれば良いんじゃないでしょうか。

      でも、1962年生まれの人ですからねぇ。
      会社ではそれなりにえらい立場な人なはずです。(なんでそんな人がコードを書いているのかは知りませんが)
      そういう人が自分は分かってる、って思い込んでるわけで、そうなると現場の若い人たちにもstatic pubulic宣言
      押し付けている可能性が高いです。だから、声を上げずにはいられないのでしょう。
      親コメント
  • 上には上がいる (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2010年05月06日 19時33分 (#1759304)

    コーディングルールで縛るなんてショボイです。技術的に解決できるなら技術的に解決すべきです。
    #define private public
    #define class struct

  • ローカル変数であれば隠ぺいできる話。

     問題は複数の関数にまたがってローカル変数を使えないが、グローバル変数だと今度は通用範囲が広すぎるということです。ただ、例えばCだとグローバル変数にstaticを付ければ通用範囲がソースファイル内に限られるので、大体所望のものと似たような効果が得られますが、もうひとつ問題があって、この方法だと変数がプログラム全体で共用になってしまう。
     実務的にみたときは、そういう問題の解決策がクラス(のメンバ変数)ということになります。メンバ関数は、それらのメンバ変数を使いたい関数として指定されたもののことです。
     Cで、mallocを使って作業用メモリを確保して、それに対応する「ハンドル」を返して……とやっていたものをシステマチックにしたものですね。

     ただ、(理論派きどりの)世間のオブジェクト指向の解説に大変うさんくさいものが多いことは認めます。

     なお、OOPの機能のうち、継承とインタフェースの系統の機能は、ライブラリを作っているのではないかぎり、それらを定義するという面からは、使う機会があまり多くありませんので、使わないでもいいと思います。

    • >なお、OOPの機能のうち、継承とインタフェースの系統の機能は、ライブラリを作っているのではないかぎり、
      >それらを定義するという面からは、使う機会があまり多くありませんので、使わないでもいいと思います。

      業務系のアプリでも、将来の機能追加に備えて機能を抽象化し、拡張ポイントを設定しておくなんて場合には
      よく使いますね。というか、最近の仕事はそんなのばっかりです。

      親コメント
    • なお、OOPの機能のうち、継承とインタフェースの系統の機能は、ライブラリを作っているのではないかぎり、それらを定義するという面からは、使う機会があまり多くありませんので、使わないでもいいと思います。

      継承やインタフェースを使わないとデザインパターンが導入出来ない...

      親コメント
  • namespace (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2010年05月06日 19時33分 (#1759305)

    特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。

    そこで、namespaceですよ。お兄さん。

  • by duenmynoth (34577) on 2010年05月06日 19時40分 (#1759314) 日記
    継承図すら作らずにコーディング始めるとか問題外にも程がある・・・と思ってましたが、
    世の中は案外そんなもんらしく・・・

    #で結局デスマーチ、と
    • Re:問題外 (スコア:4, おもしろおかしい)

      by firewheel (31280) on 2010年05月06日 19時47分 (#1759321)

      継承図なんて要らんよ。フローチャートと同じで、まともなプログラマーにはそんなものは必要ない。

      書いても良いけど品質が上がるわけではないので、結局は時間の無駄。

      親コメント
      • Re:問題外 (スコア:2, すばらしい洞察)

        by duenmynoth (34577) on 2010年05月06日 20時21分 (#1759347) 日記
        概要設計、基本設計、コーディングルール、etcetc・・・
        いろんなものが「自称」優秀なプログラマには必要無いのでしょうね

        #で結局デスマーチ、と
        親コメント
        • Re:問題外 (スコア:3, おもしろおかしい)

          by firewheel (31280) on 2010年05月06日 21時45分 (#1759411)

          >概要設計、基本設計、コーディングルール、etcetc・・・
          見事に全部不要なもんばかりだなあ。感心するわ。

          >いろんなものが「自称」優秀なプログラマには必要無いのでしょうね
          平凡なプログラマでも不要です。

          あなたが平均以下のプログラマーなのは勝手だけど、
          平均以上の人間の足を引っ張るのだけはやめてくださいね。

          親コメント
      • コードからUML図を作ってくれるツールを使えば、対外的なドキュメントは後から作れるしねw

        親コメント
      • by rti (659) on 2010年05月06日 23時28分 (#1759491) ホームページ

        継承図とかは接合部分にだけあればOKだと思う。
        最下層の部分とかには不要でしょう。
        だって、まともにOOやればクラスなんてどんどん増えていくし。
        全部は書ききれないと思う。

        接合部にだけこんな感じっていう図を用意するのがいいと思う。
        どうしてもほしい人はDoxygenでも使って自動生成すればいい。

        そんで、他人が作ったものはクラスというかモジュールは、ブラックボックスとして利用させてもらいたいっす。
        そのモジュールの中までは興味なし。暇があったら流し読みしたいけど。

        図を一生懸命書く暇があったらテストの一つでも作ってほしいと思うんよ。

        --
        by rti.
        親コメント
  • by Anonymous Coward on 2010年05月06日 20時19分 (#1759345)

    23項(p.100)に「メンバ関数より、メンバでもfriendでもない関数を使おう」とあるけど、この項での主張はそうしたほうががカプセル化を強めることができるからというものです。(いわゆる素の関数がない言語の場合はユーティリティクラスのstaticメンバ関数を使いましょうとか書いてある)

    なんか元ブログとはいってることが真逆な感じが…。

  • by Ryo.F (3896) on 2010年05月06日 20時22分 (#1759348) 日記

    みんな釣られすぎなんじゃね?

  • 全部パブリックにして直接代入するとか、staticにして関数を使うとかは勝手にすれば、と思うけど、
    Cでいうところの構造体の操作にあたることは、どうしてるんだろう。

    Foo foo(hoge);
    Foo::func(&foo);
    とかわざわざやってるとしたら、無駄な苦労してるだけとしか。

    # ちなみにPythonだとメンバーは全部パブリックで、foo.func(arg)はFoo.func(foo, arg)と同等だったかと。

    --
    1を聞いて0を知れ!
  • 「オブジェクト指向言語でオブジェクト指向っぽいプログラミングをしない」のはNG?

    ……てな寝言 を言ってる人が作ったプログラムを、俺がメンテする事が無ければ、と云う条件が成り立つので有れば、勝手にして
    その条件が成り立たなければ……コードじゃなくて異動願いを書きます。

  • by vn (10720) on 2010年05月06日 21時44分 (#1759409) 日記
    適当な名前の、データのないオブジェクトをまず拵えて、
    呼び出したいメソッドをモシャモシャ生やせばいいんだよ。
    外見的にはオブジェクト指向みたいに見えるから、みんなハッピーだ。
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...