オブジェクト指向の達人ってどんだけ凄いの？

オブジェクト指向の達 ..

2:仕様書無しさん
07/11/22 17:34:23
つーかオブジェクト指向の達人てなんだよｗ

3:仕様書無しさん
07/11/22 17:34:37
わからんやつは芯で良いよ

4:仕様書無しさん
07/11/22 17:35:25
オブスレ池

5:おじゃばさま ◆GxjxF3yEw6
07/11/22 20:24:44
呼んだ？

6:仕様書無しさん
07/11/22 20:26:44
どんだけ～～～～～

7:仕様書無しさん
07/11/22 23:14:10
オブジェクト指向が全くわからん人に一瞬で理解させるぐらい凄い

8:仕様書無しさん
07/11/22 23:50:33
×理解
○誤解

9:仕様書無しさん
07/11/23 04:57:39
日常会話でオブジェクト指向用語が出てくるぐらいすごい。

この間、俺とワイフの多重継承したチルドのインスタンスがニューされたよ。
目元は俺を継承して、口元はワイフを継承している。
きっと多彩なクラスをインプリメンツしたクレバーなチルドになるぞ。
フューチャーが楽しみだ

10:仕様書無しさん
07/11/23 05:06:18
ルー語じゃねぇかｗｗｗ

11:仕様書無しさん
07/12/02 12:17:17
>>10
その突っ込み見て吹いたw

12:仕様書無しさん
07/12/03 20:27:04
昨日彼女と一緒にメメント観てたらいつのまにかチムポがブリッジしちまってさー
そしたら彼女が俺の上にビジターしてきてアダプタしちゃったよ
まあ全部俺の妄想で本当はシングルトンな毎日なんだけどさ

13:仕様書無しさん
07/12/04 12:06:51
オブジェクト指向全然関係ねー

14:仕様書無しさん
07/12/09 11:27:07
俺の先輩は仕事を俺にデリゲートしてばっかりでこまる。

15:仕様書無しさん
07/12/10 11:02:27
N○○のPMは基本クラスというより抽象クラスで、
メソッドの中身が入っていない上に、全メソッドがオーバーライド必須ときている。。。

16:仕様書無しさん
07/12/10 21:34:00
リアルのすべてのものの継承関係を考え続ける

17:仕様書無しさん
07/12/17 22:02:51
俺そうかも

18:仕様書無しさん
07/12/18 20:43:43
俺にとってのオブジェクト指向とは：プログラミングとは一種の道だ。
その道が出来ていなかったら終わりまでたどり着かない。オブジェクト指向とは
その道を通るときの橋やらフェリーやらそういう物だと考えている。
カプセル化とかは入っていないが割愛する。

19:仕様書無しさん
07/12/18 22:59:41
俺にとっては全ての物事を論理的にとらえるための考え方だな。
たまたまその考え方がプログラミングにも使えるだけだ。

20:仕様書無しさん
07/12/18 23:41:11
お前らの想像以上に達人はすごいよ。
まず達人の作るクラスなんかは階層構造が深すぎて
実装可能なコンピュータが地球上には存在しない。
メソッドの数の総計は宇宙に存在する原子の数よりも多いのではないかと
言われている。

21:仕様書無しさん
07/12/18 23:50:14
存在しないと思われていたjava.lang.Objectのスーパークラスを発見したのも達人の功績

22:仕様書無しさん
07/12/19 00:41:17
>>10が総てだなｗ

23:仕様書無しさん
07/12/19 08:22:16
ルー語ｗ

24:仕様書無しさん
07/12/21 12:57:23
達人は保護されているッッ！

... General Protection Fault.

25:仕様書無しさん
07/12/23 00:26:43
ぬるぽもOOの達人に発見された

26:仕様書無しさん
07/12/28 21:48:47
あ。。。

27:仕様書無しさん
07/12/29 09:43:37
>>9
「直交する概念」「ひも付けられる」
とかも使って欲しい

28:仕様書無しさん
08/02/09 00:01:58
女もオブジェクト。
欲しいときにインスタンス化。そしてインジェクション

金という引数が必須

29:仕様書無しさん
08/02/10 07:56:55
女はファイナライザにとんでもないバグが入ってることがあるからなあ

30:仕様書無しさん
08/02/10 23:46:23
太鼓の達人並みに凄い

31:仕様書無しさん
08/02/10 23:57:35
目からビームが出る

32:仕様書無しさん
08/02/11 01:33:18 BE:156092663-2BP(2)
オブジェクト指向の達人といえば誰だ？
JavaだけでなくSmalltalkを使いこなせる者？

デザインパターンを駆使できる者？

33:仕様書無しさん
08/02/11 02:02:31
使うのがたまたまオブジェクト指向

