オブジェクト指向とは 分かりやすく教えてくれ

1

： 仕様書無しさん [sage] 2018/03/24(土) 14:39:26.84

PG、SE歴17年だが
いまだに良く分からん
もやっとしてる
教えてくれ

2

： 仕様書無しさん [sage] 2018/03/24(土) 15:27:32.69

本が一杯出てるからそれ読めばいいだろ
読んで理解できないのならここで説明した所で無理だろ

3

： 仕様書無しさん [] 2018/03/24(土) 16:36:10.31

どっちが欲しいの？　ボケ？　マジレス？

4

： 仕様書無しさん [sage] 2018/03/24(土) 16:57:08.73

OOPはポインタ

5

： 仕様書無しさん [] 2018/03/24(土) 17:27:25.63

全部staticでいいじゃん

6

： 仕様書無しさん [] 2018/03/24(土) 17:29:16.62

まず、Cの構造体の勉強をすることだな。

7

： 仕様書無しさん [sage] 2018/03/24(土) 18:50:15.40

ウンコ

8

： 仕様書無しさん [sage] 2018/03/24(土) 19:05:28.24

プログラミング関連はWikipediaが割と良い

9

： 仕様書無しさん [sage] 2018/03/24(土) 20:20:18.00

オブ脳本でも読めば？

10

： 仕様書無しさん [] 2018/03/24(土) 20:43:41.24

>>1

17年やってわからんとは、つける薬がないほどの馬鹿だ。
迷惑だからPG辞めたほうがいいな。

11

： 仕様書無しさん [sage] 2018/03/24(土) 21:30:17.97

メリットの説明はできた者がいない

どや顔でやって来るやつは大抵意味不明なことをのたまって終わり
オブジェクト指向に脳をやられている

12

： 仕様書無しさん [] 2018/03/24(土) 22:14:51.56

>>11

脳がやられているのでOOP理解できなかった奴

13

： 仕様書無しさん [sage] 2018/03/24(土) 22:15:36.11

なんてこったい
オーノー

14

： 仕様書無しさん [sage] 2018/03/24(土) 22:24:50.59

>>1

使ってる言語は？

15

： 仕様書無しさん [sage] 2018/03/24(土) 22:31:51.65

>>12

脳がやられているのでメリットを説明できない奴？

16

： 仕様書無しさん [] 2018/03/25(日) 00:08:40.33

ところで「チンボがシコシコする」という日本語表現は、文法的に正しいのか？

チンボ「を」シコシコするのではなくて、チンボ「が」シコシコする。この場合、「チンボ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！

17

： 仕様書無しさん [] 2018/03/25(日) 00:14:32.10

（第1章 はじめに　2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。

『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル

18

： 仕様書無しさん [sage] 2018/03/25(日) 00:35:27.13

凄いな完璧にオブジェクト指向を表現した
完璧にだ

19

： 仕様書無しさん [] 2018/03/25(日) 01:28:13.49

>>16

「舌がピリピリする」みたいな
身体の受動的感覚なら文法的に可
「顔がニコニコする」みたいに
動作主体が人間なら不可

20

： 仕様書無しさん [sage] 2018/03/25(日) 11:24:17.96

人類のスーパクラスはネズミの祖先だと思うんだ

21

： 仕様書無しさん [] 2018/03/25(日) 12:02:46.92

まだ進化論信じてんだ

22

： 仕様書無しさん [] 2018/03/25(日) 12:03:24.49

まだextendしてきたと思ってんだ

23

： 仕様書無しさん [sage] 2018/03/25(日) 13:46:32.99

人類のスーパクラスは哺乳類
OOPが理解できない最大の理由

24

： 仕様書無しさん [] 2018/03/25(日) 14:44:38.63

自然言語処理の知識はゼロなのでわからないです。面白いアイデアだと思うので、Twitterの自然言語処理が専門の方々に聞いてみては？
ttps://peing.net/ja/q/417c9e29-35de-4c95-8323-afd6a50fcbc7

25

： 仕様書無しさん [] 2018/03/25(日) 15:05:25.89

>>23

extendsしてると本当に思ってるゔぁか

26

： 仕様書無しさん [sage] 2018/03/25(日) 15:07:37.24

マジレスすると、OOPが有用かどうかは分からないが、継承がフレームワーク作成側、利用側の両者で直感的なのは間違いない。
また、クラスに対してC#拡張メソッドより PHPtraitの方が色々問題もありそうだが直感的なmixinだ

27

： 仕様書無しさん [sage] 2018/03/25(日) 21:56:10.25

>>21

進化論がダーウィンのものだと勘違いしてる奴が此処にも。

28

： 仕様書無しさん [sage] 2018/03/26(月) 22:22:24.17

>>1

考えるんじゃない、感じろ

29

： 仕様書無しさん [sage] 2018/03/26(月) 23:09:46.00

>>27

進化論はダーウィンの物ではない、悪魔の物だ

30

： 仕様書無しさん [sage] 2018/03/26(月) 23:25:05.78

人間にわからんものは神か悪魔のせいにしとけば間違いない

31

： 仕様書無しさん [sage] 2018/03/27(火) 01:55:18.27

全て乾巧って奴の

32

： 仕様書無しさん [] 2018/03/31(土) 02:03:04.50

>>27

どっから“ダーウィン”って言葉が出てきたんだよ。ヴァカなのか!?

33

： 仕様書無しさん [sage] 2018/03/31(土) 02:14:23.88

タービンだっけ？

34

： 仕様書無しさん [sage] 2018/03/31(土) 04:05:36.68

まだ進化出来ないから仕方ないな

35

： 仕様書無しさん [sage] 2018/03/31(土) 04:43:13.93

進化の石がないだけやで

36

： 仕様書無しさん [sage] 2018/03/31(土) 06:53:43.60

人類はとっくに自ら進化を促せるだけの力はあるのに神だの悪魔だの呪縛で出来ないでいる

つまり、extendedじゃなくrevolutionというキーワードにすべきだった

37

： 仕様書無しさん [sage] 2018/03/31(土) 08:46:12.73

OOPの説明に犬猫だすのは無能

38

： 仕様書無しさん [sage] 2018/03/31(土) 09:09:40.69

カモノハシで説明してくれないとよくわからないよな

39

： 仕様書無しさん [sage] 2018/03/31(土) 09:36:45.70

データをまとめた構造体に、そのデータを扱うメソッドも入れてしまおうというのは自然な流れだし
メソッドを入れたんなら、それで内部データにアクセスできるから、外部から勝手に変更されないようにアクセス制限を儲けようというのも自然な流れだし、
型を拡張したり、拡張した型によって呼ばれるメソッドを変えられるようにしたら便利だなという考えに行き着くのも自然な流れだった。
つまり、オブジェクト指向はプログラミング工学の進化の仮定で発生したごく必然的な考え方なのであーる。

40

： 仕様書無しさん [sage] 2018/03/31(土) 09:40:53.28

>>39

鶴と亀を引数にとるメソッドは何処に書けばいいの？

41

： 仕様書無しさん [sage] 2018/03/31(土) 10:21:23.83

何をするメソッドなのか

42

： 仕様書無しさん [sage] 2018/03/31(土) 10:24:50.01

>>41

鶴亀算
豚と猫の拡張も考慮したい

43

： 仕様書無しさん [sage] 2018/03/31(土) 10:54:48.19

鶴亀ソルバってクラスを作って、Animalクラスを引数にとるSetAnimal関数を作る
Animalクラスを継承したTsuruクラスとKameクラスを作る
鶴亀ソルバを作る人は、引数のクラスを気にせず実装出来る
Butaクラスを作る人やNekoクラスを作る人も、そのクラスがどう扱われるかを気にせず実装できる

44

： 仕様書無しさん [sage] 2018/03/31(土) 11:06:35.55

進化の過程で必要なのはバージョン管理

45

： 仕様書無しさん [sage] 2018/03/31(土) 12:16:16.90

>>43

全部でいくつクラスできるんです？
ブレーメンの音楽隊以上にはなります

46

： 仕様書無しさん [sage] 2018/03/31(土) 12:19:33.53

足の本数が整数でわかれば計算できるときに
なぜAnimalクラスが必要か！？

47

： 仕様書無しさん [sage] 2018/03/31(土) 12:22:24.94

自然界はオブジェクト指向ではない。
生物の分類なんて完璧にはできない


だが、人間が理解しやすいように分類したものは
オブジェクト指向で表現することが可能
完璧な表現なんか誰も求めていない
目的が達成できれば良いのだよ

48

： 仕様書無しさん [sage] 2018/03/31(土) 12:22:35.99

Animalじゃなかったその下

49

： 仕様書無しさん [sage] 2018/03/31(土) 12:33:04.42

Animalの下っていうと
Humanか？

50

： 仕様書無しさん [sage] 2018/03/31(土) 13:20:04.83

class Human extended Ameba

51

： 仕様書無しさん [sage] 2018/03/31(土) 13:32:39.80

new 動物("鶴", 2)
new 動物("亀", 4)

52

： 仕様書無しさん [sage] 2018/03/31(土) 13:51:09.60

ムカデサポート

53

： 仕様書無しさん [sage] 2018/03/31(土) 14:30:15.36

Tsurukame t = new Tsurukame();
t.setAnimal(0, new Tsuru());
t.setAnimal(1, new Kame());
Result r = t.calc(20, 60);
println(r.get(0))
println(r.get(1))

54

： 仕様書無しさん [sage] 2018/03/31(土) 14:42:40.12

自然界こそオブジェクト指向だと思います

55

： 仕様書無しさん [] 2018/03/31(土) 16:20:17.18

class 鶴 extends 鳥類{}
class 亀 extends 爬虫類{}

new 鶴();
new 亀();

56

： 仕様書無しさん [sage] 2018/03/31(土) 16:23:18.96

だから足の本数だけでいいんだって
なんで継承…

57

： 仕様書無しさん [] 2018/03/31(土) 16:31:46.26

足の数はメンバ変数で定義されてるに決まってんじゃん。
なんで外から渡すんだよ。

58

： 仕様書無しさん [sage] 2018/03/31(土) 16:37:23.87

足の本数ごとに親をまとめてるのか…

59

： 仕様書無しさん [sage] 2018/03/31(土) 16:44:28.00

LegCountable というインターフェスだけでいい
Animalクラスもいらん

60

： 仕様書無しさん [] 2018/03/31(土) 16:44:38.04

4本足あったら、それは鳥類じゃねえよボケナス

61

： 仕様書無しさん [sage] 2018/03/31(土) 17:00:27.55

頭の数も欲しいと言われたらHeadCountable作るの？

62

： 仕様書無しさん [sage] 2018/03/31(土) 17:08:55.16

>>56

猫の手も借りたいところだな

63

： 仕様書無しさん [sage] 2018/03/31(土) 17:16:12.31

LegCountableもいらん
このつくりなら
足の数以外なんもいらんのだから整数でいいだろ！

64

： 仕様書無しさん [sage] 2018/03/31(土) 17:19:26.00

鶴亀算をオブジェクト指向で作る意味がないとは思うが、
オブジェクト指向のスレだからな

65

： 仕様書無しさん [sage] 2018/03/31(土) 17:20:05.19

と思ったけど要素と動物をふやして３元連立に拡張できるからあったほうがいいのか？

66

： 仕様書無しさん [sage] 2018/03/31(土) 17:59:40.91

このように考え過ぎるのがオブジェクト思考の特徴

とにかく無駄な拡張性だけ考えておくのです

67

： 仕様書無しさん [sage] 2018/03/31(土) 18:04:25.37

うん、やっぱりいらないな

業務的な切り口を考えたら鶴亀固定で計算を行うクラス
処理的な切り口を考えたら二元一次方程式クラスになる

動物クラスの出る幕がない

68

： 仕様書無しさん [] 2018/03/31(土) 18:38:22.52

そして神クラスへ

69

： 仕様書無しさん [sage] 2018/03/31(土) 18:52:44.69

今いるところは神クラスはないがサービスクラスという手続き型だけだわ

70

： 仕様書無しさん [sage] 2018/03/31(土) 19:05:10.25

足の数は属性なんでクラスじゃないな
インターフェースでもない

71

： 仕様書無しさん [sage] 2018/03/31(土) 19:11:54.45

足はhas Aで実装でしょ
例えば手や足って将来的に機械で拡張される場合もあるし
ほかにも羽が生えてくるかもしれない（工学的な意味で）
そんなわけで親子関係をもった部位クラスとして実装すべき

72

： 仕様書無しさん [] 2018/03/31(土) 19:22:06.32

お前の腕機能拡張して増やせるんだ。すげーや。

73

： 仕様書無しさん [sage] 2018/03/31(土) 20:14:55.74

だからいらんちゅーに
もともとあるならまだしも鶴亀算したいだけだろうがｗ

74

： 仕様書無しさん [sage] 2018/03/31(土) 20:21:53.30

>>32

OA進化論者か・・・

75

： 仕様書無しさん [sage] 2018/03/31(土) 20:54:12.34

>>72

義手とか有るから増やせると思うよ

76

： 仕様書無しさん [sage] 2018/03/31(土) 20:58:55.10

>>61

鶴亀算は足の数をもとに計算する仕様だから、頭の数も考慮するとなると前提条件の見直しになる。恐らくインターフェース名と前提条件の変更を余儀なくされるだろう
インターフェスーに抽象メソッドを追加し、クラスにもメソッドを追加しないといけない。しかしそれでも変更箇所は限定的で、コンパイルエラーによって実装漏れも教えてくれる。

しかし、そもそも頭が複数ある般的な生物なんているのか？

77

： 仕様書無しさん [sage] 2018/03/31(土) 22:11:19.03

唐傘小僧参戦決定!

78

： 仕様書無しさん [] 2018/03/31(土) 22:12:23.68

>>76

なんか

>>75

が増やせるっていうから義頭拡張されたらもう、どうしようもないぞ。

79

： 仕様書無しさん [sage] 2018/03/31(土) 22:15:10.00

ヤマタノオロチがこっちを見ている!

80

： 仕様書無しさん [sage] 2018/03/31(土) 22:25:52.42

キメラクラス

81

： 仕様書無しさん [sage] 2018/03/31(土) 22:38:26.54

>>78

実際頭が2つ有る人間だっているしね。

え？頭が2つある人を人間だって認めないっていうのかい？
まさかそんなことはないよねｗｗｗ

82

： 仕様書無しさん [sage] 2018/03/31(土) 22:40:33.48

自然界をオブジェクト指向で表現することができないのは
例外や突然変異があるから

だからといってオブジェクト指向は使えないのではなく
大半の要求を満たせるのだから問題ないのだ

100%の仕事なんか求められていないし不可能

83

： 仕様書無しさん [] 2018/03/31(土) 23:11:56.15

>>81

俺のシステムはその時点でException投げるから、
そっから先は例外処理。

84

： 仕様書無しさん [] 2018/03/31(土) 23:13:21.90

>>81

のシステム、クズ過ぎｗｗｗｗｗｗｗｗｗｗｗｗｗ

85

： 仕様書無しさん [sage] 2018/04/01(日) 00:12:58.66

class 生き物{
head;
leg;
}
class 鶴 extends 生き物{
head = 1;
leg = 2;
}
class 亀 extends 生き物{
head = 1;
leg = 4;
}
class ケルベロス extends 生き物{
head = 3;
leg = 4;
}
class 案山子 extends 生き物{
head = 1;
leg = 1;
}
class 鶴亀ソルバ{
void SetAnimal(生き物 animal);
Result Solve();
生き物[] m_Animal;
}

でもこれだと、あんまりポリモーフィズムのメリットが活かせてないな
生き物クラスにメソッドを持たせないと

86

： 仕様書無しさん [sage] 2018/04/01(日) 00:19:02.73

俺も理解するまで時間がかかったけど
RPGのゲームを考えると理解できた

例えば敵キャラのスライム10匹との戦闘をプログラミングで表現しようとした場合、
ライフやMPを配列で管理しようとすると大変だ
それよりも一つスライムというクラスを作りその中にライフやMPという変数をもたせたほうが、
何匹いようが個々のメソッドでライフやMPを減らすように作った方が楽になる

また、そのスライムというクラスを継承してメタルスライムやキングスライムといった派生クラスを作れば
それぞれのクラスをを1から作らなくても良い

87

： 仕様書無しさん [sage] 2018/04/01(日) 00:41:04.84

>>86

それ、スライムって構造体を作るのと何が違うの？
スライム10体なら、スライムって構造体の変数を10個作ればいいだけ
構造体ならクラスの概念のないC言語でも出来るよ

88

： 仕様書無しさん [sage] 2018/04/01(日) 00:42:54.88

オブジェクト指向ってのは設計が大事なんだよ
理解できてなくてもプログラムを書くことは出来るし要件を満たせるが
オブジェクト指向を理解することによって保守性とかプログラムの美しさに繋がる

89

： 仕様書無しさん [sage] 2018/04/01(日) 00:45:07.79

class スライム:ウンコ

90

： 仕様書無しさん [sage] 2018/04/01(日) 01:53:24.59

>>87

c言語でスライムは出来るだろうけど
メタルスライムとかキングスライムはどうする？

91

： 仕様書無しさん [sage] 2018/04/01(日) 02:42:16.23

>>88

プログラムなんて
車のシャーシどころか設計図みたいなもん
なんて美しい設計図なんだ！ってあほか

車が走らんとどうしょうもない

多少汚くたって困るのプログラマーだけじゃねえか
賃金やすいんだから工数倍になったってたかが知れてる

92

： 仕様書無しさん [sage] 2018/04/01(日) 02:53:57.04

保守性がよくなるってのもうそっぱち
状態がある分、クラスのメンテは関数のメンテよりはるかに大変
処理自体も基本わかりづらくなる。
いっぺんイテレーター作ってみやがれ

標準ライブラリのように完膚なきまでにテストされ、作りこまれて安定したクラスを
使うとき
だけ、保守性や生産性が向上するんだ…

93

： 仕様書無しさん [sage] 2018/04/01(日) 02:59:36.14

そもそも

>>88

の言ってることが漠然としすぎてて発狂する
なんやねん

94

： 仕様書無しさん [sage] 2018/04/01(日) 03:00:57.96

>>90

こんな感じじゃね？

