老害ここに極まれり 175
タレコミ by Anonymous Coward
あるAnonymous Coward 曰く、
情報元へのリンク
@ITのエンジニアライフブログよりの引用
『
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。
「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。
staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。
オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他の言語でもローカル変数であれば隠ぺいできる話。クラスでもパブリック宣言しちゃえば、隠蔽性なんてなくなる。それから、プロパティに隠ぺい性はない。逆に隠ぺいされていると困る。
プログラムの記法から見ると、インスタンス宣言って
クラス名 インスタンス名
となっていて、型宣言と非常に似ている。データベースにはこのクラスで宣言し、ファイルにはあのクラスで宣言し……なんてことをすると、データベース操作やファイル操作で便利なプロパティやメンバー関数が使える。
結局、何をしたいのかによって、クラス名やメンバー関数、プロパティがそれぞれ違ってくるわけで、典型的なプログラミングTipsをメモって使うしかないんだよね。Visual Studioは「インスタンス名.」と打てばプロパティやメンバー関数の候補が出てくるから楽になった。
オブジェクト指向は、結局のところホントにモノ（オブジェクト）に使われている記法、例えばGUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係のものである。
オブジェクトはその種類により特有のクラスでインスタンス宣言が必要であり、クラスで規定されたメンバー関数、プロパティしか使用できない。
非オブジェクト指向言語で数値型宣言されているものは + (プラス）という記号を使って加算できるが、文字列宣言されているものは加算できない。プラスという記号が一種のメンバー関数の役割を果たしている。
』
かなり炎上しまくっては居ますが、
まぁぶっちゃけ、オブジェクト指向的だろうがなかろうが、保守性と試験性、再利用性が高ければいいのでしょうけど、
この人のコードじゃぁ駄目だろうな。
全部staticになってるからMock使えないわ変な副作用ありそうだわ・・・、となりそうなので。
情報元へのリンク
質問が間違いですね (スコア:5, すばらしい洞察)
そもそも設計がオブジェクト指向でなければ実装だけオブジェクト指向になることもないですし、オブジェクト指向設計はプログラミング言語抜きに行うことも出来ますよね。
(言語に対してある程度のオブジェクト指向的な機能は仮定するにしても)
あと、もとの記事を見るとC++が挙がっていますが、C++は「オブジェクト指向にも書ける」言語であって「オブジェクト指向のための」言語ではありません。
なので「C++を利用するならオブジェクト指向でプログラミングしなければならないか」というように質問を解釈したとすれば、「否」が答ですね。
STLの実装を見てもらえば分かりますが、C++の機能をふんだんに利用して「オブジェクト指向でなく」書いていますね。
各々のコンテナやアルゴリズムはできるだけ独立で直交するように設計されています。
# STLをUMLで再設計してみようとすれば如何にSTLがオブジェクト指向でないかが分かります
Best regards, でぃーすけ
生きたソフトウェアは改修され続ける (スコア:1)
一個のシステムが異なる性質を持つ場合もあり、複数の言語を混合するのはそれはそれで異言語インターフェースが大変（必要があればできるし、不可能ではないが）なので、広くつかわれる言語に他言語の特徴を模倣するライブラリが追加されるのは仕方ないとは思います。
C++templateに関してはtemplate自身、
元来は「クラス付きのC」でC++に対して後付けですし、
メタプログラミングに至っては意図的に設計されたものではなく
利用サイドからの創発なので。
実用を指向する場合、
既成言語の改修・拡張とその利用経験から新しい言語が生まれるのだと思います。
訂正 (スコア:1)
誤）元来は「クラス付きのC」でC++に対して後付けですし、
正）元来は「クラス付きのC」であったC++に対しては後付けですし、
読む人が構文解析＆補完しにくい編集ミスがありましたので謹んで訂正します。
このはてしなく長いプログラマ坂をよ・・・ (スコア:3, おもしろおかしい)
ということは、知らずにやってた時期があったわけですね。
それはさておき、新たな技法を手に入れて過去の所行を見直したり、教科書に書いてある技をそれと知らず再発明したり、 逆についうっかりおっちょこちょいな独自の技法を編み出してしまったり、 「いやお前の考えはおかしい。エライ人が書いた教科書にもこっち方が正しいと書いてある」と言う実はもっともなアドバイスに反発してみたり、 後になって自らの過ちに気付いたり。 プログラマはそうやって、一歩一歩、成長を遂げるもんでしょう。
このトピックの話題も、そういう階段を一段上がり損ねた一事例に過ぎないでしょうから、ほほえましく見守ってあげれば良いんじゃないでしょうか。
# そうだそうだ!と言う賛同者をたくさん集めちゃって、階段の踊り場なんかが形成されたら嫌だけど
Re:このはてしなく長いプログラマ坂をよ・・・ (スコア:2)
構造体の可変長配列のメンバーに可変長配列があって・・・なんてことを昔にやってしまった人間としては、C++のコンストラクタ＆デストラクタは福音でした。STLに至っては言うに及ばずです。 似たような構造体の定義が山ほどあって、こいつの整理に継承と多態が非常に有効であることを知ったときは目から鱗が落ちました。
なぜ、ポインタが必要なのか。なぜ、仮想関数が必要なのか。スクリプト系言語の怠惰さとか、今まで理解できなかった事を理解できたときの喜びって最高だと思うんですけどね・・・。
ぶっちゃけ、僕なんかその快楽を得るためにプログラマをやっているようなものですけど。
共用体 (スコア:1)
可変長配列メンバと同じようなものですが、継承を使うと共用体（可変長レコード）を殆ど使わずに済む（メモリ上で同じ位置に異なる型のデータを置きたい特殊な場合を除いて）のも中々の福音でないかと。
Re:このはてしなく長いプログラマ坂をよ・・・ (スコア:2, 興味深い)
オブジェクト指向は戦場では役に立たない。
そんなことふうに考えていた時期が俺にもありました。
構造体の延長として作った 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.
Re:このはてしなく長いプログラマ坂をよ・・・ (スコア:1, すばらしい洞察)
でも、1962年生まれの人ですからねぇ。
会社ではそれなりにえらい立場な人なはずです。（なんでそんな人がコードを書いているのかは知りませんが）
そういう人が自分は分かってる、って思い込んでるわけで、そうなると現場の若い人たちにもstatic pubulic宣言を
押し付けている可能性が高いです。だから、声を上げずにはいられないのでしょう。
Re:このはてしなく長いプログラマ坂をよ・・・ (スコア:1, 興味深い)
どこにぶら下げるかなやみつつ。
C++ってば、アカデミズムあふれるオブジェクト指向言語なんかじゃ全然ないです。オブジェクト指向もサポートしている変態(本気で考えないと理解できない微妙な制限てんこ盛りのなんでもあり)言語です。
いや正直、テンプレートでメタプログラミングとか、楽しくてしょうがない。でもね、どんなに頑張っても、すらっとスマートポインタとか作れないですよ。なんちゃってレベルならすぐ作れるけど、あまりにもバッドノウハウが必要すぎる。ここ [wikibooks.org]とかよむと、自信なくしちゃいます。
以前はC++最高と思ってたけど、なんかもう疲れたよ。お願い、もう仕様を増やさないで。
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm [aoky.net]
Re:このはてしなく長いプログラマ坂をよ・・・ (スコア:1)
「と言う感じで」がC++とJavaのどちらにかかるのかわかりませんが、
別に Java もとってもオブジェクト指向な言語ではないですよね。
だいたい、プリミティブ型があることからして不純です。
上には上がいる (スコア:2, おもしろおかしい)
コーディングルールで縛るなんてショボイです。技術的に解決できるなら技術的に解決すべきです。
#define private public
#define class struct
Re:上には上がいる (スコア:1)
斜め上には斜め上がいるだとｵﾓﾀ
メンバ変数はローカル変数とグローバル変数の中間 (スコア:2)
問題は複数の関数にまたがってローカル変数を使えないが、グローバル変数だと今度は通用範囲が広すぎるということです。ただ、例えばCだとグローバル変数にstaticを付ければ通用範囲がソースファイル内に限られるので、大体所望のものと似たような効果が得られますが、もうひとつ問題があって、この方法だと変数がプログラム全体で共用になってしまう。
実務的にみたときは、そういう問題の解決策がクラス(のメンバ変数)ということになります。メンバ関数は、それらのメンバ変数を使いたい関数として指定されたもののことです。
Cで、mallocを使って作業用メモリを確保して、それに対応する「ハンドル」を返して……とやっていたものをシステマチックにしたものですね。
ただ、(理論派きどりの)世間のオブジェクト指向の解説に大変うさんくさいものが多いことは認めます。
なお、OOPの機能のうち、継承とインタフェースの系統の機能は、ライブラリを作っているのではないかぎり、それらを定義するという面からは、使う機会があまり多くありませんので、使わないでもいいと思います。
Re:メンバ変数はローカル変数とグローバル変数の中間 (スコア:1)
＞なお、OOPの機能のうち、継承とインタフェースの系統の機能は、ライブラリを作っているのではないかぎり、
＞それらを定義するという面からは、使う機会があまり多くありませんので、使わないでもいいと思います。
業務系のアプリでも、将来の機能追加に備えて機能を抽象化し、拡張ポイントを設定しておくなんて場合には
よく使いますね。というか、最近の仕事はそんなのばっかりです。
Re:メンバ変数はローカル変数とグローバル変数の中間 (スコア:1)
継承やインタフェースを使わないとデザインパターンが導入出来ない．．．
namespace (スコア:1, すばらしい洞察)
そこで、namespaceですよ。お兄さん。
問題外 (スコア:1)
世の中は案外そんなもんらしく・・・
＃で結局デスマーチ、と
Re:問題外 (スコア:4, おもしろおかしい)
継承図なんて要らんよ。フローチャートと同じで、まともなプログラマーにはそんなものは必要ない。
書いても良いけど品質が上がるわけではないので、結局は時間の無駄。
Re:問題外 (スコア:2, すばらしい洞察)
いろんなものが「自称」優秀なプログラマには必要無いのでしょうね
＃で結局デスマーチ、と
Re:問題外 (スコア:3, おもしろおかしい)
＞概要設計、基本設計、コーディングルール、etcetc・・・
見事に全部不要なもんばかりだなあ。感心するわ。
＞いろんなものが「自称」優秀なプログラマには必要無いのでしょうね
平凡なプログラマでも不要です。
あなたが平均以下のプログラマーなのは勝手だけど、
平均以上の人間の足を引っ張るのだけはやめてくださいね。
Re:問題外 (スコア:1)
複数人で作業するならコーディング規約は必要でしょ？
コーディング規則が不要な人達を「平均以上」と定義、というオチでは？
どんな開発であっても設計書は必要だよね？(Re:問題外 (スコア:1, 参考になる)
どんな開発であっても複数人数でやるものならば必須だよね？
アジャイルとかXPとか設計書はいらないなんて開発手法もいわれているけれど
あれってただの夢物語でJavaがポインタなんていらないぜーとか、メモリリークしないよとかとか
いっているのと同じレベルだよね？
設計書もなしでどうやって、機能テストの妥当性をレビューするつもりなんだろう
内部設計以降はいらないと思うけどさ。外部設計以前は必須でしょ。
ライブラリつくってはい、おわりーとかだったら別だけど。。。
ツール利用 (スコア:1)
コードからUML図を作ってくれるツールを使えば、対外的なドキュメントは後から作れるしねｗ
Re:問題外 (スコア:1)
継承図とかは接合部分にだけあればOKだと思う。
最下層の部分とかには不要でしょう。
だって、まともにOOやればクラスなんてどんどん増えていくし。
全部は書ききれないと思う。
接合部にだけこんな感じっていう図を用意するのがいいと思う。
どうしてもほしい人はDoxygenでも使って自動生成すればいい。
そんで、他人が作ったものはクラスというかモジュールは、ブラックボックスとして利用させてもらいたいっす。
そのモジュールの中までは興味なし。暇があったら流し読みしたいけど。
図を一生懸命書く暇があったらテストの一つでも作ってほしいと思うんよ。
by rti.
Re:問題外 (スコア:1)
>納品図書として請求される場合があることを忘れていないか？
そういうことはあるだろうけど、
＞＞ 継承図すら作らずにコーディング始めるとか
には当たらんよね。
その手の書類はコーディング後、又はコーディングと平行して作る物です。
Re:問題外 (スコア:1, すばらしい洞察)
というかdoxygen使えばすぐ出来ちゃうよね。
Effective C++(第３版) を見ると (スコア:1, 参考になる)
23項(p.100)に「メンバ関数より、メンバでもfriendでもない関数を使おう」とあるけど、この項での主張はそうしたほうががカプセル化を強めることができるからというものです。（いわゆる素の関数がない言語の場合はユーティリティクラスのstaticメンバ関数を使いましょうとか書いてある）
なんか元ブログとはいってることが真逆な感じが…。
スルー力 (スコア:1)
みんな釣られすぎなんじゃね？
staticにして、データ構造はどうしてんのよ。 (スコア:1)
全部パブリックにして直接代入するとか、staticにして関数を使うとかは勝手にすれば、と思うけど、
Cでいうところの構造体の操作にあたることは、どうしてるんだろう。
Foo foo(hoge);
Foo::func(&foo);
とかわざわざやってるとしたら、無駄な苦労してるだけとしか。
# ちなみにPythonだとメンバーは全部パブリックで、foo.func(arg)はFoo.func(foo, arg)と同等だったかと。
1を聞いて0を知れ!
そりゃ、決まてるがな (スコア:1)
……てな
寝言事を言ってる人が作ったプログラムを、俺がメンテする事が無ければ、と云う条件が成り立つので有れば、勝手にして。その条件が成り立たなければ……コードじゃなくて異動願いを書きます。
面従腹背の勧め (スコア:1)
呼び出したいメソッドをモシャモシャ生やせばいいんだよ。
外見的にはオブジェクト指向みたいに見えるから、みんなハッピーだ。
Re:ひとりで趣味でやるなら (スコア:2)
＞チームで仕事するなら、ルールぐらい守れよ
年齢から見て、おそらくこの人はルールを
捏造する作る側の人じゃないの？老害が時代錯誤なヘボルールを作って、それに従うよう強要される憐れな若手の姿が目に浮かぶ。
Re:ひとりで趣味でやるなら (スコア:3, すばらしい洞察)
コーディングする立場なら忠実にコーディングすべき。
実害が無かったと思っていても、その行動は間違い。
そもそも、潜在的危険性を産んだのに自覚していないかもしれないし。
それが正しいと思って無視して行動してしまうようではリスキーで使えない。
Re:ひとりで趣味でやるなら (スコア:2, すばらしい洞察)
相手先が固定長の(ファイル|フィールド)の場合、変に頑張って処理を続けるより、
あっさり死んでくれた方が助かるケースもかなりありますよね？
(そもそも想定外のファイルが送られてくる時点で、そのデータは信用できない場合とか)
PGレベルでの実装のきれいさと、仕様としてのきれいさが(矛盾とまではいかないまでも)
反することなど日常茶飯事で、むしろそこの穴を埋めるのがPGとしての腕だと思いますが。
プログラムでのコミュ力というか…
いちPGとしての矜持に反するというその憤りも分かりますが、だからといって
上司を無視するようなその態度(およびそのことを武勇伝的に思っている)も
いち社会人としてはどうかと思いますね…
Re:ひとりで趣味でやるなら (スコア:2, 興味深い)
元コメントのACさんが正しいと思うんですけど。。。
反論するコメントばかり付いてますが、
自分にまわってきた仕様を実際に組む検討をするときに
「いやこれじゃだめじゃん」って気づくことは多々あると思うのですが
皆さんはそれを上司やSEに「これじゃだめです」って訴えないのですか?
間違ってると思ってても、そのまま書くのですか？
こっそり「後で変更可能な仕組み」を入れたりもしないのですか？
それでは、「プログラマー」ではなくて唯の「コーダー」ですよね？
それが「時間や金に縛られる『会社』というものだ」と言われれば
私には反論できませんが、なんか悲しいです。
元ACさんがおっしゃるように
vectorから固定長配列に変換するのなんて数行なんですから
上司さんがvectorの便利さを知らなかったとしか思えないです
Re:ひとりで趣味でやるなら (スコア:1, おもしろおかしい)
# 幾つになっても、お助け屋から抜け出せない生活なのでAC
Re:ぶっちゃけ (スコア:2)
まあそうですよね。「しっくりこない」のなら、別に無理してオブジェクト指向の流儀にしなくたっていい。それでも動くものは作れるし、情シス部門でシステム構築というプロフィールからしてそれほど大規模でない自社内システム専門、保守性なども自己責任なのだろうから。
しかし、作ったものがきちんと動くものになっていないのなら、それはプログラマとして問題ですぜ。で、そういった観点で記事を読み直してみると、そもそもOOPがどうとかいうレベル以前の問題がありそうな気がそこはかとなく。
記事からは、ちゃんと動かないコードを書いているような感じが伝わってくるんだけどどうなのかなあ…。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:3, すばらしい洞察)
> 「使い回し」が可能
前書いたコードからコピペすればいいと思っているので、そんなの問題じゃないんです。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
> 綺麗にコーティングすると「使い回し」が可能な点です。
同意です。
もっともオブジェクト指向で無くとも同様のことは可能です。
可能ですが、オブジェクト指向の言語の方がより、簡単に綺麗に表現できますね。
まあ、いくら道具が良くても使う人の力量以上のことはできないので、
筆者の勉強不足のように感じます。
かくいう私もオブジェクト指向の良さが理解できたのはデザインパターンを知ってからでしたが...
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
> おぶっじぇくと志向の利点は
> 綺麗にコーティングすると「使い回し」が可能な点です。
良くある間違いですね。
あなたが言っていることは、「構造化プログラミング」の手法を使えば「使い回し」可能なコードが実装できるよ、という話で、オブジェクト指向とは関係ない話です。
構造化プログラミングってのは、サブルーチンとか手続きといった処理の組合わせ、使い回しでシステムを設計したり実装する方法。要は printf みたいな便利な関数、ライブラリはどんどん使い回しましょう、という話。
オブジェクト指向は、この処理の組合わせとか使い回しを、オブジェクト中心で考えるように方針転換しましょう、って話ですね。
オブジェクト指向 (スコア:2)
| …オブジェクト中心で考えるように…
は、恐らく前者でしょう。一方後者のオブジェクト指向プログラミングは、C言語での関数ポインタやvoidポインタ等を明示的に使わないで「似ているもの」を「同じもの」と「異なるもの」とに容易に分離した記述(コーディング)を可能とし、「同じもの」の記述を複数行わない((バグも)コピペしない)ことを容易に達成できる言語仕様及びそれを使ったコード作成技法です。
「オブジェクト指向設計」されたものの実装に「オブジェクト指向プログラミング」を用いることは至極自然です。一方「オブジェクト指向設計」を考慮していない設計への「オブジェクト指向プログラミング」の適用も、有用です。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1)
継承だけでなく集約も大事ですよ。
データ構造とメソッドがパックになったオブジェクトが再利用の単位になったことで
複雑なデータ構造や複雑な状態管理を必要とする処理の再利用が容易になりました。
（細かいことを言えばこれはオブジェクト指向というよりオブジェクト・ベースの話ではありますが。）
そのため構造化時代の中心であったサブルーチン・ライブラリのようなものだけでなく、
コンテナ・ライブラリや通信プロトコルのような応用のライブラリ化が
容易になりました。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1, 興味深い)
実際にいろんな現場を体験してると、こう言う「理想論」的な話には違和感を感じてしまいます。
かといって元記事の話は、著者の無知がひどすぎで擁護不可能ですが。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
そうなんですよね。
自分がはじめてJavaのプロジェクトに参加したときのことです。
S2DAOを使っていたんですが、テーブルのコードをクラスごとに定数宣言していてめまいを感じた覚えが。
いろいろとWebを調べてenumを使えるようにしたのですが、時間がかかったのでクラスに反映できませんでした。
それでも、他の会社のソースと比べるとましだったんですが。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1, すばらしい洞察)
本当に隠蔽化されてしまったクラスの
「使い回し」の恐ろしさをしらないなんて
再利用以前 (スコア:1)
でも問題のコラムではクラス変数とインスタンス変数（あるいはモジュール/パッケージとオブジェクト）の区別がちゃんとついていない気配があるので、継承やら使いまわし以前にデータ構造が定義できないと思う。あの理解だとクラス、オブジェクト以前に構造体（C言語）ですらきちんと使えるかどうか怪しい。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
きちんと分割できていればクラスの作り直しで済むのがオブジェクト指向の利点でしょうね。
public staticであらゆる場所が依存しあっていたら常に全体の作り直しになります。
Re:頭の中が機械語な人には (スコア:2, 参考になる)
問題のコラムの人は年は食ってる（といっても私と5つしか違わないがｗ）けど
機械語の人じゃないと思う。
理由はもう一個前のCPUのコラム（これもかなりヒドイ）。
「システムエンジニア 生き残りの極意
システムエンジニアとして長期に活躍した経験に基づく極意、ノウハウを教えます
この業界の基盤技術の核心！ CPUってどんなもの？ [atmarkit.co.jp]」
極意、絶賛実演中 (スコア:4, おもしろおかしい)
いや、生き残りの極意とは、炎上(あるいは炎上マーケッティング）に耐えきる強い耐火性。そして：
あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？ 私は学部は東北大学で大学院が東工大です。
（2010年5月 2日 (日) 14:28のコメント）
私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？
皆さん生きていけないですよ！
（2010年5月 3日 (月) 13:47のコメント）
学歴や将来の取引関係（の可能性)を盾にしてでも決して問題を認めない強心臓にあるんだよ！
彼はそれを背中で教えてくれてるのさ！
Re:極論過ぎるし適当過ぎるとは思うものの (スコア:2)
みながわ氏がテストをどうやってるのか知りたいですねえ。
待っていたらそのうち「テストは人手に限る」なんてコラムを書いてくれそうな気がする。