34:仕様書無しさん
08/02/11 02:03:35
たまたま使うのがオブジェクト指向なだけで、そういう縛りがなければもっと自由にすごい事をやっちゃう人。

35:Test ◆LaogU1uvPU
08/02/11 08:14:03 BE:104062234-2BP(2)
オブジェクト指向の達人になるには
ロバートＣマーチンのアジャイルソフトウェア開発の奥義
に載っているオブジェクト指向設計原則も理解しないとだめかねえ。

36:仕様書無しさん
08/02/11 10:12:26
多分古参が言う「オブジェクト指向の達人」っていうと青木淳さんだろうな。
この人の書く文章は仏教思想も入っていて面白い。

つーか、Matzといい結城といい青木さんといい、日本でのその道の大家はなぜか宗教的なものを備えているのが気になる。

37:仕様書無しさん
08/02/11 14:58:57
まあ、東大卒でオウム真理教に入ったやつと似たようなもんだな。

38:仕様書無しさん
08/02/15 09:53:40
>>36
A氏の言ってることは耳にタコができた古くさいMVCとうさん臭い仏教話だけと思われ

39:仕様書無しさん
08/02/15 13:00:47
俺が一番覚えてる青木さんの文章はコレなんだけど、
URLﾘﾝｸ(bizboard.nikkeibp.co.jp)

裏付けのある凄いことを書く人だと思う。

40:仕様書無しさん
08/02/15 19:31:49
宗教はいってる時点で俺はパスだな
宗教人はたいてい表の顔と裏の顔のギャップが激しいから。

41:仕様書無しさん
08/02/16 00:16:08
宗教人なのではなくて、宗教を信仰しているだけだろ。
日本人はそこら辺の感覚が無いから信仰を持っている人間が奇異に映るのは確かだが。

まぁ、確かに青木さんの言ってるオブジェクト指向話は
あくまでスタンドアロンの仮想世界上で閉じたMVCであって、
当世風のネットワークを意識した設計と相容れない部分があるのも確か。

42:仕様書無しさん
08/02/16 06:23:08
>>41
日本で信仰を持ちながら生活すると
どうしても表と裏ができるんじゃないかな

43:仕様書無しさん
08/02/16 08:40:21
宗教について鈍感なだけなのに、日本人は宗教について寛容とか、
ボケてる奴がほとんどだから、どうしてもそういう対応をせざるをえない。

44:仕様書無しさん
08/02/16 15:24:47
>>40
そうそう。表面はよくても利害が絡むととたんに豹変とかね。

45:仕様書無しさん
08/02/16 19:47:19
>>39
日系社員オツw

46:仕様書無しさん
08/02/18 08:34:23
36の唐突さは社員だな

47:36
08/02/19 00:33:53
社員じゃねーよ。青木さんとも面識は無い。
どちらかと言うと SRE はそこの製品でえらい目にあったからあんまり好きじゃない。

48:仕様書無しさん
08/02/20 16:16:48
>>47
日系さんいらっしゃい。

49:仕様書無しさん
08/02/21 13:05:04
39 正直内容が古くさすぎ

50:仕様書無しさん
08/03/05 20:42:52
誰とは言わないが、日本のソフト業界にOOが導入されようとしていた時、
OOの達人と言われていた人達が変に宗教的概念を混ぜ込んでしまったために
OOが純粋にプログラミング技術として素直に紹介されなかったことが
日本でOOの導入が遅れた要因だと思う。