class Charactor {
　int HP;
　int MP;
　render() { // 自キャラデザインを描画する }
　action() { // 自ターンでの行動 }
　damaged() { // ダメージを受けた時 }
}

class Slime extends Charactor {}
class SlimeBeth extends Slime { // デザインとステータスが違うだけで攻撃パターンなどは同じ }
class MetalSlime extends Charactor {}
class KingSlime extends Charactor {}


メタルスライムだからって必ずしもスライムを継承する必要はないしねｗ

キングスライムは、（キングスライム化可能な）スライムが
次ターンんで仲間を呼んで、8匹そろったら合体アニメーション表示
終わったらキングスライムに変化って感じだろうね
（内部的には新たなキングスライムを呼び出しして自分達はdeleteする）

95

： 仕様書無しさん [sage] 2018/04/01(日) 09:42:34.11

>>92

カプセル化、全否定かよ

96

： 仕様書無しさん [sage] 2018/04/01(日) 09:48:34.07

>>95

俺もいいことないと思うな
結局、中の状態を把握した上でないと使えないし
なんの説明もないくせにinitメソッド2回呼ぶとバグるし
initメソッド2回呼ぶとバグるのはソース見ないとわからんし
だったらC言語時代に戻ろうぜ

97

： 仕様書無しさん [sage] 2018/04/01(日) 10:53:24.38

データを変更するメソッドが、そのクラス内にしかないと分かっているの楽

98

： 仕様書無しさん [sage] 2018/04/01(日) 11:00:52.39

>>97

だから鶴亀算をどこに書くのかと

99

： 仕様書無しさん [] 2018/04/01(日) 11:02:50.87

観測する人間クラスの中に決まってんじゃん

100

： 仕様書無しさん [sage] 2018/04/01(日) 11:04:28.90

>>99

そうなると鶴クラスと亀クラスが存在しないと人間クラスは存在できないクソ設計

101

： 仕様書無しさん [] 2018/04/01(日) 11:19:29.37

なんでだよ ヴァカ

102

： 仕様書無しさん [sage] 2018/04/01(日) 11:20:49.02

>>101

人間クラスに鶴亀クラスが出てくるから
人間クラスだけ使う場合も
鶴亀クラスもってこないとエラー出るだろボケ

103

： 仕様書無しさん [sage] 2018/04/01(日) 11:25:54.85

>>91

綺麗な設計のプログラムは動かないという前提なら、そりゃ汚くても動く方がマシだけど、そうじゃないだろアホ

104

： 仕様書無しさん [sage] 2018/04/01(日) 11:27:36.67

鶴亀算コントローラで鶴亀算に必要なクラス呼べばいいだけだし

105

： 仕様書無しさん [sage] 2018/04/01(日) 11:28:07.57

trello

ttps://trello.com/

106

： 仕様書無しさん [sage] 2018/04/01(日) 11:35:30.27

オブジェクト思考は人間の都合のいい解釈で抽象化なされた現実離れしたもの。
しかし、人間の都合のいい解釈によって、使い方の提案を含めたオブジェクトが作成できることは
その利用者の思考コストを減らすから、それがメリットみたいなこと書いてあった。

ttps://qiita.com/tutinoco/items/7f7568cc7dbf7e2276c8

個人的にしっくりきたんだけど、どうなん？
もしオブジェクト指向がいらないものだったら
ここまで使われてる理由がわからんし、やはり利用者のためのオブジェクト指向なのかなと。

実際使う時便利だし。モジュールのためのオブジェクト指向って感じなのかなぁ

107

： 仕様書無しさん [sage] 2018/04/01(日) 11:38:17.87

今のsiは似たような部品とかを一から作って水増し工数をしてるんだな
だからオブジェクト指向は使われてない効率よくしようとはされてない
そもそも寄せ集めだからプログラマーのレベルもバラバラ

108

： 仕様書無しさん [sage] 2018/04/01(日) 11:44:16.63

下級プログラマはオブジェクト指向のことは考えなくていい
そういうのは上級プログラマが考えるから、下級プログラマは提供されたフレームワークなりライブラリなりの
使い方だけ知っていればいい

109

： 仕様書無しさん [sage] 2018/04/01(日) 11:58:05.21

>>106

じゃ、メリットは？
〜な気がするとかおままごとは他所でやれよ

110

： 仕様書無しさん [sage] 2018/04/01(日) 14:26:36.47

標準apiとかフレームワークこそがオブジェクト指向の良い教材
誰でも簡単に使えるやん

111

： 仕様書無しさん [sage] 2018/04/01(日) 14:33:16.18

>>110

周知されてるからでしょ？
お前が作るオナニークラスライブラリはノーサンキュー

112

： 仕様書無しさん [sage] 2018/04/01(日) 15:12:47.23

オブジェクト指向＝再利用の認識の人ってまだいるんだ

113

： 仕様書無しさん [sage] 2018/04/01(日) 15:36:20.72

>>112

地球が真っ二つになったエピソードで見るのやめた

114

： 仕様書無しさん [sage] 2018/04/01(日) 18:48:36.51

人間クラスとか現実世界を再現しようとするなよ

115

： 仕様書無しさん [sage] 2018/04/01(日) 19:49:08.77

>>87

ステータスの管理だけならば構造体でも良いけど、
実際には

>>94

のような攻撃や防御といった自分の動作まで記述するから
メインルーチンからはさらに手間がかからなくなる
スライムの攻撃や防御のロジックを別で書くと管理が面倒になる

ちなみにオブジェクト志向はデスクトップのアプリなど、
ユーザーが終了するまで常駐し続けるプログラムには有効だけど、
SI系のバッチプログラムなど一連の処理が順番に流れる手続き型にはあまり向いていない
という、そんな凝ったことをして意味がない

116

： 仕様書無しさん [sage] 2018/04/01(日) 19:56:19.28

バカの話は相変わらず長いな

117

： 仕様書無しさん [sage] 2018/04/01(日) 21:29:46.71

例え話の正しい使い方

○ A. 相手に説明する時に相手がすでに知ってる知識を利用してわかりやすく伝えるために使う
× B. 何かを馬鹿にしたい時に、悪いものと認識されているものに例えることで印象操作を行う
　（カレーはウンコと似ている所があるとウンコに例えることでカレーを臭い排泄物だと思わせること）


例え話に対する反論方法

A. に対して例えが正確じゃないということ。もともと知らない人に対して
わかりやすく伝えることが目的であり、正確な例えをしているわけじゃない。

例えなのだから正確ではないのは当たり前で、それを承知の上で
相手への説明のために例えを使ってる人に対して
その例えは正確じゃないと反論するのは只のマヌケ

B. に対しては、その例えは正確じゃないと反論するのが正しい。
なぜなら印象操作は例えが正しいことを前提として意味があるので
その例えが間違いであると言うことは、反論として成り立つ
（カレーとウンコは違うので、いくらウンコが臭い排泄物だと言った所でカレーには関係ない話）
例えなのだから正確ではないのは当たり前でそこを指摘すると言い返せない
（カレーはウンコではないのは常識）

118

： 仕様書無しさん [sage] 2018/04/01(日) 21:41:14.57

バカの話は相変わらず長いな

119

： 仕様書無しさん [sage] 2018/04/01(日) 22:49:51.85

その程度の中長文で理解できない人間はプログラミングに向いてないよな
拒絶反応から否定の逃げ台詞を吐いて逃亡するしかない

120

： 仕様書無しさん [sage] 2018/04/01(日) 22:52:09.26

>>119

自己紹介乙

121

： KAC [sage] 2018/04/01(日) 23:08:32.06

なにやら変な話題で盛り上がってんのな

オブジェクト指向なんてのは、考え方の一つなんだから、
オブジェクト指向言語じゃなきゃ実現できないアプリなんて無い。

「オブジェクト指向じゃなくてもできる」
という指摘はオブジェクト指向を否定するものじゃ無い。

122

： 仕様書無しさん [sage] 2018/04/02(月) 10:10:08.67

お前じゃなきゃ実現できない仕事なんて無い。

「お前じゃなくてもできる」
という指摘はお前を否定するものじゃ無い。

123

： 仕様書無しさん [sage] 2018/04/02(月) 12:11:56.92

>>109

だからメリットは「使い方の提案を含めたオブジェクトは指向コストを減らす」じゃないの？

124

： 仕様書無しさん [sage] 2018/04/02(月) 12:39:42.79

>>123

なんかそういう資料あるの？

125

： 仕様書無しさん [sage] 2018/04/02(月) 12:59:33.19

>>124

うん。

その資料曰く根本的にデータは使い方には制限はないが、制限は明確さを与えるので利便性が生まれるとか書いてあったような..

冷蔵庫を収納に使う話とかわかりやすかった。

126

： 仕様書無しさん [sage] 2018/04/02(月) 16:14:28.23

人間の認識に近いんよ

OOP指向言語なら逆引きができる。

127

： 仕様書無しさん [sage] 2018/04/02(月) 17:45:05.58

>>125

ソースは？

128

： KAC [sage] 2018/04/02(月) 18:13:59.61

>>122

そんなもので否定されたら
世の中の大半の人は存在意義無くなるよな

129

： 仕様書無しさん [sage] 2018/04/02(月) 20:33:04.06

自分以外にできるやつがいなくなるまで
コミュニティを小さくすればいいんだ！

130

： 仕様書無しさん [sage] 2018/04/03(火) 11:20:33.32

>>127

いまスマホ。
リンク貼るのめんどいから辿ってちょ

131

： 仕様書無しさん [sage] 2018/04/03(火) 20:02:23.79

>>130

そんな事実はない

132

： 仕様書無しさん [sage] 2018/04/03(火) 23:20:42.41

>>106

> オブジェクト思考は人間の都合のいい解釈で抽象化なされた現実離れしたもの。

その「現実」っていうのがずれてるんだろうねｗ

システム開発してる人にとってはシステム開発で必要なものも「現実」
だけど、人間の都合に良いように〜とか言ってる奴の「現実」って
現実世界のシミュレーション限定だろｗ

133

： 仕様書無しさん [sage] 2018/04/03(火) 23:22:07.73

オブジェクト思考は人間の都合のいい解釈で抽象化なされたもので
シミュレーションとして生物などを正確に表現することには適してない

と言いたいんだろうなｗ

134

： 仕様書無しさん [sage] 2018/04/03(火) 23:28:37.78

やりたいことを抽象化したデザインパターンを
常識として受け入れましょうってのがオブジェクト指向だろ

135

： 仕様書無しさん [sage] 2018/04/03(火) 23:43:06.63

違う。人間が大雑把に考えてる考え方はオブジェクト指向に近いので、
コンピュータ寄りではなくより人間的な考え方をしましょう
っていうのがオブジェクト指向
オブジェクト指向は人間の考え方を表現できるように進化してきた

136

： 仕様書無しさん [sage] 2018/04/03(火) 23:47:11.47

ソースコードが長くなると、複数の関数に分けたくなる
↓
関数をバラバラにわけていると、どうしても引数の数が多くなる
↓
関数によって共通する引数があるので、それを構造体にまとめて引数の数を減らす
↓
どうせなら構造体の中に関数を入れてしまえばいいじゃない
↓
構造体の中の値を気にしないように実装したら、なんかソースコードが読みやすくなった気がする
↓
これに名前を付けたのが、カプセル化

137

： 仕様書無しさん [sage] 2018/04/04(水) 04:46:26.02

グローバル変数は便利だが管理が面倒だからクラスに入れてその変数に対する処理をクラス関数にする程度にしか思ってない

138

： 仕様書無しさん [sage] 2018/04/04(水) 08:20:43.18

public変数の機能を禁止する法案を提出したい
マイクロソフトやオラクルがpublic変数禁止法で訴訟されるような世の中を作りたい

ひさびさにひっかかった・・・orz

139

： 仕様書無しさん [sage] 2018/04/04(水) 08:56:46.85

>>137

そりゃまともなコードが書けないわけだわ

140

： 仕様書無しさん [sage] 2018/04/04(水) 12:47:34.68

モノつくる時みたいに役割分担を明確にして設計しましょう
カプセル化とか継承とかはそのための手段

程度の認識だわ

141

： 仕様書無しさん [sage] 2018/04/04(水) 21:10:53.00

指向だからええんじゃね

グローバル変数禁止で

142

： 仕様書無しさん [sage] 2018/04/05(木) 00:28:53.41

ALLシングルトン

143

： 仕様書無しさん [sage] 2018/04/05(木) 07:01:04.00

ALLシングルトンというか手続き型なクラスだらけで
staticと変わらない

144

： 仕様書無しさん [sage] 2018/04/06(金) 01:03:31.62

デザパタを批判するときは唯一わかるシングルトンを
持ち出すことしかできない

145

： 仕様書無しさん [sage] 2018/04/06(金) 07:34:51.82

>>144

俺はデザパタは嫌いだがシングルトンは大好きなんだ

146

： 仕様書無しさん [sage] 2018/04/06(金) 11:39:18.39

ウイングルトンとシングル、どっちもテニス用語なので
シングルトンもテニス関係の言葉だと思っていました。

147

： 仕様書無しさん [sage] 2018/04/06(金) 19:47:11.73

俺もお前もシングルトン

148

： 仕様書無しさん [sage] 2018/04/06(金) 19:49:43.96

そしていつでも疎結合

149

： 仕様書無しさん [sage] 2018/04/07(土) 04:32:57.07

ガバガバなんですね

150

： 仕様書無しさん [sage] 2018/04/08(日) 16:13:10.05

OOPの本質は疎結合

まったく結合を無くしたいんだが良い方法は無いか

151

： 仕様書無しさん [sage] 2018/04/08(日) 16:39:24.28

動的オブジェクト言語を使えばいいのでは

152

： 仕様書無しさん [sage] 2018/04/08(日) 16:47:56.67

>>150

シングルトンアルヨ

153

： 仕様書無しさん [sage] 2018/04/08(日) 19:43:48.98

DIが思い付くが型を特定しなくともインターフェースが固定されるから駄目だな

じゃあ呼び出しコードも含めて依存性を注入すりゃあ？って事になる

154

： 仕様書無しさん [sage] 2018/04/08(日) 19:48:29.64

>>153

え？ どんなインターフェースでも使える
メソッドなんてあるの？

コンテナクラスならobjectの中身はとわないんで、
objectであれば十分だから作れるけど
渡すオブジェクトのメソッドを呼ぶなら
そのメソッドがあるインターフェースを持ってないとだめでしょ

155

： 仕様書無しさん [sage] 2018/04/08(日) 19:58:03.19

まさにそれさ！インターフェースに依存してるって事は依存性はゼロじゃないって事さ

それでは丸ごとすげ替えるって事は出来ない
更に依存を注入するための機構にも依存してしまう

156

： 仕様書無しさん [sage] 2018/04/08(日) 20:02:41.75

>>155

意味が分からん。
実装に依存すると問題が多いから
インタフェースに依存することが
いい方法ですって話なのに、

インタフェースに依存してるじゃんって言われても
だからその素晴らしい方法を目指してるんだがとしか
言えないんだが？

157

： 仕様書無しさん [sage] 2018/04/08(日) 20:16:23.28

あと丸ごとすげ替えしたいって言うけど、目的ないでしょ？ｗ

例えば、ボタンオブジェクトを要求されてる場面で
セレクトボックスオブジェクトを渡した所で
正しく動くことはない

すげ替えたくなる対象は互換性がある型
その互換性っていうのがインターフェースそのもの

158

： 仕様書無しさん [sage] 2018/04/08(日) 20:18:32.13

例えば「このオブジェクトはfooメソッドを持っていること」
というのもインターフェースだからね

明示的に書かない言語も有るけど、コードはfooメソッドを持っていること
というのはfooメソッドを使うからであって
明示的に書いてないだけでインターフェースは存在する

159

： 仕様書無しさん [sage] 2018/04/08(日) 20:23:58.93

そうだね、明示的になくてもインターフェースは存在するね

しかも実行時に実装が無ければ余計にタチが悪い

ではそもそも結合度をゼロにするなんて事は出来ないんじゃないか？

160

： 仕様書無しさん [sage] 2018/04/08(日) 20:31:42.75

ゼロにできないから何？
エアバッグ付けても交通事故はゼロにならないよな

で、ゼロにできないから何だって言いたいの？

161

： 仕様書無しさん [sage] 2018/04/08(日) 20:32:45.75

> しかも実行時に実装が無ければ余計にタチが悪い

それはタチが悪いんじゃなくて動きませんが？
動かすために実装作るんでしょ

なにが言いたいんですか？

162

： 仕様書無しさん [sage] 2018/04/08(日) 21:12:12.47

AとBの結合度がゼロってことは、AとBは無関係ってのと同じこと
結合度は低い方が良いと言ったって、ゼロにしろってことじゃないわな

163

： 仕様書無しさん [sage] 2018/04/08(日) 21:57:23.36

>>160

でもマシにもなってないんじゃない？
結局、こない未来を想像した時点で失敗なのよ

164

： 仕様書無しさん [sage] 2018/04/08(日) 22:09:09.99

そもそも結合度を気にしたい箇所ってお金がかかるとことお金がかからないところを明確にしないと正当性が主張できないよね
全部入れ替えたって大して金のかからない箇所を一生懸命疎結合とか言ってる奴は本当にアホにしか見えないじゃん

サーバー側をいじらずにクライアント側だけ新しくするってのも
俺には難しく見えるがな
っていうか経験上一見関係ないように見えるけど
データって見せるためのまとまりであるから実際は難しいんだよね

アプリ単位でこんなこと気にしてるなんて本当は無意味なんじゃねーの？
って思う

165

： 仕様書無しさん [sage] 2018/04/09(月) 01:49:44.62

>>163

マシになってるが？

なんでお前勝手に結論づけてるんだ
知らないならまず聞け、話もせずに結論を言うな

166

： 仕様書無しさん [sage] 2018/04/09(月) 02:21:02.04

インターフェイスのクラスを継承する場合はやっぱり結合度高いとおもうんだよな。

個人的に疎結合といえばC++のテンプレートだと思う

167

： 仕様書無しさん [sage] 2018/04/09(月) 06:00:19.44

>>166

なるほど。C++のテンプレートに疎結合を
意識して考えたことなかったから感心した。

168

： 仕様書無しさん [sage] 2018/04/09(月) 06:14:09.96

まさか
呼び出し関係を結合
って思ってる人居ないよね

基礎からやり直したら？

169

： 仕様書無しさん [sage] 2018/04/09(月) 07:23:37.69

コピペするとき一緒にコピペする必要があったら結合

170

： 仕様書無しさん [sage] 2018/04/09(月) 07:34:02.61

ユニットテストのしやすさが尺度じゃ？

171

： 仕様書無しさん [sage] 2018/04/09(月) 08:06:57.70

C++テンプレートなら特定のクラスに依存しない事も可能だぞ。
vectorやlistなんか管理方法を抽象化してる。

他にも走る事を仕様にすれば
template<typename T>
void obj_run(T obj){
obj.run();
}

これならオブジェクトはrun()という関数さえ持ってればいい。

※オブジェクト思考についてよく知らないのは認める

172

： 仕様書無しさん [sage] 2018/04/09(月) 08:11:52.00

>>169

俺もその認識
結局エラー出ちゃうんじゃ
修正するのと変わんないじゃん

173

： 仕様書無しさん [sage] 2018/04/09(月) 21:24:10.59

C++のテンプレートは的外れだなｗ
あれは極端な言い方をすればクラス定義を作るものなんだから
単体のクラスを作る範囲なら、他のクラスと依存しないという
当たり前のことを言ってるだけだよ

テンプレートで作ったクラスを実際に使う段階で
どちらにしろ依存してしまう

>>171

がその例だね
他のクラスから呼び出すために、オブジェクトはrun()という
関数（インターフェース）が必要という事になってしまった。

174

： 仕様書無しさん [sage] 2018/04/09(月) 22:05:50.79

インターフェイスに依存するのは悪くないのでは？

175

： 仕様書無しさん [sage] 2018/04/09(月) 22:22:45.97

静的言語のインターフェースは実体がありよるからな
どうがんばっても一方が一方を知ってないといけない

依存が拡大しがちだし
モジュールのすげ替えがやりにくい
きがする

176

： 仕様書無しさん [sage] 2018/04/09(月) 22:27:27.23

インタフェースをありがたがるのは周回遅れって感じ

177

： 仕様書無しさん [] 2018/04/09(月) 22:29:02.46

今どきなら？

178

： 仕様書無しさん [sage] 2018/04/09(月) 22:47:17.50

>>168

浅学ですまないのだが少し教えてもらえないだろうか？
モジュールXのクラスAのメソッドが、モジュールYのクラスBのメソッドを呼び出すなら、それは結合してるって言えるんじゃないの？
それとも、その呼び出し関係ってのはもっと別の話？

179

： 仕様書無しさん [sage] 2018/04/10(火) 00:55:45.03

>>178

モジュールXのインターフェースZを作成し
モジュールYのメソッドでZを使い
モジュールXの外でモジュールYをnewして
モジュールXのコンストラクタなどで
モジュールYを渡してれば（依存性注入）
モジュールYはインターフェースZに依存するので疎結合。

モジュールBの中でnewしたら完全に依存するってことだと思ってる。

180

： 仕様書無しさん [sage] 2018/04/10(火) 01:05:58.00

>>179

え？何が良くなったの？

181

： 仕様書無しさん [sage] 2018/04/10(火) 01:10:21.61

>>178

わかりにくかったのでもっかい書く

ポイントは「インターフェースに対してプログラミングすること」が疎結合の前提であり、「どこでnewするか」の判断を誤ると一気に取り返しのつかない結合が起こるということ。

つまり、クラスBをクラスAの外でnewして依存性注入（コンストラクタなどでnewしたクラスBを渡す）してれば疎結合性は保たれるが

クラスBのメソッドでインターフェースのワンクッションを挟まずに直接プログラムしたり、クラスBのコンストラクタなどでクラスAを直接newしたりすると疎結合性が一気に崩壊する。

そして結合疎結合の本質は

>>169

が良いこと言ってて、コピペした時に芋ずる式に他モジュールが付いてくるか否かで測れる。

C++のテンプレートの疎結合性は的外れ的なコメントがあったけど、個人的にはコピペの原則に当てはめると立派な疎結合してるように感じた。

182

： 仕様書無しさん [sage] 2018/04/10(火) 01:14:07.38

疎結合合戦をしたいわけじゃなくて
関連があるなら結合があるべきだし
関連がないならあるべきでないしって話であるべきだよね？

ネジでくっつけるところをマグネットで付けて喜んでるアホに見える

183

： 仕様書無しさん [sage] 2018/04/10(火) 01:18:55.41

>>182

ワロタww
その通りだよ

だからネジでいいところはネジで作らなければ、それはオーバーインプリメンツだおw

ハローワールドを画面に出力するのに、いろんなモジュール作ったりして遠回しに実現することは、イケてない。

184

： 仕様書無しさん [sage] 2018/04/10(火) 01:53:40.12

>>179

XYZの使い方が下手で読みにくい
そういうところのセンスだよ、オブジェクト指向に大切なのって

185

： 仕様書無しさん [sage] 2018/04/10(火) 02:03:59.52

なんとなく思った事を、一言だけ言わせてくれ

マ板じゃなくて厶板でやれ

186

： 仕様書無しさん [sage] 2018/04/10(火) 06:53:32.48

ここでいいよ

187

： 仕様書無しさん [sage] 2018/04/10(火) 09:06:36.39

>>184

だから書き直したんじゃん
。・゜・(ノД`)・゜・。

188

： 仕様書無しさん [sage] 2018/04/10(火) 09:10:01.78

C++のテンプレートみたいにインターフェース以外で
疎結合を実現する方法って他に何があるの？

189

： 仕様書無しさん [] 2018/04/10(火) 10:45:43.04

自然言語処理の知識はゼロなのでわからないです。面白いアイデアだと思うので、Twitterの自然言語処理が専門の方々に聞いてみては？
ttps://peing.net/ja/q/417c9e29-35de-4c95-8323-afd6a50fcbc7

コンピューターのための自然言語理解シミュレ
ーターというのは可能ですか？

例えば第二次大戦の推移について、言葉ではな
くて動画で理解する方法もあります。
言葉で説明するよりもマインクラフトのような
創作ゲーム表現に変えたほうが分かりやすいで
す。
けれども自分が読み漁った人工知能や自然言語
処理の本にはそうしたアプローチは見つからな
かったです。
言語はただの記号の羅列で機械は現実世界を全
く知らない。でもそういうことなら、
テレビゲームのような仮想世界をインプットし
て、自然言語で操作したらいいと思います。
というか自然言語入力でときめきメモリアルみ
たいなゲームをやってみたいてす。

190

： 仕様書無しさん [sage] 2018/04/10(火) 14:06:04.12

>>188

pythonの関数はどうだろう？

191

： 仕様書無しさん [sage] 2018/04/10(火) 14:59:07.58

>>190

詳しく

192

： 仕様書無しさん [] 2018/04/10(火) 23:28:17.29

>>191

pythonの関数の引数は型を明記しない（一応type hintはあるが・・・）
その為C++のtemplate関数みたいな使い方にできる。


ただ

>>182-183

のいう事もごもっともだとおもいます。

193

： 仕様書無しさん [sage] 2018/04/11(水) 00:21:14.21

>>192

なるほど

ダックタイピングって言うんだっけ？pythonやJavaScriptみたいな言語は型に縛られないからC++のようなテンプレートを必要としないってことか。

うーんと、C++のテンプレートがただ型の異なるコードに対応できるものと考えると、C++のテンプレートって疎結合関係ないような気がしてきた。型専用のマクロみたいなものか

194

： 仕様書無しさん [sage] 2018/04/11(水) 00:51:38.94

クラスに依存しないで仕様に依存するのが疎結合じゃないの？

195

： 仕様書無しさん [sage] 2018/04/11(水) 04:53:13.04

>>194

仕様に依存ってどういうこと？

196

： 仕様書無しさん [sage] 2018/04/11(水) 22:43:47.41

>>193

> ダックタイピングって言うんだっけ？pythonやJavaScriptみたいな言語は型に縛られないからC++のようなテンプレートを必要としないってことか。

関数の引数は型に縛られないが、
関数の中身は型に縛られるんだよね


foo(obj) {　　　　← 確かに型に縛られないよ
　obj.hello();　　　← でも結局ここでhelloメソッドがあること縛られてる。
}

んで、コードが長くなったら見通しが悪くなって、
objって一体何のメソッドを必要とするんだ？ってなる。

そこでコメントとしてて書くのさ

// objはhelloメソッドを持っていること　　← 結局これがインターフェース
foo(obj) {
　obj.hello();
}

197

： 仕様書無しさん [sage] 2018/04/12(木) 01:08:59.73

>>196

そういう初心者プログラマ向けの注釈が必要ってことは想定せずに会話したいね

198

： 仕様書無しさん [sage] 2018/04/12(木) 07:07:30.91

疎結合の話が途中に出てくる
ttps://qiita.com/carotene555/items/942bef4c7b1529cff572

199

： 仕様書無しさん [] 2018/04/14(土) 11:50:31.79

デザインパターンをインターフェースから説明した良心的なブログ
途中で息切れしてるみたい？？

ttps://blogs.yahoo.co.jp/kamyu_2010/35417803.html

200

： 仕様書無しさん [sage] 2018/04/14(土) 11:51:40.87

コピペしなくて良いよ

201

： 仕様書無しさん [sage] 2018/04/14(土) 11:51:47.87

ウンコの子

202

： 仕様書無しさん [sage] 2018/04/14(土) 12:05:02.07

設計にこだわりすぎるとダメよね

203

： 仕様書無しさん [sage] 2018/04/14(土) 12:28:36.90

>>202

そりゃお前程度が設計にこだわったところで大したもんは出てこないし、そもそもしっかり設計されてないと構築できないほどの難度のものには縁がないだろうし

204

： 仕様書無しさん [sage] 2018/04/14(土) 13:51:43.02

設計して実装して
実装が増えてくると設計がダメって気が付いて
コンバータ作って設計やり直して、
の繰り返し

いきなり完璧な設計できる人尊敬するわ

205

： 仕様書無しさん [sage] 2018/04/14(土) 13:55:39.43

>>204

そこで、設計のやり直しじゃなくて
リファクタリング "技術" を使って変化させるんやで？


リファクタリングはクソコードを直すものじゃなくて
設計を安全に変化させる技術だ

206

： 仕様書無しさん [sage] 2018/04/14(土) 14:39:11.91

>>205

全く意味わからん
改修作業ってことで見積り出していいですよね？

207

： 仕様書無しさん [sage] 2018/04/14(土) 14:59:44.24

>>206

当たり前だろ？

例えば家をリフォームすると言っても
既存の部分に手を入れずにリファームなんてできない
そこまで見積もりに含める

2階建ての家を3階に改築する時に、3階部分を
追加するだけの費用を見積もるやつはいない。
3階に改築できるかどうか調べて場合によっては基礎工事からやり直し

追加部分だけ請求すればいいわけじゃないんだよ？
もしそんな事してれば、それは馬鹿かマヌケのどちらかだ

208

： 仕様書無しさん [sage] 2018/04/14(土) 15:05:03.69

そうなるとリファクタリングって言葉が何で存在するのかわからん
ただの改修作業じゃん

209

： 仕様書無しさん [sage] 2018/04/14(土) 15:14:49.00

>>208

改修作業に用いるテクニックのことだけど？

リファクタリングは、新しい完成図に持っていくときに使うテクニック。
リファクタリングと仕様変更を交互に繰り返しながら修正を行う

リファクタリングを行うと仕様変更が楽になる（そのために行う）から
不具合率も低下するし、テスト済みの既存のコードを活かせる

リファクタリングを行わないで仕様変更しようとすると
構造的に無理な所が出てくるのですぐに破綻する

210

： 仕様書無しさん [sage] 2018/04/14(土) 15:19:27.46

リフォームするときに既存の部分に手を入れるのは
当たり前の話なんで「既存の部分修正代」して
別に見積もりを出すことはないだろう

リファクタリングも同じ。既存の部分を修正するのは
当たり前の話なんだから、わざわざ分離して見積もりを
する必要はない。改修作業の中に自動的に組み込まれるもの

それを組み込まないで、追加部分だけで考えるから
デスマになる

211

： 仕様書無しさん [sage] 2018/04/14(土) 15:23:41.83

>>209

え？何言ってるのかさっぱりわからない
改修作業の何のための工程なの？
やってもやらなくても実現できる要件は同じなんでしょ？
余計な工数使わないで

212

： 仕様書無しさん [sage] 2018/04/14(土) 15:26:14.72

>>211

改修作業の中の工程の一つだけど？
もしかして無計画に改修してる？

213

： 仕様書無しさん [sage] 2018/04/14(土) 15:26:41.54

> やってもやらなくても実現できる要件は同じなんでしょ？

リファクタリングすることで要件を楽に実現できる
全体の時間も短くなる

214

： 仕様書無しさん [sage] 2018/04/14(土) 15:27:27.13

>>212

普通に要件定義→設計→実装→テストだよ

215

： 仕様書無しさん [sage] 2018/04/14(土) 15:27:57.46

リファクタリングはどの工程で何をするの？

216

： 仕様書無しさん [sage] 2018/04/14(土) 15:29:15.38

オブジェクトとはすなわち物質、本来形のないバーチャルなものまで、例えば仮想通貨やゲーム内で使われるコインなどの加熱した取引を戒める言葉

217

： 仕様書無しさん [sage] 2018/04/14(土) 15:29:30.04

リファクタリングとは、ソフトウェアの外部的振る舞いを保ちつつ、理解や修正が簡単になるように、内部構造を改善することです。
改修作業のことではありません

218

： 仕様書無しさん [sage] 2018/04/14(土) 15:30:11.12

>>215

詳細設計は？

リファクタリングは詳細設計を行った後に
その詳細設計に向けて、既存のコードを
不具合なく修正していく作業

219

： 仕様書無しさん [sage] 2018/04/14(土) 15:30:32.02

納品段階で要件定義書をこっそり修正する

Re-Fact
代替的事実、事実の再構成

それこそがリファクタ

220

： 仕様書無しさん [sage] 2018/04/14(土) 15:30:44.61

>>217

改修作業に含まれる工程の一つだよ

だから改修作業のことだなんて一言も言っていない

221

： 仕様書無しさん [sage] 2018/04/14(土) 15:32:43.01

>>217

じゃあ、基本設計ミスってるときにやる修正みたいなもんなんだ？

222

： 仕様書無しさん [sage] 2018/04/14(土) 15:32:55.86

もちろん新規作成でもリファクタリングは行う。
最初から無駄のないコードを書ける人なんていない

リファクタリングを行って（最後にやるという意味ではない）
それでコードは完成する。だからコードを書くときには
必然的にリファクタリングが含まれてる

223

： 仕様書無しさん [sage] 2018/04/14(土) 15:33:22.83

>>221

改修じゃないって言ってるのに、修正なんだって
お前日本語わかってないのか？

224

： 仕様書無しさん [sage] 2018/04/14(土) 15:34:58.27

改修を仕様どおりに作らなかったっっものを
直すことだと思ってるんだろｗ

225

： 仕様書無しさん [sage] 2018/04/14(土) 15:36:32.78

リファクタリングとかいいから仕事しろよ

226

： 仕様書無しさん [sage] 2018/04/14(土) 15:38:52.19

ほらみてみｗ
またリファクタリングが仕事の一部だと理解してないやつが来たｗ
釣れる釣れる釣りまくれーｗ

227

： 仕様書無しさん [] 2018/04/14(土) 15:40:34.31

デザインパターンをインターフェースから説明した良心的なブログ
途中で息切れしてるみたい？？

ttps://blogs.yahoo.co.jp/kamyu_2010/35417803.html

228

： 仕様書無しさん [sage] 2018/04/14(土) 15:41:24.44

>>226

具体的なメリットが一切わからない

229

： 仕様書無しさん [sage] 2018/04/14(土) 15:44:06.74

>>228

開発コストが下がる。バグが減る。
これがメリットだってわからないってこと？

230

： 仕様書無しさん [sage] 2018/04/14(土) 15:45:06.32

>>229

どういう理屈で下がるの？

231

： 仕様書無しさん [sage] 2018/04/14(土) 15:48:07.00

>>230

簡単に言えば、1000行のコード見てバグを探すのと
100行のコード見てバグを探すの
どちらが時間少なくて済むかって話。

また10000行のコードは、1000行の10倍の時間で足りると思う？
そう全然足りない。増えた行数以上に時間がかかる

同じことを実現するのでも少なくてわかりやすいほうが
コードをレビューする時間は減るし、
バグを入れ込むすきも減る。テストの時間も減る

232

： 仕様書無しさん [sage] 2018/04/14(土) 15:48:53.66

>>231

はぁ？

233

： 仕様書無しさん [sage] 2018/04/14(土) 15:50:45.35

反論ないならレスいらないよｗ

234

： 仕様書無しさん [sage] 2018/04/14(土) 15:51:50.24

虚構だよな

235

： 仕様書無しさん [sage] 2018/04/14(土) 15:52:19.62

一人で作っていて書いたコード全部覚えてますってなら
1万行のコードでも良いかもしれないが、
仕事だと、コードのレビューがあって自分以外の人が読むし
バグった時の修正だって、自分以外の人がやるかもしれない

その時に理解しやすいコードとそうでないコードでは
数倍の差がでる。コスト意識を持っていれば
リファクタリングしてようやく完成っていうのがわかるはず

236

： 仕様書無しさん [sage] 2018/04/14(土) 15:53:31.77

リファクタリングして完成だし、
仕様が変わって設計も変わったら、
新しい設計にそってコードを変更する必要がある
設計無視した（つまり旧設計の）コードのままではだめ

237

： 仕様書無しさん [sage] 2018/04/14(土) 16:16:51.53

先輩がリファクタリングしたコード、僕には読みにくかったんで、僕にとって読みやすいようにリファクタリングしときました

238

： 仕様書無しさん [sage] 2018/04/14(土) 16:19:49.37

>>237

お前がリファクタリングしたコードも読みにくいから俺がリファクタリングしといてやったぞ

239

： 仕様書無しさん [sage] 2018/04/14(土) 16:20:04.90

大体リファクタってそんなのばかりだなあ

240

： 仕様書無しさん [sage] 2018/04/14(土) 16:23:12.67

>>238

お前らのコードはリファクタリングすべきだとコンサルに言われたから、外部の業者に入ってもらってリファクタリングするわ、

241

： 仕様書無しさん [sage] 2018/04/14(土) 16:24:14.61

>>240

現場がわかってないコンサルのコードでは業務に支障をきたすので現場に則したコードにリファクタリングします

242

： 仕様書無しさん [sage] 2018/04/14(土) 16:47:26.25

>>239

犬がおしっこしていくのと似てるよね？

243

： 仕様書無しさん [sage] 2018/04/14(土) 16:49:41.20

>>238

アイツ気に入らなかったんでアイツのPCで動かないようにリファクタリングしておきました

244

： 仕様書無しさん [sage] 2018/04/14(土) 17:23:54.47

リファックタリング

245

： 仕様書無しさん [sage] 2018/04/14(土) 19:03:13.39

コミットのコメントがリファクタリングだらけで

246

： 仕様書無しさん [sage] 2018/04/14(土) 19:05:16.63

だから間違った使い方すんなって
"あるべき設計・コード" を考えることがリファクタリングなんじゃなくて
"あるべき設計・コード" に移行していくやり方がリファクタリング

お前らが言ってる読みにくかったんで〜は
リファクタリングじゃなくて、
あるべきコードの話になってるだろ

247

： 仕様書無しさん [sage] 2018/04/14(土) 20:16:26.49

>>246

僕が思うあるべき設計はそうじゃないのでリファクタリングしときますね^^

248

： 仕様書無しさん [sage] 2018/04/14(土) 20:29:14.15

>>247

そこでわざわざリファクタリングっていう必要なくね？

僕が思うあるべき設計の問題でしょう？

249

： 219 [sage] 2018/04/14(土) 20:45:00.22

まじめにいってるのに
おそらく本当にそうだったんだ
政治的レッテルに使われるのを嫌がって単語がしょうもないＩＴ用語として上書きされたんだ

もっと適切な言葉もあったろうに
胡散臭い呼び方がされてるのは
きっと本当にそのせいなんだ

250

： 仕様書無しさん [sage] 2018/04/14(土) 20:54:25.34

あの客ムカツクんで動かなくなるようにリファクタリングしておきました

251

： 仕様書無しさん [sage] 2018/04/14(土) 20:55:47.13

>>249

真面目に言ってないじゃん。
どこに「納品段階で」とか「こっそり」とか書いてあんのさ？

252

： 仕様書無しさん [sage] 2018/04/14(土) 20:57:46.26

>>251

そんなのスケジュールにねーし

253

： 仕様書無しさん [sage] 2018/04/14(土) 20:57:52.54

本来の意味の話

254

： 仕様書無しさん [sage] 2018/04/14(土) 20:59:03.32

>>252

それはお前の問題では？

255

： 仕様書無しさん [sage] 2018/04/14(土) 21:00:23.65

>>254

どうやってお客に説明するん？

256

： 仕様書無しさん [sage] 2018/04/14(土) 21:29:35.83

>>255

客との話なんだから完全にお前の問題だね

257

： 仕様書無しさん [sage] 2018/04/14(土) 21:46:59.35

リファクタリングやるのでお金ちょーだいって？
通らないし必要があるとも思えない

258

： 仕様書無しさん [sage] 2018/04/14(土) 21:48:50.97

だいたい本当に効果あるなら
素直な改修より費用下がるはずだしな

259

： 仕様書無しさん [sage] 2018/04/14(土) 21:57:51.90

>>257

仕事だろ？なんで必要な仕事で金もらえないんだ？

それはお前が重要性を分かってないだけじゃねーか
客のせいにするな。お前の問題だ


> だいたい本当に効果あるなら
> 素直な改修より費用下がるはずだしな
ただで良いものが作れると思ってんの？

260

： 仕様書無しさん [sage] 2018/04/14(土) 22:00:02.06

そんなコードに拘り過ぎてもね

261

： 仕様書無しさん [sage] 2018/04/14(土) 22:00:37.11

コード無しで動くものが作れるというのなら
やってみると良い

262

： 仕様書無しさん [sage] 2018/04/14(土) 22:00:55.90

>>259

え？
「動きを変えない」のがリファクタだろ？

最終的な製品のよさに一切関係ないじゃん

263

： 仕様書無しさん [sage] 2018/04/14(土) 22:33:53.14

>>262

アホかｗ

動きを変える時に既存の部分に手を入れやすくするために
行うのがリファクタリングなんだよｗ

なんで既存の部分を拡張するときに、
既存の部分に一切手を入れずに拡張しないといかんのだ
そんなことをするとシステムが破綻するだろ
そんなの客は望んでない

264

： 仕様書無しさん [sage] 2018/04/14(土) 22:48:28.81

ま、客の心理としては、リファクタリングに金なんて出したくないよな
効果があるならちゃんと定量的に示さないと

265

： 仕様書無しさん [sage] 2018/04/14(土) 22:49:48.06

>>263

それは改修に必要な作業だろ
設計改善という意味でのリファクタリングとは違う

266

： 仕様書無しさん [sage] 2018/04/14(土) 22:52:35.01

>そんなことをするとシステムが破綻するだろ

おれの知る限り実態とはかけ離れてるが
いい脅し文句だな

267

： 仕様書無しさん [sage] 2018/04/14(土) 22:57:51.82

>>266

設計を改善しないで拡張ばかり繰り返して
手がつけられなくなったプロジェクトは山ほどあるぞ

リファクタリングの概念がなかったCOBOL時代のプロジェクトなんか
そんな感じで一行修正するだけでもその影響範囲が
どこまであるのかさっぱりわからない状態になってるぞ

268

： 仕様書無しさん [sage] 2018/04/14(土) 22:59:08.23

ってか不必要に改変してテスト工数が増えるだけ
そしてそれは既存コードの破壊の可能性を意味する
最も客の信頼を破壊する行為だ
リファクタリングで工数が増える要素はいくらでもあるが
お前が主張する工数が減る要素は欠片も見えない

269

： 仕様書無しさん [sage] 2018/04/14(土) 22:59:44.75

>>264

> ま、客の心理としては、リファクタリングに金なんて出したくないよな
> 効果があるならちゃんと定量的に示さないと

なんでそこに客が出てくるのか分からんのだが？
修正＝リファクタリング＋機能追加・変更だろ

270

： 仕様書無しさん [sage] 2018/04/14(土) 23:00:19.54

>>268

> ってか不必要に改変してテスト工数が増えるだけ
> そしてそれは既存コードの破壊の可能性を意味する

機能追加したら、どうせ全部テストするだろ？
なにを言ってるんだろうか。

271

： 仕様書無しさん [sage] 2018/04/14(土) 23:01:38.09

実際問題普通に改修したほうが安い

既存部分に手を入れやすくなるっていうのが
具体的に何を示してるんかはわからんが
テスト工数が減るとか増えるとか具体的なリスクやメリットを説明しないといけないのはもちろん
思ったより工数がかさんだら客は受注そのものをしなくなる

へたなこと言ったら将来にわたって改修の割引を要求されるかもしらん

272

： 仕様書無しさん [sage] 2018/04/14(土) 23:01:54.81

>>270

影響ないとこはしないよ

273

： 仕様書無しさん [sage] 2018/04/14(土) 23:03:08.20

>>269

おまいがリファクタ分の改修工数客からもらえって言いだしたんじゃないんかｗ

274

： 仕様書無しさん [sage] 2018/04/14(土) 23:04:27.75

ソースが汚いので綺麗にしておきました
動作は変わりません
とか勝手にやったらちゃんと管理してるようなとこは検収拒否もあり得るレベルだと言うことは認識したほうがいい

275

： 仕様書無しさん [sage] 2018/04/14(土) 23:12:05.78

>>273

お前はコード1行ごとに見積もりだしてんのか？

リファクタリングなんか機能の修正の一部でしかないだろうが
別々に費用を分けるという発想がおかしいんだよ

>>274

なんで修正しないのにリファクタリングしてんの？
修正の一部にリファクタリングが含まれてるってだけなのに

276

： 仕様書無しさん [sage] 2018/04/14(土) 23:19:02.03

混ぜ込んでばれない程度ならいいけどな

277

： 仕様書無しさん [sage] 2018/04/14(土) 23:19:58.46

っていうか、見積もりだす時に
既存のコードの状態に関係なく、
まったく同じ費用を出すのか？

デスマの未来しか見えないなｗ

278

： 仕様書無しさん [sage] 2018/04/14(土) 23:20:54.13

>>276

普段からこまめに片付けしてないから
部屋片付けるだけで土日潰れるんやで？ｗ

279

： 仕様書無しさん [sage] 2018/04/14(土) 23:27:05.74

派遣や請け負いだとコードが自分達の資産である意識が低いから読みやすさとかどーでもいい、動いて検収に通りさえすればいいという意識が働く

リファクタリングとかは時間が余った時の暇潰し

280

： 仕様書無しさん [sage] 2018/04/14(土) 23:30:29.87

意識が低いというか実際自分のものじゃないじゃないか

そのうえコード所有者の客が工数くれないのになぜ勝手にやろうとするのか

281

： 仕様書無しさん [sage] 2018/04/14(土) 23:33:29.16

>>280

だよな
大きなお世話だと理解しろよな

282

： 仕様書無しさん [sage] 2018/04/14(土) 23:37:04.32

>>280

> そのうえコード所有者の客が工数くれないのになぜ勝手にやろうとするのか

え？ お前、客がなにかしたいと言った時
工数くれなくても働くの？
タダ働きしてるの？

283

： 仕様書無しさん [sage] 2018/04/14(土) 23:37:47.85

>>282

や　ら　な　い　よ　？

284

： 仕様書無しさん [sage] 2018/04/14(土) 23:39:11.64

じゃあ工数の中に、やるべきことを含めないで
ぎりぎりの見積もりを出すんだろうねｗ

285

： KAC [sage] 2018/04/14(土) 23:40:38.16

というか、下請け作業の発注元を「客」と表現するのやめとけ。
話が混乱してるぞ。

286

： 仕様書無しさん [sage] 2018/04/14(土) 23:41:30.22

客のせいにしているけど、結局は自分がやるべきことを
やらなくてもいいと思ってるから、低い見積もりだして
どんどんシステムをダメにしていってるってのが
分かってないんだろうね

287

： 仕様書無しさん [sage] 2018/04/14(土) 23:44:41.22

やらないほうが安いからやるのがどうかって話してんのに
なんでいつの間にか「やるべきこと」になってんの？

288

： 仕様書無しさん [sage] 2018/04/14(土) 23:45:23.28

>>280

だから受け入れ側のコードレビューが大事

どんなコード書かれるかわかったもんじゃない

289

： 仕様書無しさん [sage] 2018/04/14(土) 23:46:41.99

>>287

まともなものを作るにはどちらにしろ金がかかる。
まともなものを作るという前提においては
リファクタリングしたほうが安くなる

それに対して、バグばかりでろくに動かない
品質が低いものをでいいだろ、どうせ検収に通ればOK
使うのは俺らじゃないし、で作れば金はかからないだろうが
できるのはゴミ。

290

： 仕様書無しさん [sage] 2018/04/14(土) 23:49:46.95

>>287

リファクタしたら少なくともそれまでの手動テストはやりなおしじゃん
稼働実績も影響範囲内でリセットになるし
一般的にいってリファクタすると一時的にせよ品質は下がる

おまえのいってる品質向上の根拠ってどこにあんの？

291

： 仕様書無しさん [sage] 2018/04/14(土) 23:50:12.69

>>287

×

>>289

〇

292

： 仕様書無しさん [sage] 2018/04/14(土) 23:58:30.24

>>290

> リファクタしたら少なくともそれまでの手動テストはやりなおしじゃん

リファクタしなくても修正するんだろ？
じゃあその修正箇所はどちらにしろやり直しじゃん
なら修正箇所のリファクタリングしても同じなんだけど

> 一般的にいってリファクタすると一時的にせよ品質は下がる
用語の使い方が間違ってる。
お前はただ単に「修正」の意味で使ってる

定義からしてリファクタリングは品質を上げるものなので
下がることはない。（下がる時点でそれはリファクタリングになっていない）

> おまえのいってる品質向上の根拠ってどこにあんの？
客観的な計測ツールで計測できることをわざわざ質問しないでくれないかな？
コードの品質を調べるツールならいくらでもあるだろ
ttp://blog.y-yuki.net/entry/2017/05/13/000000

293

： 仕様書無しさん [sage] 2018/04/15(日) 00:04:24.69

>>292

超長いけど全く中身がないなｗ
自分の言葉で説明しろよ

294

： 仕様書無しさん [sage] 2018/04/15(日) 00:07:00.26

>>292

おまえさっき改修のために既存部分にも手を入れるって言ってたやん！
つまりコードメトリクス上のスコアを上げるために改修部分に合わせて既存部分も修正するんだろ？

ＵＴまでで図れる品質は多少上がるだろうが、結合試験以降の分は？


>定義からしてリファクタリングは品質を上げるものなので
>下がることはない。（下がる時点でそれはリファクタリングになっていない）

ちょっと背筋さむくなった
主張が変わってもこのヤバい思考は見覚えがある
…else…

295

： 仕様書無しさん [sage] 2018/04/15(日) 00:08:01.95

>>292

意味不明なこと言ってんなよ
客側でした試験もやり直しだし
検収もやり直しだし
今までの実績も無価値になっちゃうし
一体どこに品質を上げる要素があんだよ
寝ぼけてんのかよ
テメーみてーな単価50万じゃすまねーヤツの工数まで無価値にしてんだぞ
テメーだけで仕事やってんのかよ

296

： 仕様書無しさん [sage] 2018/04/15(日) 00:10:16.66

>>294

> おまえさっき改修のために既存部分にも手を入れるって言ってたやん！
> つまりコードメトリクス上のスコアを上げるために改修部分に合わせて既存部分も修正するんだろ？

え？ 既存の部分と結合するのに、その部分のテストはしないつもり？
まさか自分が書いた部分だけをテストすればOKだと思ってる？

297

： 仕様書無しさん [sage] 2018/04/15(日) 00:11:26.96

シチュエーションに対する想像力なさすぎやしませんかね

298

： 仕様書無しさん [sage] 2018/04/15(日) 00:12:49.27

>>296

曲解し過ぎ
要点は変更する必要もない
コードを見通しが悪いとかいう意味不明な理由で
実績のあるコードを変更してしまうこと

299

： 仕様書無しさん [sage] 2018/04/15(日) 00:13:10.47

>>295

> 一体どこに品質を上げる要素があんだよ

素直に、品質を上げる要素がわかりませんって
いったほうが良いのでは？

何度も言ってる。コードをあるべき姿に修正すると
レビューする時間も減るしバグの見逃しも減る。

客からの要請でコードを修正するとき、
修正したコード（とそれに関連する部分）の
レビューとテストが大幅に減る。

コードが単純であればるほど、問題ないねと判断するのが速くなる
逆にコードが複雑だと、なにをやってるのか「解析」しなければいけない

300

： 仕様書無しさん [sage] 2018/04/15(日) 00:14:51.21

>>298

> 要点は変更する必要もない

客が機能等を追加変更する時の話をしてるのに
なんで変更する必要がないの？

なにかを変更する時、そこにリファクタリングは
必ず含まれるってだけなんだけど

リファクタリングせずに闇雲に修正していったら
すぐに破綻する

301

： 仕様書無しさん [sage] 2018/04/15(日) 00:14:53.02

>>299

全く根拠がねーだよ
お前が言ってるのは全部お前の主観でしかない
今まで本番環境で問題なく動いてた実績を
ゴミにしてまでやってしまっていいことではない

302

： 仕様書無しさん [sage] 2018/04/15(日) 00:16:13.53

>>300

お前は見通しが悪いってだけでコードを修正しちまうんだよな？

303

： 仕様書無しさん [sage] 2018/04/15(日) 00:16:49.68

>>298

> コードを見通しが悪いとかいう意味不明な理由で
> 実績のあるコードを変更してしまうこと

実績のあるコードをそのまま使えるなら修正しなくて良いのでは？（笑）
ブラックボックスとして使えばいいでしょ。

それでその「実績のあるそのコード」に関連する部分を修正する時に
その修正にブラックボックスが耐えられるかどうか、
どうやって判断するの？

実績があるのは修正が入らない状態で、
修正が入るなら実績は意味なくなるよ。

304

： 仕様書無しさん [sage] 2018/04/15(日) 00:18:46.54

>>302

> お前は見通しが悪いってだけでコードを修正しちまうんだよな？

お前順番が逆ｗ

コードを修正するときは、客の要請など理由がある時
修正するのは大前提で、理由は今の話と関係ない。

修正する時に、リファクタリングして修正するか
闇雲に修正するかの話だ。

お前は見通しが悪いものを修正するときに
見通しが悪いまま修正するんだな？
そして見通しが悪いまま他の人にレビューさせるわけだよな？
せっかくお前が時間かけて見通しが悪いものを理解しても
その理解は残さず、見通しが悪いまま残しておくと

305

： 仕様書無しさん [sage] 2018/04/15(日) 00:18:57.35

>>303

え？修正があるかもしれない？って状況であって修正があるわけじゃないんだよね？
何でその状態でいじっちゃうの？

306

： 仕様書無しさん [sage] 2018/04/15(日) 00:20:04.21

正直既存部分でも
Ｅｃｌｉｐｓｅ機能でメソッド抽出するぐらい見逃してくれとおもわんでもない

307

： 仕様書無しさん [sage] 2018/04/15(日) 00:22:58.36

>>305

> え？修正があるかもしれない？って状況であって修正があるわけじゃないんだよね？

お前ひどいな。修正があるかもしれない？状況って
俺言ってないじゃん。

そうやってお前は、嘘つきまくるわけか
嘘つき

修正するのは大前提。客が修正したいって言ってるんだから
修正するのは決定事項で、修正するかどうかは今の話に関係ない

308

： 仕様書無しさん [sage] 2018/04/15(日) 00:24:01.30

>>306

どっちみちそのコードを通るテストをするなら
やっていいよ

309

： 仕様書無しさん [sage] 2018/04/15(日) 00:24:11.33

>>307

は？
マジで何言ってるのかわからない
頭大丈夫か？

310

： 仕様書無しさん [sage] 2018/04/15(日) 00:24:47.98

>>309

わからないなら、頭が悪いのでは？

311

： 仕様書無しさん [sage] 2018/04/15(日) 00:25:30.95

>>310

siriのがマシなレベルでびっくりしてる

312

： 仕様書無しさん [sage] 2018/04/15(日) 00:26:40.07

>>311

じゃあsiriと会話してれば良いのでは？ｗ

313

： 仕様書無しさん [sage] 2018/04/15(日) 00:27:42.96

サイコパスもいいとこだな
結局リファクタリングのビジネス的なメリットを一切挙げることができてないことに気づいてるの？彼は

314

： 仕様書無しさん [sage] 2018/04/15(日) 00:28:43.22

中身の無い奴ほど長文を書く

315

： 仕様書無しさん [sage] 2018/04/15(日) 00:28:48.35

>>313

それはリファクタリング本を書いている人に対して喧嘩を売ってるということでいいの？

316

： 仕様書無しさん [sage] 2018/04/15(日) 00:31:15.72

そうではないといいたいところだが実は喧嘩売りたい
マーチンファウラーは悪魔

317

： 仕様書無しさん [sage] 2018/04/15(日) 00:31:28.12

>>315

本？急にどうしたの？
どっから本とか出てきた？

俺はお前が説明できてないよね
って言っただけだよ
急に本とか何？どっから出てきたの？

脳に障害でもあるの？

318

： 仕様書無しさん [sage] 2018/04/15(日) 00:33:28.86

権威に根差してものを考えるタイプなんだろう
たぶん幼少時の教育が悪すぎた

319

： 仕様書無しさん [sage] 2018/04/15(日) 00:37:07.39

>>318

技術者にはなるべきではなかったんだろうなぁ
言ってること滅茶苦茶だったし

320

： 仕様書無しさん [sage] 2018/04/15(日) 00:44:24.24

ジャップ君もといelse不要ガイジのいなくなった上級雑談スレの惨状を見るにつけ
それはどうか微妙なところ
滅茶苦茶でも一応相手の言うこと聞いてきっちり答えてるから会話が成立する

茶化すだけならサルでもできるし

321

： 仕様書無しさん [sage] 2018/04/15(日) 01:38:37.55

機能追加のために既存コードを改修することをリファクタリングと言ってる人と、設計改善をリファクタリングと言ってる人で平行線

322

： 仕様書無しさん [sage] 2018/04/15(日) 02:14:19.62

ttps://medaka.5ch.net/test/read.cgi/prog/1523721765/

Ｊａｖａじじいをこれ以上だませなくなったのでターゲット変えた模様

コードのにおいとか言われて
他人のコードを場当たり的にぐちゃぐちゃにする新人がまたどれだけ出ることやら

323

： 仕様書無しさん [sage] 2018/04/15(日) 03:52:14.93

>>321

どっちもリファクタリングの一部では？

324

： 仕様書無しさん [sage] 2018/04/15(日) 04:50:40.58

ttp://www.atmarkit.co.jp/ait/articles/1403/25/news033_2.html

> Scenario: TDDのサイクルはRED、GREEN、REFACTORからなっています。
> GREENからREFACTORを飛ばすことはありますが、REDからGREENを飛ばしてREFACTORしないのが特徴です。
> これはテストなどによって保証されている範囲でのみ内部を変更することを「REFACTORING」と呼ぶという定義によるものです。

これはテストなどによって保証されている範囲でのみ内部を変更することを
「REFACTORING」と呼ぶという定義によるものです。

これはテストなどによって保証されている範囲でのみ内部を変更することを
「REFACTORING」と呼ぶという定義によるものです。

定義ぐらい知っておけよ

325

： 仕様書無しさん [sage] 2018/04/15(日) 06:49:51.02

定義が現実の課題の何を解決してくれるんだ

326

： 仕様書無しさん [sage] 2018/04/15(日) 07:27:26.07

ちゃんと定義しないと何議論してるか分かんないじゃん

327

： 仕様書無しさん [sage] 2018/04/15(日) 07:34:53.60

リファクタリングのメリットを定義して欲しい

328

： 仕様書無しさん [sage] 2018/04/15(日) 07:41:54.33

リファクタリングをしない工程とはどんな手順を想定していて
リファクタリングをする工程とはどんな手順をを想定しているのか？
工数が減るならそれのどの手順でどんな理由で工数が減るのか？
品質が上がるならそれのどの手順でどんな理由で品質が上がるのか？
また、その品質を判定する基準は何か？
おおよその目処となる数字を入れて説明して欲しい

リファクタリング
　→無条件で品質は上がり工数は削減できる

って言われても
( ﾟдﾟ)はぁ？
としか

329

： 仕様書無しさん [sage] 2018/04/15(日) 07:48:33.45

仕様をねじ曲げる事ではない

リファクタするにはユニットテストが重要

330

： 仕様書無しさん [sage] 2018/04/15(日) 07:50:21.74

>>329

そんなくだらんレスを付けると
ユニットテスト＝リファクタリングでいいの？
とかくだらないレスに対応することになるわけよ

331

： 仕様書無しさん [sage] 2018/04/15(日) 07:51:49.97

コードを整理するには広くて先を見通す視野、ある程度の経験が必要

332

： 仕様書無しさん [sage] 2018/04/15(日) 07:53:04.79

振る舞いが変わっていないことを担保するのがユニットテスト

333

： 仕様書無しさん [sage] 2018/04/15(日) 08:00:46.28

>>332

結合にも影響出るよね？
何で担保するん？

334

： 仕様書無しさん [sage] 2018/04/15(日) 08:04:44.80

だって求める品質によるもの
複雑さを品質に求める分野もあれば
動きゃよいんだよどうせ派遣だしもあるし
後者にリファクタリングもテストコードも要らんだろ

ところでOOPのスレじゃないのかココ

335

： 仕様書無しさん [sage] 2018/04/15(日) 08:05:49.62

>>334

OOPとリファクタリングはなんの関係もないという主張？

336

： 仕様書無しさん [sage] 2018/04/15(日) 08:24:47.34

結合通った後はコードに触ってはいけないという思想はシステムの硬直化を招き定期的なリプレースが必要となる

337

： 仕様書無しさん [sage] 2018/04/15(日) 08:40:17.41

リファクタ推奨するメリケン人どもはどうやってそのへんクリアしてるのか知りたい
ほんとに

338

： 仕様書無しさん [sage] 2018/04/15(日) 08:56:29.91

>>335

おそれりました

そりゃ
リファクタリングしてテスト通ったコードが
現場で問題出したら
それテストコードのバグだから

339

： 仕様書無しさん [sage] 2018/04/15(日) 09:48:16.91

>>335

少しでも関係あればなんでもありっていう主張？

340

： 仕様書無しさん [sage] 2018/04/15(日) 09:50:17.26

オブジェクト指向とelseは無関係ではないからelseを使うことの是非について議論したい

341

： 仕様書無しさん [sage] 2018/04/15(日) 09:53:16.31

elseとかどうでもいい死ね

342

： 仕様書無しさん [sage] 2018/04/15(日) 09:57:01.98

どうでもいいっていうのは、elseを使わないことでどれだけコードの見通しがよくなるかを知らない奴の意見

343

： 仕様書無しさん [sage] 2018/04/15(日) 10:01:46.42

1メソッドの行数が長いゴミの意見

344

： 仕様書無しさん [sage] 2018/04/15(日) 10:26:46.73

リファクタリングすれば短くなるし問題ない

345

： 仕様書無しさん [sage] 2018/04/15(日) 10:39:41.50

>>340

向こうでやれ

346

： 仕様書無しさん [] 2018/04/15(日) 11:02:17.65

デザインパターンをインターフェースから説明した良心的なブログ

ttps://blogs.yahoo.co.jp/kamyu_2010/35417803.html

347

： 仕様書無しさん [sage] 2018/04/15(日) 12:23:22.87

>>333

UIテスト

348

： 仕様書無しさん [sage] 2018/04/15(日) 12:25:43.59

>>347

バカが納品できねーよ

349

： 仕様書無しさん [sage] 2018/04/15(日) 12:27:48.06

>>348

すまん意味不明なので整理してもっかいレスして

350

： 仕様書無しさん [sage] 2018/04/15(日) 13:04:27.43

はい、スレ立てた

少し修正するたびに全部テストするのは当たり前
ttps://medaka.5ch.net/test/read.cgi/prog/1523765051/

351

： 仕様書無しさん [sage] 2018/04/15(日) 13:05:51.89

日本ではアジャイルが流行らないわけだ

352

： 仕様書無しさん [sage] 2018/04/15(日) 13:14:22.09

はい、スレ立てたｗ

ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾
ttps://medaka.5ch.net/test/read.cgi/prog/1523765624/

353

： 仕様書無しさん [sage] 2018/04/15(日) 17:47:40.29

２つもたてたんかい

354

： 仕様書無しさん [sage] 2018/04/15(日) 18:59:09.34

まだまだあるぜ

リファクタリングなんて金の無駄
ttps://medaka.5ch.net/test/read.cgi/prog/1523780004/

ｿｰｽｺｰﾄﾞだけじゃなく設計もﾘﾌｧｸﾀﾘﾝｸﾞしよう！
ttps://medaka.5ch.net/test/read.cgi/prog/1523772587/

355

： 仕様書無しさん [sage] 2018/04/15(日) 19:50:19.56

勝手に変更する行為をﾘﾌｧｸﾀﾘﾝｸﾞと思い込んでるﾊﾞｶへ
ttps://medaka.5ch.net/test/read.cgi/prog/1523772103/

356

： 仕様書無しさん [sage] 2018/04/15(日) 20:08:29.70

汚いｺｰﾄﾞを修正のたびに何度も解析するのがプロだろ
ttps://medaka.5ch.net/test/read.cgi/prog/1523790217/

357

： 仕様書無しさん [sage] 2018/04/15(日) 20:51:53.26

こちとら1関数平均1000行コードを相手にしてるんだ
ttps://medaka.5ch.net/test/read.cgi/prog/1523791012/

358

： 仕様書無しさん [sage] 2018/04/15(日) 21:50:17.18

リファクタリングでなにがあったの？

359

： 仕様書無しさん [sage] 2018/04/15(日) 21:52:29.67

リファクタリングはゴミ
ttps://medaka.5ch.net/test/read.cgi/prog/1523793974/

360

： 仕様書無しさん [sage] 2018/04/16(月) 14:27:02.06

ところで、オブジェクト指向ってなんですか？
わかりやすく教えてください。

361

： 仕様書無しさん [sage] 2018/04/16(月) 14:33:22.45

リファクタリングのことです

362

： 仕様書無しさん [sage] 2018/04/16(月) 15:11:03.41

COBOLをリファクタリングしてもオブジェクト指向にはならなくね？

363

： 仕様書無しさん [sage] 2018/04/16(月) 15:28:12.64

C言語でもオブジェクト指向な実装はできるんだから、COBOLでも頑張ってやれば出来んじゃね？

364

： KAC [sage] 2018/04/16(月) 17:48:09.62

>>360

「指向」という意味は理解できてる？

365

： 仕様書無しさん [sage] 2018/04/16(月) 21:34:26.65

>>1

犬はワンで猫はニャー。

366

： 仕様書無しさん [sage] 2018/04/16(月) 21:43:36.62

なんとなく漠然とオブジェクトのほうを指さしているイメージ

367

： 仕様書無しさん [sage] 2018/04/16(月) 21:45:28.02

>>363

出来るのは当たり前。
使い物にならない、ってだけ。

368

： 仕様書無しさん [sage] 2018/04/16(月) 22:36:43.07

>>364

わからないので教えてください><

369

： KAC [sage] 2018/04/16(月) 22:51:01.08

>>368

じゃあ辞書引いてから出直して

370

： 仕様書無しさん [sage] 2018/04/16(月) 23:03:26.64

えらそうに振り回すだけで情報出さないくそＳＥの鏡

371

： KAC [sage] 2018/04/16(月) 23:55:16.32

調べられる事くらい調べといて貰わないと
時間とスレが無駄に消費されるだけで
百害あって一利無しだろ？

372

： 仕様書無しさん [sage] 2018/04/16(月) 23:57:31.81

百害あって一利なし
確かに

373

： 仕様書無しさん [sage] 2018/04/17(火) 00:01:45.95

たぶんお前と一緒にオブジェクト指向の意味を考察したいわけじゃなくて
知ってる人に教えてほしかっただけだとおもうが

知った気な顔しといた挙句横から人に指図するだけで
なんの役にも立ってないおまいはなんなんだ

374

： 仕様書無しさん [sage] 2018/04/17(火) 02:16:14.68

じゃあせめてオブジェクト指向とは何か三行で教えて

375

： 仕様書無しさん [sage] 2018/04/17(火) 03:03:16.01

ち
ん
ぽ

376

： 仕様書無しさん [sage] 2018/04/17(火) 10:18:35.28

三行もいらない。

オブジェクト指向とはポインター

377

： 仕様書無しさん [sage] 2018/04/17(火) 10:52:13.75

宗教の一種だな
現実に追い詰められたプログラマの心の拠り所

OOP教FP教、DDD教、アジャイル教
経典に描かれた楽園を夢見ても、
クソ客クソPMクソ外注クソコード、現実の苦しみからは救ってくれないのが悲しいね

378

： 仕様書無しさん [sage] 2018/04/17(火) 10:56:28.98

ジハードが必要だな。

379

： 仕様書無しさん [sage] 2018/04/17(火) 16:14:37.11

>>376

ないわ〜

380

： 仕様書無しさん [sage] 2018/04/17(火) 19:29:42.72

まあC言語のファイル操作の関数を考えてみればいいんじゃね？

データ（ファイルポインタ）を内包出来ないから毎回持ち回らないといけない

データとその操作をワンセットで扱えるのが利点だと思うが

381

： 仕様書無しさん [sage] 2018/04/17(火) 19:31:02.46

持ち回るというのは引数で指定する必要があるって意味ね

382

： 仕様書無しさん [sage] 2018/04/23(月) 11:43:52.16

疎結合というのは倦怠期でセックスをしなくなった中年夫婦のようなもの

383

： 仕様書無しさん [sage] 2018/04/27(金) 01:15:37.94

誰でもいいから早くオブジェクト指向が何か答えてくれない？

384

： 仕様書無しさん [sage] 2018/04/27(金) 02:03:29.94

>>8

385

： KAC [sage] 2018/04/27(金) 07:38:38.15

>>383

「オブジェクト」と「指向」をそれぞれ辞書引けば解るだろ

386

： 仕様書無しさん [sage] 2018/04/27(金) 07:45:06.50

>>385

それを語るスレでそんなこと言っちゃうわけ？ww

387

： 仕様書無しさん [sage] 2018/04/27(金) 12:41:08.47

>>383

変数とそれを扱う関数をまとめたオブジェクト同士が情報をやりとりしながら動作するソフトを作る設計手法

388

： 仕様書無しさん [sage] 2018/04/27(金) 16:06:25.42

>>387

みなさんこれでFAですか？

389

： 384 [sage] 2018/04/27(金) 18:35:06.26

だからまずWikipedia読もうよ

390

： 仕様書無しさん [] 2018/04/27(金) 18:40:35.63

>>389

読んだらおまえが報告しろよw

391

： 仕様書無しさん [sage] 2018/04/27(金) 19:29:55.50

関連するデータと手続きを一まとめにしたもの、こいつをオブジェクトと呼ぶことにします

オブジェクトを基本単位にプログラムを作ること、そいつをオブジェクト指向と呼ぶことにします

392

： 仕様書無しさん [sage] 2018/04/27(金) 21:07:25.85

オブジェクト指向に必須ではないものを取り除いた
最小限のたオブジェクト指向には
なにがあるのでしょうか？

393

： 仕様書無しさん [sage] 2018/04/27(金) 21:55:38.27

オブジェクト

394

： 仕様書無しさん [sage] 2018/04/27(金) 22:10:04.98

>>391

この説明以上に必要なことある？

395

： 仕様書無しさん [sage] 2018/04/27(金) 22:50:28.34

結局戦争はなくならなかった
だが変化はあった

396

： 仕様書無しさん [sage] 2018/04/27(金) 23:09:28.43

>>391

合ってる。

オブジェクトの性格(？)は、
出来るだけコミュ障(必要最小限)な方がいいと思う。

397

： 仕様書無しさん [sage] 2018/04/27(金) 23:41:22.95

更に、オブジェクトを作るための型、これをクラスと呼ぶこととします（便宜上クラスから作られた実体をインスタンスと表現したりもします）

クラスの定義はまだ台本を書いただけで、インスタンス化されたときにはじめて役者がステージに上がり実際に演技をします

398

： 仕様書無しさん [sage] 2018/04/28(土) 02:19:15.08

>>397

蛇足だわ

399

： 仕様書無しさん [sage] 2018/04/28(土) 05:35:11.99

オブジェクト指向って何？に対してよくある
バカな説明レベルに戻っとる

400

： 仕様書無しさん [sage] 2018/04/28(土) 08:23:55.28

>>399

バカじゃない説明出来るの？

401

： 仕様書無しさん [sage] 2018/04/28(土) 09:50:08.01

猫とかステージとか、例えが出てくるとバカっぽく見える事はあるな
解りやすければ、どんなにバカでもかまわないけど

402

： 仕様書無しさん [sage] 2018/04/28(土) 10:21:26.84

もっとお馬鹿っぽいのがよかったな

403

： 仕様書無しさん [sage] 2018/04/28(土) 10:45:42.82

わかりやすく例えて説明する
↓
その例えでは完璧に表現できないといちゃもんをつける


例えは所詮例えであって、
わからない人にわかりやすく伝えるための手段なのに
オブジェクト指向の限界みたいな話に持って
いこうとするやつがいるんだよなあぁ

あれは本当に馬鹿

404

： 仕様書無しさん [sage] 2018/04/28(土) 10:58:36.25

キャットドア…

405

： 仕様書無しさん [sage] 2018/04/28(土) 11:15:21.20

>>404

そう。それも馬鹿ｗ

406

： 仕様書無しさん [sage] 2018/04/28(土) 11:15:50.89

萌えキャラに擬人化するともっとお馬鹿っぽく出来るかも知れない

407

： 仕様書無しさん [sage] 2018/04/28(土) 11:55:28.97

これぐらい単純な例のほうがいいわ
ttps://qiita.com/Nekonecode/items/d194c66ddb8a27dc4345

408

： 仕様書無しさん [sage] 2018/04/28(土) 11:59:49.19

ゲームはイメージしやすいかもな

409

： 仕様書無しさん [sage] 2018/04/28(土) 12:45:59.35

やっぱりクラスを使わない場合の実装とかクラスライブラリの成長過程を体験しないと本当に理解は出来ないからな

410

： 384 [sage] 2018/04/28(土) 13:39:43.52

>>390

報告？
あれがよくまとまってるから推奨してるんだが、まさか読まずに言ってるとでも思ったのか？

411

： 仕様書無しさん [sage] 2018/04/28(土) 19:03:29.48

犬猫の説明は有害
あれ誰が始めたんだか

412

： 仕様書無しさん [sage] 2018/04/28(土) 19:28:15.44

別に有害じゃない。

動物がたくさん出てくるゲームを作ろうと思ったら
CatクラスDogクラスは普通に作る。

413

： 仕様書無しさん [sage] 2018/04/28(土) 19:34:59.55

>>412

いや、有害。

オブジェクトと生命をごちゃ混ぜに考えるとわけわかんなくなる

414

： 仕様書無しさん [sage] 2018/04/28(土) 19:37:19.66

>>413

有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる

415

： 仕様書無しさん [sage] 2018/04/28(土) 21:09:33.14

>>412

今時、そんな拡張性のない方法使わんだろ。
振る舞いが動物に見えれば良いんだし。

416

： 仕様書無しさん [sage] 2018/04/28(土) 21:40:47.91

>>413

俺は犬猫の説明でオブジェクト指向をふんわり理解して、その少しあとにはもう業務システムに適用してたよ
抽象と具象を行ったりきたりできない人には有害なのかな、、

417

： 仕様書無しさん [sage] 2018/04/28(土) 22:18:39.34

ある程度の経験者なら余計なイメージを経由したくは無いだろうな

418

： 仕様書無しさん [sage] 2018/04/28(土) 22:47:23.43

ある程度の経験者なら犬猫に惑わされたりしないだろ

419

： 仕様書無しさん [sage] 2018/04/28(土) 22:48:31.00

>>415

だからお前の考える世界を実現するために
言ってるんじゃないんだよ
本当にアホだなぁｗ

初心者にわかりやすく説明するために使ってるの

420

： 仕様書無しさん [sage] 2018/04/28(土) 22:50:11.70

オブジェクト指向が主流になってもうどれだけ経つよ？
いまだに使いこなせてない意味がわかんないんだけど

421

： 仕様書無しさん [sage] 2018/04/28(土) 22:57:29.79

使えるけど作れない人はいまだに五万といるよ

おまじない的にコピペで出来てしまうからね

422

： 仕様書無しさん [sage] 2018/04/29(日) 06:01:59.48

>>414

いいや、有害なのはあんただね！

オブジェクト指向で犬や猫を作ることなんてできたか？
俺はできなかったね！！俺が作ることができたのはボタンを押したら猫の声が出るおもちゃだ。

わかりやすい例え話をするんだったら、ホイールやハンドル、エンジンを使って車を作る例え話をするべきなんだ。

423

： 仕様書無しさん [sage] 2018/04/29(日) 06:37:46.24

だって種分類とOOPは何の関係もないし

もし
人類のスーパクラスがあったら
それはネズミの祖先だわい
(ループ開始)

424

： 仕様書無しさん [sage] 2018/04/29(日) 06:39:11.67

>>420

人類は100万年経つのに
まだ戦争やってるだろ

425

： 仕様書無しさん [sage] 2018/04/29(日) 07:06:24.08

ネズミの祖先が人類のスーパークラスになるの？

426

： 仕様書無しさん [sage] 2018/04/29(日) 07:06:54.48

犬猫とかのあまり実用的でない例を出さなくても
実用的な例で説明したらいいんじゃない？

例えばstringクラスとかなら、実用的だし理解しやすいだろ

427

： 仕様書無しさん [sage] 2018/04/29(日) 08:57:23.25

犬猫で納得する奴はOOPを理解していないよ

428

： 仕様書無しさん [sage] 2018/04/29(日) 09:20:13.50

>>419

初心者に媚びて、結局嘘教えるんじゃあ有害なだけだが？

429

： 仕様書無しさん [sage] 2018/04/29(日) 09:52:58.94

適当にいったつもりだったが
思いの外みんな賛同してくれてビビったww

430

： 仕様書無しさん [sage] 2018/04/29(日) 09:56:39.30

OOPを知っている人は犬猫をOOPで扱うことができるけど、
OOPを知らない人に犬猫をOOPとして考えた時の話をしても
正しい意味で理解できない。
OOPの犬猫の話はOOPを知っている前提の上で成立しているんだよ。

431

： 仕様書無しさん [sage] 2018/04/29(日) 10:13:24.45

>>422

> オブジェクト指向で犬や猫を作ることなんてできたか？

できたぞ？

class Cat
class Dog

432

： 仕様書無しさん [sage] 2018/04/29(日) 10:13:58.50

>>429

みんな適当に言ってるお前に合わせてるだけだｗ

433

： 仕様書無しさん [sage] 2018/04/29(日) 10:20:02.29

生きてる価値のないごみクズってホントやだね
せめて生きててごめんなさいって自害でもしてくれれば
少しは可愛げもうまれるんだろうけど

434

： 仕様書無しさん [sage] 2018/04/29(日) 10:22:54.35

お前が決めた生きてる価値とやらに合わなければ死ねとかｗ

435

： 仕様書無しさん [sage] 2018/04/29(日) 10:31:17.81

死ねじゃなくて、死んでくださいってお願いだろ？
その願いが聞き届けられることはないけどｗ
かわいそうｗｗｗｗ

あ、100年後には聞き届けられてるかもなーｗｗｗ

436

： 仕様書無しさん [sage] 2018/04/29(日) 10:43:13.01

>>430

> OOPを知らない人に犬猫をOOPとして考えた時の話をしても
> 正しい意味で理解できない。

正しい意味で理解できないからだめだっていう
考え方がそもそも間違いだからなぁｗ

中学生ぐらいのレベルでは、原子はそれ以上分解できないという
教えられるが、実際には分解できる。
電流はプラスからマイナスに流れると教えられるが
実際にプラスからマイナスに流れているものはない

例えというのは正しく理解させるためではなく
理解するのに必要な壁を低くするためにある
小さい壁を何度も登っていけば高いところまでいけるが
最初が高いと最初の壁すら登ることさえできない

例えで必要なのは正確さではなく、身近でよく知ってるものに例えることだ
車のパーツとか趣味で車をよく知っている人じゃないとピンとこない

437

： 仕様書無しさん [sage] 2018/04/29(日) 10:44:25.55

>>436

それは理解できない人間の詭弁だね

438

： 仕様書無しさん [sage] 2018/04/29(日) 10:45:40.52

stringでいいじゃん

439

： 仕様書無しさん [sage] 2018/04/29(日) 10:47:03.91

どこでもいいから高いところへ行ければいいと思ってる時点で馬鹿
そんな考えだと行きたいところから遠ざかることもある

440

： 仕様書無しさん [sage] 2018/04/29(日) 10:47:36.61

>>437

詭弁ではないと思うが？

反論の一つぐらい言うように

441

： 仕様書無しさん [sage] 2018/04/29(日) 10:48:16.57

>>439

途中で方向転換すればいいだけ
急がば回れって言葉知ってる？ｗ

442

： 仕様書無しさん [sage] 2018/04/29(日) 10:52:59.05

>>441

急がば回れって知ってる？
どこへ進むのか、進み方もわからん奴にとにかく進めって言っといて急がば回れとか
デタラメにグルグル回っててどうやって目的地につくんですかね

443

： 仕様書無しさん [sage] 2018/04/29(日) 10:53:15.44

途中で方向転換とか、アジャイル厨は消えろ

444

： 仕様書無しさん [sage] 2018/04/29(日) 10:53:35.26

>>440

俺は詭弁だと言っているのだから反論する価値もないと判断したということ。

445

： 仕様書無しさん [sage] 2018/04/29(日) 10:54:58.78

>>442

進み方が知らないのは初心者
初心者にわかりやすく押している俺は理解してる
普通に目的地につけるが？

え？なに？お前初心者が一人で
頑張ってることを想定してんの？

たとえ話を使って教えている人は誰だよｗ

446

： 仕様書無しさん [sage] 2018/04/29(日) 10:55:46.97

>>444

じゃあお前の発言はすべて詭弁だから
反論する価値＝間違いってことですね？

447

： 仕様書無しさん [sage] 2018/04/29(日) 10:59:35.03

>>443

アジャイル良いよねｗ
最初から完璧なものを求めても
単に時間がかかるだけでなにも進まない

448

： 仕様書無しさん [sage] 2018/04/29(日) 10:59:59.56

>>446

そうですね、あなたがそう思うのならそうなんでしょうね。お好きにどうぞ。
別に俺は困りません。

449

： 仕様書無しさん [sage] 2018/04/29(日) 11:00:57.06

> それは理解できない人間の詭弁だね

そうですね、あなたがそう思うのならそうなんでしょうね。お好きにどうぞ。
別に俺は困りません。

完

450

： 仕様書無しさん [sage] 2018/04/29(日) 11:09:29.58

長文は詭弁と定義する

451

： 仕様書無しさん [sage] 2018/04/29(日) 11:10:44.68

それが詭弁

452

： 仕様書無しさん [sage] 2018/04/29(日) 14:40:29.58

本読めないな

453

： 仕様書無しさん [sage] 2018/04/29(日) 15:44:55.30

長文が詭弁であって詭弁を読まないとは言っていない

454

： 仕様書無しさん [sage] 2018/04/29(日) 15:50:59.82

読んだ後、詭弁だなで終わるから
なにも学習しない

455

： 仕様書無しさん [sage] 2018/04/29(日) 15:54:12.49

よっぽど悔しかったらしいｗ

456

： 仕様書無しさん [sage] 2018/04/29(日) 15:58:35.42

>>455

お前がなｗｗｗ

457

： 仕様書無しさん [sage] 2018/04/29(日) 16:11:56.61

悔しくねーしｗ

458

： 仕様書無しさん [sage] 2018/04/29(日) 16:14:39.14

すべてのメソッドが怒りに継承されているんですね

459

： KAC [sage] 2018/04/29(日) 17:41:15.78

>>453

少なくともそれは詭弁だな

460

： 仕様書無しさん [sage] 2018/04/29(日) 17:44:55.39

>>447

まあ実際には、禄に設計も出来てないのをアジャイルとか言い張ってる偽物が多いけど。

461

： 仕様書無しさん [sage] 2018/04/29(日) 18:51:50.74

アジャイル界では、日本の企業で"正しく"アジャイルを導入できてるケースは皆無って言われてるからね
そもそも日本人にアジャイルは向いてないとオレは思う
だからといって、ウォーターフォールが糞であることに変わりはないけどな

462

： 仕様書無しさん [sage] 2018/04/29(日) 19:50:46.18

元々はトヨタの看板方式のソフトウエア版なんだけどね

463

： 仕様書無しさん [] 2018/04/29(日) 20:25:35.35

>>410

だから読んだらおまえが報告しろよw

464

： 仕様書無しさん [sage] 2018/04/29(日) 20:28:53.39

あれ以上まとまっているものに要約は要らんわな

465

： 仕様書無しさん [sage] 2018/04/30(月) 12:44:42.99

>>462

トヨタのような一流企業が長い期間をかけて最適化してきたことを、そこらの派遣プログラマで再現するのは大変だろうな
彼らに出来ることはせいぜい本とかwebを読んでわかった気になるぐらい

466

： 仕様書無しさん [sage] 2018/04/30(月) 14:04:33.08

>>431

ほほう、その犬や猫は、ご主人に餌を求めたりおしっこ漏らしたりするんですかね？

467

： 仕様書無しさん [sage] 2018/04/30(月) 14:05:24.46

>>436

犬や猫はしってるけど、エンジンやタイヤを知らない人なんて見たことない

468

： 仕様書無しさん [sage] 2018/04/30(月) 15:01:45.98

>>466

すでにお前の発言は反論済み

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66

>>413

有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる

469

： 仕様書無しさん [sage] 2018/04/30(月) 17:37:11.93

>>466

そういう機能を実装すればするよ？

470

： 仕様書無しさん [sage] 2018/04/30(月) 19:52:30.01

>>468

えっ、犬とか猫って生物だよね？？
違いましたか？？ww

>>469

じゃあ、実物の猫とほとんど区別がつかない
猫シミュレータ作ってみ？

471

： 仕様書無しさん [sage] 2018/04/30(月) 20:00:08.45

>>470

それは機能が多すぎるし複雑すぎるし要件がわからんからできないけど

何が「じゃあ」なのかが一番わからない
それをもって何をいいたいのか

472

： 仕様書無しさん [sage] 2018/04/30(月) 20:01:57.13

オブジェクト指向スレにいつも現実世界の物を作ってみろー
というバカが出てくるのか不思議で仕方ない

473

： 仕様書無しさん [sage] 2018/04/30(月) 20:07:09.29

>>471

つまり、生物をプログラミングの例えに使うのは
アンチパターンだってこと。

クラスとかモジュールってのは
時計仕掛けとか人形仕掛けのようなものであって

生物を例に出すと混乱の元になる

474

： 仕様書無しさん [sage] 2018/04/30(月) 20:11:47.79

>>473

それって、課題の複雑さにお前がついていけなかっただけじゃないの？

誰も「猫を作れ」なんてことを要求はしていないだろう
猫を描いてくださいとか、猫という字を書いてくださいというののちょっと複雑版だっただけだ
おまえなりの切り口で、お前なりの単純化と抽象化をすればよかったんだ

オブジェクト指向にかぎらずプログラムというのは常にそうだ
おまえはプログラムを始めるには幼なすぎたんだ

475

： 仕様書無しさん [sage] 2018/04/30(月) 20:12:42.39

>>470

> えっ、犬とか猫って生物だよね？？

お前馬鹿なのか？
今はソースコードの話をしてる
class Dogだからって、生き物の犬のことではない。
仮にclass 車の部品 だとしても、
このクラスを実際に車に取り付けられるわけではない。

ほんまにおまえはアホやなｗ

476

： 仕様書無しさん [sage] 2018/04/30(月) 20:14:21.15

>>473

> つまり、生物をプログラミングの例えに使うのは
> アンチパターンだってこと。

その理屈だと時計や人形仕掛けもアンチパターンになる。
ゼンマイはどこにあるんですか？ｗ
オイルはどこに塗れば良いんですかｗ

477

： 仕様書無しさん [sage] 2018/04/30(月) 20:15:18.35

>>474

> オブジェクト指向にかぎらずプログラムというのは常にそうだ
> おまえはプログラムを始めるには幼なすぎたんだ

そういうことなんだよねｗ
例は例であって、本物ではない。
それは誰もが知っていることなんだけど、
そのレベルで分かってない

478

： 仕様書無しさん [sage] 2018/04/30(月) 20:20:41.72

>>475

バカなのはお前だ。

プログラミングやオブジェクト指向がわからない人に
わかりやすく説明する話をしてるんだよ？

犬とか猫って言われたら、犬とか猫をイメージして当然だろ！！
人工知能がどうとか言われる時代なら尚更混乱するわ！！

たしかにEngineクラスを作ったとしても
そのエンジンは実際の車には取り付けられないよ？
でも、ディスプレイの中では取り付けられるよね？

では猫は？ディスプレイの中で現実とそう大差ない猫が作れますか？

479

： 仕様書無しさん [sage] 2018/04/30(月) 20:27:16.29

>>477

もちろんそれは前提としてわかってる

例えるとするならどちらの方がわかりやすい？って話だよ

480

： 仕様書無しさん [sage] 2018/04/30(月) 20:28:25.39

>>478

お前、サイトの利用者を表すUserオブジェクトを作るときに、現実の人間とそう大差ないものを作ってんの？

481

： 仕様書無しさん [sage] 2018/04/30(月) 20:29:27.16

>>479

どっちも大差ないだろ

482

： 仕様書無しさん [sage] 2018/04/30(月) 20:32:14.59

>>445

をちゃんと読め
わかるようになるまでちゃんとフォローアップするって言ってる人に文句言うのはナンセンス

483

： 仕様書無しさん [sage] 2018/04/30(月) 20:40:18.37

>>480

バカじゃん

ユーザーとそう大差ないものを作るわけないだろ？
ユーザーは生物なんだから。人の話聞いてる？？

484

： 仕様書無しさん [sage] 2018/04/30(月) 20:40:24.90

たいていの業務だと、猫シミュレーターなんか作らんからな

猫の毛並みだの血統だの
振る舞いっていったら鳴いたりウンコ漏らしたりすることではなく、
猫クラスからデータを取得するとか、ＤＢにデータを保存するとか、
あったとしても自分の値段を算出することぐらいだ
戸惑うのはわかる

でもそのつまづきポイントはそのはるか手前だろ…

485

： 仕様書無しさん [sage] 2018/04/30(月) 20:41:24.32

>>478

> では猫は？ディスプレイの中で現実とそう大差ない猫が作れますか？

作る必要がない。
誰でもそれが本物の猫のことではないことぐらいわかってるから

486

： 仕様書無しさん [sage] 2018/04/30(月) 20:41:47.86

もう一回かいておくか

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66

>>413

有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる

487

： 仕様書無しさん [sage] 2018/04/30(月) 20:43:46.84

犬猫じゃわからんって言ってる人たちって、これならわかるって説明をいまだに見つけられてないんだよね？
犬猫で説明されてもわからん、かといって他の例で説明されてもわからん、って感じでしょ？
それって、犬猫が悪いんじゃなくて、頭が悪いんだと思う

488

： 仕様書無しさん [sage] 2018/04/30(月) 20:45:26.26

>>486

ぼくの過去れす、とか言われても知らねえよw
誰だよこの名無しw

489

： 仕様書無しさん [sage] 2018/04/30(月) 20:45:48.06

エンジンやハンドルだと、これがクラスなのか
インスタンスなのか分かりづらいという問題がある

犬や猫だと、これがクラスであり
ポチやタマが、インスタンスだと言って
すぐに理解してくれる

490

： 仕様書無しさん [sage] 2018/04/30(月) 20:47:55.65

>>487

> それって、犬猫が悪いんじゃなくて、頭が悪いんだと思う

他人は頭が悪いから、こう考えるんだという想像をしている
俺だったら、こういう勘違いをするという
自分の頭の悪さをかいている

491

： 仕様書無しさん [sage] 2018/04/30(月) 20:52:05.58

犬や猫だと、鳴くという同じメソッドであっても
犬はワンワン、猫はニャーという風に
クラスによって別の処理ができることを説明できる

エンジンやハンドルだと説明できないに
仮にできたとしても、マニアにしか分からん話になる

492

： 仕様書無しさん [sage] 2018/04/30(月) 20:56:24.85

たとえ実態とかけはなれていても
オブジェクト指向の犬猫の説明には楽しそうで夢がある
プログラムに魅力を感じ、のめり込んでもらうにはもってこい

なにより大事なことだが、新人には夢をみせておくにかぎるんだ
いきなり現実の無機質なオブジェクト指向をつきつけたら現実に絶望してしまう…

493

： 仕様書無しさん [sage] 2018/04/30(月) 21:02:37.09

エンジンやハンドルなどのパーツは
同じ名前のメソッドを持ってないからダメなんだろうな
オブジェクト指向の例えとして使ってもすぐに行き詰まる

494

： 仕様書無しさん [sage] 2018/04/30(月) 22:36:29.82

>>493

ハンドルクラスやエンジンクラスがあって、実際のハンドルやエンジンはそのクラスを継承してると考える
ハンドルクラスには、右に回す、左に回す、真ん中を押すというメソッドが有る
で、車にハンドルを乗せる時に、B社のハンドルでもT社のハンドルでも海外製のハンドルでも、必ずハンドルクラスを継承してるので、右に回す、左に回すって事が可能だ
逆に、継承してないハンドルがあれば、それは規格外なので使わないほうが良いと言える
さらにハンドルに企業秘密な技術が使われてて、さらにその技術はハンドル内に隠されて外から見えなかったとしても、中身を気にせず右に回す左に回す事が出来る

で、この説明では

>>489

に陥る

495

： 仕様書無しさん [sage] 2018/04/30(月) 22:48:54.27

> ハンドルクラスやエンジンクラスがあって、実際のハンドルやエンジンはそのクラスを継承してると考える

「実際のハンドルやエンジン」はクラスを継承しているということは
これらはクラスということになる

つまり「実際のハンドルやエンジン」はインスタンスではない

だからこのような説明が必要。
・ハンドルやエンジンというのは共通規格というものがあって、その規格で作られている
・といってもまあメーカーごとに規格違うから互換性ないだろうけどな
・仮にあるとしてだ、ハンドルやエンジンの共通規格を継承して実際のハンドルやエンジンが存在する
・実際のハンドルやエンジンといっても、それは実際に車に取り付けられているものそのものではなく型番みたいなものだ
・同じ型番から作られた製品、実際に車に取り付けられてるやつがインスタンスだ

ややこしいわｗ

496

： 仕様書無しさん [sage] 2018/04/30(月) 22:52:16.28

ハンドルクラスやエンジンクラスを継承した、
実際のハンドルやエンジンを表すクラス。

全ての実際のハンドルやエンジンを表すクラスは
全て右に回す、左に回すというメソッドがあり
いかなる実際のハンドルやエンジンを表すクラスも同じ動作をする

継承したクラスは全て同じ動きをするものである
と勘違いするわけだよな

やっぱり例えとしてだめだわ。
分かりづらいし誤解される

497

： 仕様書無しさん [sage] 2018/05/01(火) 03:17:11.73

ハンドルやエンジンでオブジェクト指向を説明するのは無理だな
やっぱり犬や猫のほうが良い

498

： 仕様書無しさん [sage] 2018/05/01(火) 06:48:54.97

よりダメな例を出して
だから犬猫が良いのよ
という詭弁の典型例

499

： 仕様書無しさん [sage] 2018/05/01(火) 07:20:10.51

そういう詭弁は、もっと良い例を挙げれば一発でひっくり返せる
さぁ、犬猫より良い例を出せよ

500

： 仕様書無しさん [sage] 2018/05/01(火) 07:37:57.50

人間でやったら？
日本人と外国人とか
小学生と中学生とか

501

： 仕様書無しさん [sage] 2018/05/01(火) 07:42:30.20

犬猫の方がわかりやすいというのを認めたとしても

クラスを作れるようになったら、犬猫よりも
エンジンと車の方がわかりやすいのは事実。

そうだろ？

502

： 仕様書無しさん [sage] 2018/05/01(火) 07:46:53.34

クラスを理解して自分で作れるようになったら、エンジンクラスなんて例にする必要ないじゃん

503

： 仕様書無しさん [sage] 2018/05/01(火) 07:52:57.56

>>502

バカなの？理解には理解レベルってのがあるんだよ

504

： 仕様書無しさん [sage] 2018/05/01(火) 07:56:38.35

それに、前に誰かが言ってくれたけど
生物を例に出したら、継承って先祖みたいで混乱するじゃん

犬とか猫を使って説明するのはやはりアンチパターン

505

： 仕様書無しさん [sage] 2018/05/01(火) 08:00:35.91

>>501

先に出てた説明はエンジンとハンドルだったと思うけど
自分で理解してクラス作れるようになった人向けにはわかりやすい（と主張する）説明とか本末転倒では？

506

： 仕様書無しさん [sage] 2018/05/01(火) 08:38:51.09

なんでエンジンクラスをそんなに推してんのw
自分が思いついた考えは特別に感じて捨てられないアレか？

507

： KAC [sage] 2018/05/01(火) 08:42:07.77

エンジンと車の関係と
犬と猫の関係が
同じように語られてるのは何故？

508

： 仕様書無しさん [sage] 2018/05/01(火) 10:00:01.05

>>504

> 生物を例に出したら、継承って先祖みたいで混乱するじゃん

哺乳類を先祖って勘違いする人はいないが？

509

： 仕様書無しさん [sage] 2018/05/01(火) 10:02:21.95

DNAをプログラムとするなら
OOPの継承とは進化だ！
という意見だよ。

510

： KAC [sage] 2018/05/01(火) 10:06:56.41

>>509

どこがオブジェクト指向の話？

511

： 仕様書無しさん [sage] 2018/05/01(火) 10:07:59.18

加えて継承って訳が悪いと思う
Javaみたいに拡張の方良さげ

512

： 仕様書無しさん [sage] 2018/05/01(火) 10:09:29.45

>>510

DNAがOOPだってことさ

513

： 仕様書無しさん [sage] 2018/05/01(火) 10:49:53.70

コードそのものを書き換えてしまうDNAは適切な例えじゃ無いよ。

514

： 仕様書無しさん [sage] 2018/05/01(火) 11:03:54.60

>>505

違う違う。

クラスには何があるのか把握するのは簡単でしょ。コンストラクタがあってーとか、パブリックやプライベートがあってーとか、extendsつかって継承するんだーとか。

そこまでは頭使わなくても、参考書通りに手を動かしていけば誰だってクラスの定義はできるようになるよね。

問題はそれらを応用してアプリケーションを作るときの話だ。その時に犬とか猫とか言われても訳がわからないだろう？

エンジンと車なら一発で理解できるし、クラスが他のクラスの機能を使うとき、ほとんどの場合継承は使わないことも理解できる。

犬とか猫で学んだ人は、何でもかんでも親クラスに共通する機能を定義した神クラスのアンチパターンを踏んでしまう。あんたも神クラス作ったことあるだろう？？

515

： 仕様書無しさん [sage] 2018/05/01(火) 11:26:30.92

胎児のある時期エラがあったりするので中々味わい深い

516

： 仕様書無しさん [sage] 2018/05/01(火) 11:46:27.83

>>508

なんでそういうバカみたいな返信しかできないの？

継承が機能受け継ぎとか親クラスとか言われてて
遺伝を継いだ子供が作れるってことかな？って
間違えて考えてしまう人がいることもわからないわけ？

517

： 仕様書無しさん [sage] 2018/05/01(火) 12:16:05.79

>>514

> エンジンと車なら一発で理解できるし、

エンジンは例えばどんなメソッドを持ってんの？

518

： 仕様書無しさん [sage] 2018/05/01(火) 12:18:25.61

自分が考えることはみんなもそう考えるはずだから仕方ないね

519

： 仕様書無しさん [sage] 2018/05/01(火) 13:26:53.34

ここで犬にエンジン搭載する方法学んでも仕事で使えないんだよねー...

手続きダラダラ書いちゃうし、ちょっと違う似た機能コピペで量産しちゃうし、小さな変更で何箇所も修正が要るし

520

： 仕様書無しさん [sage] 2018/05/01(火) 16:38:21.55

>>516

馬鹿はお前だな
知らない人への説明で継承という言葉だけを
教えて理解しろなんて言わない

継承の親クラスというのは具体的にいうと
哺乳類や動物のことです。
ニワトリクラスであれば鳥類です

重要なのは、これだけで誰でも
容易に理解できるということ

対してエンジンや車は何を継承しているか？
説明してみせよ

521

： 仕様書無しさん [sage] 2018/05/01(火) 16:41:28.87

間違えて理解しそうなら、説明すればいいだけ。
わかりやすいものに例えてね

エンジンや車だとわかりやすい説明ができない

522

： 仕様書無しさん [sage] 2018/05/01(火) 18:04:17.51

スレの流れが長すぎて口出しにくいが…

エンジンという抽象クラスの派生クラスとしてロータリーエンジンだのディーゼルエンジンだのを考えれば良いんじゃないのかな
エンジンは自動車や発電機に搭載するためのメソッドを持ってて云々

523

： 仕様書無しさん [sage] 2018/05/01(火) 18:35:36.86

何を身近に感じるかなんて人それぞれだと思うが

524

： 仕様書無しさん [] 2018/05/01(火) 18:44:36.67

バカの特徴
例え話が好きすぎる
というか例えでしか世界を理解できない

525

： 仕様書無しさん [sage] 2018/05/01(火) 19:00:23.08

な
哺乳類クラスって有害だろ
種とクラスを混同して
OOPが理解できなくなる

526

： 仕様書無しさん [sage] 2018/05/01(火) 19:09:46.75

>>525

ほんとそれ

527

： KAC [sage] 2018/05/01(火) 19:10:16.34

>>522

外部仕様が変わる奴じゃ無いと教える為に分ける意味が薄いぞ？

>>525

何が有害なのか詳しく。
つか、お前さんがオブジェクト指向をまともに理解できないだけだろ？

528

： 仕様書無しさん [sage] 2018/05/01(火) 19:11:39.35

>>516

なにこのバカｗｗｗ

529

： 仕様書無しさん [sage] 2018/05/01(火) 19:12:10.27

>>525

俺はもう疲れたので詳しく

530

： 仕様書無しさん [sage] 2018/05/01(火) 19:12:53.36

>>528

バカにバカって言われたくねーよバーカ

531

： 仕様書無しさん [sage] 2018/05/01(火) 19:15:05.48

>>530

自己紹介おつ

532

： 仕様書無しさん [sage] 2018/05/01(火) 19:15:17.97

>>530

ばーか

533

： 仕様書無しさん [sage] 2018/05/01(火) 19:16:47.34

>>532

神クラス作ってオブジェクト指向やってるつもりになってろよバーカ

534

： 仕様書無しさん [] 2018/05/01(火) 19:19:23.66

おまえらみんな平等にバカですからケンカしないでねw

535

： 仕様書無しさん [sage] 2018/05/01(火) 19:22:42.79

>>527

生物種アナロジーでクラスを騙っている奴は
OOPを理解できてないよ

536

： 仕様書無しさん [sage] 2018/05/01(火) 19:30:44.68

蛇足だが別案すれば
祖先の形態を継承しつつ
環境に合わせてパーツを変えていく
進化モデルがOOPの実際に近いとおもうのだが

あんまり賛同してくれる人は居ないみたい

537

： 仕様書無しさん [sage] 2018/05/01(火) 19:59:16.53

分類と進化の系譜の両方とも有りな気がする

538

： 仕様書無しさん [sage] 2018/05/01(火) 21:06:03.20

オブジェクト指向が理解できないというのが理解できない
少し学べばすぐ実用的なプログラムをオブジェクト指向で書けるようになるっしょ

539

： 仕様書無しさん [sage] 2018/05/01(火) 21:07:28.80

>>538

それはお前が天才なだけ

540

： 仕様書無しさん [] 2018/05/01(火) 21:27:30.27

うむ、天才にしか理解できないオブジェクト指向は我々凡人とってはそこらにありふれた路傍の石にすぎんのだよ
それを理解しようなどと考える事がそもそもの間違いだという事に我々はもっと早く気がつくべきだった
オブジェクト指向などただ黙って右から左にうけ流せばよいのだ

541

： KAC [sage] 2018/05/01(火) 21:52:34.54

>>535

オブジェクト指向では
オブジェクトの何に注目するかは自由。

観点を否定するなら、それに足る理由が必要。

542

： 仕様書無しさん [sage] 2018/05/01(火) 21:59:18.22

生物種アナロジーでクラスを騙っている奴はOOPを
理解できてないよっていってまさか理由を求められるとは思わなかった。
そんなの感覚的にわかるだろ？
感覚的にわかることなんだから理由はいらない
それぐらいのレベルの話なのに、理由を説明しろとかセンスが無いよ

543

： 仕様書無しさん [sage] 2018/05/01(火) 22:03:10.51

>>522

> エンジンという抽象クラスの派生クラスとしてロータリーエンジンだのディーゼルエンジンだのを考えれば良いんじゃないのかな
そうなるやろ？
ロータリーエンジンは継承元のエンジンからなにを引き継いでいるのか？
詳しい人ならわかるのかもしれないが、普通はさっぱりだな。

> エンジンは自動車や発電機に搭載するためのメソッドを持ってて云々
エンジンは自動車、発電機の他、船、航空機、芝刈り機、などなどに
搭載するためのメソッドを持っていて・・・

ほら、神クラスになっちゃったｗ
こっちの方だよ、神クラスになるのは
自然な流れで証明できたじゃないかｗ

544

： 仕様書無しさん [sage] 2018/05/01(火) 22:04:34.28

対象重視型

545

： 仕様書無しさん [sage] 2018/05/01(火) 22:11:27.98

んー
じゃ哺乳類クラスを拡張して猫クラスを作って

546

： 仕様書無しさん [sage] 2018/05/01(火) 22:15:08.76

>>545

じゃああんたはエンジンと自動車の方をお願いね

547

： 仕様書無しさん [sage] 2018/05/01(火) 22:15:50.25

エンジンや自動車を拡張って無理だろｗｗｗ

548

： 仕様書無しさん [sage] 2018/05/01(火) 22:19:13.62

>>545

先に書いておくね

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66

>>413

有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる


class 哺乳類 {
　哺乳類の一般的な特徴
}

class 猫 extends 哺乳類 {
　猫特有の特徴
}

class アレ extends 哺乳類 {
　哺乳類だけど、哺乳類の一般的な特徴に当てはまらないものはここでオーバーライドする
}

549

： KAC [sage] 2018/05/01(火) 22:19:15.37

>>542

理由を説明できないからって誤魔化し始めるのは関心しない。

「お前の考え得る範囲では思いつかない」
と言うことだけは解ったが、
それは他人の設計を否定するものでは無い。

550

： 仕様書無しさん [sage] 2018/05/01(火) 22:20:33.98

>>549

生物種アナロジーでクラスを騙っている奴はOOPを
理解できてない

ここだけは認めろ
これは真理だ

551

： 仕様書無しさん [sage] 2018/05/01(火) 22:23:04.21

よくヤンキーが自動車を拡張してるな

552

： 仕様書無しさん [sage] 2018/05/01(火) 22:27:45.45

え？自動車を広くするの？俺もしたい

って勘違いされやすい。
やっぱりだめだなｗ

553

： 仕様書無しさん [] 2018/05/01(火) 22:27:56.72

なんだまたバカどもが藻掻きだしたなw

554

： 仕様書無しさん [sage] 2018/05/01(火) 22:29:06.33

バカどもへ
生物種アナロジーでクラスを騙っている奴はOOPを
理解できてない。これは真理だから理由を説明する必要はない

555

： 仕様書無しさん [] 2018/05/01(火) 22:30:33.44

>>554

おまえもやw

556

： 仕様書無しさん [sage] 2018/05/01(火) 22:38:13.26

>>551

> よくヤンキーが自動車を拡張してるな

自分だけのオリジナルアバターを作るような感じだと思うが
自動車の拡張は継承ではないな

557

： 仕様書無しさん [sage] 2018/05/01(火) 22:49:08.26

バカ「これが真理」


ワロタw

558

： 仕様書無しさん [sage] 2018/05/01(火) 23:08:45.44

もうファイルとかディレクトリとかでよくね？

559

： 仕様書無しさん [sage] 2018/05/01(火) 23:11:40.89

オリエント指向

560

： KAC [sage] 2018/05/01(火) 23:28:13.79

>>550

うん。
お前には理解できていない。

これだけは理解した。

561

： 522 [sage] 2018/05/02(水) 00:18:51.14

>>543

要は動力を提供するインターフェースだけなのにどうして神クラスってことになるんだか

あー、いやいや口出して悪かった。
こりゃ議論にならなそうだ。

562

： 仕様書無しさん [sage] 2018/05/02(水) 00:40:19.73

>>561

だからエンジンの例えがダメなんだってｗ
証拠あがってるじゃないか

エンジンはなんでも搭載できるわけじゃない
自動車に搭載するなら、自動車に登録するためのインターフェースが必要だし
船に搭載するなら、船に搭載するためのインターフェースがエンジンに必要

エンジンが全てのインターフェースを持っていたらそれは変なので
エンジンからは何も継承するものはない。継承なのになｗ

563

： 仕様書無しさん [sage] 2018/05/02(水) 06:34:06.21

エンジンに搭載インタフェース付けたらいいんじゃないの？
自動車や船にそれぞれの搭載の実装書いてエンジンはエンジンの仕事するだけ

564

： 仕様書無しさん [sage] 2018/05/02(水) 06:37:50.41

継承なんて使わないしな

565

： 仕様書無しさん [sage] 2018/05/02(水) 07:11:39.04

>>563

アダプターパターンの理解も深まっていいよね
やっぱりエンジンと車の方がわかりやすい

566

： 仕様書無しさん [sage] 2018/05/02(水) 07:14:14.15

生物種アナロジーでクラスを騙っている奴はOOPを理解できてないってのは本当に真実で

ものづくりの世界に生物を持ってきてはならないのだよ。

生物は誰に作られたか考えれば答えは自ずとわかるだろう。

567

： 仕様書無しさん [sage] 2018/05/02(水) 09:05:39.99

エンジンというクラスがあると、子はレシプロだのロータリーなど、
レシプロの子に直６だの水平対向だの、分類上は子ができるし、
意味的にメソッドの継承もできるけど、結局ハードとして別個体であって
独立したものだからソフトウェアとしてのOOPでは意味をなさないんだよね。
概念として継承できるけど実装としてそれは独立であり無価値。

568

： 仕様書無しさん [sage] 2018/05/02(水) 09:09:20.55

ところが解析的な要因特性で親子構造を構成した場合、共通部と独自部という
形で概念的な継承が意味を持つ。エンジンだとDRBFM的なものの見方をしたときには概念的な階層構造は省力化に大いに役立つ。

569

： 仕様書無しさん [sage] 2018/05/02(水) 09:18:18.60

>>567

同じ企画のネジが使えるのは、ネジの形が一緒だからだろ？
でもそれぞれのネジは別個体だ。

クラスってのはどこまでも企画であって、実態はインスタンスだろう？

何も問題ないじゃないか

570

： 仕様書無しさん [sage] 2018/05/02(水) 09:36:48.64

>>569

表現不能な個体差がある可能性のある物理的なものはOOPで表現できない

571

： 仕様書無しさん [sage] 2018/05/02(水) 09:42:56.67

>>569

問題はそこまでしか説明できないってこと
継承はどこに行ったね？

572

： 仕様書無しさん [sage] 2018/05/02(水) 09:52:41.99

>>570

何がいいたいのかよくわからなかった。

俺とお前のiPhoneは同じように見えて、お前のiPhoneは傷だらけだよ？
そんなことはプログラミングの世界では起こらないよね？だからてきかくではないよね？
って事がいいたいの？

どうぶつよりマシだと思うんだけど

573

： 仕様書無しさん [sage] 2018/05/02(水) 09:53:35.11

>>571

継承がどうした？流れが早くてわからん。何が知りたいの？

574

： 仕様書無しさん [sage] 2018/05/02(水) 09:54:02.30

>>569

厳密に同じにならない。
同じに見えるのは、同じに見える程度の薄っぺらい理解しかしていないから。

575

： 仕様書無しさん [sage] 2018/05/02(水) 09:55:22.21

>>574

ごめん君は犬派なの？車派なの？それともまた別なアレなの？

576

： 仕様書無しさん [sage] 2018/05/02(水) 09:55:29.02

>>573

ネジを使ってオブジェクト指向を説明するのが難しいって話
どうしても専門的な話になって普通の人にはピンとこない
犬や猫のように文字化な例を使って説明する方がいい
という結論に持っていきましょうｗ

577

： 仕様書無しさん [sage] 2018/05/02(水) 09:56:05.40

>>572

お前の持っているiPhoneもエンジンもプログラミングの世界で表現可能なものならばそうなのだろうな。

578

： 仕様書無しさん [sage] 2018/05/02(水) 09:58:59.48

本来は同じクラスでもインスタンスごとに属性が違ってる。
メソッドは同じだが属性は違うのが普通

同じ規格のネジの場合、全てのインスタンスの属性が同じに見えてしまう
どのネジでも同じように使えるから
メソッドが何に相当するのかもわからない

これでオブジェクト指向を説明するのは難しいな

579

： 仕様書無しさん [sage] 2018/05/02(水) 10:01:58.83

>>576

別に車とエンジンじゃなくても生物じゃなければいいんだ

>>567

が、子クラスが別個体だとか意味わかんないこと言うから
クラスってのは全部設計書であって個体はインスタンスだよね？って主張したくて
ネジの話を持ってきたが、すまん、余計にややこしくなったのでネジの話は忘れてくれ

580

： 仕様書無しさん [sage] 2018/05/02(水) 10:04:02.70

>>577

表現可能じゃん

VRの世界に存在するスマホの中でAndroidが立ち上がればいいんでしょ？

581

： 仕様書無しさん [sage] 2018/05/02(水) 10:52:15.12

哺乳類をどんなに拡張しても猫にはならない
なぜなら哺乳類は分類であってクラスじゃないから

DNAがクラス
生物はそのインスタンス
進化はDNAの継承

でOOPはスッキリ理解しましょうｗ。

582

： 仕様書無しさん [sage] 2018/05/02(水) 11:02:46.94

>>580

だから、それがお前が認識している表現可能なすべてであるなら、
それでいいんじゃない？
他の人はそうは思わないというだけのことだよ。

583

： 仕様書無しさん [sage] 2018/05/02(水) 11:07:02.84

>>581

クラスは分類であって拡張じゃないんだがｗ

584

： 仕様書無しさん [sage] 2018/05/02(水) 11:16:34.00

>>582

はいはい、逃げ乙

585

： 仕様書無しさん [sage] 2018/05/02(水) 11:20:36.22

VRでiPhoneを再現可能とか、進んでるなぁｗ

586

： 仕様書無しさん [sage] 2018/05/02(水) 11:21:53.96

>>585

しかもAndroidが立ち上がるらしいぞ

587

： 仕様書無しさん [sage] 2018/05/02(水) 11:41:52.87

>>585

>>586

大切なのはそれが可能である事が明確であることだよ
だからわかりやすいんじゃん。

生物はソフトウェアの世界に作れない。
もちろん、物質もソフトウェアの世界には作れないが近いものは作れる。それは、ゲームやったことある人ならわかるだろう？

588

： 仕様書無しさん [sage] 2018/05/02(水) 11:55:15.12

>>587

生物も物質も作れないよ、現在の技術じゃ
できると思っているならそれは傲慢だ

589

： 仕様書無しさん [sage] 2018/05/02(水) 11:59:28.80

>>588

ごめん、読み返してもらっていいかな？

590

： 仕様書無しさん [sage] 2018/05/02(水) 11:59:29.25

俺のiPhoneをVRの中にdeep copyすると寸分たがわず同じものが再現できるの？
同じものじゃないけど近いものならできるって？
それはお前が勝手に近いと判断しただけのまがい物だろ？って話だよねｗ

591

： 仕様書無しさん [sage] 2018/05/02(水) 12:00:16.20

>>590

iPhoneはソースが公開されてないから
アンドロイドにしてくれ

592

： 仕様書無しさん [sage] 2018/05/02(水) 12:01:59.99

オブジェクト指向じゃなくて技術崇拝だなこりゃ
マジキチ

593

： 仕様書無しさん [sage] 2018/05/02(水) 12:03:30.99

統失なんだろうな
自分と他者の境界が曖昧で「我思うすなわち真理」状態に入ってるんだよ

594

： 仕様書無しさん [sage] 2018/05/02(水) 12:05:34.51

叩くことでしか反論できないバカどもめ
ファーーーwww

595

： 仕様書無しさん [sage] 2018/05/02(水) 12:10:27.76

昼になったら変なのが増えたｗ
こんな日に出勤とは社畜の鏡だなｗ

596

： 仕様書無しさん [sage] 2018/05/02(水) 12:54:27.05

まとめるとこうかな。

�@
システムを設計するのは難しい。だから、わかりやすい解釈（例え）が人間には必要だ。特に初心者にはね！

�A
オブジェクト指向の例えとしてよく使われるのが動物や犬猫を使った話だ。これは一見わかりやすく思えるが、根っこに大きな罠があるため、アンチパターンとなる。

�B
犬猫の例えがダメな理由は、それが生物を使った例えだからだ。生物とは神の手によって創造されたものであり、人間には作れないものだ。人間に作れるものはカラクリであり、命を創造することはできない。

�C
よってオブジェクト指向の例え話は、生物を使わない例えを使用したほうが良い。その例えの候補は、エンジン、タイヤ、ハンドルを使った車の作成の例えである。（ほかにもっといい生物を使わない例があったら教えて）

というわけだ。

現実の猫と区別がつかない猫をVRの世界で作れたら、俺は負けを認める。

597

： 仕様書無しさん [sage] 2018/05/02(水) 13:00:27.30

現実と区別がつかないものを作るための技法じゃないんだよなぁオブジェクト指向って

598

： 仕様書無しさん [sage] 2018/05/02(水) 13:03:38.41

�@
システムを設計するのは難しい。だから、わかりやすい解釈（例え）が人間には必要だ。特に初心者にはね！

�A
オブジェクト指向の例えとしてよく使われるのが動物や犬猫を使った話だ。これは一見わかりやすく思えるが、
根っこに大きな罠があるため、アンチパターンとなる主張しているが、その罠もアンチパターンも示されていない

�B
犬猫の例えがダメな理由は、それが生物を使った例えだからだ。生物とは神の手によって創造されたものであり、
人間には作れないものだ。人間に作れるものは子供だけであり、セックス以外で命を創造することはできない。
同様に勇者、村人、モンスター、命あるものはソフトウェアで表現することはできない
最大の生物である惑星の地球シミュレータなんてもっての外だ。作れるのは神だけだ

�C
よってオブジェクト指向の例え話は、生物を使わない例えを使用したほうが良い。その例えの候補は、
エンジン、タイヤ、ハンドルを使った車の作成の例えである。エンジン、タイヤ、ハンドルは
ソフトウェアで作ることができる。3Dプリンタを使えば良いのだ。

599

： 仕様書無しさん [sage] 2018/05/02(水) 13:04:51.47

>>597

そうだよ、だから現実に存在する猫は作れないって話ししてんじゃん

600

： 仕様書無しさん [sage] 2018/05/02(水) 13:06:33.26

>>598

おまいはどっちの味方なんだww

601

： 仕様書無しさん [sage] 2018/05/02(水) 13:06:38.16

>>599

なんで現実に存在する猫を作らないといけないの？

602

： 仕様書無しさん [sage] 2018/05/02(水) 13:09:13.68

3Dプリンタ作ってもいいけどさ、
エンジンを作ることができるクラス設計
というものを見せてほしいんだが。

クラスにあるメソッドとプロパティはなにか？
それがあるとエンジンが作れるんだろう？

エンジンが作れるほどのクラスがあるとするなら
それは形と材料のデータの集まりでしかなく
ソフトウェアのクラスとしては使いものにならないと思うが？

603

： 仕様書無しさん [sage] 2018/05/02(水) 13:09:43.01

× 3Dプリンタ作ってもいいけどさ、
○ 3Dプリンタ使ってもいいけどさ、

604

： 仕様書無しさん [sage] 2018/05/02(水) 13:10:06.56

>>600

> おまいはどっちの味方なんだww
バカの見方ではないことは確実だなｗ

605

： 仕様書無しさん [sage] 2018/05/02(水) 13:10:39.71

>>601

それができたら「ソフトウェアの世界で生物を作れる」と考えてもいいことになり
オブジェクト指向の例えに犬猫を使ってもいいと思えるからだよ

606

： 仕様書無しさん [sage] 2018/05/02(水) 13:12:31.56

>>605

だからなんで、クラスの意味を教えるだけなのに、
生物を作らないといけないの？って話をしてるんだが

お前の理屈だとクラスの意味を教えるだけなのに
エンジンを作らないといけないってことになるんだが？

607

： 仕様書無しさん [sage] 2018/05/02(水) 13:13:40.24

ぶっちゃけ、オブジェクト指向だけで、
エンジンは作れないよ。

だってエンジンの材料は元をたどれば
全て神が作った物質だから

608

： 仕様書無しさん [sage] 2018/05/02(水) 13:16:11.10

>>606

？？？

何回も言ってるけど、おれが言ってるのはオブジェクト指向の例えで動物使うのって混乱の元だよね？って話だよ

車の例えは適当に言ったから、もっとわかりやすいのがあるかもしれないけど、有力なのが他に思いつかないから、生物を使わない例えの一例として言ってるのだよ。

実際、動物より車の例えのほうがいいでしょ。生物っていう作れないものを相手にしてないんだもん。諸悪の根源がなくなって明確だ

609

： 仕様書無しさん [sage] 2018/05/02(水) 13:18:39.17

実装がすでにある生物やエンジンから、逆にOOPの設計を起こそうとしたって
意図を完全に掌握しなければ完全な設計はできないんだよ。
それが神であれ他人であれ。
エンジンならできる気になっているのは知識が薄っぺらいからに他ならない。
なので、いまあるものをOOPで表そうとしている時点で不可能なことに挑んでいる。

あくまで自分で設計し掌握しているものを記述するのがOOP。
ここをはき違えるとエンジンなら再現可能みたいな馬鹿なことを言い出す。

610

： 仕様書無しさん [sage] 2018/05/02(水) 13:19:19.04

>>607

それは認めてるって。ソフトウェアの世界は全て実体がないんだから。

611

： 仕様書無しさん [sage] 2018/05/02(水) 13:24:47.92

>>609

言ってる事がめちゃめちゃだよww

エンジンを設計したのは人間だ。
オブジェクト指向を使ってアプリを設計するのも人間だよ。

土俵は違うけど、これは設計できる（作れる）ってことじゃん。

おれが言ってるのは人間が作れないものを持ってくるなって話。

612

： 仕様書無しさん [sage] 2018/05/02(水) 13:26:28.18

オブジェクト指向だけじゃネジすら作れない。

ネジのクラスか属性になるかは置いといてピッチ（ネジのギザギザ）の幅を
情報として持たせる必要があるだろう。でも単にM6（ネジ山の間隔が1.0mm）と
もたせた所で、ここから3Dプリンタでネジが作れるわけじゃない

3Dプリンタでネジを作ろうと思ったらCADデータが必要
そのデータはクラスの持ってる属性とはまったく別物になるだろう。
ピッチという情報もいらない。形情報があれば済むことだから

つまりオブジェクト指向でクラスに持たせるための情報というのは
現実のものを表現したものではなく、人が持ってる"概要"でしかない。
概要から実際のネジなどの物質が作れないの当然の話

だから動物の場合でも、DNAをクラスの中に持たせるっていうのは
CAD情報をクラスの中に持たせるのと同じで意味不明な理屈
動物の場合でも概要であれば、クラスに持たせられる。

クラスというのは、DNAやCADデータじゃないのだよ

613

： 仕様書無しさん [sage] 2018/05/02(水) 13:27:59.92

>>611

おまえエンジン自力で作れるつもりなの？
そこまで究極の馬鹿だったんか？

614

： 仕様書無しさん [sage] 2018/05/02(水) 13:29:48.13

>>613

「頑張れば作れる」と「頑張っても作れない」の違いは、大差がないとでも言いたいの？

615

： 仕様書無しさん [sage] 2018/05/02(水) 13:30:34.58

>>612

なかなか好感もてた

616

： 仕様書無しさん [sage] 2018/05/02(水) 13:32:26.63

>>609

> 実際、動物より車の例えのほうがいいでしょ。生物っていう作れないものを相手にしてないんだもん。諸悪の根源がなくなって明確だ

なんで人間が作れるのかどうかが焦点になってるのか分からんのだが？

人間が作れようが作れまいが、それをソフトウェアで表現するのがクラスだよ。
あくまで表現。実際に作れって話じゃない。実際に作る話だとクラスからじゃ無生物も作れない

オブジェクト指向の設計というのは、すでにあるなにかをオブジェクト指向で表現すること
つまりオブジェクト指向よりも前に、表現したい何かはすでに存在しているということ

だから、人間が作るよりも前に存在している生物は「すでに存在している」ということを
満たしており、むしろ生物の種別をどのように分類するかという試行錯誤が
オブジェクト指向の設計の試行錯誤に近く、よりたとえとして適切

エンジンやネジなんかに例えると、お前がすでに勘違いしているように、このクラスから
実際にエンジンやネジを作れなければならないという話になって、すでにある物の表現ではなく
CADデータの作成の話になってしまう。クラスからエンジンやネジを作れないといけないという話になってしまう

617

： 仕様書無しさん [sage] 2018/05/02(水) 13:34:12.24

>>614

現時点で作れないだろ？
お前にとって、エンジンを完全に掌握した他人はエンジンに関しては神にも等しい存在だろ？
できる存在がいることと、お前がそれを設計できることを混同するなよ。
その意味で「大差はない」が答えだ。

618

： 仕様書無しさん [sage] 2018/05/02(水) 13:36:00.71

あー馬鹿の相手は疲れるなぁ。
設計から生まれていないものを設計に帰することができるのは神だけだよ。

619

： 仕様書無しさん [sage] 2018/05/02(水) 13:37:08.44

エンジンは経験から生まれたもので設計から生まれていない、ってのは常識。

620

： 仕様書無しさん [sage] 2018/05/02(水) 13:37:16.84

あー馬鹿の相手は疲れるなぁ。
CADによる設計から生まれたものなら、CADによる設計に帰することができるんだよ
クラス設計ではなくCADの設計な

621

： 仕様書無しさん [sage] 2018/05/02(水) 13:37:22.13

>>616

なるほどね

622

： 仕様書無しさん [sage] 2018/05/02(水) 13:42:03.05

こいつはCADの設計とクラスの設計をごっちゃにしてるってことでFAだなｗ

623

： 仕様書無しさん [sage] 2018/05/02(水) 13:43:53.97

まともに読んでないからこいつが誰なのかわからないけど、
喩え話が下手な奴に喩え話をさせてはいけない、ってのは
よくわかる。

624

： 仕様書無しさん [sage] 2018/05/02(水) 13:46:28.14

>>616

プログラミングはものづくりだから、作りたいものがプログラミングによって作れるかどうかは大切だと思ってるんだけど違うの？

あと、実際に作れなんて話、俺してないからね！クソッタレが3Dプリンターとか言い出したせいで、流れがおかしくなったけど、今まで俺が話してきた「作る」って意味は「実体なき存在としてソフトウェアの世界に作る」って意味に決まってんじゃん。

クラスが表現って話は面白いので、もっと語ってくれ

625

： 仕様書無しさん [sage] 2018/05/02(水) 13:46:52.29

>>622

だから俺じゃねーから！！

626

： 仕様書無しさん [sage] 2018/05/02(水) 13:48:14.02

たのむから

>>596

を読んでくれ

627

： 仕様書無しさん [sage] 2018/05/02(水) 13:49:57.70

>現実の猫と区別がつかない猫をVRの世界で作れたら、

こんなことを言っている時点で何も理解していない感が。

628

： 仕様書無しさん [sage] 2018/05/02(水) 13:51:01.71

>>627

なぜ何も理解していない感を感じるのか詳しく。
人を馬鹿にしたお前には答える義務がある。

629

： 仕様書無しさん [sage] 2018/05/02(水) 13:51:17.98

>設計から生まれていないものを設計に帰することができるのは神だけだよ。

これが真理だろ

630

： 仕様書無しさん [sage] 2018/05/02(水) 13:52:02.62

>>624

> プログラミングはものづくりだから、作りたいものがプログラミングによって作れるかどうかは大切だと思ってるんだけど違うの？

その場合の「もの」とはソフトウェアであって、
現実にある物体ではありません。

> 「実体なき存在としてソフトウェアの世界に作る」って意味に決まってんじゃん。
え、なに？ CADソフトを使ってエンジンやネジを設計するの？

それクラス設計じゃないよねｗ
クラス設計というのは、実体があろうがなかろうが人間が作ろうが神が作ろうかは関係なく
何かを人間が捉えている形に近い形で簡潔に表現しただけのものです。
人間が捉えられてるものなら、生き物だってクラス設計できます。

631

： 仕様書無しさん [sage] 2018/05/02(水) 13:52:45.44

>>628

一人でVRVR騒いでなにやってんの？

632

： 仕様書無しさん [sage] 2018/05/02(水) 13:53:05.14

>>626

それは前提が間違ってるので的外れ。

クラス設計は、シミュレータではない
ネジのクラス設計は、CADでネジそのものを作ることではない

633

： 仕様書無しさん [sage] 2018/05/02(水) 13:53:26.06

>>627

VRなんて言ってんのCAD厨のお前だけじゃんｗ

634

： 仕様書無しさん [sage] 2018/05/02(水) 13:53:55.84

>>630

だからCADの話やめてくれない？言い出したの俺じゃないから

635

： 仕様書無しさん [sage] 2018/05/02(水) 13:53:58.60

な？ 俺が最初にかいたとおりになったろ？

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66

>>413

有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる

636

： 仕様書無しさん [sage] 2018/05/02(水) 13:54:14.04

>>629

哲学的表現で煙に巻こうとしても逃げられないよ？ｗ

637

： 仕様書無しさん [sage] 2018/05/02(水) 13:54:55.59

だからCADなんてひとこともいってねー！！！
もうおまえらばか！！ばか！！このわからずや！！

638

： 仕様書無しさん [sage] 2018/05/02(水) 13:55:26.09

>>634

じゃあお前はVRの話止めてくれない？

>>596

の↓な
> 現実の猫と区別がつかない猫をVRの世界で作れたら、俺は負けを認める。

639

： 仕様書無しさん [sage] 2018/05/02(水) 13:55:43.81

>>637

お前のレスの先頭から4文字目〜6文字目をよく見るといい。

640

： 仕様書無しさん [sage] 2018/05/02(水) 13:55:56.33

>>638

いや、VRはいったよ。別に弁解もないよ

641

： 仕様書無しさん [sage] 2018/05/02(水) 13:56:38.47

>>639

子供か

642

： 仕様書無しさん [sage] 2018/05/02(水) 13:57:22.17

>>637

CADの話になってるって自分で気づいてないのか？

現実のネジと区別がつかないネジをVRの世界で作るには
CADデータが無いと作れないだろ。

ネジという概念を表すだけのものを作るというのなら
それは犬や猫でもできることだ

643

： 仕様書無しさん [sage] 2018/05/02(水) 13:57:54.57

>>630

しかまともな回答してくれないよ。
ちょっと疲れたから後で返信する

644

： 仕様書無しさん [sage] 2018/05/02(水) 13:58:28.80

>>642

ネジはやめろといっただろ

645

： 仕様書無しさん [sage] 2018/05/02(水) 13:58:33.81

>>641

一言も言っていないというから、そうではないことを示しただけだが？
謝れよ。

646

： 仕様書無しさん [sage] 2018/05/02(水) 13:58:42.62

> 現実の猫と区別がつかない猫をVRの世界で作れたら、俺は負けを認める。

VRのサメとかあるけどなｗ

647

： 仕様書無しさん [sage] 2018/05/02(水) 13:59:08.75

>>645

うるせーガキ

648

： 仕様書無しさん [sage] 2018/05/02(水) 13:59:11.44

>>644

> ネジはやめろといっただろ

なぜ？ ネジは神が作ったものだからかい？ｗ

649

： 仕様書無しさん [sage] 2018/05/02(水) 14:00:38.13

>>646

そのサメはどっちかっていうと遊園地のアトラクションとかのサメだろ。
本物のサメとは違う。人間が作ったものは全てカラクリなんだよ

650

： 仕様書無しさん [sage] 2018/05/02(水) 14:02:27.49

>>648

うるさいなww

ネジの話は、サブクラスが実体だみたいなこと言う奴がいたから、インスタンスが実体でしょ？っていうのをわかりやすく説明しようとして失敗しただけ。

もうネジの話はおしまい。

651

： 仕様書無しさん [sage] 2018/05/02(水) 14:02:40.48

エンジンでも一緒だよな。現実の世界と区別がつかないエンジンを
VRの世界で作るなら、エンジンのCADデータと高度な物理演算機能を
搭載したシミュレータが必要

そこにVRゴーグルつけた俺がエンジンを手にして、
その重さと臭いを感じられるようにするには・・・
まだまだいろいろ足りないな。


で、クラス設計の話とはまったく違う話になったなｗ

652

： 仕様書無しさん [sage] 2018/05/02(水) 14:03:27.86

>>649

> そのサメはどっちかっていうと遊園地のアトラクションとかのサメだろ。
> 本物のサメとは違う。人間が作ったものは全てカラクリなんだよ

故に、人間が作ったエンジンはカラクリですね

653

： 仕様書無しさん [sage] 2018/05/02(水) 14:04:17.77

>>652

そのとおり、やっと分かってくれたか

654

： 仕様書無しさん [sage] 2018/05/02(水) 14:06:03.77

>>653

おや？ だからクラスで生物もエンジンなどの人間が作ったものも
表現することはできないって話なんだが、
そうかやっと分かってくれたかｗ

そうだよな。生物だとDNAに相当するCADデータがないと
VRの世界で本物そっくりのものは作れないしな

655

： 仕様書無しさん [sage] 2018/05/02(水) 14:08:00.86

まとめ

生物を作るには生物の設計図であるDNA
機械を作るには機械の設計図であるCADデータ
が必要だが、

クラス設計というのは、それら実際にあるものを人間が
どう捉えているかを表現するものなので、
生物でも機械でもクラス設計を行うことはできる

656

： 仕様書無しさん [sage] 2018/05/02(水) 14:08:46.44

クラスを初心者にわかりやすく説明するなら、
身近な例である犬猫で表現したほうが良いってことだな

657

： 仕様書無しさん [sage] 2018/05/02(水) 14:17:37.47

>>651

もうつかれたよ。

現実世界にエンジンの生成マシンがあったら
ボタンを押せばエンジンは作れるよね？

これをプログラミングの世界に持ってくると
クラスはエンジン生成マシンと言えるし
実体を作るにはnewすればいい。

わかりやすいでしょ？

でも猫はどお？猫生成マシンなんて現実にはないし
newボタンを押して命を人間が創造するなんて聞いたこともない

だから猫を作ったときは、それは猫型ロボット、つまりドラえもんってことさ、うんこうんこ

658

： 仕様書無しさん [sage] 2018/05/02(水) 14:22:46.89

>>657

だから現実世界のシミュレータを作ろう！って
話なんかしてないんだって

仮想世界の猫は、仮想世界の猫生成ボタンで作れる
地面に魔法陣かいて、悪魔召喚することで悪魔を
newできる仮想世界で何を言ってるんだ？

659

： 仕様書無しさん [sage] 2018/05/02(水) 14:22:50.89

エンジン推しの言いたいことはわかる。共感はしないけど。

逆に、犬猫で理解できない奴は抽象化ができないってことで、オブジェクト指向に向いた考え方ができるかどうかのふるいになりそうだね。

660

： 仕様書無しさん [sage] 2018/05/02(水) 14:24:22.73

>>658

その猫は猫型ロボットであり、猫ではない

661

： 仕様書無しさん [sage] 2018/05/02(水) 14:24:52.52

>>657

現実にはない猫生成マシンを
仮想世界には作ることができる。

現実に作れないものは仮想世界にも作れないという
思い込みをしてしまうから、その説明は害悪

662

： 仕様書無しさん [sage] 2018/05/02(水) 14:26:14.12

>>661

なるほど、たしかに。

でも作れない動物を作れると思わせる例も同時に害悪だろう

663

： 仕様書無しさん [sage] 2018/05/02(水) 14:26:35.78

>>660

> その猫は猫型ロボットであり、猫ではない
当たり前でしょｗ

ソフトウェアで表現したものは猫でもネジでも
本物ではない。本物でなくていいんだよ？

本物でなければならないという思い込みを
してしまってるので、お前はすでに勘違いの
度合いが極限まで進んでしまってる

664

： 仕様書無しさん [sage] 2018/05/02(水) 14:27:54.57

>>662

> でも作れない動物を作れると思わせる例も同時に害悪だろう

テレビの中にいる人間は、本物だと思いこんでいる人？

変だな。誰もソフトウェアの中にいるネジが本物だと
思ってる人はいないはずだがｗ

お前、すでに頭がおかしくなってるよ
現実と想像の区別がつかなくなってるよ。

665

： 仕様書無しさん [sage] 2018/05/02(水) 14:28:01.92

>>663

だって「オブジェクト指向は現実をそのままソフトウエアに表現する」とか意味わかんない解説よくされるし

666

： 仕様書無しさん [sage] 2018/05/02(水) 14:28:49.54

>>664

人のことを糖質みたいに言うなww

667

： 仕様書無しさん [sage] 2018/05/02(水) 14:29:44.24

ツリーっていうデータ構造があるけど、図解するときは決まって頂点がルートで、リーフは下方向に広がっている
本物の木はそういう構造をしてないから、ツリーという名前もしくは図解の仕方は害悪
初心者の理解を妨げてる

668

： 仕様書無しさん [sage] 2018/05/02(水) 14:30:00.73

>>665

されてないよ

669

： 仕様書無しさん [sage] 2018/05/02(水) 14:31:12.16

>>668

え、うそ？されてるでしょ

670

： 仕様書無しさん [sage] 2018/05/02(水) 14:33:26.12

>>665

> だって「オブジェクト指向は現実をそのままソフトウエアに表現する」とか意味わかんない解説よくされるし

あ「表現」という言葉の意味がわかってないのね。

ttps://yuuma7.com/ラリベラの岩窟教会群を歩いて観光してみた感想/
> ゴルゴタ聖堂（ベテ・ゴルゴタ）
> ラリベラ王の墓所だったともいわれるのがゴルゴタ聖堂だ。その名の通り、
> イエス・キリストが処刑された地を想って造られた教会で、
> 角ばった建造物には形の違う窓が3つあり「三位一体」を、
> ｂｭりぬかれたクャ鴻Xは「キリスャg」を表現してｂ｢る。

はい、くりぬかれたクロスは「キリスト」を表現していますが、
くりぬかれたクロスは「キリスト」なのでしょうか？

違いますね。「表現」とは本物でも本物を再現することでもありません。
「表現」しているだけです。

671

： 仕様書無しさん [sage] 2018/05/02(水) 14:34:54.54

>>670

ソフトウェア自体が実態の出さないものだから全て表現だわな

672

： 仕様書無しさん [sage] 2018/05/02(水) 15:30:38.86

>>667

作業の都合上の理由で上下が逆になってるだけで同じ構造では？

673

： 仕様書無しさん [sage] 2018/05/02(水) 16:04:07.98

＞クラスは分類であって拡張じゃない

犬猫モデルの犠牲者がここにも

674

： 仕様書無しさん [sage] 2018/05/02(水) 16:39:06.74

>>673

なんか言えよｗ

675

： 仕様書無しさん [sage] 2018/05/02(水) 18:14:09.43

クラスは類なんだよなぁ

インスタンスはクラスを拡張してるわけじゃないんだよなぁ

676

： 仕様書無しさん [sage] 2018/05/02(水) 20:33:11.74

ネコ型ロボットはどちらになりますか？

677

： 仕様書無しさん [sage] 2018/05/02(水) 20:38:46.35

>>676

文脈次第
ネコ型ロボットをプログラム中でどう扱いたいかによる
そういう質問が出てくるのはオブジェクト指向を理解できていない証拠

678

： 仕様書無しさん [sage] 2018/05/02(水) 20:40:32.07

AIBOはどうでしょうか？

679

： 仕様書無しさん [sage] 2018/05/02(水) 20:46:50.11

>>678

エンジンと同じ扱いでどうでしょうか？

680

： 仕様書無しさん [] 2018/05/02(水) 21:38:58.45

>>675

クラスはクラスやな
バカはホンマに例えが好きなんやなあw

681

： 仕様書無しさん [sage] 2018/05/02(水) 21:40:05.74

クラスがわからない人への説明で、クラスはクラスで終わってどうするｗ
前提が分かってない

682

： 仕様書無しさん [] 2018/05/02(水) 21:41:28.22

>>681

未知の概念は何かに例えて理解できるものではないんやなあw
バカは例えで曲解するけどw

683

： 仕様書無しさん [sage] 2018/05/02(水) 21:48:58.61

頭で考えて理解出来るものでもないな
ある日突然悟るものだし

684

： 仕様書無しさん [sage] 2018/05/02(水) 22:03:15.81

> 未知の概念は何かに例えて理解できるものではないんやなあw

理解できるだろ？
何を言ってるんだろうか？

685

： KAC [sage] 2018/05/02(水) 22:03:46.43

>>680

それ以上説明できないってのは
内容を正しく理解できていないって事。

686

： 仕様書無しさん [sage] 2018/05/02(水) 22:05:59.13

元彼がなんというかものの例えが
理解出来ない人だった。


具体的に言うと
福山雅治のスコールという歌が私は好きでよく聞いてたんだけど
その歌が
「汗をかいたアイスティーと
取りすぎたポラロイド写真」
って歌詞から始まるんだけど元彼が聞くたびに
「アイスティーが汗かくわけないじゃんwwwwww」と失笑する。
最初はスルーしてたけどあまりにも
何度も言うからくどいなと思って
いや、机に置いてあるアイスティーの氷が溶ける程長くその場にいたとか
夏の暑さの表現でしょ。と言っても

「でもアイスティーは無機物だから汗かかないから日本語おかしいじゃん？｣

とこちらをバカにしたように言ってきたり、その他にも歌詞とか宣伝の
「まるで〇〇のような〜」とか「××みたいな〜」とかの例え話に
「いや、でもそれは〇〇とか××とは違うじゃん。俺現実主義者だから」
と真顔で言い始めたので
この人本当に例え話が理解出来てないんだ、と思ったら冷めた。
現実主義者とは全く意味が違うのにそれも理解してなかった。

687

： 仕様書無しさん [] 2018/05/02(水) 22:12:31.97

>>684

そら例えは理解できるやろwそれを曲解と言うとるんやなあw

688

： 仕様書無しさん [] 2018/05/02(水) 22:18:06.04

>>686

よく見たらおまえ例えもわかっとらんやんw

689

： 仕様書無しさん [sage] 2018/05/02(水) 22:18:18.15

自分にとってデメリットしか無いのに
なぜ素直に受け取らないで曲解するの？

もしかして「曲解」の意味もわかってない？
「表現」の意味も知らなかった人と同じかな

> きょっ‐かい〔キヨク‐〕【曲解】
>
> ［名］(スル)物事や相手の言動などを素直に受け取らないで、ねじまげて解釈すること。

690

： 仕様書無しさん [sage] 2018/05/02(水) 22:22:18.76

>>688

それコピペだよ♪

691

： 仕様書無しさん [] 2018/05/02(水) 22:26:07.47

>>690

なんやwあまりにもおまえらっぽすぎてガチやと思ったわw

692

： 仕様書無しさん [sage] 2018/05/02(水) 22:29:09.90

>>691

こんなものに引っかかったのか
マヌケだな

693

： 仕様書無しさん [] 2018/05/02(水) 22:31:19.10

>>692

でもおまえも例えすらわかっとらんのやろw

694

： 仕様書無しさん [sage] 2018/05/02(水) 22:32:52.70

>>693

じゃあ例えの意味言ってみ

695

： 仕様書無しさん [] 2018/05/02(水) 22:35:24.65

>>694

なんでこのタイミングでいきなり命令口調やねんwそもそもがアホやんおまえw

696

： 仕様書無しさん [sage] 2018/05/02(水) 22:36:56.07

例え話の効果はかなり高いからなぁ
多分うまいたとえ話に嫉妬してるんやろう

697

： 仕様書無しさん [sage] 2018/05/02(水) 22:38:56.15

クラスを犬や猫に例えるのは
わかりやすいし確かに良い例えだよね

698

： 仕様書無しさん [sage] 2018/05/02(水) 22:53:09.34

犬やネコを見たことない人には不適切だな
やはり食い物がいいよ

699

： 仕様書無しさん [sage] 2018/05/03(木) 02:11:10.62

でも、犬クラスも猫クラスも派生クラスだけどな。

700

： 仕様書無しさん [sage] 2018/05/03(木) 09:50:29.16

モデリングの意味も知らない奴が「例え話」とか言って誤魔化すから余計意味不明になる。

701

： 仕様書無しさん [sage] 2018/05/03(木) 11:54:02.45

>>699

うーん、50点

702

： 仕様書無しさん [sage] 2018/05/03(木) 11:59:12.12

>>699

ある人が考えた設計が、生物学的に正しい必要はないわけで、
トカゲクラスが犬クラスの派生でも、別に構わないんだけどね。
納得させられるだけの理由があれば。

Personクラスを設計した時に、親クラスに猿人クラスを
設計しないだろ？設計で問われるのは主体がなんなのかということだ。

703

： 仕様書無しさん [sage] 2018/05/03(木) 12:12:17.19

>>702

お前のモデリングセンスどうなってんの？
なんでPersonを抽象化したら猿人になんの？

704

： 仕様書無しさん [sage] 2018/05/03(木) 13:25:59.67

>>703

なんでPersonを抽象化したら猿人になんの？なんて言ったの？

705

： 仕様書無しさん [sage] 2018/05/03(木) 13:35:35.91

person is-a 猿人

706

： 仕様書無しさん [sage] 2018/05/03(木) 13:42:22.89

ほらね、こう言う事が起きるから生物は使うべきじゃないんだよ

707

： KAC [sage] 2018/05/03(木) 13:45:45.70

自動車とか言いだしたから猿人が出てきたんだろう。。。

708

： 仕様書無しさん [sage] 2018/05/03(木) 13:52:31.02

>>707

(ﾟДﾟ)ﾊｧ?

709

： 仕様書無しさん [sage] 2018/05/03(木) 13:54:24.82

自動車の基底クラスは馬車

710

： 仕様書無しさん [] 2018/05/03(木) 13:55:33.19

なんや結局おまえら形を変えた美少女うんこ問題をやりたいだけなんやろw
素直になれやw

711

： 仕様書無しさん [sage] 2018/05/03(木) 13:55:33.98

>>706

> ほらね、こう言う事が起きるから生物は使うべきじゃないんだよ

は？ Personクラスを設計した時に、親クラスに猿人クラスを
設計しないだろ？
当たり前過ぎて、親クラスに猿人クラスを設計しないだろ？

このように間違った設計をしないから、
生物を使ったほうがわかりやすいって話なんだが。

なんでオマエは勘違いしたの？
それはオマエの頭の問題だよね？
そうかオマエは親クラスを猿人クラスにするんだーｗ

712

： 仕様書無しさん [sage] 2018/05/03(木) 13:56:17.36

>>708

円陣といえばわかるか？

713

： 仕様書無しさん [sage] 2018/05/03(木) 14:04:10.08

でもこの恥ずかしい間違いのおかげで

>>702

は学ぶことができた

だが俺はなにも得ていない
もうこのスレで時間を無駄にするのはやめるわ

じゃあの

714

： 仕様書無しさん [sage] 2018/05/03(木) 14:17:05.97

>>自動車の基底クラスは馬車
これが正しい認識

>>自動車の基底クラスは車両
は間違った認識

715

： 仕様書無しさん [] 2018/05/03(木) 14:42:25.62

>>美少女の基底クラスは人間
これは正しいのか？

716

： 仕様書無しさん [sage] 2018/05/03(木) 14:53:47.01

自動車の基底クラスは馬車
自動車の基底クラスは車両

こういう間違った解釈をするから
自動車はたとえとして不適切なんだよな

717

： 仕様書無しさん [sage] 2018/05/03(木) 17:12:48.22

ここは底辺連中が程度の低いところでお互いにマウント取り合おうとしてるスレですね

718

： KAC [sage] 2018/05/03(木) 17:21:12.75

>>715

美少女とは違うが、
>アイドルの基底クラスは人間
これを誤りだと主張する奴は少なからず居る

719

： 仕様書無しさん [sage] 2018/05/03(木) 17:34:55.87

>>718

それはアイドルが人間かどうかじゃなくて
アイドルはクラスとすべきかって話だよ

ゲームのジョブみたいに一つしか選べないならクラスで良いかもしれないけど
現実には、アイドル 兼 農家 兼 ロリコン という職業もあるわけだし
まあ多重継承するって手もあるけどさ

720

： 仕様書無しさん [] 2018/05/03(木) 18:06:01.27

自転車と自動車があるだろ、どっちもタイヤがあるだろそれならこれを抽象化して呼び出したときに画像だけ変えてコード量を減らそうとかな
共有できる処理は基本クラスにして継承してから独自のはここで書き足せば綺麗に楽にするということ

721

： 仕様書無しさん [sage] 2018/05/03(木) 18:33:26.55

画像だけ変えるのにわざわざ別のクラスにすんなよ

722

： 仕様書無しさん [sage] 2018/05/03(木) 18:37:35.43

>>720

ゲームならそれでいいが、俺達が住んでるのはゲームの世界じゃない
現実世界だ。現実世界で自転車と自動車で共通する処理なんて無いぞ。
自転車と自動車の違いは画像だけじゃないからな
現実世界と同じように表現できるのがオブジェクト指向だろう

723

： 仕様書無しさん [sage] 2018/05/03(木) 19:02:22.85

オブジェクト指向って現実世界を表現できるの？
すげー

724

： 仕様書無しさん [] 2018/05/03(木) 19:24:29.29

>>719

全然違う
うんこをしないのに排便メゾットを持つべきかって話だよ

725

： 仕様書無しさん [sage] 2018/05/03(木) 19:38:30.30

>>724

その話は潰したはずだが？

726

： 仕様書無しさん [] 2018/05/03(木) 20:41:22.28

>>725

おれにはずっと美少女うんこ問題をあつかっとる様にしか見えんがw

727

： 仕様書無しさん [] 2018/05/03(木) 21:23:46.95

だから、キャットドア課題をなんとかしろよ、お前らは。

728

： 仕様書無しさん [sage] 2018/05/03(木) 22:17:38.96

ほらな。他のたとえを使うと

>>726-727

のような意味不明な展開になる。

クラスは犬猫で例えたほうが判り易いやろ？

729

： 仕様書無しさん [sage] 2018/05/03(木) 22:57:02.61

>>728

いや全然。
プロセス指向からの切り替えだって事説明出来ないまま、犬猫とか出しても有害なだけ。

730

： 仕様書無しさん [sage] 2018/05/03(木) 22:58:36.93

じゃー、説明すればいいだけじゃないですかねー、またわかりやすい例えでー

731

： 仕様書無しさん [] 2018/05/04(金) 00:20:25.97

オブジェクト指向の話をすると、なんで継承の話がメインなんの？

732

： 仕様書無しさん [] 2018/05/04(金) 00:20:59.32

>>727

ラッカー乙

733

： 仕様書無しさん [sage] 2018/05/04(金) 00:22:50.14

それが一番よく使われるからじゃないですかねー

734

： 仕様書無しさん [] 2018/05/04(金) 00:59:26.21

継承って密結合になるからフレームワーク使う側なら継承あんま使わなくね？

735

： 仕様書無しさん [] 2018/05/04(金) 01:00:44.62

オブジェクト指向の本質はオブジェクト同士が協調し合って事を成し遂げるところにあるのであって、継承って二の次三の次だろ

736

： 仕様書無しさん [sage] 2018/05/04(金) 01:15:27.22

継承が話題になるのは、有効活用するのが難しいからでしょうね
データとそれに対する操作をオブジェクトとしてまとめるというのは、誰にでも理解できるから

737

： 仕様書無しさん [sage] 2018/05/04(金) 06:13:42.41

>>735

そうそう、もともとはオブジェクトがメッセージをやり取りし合うって概念だしね。
究極を求めるとErlangこそが真のオブジェクト指向であるという噂だし。

738

： 仕様書無しさん [sage] 2018/05/04(金) 07:27:26.03

>>736

継承で注意が必要なのは、diamond継承などの矛盾解決や、継承のonoffコントロールの癖だね。
言語によっては、継承に似た別機構で問題を回避してるものもある（Rubyのmixinなど）。

739

： 仕様書無しさん [sage] 2018/05/04(金) 07:34:28.59

>>737

実装はそのとおりだけど、更に何故オブジェクト指向が必要になったかと言うと、理由の一つは「システム稼働中の動的入替え」を出来るようにしたかったから。
Erlangは、連続運転の世界規模通信システムを想定していたので、動的入替えの仕掛けを標準で持っている。

740

： 仕様書無しさん [sage] 2018/05/04(金) 10:29:35.73

最初の頃は、継承をどんどんしろ、
だったのが、今は、継承を使うな、
がセオリーだったか？
やれと言われたり、やるなと言われることが変わりすぎて
わけ分からなくなってるのがオブジェクト指向。

741

： 仕様書無しさん [] 2018/05/04(金) 11:21:51.39

>>740

そんなセオリー有ったかな？
バズワードで購読数稼ごうとしてる孫引き解説記事ではそういう文言見たことあるけど。
継承がどの程度必要かが事前にわかるのは、ルーチンワークを機械化するときくらい。
今時のプロジェクトは大抵は、途中で構成の見直しが必要になる。
なので、継承の構造自体を変える訳だが、期待通りに変わったかどうかのチェックは自動テストで確認するってのが多い。

742

： 仕様書無しさん [sage] 2018/05/04(金) 12:18:50.16

> 今時のプロジェクトは大抵は、途中で構成の見直しが必要になる。
> なので、継承の構造自体を変える訳だが、

意味不明

743

： 仕様書無しさん [] 2018/05/04(金) 12:36:18.62

web限定の話やろw

744

： 仕様書無しさん [sage] 2018/05/04(金) 12:50:34.64

web業界が一番進んでるからね。
最新の手法が採用されるのはweb業界

745

： 仕様書無しさん [] 2018/05/04(金) 12:59:33.16

>>742

ルーチンワークの機械化で済む仕事は減ってきてるからね。
ここ20年くらいのコンピュータ利用ってのは、OA化。
つまり過去数世紀に渡ってやってきた事務作業の機械化だった訳だが、それもほぼ一巡してしまった。
新しい事を試みようとすると、「やってみるまではよく分からない」部分が多いので、ある意味割り切って、途中で構成変更出来るように考えておく。

746

： 仕様書無しさん [sage] 2018/05/04(金) 13:42:19.34

どんな仕事でもある程度はやってみなければわからない部分があるが、アホほど見通せる範囲が狭い
不確実性を言い訳にちんたらやってる奴は、少しでも遠くを見渡せるようにスキルアップしてほしい

747

： 仕様書無しさん [sage] 2018/05/04(金) 14:26:48.66

見通せるって豪語してる連中はよくいるけど、見通した気になってるだけの奴が大半

748

： 仕様書無しさん [sage] 2018/05/04(金) 14:39:04.77

不確実性うんぬん言ってる奴はよくいるけど、大して新規性もないのに応用力のなさゆえに
新しい問題に見えてしまってるだけの奴が大半

749

： 仕様書無しさん [sage] 2018/05/04(金) 14:48:15.91

まあ俺は20年前にインターネット時代が来ることも
10年前にスマホ時代が来ることも予想していたし、
10年後がどうなっているかも確実に見通してる

750

： 仕様書無しさん [sage] 2018/05/04(金) 14:50:31.15

見渡せる見渡せないは重要じゃなくて
見渡せない部分があることを素直に認めて対応する余地を確保することが重要
これができてない人は仮に全部見渡せていても論外

751

： 仕様書無しさん [sage] 2018/05/04(金) 14:55:11.42

最初から完璧なら後から修正する必要がなくなる

752

： 仕様書無しさん [sage] 2018/05/04(金) 15:01:49.31

>>751

こういうカン違いが最悪
ビジネスは常に変化する
それはシステム開発中にでもだ

753

： 仕様書無しさん [sage] 2018/05/04(金) 16:24:23.36

>>745

継承の構造自体を変えるってのがわからんので具体例教えて

754

： 仕様書無しさん [sage] 2018/05/04(金) 17:52:22.66

オブジェクト前入れ替えじゃねか

755

： 仕様書無しさん [] 2018/05/04(金) 21:53:29.75

>>753

聞くんなら、自分のコンテキスト教えたほうが良くね？
例えば趣味なのか、仕事なのか、計算モデルは何なのかとか。
俺はDDDに関心あるから、その前提で責務分担の見直し方法に関心がある。

756

： 仕様書無しさん [] 2018/05/04(金) 21:55:04.32

>>752

ピープルウェアとかデッド・ラインに出てくる「プロジェクトをダメにする自称管理者の勘違い」だもんなあ・・・

757

： 仕様書無しさん [sage] 2018/05/04(金) 22:45:58.66

>>755

バカは口出ししないでくれる？

758

： 仕様書無しさん [] 2018/05/04(金) 22:49:29.79

バカにはもっとキツい言い方せんと理解できんよw

759

： 仕様書無しさん [sage] 2018/05/04(金) 23:05:33.89

計算モデルはなんなのかww

760

： 仕様書無しさん [sage] 2018/05/04(金) 23:33:53.03

エンジンと車の解説は、継承なんて使わないよ！コンポジションを使うんだよ！という隠れた意図がある。

だからエンジンと車の例えがイケてるってわけさ

761

： 仕様書無しさん [sage] 2018/05/04(金) 23:39:14.97

>>760

なるほど、先に継承はなにかが分かってないと
いけないってことだな

762

： 仕様書無しさん [sage] 2018/05/04(金) 23:58:28.63

まあ、処理なんかどこに書いたって見積りは変わんないけどね

763

： KAC [sage] 2018/05/05(土) 01:17:38.83

>>760

そういう喩えでは、
「コンポーネント分ければCで問題なく組めるけど？」
と言う疑問に対して優位性が解りづらい。

764

： 仕様書無しさん [sage] 2018/05/05(土) 07:23:08.54

>>763

どういうこと？

765

： 仕様書無しさん [sage] 2018/05/05(土) 07:35:28.89

>>761

もちろんそうなるさ

だけど犬猫を使って継承を説明するとワナにかかるから
生物を使わないで継承を説明すればいいってこと。

いろんな種類のエンジンがあって、好きなのを車に搭載できる。スーパークラスってのはその様々なエンジンに共通するインターフェースなんだよ。

って説明するだけで良くない？たしかにマニアックかもしれないけど、もしそうならiPhoneケースでもいいし。

バッテリーを拡張できるスマホケースとか、裏にリングが付いてて持ちやすいケースとかいろいろあるでしょ？
でもiPhoneケースはAndroidスマホには搭載できない。
スーパークラスってのは、iPhoneケースのカメラ部分に穴が空いているといったiPhoneケースの共通点を抽出した規格のことを言うんだ。
もちろんソフトウェアの世界に形はないから、その共通点は機能や役割として抽象化されるんだ。

でわかるじゃん

766

： 仕様書無しさん [sage] 2018/05/05(土) 08:46:58.03

>>765

それだとインターフェースの説明にしかならないよな
継承そのものではなく、その利用のしかたのひとつ

767

： 仕様書無しさん [sage] 2018/05/05(土) 08:49:21.31

何処で覚えなさったら知りませんが、
動的入れ替えはOOPとは関係ありません。

768

： 仕様書無しさん [sage] 2018/05/05(土) 11:35:07.04

> いろんな種類のエンジンがあって、好きなのを車に搭載できる。
搭載できないよ。車ごとに搭載できるエンジンは決まってる

769

： 仕様書無しさん [sage] 2018/05/05(土) 11:44:13.22

同じエンジンに交換した場合は問題ないけど
違うエンジンに変更した場合は、そのままでは車検が通らない

違うエンジンに変更することをエンジンスワップという
エンジンスワップした場合は構造変更申請が必要

770

： 仕様書無しさん [sage] 2018/05/05(土) 11:44:55.02

横型エンジンには大きく分けて6V系と12V系に大別できます。

6V系はさらに分かれますが、これらの系統間では大きな変更があり、オイ
ルポンプ、クランクシャフト、ピストン、ミッション、キックギアなどが
異なっており、流用は困難か、加工が必要です。

また、同じベンリー（CD）の12Vでも、50ccと90ccではクランクシャフ
ト、ヘッド、ミッション、クラッチが異なっており、流用の際には注意が
必要です。

12V系の機種間の互換性も、モンキー・ゴリラのリターン式、ベンリー
（CD）のロータリーになりますので、この点でも問題になります。

エンジンまるごとの載せかえでは、12Vではモンキー、ゴリラ、カブ、ベ
ンリー（CD）間では可能ですが、マグナについてはできません。
また、その場合でも左クランクケースカバーが違いますので、モンキーに
ベンリー（CD）のエンジンを載せる場合は加工が必要です。

771

： 仕様書無しさん [sage] 2018/05/05(土) 11:45:45.94

同じ駆動方式同士でのスワップは比較的簡単(!?)にエンジン換装は出来ますね。
数年前だとS13シルビアに13B搭載やR31タイプMにVG30搭載などは
エンジンスワップが得意なチューニングショップでは結構ありましたね。
1G搭載車には7Mも比較的加工も少なくスワップ出来ます。
データとノウハウを持ってるお店もいくつかありますしね。
大昔で言えばマツダシャンテ(360ccの軽自動車)に12Aターボぶち込みとか・・
(そんな事考えるのはひとりだけだけど・・・笑)　

で 駆動方式の違う物同士でのスワップは無理に近いでしょう。
それこそ新しく作り変えるくらいの作業が必要でしょう。
エンジンのマウントはなんとかなったとしてもそこから先が
かなりな作業になるでしょうね。
それこそ車一台買える以上の金額が必要になるかと・・・。
と いう事で＃3のおっしゃってる86系のスワップ以外は一般的な作業ではないですね。

772

： 仕様書無しさん [sage] 2018/05/05(土) 12:05:23.14

OOPに限らず
ソフト業界って妙な例え用語が多くて
「そのプロセスをキルするんだよ」
とか傍で聴いている一般人はビックリするよね

妙な例えしないほうが解りやすいな

773

： 仕様書無しさん [sage] 2018/05/05(土) 12:19:24.00

エンジンや自動車に例えるのは
詳しい人でないとピンと来ないってところなんだよね

774

： 仕様書無しさん [sage] 2018/05/05(土) 12:22:59.50

>>772

例えじゃないし一般人もビックリしませんが

775

： 仕様書無しさん [sage] 2018/05/05(土) 12:24:41.98

オブジェクト指向は言語に制限されないんだから、ここでCがどうのC#がどうの言うのってスレ違いだよね？

776

： 仕様書無しさん [sage] 2018/05/05(土) 12:26:37.57

>>773

じゃあ今後はiPhoneとiPhoneケースでよろしく

777

： 仕様書無しさん [sage] 2018/05/05(土) 12:32:00.24

iPhone8を継承して作られたiPhoneXは
大きさも違って、iPhone8用ケースが使えなくなる
こんな感じかな

778

： 仕様書無しさん [sage] 2018/05/05(土) 12:32:29.49

プログラマって、たとえ話で説明すると必ずたとえ話の重箱隅を突き始めるバカが湧いてくるよな
会話のエッセンスを抽出して理解、発展させる事ができないのかね

779

： 仕様書無しさん [sage] 2018/05/05(土) 12:38:53.71

それは例えた例が悪いからじゃね？

780

： 仕様書無しさん [sage] 2018/05/05(土) 12:40:45.03

>>778

そうそう

大切なのはアイディアを出し合って
よりベターな例えを見つけることだ

車とエンジンが例えとしてイケてないのは事実だし
プログラミングの世界に想像できない生物を持ってくる事がイケてないのも事実。

じゃあ、生物を使わないでわかりやすい例えはなんだろう？
それを俺たちでみつければいいのさ

781

： 仕様書無しさん [sage] 2018/05/05(土) 12:48:10.80

>>778

> プログラマって、たとえ話で説明すると必ずたとえ話の重箱隅を突き始めるバカが湧いてくるよな
な？俺が最初に言ったとおりだろ

414 名前：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66

>>413

有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる

782

： 仕様書無しさん [sage] 2018/05/05(土) 12:49:04.27

例えなきゃならないのは、具体的な案件が諸事情で出せないからだけどな。
社内じゃ例えなんか使わないでダイレクトに案件固有の状況で話すから。

783

： 仕様書無しさん [sage] 2018/05/05(土) 12:50:27.24

>>782

あのー、オブジェクト指向が分かってない人への
オブジェクト指向の説明の話なんですけど？

784

： 仕様書無しさん [sage] 2018/05/05(土) 13:04:08.74

>>781

お前そのコピペ大好きだなほんと

初心者にはイメージが大切なんだ。
で、プログラムの世界をイメージするのに最適な世界って
ゲームの世界だよな。

そしてプログラミングで大事なのはモジュールという概念だ。
んで、オブジェクト指向では、クラスでモジュールを作成する。

モジュールってのは初心者にわかりやすく説明するならパーツやマシンのことだろう？

そしてそのパーツやマシンを組み合わせて、プログラマが作りたいものを作れるのがプログラミングでありオブジェクト指向じゃないか。

レースゲームでタイヤ変えたりするのが、オブジェクト指向のイメージにぴったりだと思うのは何か間違ってんの？？

785

： 仕様書無しさん [] 2018/05/05(土) 13:23:28.46

>>783

,784
ところでおまえら自身がわかってないのに
どうしてわかってない人への説明などという無謀な挑戦をするのや？

786

： 仕様書無しさん [sage] 2018/05/05(土) 13:24:59.69

>>785

と、意味不明な供述をしており・・・

787

： 仕様書無しさん [sage] 2018/05/05(土) 13:59:34.24

>>785

もっと意味ある投稿してよ

788

： 仕様書無しさん [sage] 2018/05/05(土) 14:44:42.49

>>785

継承が表現できてないから駄目だな

789

： 仕様書無しさん [sage] 2018/05/05(土) 15:11:03.82

>>784

お前なにか勘違いしてないか？
犬猫に例えるのが駄目だって言ってるんだよ。
レースゲームがどうとかいう話はしていない

790

： 仕様書無しさん [sage] 2018/05/05(土) 15:27:06.19

>>789

話を次のステップに進めたいんだよ俺は

犬猫がダメな理由は犬猫が生物だからだろう？
その次の話をしたいの。生物を使わないわかりやすい例えはなんだろうねって

791

： 仕様書無しさん [sage] 2018/05/05(土) 15:37:54.17

> 犬猫がダメな理由は犬猫が生物だからだろう？
理由になってない

792

： 仕様書無しさん [sage] 2018/05/05(土) 15:40:38.44

犬猫が良い理由も犬猫が生物だからなんだけどね

生物であるがゆえに、最初に構造を自分で考える必要がない
なにも知らないで自分で考えるよりも
最初にあるものを例にしたほうがわかりやすいから

793

： 仕様書無しさん [sage] 2018/05/05(土) 16:10:35.71

哺乳類という分類をどんなに拡張しても猫にならない
なので犬猫モデルはダメダメ

794

： 仕様書無しさん [sage] 2018/05/05(土) 16:11:35.70

>>791

>>793

が理由になってる

795

： 仕様書無しさん [sage] 2018/05/05(土) 16:14:56.72

>>793

> 哺乳類という分類をどんなに拡張しても猫にならない
なるぞ？

796

： 仕様書無しさん [sage] 2018/05/05(土) 16:16:04.25

エンジンという分類をどんなに拡張しても
ディーゼルエンジンにはならない

797

： 仕様書無しさん [sage] 2018/05/05(土) 16:16:09.66

>>784

スーパークラスは規格なんだよ。お家のコンセントが、家によってバラバラだったら家電使えないでしょ？

タイヤにもコンセントみたいな規格があって、その規格にあわせていろんなタイヤを作るから
タイヤが交換できるんだよ。

で、説明可能（ドヤッ

798

： 仕様書無しさん [sage] 2018/05/05(土) 16:16:58.29

OOPがモデリングの世界という事を理解してない奴が多いな
犬猫クラスは簡略化された犬猫のモデルであって厳密な犬猫の定義ではない
なので現実の犬猫はああだこうだと細かく指摘するのは無意味

799

： 仕様書無しさん [sage] 2018/05/05(土) 16:17:45.97

ごめん

>>797

は

>>788

の返信ね

800

： 仕様書無しさん [sage] 2018/05/05(土) 16:18:04.20

>>797

でもコンセントの形は各国でバラバラだぞ

801

： 仕様書無しさん [sage] 2018/05/05(土) 16:21:08.53

>>795

哺乳類のダメなところは規格きよる分類として
プログラミングと相性が悪いところなんだよ

哺乳類の規格なんて答えられるやついるか？？反面、乾電池の規格はわかりやすいし、
その規格に適応させることで連携稼働するという結果も見られる。

802

： 仕様書無しさん [sage] 2018/05/05(土) 16:21:20.93

タイヤの規格を拡張したものがタイヤです

803

： 仕様書無しさん [sage] 2018/05/05(土) 16:22:04.15

>>801

> 哺乳類の規格なんて答えられるやついるか？？

哺乳類にあるのは規格じゃなくて性質ですが？

804

： 仕様書無しさん [sage] 2018/05/05(土) 16:22:17.63

>>800

そこで、アダプターパターンの説明すれば
オオッ！なるほどデザインパターン大事ですね！ってもっと良いじゃん

805

： 仕様書無しさん [sage] 2018/05/05(土) 16:23:12.81

>>803

だからダメなんじゃん。

プログラミングは性質なんて曖昧なもんで繋がってない。

806

： 仕様書無しさん [sage] 2018/05/05(土) 16:23:31.71

「オブジェクト指向の説明に生物は不適切！だからUserクラスとか定義したらダメ！」

807

： 仕様書無しさん [sage] 2018/05/05(土) 16:23:53.99

> 乾電池の規格はわかりやすいし、
あ、はい

ttp://www.geocities.jp/r_oda42/main_denti.html

電池系記号 　 電池の通称 　 公称電圧
なし 　 マ ン ガ ン 乾 電 池 　 1.5V
B 　 フッ化黒鉛 リチウム電池 　 3.0V
C 　 二酸化マンガンリチウム電池 　 3.0V
G 　 酸 化 銅 リチウム 電 池 　 1.5V
E 　 塩化チオニルリチウム電池 　 3.6V
L 　 ア ル カ リ 乾 電 池 　 1.5V
P 　 空 気 亜 鉛 電 池 　 1.4V
S 　 酸 化 銀 電 池 　 1.55V
H 　 ニッケル水素電池（二次） 　 1.2V
K 　 ニ カ ド 電 池 （二次） 　 1.2V
Z 　 ニ ッ ケ ル 系 電 池 　 1.5V
M , N 　 水 銀 電 池 　 1.35V

米国の通称 IEC/JIS 日本の通称 旧JIS 直径 �o 高さ �o
D R２０ 単１ UM-1 34.2 61.5
C R１４ 単２ UM-2 26.2 50.0
AA R６ 単３ UM-3 14.5 50.5
AAA R０３ 単４ UM-4 10.5 44.5
N R１ 単５ UM-5 12.0 30.2 　

808

： 仕様書無しさん [sage] 2018/05/05(土) 16:25:01.18

>>805

> プログラミングは性質なんて曖昧なもんで繋がってない。

性質が駄目なら属性でもいいけど？

809

： 仕様書無しさん [sage] 2018/05/05(土) 16:25:29.63

>>807

おまえ乾電池使ってる人が全てその認識あるとおもってんの？
もしそうおもってないなら乾電池がわかりやすく使いやすい証明になるんだけど

810

： 仕様書無しさん [sage] 2018/05/05(土) 16:25:55.15

>>804

余計混乱するだろうなｗ

811

： 仕様書無しさん [sage] 2018/05/05(土) 16:26:21.52

>>809

> おまえ乾電池使ってる人が全てその認識あるとおもってんの？

だからだめなんだよね。
身近な例じゃないから分かりづらい

812

： 仕様書無しさん [sage] 2018/05/05(土) 16:27:53.28

>>810

混乱する人にはまだ早いだけでしょ
アダプターパターンを理解するのにこれ以上わかりやすい説明あったら教えてよww

できるなら動物使って説明してみてよwww

813

： 仕様書無しさん [sage] 2018/05/05(土) 16:28:35.85

やっぱりわかりやすい
ttps://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak3/S3-3-1.html

分類概念の上下関係にもとづいてクラスの継承をきちんと作成していくと、「実際にはインスタンスを作成する必要のないクラス」が存在することになります。

例えば、ペットブリーダーを支援するアプリケーションを作成していたと考えてみましょう。様々な動物をプログラム上管理する必要があるため、

哺乳類
犬
柴犬
チワワ
コリー
猫
…
といった形でクラスを定義していたとします。

実際に、ペットブリーダーが育てるのは、「(芝犬の)ポチ」や「(コリーの)ラッシー」です。この場合に、「哺乳類」
「犬」「猫」といったクラスは、主として分類の適切な階層を形成するために存在し、実際のインスタンスは
作成しないことになります。(なんだかよくわからない「哺乳類のインスタンス」をペットブリーダーが対象にすることはありえません)。

こうしたクラスを抽象クラスと呼びます。抽象クラスの「抽象」とは、決して「具体的なインスタンスが作成されない」
という意味になります。(これに対し、実際にインスタンスが作成されるクラスを「具象クラス」とよぶ場合があります)。
ただし、抽象クラスの持つ「属性の定義」、「操作の定義」、「操作の実装」は依然としてサブクラスで継承され、利用されることになります。
例えば「哺乳類」には、「平均体温」といった属性の定義を行っておくことができ、「犬」には「お手
」「おすわり」といった操作の定義、実装をすることができます。

抽象クラスは分類の概念をきちんと整理するのに役立ち、また、継承によるコードの再利用も促進します。

814

： 仕様書無しさん [sage] 2018/05/05(土) 16:29:39.30

>>812

> アダプターパターンを理解するのにこれ以上わかりやすい説明あったら教えてよww

だからそうじゃなくてい、今はオブジェクト指向が分かってない人向けの説明
小学生にいきなり高等数学お教えても理解できないんだよ

815

： 仕様書無しさん [sage] 2018/05/05(土) 16:30:07.38

そうだな。クラスとかインスタンスとか分かってないレベルの人には
犬猫で例えたほうがわかりやすいだろう。

816

： 仕様書無しさん [sage] 2018/05/05(土) 16:32:23.65

>>806

大切なのはエンジニアがプログラムの世界に生物はいないって認識を持つこと。

そしたらUserクラスを作っても、これはUser自体を指すのではなく
アプリケーションがもつユーザに関するデータや機能がある装置（パーツ）なんだって正しい認識ができるじゃん

817

： 仕様書無しさん [sage] 2018/05/05(土) 16:33:13.62

> 大切なのはエンジニアがプログラムの世界に生物はいないって認識を持つこと。

な？ いきなりプログラムの世界という馴染みのない世界での話をする
それじゃ、分かってない人は理解できないよ

818

： 仕様書無しさん [sage] 2018/05/05(土) 16:34:09.60

重要なのは相手の立場になって考えること。
プログラムの世界にいない人はいるが
現実世界であれば誰でもいる
その現実世界で例えるから理解しやすい

819

： 仕様書無しさん [sage] 2018/05/05(土) 16:34:19.91

>>815

かもしれない。

けど、クラスを作れるようになったら犬猫の概念が邪魔になるから忘れろ！っていうのもおかしな話だ

820

： 仕様書無しさん [sage] 2018/05/05(土) 16:34:52.42

>>817

はいはい
ゲームの世界ならわかるでしょ

821

： 仕様書無しさん [sage] 2018/05/05(土) 16:35:29.08

乾電池といっても場面によって様々だ

オンラインショップでは特別なクラスでは無く単に商品クラスの1インスタンスになるだろう
商品説明プロパティに通称や規格といった情報がドキュメントとして含まれるかもしれないがそれが振る舞いに影響することはない

中高生向け教材用の回路シミュレーターでは電圧など簡略化された物理特性が定義されていれば十分で規格や通称などは無視されるだろう
この場合の乾電池クラスは素子クラスを継承しているかもしれない

乾電池の現実的なあらゆる側面を考慮してクラス化しようとするから無理が生じる
乾電池クラスはあくまで簡略化されたモデルでしかないのでリアルな乾電池の全てを正確に表現する意味はどこにもない

822

： 仕様書無しさん [sage] 2018/05/05(土) 16:35:56.79

>>819

じゃまにはならんよｗ

>>820

> ゲームの世界ならわかるでしょ
ゲームの世界の犬や猫ってことですね！

823

： 仕様書無しさん [sage] 2018/05/05(土) 16:39:48.57

>>822

いや、なってるよ！

継承よりコンポジションやDIが大切なのに
それが行われずに何でもかんでも共通機能は
全部親クラスに定義して神クラスが出来上がるのは犬猫のせいだろ！

犬の臓器をコンストラクタで代入するなんて発想、初心者には意味不明すぎ。だから神クラスができる。

824

： KAC [sage] 2018/05/05(土) 16:40:53.29

>>793

オブジェクト指向を理解してから発言したほうがいい

825

： 仕様書無しさん [sage] 2018/05/05(土) 16:46:02.25

>>823

ほんと理解できないやつだなｗ

分かってない人向けの説明だって言ってるだろ
まず犬猫で継承を理解してからだって
コンポジションやDIなんてオブジェクト指向に必須のものではない

826

： 仕様書無しさん [sage] 2018/05/05(土) 16:47:40.97

>>814

深掘りする質問されたらレベルが深くなるのは当たり前なんですけど。バカなの？

827

： 仕様書無しさん [sage] 2018/05/05(土) 16:47:44.87

>>825

コンポジションが必要じゃないわけないだろ
お前のクラスのフィールドは全部プリミティブ型なのか

828

： 仕様書無しさん [sage] 2018/05/05(土) 16:48:47.76

>>825

こいつはオブジェクト指向を理解したつもりになってます

829

： 仕様書無しさん [sage] 2018/05/05(土) 16:50:18.73

初心者には継承より先にコンポジションを説明するべきだと思うほど重要だろう

830

： 仕様書無しさん [sage] 2018/05/05(土) 16:51:57.79

継承を知らない人に継承は良くないですよって
言っても理解できない

831

： 仕様書無しさん [sage] 2018/05/05(土) 16:52:55.92

どんなことでも基本が大事
オブジェクト指向の機能はクラスと継承だ

832

： 仕様書無しさん [sage] 2018/05/05(土) 16:54:02.55

>>831

クラスとインターフェースだろう？

833

： 仕様書無しさん [sage] 2018/05/05(土) 16:55:00.58

継承は重要な概念だが重要な機能ではない
重要な概念かつ重要な機能であるインターフェースを学ばせるほうが有益

834

： 仕様書無しさん [sage] 2018/05/05(土) 16:56:11.74

あ、先に言っておくとインターフェースって、スーパークラスとinterfaceの両方を含む意味のことね！
ポリモーフィズム的視点から見たらどっちもインターフェースだから

835

： 仕様書無しさん [sage] 2018/05/05(土) 16:56:38.95

>>833

君とは仲良くなれそうだ

836

： 仕様書無しさん [sage] 2018/05/05(土) 17:07:49.70

自作自演かよｗ

837

： 仕様書無しさん [sage] 2018/05/05(土) 17:11:58.64

>>836

(ﾟДﾟ)ﾊｧ?

838

： 仕様書無しさん [sage] 2018/05/05(土) 17:13:04.36

継承は基本だからオブジェクト指向しっていて知らないのは潜りだぞ

839

： 仕様書無しさん [sage] 2018/05/05(土) 17:14:13.01

>>838

お、おう
そうだな

840

： 仕様書無しさん [sage] 2018/05/05(土) 17:15:52.03

結局、犬猫がだめな理由が出てないんだよね。
生物だからだめだー。ただこれだけ

841

： 仕様書無しさん [sage] 2018/05/05(土) 17:21:25.89

>>840

>>823

よく読めよ

842

： 仕様書無しさん [sage] 2018/05/05(土) 17:33:19.46

>>841

それがどうかしたの？
構造体使えばいいのに何でも配列を使うのは
配列を教えたせいだ！って言ってるようにしか見えないなぁｗ

843

： 仕様書無しさん [sage] 2018/05/05(土) 18:00:29.78

>>842

ただ否定したいだけじゃん
ガキ

844

： KAC [sage] 2018/05/05(土) 18:02:37.60

>>833

インターフェースは、継承の概念に基づいた実装の一つ。
多分、抽象クラスの話題と混同してる。

というか、作ったインターフェースを継承しないの？何故気付かないのか。。。

845

： 仕様書無しさん [sage] 2018/05/05(土) 18:14:54.99

>>844

インターフェースは契約の集合であって継承とは異なる概念だけどまあ言ってもわからんだろうね

846

： 仕様書無しさん [sage] 2018/05/05(土) 19:55:30.15

>>845

C++で多重継承してひどい目にあったことがある。

いろいろおもったことはあったけど、そこから学んだことは「多重継承はアンチパターン」ってことと「インターフェースであれば多重継承問題が起こらない」ということだった。

詳しいみたいなので聞きたいんだが、これ以外にツッコミどことか知っておくべきことってある？

847

： 仕様書無しさん [sage] 2018/05/05(土) 20:35:38.69

多重継承は使うな、
ってのは今じゃなくても
オブジェクト指向が流行りだした
かなり初期の頃から言われてたじゃん。

848

： 仕様書無しさん [sage] 2018/05/05(土) 20:39:23.43

>>847

多重継承がよく使われるっていうのは、インターフェースの多重継承ではなくて？