51:仕様書無しさん
08/04/01 21:50:22
>>50
それはあるな。キリスト教(Java, ruby)とか仏教(Smalltalk）とか、胡散臭さを醸し出していた。

52:仕様書無しさん
08/04/02 01:02:53
結城、松本、青木か。

53:仕様書無しさん
08/04/02 11:52:56
N村S3郎は密教がどーたら、とか言ってたな
鵺だTAOだ言ってる奴等も電電公社方面にいたし

54:仕様書無しさん
08/04/02 15:30:50
共通しているのは自画自賛にすごく熱心な人達ということだな

55:仕様書無しさん
08/04/14 15:24:45
そういう人達の実装技術はどんなもんかね。
matzは処理系実装しているからいいとして、
他の人達が自分自身でつくったものは
どの程度のものなんだろう。

56:仕様書無しさん
08/04/14 15:52:25
じゅん、とか？
URLﾘﾝｸ(www.sra.co.jp)

57:仕様書無しさん
08/04/14 18:33:35
聞いた話だけどじゅんはopengl周りとかquicktime関連は別の人が書いたらしいよ。

58:仕様書無しさん
08/04/15 00:54:14
matzのコードは糞コードと言われてるらしいけどな(どの観点で言われてるのかは知らないけど)。
まぁ、美しい文法を作るのが仕事で、実行効率は二の次とか言ってるみたいだしさもありなん。

59:仕様書無しさん
08/04/15 07:34:33
美しい文法？あのperlくずれみたいな文法が？

60:仕様書無しさん
08/04/15 23:49:32
美しいは確かに間違いだ。すまん。
それなりに力があって読みやすくて痒いところに手が届く文法。

まぁ、俺はそんなもの慣れの問題だと思ってるが。

61:仕様書無しさん
08/05/08 20:05:11
matzってANSIスタイル徹底的に嫌ってなかったか
人とちょっと違うぜ感に浸ってるイメージ

62:仕様書無しさん
08/05/08 20:38:10
(1) 書き始めたのが昔
(2) 一旦どちらかで書いたら混在させないほうが良い

63:仕様書無しさん
08/08/08 07:11:29
教訓
この手の人達は我が強すぎるため協調作業に向いていない。

64:仕様書無しさん
08/08/08 07:38:08
>>62
書き直せばいいだけ。コードレビューにもなるし。
それが面倒なら、フィルタを書けばいいじゃん。Rubyで。

65:仕様書無しさん
08/08/08 09:56:15
>>57
1人の有名プログラマーの影には10人の踏み台プログラマーが使い捨てられているものだよ

66:仕様書無しさん
08/08/09 06:04:22
>>65
10人程度なのが日本人の限界なんだろうな。
Linusなら1桁上をいくからな。

67:仕様書無しさん
08/08/12 15:11:00
OOの真価は他人（特に格下）に使わせるものを作るときに発揮されるから
達人はすさまじいです。

68:仕様書無しさん
08/09/15 14:31:21
boost使ってんのすげーという人がいる。
そこでboostを作っている人はドンだけ凄いかってこと。

69:仕様書無しさん
08/11/08 14:28:41
しかし思うんですが、オブジェクト指向設計や同プログラミングでチームで開発する
という場合、横割りでクラス分担するとかするという方法では、基本的にメソッドなど
のインターフェースを最初に決めておいて一斉に作成作業に取り掛かるとなったとき、

後から後から次々にここはこうでないとダメだった、こうしよう、あれはああ
でなかったらできない、こうしよう、どうしよう・・・というインターフェースの変更が
とめどもなく現れてくる予感がして、収集が付かなくなる感じがするのですが、

実際にやっておられる方々はそうした点をどうやって乗り越えておられるのですか？
よろしかったら教えてください。

70:仕様書無しさん
08/11/08 14:41:24
>>28
女にオーバーライドしたことがないクセに・・・

71:仕様書無しさん
08/11/08 14:56:34
>>69
多人数の時には、設計時に十分レビューをすることで対処。
比較的少人数の時には、設計と実装を毎日のように往復することで対処。

72:仕様書無しさん
08/11/29 04:48:27
オブジェクト指向とは、楽するために苦労する為のものである。

73:仕様書無しさん
08/11/29 11:27:42
本当に大事なのは、オブジェクト指向の達人になることではなく、プログラミングの達人になること。
オブジェクト指向の達人なんて、みんなインチキコンサルやセミナー屋ばかり。

74:仕様書無しさん
09/03/28 05:02:21
オブジェクト指向はそもそも量産のための技術だからな

オブだけでジムやボールを作れても、オブだけを極めてもガンダムは作れない

75:仕様書無しさん
09/03/28 09:34:55
アルゴ君に続く新人「オブ君」の誕生を見た！

76:仕様書無しさん
10/07/13 03:00:06
オブジェクト指向って言いながらできる人って少ないんだよね。
メソッドの引数に応じて、オブジェクトの振る舞いが変わるとか死ねばいい

77:仕様書無しさん
10/07/13 09:16:55
引数の値によって関数の結果が変わらなかったら関数の意味がないだろ。
実はオブジェクト指向以前の人って多いんだよね。

78:76
10/07/13 12:34:54
>>77
あほすぎワロタ

79:仕様書無しさん
10/07/13 12:35:54
結果と振る舞いを同義だと思ってる人は死ねばいい

80:仕様書無しさん
10/07/13 12:41:32
メソッドと関数が同義だと思っている人は死ねばいい

81:仕様書無しさん
10/07/13 13:47:35
C言語の関数とC++のメソッドはクラスに属するかの違いだけで、大した違いはないから
たかがクラスが理解できているからといって調子に乗るなよ、ガキ

82:仕様書無しさん
10/07/13 13:55:46
どうやら概念が全くできていないらしい。
>>72は>>81のような人間に作られたコーディングで苦戦を強いられてるんだよ

83:81
10/07/13 14:02:19
>>82
だから1KStep/DayのPG/SE/Corderだから苦戦なんて全くの別世界

84:81
10/07/13 17:30:27
>>82
全く理解できているので、もう一言。
>>81で大した違いはないといったのは、大雑把に言えば
メソッドはそのクラスの変数に対して操作を行うことができて
他のクラスや、どのクラスにも属さない関数からの直接の
アクセスを禁止して、変数の操作を限定している。
これによって、不正な変数操作ができないようにしているが、
私の考えとしては、メソッドはクラスに属する関数で
あり、なんらそれを異なるものと認識するのは違っていて
関数という範疇におさまるものと考えられるが。

85:81
10/07/13 17:36:52
関数の機能
・変数の値を操作する
・他の関数を呼び出す
この機能をメソッドも同じくもっているため
上記のように考えられるが。

86:仕様書無しさん
10/07/13 20:19:52
まず理解しやすく分解してみるか。

>　大雑把に言えばメソッドはそのクラスの変数に対して操作を行うことができて
>　他のクラスや、どのクラスにも属さない関数からの直接のアクセスを禁止して、変数の操作を限定している。
メソッドはprivate protected 属性へのアクセスのために存在する。
private protected 属性によりデータをカプセル化し、他のインスタンスからの直接のアクセスを禁止する。

>　これによって、不正な変数操作ができないようにしているが、
>　私の考えとしては、メソッドはクラスに属する関数で
>　あり、なんらそれを異なるものと認識するのは違っていて
>　関数という範疇におさまるものと考えられるが。
これによって、インスタンスの持つデータに対する外部からの不正なアクセスを禁止し、
外部からデータの変更を防止する。
よって関数と言う事になる。

>　関数の機能
>　・変数の値を操作する
>　・他の関数を呼び出す
>　この機能をメソッドも同じくもっているため
>　上記のように考えられるが。
読解不能

俺、お前部下にいたらイラン

87:仕様書無しさん
10/07/13 21:08:56
お前が偉そうに書いた事は全て分かっている。

＞メソッドはクラスに属する関数で
に関してはメソッドはクラスに属している関数ということができ
と修正する。

後段は関数とメソッドの機能の類似点を上げているだけで、
C言語の関数をC++ではクラスごとにその関数をクラスの変数を
操作するように新しく定義したまでの事であり、関数が進化した
だけのものだと考える。

オブジェクト指向を学んでから、16年経っている俺に偉そうな
講釈を有難う。

88:仕様書無しさん
10/07/13 21:18:39
お前の部下になぞ、何でならなくてはならないのか分からないが、

>>　大雑把に言えばメソッドはそのクラスの変数に対して操作を行うことができて
>>　他のクラスや、どのクラスにも属さない関数からの直接のアクセスを禁止して、変数の操作を限定している。
>メソッドはprivate protected 属性へのアクセスのために存在する。
>private protected 属性によりデータをカプセル化し、他のインスタンスからの直接のアクセスを禁止する。

ここの部分はお前が勝手に上記の部分の説明をしただけで
なんら言っている事に相違はないだろ。
あるんだったら、指摘しろ。

C言語の関数の機能、特徴をC++のメソッドも持っているということで、メソッドは関数の
SubSetということがいえるのではないかと言っている訳だが、通じないの？

89:仕様書無しさん
10/07/13 22:12:12
>>81はVB厨

90:仕様書無しさん
10/07/14 01:13:40
俺のチンポクラス、ずっとラッピングされたままなんだけど。

91:仕様書無しさん
10/07/14 03:52:47
長年オブジェクト指向に携わっていながら
その本質を３行でまとめられないとか才能無いから
はやく業界から立ち去ってくださいね

92:81
10/07/14 06:29:36
>>89
何故？

>>91
じゃあ３行でまとめてくれ。

93:仕様書無しさん
10/07/14 08:59:06
>>81さん
あなたは勉強しなおすべき

94:仕様書無しさん
10/07/14 09:10:03
どこが間違っているのか指摘してくれ、自分の覚えている内容と
違うからといって間違いとは限らないんじゃないの？

95:仕様書無しさん
10/07/14 09:13:49
>>91
立ち去るとか言ってもねリストラされてから、就職活動中。
13KStepの新規タスクの開発をしたから、自分でいうのも
何だけど、かなり優秀なPG/SEといえると思う。
年収査定も430万円～680万円だからね。
俺に業界から去れなんて言う人間は、自分の年収査定を
晒してみろよ。

96:仕様書無しさん
10/07/14 09:16:24
お前鬱病だろ
プライドが高いくせに仕事ができんからってこんなとこで鬱憤晴らしていても仕方ありませんよ。

97:仕様書無しさん
10/07/14 09:17:09
すぐにテレビ局がかみついてきて、自分の説を世の中に
公開するのがおかしいというような発想は官僚的であり、
そのような思考がこの国を凋落させている原因だと思う。

「メソッドは関数のサブセットである。」
という事に対してね。

何か真面な反論がある方はどうぞ。ご教授いただきたい。

98:仕様書無しさん
10/07/14 09:18:51
>>96
仕事ができないんじゃなくて、俺の能力を活かせるような真面なプロジェクトが
ないっていう事が問題なの。
4/15プロジェクトだった、真面なプロジェクトは。

99:仕様書無しさん
10/07/14 09:22:06
>>96
過去にそのようになった事はある
・せまい
・うるさい
・仕事がない
・ネットがつながっていない
・椅子が固い
という信じらねない現場があって。

100:仕様書無しさん
10/07/14 10:15:49
>>97
設計上では、関数が一連の処理をまとめた手続きであるのに対し、
メソッドはオブジェクトへの操作である。
これをOOPLの構文だけを見て何の前提条件も無しに、
一緒くたに「同じ」としたのでは、概念が分かってない、
と言われてもしょうがないな。
あんたは実装の話しかしてない。

101:仕様書無しさん
10/07/14 10:21:14
>>100

102:仕様書無しさん
10/07/14 10:22:33
>>100
同じとは全くいっていない、ちゃんと読んで欲しいね。
>>85に書いてある特性をどちらも持っているから
メソッドが関数を汎化したサブセット(サブクラス)
と考えられると言っているのだが。

103:仕様書無しさん
10/07/14 10:44:48
>>100
>一緒くたに「同じ」としたのでは、概念が分かってない、
概念はわかっている。ならどこが違ってたのか説明してくれないと
分からない。

104:仕様書無しさん
10/07/14 11:48:17
概念と実装をごっちゃにして説明するけど、要は仮想呼び出しされるのがメソッドで、
関数はそれができない、でいいんじゃないのか？

105:仕様書無しさん
10/07/14 12:13:42
>>102
関数がどうとかどうでもいいけど、
汎化したらスーパーセットじゃねーの？

106:仕様書無しさん
10/07/14 13:40:30
>>102
クラスの中にある関数がメソッド
グローバルな領域にある関数との違いはクラスの中にあるかないかの違い

と言いたいの？ｗｗｗｗｗｗ

107:仕様書無しさん
10/07/14 13:41:32
age

108:仕様書無しさん
10/07/14 14:50:28
>>104
仮想的に呼び出されるなんて言い回しは初めて聞いたけど。

>>105
Super Class(既定クラス)の継承したものがSub Class(派生クラス)であり
汎化は基底クラスから派生クラスを継承を表すもので。派生クラスは基底クラスを
汎化したものでサブセットではないのだろうか？
これは認識が誤っているかもしれないので、その場合は訂正していただきたい。

>>106
メソッドはC言語の関数と>>85の点で同じ機能・特性があるため
関数を汎化した概念だと言っている。
クラスの中にあるかないかの違いとは言っていない。
それでは、メソッドが関数と比べてクラスに属するという事以外の違いを説明してくれ。

109:仕様書無しさん
10/07/14 15:01:40
×クラスの中にあるかないかの違いとは言っていない。
○クラスの中にあるかないかの違いとは言っていなく、
クラスに属するかの違いと言っている。

110:仕様書無しさん
10/07/14 15:05:02
スーパークラスのメンバがサブセットで、派生クラスのメンバがスパーセット？？？

111:仕様書無しさん
10/07/14 15:11:03
全ての訂正
×派生クラスは基底クラスを汎化したもの
○派生クラスは基底クラスを特化したもの

×スーパークラスのメンバがサブセットで、派生クラスのメンバがスパーセット
○スーパークラスのメンバがスパーセットで、派生クラスのメンバがサブセット

112:仕様書無しさん
10/07/14 15:20:00
>>108
>ソッドが関数と比べてクラスに属するという事以外の違いを説明してくれ。

class hogehoge
{
　　private $_name;

　　function __construct($name)
　　{
　　　　$this->_name = $name;
　　}

　　public function zikosyoukai()
　　{
　　　　echo "私の名前は " . $this->_name . " です";
　　}
}

class hogehoge2
{
　　public function zikosyoukai($name)
　　{
　　　　echo "私の名前は " . $name . " です";
　　}
}

全然違うよね？？

113:仕様書無しさん
10/07/14 15:20:44
　

114:仕様書無しさん
10/07/14 15:54:12
>>112
何が言いたいのかよく分からん。
クラスhogehogeではメンバ変数があり、hogehoge2ではメンバ変数がなく
hogehoge2クラスのインスタンスを生成してから、変数を引数で指定しなければ
ならない、程度の違いしか見い出せない。
もしかして、hogehoge2クラスのメソッドは、メンバ変数を操作しないとでも
いいたいの、それで、私の2つの条件が満たされないとか。
重箱の隅をつつきすぎのような…

115:仕様書無しさん
10/07/14 16:03:23
自己紹介してもらうのになんで名前を指定してあげないといけないんだよ！！！！！！！！！！！！

116:仕様書無しさん
10/07/14 19:27:43
逃げたのか

117:仕様書無しさん
10/07/14 22:30:11
>>114
ちょっとその君が分かってるところの
関数とメソッドのそれぞれの概念を書いてみてよ。

118:仕様書無しさん
10/07/14 22:42:19
>>117
概念ということになるとどちらも、データの操作を行う事と
他の関数、メソッド、ライブラリを利用する事と考えれば
差はないのではないかと。

119:仕様書無しさん
10/07/14 23:17:55
>>1
自作自演はそろそろ辞めにしましょうね

120:仕様書無しさん
10/07/16 00:52:14
はじめてオブジェクト指向でプログラム作ったときは
まさにアンチパターンのオンパレード
こんなことなら手続き型で作ったほうがよっぽどすっきりしてシンプルだった
でも上手く使いこなせるようになると生産性・保守性・拡張性が高く
かつ美しいプログラムを作れるようになる

121:仕様書無しさん
10/07/16 19:53:44
>>120
ならないよ
オブジェクト指向の何の要素でそんなことになるって言ってるの？

122:仕様書無しさん
10/07/16 20:51:48
>>121
リファレンスをプロパティで持つか
サブクラスとするか
多重継承するか

すっごく迷う私に助けをください

123:仕様書無しさん
10/07/16 21:49:12
>>121
え？ならないの？
だったらオブジェクト指向でプログラム開発する理由はなに？
どんな利点があるの？

124:仕様書無しさん
10/07/16 22:33:04
>>74
>オブだけでジムやボールを作れても、オブだけを極めてもガンダムは作れない
一年以上前の発言にレスするね。
ガンダムを一つ作ったなら、オブでガンダムがいくらでも作れるだろ。

125:仕様書無しさん
10/07/17 00:09:14
>>123
ないよ

この業界、腐りまくってるからセミナーで儲けたいクズどもが
とにかく出てくるもの出てくるものなんでも大絶賛して
まったく無価値なものをやたらと高価そうに魅せるから注意な

オブジェクト指向で開発する意味？
俺が聞きたいよｗ

クズどもに騙されてるような奴は自分が騙されたことにすら気がつかないマヌケだから救いようがない
頭のいい奴はオブジェクト指向で書いたソースと
そうでないものとで比べてさっさと結論付けてオブジェクト指向なんてゴミ箱に捨ててるｗ

126:仕様書無しさん
10/07/17 00:44:30
>>125
自分はjavaから入ったから
cのようなソースを読んでると見難くてだめなんだが

127:仕様書無しさん
10/07/17 03:38:34
javaをそこそこ長く使っているが、オブジェクト指向のメリットは、コピペじゃなく、
継承による差分コーディングと、継承による実装範囲の制限くらいじゃないかな。

ある程度機能をメソッド単位で分割してあると、適当なメソッドだけ書き換えてとか
できる。まあ、privateのプロパティでgetterがなくて結局コピペコードになる場合も
多々あるけど。アスペクト志向ってのはこの差分コーディングを推し進めた
感じかなぁと。

後者はweb系でよくある、フレームワークの部分に普通の人は触らせずに、
ビジネスロジックだけ書かして、ダメコードの被害を最低限そのビジネスロジック
一つに押さえ込むっていう方法。

拡張性やら保守性なんてものは方法論云々じゃなくて、結局のところ適度な
リファレンス、適度なコメント、そして何より必要なのはその手法に習熟してる
って事だと思うな。ダメなコードはオブジェクト指向だろうが、手続き型だろうが
何をしようとしてもダメ。

128:仕様書無しさん
10/07/17 07:37:48
>>127
>継承による差分コーディングと、継承による実装範囲の制限くらいじゃないかな
出だしからレベルが低すぎて話にならない
こんなのそんなに時間とるか？と聞きたい

そもそもソフト開発において実装という作業工程にそんなに時間がかかるか？と
全体をよく見てからもう一度発言したらいいと思う

129:仕様書無しさん
10/07/17 10:39:58
>>128
レベル低くてすいません＾＾レベルが高い貴方はどういう所で時間を使ってるか
教えていただけませんか？＾＾

＞そもそもソフト開発において実装という作業工程にそんなに時間がかかるか？と

テストとその不具合の修正、機能追加による修正が私の場合は多いですね。
いかに他に影響なくデグレを起こすことなく、なるべく早くということが求められます。
あとは実際にコードを書くより、どう書くか考えている時間の方が多いですけどね。

130:仕様書無しさん
10/07/17 10:57:20
>>127
> 継承による差分コーディングと、継承による実装範囲の制限くらいじゃないかな。

こんなのOOPのメリットに上げたら、アンチOOP厨の的だろｗ

ネットのないころに既存のソースとか限られた本見て自己流でOOPしているとこんな感じになったな

131:仕様書無しさん
10/07/17 10:59:45
アンチOOPはOOPの出始めからいるので、OOPのFAQ的な弱点を知り尽くしていると思われたし。
アンチすることが趣味なのはおいておいて、
こんなスレで下手に「OOPはこんなもんだ、こんなメリットが」と言われると、
闇金が債務者をカタにハメるかのごとく、テンプレ通りの反論が返ってくるのだよ？

132:仕様書無しさん
10/07/17 11:44:13
それじゃそのカタにはまったテンプレ通りの反論を見せてみ？

133:仕様書無しさん
10/07/17 12:09:32
>>129
>テストとその不具合の修正、機能追加による修正が私の場合は多いですね
（仕事したことあるのかな？この人・・・）

134:仕様書無しさん
10/07/17 12:17:30

またもや自作自演が始まったか

そもそもオブジェクト指向の達人は
オブジェクト指向の思考をして設計してます。

135:仕様書無しさん
10/07/17 12:20:52
そしてコーディングをプログラマーに指示
１．プログラマー何こいつ言ってるの？？わけわからん設計と思いながら
２．書かれた通りにコーディングを進める
３．わけわからん設計と思っていた自分が恥ずかしくなる
４．そういう事かぁ～ってつぶやく
５．ネ申　の存在に気が付く

以上

136:仕様書無しさん
10/07/17 22:00:34
オブジェクト指向が分かると世界が面白くなるけどすぐにつまらなくなる
楽しいのは本当に一瞬

137:仕様書無しさん
10/07/17 22:08:48
それは分かったつもりになっただけの馬鹿

138:仕様書無しさん
10/07/17 22:11:12
そんなに顔を赤くするなよ
無能を受け入れるのも勇気だ

139:仕様書無しさん
10/07/17 22:32:35
規模の小さなシステムではオブジェクト指向なんぞ
何の意味もない

140:仕様書無しさん
10/07/17 22:58:20
オブジェクトって、システム自体じゃなくて、テスト用のツールを作るためにある。
コードがオブジェクトだからメンテナンス性がいいというのは実はあまり関係なくて、
典型的な例が、機械を動かすシーケンサで、これはアナログ／デジタル回路のキ
メラなので、構造化すらできなくてスパゲッティ化しやすい。これをデバッグするた
めに機械をつないで動かしていたら破産してしまうので、機械そのものをシミュレー
トするオブジェクトシステムを代わりにつないでやれればそれに越したことはなく、
機械そのものの値段と比較すれば、ある程度の予算をかけてオブジェクトデバッ
グシステムを組むことができる。コード自体がスパゲッティでも既に運用されてい
る場合、書き直すよりはデバッグシステムを作ってしまった方がおそらく早い。

141:通りがかり
10/07/17 23:34:30
>>127も>>128も>>129の考えもわかる
>>136も>>139もわかる
>>134 >>135はすごく分かる

>>140はさっぱりわからん
そのシュミレートするオブジェクトシステムと
このスレのオブジェクト指向は全く違うものだと思います！

142:仕様書無しさん
10/07/18 00:36:39
大丈夫。このスレの大半は彼がオブジェクトシステムって口走ってるとこで
オブジェクト指向を理解して無いんだなってことぐらい把握できてるよ。

143:仕様書無しさん
10/07/19 04:26:21
オブジェクト指向もわからない人がプログラマーになれるの？ｗｗｗ　ぷぷぷ

144:仕様書無しさん
10/07/19 11:48:32
デザインパターンとUMLを解さない奴にオブジェクト指向は無用の長物
むしろそんな輩は邪魔になるから手を出さないでくれ

145:仕様書無しさん
10/07/19 13:15:06
>>144
オブジェクト指向を理解していたらデザインパターンなんて使うタイミングないはず
オブジェクト指向は現実モデルを設計に当てはめる設計手法で
デザパタは金型プログラミングなので手法同士がぶつかり合って互いに邪魔になる

なんのつもりでオブジェクト指向語ってるのか知らないけど
お前みたいなにわかが一番邪魔なんじゃないだろか？

146:仕様書無しさん
10/07/19 17:45:18
デザインパターンって、早い話が普通の仕事で言うルーチンワークの業務手順
みたいなもんだろ？

何でもいいけど、UMLで書けば漏れなく仕様が決まるとか勘違いしている
馬鹿大杉。

147:仕様書無しさん
10/07/19 17:56:59
> オブジェクト指向を理解していたらデザインパターンなんて使うタイミングないはず
普通に使っているだろｗ
いや、お前もだよ。

148:仕様書無しさん
10/07/19 18:09:49
「デザインパターン」とか「MISRAC」とか、昔からごく普通にあるコーディング
手法にもっともらしい名前を付けることで、あたかも自分が考えたとか、新しい
技術であるかのように錯覚させているものって多いよなぁ。

竹島に、独島と名前を付けて領有権を主張するようなものか？

149:仕様書無しさん
10/07/19 18:13:20
デザパタ理解してテンプレート理解してＣ＋＋使うと最強

150:仕様書無しさん
10/07/19 18:45:44
>>148
そうそう。そもそもがオブジェクト指向なんてマルチメソッドの特殊例でしかない。

151:仕様書無しさん
10/07/19 18:59:36
>>148
それ、デザインパターンの本の冒頭に、
自分で考えたものではなく、名前をつけたものであるって
ちゃんと書いてあるからｗ

お前はデザパタ本の冒頭レベルに過ぎない・・・

152:仕様書無しさん
10/07/19 19:07:52
>>151
だから、とにかく新しい技術というネタや切り口を持ち出すことで、本を買わ
せたい出版社やライターの思惑があるだけで、立ち読みで冒頭を確認すれば
十分、わざわざ本にして出すような有意義な中身なんてもももとないってことだ。

153:仕様書無しさん
10/07/19 19:11:32
デザパタ本を読むぐらいなら、Smalltalk-80のソースを読め、と言いたい。

154:仕様書無しさん
10/07/19 19:11:50
>>152
じゃあ、お前はどんな本なら有意義だと思うんだ？

155:仕様書無しさん
10/07/19 19:17:32
誰も知らないことを書いている本なら有意義かな。

誰も知らない＝俺も知らないだからね。
誰かが知っていることは、俺も知っていることなので
価値はない。

156:仕様書無しさん
10/07/19 19:19:20
誰も知らない = 著者も書いてあることを知らない。そんな本は著者がいないのでありえない。証明終

157:仕様書無しさん
10/07/19 19:22:36
>>154
最近は、買うに値するような本はないね。昔は買っていたリファレンス本みたい
なものさえネットで無料で手に入るし、本は内容がアップデートされないから、
古くなると使えない。

電子書籍で流通したとしても、いまさらソフトウェア関係で買いたいと思う
ような本なんて思い当たらないなぁ。

英文の文書だってGoogle翻訳で必要な箇所だけ訳して必要ならワードなりの
文書に貼り付けてPDF化。わざわざインプレスあたりの本を買うまでもない。

158:仕様書無しさん
10/07/19 19:23:30
>>157
誰もお前個人の感想なんて聞いてねーんだよ

159:仕様書無しさん
10/07/19 19:27:18
>>158 の書き込みみたいな、内容がない本ばかりだから、買う価値がない。

なのに、出版社は >>158 の書き込みのように、毎月決まった冊数の新刊本を
出してくるのだな。

160:仕様書無しさん
10/07/19 19:31:58
ふぅｗ

内容が無いと
自分にとっては必要が無い本の
区別がつけられないんだね。

こういう人は・・・ちょっとうちには要らないｗ

161:仕様書無しさん
10/07/19 19:41:03
うちってどこの特定派遣業の方？(w

内容がない本 ∪ 自分にとっては必要が無い本
内容がない本 ∩ 自分にとっては必要が無い本
内容がない本 ⊆ 自分にとっては必要が無い本
内容がない本 ⊂ 自分にとっては必要が無い本
内容がない本 ⊇ 自分にとっては必要が無い本
内容がない本 ⊃ 自分にとっては必要が無い本

という集合がいずれも成立しうることさえ理解できんのかな？
まぁ、全角英数字使ってる時点でお里が知れるけど。

オナニー本を自費出版するのは勝手だが、頼むから、間違っても設計とか
実務には関わらんでくれ。

162:仕様書無しさん
10/07/19 19:45:58
>誰かが知っていることは、俺も知っていること

実際云々以前に、この姿勢が技術者として終わっとる

163:仕様書無しさん
10/07/19 19:52:55
売る側が買わせたい本と、買う側が欲しいと思う本との乖離かな。

IT業界のブラックぶりが広く知れ渡るようになり、わざわざ高い金払って
ITドカタを目指す若者も少なくなって道理。