２ちゃんねる ■掲示板に戻る■ 全部 1- 最新50

■ このスレッドは過去ログ倉庫に格納されています

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

1 ：仕様書無しさん：2018/03/24(土) 14:39:26.84 .net: PG、SE歴17年だが
いまだに良く分からん
もやっとしてる
教えてくれ
2 ：仕様書無しさん：2018/03/24(土) 15:27:32.69 .net: 本が一杯出てるからそれ読めばいいだろ
読んで理解できないのならここで説明した所で無理だろ
3 ：仕様書無しさん：2018/03/24(土) 16:36:10.31 .net: どっちが欲しいの？　ボケ？　マジレス？
4 ：仕様書無しさん：2018/03/24(土) 16:57:08.73 .net: OOPはポインタ
5 ：仕様書無しさん：2018/03/24(土) 17:27:25.63 .net: 全部staticでいいじゃん
6 ：仕様書無しさん：2018/03/24(土) 17:29:16.62 .net: まず、Cの構造体の勉強をすることだな。
7 ：仕様書無しさん：2018/03/24(土) 18:50:15.40 .net: ウンコ
8 ：仕様書無しさん：2018/03/24(土) 19:05:28.24 .net: プログラミング関連はWikipediaが割と良い
9 ：仕様書無しさん：2018/03/24(土) 20:20:18.00 .net: オブ脳本でも読めば？
10 ：仕様書無しさん：2018/03/24(土) 20:43:41.24 .net: >>1
17年やってわからんとは、つける薬がないほどの馬鹿だ。
迷惑だからPG辞めたほうがいいな。
11 ：仕様書無しさん：2018/03/24(土) 21:30:17.97 .net: メリットの説明はできた者がいない

どや顔でやって来るやつは大抵意味不明なことをのたまって終わり
オブジェクト指向に脳をやられている
12 ：仕様書無しさん：2018/03/24(土) 22:14:51.56 .net: >>11

脳がやられているのでOOP理解できなかった奴
13 ：仕様書無しさん：2018/03/24(土) 22:15:36.11 .net: なんてこったい
オーノー
14 ：仕様書無しさん：2018/03/24(土) 22:24:50.59 .net: >>1
使ってる言語は？
15 ：仕様書無しさん：2018/03/24(土) 22:31:51.65 .net: >>12
脳がやられているのでメリットを説明できない奴？
16 ：仕様書無しさん：2018/03/25(日) 00:08:40.33 .net: ところで「チンボがシコシコする」という日本語表現は、文法的に正しいのか？

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

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

違うか？

「頭がズキズキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！
17 ：仕様書無しさん：2018/03/25(日) 00:14:32.10 .net: （第1章はじめに　2頁）
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。

『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル
18 ：仕様書無しさん：2018/03/25(日) 00:35:27.13 .net: 凄いな完璧にオブジェクト指向を表現した
完璧にだ
19 ：仕様書無しさん：2018/03/25(日) 01:28:13.49 .net: >>16
「舌がピリピリする」みたいな
身体の受動的感覚なら文法的に可
「顔がニコニコする」みたいに
動作主体が人間なら不可
20 ：仕様書無しさん：2018/03/25(日) 11:24:17.96 .net: 人類のスーパクラスはネズミの祖先だと思うんだ
21 ：仕様書無しさん：2018/03/25(日) 12:02:46.92 .net: まだ進化論信じてんだ
22 ：仕様書無しさん：2018/03/25(日) 12:03:24.49 .net: まだextendしてきたと思ってんだ
23 ：仕様書無しさん：2018/03/25(日) 13:46:32.99 .net: 人類のスーパクラスは哺乳類
OOPが理解できない最大の理由
24 ：仕様書無しさん：2018/03/25(日) 14:44:38.63 .net: 自然言語処理の知識はゼロなのでわからないです。面白いアイデアだと思うので、Twitterの自然言語処理が専門の方々に聞いてみては？
https://peing.net/ja/q/417c9e29-35de-4c95-8323-afd6a50fcbc7
25 ：仕様書無しさん：2018/03/25(日) 15:05:25.89 .net: >>23

extendsしてると本当に思ってるゔぁか
26 ：仕様書無しさん：2018/03/25(日) 15:07:37.24 .net: マジレスすると、OOPが有用かどうかは分からないが、継承がフレームワーク作成側、利用側の両者で直感的なのは間違いない。
また、クラスに対してC#拡張メソッドより PHPtraitの方が色々問題もありそうだが直感的なmixinだ
27 ：仕様書無しさん：2018/03/25(日) 21:56:10.25 .net: >>21
進化論がダーウィンのものだと勘違いしてる奴が此処にも。
28 ：仕様書無しさん：2018/03/26(月) 22:22:24.17 .net: >>1
考えるんじゃない、感じろ
29 ：仕様書無しさん：2018/03/26(月) 23:09:46.00 .net: >>27
進化論はダーウィンの物ではない、悪魔の物だ
30 ：仕様書無しさん：2018/03/26(月) 23:25:05.78 .net: 人間にわからんものは神か悪魔のせいにしとけば間違いない
31 ：仕様書無しさん：2018/03/27(火) 01:55:18.27 .net: 全て乾巧って奴の
32 ：仕様書無しさん：2018/03/31(土) 02:03:04.50 .net: >>27

どっから“ダーウィン”って言葉が出てきたんだよ。ヴァカなのか!?
33 ：仕様書無しさん：2018/03/31(土) 02:14:23.88 .net: タービンだっけ？
34 ：仕様書無しさん：2018/03/31(土) 04:05:36.68 .net: まだ進化出来ないから仕方ないな
35 ：仕様書無しさん：2018/03/31(土) 04:43:13.93 .net: 進化の石がないだけやで
36 ：仕様書無しさん：2018/03/31(土) 06:53:43.60 .net: 人類はとっくに自ら進化を促せるだけの力はあるのに神だの悪魔だの呪縛で出来ないでいる

つまり、extendedじゃなくrevolutionというキーワードにすべきだった
37 ：仕様書無しさん：2018/03/31(土) 08:46:12.73 .net: OOPの説明に犬猫だすのは無能
38 ：仕様書無しさん：2018/03/31(土) 09:09:40.69 .net: カモノハシで説明してくれないとよくわからないよな
39 ：仕様書無しさん：2018/03/31(土) 09:36:45.70 .net: データをまとめた構造体に、そのデータを扱うメソッドも入れてしまおうというのは自然な流れだし
メソッドを入れたんなら、それで内部データにアクセスできるから、外部から勝手に変更されないようにアクセス制限を儲けようというのも自然な流れだし、
型を拡張したり、拡張した型によって呼ばれるメソッドを変えられるようにしたら便利だなという考えに行き着くのも自然な流れだった。
つまり、オブジェクト指向はプログラミング工学の進化の仮定で発生したごく必然的な考え方なのであーる。
40 ：仕様書無しさん：2018/03/31(土) 09:40:53.28 .net: >>39
鶴と亀を引数にとるメソッドは何処に書けばいいの？
41 ：仕様書無しさん：2018/03/31(土) 10:21:23.83 .net: 何をするメソッドなのか
42 ：仕様書無しさん：2018/03/31(土) 10:24:50.01 .net: >>41
鶴亀算
豚と猫の拡張も考慮したい
43 ：仕様書無しさん：2018/03/31(土) 10:54:48.19 .net: 鶴亀ソルバってクラスを作って、Animalクラスを引数にとるSetAnimal関数を作る
Animalクラスを継承したTsuruクラスとKameクラスを作る
鶴亀ソルバを作る人は、引数のクラスを気にせず実装出来る
Butaクラスを作る人やNekoクラスを作る人も、そのクラスがどう扱われるかを気にせず実装できる
44 ：仕様書無しさん：2018/03/31(土) 11:06:35.55 .net: 進化の過程で必要なのはバージョン管理
45 ：仕様書無しさん：2018/03/31(土) 12:16:16.90 .net: >>43
全部でいくつクラスできるんです？
ブレーメンの音楽隊以上にはなります
46 ：仕様書無しさん：2018/03/31(土) 12:19:33.53 .net: 足の本数が整数でわかれば計算できるときに
なぜAnimalクラスが必要か！？
47 ：仕様書無しさん：2018/03/31(土) 12:22:24.94 .net: 自然界はオブジェクト指向ではない。
生物の分類なんて完璧にはできない

だが、人間が理解しやすいように分類したものは
オブジェクト指向で表現することが可能
完璧な表現なんか誰も求めていない
目的が達成できれば良いのだよ
48 ：仕様書無しさん：2018/03/31(土) 12:22:35.99 .net: Animalじゃなかったその下
49 ：仕様書無しさん：2018/03/31(土) 12:33:04.42 .net: Animalの下っていうと
Humanか？
50 ：仕様書無しさん：2018/03/31(土) 13:20:04.83 .net: class Human extended Ameba
51 ：仕様書無しさん：2018/03/31(土) 13:32:39.80 .net: new 動物("鶴", 2)
new 動物("亀", 4)
52 ：仕様書無しさん：2018/03/31(土) 13:51:09.60 .net: ムカデサポート
53 ：仕様書無しさん：2018/03/31(土) 14:30:15.36 .net: 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 ：仕様書無しさん：2018/03/31(土) 14:42:40.12 .net: 自然界こそオブジェクト指向だと思います
55 ：仕様書無しさん：2018/03/31(土) 16:20:17.18 .net: class 鶴 extends 鳥類{}
class 亀 extends 爬虫類{}

new 鶴();
new 亀();
56 ：仕様書無しさん：2018/03/31(土) 16:23:18.96 .net: だから足の本数だけでいいんだって
なんで継承…
57 ：仕様書無しさん：2018/03/31(土) 16:31:46.26 .net: 足の数はメンバ変数で定義されてるに決まってんじゃん。
なんで外から渡すんだよ。
58 ：仕様書無しさん：2018/03/31(土) 16:37:23.87 .net: 足の本数ごとに親をまとめてるのか…
59 ：仕様書無しさん：2018/03/31(土) 16:44:28.00 .net: LegCountable というインターフェスだけでいい
Animalクラスもいらん
60 ：仕様書無しさん：2018/03/31(土) 16:44:38.04 .net: 4本足あったら、それは鳥類じゃねえよボケナス
61 ：仕様書無しさん：2018/03/31(土) 17:00:27.55 .net: 頭の数も欲しいと言われたらHeadCountable作るの？
62 ：仕様書無しさん：2018/03/31(土) 17:08:55.16 .net: >>56
猫の手も借りたいところだな
63 ：仕様書無しさん：2018/03/31(土) 17:16:12.31 .net: LegCountableもいらん
このつくりなら
足の数以外なんもいらんのだから整数でいいだろ！
64 ：仕様書無しさん：2018/03/31(土) 17:19:26.00 .net: 鶴亀算をオブジェクト指向で作る意味がないとは思うが、
オブジェクト指向のスレだからな
65 ：仕様書無しさん：2018/03/31(土) 17:20:05.19 .net: と思ったけど要素と動物をふやして３元連立に拡張できるからあったほうがいいのか？
66 ：仕様書無しさん：2018/03/31(土) 17:59:40.91 .net: このように考え過ぎるのがオブジェクト思考の特徴

とにかく無駄な拡張性だけ考えておくのです
67 ：仕様書無しさん：2018/03/31(土) 18:04:25.37 .net: うん、やっぱりいらないな

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

動物クラスの出る幕がない
68 ：仕様書無しさん：2018/03/31(土) 18:38:22.52 .net: そして神クラスへ
69 ：仕様書無しさん：2018/03/31(土) 18:52:44.69 .net: 今いるところは神クラスはないがサービスクラスという手続き型だけだわ
70 ：仕様書無しさん：2018/03/31(土) 19:05:10.25 .net: 足の数は属性なんでクラスじゃないな
インターフェースでもない
71 ：仕様書無しさん：2018/03/31(土) 19:11:54.45 .net: 足はhas Aで実装でしょ
例えば手や足って将来的に機械で拡張される場合もあるし
ほかにも羽が生えてくるかもしれない（工学的な意味で）
そんなわけで親子関係をもった部位クラスとして実装すべき
72 ：仕様書無しさん：2018/03/31(土) 19:22:06.32 .net: お前の腕機能拡張して増やせるんだ。すげーや。
73 ：仕様書無しさん：2018/03/31(土) 20:14:55.74 .net: だからいらんちゅーに
もともとあるならまだしも鶴亀算したいだけだろうがｗ
74 ：仕様書無しさん：2018/03/31(土) 20:21:53.30 .net: >>32
OA進化論者か・・・
75 ：仕様書無しさん：2018/03/31(土) 20:54:12.34 .net: >>72
義手とか有るから増やせると思うよ
76 ：仕様書無しさん：2018/03/31(土) 20:58:55.10 .net: >>61
鶴亀算は足の数をもとに計算する仕様だから、頭の数も考慮するとなると前提条件の見直しになる。恐らくインターフェース名と前提条件の変更を余儀なくされるだろう
インターフェスーに抽象メソッドを追加し、クラスにもメソッドを追加しないといけない。しかしそれでも変更箇所は限定的で、コンパイルエラーによって実装漏れも教えてくれる。

しかし、そもそも頭が複数ある般的な生物なんているのか？
77 ：仕様書無しさん：2018/03/31(土) 22:11:19.03 .net: 唐傘小僧参戦決定!
78 ：仕様書無しさん：2018/03/31(土) 22:12:23.68 .net: >>76

なんか>>75が増やせるっていうから義頭拡張されたらもう、どうしようもないぞ。
79 ：仕様書無しさん：2018/03/31(土) 22:15:10.00 .net: ヤマタノオロチがこっちを見ている!
80 ：仕様書無しさん：2018/03/31(土) 22:25:52.42 .net: キメラクラス
81 ：仕様書無しさん：2018/03/31(土) 22:38:26.54 .net: >>78
実際頭が2つ有る人間だっているしね。

え？頭が2つある人を人間だって認めないっていうのかい？
まさかそんなことはないよねｗｗｗ
82 ：仕様書無しさん：2018/03/31(土) 22:40:33.48 .net: 自然界をオブジェクト指向で表現することができないのは
例外や突然変異があるから

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

100%の仕事なんか求められていないし不可能
83 ：仕様書無しさん：2018/03/31(土) 23:11:56.15 .net: >>81

俺のシステムはその時点でException投げるから、
そっから先は例外処理。
84 ：仕様書無しさん：2018/03/31(土) 23:13:21.90 .net: >>81 のシステム、クズ過ぎｗｗｗｗｗｗｗｗｗｗｗｗｗ
85 ：仕様書無しさん：2018/04/01(日) 00:12:58.66 .net: 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 ：仕様書無しさん：2018/04/01(日) 00:19:02.73 .net: 俺も理解するまで時間がかかったけど
RPGのゲームを考えると理解できた

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

また、そのスライムというクラスを継承してメタルスライムやキングスライムといった派生クラスを作れば
それぞれのクラスをを1から作らなくても良い
87 ：仕様書無しさん：2018/04/01(日) 00:41:04.84 .net: >>86
それ、スライムって構造体を作るのと何が違うの？
スライム10体なら、スライムって構造体の変数を10個作ればいいだけ
構造体ならクラスの概念のないC言語でも出来るよ
88 ：仕様書無しさん：2018/04/01(日) 00:42:54.88 .net: オブジェクト指向ってのは設計が大事なんだよ
理解できてなくてもプログラムを書くことは出来るし要件を満たせるが
オブジェクト指向を理解することによって保守性とかプログラムの美しさに繋がる
89 ：仕様書無しさん：2018/04/01(日) 00:45:07.79 .net: class スライム:ウンコ
90 ：仕様書無しさん：2018/04/01(日) 01:53:24.59 .net: >>87
c言語でスライムは出来るだろうけど
メタルスライムとかキングスライムはどうする？
91 ：仕様書無しさん：2018/04/01(日) 02:42:16.23 .net: >>88
プログラムなんて
車のシャーシどころか設計図みたいなもん
なんて美しい設計図なんだ！ってあほか

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

多少汚くたって困るのプログラマーだけじゃねえか
賃金やすいんだから工数倍になったってたかが知れてる
92 ：仕様書無しさん：2018/04/01(日) 02:53:57.04 .net: 保守性がよくなるってのもうそっぱち
状態がある分、クラスのメンテは関数のメンテよりはるかに大変
処理自体も基本わかりづらくなる。
いっぺんイテレーター作ってみやがれ

標準ライブラリのように完膚なきまでにテストされ、作りこまれて安定したクラスを
使うとき
だけ、保守性や生産性が向上するんだ…
93 ：仕様書無しさん：2018/04/01(日) 02:59:36.14 .net: そもそも>>88の言ってることが漠然としすぎてて発狂する
なんやねん
94 ：仕様書無しさん：2018/04/01(日) 03:00:57.96 .net: >>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 ：仕様書無しさん：2018/04/01(日) 09:42:34.11 .net: >>92
カプセル化、全否定かよ
96 ：仕様書無しさん：2018/04/01(日) 09:48:34.07 .net: >>95
俺もいいことないと思うな
結局、中の状態を把握した上でないと使えないし
なんの説明もないくせにinitメソッド2回呼ぶとバグるし
initメソッド2回呼ぶとバグるのはソース見ないとわからんし
だったらC言語時代に戻ろうぜ
97 ：仕様書無しさん：2018/04/01(日) 10:53:24.38 .net: データを変更するメソッドが、そのクラス内にしかないと分かっているの楽
98 ：仕様書無しさん：2018/04/01(日) 11:00:52.39 .net: >>97
だから鶴亀算をどこに書くのかと
99 ：仕様書無しさん：2018/04/01(日) 11:02:50.87 .net: 観測する人間クラスの中に決まってんじゃん
100 ：仕様書無しさん：2018/04/01(日) 11:04:28.90 .net: >>99
そうなると鶴クラスと亀クラスが存在しないと人間クラスは存在できないクソ設計
101 ：仕様書無しさん：2018/04/01(日) 11:19:29.37 .net: なんでだよヴァカ
102 ：仕様書無しさん：2018/04/01(日) 11:20:49.02 .net: >>101
人間クラスに鶴亀クラスが出てくるから
人間クラスだけ使う場合も
鶴亀クラスもってこないとエラー出るだろボケ
103 ：仕様書無しさん：2018/04/01(日) 11:25:54.85 .net: >>91
綺麗な設計のプログラムは動かないという前提なら、そりゃ汚くても動く方がマシだけど、そうじゃないだろアホ
104 ：仕様書無しさん：2018/04/01(日) 11:27:36.67 .net: 鶴亀算コントローラで鶴亀算に必要なクラス呼べばいいだけだし
105 ：仕様書無しさん：2018/04/01(日) 11:28:07.57 .net: trello

https://trello.com/
106 ：仕様書無しさん：2018/04/01(日) 11:35:30.27 .net: オブジェクト思考は人間の都合のいい解釈で抽象化なされた現実離れしたもの。
しかし、人間の都合のいい解釈によって、使い方の提案を含めたオブジェクトが作成できることは
その利用者の思考コストを減らすから、それがメリットみたいなこと書いてあった。

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

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

実際使う時便利だし。モジュールのためのオブジェクト指向って感じなのかなぁ
107 ：仕様書無しさん：2018/04/01(日) 11:38:17.87 .net: 今のsiは似たような部品とかを一から作って水増し工数をしてるんだな
だからオブジェクト指向は使われてない効率よくしようとはされてない
そもそも寄せ集めだからプログラマーのレベルもバラバラ
108 ：仕様書無しさん：2018/04/01(日) 11:44:16.63 .net: 下級プログラマはオブジェクト指向のことは考えなくていい
そういうのは上級プログラマが考えるから、下級プログラマは提供されたフレームワークなりライブラリなりの
使い方だけ知っていればいい
109 ：仕様書無しさん：2018/04/01(日) 11:58:05.21 .net: >>106
じゃ、メリットは？
～な気がするとかおままごとは他所でやれよ
110 ：仕様書無しさん：2018/04/01(日) 14:26:36.47 .net: 標準apiとかフレームワークこそがオブジェクト指向の良い教材
誰でも簡単に使えるやん
111 ：仕様書無しさん：2018/04/01(日) 14:33:16.18 .net: >>110
周知されてるからでしょ？
お前が作るオナニークラスライブラリはノーサンキュー
112 ：仕様書無しさん：2018/04/01(日) 15:12:47.23 .net: オブジェクト指向＝再利用の認識の人ってまだいるんだ
113 ：仕様書無しさん：2018/04/01(日) 15:36:20.72 .net: >>112
地球が真っ二つになったエピソードで見るのやめた
114 ：仕様書無しさん：2018/04/01(日) 18:48:36.51 .net: 人間クラスとか現実世界を再現しようとするなよ
115 ：仕様書無しさん：2018/04/01(日) 19:49:08.77 .net: >>87
ステータスの管理だけならば構造体でも良いけど、
実際には>>94のような攻撃や防御といった自分の動作まで記述するから
メインルーチンからはさらに手間がかからなくなる
スライムの攻撃や防御のロジックを別で書くと管理が面倒になる

ちなみにオブジェクト志向はデスクトップのアプリなど、
ユーザーが終了するまで常駐し続けるプログラムには有効だけど、
SI系のバッチプログラムなど一連の処理が順番に流れる手続き型にはあまり向いていない
という、そんな凝ったことをして意味がない
116 ：仕様書無しさん：2018/04/01(日) 19:56:19.28 .net: バカの話は相変わらず長いな
117 ：仕様書無しさん：2018/04/01(日) 21:29:46.71 .net: 例え話の正しい使い方

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

例え話に対する反論方法

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

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

B. に対しては、その例えは正確じゃないと反論するのが正しい。
なぜなら印象操作は例えが正しいことを前提として意味があるので
その例えが間違いであると言うことは、反論として成り立つ
（カレーとウンコは違うので、いくらウンコが臭い排泄物だと言った所でカレーには関係ない話）
例えなのだから正確ではないのは当たり前でそこを指摘すると言い返せない
（カレーはウンコではないのは常識）
118 ：仕様書無しさん：2018/04/01(日) 21:41:14.57 .net: バカの話は相変わらず長いな
119 ：仕様書無しさん：2018/04/01(日) 22:49:51.85 .net: その程度の中長文で理解できない人間はプログラミングに向いてないよな
拒絶反応から否定の逃げ台詞を吐いて逃亡するしかない
120 ：仕様書無しさん：2018/04/01(日) 22:52:09.26 .net: >>119
自己紹介乙
121 ：KAC：2018/04/01(日) 23:08:32.06 .net: なにやら変な話題で盛り上がってんのな

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

「オブジェクト指向じゃなくてもできる」
という指摘はオブジェクト指向を否定するものじゃ無い。
122 ：仕様書無しさん：2018/04/02(月) 10:10:08.67 .net: お前じゃなきゃ実現できない仕事なんて無い。

「お前じゃなくてもできる」
という指摘はお前を否定するものじゃ無い。
123 ：仕様書無しさん：2018/04/02(月) 12:11:56.92 .net: >>109
だからメリットは「使い方の提案を含めたオブジェクトは指向コストを減らす」じゃないの？
124 ：仕様書無しさん：2018/04/02(月) 12:39:42.79 .net: >>123
なんかそういう資料あるの？
125 ：仕様書無しさん：2018/04/02(月) 12:59:33.19 .net: >>124
うん。

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

冷蔵庫を収納に使う話とかわかりやすかった。
126 ：仕様書無しさん：2018/04/02(月) 16:14:28.23 .net: 人間の認識に近いんよ

OOP指向言語なら逆引きができる。
127 ：仕様書無しさん：2018/04/02(月) 17:45:05.58 .net: >>125
ソースは？
128 ：KAC：2018/04/02(月) 18:13:59.61 .net: >>122
そんなもので否定されたら
世の中の大半の人は存在意義無くなるよな
129 ：仕様書無しさん：2018/04/02(月) 20:33:04.06 .net: 自分以外にできるやつがいなくなるまで
コミュニティを小さくすればいいんだ！
130 ：仕様書無しさん：2018/04/03(火) 11:20:33.32 .net: >>127
いまスマホ。
リンク貼るのめんどいから辿ってちょ
131 ：仕様書無しさん：2018/04/03(火) 20:02:23.79 .net: >>130
そんな事実はない
132 ：仕様書無しさん：2018/04/03(火) 23:20:42.41 .net: >>106
> オブジェクト思考は人間の都合のいい解釈で抽象化なされた現実離れしたもの。

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

システム開発してる人にとってはシステム開発で必要なものも「現実」
だけど、人間の都合に良いように～とか言ってる奴の「現実」って
現実世界のシミュレーション限定だろｗ
133 ：仕様書無しさん：2018/04/03(火) 23:22:07.73 .net: オブジェクト思考は人間の都合のいい解釈で抽象化なされたもので
シミュレーションとして生物などを正確に表現することには適してない

と言いたいんだろうなｗ
134 ：仕様書無しさん：2018/04/03(火) 23:28:37.78 .net: やりたいことを抽象化したデザインパターンを
常識として受け入れましょうってのがオブジェクト指向だろ
135 ：仕様書無しさん：2018/04/03(火) 23:43:06.63 .net: 違う。人間が大雑把に考えてる考え方はオブジェクト指向に近いので、
コンピュータ寄りではなくより人間的な考え方をしましょう
っていうのがオブジェクト指向
オブジェクト指向は人間の考え方を表現できるように進化してきた
136 ：仕様書無しさん：2018/04/03(火) 23:47:11.47 .net: ソースコードが長くなると、複数の関数に分けたくなる
↓
関数をバラバラにわけていると、どうしても引数の数が多くなる
↓
関数によって共通する引数があるので、それを構造体にまとめて引数の数を減らす
↓
どうせなら構造体の中に関数を入れてしまえばいいじゃない
↓
構造体の中の値を気にしないように実装したら、なんかソースコードが読みやすくなった気がする
↓
これに名前を付けたのが、カプセル化
137 ：仕様書無しさん：2018/04/04(水) 04:46:26.02 .net: グローバル変数は便利だが管理が面倒だからクラスに入れてその変数に対する処理をクラス関数にする程度にしか思ってない
138 ：仕様書無しさん：2018/04/04(水) 08:20:43.18 .net: public変数の機能を禁止する法案を提出したい
マイクロソフトやオラクルがpublic変数禁止法で訴訟されるような世の中を作りたい

ひさびさにひっかかった・・・orz
139 ：仕様書無しさん：2018/04/04(水) 08:56:46.85 .net: >>137
そりゃまともなコードが書けないわけだわ
140 ：仕様書無しさん：2018/04/04(水) 12:47:34.68 .net: モノつくる時みたいに役割分担を明確にして設計しましょう
カプセル化とか継承とかはそのための手段

程度の認識だわ
141 ：仕様書無しさん：2018/04/04(水) 21:10:53.00 .net: 指向だからええんじゃね

グローバル変数禁止で
142 ：仕様書無しさん：2018/04/05(木) 00:28:53.41 .net: ALLシングルトン
143 ：仕様書無しさん：2018/04/05(木) 07:01:04.00 .net: ALLシングルトンというか手続き型なクラスだらけで
staticと変わらない
144 ：仕様書無しさん：2018/04/06(金) 01:03:31.62 .net: デザパタを批判するときは唯一わかるシングルトンを
持ち出すことしかできない
145 ：仕様書無しさん：2018/04/06(金) 07:34:51.82 .net: >>144
俺はデザパタは嫌いだがシングルトンは大好きなんだ
146 ：仕様書無しさん：2018/04/06(金) 11:39:18.39 .net: ウイングルトンとシングル、どっちもテニス用語なので
シングルトンもテニス関係の言葉だと思っていました。
147 ：仕様書無しさん：2018/04/06(金) 19:47:11.73 .net: 俺もお前もシングルトン
148 ：仕様書無しさん：2018/04/06(金) 19:49:43.96 .net: そしていつでも疎結合
149 ：仕様書無しさん：2018/04/07(土) 04:32:57.07 .net: ガバガバなんですね
150 ：仕様書無しさん：2018/04/08(日) 16:13:10.05 .net: OOPの本質は疎結合

まったく結合を無くしたいんだが良い方法は無いか
151 ：仕様書無しさん：2018/04/08(日) 16:39:24.28 .net: 動的オブジェクト言語を使えばいいのでは
152 ：仕様書無しさん：2018/04/08(日) 16:47:56.67 .net: >>150
シングルトンアルヨ
153 ：仕様書無しさん：2018/04/08(日) 19:43:48.98 .net: DIが思い付くが型を特定しなくともインターフェースが固定されるから駄目だな

じゃあ呼び出しコードも含めて依存性を注入すりゃあ？って事になる
154 ：仕様書無しさん：2018/04/08(日) 19:48:29.64 .net: >>153
え？どんなインターフェースでも使える
メソッドなんてあるの？

コンテナクラスならobjectの中身はとわないんで、
objectであれば十分だから作れるけど
渡すオブジェクトのメソッドを呼ぶなら
そのメソッドがあるインターフェースを持ってないとだめでしょ
155 ：仕様書無しさん：2018/04/08(日) 19:58:03.19 .net: まさにそれさ！インターフェースに依存してるって事は依存性はゼロじゃないって事さ

それでは丸ごとすげ替えるって事は出来ない
更に依存を注入するための機構にも依存してしまう
156 ：仕様書無しさん：2018/04/08(日) 20:02:41.75 .net: >>155
意味が分からん。
実装に依存すると問題が多いから
インタフェースに依存することが
いい方法ですって話なのに、

インタフェースに依存してるじゃんって言われても
だからその素晴らしい方法を目指してるんだがとしか
言えないんだが？
157 ：仕様書無しさん：2018/04/08(日) 20:16:23.28 .net: あと丸ごとすげ替えしたいって言うけど、目的ないでしょ？ｗ

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

すげ替えたくなる対象は互換性がある型
その互換性っていうのがインターフェースそのもの
158 ：仕様書無しさん：2018/04/08(日) 20:18:32.13 .net: 例えば「このオブジェクトはfooメソッドを持っていること」
というのもインターフェースだからね

明示的に書かない言語も有るけど、コードはfooメソッドを持っていること
というのはfooメソッドを使うからであって
明示的に書いてないだけでインターフェースは存在する
159 ：仕様書無しさん：2018/04/08(日) 20:23:58.93 .net: そうだね、明示的になくてもインターフェースは存在するね

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

ではそもそも結合度をゼロにするなんて事は出来ないんじゃないか？
160 ：仕様書無しさん：2018/04/08(日) 20:31:42.75 .net: ゼロにできないから何？
エアバッグ付けても交通事故はゼロにならないよな

で、ゼロにできないから何だって言いたいの？
161 ：仕様書無しさん：2018/04/08(日) 20:32:45.75 .net: > しかも実行時に実装が無ければ余計にタチが悪い

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

なにが言いたいんですか？
162 ：仕様書無しさん：2018/04/08(日) 21:12:12.47 .net: AとBの結合度がゼロってことは、AとBは無関係ってのと同じこと
結合度は低い方が良いと言ったって、ゼロにしろってことじゃないわな
163 ：仕様書無しさん：2018/04/08(日) 21:57:23.36 .net: >>160
でもマシにもなってないんじゃない？
結局、こない未来を想像した時点で失敗なのよ
164 ：仕様書無しさん：2018/04/08(日) 22:09:09.99 .net: そもそも結合度を気にしたい箇所ってお金がかかるとことお金がかからないところを明確にしないと正当性が主張できないよね
全部入れ替えたって大して金のかからない箇所を一生懸命疎結合とか言ってる奴は本当にアホにしか見えないじゃん

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

アプリ単位でこんなこと気にしてるなんて本当は無意味なんじゃねーの？
って思う
165 ：仕様書無しさん：2018/04/09(月) 01:49:44.62 .net: >>163
マシになってるが？

なんでお前勝手に結論づけてるんだ
知らないならまず聞け、話もせずに結論を言うな
166 ：仕様書無しさん：2018/04/09(月) 02:21:02.04 .net: インターフェイスのクラスを継承する場合はやっぱり結合度高いとおもうんだよな。

個人的に疎結合といえばC++のテンプレートだと思う
167 ：仕様書無しさん：2018/04/09(月) 06:00:19.44 .net: >>166
なるほど。C++のテンプレートに疎結合を
意識して考えたことなかったから感心した。
168 ：仕様書無しさん：2018/04/09(月) 06:14:09.96 .net: まさか
呼び出し関係を結合
って思ってる人居ないよね

基礎からやり直したら？
169 ：仕様書無しさん：2018/04/09(月) 07:23:37.69 .net: コピペするとき一緒にコピペする必要があったら結合
170 ：仕様書無しさん：2018/04/09(月) 07:34:02.61 .net: ユニットテストのしやすさが尺度じゃ？
171 ：仕様書無しさん：2018/04/09(月) 08:06:57.70 .net: C++テンプレートなら特定のクラスに依存しない事も可能だぞ。
vectorやlistなんか管理方法を抽象化してる。

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

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

※オブジェクト思考についてよく知らないのは認める
172 ：仕様書無しさん：2018/04/09(月) 08:11:52.00 .net: >>169
俺もその認識
結局エラー出ちゃうんじゃ
修正するのと変わんないじゃん
173 ：仕様書無しさん：2018/04/09(月) 21:24:10.59 .net: C++のテンプレートは的外れだなｗ
あれは極端な言い方をすればクラス定義を作るものなんだから
単体のクラスを作る範囲なら、他のクラスと依存しないという
当たり前のことを言ってるだけだよ

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

>>171がその例だね
他のクラスから呼び出すために、オブジェクトはrun()という
関数（インターフェース）が必要という事になってしまった。
174 ：仕様書無しさん：2018/04/09(月) 22:05:50.79 .net: インターフェイスに依存するのは悪くないのでは？
175 ：仕様書無しさん：2018/04/09(月) 22:22:45.97 .net: 静的言語のインターフェースは実体がありよるからな
どうがんばっても一方が一方を知ってないといけない

依存が拡大しがちだし
モジュールのすげ替えがやりにくい
きがする
176 ：仕様書無しさん：2018/04/09(月) 22:27:27.23 .net: インタフェースをありがたがるのは周回遅れって感じ
177 ：仕様書無しさん：2018/04/09(月) 22:29:02.46 .net: 今どきなら？
178 ：仕様書無しさん：2018/04/09(月) 22:47:17.50 .net: >>168
浅学ですまないのだが少し教えてもらえないだろうか？
モジュールXのクラスAのメソッドが、モジュールYのクラスBのメソッドを呼び出すなら、それは結合してるって言えるんじゃないの？
それとも、その呼び出し関係ってのはもっと別の話？
179 ：仕様書無しさん：2018/04/10(火) 00:55:45.03 .net: >>178
モジュールXのインターフェースZを作成し
モジュールYのメソッドでZを使い
モジュールXの外でモジュールYをnewして
モジュールXのコンストラクタなどで
モジュールYを渡してれば（依存性注入）
モジュールYはインターフェースZに依存するので疎結合。

モジュールBの中でnewしたら完全に依存するってことだと思ってる。
180 ：仕様書無しさん：2018/04/10(火) 01:05:58.00 .net: >>179
え？何が良くなったの？
181 ：仕様書無しさん：2018/04/10(火) 01:10:21.61 .net: >>178
わかりにくかったのでもっかい書く

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

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

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

そして結合疎結合の本質は>>169が良いこと言ってて、コピペした時に芋ずる式に他モジュールが付いてくるか否かで測れる。

C++のテンプレートの疎結合性は的外れ的なコメントがあったけど、個人的にはコピペの原則に当てはめると立派な疎結合してるように感じた。
182 ：仕様書無しさん：2018/04/10(火) 01:14:07.38 .net: 疎結合合戦をしたいわけじゃなくて
関連があるなら結合があるべきだし
関連がないならあるべきでないしって話であるべきだよね？

ネジでくっつけるところをマグネットで付けて喜んでるアホに見える
183 ：仕様書無しさん：2018/04/10(火) 01:18:55.41 .net: >>182
ワロタww
その通りだよ

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

ハローワールドを画面に出力するのに、いろんなモジュール作ったりして遠回しに実現することは、イケてない。
184 ：仕様書無しさん：2018/04/10(火) 01:53:40.12 .net: >>179
XYZの使い方が下手で読みにくい
そういうところのセンスだよ、オブジェクト指向に大切なのって
185 ：仕様書無しさん：2018/04/10(火) 02:03:59.52 .net: なんとなく思った事を、一言だけ言わせてくれ

マ板じゃなくて厶板でやれ
186 ：仕様書無しさん：2018/04/10(火) 06:53:32.48 .net: ここでいいよ
187 ：仕様書無しさん：2018/04/10(火) 09:06:36.39 .net: >>184
だから書き直したんじゃん
。・゜・(ノД`)・゜・。
188 ：仕様書無しさん：2018/04/10(火) 09:10:01.78 .net: C++のテンプレートみたいにインターフェース以外で
疎結合を実現する方法って他に何があるの？
189 ：仕様書無しさん：2018/04/10(火) 10:45:43.04 .net: 自然言語処理の知識はゼロなのでわからないです。面白いアイデアだと思うので、Twitterの自然言語処理が専門の方々に聞いてみては？
https://peing.net/ja/q/417c9e29-35de-4c95-8323-afd6a50fcbc7

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

例えば第二次大戦の推移について、言葉ではな
くて動画で理解する方法もあります。
言葉で説明するよりもマインクラフトのような
創作ゲーム表現に変えたほうが分かりやすいで
す。
けれども自分が読み漁った人工知能や自然言語
処理の本にはそうしたアプローチは見つからな
かったです。
言語はただの記号の羅列で機械は現実世界を全
く知らない。でもそういうことなら、
テレビゲームのような仮想世界をインプットし
て、自然言語で操作したらいいと思います。
というか自然言語入力でときめきメモリアルみ
たいなゲームをやってみたいてす。
190 ：仕様書無しさん：2018/04/10(火) 14:06:04.12 .net: >>188
pythonの関数はどうだろう？
191 ：仕様書無しさん：2018/04/10(火) 14:59:07.58 .net: >>190
詳しく
192 ：仕様書無しさん：2018/04/10(火) 23:28:17.29 .net: >>191
pythonの関数の引数は型を明記しない（一応type hintはあるが・・・）
その為C++のtemplate関数みたいな使い方にできる。

ただ>>182-183のいう事もごもっともだとおもいます。
193 ：仕様書無しさん：2018/04/11(水) 00:21:14.21 .net: >>192
なるほど

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

うーんと、C++のテンプレートがただ型の異なるコードに対応できるものと考えると、C++のテンプレートって疎結合関係ないような気がしてきた。型専用のマクロみたいなものか
194 ：仕様書無しさん：2018/04/11(水) 00:51:38.94 .net: クラスに依存しないで仕様に依存するのが疎結合じゃないの？
195 ：仕様書無しさん：2018/04/11(水) 04:53:13.04 .net: >>194
仕様に依存ってどういうこと？
196 ：仕様書無しさん：2018/04/11(水) 22:43:47.41 .net: >>193
> ダックタイピングって言うんだっけ？pythonやJavaScriptみたいな言語は型に縛られないからC++のようなテンプレートを必要としないってことか。

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

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

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

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

// objはhelloメソッドを持っていること　　← 結局これがインターフェース
foo(obj) {
　obj.hello();
}
197 ：仕様書無しさん：2018/04/12(木) 01:08:59.73 .net: >>196
そういう初心者プログラマ向けの注釈が必要ってことは想定せずに会話したいね
198 ：仕様書無しさん：2018/04/12(木) 07:07:30.91 .net: 疎結合の話が途中に出てくる
https://qiita.com/carotene555/items/942bef4c7b1529cff572
199 ：仕様書無しさん：2018/04/14(土) 11:50:31.79 .net: デザインパターンをインターフェースから説明した良心的なブログ
途中で息切れしてるみたい？？

https://blogs.yahoo.co.jp/kamyu_2010/35417803.html
200 ：仕様書無しさん：2018/04/14(土) 11:51:40.87 .net: コピペしなくて良いよ
201 ：仕様書無しさん：2018/04/14(土) 11:51:47.87 .net: ウンコの子
202 ：仕様書無しさん：2018/04/14(土) 12:05:02.07 .net: 設計にこだわりすぎるとダメよね
203 ：仕様書無しさん：2018/04/14(土) 12:28:36.90 .net: >>202
そりゃお前程度が設計にこだわったところで大したもんは出てこないし、そもそもしっかり設計されてないと構築できないほどの難度のものには縁がないだろうし
204 ：仕様書無しさん：2018/04/14(土) 13:51:43.02 .net: 設計して実装して
実装が増えてくると設計がダメって気が付いて
コンバータ作って設計やり直して、
の繰り返し

いきなり完璧な設計できる人尊敬するわ
205 ：仕様書無しさん：2018/04/14(土) 13:55:39.43 .net: >>204
そこで、設計のやり直しじゃなくて
リファクタリング "技術" を使って変化させるんやで？

リファクタリングはクソコードを直すものじゃなくて
設計を安全に変化させる技術だ
206 ：仕様書無しさん：2018/04/14(土) 14:39:11.91 .net: >>205
全く意味わからん
改修作業ってことで見積り出していいですよね？
207 ：仕様書無しさん：2018/04/14(土) 14:59:44.24 .net: >>206
当たり前だろ？

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

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

追加部分だけ請求すればいいわけじゃないんだよ？
もしそんな事してれば、それは馬鹿かマヌケのどちらかだ
208 ：仕様書無しさん：2018/04/14(土) 15:05:03.69 .net: そうなるとリファクタリングって言葉が何で存在するのかわからん
ただの改修作業じゃん
209 ：仕様書無しさん：2018/04/14(土) 15:14:49.00 .net: >>208
改修作業に用いるテクニックのことだけど？

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

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

リファクタリングを行わないで仕様変更しようとすると
構造的に無理な所が出てくるのですぐに破綻する
210 ：仕様書無しさん：2018/04/14(土) 15:19:27.46 .net: リフォームするときに既存の部分に手を入れるのは
当たり前の話なんで「既存の部分修正代」して
別に見積もりを出すことはないだろう

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

それを組み込まないで、追加部分だけで考えるから
デスマになる
211 ：仕様書無しさん：2018/04/14(土) 15:23:41.83 .net: >>209
え？何言ってるのかさっぱりわからない
改修作業の何のための工程なの？
やってもやらなくても実現できる要件は同じなんでしょ？
余計な工数使わないで
212 ：仕様書無しさん：2018/04/14(土) 15:26:14.72 .net: >>211
改修作業の中の工程の一つだけど？
もしかして無計画に改修してる？
213 ：仕様書無しさん：2018/04/14(土) 15:26:41.54 .net: > やってもやらなくても実現できる要件は同じなんでしょ？

リファクタリングすることで要件を楽に実現できる
全体の時間も短くなる
214 ：仕様書無しさん：2018/04/14(土) 15:27:27.13 .net: >>212
普通に要件定義→設計→実装→テストだよ
215 ：仕様書無しさん：2018/04/14(土) 15:27:57.46 .net: リファクタリングはどの工程で何をするの？
216 ：仕様書無しさん：2018/04/14(土) 15:29:15.38 .net: オブジェクトとはすなわち物質、本来形のないバーチャルなものまで、例えば仮想通貨やゲーム内で使われるコインなどの加熱した取引を戒める言葉
217 ：仕様書無しさん：2018/04/14(土) 15:29:30.04 .net: リファクタリングとは、ソフトウェアの外部的振る舞いを保ちつつ、理解や修正が簡単になるように、内部構造を改善することです。
改修作業のことではありません
218 ：仕様書無しさん：2018/04/14(土) 15:30:11.12 .net: >>215
詳細設計は？

リファクタリングは詳細設計を行った後に
その詳細設計に向けて、既存のコードを
不具合なく修正していく作業
219 ：仕様書無しさん：2018/04/14(土) 15:30:32.02 .net: 納品段階で要件定義書をこっそり修正する

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

それこそがリファクタ
220 ：仕様書無しさん：2018/04/14(土) 15:30:44.61 .net: >>217
改修作業に含まれる工程の一つだよ

だから改修作業のことだなんて一言も言っていない
221 ：仕様書無しさん：2018/04/14(土) 15:32:43.01 .net: >>217
じゃあ、基本設計ミスってるときにやる修正みたいなもんなんだ？
222 ：仕様書無しさん：2018/04/14(土) 15:32:55.86 .net: もちろん新規作成でもリファクタリングは行う。
最初から無駄のないコードを書ける人なんていない

リファクタリングを行って（最後にやるという意味ではない）
それでコードは完成する。だからコードを書くときには
必然的にリファクタリングが含まれてる
223 ：仕様書無しさん：2018/04/14(土) 15:33:22.83 .net: >>221
改修じゃないって言ってるのに、修正なんだって
お前日本語わかってないのか？
224 ：仕様書無しさん：2018/04/14(土) 15:34:58.27 .net: 改修を仕様どおりに作らなかったっっものを
直すことだと思ってるんだろｗ
225 ：仕様書無しさん：2018/04/14(土) 15:36:32.78 .net: リファクタリングとかいいから仕事しろよ
226 ：仕様書無しさん：2018/04/14(土) 15:38:52.19 .net: ほらみてみｗ
またリファクタリングが仕事の一部だと理解してないやつが来たｗ
釣れる釣れる釣りまくれーｗ
227 ：仕様書無しさん：2018/04/14(土) 15:40:34.31 .net: デザインパターンをインターフェースから説明した良心的なブログ
途中で息切れしてるみたい？？

https://blogs.yahoo.co.jp/kamyu_2010/35417803.html
228 ：仕様書無しさん：2018/04/14(土) 15:41:24.44 .net: >>226
具体的なメリットが一切わからない
229 ：仕様書無しさん：2018/04/14(土) 15:44:06.74 .net: >>228
開発コストが下がる。バグが減る。
これがメリットだってわからないってこと？
230 ：仕様書無しさん：2018/04/14(土) 15:45:06.32 .net: >>229
どういう理屈で下がるの？
231 ：仕様書無しさん：2018/04/14(土) 15:48:07.00 .net: >>230
簡単に言えば、1000行のコード見てバグを探すのと
100行のコード見てバグを探すの
どちらが時間少なくて済むかって話。

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

同じことを実現するのでも少なくてわかりやすいほうが
コードをレビューする時間は減るし、
バグを入れ込むすきも減る。テストの時間も減る
232 ：仕様書無しさん：2018/04/14(土) 15:48:53.66 .net: >>231
はぁ？
233 ：仕様書無しさん：2018/04/14(土) 15:50:45.35 .net: 反論ないならレスいらないよｗ
234 ：仕様書無しさん：2018/04/14(土) 15:51:50.24 .net: 虚構だよな
235 ：仕様書無しさん：2018/04/14(土) 15:52:19.62 .net: 一人で作っていて書いたコード全部覚えてますってなら
1万行のコードでも良いかもしれないが、
仕事だと、コードのレビューがあって自分以外の人が読むし
バグった時の修正だって、自分以外の人がやるかもしれない

その時に理解しやすいコードとそうでないコードでは
数倍の差がでる。コスト意識を持っていれば
リファクタリングしてようやく完成っていうのがわかるはず
236 ：仕様書無しさん：2018/04/14(土) 15:53:31.77 .net: リファクタリングして完成だし、
仕様が変わって設計も変わったら、
新しい設計にそってコードを変更する必要がある
設計無視した（つまり旧設計の）コードのままではだめ
237 ：仕様書無しさん：2018/04/14(土) 16:16:51.53 .net: 先輩がリファクタリングしたコード、僕には読みにくかったんで、僕にとって読みやすいようにリファクタリングしときました
238 ：仕様書無しさん：2018/04/14(土) 16:19:49.37 .net: >>237
お前がリファクタリングしたコードも読みにくいから俺がリファクタリングしといてやったぞ
239 ：仕様書無しさん：2018/04/14(土) 16:20:04.90 .net: 大体リファクタってそんなのばかりだなあ
240 ：仕様書無しさん：2018/04/14(土) 16:23:12.67 .net: >>238
お前らのコードはリファクタリングすべきだとコンサルに言われたから、外部の業者に入ってもらってリファクタリングするわ、
241 ：仕様書無しさん：2018/04/14(土) 16:24:14.61 .net: >>240
現場がわかってないコンサルのコードでは業務に支障をきたすので現場に則したコードにリファクタリングします
242 ：仕様書無しさん：2018/04/14(土) 16:47:26.25 .net: >>239
犬がおしっこしていくのと似てるよね？
243 ：仕様書無しさん：2018/04/14(土) 16:49:41.20 .net: >>238
アイツ気に入らなかったんでアイツのPCで動かないようにリファクタリングしておきました
244 ：仕様書無しさん：2018/04/14(土) 17:23:54.47 .net: リファックタリング
245 ：仕様書無しさん：2018/04/14(土) 19:03:13.39 .net: コミットのコメントがリファクタリングだらけで
246 ：仕様書無しさん：2018/04/14(土) 19:05:16.63 .net: だから間違った使い方すんなって
"あるべき設計・コード" を考えることがリファクタリングなんじゃなくて
"あるべき設計・コード" に移行していくやり方がリファクタリング

お前らが言ってる読みにくかったんで～は
リファクタリングじゃなくて、
あるべきコードの話になってるだろ
247 ：仕様書無しさん：2018/04/14(土) 20:16:26.49 .net: >>246
僕が思うあるべき設計はそうじゃないのでリファクタリングしときますね^^
248 ：仕様書無しさん：2018/04/14(土) 20:29:14.15 .net: >>247
そこでわざわざリファクタリングっていう必要なくね？

僕が思うあるべき設計の問題でしょう？
249 ：219：2018/04/14(土) 20:45:00.22 .net: まじめにいってるのに
おそらく本当にそうだったんだ
政治的レッテルに使われるのを嫌がって単語がしょうもないＩＴ用語として上書きされたんだ

もっと適切な言葉もあったろうに
胡散臭い呼び方がされてるのは
きっと本当にそのせいなんだ
250 ：仕様書無しさん：2018/04/14(土) 20:54:25.34 .net: あの客ムカツクんで動かなくなるようにリファクタリングしておきました
251 ：仕様書無しさん：2018/04/14(土) 20:55:47.13 .net: >>249
真面目に言ってないじゃん。
どこに「納品段階で」とか「こっそり」とか書いてあんのさ？
252 ：仕様書無しさん：2018/04/14(土) 20:57:46.26 .net: >>251
そんなのスケジュールにねーし
253 ：仕様書無しさん：2018/04/14(土) 20:57:52.54 .net: 本来の意味の話
254 ：仕様書無しさん：2018/04/14(土) 20:59:03.32 .net: >>252
それはお前の問題では？
255 ：仕様書無しさん：2018/04/14(土) 21:00:23.65 .net: >>254
どうやってお客に説明するん？
256 ：仕様書無しさん：2018/04/14(土) 21:29:35.83 .net: >>255
客との話なんだから完全にお前の問題だね
257 ：仕様書無しさん：2018/04/14(土) 21:46:59.35 .net: リファクタリングやるのでお金ちょーだいって？
通らないし必要があるとも思えない
258 ：仕様書無しさん：2018/04/14(土) 21:48:50.97 .net: だいたい本当に効果あるなら
素直な改修より費用下がるはずだしな
259 ：仕様書無しさん：2018/04/14(土) 21:57:51.90 .net: >>257
仕事だろ？なんで必要な仕事で金もらえないんだ？

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

> だいたい本当に効果あるなら
> 素直な改修より費用下がるはずだしな
ただで良いものが作れると思ってんの？
260 ：仕様書無しさん：2018/04/14(土) 22:00:02.06 .net: そんなコードに拘り過ぎてもね
261 ：仕様書無しさん：2018/04/14(土) 22:00:37.11 .net: コード無しで動くものが作れるというのなら
やってみると良い
262 ：仕様書無しさん：2018/04/14(土) 22:00:55.90 .net: >>259
え？
「動きを変えない」のがリファクタだろ？

最終的な製品のよさに一切関係ないじゃん
263 ：仕様書無しさん：2018/04/14(土) 22:33:53.14 .net: >>262
アホかｗ

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

なんで既存の部分を拡張するときに、
既存の部分に一切手を入れずに拡張しないといかんのだ
そんなことをするとシステムが破綻するだろ
そんなの客は望んでない
264 ：仕様書無しさん：2018/04/14(土) 22:48:28.81 .net: ま、客の心理としては、リファクタリングに金なんて出したくないよな
効果があるならちゃんと定量的に示さないと
265 ：仕様書無しさん：2018/04/14(土) 22:49:48.06 .net: >>263
それは改修に必要な作業だろ
設計改善という意味でのリファクタリングとは違う
266 ：仕様書無しさん：2018/04/14(土) 22:52:35.01 .net: >そんなことをするとシステムが破綻するだろ

おれの知る限り実態とはかけ離れてるが
いい脅し文句だな
267 ：仕様書無しさん：2018/04/14(土) 22:57:51.82 .net: >>266
設計を改善しないで拡張ばかり繰り返して
手がつけられなくなったプロジェクトは山ほどあるぞ

リファクタリングの概念がなかったCOBOL時代のプロジェクトなんか
そんな感じで一行修正するだけでもその影響範囲が
どこまであるのかさっぱりわからない状態になってるぞ
268 ：仕様書無しさん：2018/04/14(土) 22:59:08.23 .net: ってか不必要に改変してテスト工数が増えるだけ
そしてそれは既存コードの破壊の可能性を意味する
最も客の信頼を破壊する行為だ
リファクタリングで工数が増える要素はいくらでもあるが
お前が主張する工数が減る要素は欠片も見えない
269 ：仕様書無しさん：2018/04/14(土) 22:59:44.75 .net: >>264
> ま、客の心理としては、リファクタリングに金なんて出したくないよな
> 効果があるならちゃんと定量的に示さないと

なんでそこに客が出てくるのか分からんのだが？
修正＝リファクタリング＋機能追加・変更だろ
270 ：仕様書無しさん：2018/04/14(土) 23:00:19.54 .net: >>268
> ってか不必要に改変してテスト工数が増えるだけ
> そしてそれは既存コードの破壊の可能性を意味する

機能追加したら、どうせ全部テストするだろ？
なにを言ってるんだろうか。
271 ：仕様書無しさん：2018/04/14(土) 23:01:38.09 .net: 実際問題普通に改修したほうが安い

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

へたなこと言ったら将来にわたって改修の割引を要求されるかもしらん
272 ：仕様書無しさん：2018/04/14(土) 23:01:54.81 .net: >>270
影響ないとこはしないよ
273 ：仕様書無しさん：2018/04/14(土) 23:03:08.20 .net: >>269
おまいがリファクタ分の改修工数客からもらえって言いだしたんじゃないんかｗ
274 ：仕様書無しさん：2018/04/14(土) 23:04:27.75 .net: ソースが汚いので綺麗にしておきました
動作は変わりません
とか勝手にやったらちゃんと管理してるようなとこは検収拒否もあり得るレベルだと言うことは認識したほうがいい
275 ：仕様書無しさん：2018/04/14(土) 23:12:05.78 .net: >>273
お前はコード1行ごとに見積もりだしてんのか？

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

>>274
なんで修正しないのにリファクタリングしてんの？
修正の一部にリファクタリングが含まれてるってだけなのに
276 ：仕様書無しさん：2018/04/14(土) 23:19:02.03 .net: 混ぜ込んでばれない程度ならいいけどな
277 ：仕様書無しさん：2018/04/14(土) 23:19:58.46 .net: っていうか、見積もりだす時に
既存のコードの状態に関係なく、
まったく同じ費用を出すのか？

デスマの未来しか見えないなｗ
278 ：仕様書無しさん：2018/04/14(土) 23:20:54.13 .net: >>276
普段からこまめに片付けしてないから
部屋片付けるだけで土日潰れるんやで？ｗ
279 ：仕様書無しさん：2018/04/14(土) 23:27:05.74 .net: 派遣や請け負いだとコードが自分達の資産である意識が低いから読みやすさとかどーでもいい、動いて検収に通りさえすればいいという意識が働く

リファクタリングとかは時間が余った時の暇潰し
280 ：仕様書無しさん：2018/04/14(土) 23:30:29.87 .net: 意識が低いというか実際自分のものじゃないじゃないか

そのうえコード所有者の客が工数くれないのになぜ勝手にやろうとするのか
281 ：仕様書無しさん：2018/04/14(土) 23:33:29.16 .net: >>280
だよな
大きなお世話だと理解しろよな
282 ：仕様書無しさん：2018/04/14(土) 23:37:04.32 .net: >>280
> そのうえコード所有者の客が工数くれないのになぜ勝手にやろうとするのか

え？お前、客がなにかしたいと言った時
工数くれなくても働くの？
タダ働きしてるの？
283 ：仕様書無しさん：2018/04/14(土) 23:37:47.85 .net: >>282
や　ら　な　い　よ　？
284 ：仕様書無しさん：2018/04/14(土) 23:39:11.64 .net: じゃあ工数の中に、やるべきことを含めないで
ぎりぎりの見積もりを出すんだろうねｗ
285 ：KAC：2018/04/14(土) 23:40:38.16 .net: というか、下請け作業の発注元を「客」と表現するのやめとけ。
話が混乱してるぞ。
286 ：仕様書無しさん：2018/04/14(土) 23:41:30.22 .net: 客のせいにしているけど、結局は自分がやるべきことを
やらなくてもいいと思ってるから、低い見積もりだして
どんどんシステムをダメにしていってるってのが
分かってないんだろうね
287 ：仕様書無しさん：2018/04/14(土) 23:44:41.22 .net: やらないほうが安いからやるのがどうかって話してんのに
なんでいつの間にか「やるべきこと」になってんの？
288 ：仕様書無しさん：2018/04/14(土) 23:45:23.28 .net: >>280
だから受け入れ側のコードレビューが大事

どんなコード書かれるかわかったもんじゃない
289 ：仕様書無しさん：2018/04/14(土) 23:46:41.99 .net: >>287
まともなものを作るにはどちらにしろ金がかかる。
まともなものを作るという前提においては
リファクタリングしたほうが安くなる

それに対して、バグばかりでろくに動かない
品質が低いものをでいいだろ、どうせ検収に通ればOK
使うのは俺らじゃないし、で作れば金はかからないだろうが
できるのはゴミ。
290 ：仕様書無しさん：2018/04/14(土) 23:49:46.95 .net: >>287
リファクタしたら少なくともそれまでの手動テストはやりなおしじゃん
稼働実績も影響範囲内でリセットになるし
一般的にいってリファクタすると一時的にせよ品質は下がる

おまえのいってる品質向上の根拠ってどこにあんの？
291 ：仕様書無しさん：2018/04/14(土) 23:50:12.69 .net: >>287×
>>289〇
292 ：仕様書無しさん：2018/04/14(土) 23:58:30.24 .net: >>290
> リファクタしたら少なくともそれまでの手動テストはやりなおしじゃん

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

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

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

> おまえのいってる品質向上の根拠ってどこにあんの？
客観的な計測ツールで計測できることをわざわざ質問しないでくれないかな？
コードの品質を調べるツールならいくらでもあるだろ
http://blog.y-yuki.net/entry/2017/05/13/000000
293 ：仕様書無しさん：2018/04/15(日) 00:04:24.69 .net: >>292
超長いけど全く中身がないなｗ
自分の言葉で説明しろよ
294 ：仕様書無しさん：2018/04/15(日) 00:07:00.26 .net: >>292
おまえさっき改修のために既存部分にも手を入れるって言ってたやん！
つまりコードメトリクス上のスコアを上げるために改修部分に合わせて既存部分も修正するんだろ？

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

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

ちょっと背筋さむくなった
主張が変わってもこのヤバい思考は見覚えがある
…else…
295 ：仕様書無しさん：2018/04/15(日) 00:08:01.95 .net: >>292
意味不明なこと言ってんなよ
客側でした試験もやり直しだし
検収もやり直しだし
今までの実績も無価値になっちゃうし
一体どこに品質を上げる要素があんだよ
寝ぼけてんのかよ
テメーみてーな単価50万じゃすまねーヤツの工数まで無価値にしてんだぞ
テメーだけで仕事やってんのかよ
296 ：仕様書無しさん：2018/04/15(日) 00:10:16.66 .net: >>294
> おまえさっき改修のために既存部分にも手を入れるって言ってたやん！
> つまりコードメトリクス上のスコアを上げるために改修部分に合わせて既存部分も修正するんだろ？

え？既存の部分と結合するのに、その部分のテストはしないつもり？
まさか自分が書いた部分だけをテストすればOKだと思ってる？
297 ：仕様書無しさん：2018/04/15(日) 00:11:26.96 .net: シチュエーションに対する想像力なさすぎやしませんかね
298 ：仕様書無しさん：2018/04/15(日) 00:12:49.27 .net: >>296
曲解し過ぎ
要点は変更する必要もない
コードを見通しが悪いとかいう意味不明な理由で
実績のあるコードを変更してしまうこと
299 ：仕様書無しさん：2018/04/15(日) 00:13:10.47 .net: >>295
> 一体どこに品質を上げる要素があんだよ

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

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

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

コードが単純であればるほど、問題ないねと判断するのが速くなる
逆にコードが複雑だと、なにをやってるのか「解析」しなければいけない
300 ：仕様書無しさん：2018/04/15(日) 00:14:51.21 .net: >>298
> 要点は変更する必要もない

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

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

リファクタリングせずに闇雲に修正していったら
すぐに破綻する
301 ：仕様書無しさん：2018/04/15(日) 00:14:53.02 .net: >>299
全く根拠がねーだよ
お前が言ってるのは全部お前の主観でしかない
今まで本番環境で問題なく動いてた実績を
ゴミにしてまでやってしまっていいことではない
302 ：仕様書無しさん：2018/04/15(日) 00:16:13.53 .net: >>300
お前は見通しが悪いってだけでコードを修正しちまうんだよな？
303 ：仕様書無しさん：2018/04/15(日) 00:16:49.68 .net: >>298
> コードを見通しが悪いとかいう意味不明な理由で
> 実績のあるコードを変更してしまうこと

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

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

実績があるのは修正が入らない状態で、
修正が入るなら実績は意味なくなるよ。
304 ：仕様書無しさん：2018/04/15(日) 00:18:46.54 .net: >>302
> お前は見通しが悪いってだけでコードを修正しちまうんだよな？

お前順番が逆ｗ

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

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

お前は見通しが悪いものを修正するときに
見通しが悪いまま修正するんだな？
そして見通しが悪いまま他の人にレビューさせるわけだよな？
せっかくお前が時間かけて見通しが悪いものを理解しても
その理解は残さず、見通しが悪いまま残しておくと
305 ：仕様書無しさん：2018/04/15(日) 00:18:57.35 .net: >>303
え？修正があるかもしれない？って状況であって修正があるわけじゃないんだよね？
何でその状態でいじっちゃうの？
306 ：仕様書無しさん：2018/04/15(日) 00:20:04.21 .net: 正直既存部分でも
Ｅｃｌｉｐｓｅ機能でメソッド抽出するぐらい見逃してくれとおもわんでもない
307 ：仕様書無しさん：2018/04/15(日) 00:22:58.36 .net: >>305
> え？修正があるかもしれない？って状況であって修正があるわけじゃないんだよね？

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

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

修正するのは大前提。客が修正したいって言ってるんだから
修正するのは決定事項で、修正するかどうかは今の話に関係ない
308 ：仕様書無しさん：2018/04/15(日) 00:24:01.30 .net: >>306
どっちみちそのコードを通るテストをするなら
やっていいよ
309 ：仕様書無しさん：2018/04/15(日) 00:24:11.33 .net: >>307
は？
マジで何言ってるのかわからない
頭大丈夫か？
310 ：仕様書無しさん：2018/04/15(日) 00:24:47.98 .net: >>309
わからないなら、頭が悪いのでは？
311 ：仕様書無しさん：2018/04/15(日) 00:25:30.95 .net: >>310
siriのがマシなレベルでびっくりしてる
312 ：仕様書無しさん：2018/04/15(日) 00:26:40.07 .net: >>311
じゃあsiriと会話してれば良いのでは？ｗ
313 ：仕様書無しさん：2018/04/15(日) 00:27:42.96 .net: サイコパスもいいとこだな
結局リファクタリングのビジネス的なメリットを一切挙げることができてないことに気づいてるの？彼は
314 ：仕様書無しさん：2018/04/15(日) 00:28:43.22 .net: 中身の無い奴ほど長文を書く
315 ：仕様書無しさん：2018/04/15(日) 00:28:48.35 .net: >>313
それはリファクタリング本を書いている人に対して喧嘩を売ってるということでいいの？
316 ：仕様書無しさん：2018/04/15(日) 00:31:15.72 .net: そうではないといいたいところだが実は喧嘩売りたい
マーチンファウラーは悪魔
317 ：仕様書無しさん：2018/04/15(日) 00:31:28.12 .net: >>315
本？急にどうしたの？
どっから本とか出てきた？

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

脳に障害でもあるの？
318 ：仕様書無しさん：2018/04/15(日) 00:33:28.86 .net: 権威に根差してものを考えるタイプなんだろう
たぶん幼少時の教育が悪すぎた
319 ：仕様書無しさん：2018/04/15(日) 00:37:07.39 .net: >>318
技術者にはなるべきではなかったんだろうなぁ
言ってること滅茶苦茶だったし
320 ：仕様書無しさん：2018/04/15(日) 00:44:24.24 .net: ジャップ君もといelse不要ガイジのいなくなった上級雑談スレの惨状を見るにつけ
それはどうか微妙なところ
滅茶苦茶でも一応相手の言うこと聞いてきっちり答えてるから会話が成立する

茶化すだけならサルでもできるし
321 ：仕様書無しさん：2018/04/15(日) 01:38:37.55 .net: 機能追加のために既存コードを改修することをリファクタリングと言ってる人と、設計改善をリファクタリングと言ってる人で平行線
322 ：仕様書無しさん：2018/04/15(日) 02:14:19.62 .net: https://medaka.5ch.net/test/read.cgi/prog/1523721765/

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

コードのにおいとか言われて
他人のコードを場当たり的にぐちゃぐちゃにする新人がまたどれだけ出ることやら
323 ：仕様書無しさん：2018/04/15(日) 03:52:14.93 .net: >>321
どっちもリファクタリングの一部では？
324 ：仕様書無しさん：2018/04/15(日) 04:50:40.58 .net: http://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 ：仕様書無しさん：2018/04/15(日) 06:49:51.02 .net: 定義が現実の課題の何を解決してくれるんだ
326 ：仕様書無しさん：2018/04/15(日) 07:27:26.07 .net: ちゃんと定義しないと何議論してるか分かんないじゃん
327 ：仕様書無しさん：2018/04/15(日) 07:34:53.60 .net: リファクタリングのメリットを定義して欲しい
328 ：仕様書無しさん：2018/04/15(日) 07:41:54.33 .net: リファクタリングをしない工程とはどんな手順を想定していて
リファクタリングをする工程とはどんな手順をを想定しているのか？
工数が減るならそれのどの手順でどんな理由で工数が減るのか？
品質が上がるならそれのどの手順でどんな理由で品質が上がるのか？
また、その品質を判定する基準は何か？
おおよその目処となる数字を入れて説明して欲しい

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

って言われても
( ﾟдﾟ)はぁ？
としか
329 ：仕様書無しさん：2018/04/15(日) 07:48:33.45 .net: 仕様をねじ曲げる事ではない

リファクタするにはユニットテストが重要
330 ：仕様書無しさん：2018/04/15(日) 07:50:21.74 .net: >>329
そんなくだらんレスを付けると
ユニットテスト＝リファクタリングでいいの？
とかくだらないレスに対応することになるわけよ
331 ：仕様書無しさん：2018/04/15(日) 07:51:49.97 .net: コードを整理するには広くて先を見通す視野、ある程度の経験が必要
332 ：仕様書無しさん：2018/04/15(日) 07:53:04.79 .net: 振る舞いが変わっていないことを担保するのがユニットテスト
333 ：仕様書無しさん：2018/04/15(日) 08:00:46.28 .net: >>332
結合にも影響出るよね？
何で担保するん？
334 ：仕様書無しさん：2018/04/15(日) 08:04:44.80 .net: だって求める品質によるもの
複雑さを品質に求める分野もあれば
動きゃよいんだよどうせ派遣だしもあるし
後者にリファクタリングもテストコードも要らんだろ

ところでOOPのスレじゃないのかココ
335 ：仕様書無しさん：2018/04/15(日) 08:05:49.62 .net: >>334
OOPとリファクタリングはなんの関係もないという主張？
336 ：仕様書無しさん：2018/04/15(日) 08:24:47.34 .net: 結合通った後はコードに触ってはいけないという思想はシステムの硬直化を招き定期的なリプレースが必要となる
337 ：仕様書無しさん：2018/04/15(日) 08:40:17.41 .net: リファクタ推奨するメリケン人どもはどうやってそのへんクリアしてるのか知りたい
ほんとに
338 ：仕様書無しさん：2018/04/15(日) 08:56:29.91 .net: >>335
おそれりました

そりゃ
リファクタリングしてテスト通ったコードが
現場で問題出したら
それテストコードのバグだから
339 ：仕様書無しさん：2018/04/15(日) 09:48:16.91 .net: >>335
少しでも関係あればなんでもありっていう主張？
340 ：仕様書無しさん：2018/04/15(日) 09:50:17.26 .net: オブジェクト指向とelseは無関係ではないからelseを使うことの是非について議論したい
341 ：仕様書無しさん：2018/04/15(日) 09:53:16.31 .net: elseとかどうでもいい死ね
342 ：仕様書無しさん：2018/04/15(日) 09:57:01.98 .net: どうでもいいっていうのは、elseを使わないことでどれだけコードの見通しがよくなるかを知らない奴の意見
343 ：仕様書無しさん：2018/04/15(日) 10:01:46.42 .net: 1メソッドの行数が長いゴミの意見
344 ：仕様書無しさん：2018/04/15(日) 10:26:46.73 .net: リファクタリングすれば短くなるし問題ない
345 ：仕様書無しさん：2018/04/15(日) 10:39:41.50 .net: >>340
向こうでやれ
346 ：仕様書無しさん：2018/04/15(日) 11:02:17.65 .net: デザインパターンをインターフェースから説明した良心的なブログ

https://blogs.yahoo.co.jp/kamyu_2010/35417803.html
347 ：仕様書無しさん：2018/04/15(日) 12:23:22.87 .net: >>333
UIテスト
348 ：仕様書無しさん：2018/04/15(日) 12:25:43.59 .net: >>347
バカが納品できねーよ
349 ：仕様書無しさん：2018/04/15(日) 12:27:48.06 .net: >>348
すまん意味不明なので整理してもっかいレスして
350 ：仕様書無しさん：2018/04/15(日) 13:04:27.43 .net: はい、スレ立てた

少し修正するたびに全部テストするのは当たり前
https://medaka.5ch.net/test/read.cgi/prog/1523765051/
351 ：仕様書無しさん：2018/04/15(日) 13:05:51.89 .net: 日本ではアジャイルが流行らないわけだ
352 ：仕様書無しさん：2018/04/15(日) 13:14:22.09 .net: はい、スレ立てたｗ

ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾
https://medaka.5ch.net/test/read.cgi/prog/1523765624/
353 ：仕様書無しさん：2018/04/15(日) 17:47:40.29 .net: ２つもたてたんかい
354 ：仕様書無しさん：2018/04/15(日) 18:59:09.34 .net: まだまだあるぜ

リファクタリングなんて金の無駄
https://medaka.5ch.net/test/read.cgi/prog/1523780004/

ｿｰｽｺｰﾄﾞだけじゃなく設計もﾘﾌｧｸﾀﾘﾝｸﾞしよう！
https://medaka.5ch.net/test/read.cgi/prog/1523772587/
355 ：仕様書無しさん：2018/04/15(日) 19:50:19.56 .net: 勝手に変更する行為をﾘﾌｧｸﾀﾘﾝｸﾞと思い込んでるﾊﾞｶへ
https://medaka.5ch.net/test/read.cgi/prog/1523772103/
356 ：仕様書無しさん：2018/04/15(日) 20:08:29.70 .net: 汚いｺｰﾄﾞを修正のたびに何度も解析するのがプロだろ
https://medaka.5ch.net/test/read.cgi/prog/1523790217/
357 ：仕様書無しさん：2018/04/15(日) 20:51:53.26 .net: こちとら1関数平均1000行コードを相手にしてるんだ
https://medaka.5ch.net/test/read.cgi/prog/1523791012/
358 ：仕様書無しさん：2018/04/15(日) 21:50:17.18 .net: リファクタリングでなにがあったの？
359 ：仕様書無しさん：2018/04/15(日) 21:52:29.67 .net: リファクタリングはゴミ
https://medaka.5ch.net/test/read.cgi/prog/1523793974/
360 ：仕様書無しさん：2018/04/16(月) 14:27:02.06 .net: ところで、オブジェクト指向ってなんですか？
わかりやすく教えてください。
361 ：仕様書無しさん：2018/04/16(月) 14:33:22.45 .net: リファクタリングのことです
362 ：仕様書無しさん：2018/04/16(月) 15:11:03.41 .net: COBOLをリファクタリングしてもオブジェクト指向にはならなくね？
363 ：仕様書無しさん：2018/04/16(月) 15:28:12.64 .net: C言語でもオブジェクト指向な実装はできるんだから、COBOLでも頑張ってやれば出来んじゃね？
364 ：KAC：2018/04/16(月) 17:48:09.62 .net: >>360
「指向」という意味は理解できてる？
365 ：仕様書無しさん：2018/04/16(月) 21:34:26.65 .net: >>1
犬はワンで猫はニャー。
366 ：仕様書無しさん：2018/04/16(月) 21:43:36.62 .net: なんとなく漠然とオブジェクトのほうを指さしているイメージ
367 ：仕様書無しさん：2018/04/16(月) 21:45:28.02 .net: >>363
出来るのは当たり前。
使い物にならない、ってだけ。
368 ：仕様書無しさん：2018/04/16(月) 22:36:43.07 .net: >>364
わからないので教えてください><
369 ：KAC：2018/04/16(月) 22:51:01.08 .net: >>368
じゃあ辞書引いてから出直して
370 ：仕様書無しさん：2018/04/16(月) 23:03:26.64 .net: えらそうに振り回すだけで情報出さないくそＳＥの鏡
371 ：KAC：2018/04/16(月) 23:55:16.32 .net: 調べられる事くらい調べといて貰わないと
時間とスレが無駄に消費されるだけで
百害あって一利無しだろ？
372 ：仕様書無しさん：2018/04/16(月) 23:57:31.81 .net: 百害あって一利なし
確かに
373 ：仕様書無しさん：2018/04/17(火) 00:01:45.95 .net: たぶんお前と一緒にオブジェクト指向の意味を考察したいわけじゃなくて
知ってる人に教えてほしかっただけだとおもうが

知った気な顔しといた挙句横から人に指図するだけで
なんの役にも立ってないおまいはなんなんだ
374 ：仕様書無しさん：2018/04/17(火) 02:16:14.68 .net: じゃあせめてオブジェクト指向とは何か三行で教えて
375 ：仕様書無しさん：2018/04/17(火) 03:03:16.01 .net: ち
ん
ぽ
376 ：仕様書無しさん：2018/04/17(火) 10:18:35.28 .net: 三行もいらない。

オブジェクト指向とはポインター
377 ：仕様書無しさん：2018/04/17(火) 10:52:13.75 .net: 宗教の一種だな
現実に追い詰められたプログラマの心の拠り所

OOP教FP教、DDD教、アジャイル教
経典に描かれた楽園を夢見ても、
クソ客クソPMクソ外注クソコード、現実の苦しみからは救ってくれないのが悲しいね
378 ：仕様書無しさん：2018/04/17(火) 10:56:28.98 .net: ジハードが必要だな。
379 ：仕様書無しさん：2018/04/17(火) 16:14:37.11 .net: >>376
ないわ～
380 ：仕様書無しさん：2018/04/17(火) 19:29:42.72 .net: まあC言語のファイル操作の関数を考えてみればいいんじゃね？

データ（ファイルポインタ）を内包出来ないから毎回持ち回らないといけない

データとその操作をワンセットで扱えるのが利点だと思うが
381 ：仕様書無しさん：2018/04/17(火) 19:31:02.46 .net: 持ち回るというのは引数で指定する必要があるって意味ね
382 ：仕様書無しさん：2018/04/23(月) 11:43:52.16 .net: 疎結合というのは倦怠期でセックスをしなくなった中年夫婦のようなもの
383 ：仕様書無しさん：2018/04/27(金) 01:15:37.94 .net: 誰でもいいから早くオブジェクト指向が何か答えてくれない？
384 ：仕様書無しさん：2018/04/27(金) 02:03:29.94 .net: >>8
385 ：KAC：2018/04/27(金) 07:38:38.15 .net: >>383
「オブジェクト」と「指向」をそれぞれ辞書引けば解るだろ
386 ：仕様書無しさん：2018/04/27(金) 07:45:06.50 .net: >>385
それを語るスレでそんなこと言っちゃうわけ？ww
387 ：仕様書無しさん：2018/04/27(金) 12:41:08.47 .net: >>383
変数とそれを扱う関数をまとめたオブジェクト同士が情報をやりとりしながら動作するソフトを作る設計手法
388 ：仕様書無しさん：2018/04/27(金) 16:06:25.42 .net: >>387
みなさんこれでFAですか？
389 ：384：2018/04/27(金) 18:35:06.26 .net: だからまずWikipedia読もうよ
390 ：仕様書無しさん：2018/04/27(金) 18:40:35.63 .net: >>389
読んだらおまえが報告しろよw
391 ：仕様書無しさん：2018/04/27(金) 19:29:55.50 .net: 関連するデータと手続きを一まとめにしたもの、こいつをオブジェクトと呼ぶことにします

オブジェクトを基本単位にプログラムを作ること、そいつをオブジェクト指向と呼ぶことにします
392 ：仕様書無しさん：2018/04/27(金) 21:07:25.85 .net: オブジェクト指向に必須ではないものを取り除いた
最小限のたオブジェクト指向には
なにがあるのでしょうか？
393 ：仕様書無しさん：2018/04/27(金) 21:55:38.27 .net: オブジェクト
394 ：仕様書無しさん：2018/04/27(金) 22:10:04.98 .net: >>391
この説明以上に必要なことある？
395 ：仕様書無しさん：2018/04/27(金) 22:50:28.34 .net: 結局戦争はなくならなかった
だが変化はあった
396 ：仕様書無しさん：2018/04/27(金) 23:09:28.43 .net: >>391
合ってる。

オブジェクトの性格(？)は、
出来るだけコミュ障(必要最小限)な方がいいと思う。
397 ：仕様書無しさん：2018/04/27(金) 23:41:22.95 .net: 更に、オブジェクトを作るための型、これをクラスと呼ぶこととします（便宜上クラスから作られた実体をインスタンスと表現したりもします）

クラスの定義はまだ台本を書いただけで、インスタンス化されたときにはじめて役者がステージに上がり実際に演技をします
398 ：仕様書無しさん：2018/04/28(土) 02:19:15.08 .net: >>397
蛇足だわ
399 ：仕様書無しさん：2018/04/28(土) 05:35:11.99 .net: オブジェクト指向って何？に対してよくある
バカな説明レベルに戻っとる
400 ：仕様書無しさん：2018/04/28(土) 08:23:55.28 .net: >>399
バカじゃない説明出来るの？
401 ：仕様書無しさん：2018/04/28(土) 09:50:08.01 .net: 猫とかステージとか、例えが出てくるとバカっぽく見える事はあるな
解りやすければ、どんなにバカでもかまわないけど
402 ：仕様書無しさん：2018/04/28(土) 10:21:26.84 .net: もっとお馬鹿っぽいのがよかったな
403 ：仕様書無しさん：2018/04/28(土) 10:45:42.82 .net: わかりやすく例えて説明する
↓
その例えでは完璧に表現できないといちゃもんをつける

例えは所詮例えであって、
わからない人にわかりやすく伝えるための手段なのに
オブジェクト指向の限界みたいな話に持って
いこうとするやつがいるんだよなあぁ

あれは本当に馬鹿
404 ：仕様書無しさん：2018/04/28(土) 10:58:36.25 .net: キャットドア…
405 ：仕様書無しさん：2018/04/28(土) 11:15:21.20 .net: >>404
そう。それも馬鹿ｗ
406 ：仕様書無しさん：2018/04/28(土) 11:15:50.89 .net: 萌えキャラに擬人化するともっとお馬鹿っぽく出来るかも知れない
407 ：仕様書無しさん：2018/04/28(土) 11:55:28.97 .net: これぐらい単純な例のほうがいいわ
https://qiita.com/Nekonecode/items/d194c66ddb8a27dc4345
408 ：仕様書無しさん：2018/04/28(土) 11:59:49.19 .net: ゲームはイメージしやすいかもな
409 ：仕様書無しさん：2018/04/28(土) 12:45:59.35 .net: やっぱりクラスを使わない場合の実装とかクラスライブラリの成長過程を体験しないと本当に理解は出来ないからな
410 ：384：2018/04/28(土) 13:39:43.52 .net: >>390
報告？
あれがよくまとまってるから推奨してるんだが、まさか読まずに言ってるとでも思ったのか？
411 ：仕様書無しさん：2018/04/28(土) 19:03:29.48 .net: 犬猫の説明は有害
あれ誰が始めたんだか
412 ：仕様書無しさん：2018/04/28(土) 19:28:15.44 .net: 別に有害じゃない。

動物がたくさん出てくるゲームを作ろうと思ったら
CatクラスDogクラスは普通に作る。
413 ：仕様書無しさん：2018/04/28(土) 19:34:59.55 .net: >>412
いや、有害。

オブジェクトと生命をごちゃ混ぜに考えるとわけわかんなくなる
414 ：仕様書無しさん：2018/04/28(土) 19:37:19.66 .net: >>413
有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる
415 ：仕様書無しさん：2018/04/28(土) 21:09:33.14 .net: >>412
今時、そんな拡張性のない方法使わんだろ。
振る舞いが動物に見えれば良いんだし。
416 ：仕様書無しさん：2018/04/28(土) 21:40:47.91 .net: >>413
俺は犬猫の説明でオブジェクト指向をふんわり理解して、その少しあとにはもう業務システムに適用してたよ
抽象と具象を行ったりきたりできない人には有害なのかな、、
417 ：仕様書無しさん：2018/04/28(土) 22:18:39.34 .net: ある程度の経験者なら余計なイメージを経由したくは無いだろうな
418 ：仕様書無しさん：2018/04/28(土) 22:47:23.43 .net: ある程度の経験者なら犬猫に惑わされたりしないだろ
419 ：仕様書無しさん：2018/04/28(土) 22:48:31.00 .net: >>415
だからお前の考える世界を実現するために
言ってるんじゃないんだよ
本当にアホだなぁｗ

初心者にわかりやすく説明するために使ってるの
420 ：仕様書無しさん：2018/04/28(土) 22:50:11.70 .net: オブジェクト指向が主流になってもうどれだけ経つよ？
いまだに使いこなせてない意味がわかんないんだけど
421 ：仕様書無しさん：2018/04/28(土) 22:57:29.79 .net: 使えるけど作れない人はいまだに五万といるよ

おまじない的にコピペで出来てしまうからね
422 ：仕様書無しさん：2018/04/29(日) 06:01:59.48 .net: >>414
いいや、有害なのはあんただね！

オブジェクト指向で犬や猫を作ることなんてできたか？
俺はできなかったね！！俺が作ることができたのはボタンを押したら猫の声が出るおもちゃだ。

わかりやすい例え話をするんだったら、ホイールやハンドル、エンジンを使って車を作る例え話をするべきなんだ。
423 ：仕様書無しさん：2018/04/29(日) 06:37:46.24 .net: だって種分類とOOPは何の関係もないし

もし
人類のスーパクラスがあったら
それはネズミの祖先だわい
(ループ開始)
424 ：仕様書無しさん：2018/04/29(日) 06:39:11.67 .net: >>420
人類は100万年経つのに
まだ戦争やってるだろ
425 ：仕様書無しさん：2018/04/29(日) 07:06:24.08 .net: ネズミの祖先が人類のスーパークラスになるの？
426 ：仕様書無しさん：2018/04/29(日) 07:06:54.48 .net: 犬猫とかのあまり実用的でない例を出さなくても
実用的な例で説明したらいいんじゃない？

例えばstringクラスとかなら、実用的だし理解しやすいだろ
427 ：仕様書無しさん：2018/04/29(日) 08:57:23.25 .net: 犬猫で納得する奴はOOPを理解していないよ
428 ：仕様書無しさん：2018/04/29(日) 09:20:13.50 .net: >>419
初心者に媚びて、結局嘘教えるんじゃあ有害なだけだが？
429 ：仕様書無しさん：2018/04/29(日) 09:52:58.94 .net: 適当にいったつもりだったが
思いの外みんな賛同してくれてビビったww
430 ：仕様書無しさん：2018/04/29(日) 09:56:39.30 .net: OOPを知っている人は犬猫をOOPで扱うことができるけど、
OOPを知らない人に犬猫をOOPとして考えた時の話をしても
正しい意味で理解できない。
OOPの犬猫の話はOOPを知っている前提の上で成立しているんだよ。
431 ：仕様書無しさん：2018/04/29(日) 10:13:24.45 .net: >>422
> オブジェクト指向で犬や猫を作ることなんてできたか？

できたぞ？

class Cat
class Dog
432 ：仕様書無しさん：2018/04/29(日) 10:13:58.50 .net: >>429
みんな適当に言ってるお前に合わせてるだけだｗ
433 ：仕様書無しさん：2018/04/29(日) 10:20:02.29 .net: 生きてる価値のないごみクズってホントやだね
せめて生きててごめんなさいって自害でもしてくれれば
少しは可愛げもうまれるんだろうけど
434 ：仕様書無しさん：2018/04/29(日) 10:22:54.35 .net: お前が決めた生きてる価値とやらに合わなければ死ねとかｗ
435 ：仕様書無しさん：2018/04/29(日) 10:31:17.81 .net: 死ねじゃなくて、死んでくださいってお願いだろ？
その願いが聞き届けられることはないけどｗ
かわいそうｗｗｗｗ

あ、100年後には聞き届けられてるかもなーｗｗｗ
436 ：仕様書無しさん：2018/04/29(日) 10:43:13.01 .net: >>430
> OOPを知らない人に犬猫をOOPとして考えた時の話をしても
> 正しい意味で理解できない。

正しい意味で理解できないからだめだっていう
考え方がそもそも間違いだからなぁｗ

中学生ぐらいのレベルでは、原子はそれ以上分解できないという
教えられるが、実際には分解できる。
電流はプラスからマイナスに流れると教えられるが
実際にプラスからマイナスに流れているものはない

例えというのは正しく理解させるためではなく
理解するのに必要な壁を低くするためにある
小さい壁を何度も登っていけば高いところまでいけるが
最初が高いと最初の壁すら登ることさえできない

例えで必要なのは正確さではなく、身近でよく知ってるものに例えることだ
車のパーツとか趣味で車をよく知っている人じゃないとピンとこない
437 ：仕様書無しさん：2018/04/29(日) 10:44:25.55 .net: >>436
それは理解できない人間の詭弁だね
438 ：仕様書無しさん：2018/04/29(日) 10:45:40.52 .net: stringでいいじゃん
439 ：仕様書無しさん：2018/04/29(日) 10:47:03.91 .net: どこでもいいから高いところへ行ければいいと思ってる時点で馬鹿
そんな考えだと行きたいところから遠ざかることもある
440 ：仕様書無しさん：2018/04/29(日) 10:47:36.61 .net: >>437
詭弁ではないと思うが？

反論の一つぐらい言うように
441 ：仕様書無しさん：2018/04/29(日) 10:48:16.57 .net: >>439
途中で方向転換すればいいだけ
急がば回れって言葉知ってる？ｗ
442 ：仕様書無しさん：2018/04/29(日) 10:52:59.05 .net: >>441
急がば回れって知ってる？
どこへ進むのか、進み方もわからん奴にとにかく進めって言っといて急がば回れとか
デタラメにグルグル回っててどうやって目的地につくんですかね
443 ：仕様書無しさん：2018/04/29(日) 10:53:15.44 .net: 途中で方向転換とか、アジャイル厨は消えろ
444 ：仕様書無しさん：2018/04/29(日) 10:53:35.26 .net: >>440
俺は詭弁だと言っているのだから反論する価値もないと判断したということ。
445 ：仕様書無しさん：2018/04/29(日) 10:54:58.78 .net: >>442
進み方が知らないのは初心者
初心者にわかりやすく押している俺は理解してる
普通に目的地につけるが？

え？なに？お前初心者が一人で
頑張ってることを想定してんの？

たとえ話を使って教えている人は誰だよｗ
446 ：仕様書無しさん：2018/04/29(日) 10:55:46.97 .net: >>444
じゃあお前の発言はすべて詭弁だから
反論する価値＝間違いってことですね？
447 ：仕様書無しさん：2018/04/29(日) 10:59:35.03 .net: >>443
アジャイル良いよねｗ
最初から完璧なものを求めても
単に時間がかかるだけでなにも進まない
448 ：仕様書無しさん：2018/04/29(日) 10:59:59.56 .net: >>446
そうですね、あなたがそう思うのならそうなんでしょうね。お好きにどうぞ。
別に俺は困りません。
449 ：仕様書無しさん：2018/04/29(日) 11:00:57.06 .net: > それは理解できない人間の詭弁だね

そうですね、あなたがそう思うのならそうなんでしょうね。お好きにどうぞ。
別に俺は困りません。

完
450 ：仕様書無しさん：2018/04/29(日) 11:09:29.58 .net: 長文は詭弁と定義する
451 ：仕様書無しさん：2018/04/29(日) 11:10:44.68 .net: それが詭弁
452 ：仕様書無しさん：2018/04/29(日) 14:40:29.58 .net: 本読めないな
453 ：仕様書無しさん：2018/04/29(日) 15:44:55.30 .net: 長文が詭弁であって詭弁を読まないとは言っていない
454 ：仕様書無しさん：2018/04/29(日) 15:50:59.82 .net: 読んだ後、詭弁だなで終わるから
なにも学習しない
455 ：仕様書無しさん：2018/04/29(日) 15:54:12.49 .net: よっぽど悔しかったらしいｗ
456 ：仕様書無しさん：2018/04/29(日) 15:58:35.42 .net: >>455
お前がなｗｗｗ
457 ：仕様書無しさん：2018/04/29(日) 16:11:56.61 .net: 悔しくねーしｗ
458 ：仕様書無しさん：2018/04/29(日) 16:14:39.14 .net: すべてのメソッドが怒りに継承されているんですね
459 ：KAC：2018/04/29(日) 17:41:15.78 .net: >>453
少なくともそれは詭弁だな
460 ：仕様書無しさん：2018/04/29(日) 17:44:55.39 .net: >>447
まあ実際には、禄に設計も出来てないのをアジャイルとか言い張ってる偽物が多いけど。
461 ：仕様書無しさん：2018/04/29(日) 18:51:50.74 .net: アジャイル界では、日本の企業で"正しく"アジャイルを導入できてるケースは皆無って言われてるからね
そもそも日本人にアジャイルは向いてないとオレは思う
だからといって、ウォーターフォールが糞であることに変わりはないけどな
462 ：仕様書無しさん：2018/04/29(日) 19:50:46.18 .net: 元々はトヨタの看板方式のソフトウエア版なんだけどね
463 ：仕様書無しさん：2018/04/29(日) 20:25:35.35 .net: >>410
だから読んだらおまえが報告しろよw
464 ：仕様書無しさん：2018/04/29(日) 20:28:53.39 .net: あれ以上まとまっているものに要約は要らんわな
465 ：仕様書無しさん：2018/04/30(月) 12:44:42.99 .net: >>462
トヨタのような一流企業が長い期間をかけて最適化してきたことを、そこらの派遣プログラマで再現するのは大変だろうな
彼らに出来ることはせいぜい本とかwebを読んでわかった気になるぐらい
466 ：仕様書無しさん：2018/04/30(月) 14:04:33.08 .net: >>431
ほほう、その犬や猫は、ご主人に餌を求めたりおしっこ漏らしたりするんですかね？
467 ：仕様書無しさん：2018/04/30(月) 14:05:24.46 .net: >>436
犬や猫はしってるけど、エンジンやタイヤを知らない人なんて見たことない
468 ：仕様書無しさん：2018/04/30(月) 15:01:45.98 .net: >>466
すでにお前の発言は反論済み

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66
>>413
有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる
469 ：仕様書無しさん：2018/04/30(月) 17:37:11.93 .net: >>466
そういう機能を実装すればするよ？
470 ：仕様書無しさん：2018/04/30(月) 19:52:30.01 .net: >>468
えっ、犬とか猫って生物だよね？？
違いましたか？？ww

>>469
じゃあ、実物の猫とほとんど区別がつかない
猫シミュレータ作ってみ？
471 ：仕様書無しさん：2018/04/30(月) 20:00:08.45 .net: >>470
それは機能が多すぎるし複雑すぎるし要件がわからんからできないけど

何が「じゃあ」なのかが一番わからない
それをもって何をいいたいのか
472 ：仕様書無しさん：2018/04/30(月) 20:01:57.13 .net: オブジェクト指向スレにいつも現実世界の物を作ってみろー
というバカが出てくるのか不思議で仕方ない
473 ：仕様書無しさん：2018/04/30(月) 20:07:09.29 .net: >>471
つまり、生物をプログラミングの例えに使うのは
アンチパターンだってこと。

クラスとかモジュールってのは
時計仕掛けとか人形仕掛けのようなものであって

生物を例に出すと混乱の元になる
474 ：仕様書無しさん：2018/04/30(月) 20:11:47.79 .net: >>473
それって、課題の複雑さにお前がついていけなかっただけじゃないの？

誰も「猫を作れ」なんてことを要求はしていないだろう
猫を描いてくださいとか、猫という字を書いてくださいというののちょっと複雑版だっただけだ
おまえなりの切り口で、お前なりの単純化と抽象化をすればよかったんだ

オブジェクト指向にかぎらずプログラムというのは常にそうだ
おまえはプログラムを始めるには幼なすぎたんだ
475 ：仕様書無しさん：2018/04/30(月) 20:12:42.39 .net: >>470
> えっ、犬とか猫って生物だよね？？

お前馬鹿なのか？
今はソースコードの話をしてる
class Dogだからって、生き物の犬のことではない。
仮にclass 車の部品だとしても、
このクラスを実際に車に取り付けられるわけではない。

ほんまにおまえはアホやなｗ
476 ：仕様書無しさん：2018/04/30(月) 20:14:21.15 .net: >>473
> つまり、生物をプログラミングの例えに使うのは
> アンチパターンだってこと。

その理屈だと時計や人形仕掛けもアンチパターンになる。
ゼンマイはどこにあるんですか？ｗ
オイルはどこに塗れば良いんですかｗ
477 ：仕様書無しさん：2018/04/30(月) 20:15:18.35 .net: >>474
> オブジェクト指向にかぎらずプログラムというのは常にそうだ
> おまえはプログラムを始めるには幼なすぎたんだ

そういうことなんだよねｗ
例は例であって、本物ではない。
それは誰もが知っていることなんだけど、
そのレベルで分かってない
478 ：仕様書無しさん：2018/04/30(月) 20:20:41.72 .net: >>475
バカなのはお前だ。

プログラミングやオブジェクト指向がわからない人に
わかりやすく説明する話をしてるんだよ？

犬とか猫って言われたら、犬とか猫をイメージして当然だろ！！
人工知能がどうとか言われる時代なら尚更混乱するわ！！

たしかにEngineクラスを作ったとしても
そのエンジンは実際の車には取り付けられないよ？
でも、ディスプレイの中では取り付けられるよね？

では猫は？ディスプレイの中で現実とそう大差ない猫が作れますか？
479 ：仕様書無しさん：2018/04/30(月) 20:27:16.29 .net: >>477
もちろんそれは前提としてわかってる

例えるとするならどちらの方がわかりやすい？って話だよ
480 ：仕様書無しさん：2018/04/30(月) 20:28:25.39 .net: >>478
お前、サイトの利用者を表すUserオブジェクトを作るときに、現実の人間とそう大差ないものを作ってんの？
481 ：仕様書無しさん：2018/04/30(月) 20:29:27.16 .net: >>479
どっちも大差ないだろ
482 ：仕様書無しさん：2018/04/30(月) 20:32:14.59 .net: >>445をちゃんと読め
わかるようになるまでちゃんとフォローアップするって言ってる人に文句言うのはナンセンス
483 ：仕様書無しさん：2018/04/30(月) 20:40:18.37 .net: >>480
バカじゃん

ユーザーとそう大差ないものを作るわけないだろ？
ユーザーは生物なんだから。人の話聞いてる？？
484 ：仕様書無しさん：2018/04/30(月) 20:40:24.90 .net: たいていの業務だと、猫シミュレーターなんか作らんからな

猫の毛並みだの血統だの
振る舞いっていったら鳴いたりウンコ漏らしたりすることではなく、
猫クラスからデータを取得するとか、ＤＢにデータを保存するとか、
あったとしても自分の値段を算出することぐらいだ
戸惑うのはわかる

でもそのつまづきポイントはそのはるか手前だろ…
485 ：仕様書無しさん：2018/04/30(月) 20:41:24.32 .net: >>478
> では猫は？ディスプレイの中で現実とそう大差ない猫が作れますか？

作る必要がない。
誰でもそれが本物の猫のことではないことぐらいわかってるから
486 ：仕様書無しさん：2018/04/30(月) 20:41:47.86 .net: もう一回かいておくか

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66
>>413
有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる
487 ：仕様書無しさん：2018/04/30(月) 20:43:46.84 .net: 犬猫じゃわからんって言ってる人たちって、これならわかるって説明をいまだに見つけられてないんだよね？
犬猫で説明されてもわからん、かといって他の例で説明されてもわからん、って感じでしょ？
それって、犬猫が悪いんじゃなくて、頭が悪いんだと思う
488 ：仕様書無しさん：2018/04/30(月) 20:45:26.26 .net: >>486
ぼくの過去れす、とか言われても知らねえよw
誰だよこの名無しw
489 ：仕様書無しさん：2018/04/30(月) 20:45:48.06 .net: エンジンやハンドルだと、これがクラスなのか
インスタンスなのか分かりづらいという問題がある

犬や猫だと、これがクラスであり
ポチやタマが、インスタンスだと言って
すぐに理解してくれる
490 ：仕様書無しさん：2018/04/30(月) 20:47:55.65 .net: >>487
> それって、犬猫が悪いんじゃなくて、頭が悪いんだと思う

他人は頭が悪いから、こう考えるんだという想像をしている
俺だったら、こういう勘違いをするという
自分の頭の悪さをかいている
491 ：仕様書無しさん：2018/04/30(月) 20:52:05.58 .net: 犬や猫だと、鳴くという同じメソッドであっても
犬はワンワン、猫はニャーという風に
クラスによって別の処理ができることを説明できる

エンジンやハンドルだと説明できないに
仮にできたとしても、マニアにしか分からん話になる
492 ：仕様書無しさん：2018/04/30(月) 20:56:24.85 .net: たとえ実態とかけはなれていても
オブジェクト指向の犬猫の説明には楽しそうで夢がある
プログラムに魅力を感じ、のめり込んでもらうにはもってこい

なにより大事なことだが、新人には夢をみせておくにかぎるんだ
いきなり現実の無機質なオブジェクト指向をつきつけたら現実に絶望してしまう…
493 ：仕様書無しさん：2018/04/30(月) 21:02:37.09 .net: エンジンやハンドルなどのパーツは
同じ名前のメソッドを持ってないからダメなんだろうな
オブジェクト指向の例えとして使ってもすぐに行き詰まる
494 ：仕様書無しさん：2018/04/30(月) 22:36:29.82 .net: >>493
ハンドルクラスやエンジンクラスがあって、実際のハンドルやエンジンはそのクラスを継承してると考える
ハンドルクラスには、右に回す、左に回す、真ん中を押すというメソッドが有る
で、車にハンドルを乗せる時に、B社のハンドルでもT社のハンドルでも海外製のハンドルでも、必ずハンドルクラスを継承してるので、右に回す、左に回すって事が可能だ
逆に、継承してないハンドルがあれば、それは規格外なので使わないほうが良いと言える
さらにハンドルに企業秘密な技術が使われてて、さらにその技術はハンドル内に隠されて外から見えなかったとしても、中身を気にせず右に回す左に回す事が出来る

で、この説明では>>489に陥る
495 ：仕様書無しさん：2018/04/30(月) 22:48:54.27 .net: > ハンドルクラスやエンジンクラスがあって、実際のハンドルやエンジンはそのクラスを継承してると考える

「実際のハンドルやエンジン」はクラスを継承しているということは
これらはクラスということになる

つまり「実際のハンドルやエンジン」はインスタンスではない

だからこのような説明が必要。
・ハンドルやエンジンというのは共通規格というものがあって、その規格で作られている
・といってもまあメーカーごとに規格違うから互換性ないだろうけどな
・仮にあるとしてだ、ハンドルやエンジンの共通規格を継承して実際のハンドルやエンジンが存在する
・実際のハンドルやエンジンといっても、それは実際に車に取り付けられているものそのものではなく型番みたいなものだ
・同じ型番から作られた製品、実際に車に取り付けられてるやつがインスタンスだ

ややこしいわｗ
496 ：仕様書無しさん：2018/04/30(月) 22:52:16.28 .net: ハンドルクラスやエンジンクラスを継承した、
実際のハンドルやエンジンを表すクラス。

全ての実際のハンドルやエンジンを表すクラスは
全て右に回す、左に回すというメソッドがあり
いかなる実際のハンドルやエンジンを表すクラスも同じ動作をする

継承したクラスは全て同じ動きをするものである
と勘違いするわけだよな

やっぱり例えとしてだめだわ。
分かりづらいし誤解される
497 ：仕様書無しさん：2018/05/01(火) 03:17:11.73 .net: ハンドルやエンジンでオブジェクト指向を説明するのは無理だな
やっぱり犬や猫のほうが良い
498 ：仕様書無しさん：2018/05/01(火) 06:48:54.97 .net: よりダメな例を出して
だから犬猫が良いのよ
という詭弁の典型例
499 ：仕様書無しさん：2018/05/01(火) 07:20:10.51 .net: そういう詭弁は、もっと良い例を挙げれば一発でひっくり返せる
さぁ、犬猫より良い例を出せよ
500 ：仕様書無しさん：2018/05/01(火) 07:37:57.50 .net: 人間でやったら？
日本人と外国人とか
小学生と中学生とか
501 ：仕様書無しさん：2018/05/01(火) 07:42:30.20 .net: 犬猫の方がわかりやすいというのを認めたとしても

クラスを作れるようになったら、犬猫よりも
エンジンと車の方がわかりやすいのは事実。

そうだろ？
502 ：仕様書無しさん：2018/05/01(火) 07:46:53.34 .net: クラスを理解して自分で作れるようになったら、エンジンクラスなんて例にする必要ないじゃん
503 ：仕様書無しさん：2018/05/01(火) 07:52:57.56 .net: >>502
バカなの？理解には理解レベルってのがあるんだよ
504 ：仕様書無しさん：2018/05/01(火) 07:56:38.35 .net: それに、前に誰かが言ってくれたけど
生物を例に出したら、継承って先祖みたいで混乱するじゃん

犬とか猫を使って説明するのはやはりアンチパターン
505 ：仕様書無しさん：2018/05/01(火) 08:00:35.91 .net: >>501
先に出てた説明はエンジンとハンドルだったと思うけど
自分で理解してクラス作れるようになった人向けにはわかりやすい（と主張する）説明とか本末転倒では？
506 ：仕様書無しさん：2018/05/01(火) 08:38:51.09 .net: なんでエンジンクラスをそんなに推してんのw
自分が思いついた考えは特別に感じて捨てられないアレか？
507 ：KAC：2018/05/01(火) 08:42:07.77 .net: エンジンと車の関係と
犬と猫の関係が
同じように語られてるのは何故？
508 ：仕様書無しさん：2018/05/01(火) 10:00:01.05 .net: >>504
> 生物を例に出したら、継承って先祖みたいで混乱するじゃん

哺乳類を先祖って勘違いする人はいないが？
509 ：仕様書無しさん：2018/05/01(火) 10:02:21.95 .net: DNAをプログラムとするなら
OOPの継承とは進化だ！
という意見だよ。
510 ：KAC：2018/05/01(火) 10:06:56.41 .net: >>509
どこがオブジェクト指向の話？
511 ：仕様書無しさん：2018/05/01(火) 10:07:59.18 .net: 加えて継承って訳が悪いと思う
Javaみたいに拡張の方良さげ
512 ：仕様書無しさん：2018/05/01(火) 10:09:29.45 .net: >>510
DNAがOOPだってことさ
513 ：仕様書無しさん：2018/05/01(火) 10:49:53.70 .net: コードそのものを書き換えてしまうDNAは適切な例えじゃ無いよ。
514 ：仕様書無しさん：2018/05/01(火) 11:03:54.60 .net: >>505
違う違う。

クラスには何があるのか把握するのは簡単でしょ。コンストラクタがあってーとか、パブリックやプライベートがあってーとか、extendsつかって継承するんだーとか。

そこまでは頭使わなくても、参考書通りに手を動かしていけば誰だってクラスの定義はできるようになるよね。

問題はそれらを応用してアプリケーションを作るときの話だ。その時に犬とか猫とか言われても訳がわからないだろう？

エンジンと車なら一発で理解できるし、クラスが他のクラスの機能を使うとき、ほとんどの場合継承は使わないことも理解できる。

犬とか猫で学んだ人は、何でもかんでも親クラスに共通する機能を定義した神クラスのアンチパターンを踏んでしまう。あんたも神クラス作ったことあるだろう？？
515 ：仕様書無しさん：2018/05/01(火) 11:26:30.92 .net: 胎児のある時期エラがあったりするので中々味わい深い
516 ：仕様書無しさん：2018/05/01(火) 11:46:27.83 .net: >>508
なんでそういうバカみたいな返信しかできないの？

継承が機能受け継ぎとか親クラスとか言われてて
遺伝を継いだ子供が作れるってことかな？って
間違えて考えてしまう人がいることもわからないわけ？
517 ：仕様書無しさん：2018/05/01(火) 12:16:05.79 .net: >>514
> エンジンと車なら一発で理解できるし、

エンジンは例えばどんなメソッドを持ってんの？
518 ：仕様書無しさん：2018/05/01(火) 12:18:25.61 .net: 自分が考えることはみんなもそう考えるはずだから仕方ないね
519 ：仕様書無しさん：2018/05/01(火) 13:26:53.34 .net: ここで犬にエンジン搭載する方法学んでも仕事で使えないんだよねー...

手続きダラダラ書いちゃうし、ちょっと違う似た機能コピペで量産しちゃうし、小さな変更で何箇所も修正が要るし
520 ：仕様書無しさん：2018/05/01(火) 16:38:21.55 .net: >>516
馬鹿はお前だな
知らない人への説明で継承という言葉だけを
教えて理解しろなんて言わない

継承の親クラスというのは具体的にいうと
哺乳類や動物のことです。
ニワトリクラスであれば鳥類です

重要なのは、これだけで誰でも
容易に理解できるということ

対してエンジンや車は何を継承しているか？
説明してみせよ
521 ：仕様書無しさん：2018/05/01(火) 16:41:28.87 .net: 間違えて理解しそうなら、説明すればいいだけ。
わかりやすいものに例えてね

エンジンや車だとわかりやすい説明ができない
522 ：仕様書無しさん：2018/05/01(火) 18:04:17.51 .net: スレの流れが長すぎて口出しにくいが…

エンジンという抽象クラスの派生クラスとしてロータリーエンジンだのディーゼルエンジンだのを考えれば良いんじゃないのかな
エンジンは自動車や発電機に搭載するためのメソッドを持ってて云々
523 ：仕様書無しさん：2018/05/01(火) 18:35:36.86 .net: 何を身近に感じるかなんて人それぞれだと思うが
524 ：仕様書無しさん：2018/05/01(火) 18:44:36.67 .net: バカの特徴
例え話が好きすぎる
というか例えでしか世界を理解できない
525 ：仕様書無しさん：2018/05/01(火) 19:00:23.08 .net: な
哺乳類クラスって有害だろ
種とクラスを混同して
OOPが理解できなくなる
526 ：仕様書無しさん：2018/05/01(火) 19:09:46.75 .net: >>525
ほんとそれ
527 ：KAC：2018/05/01(火) 19:10:16.34 .net: >>522
外部仕様が変わる奴じゃ無いと教える為に分ける意味が薄いぞ？

>>525
何が有害なのか詳しく。
つか、お前さんがオブジェクト指向をまともに理解できないだけだろ？
528 ：仕様書無しさん：2018/05/01(火) 19:11:39.35 .net: >>516
なにこのバカｗｗｗ
529 ：仕様書無しさん：2018/05/01(火) 19:12:10.27 .net: >>525
俺はもう疲れたので詳しく
530 ：仕様書無しさん：2018/05/01(火) 19:12:53.36 .net: >>528
バカにバカって言われたくねーよバーカ
531 ：仕様書無しさん：2018/05/01(火) 19:15:05.48 .net: >>530
自己紹介おつ
532 ：仕様書無しさん：2018/05/01(火) 19:15:17.97 .net: >>530
ばーか
533 ：仕様書無しさん：2018/05/01(火) 19:16:47.34 .net: >>532
神クラス作ってオブジェクト指向やってるつもりになってろよバーカ
534 ：仕様書無しさん：2018/05/01(火) 19:19:23.66 .net: おまえらみんな平等にバカですからケンカしないでねw
535 ：仕様書無しさん：2018/05/01(火) 19:22:42.79 .net: >>527
生物種アナロジーでクラスを騙っている奴は
OOPを理解できてないよ
536 ：仕様書無しさん：2018/05/01(火) 19:30:44.68 .net: 蛇足だが別案すれば
祖先の形態を継承しつつ
環境に合わせてパーツを変えていく
進化モデルがOOPの実際に近いとおもうのだが

あんまり賛同してくれる人は居ないみたい
537 ：仕様書無しさん：2018/05/01(火) 19:59:16.53 .net: 分類と進化の系譜の両方とも有りな気がする
538 ：仕様書無しさん：2018/05/01(火) 21:06:03.20 .net: オブジェクト指向が理解できないというのが理解できない
少し学べばすぐ実用的なプログラムをオブジェクト指向で書けるようになるっしょ
539 ：仕様書無しさん：2018/05/01(火) 21:07:28.80 .net: >>538
それはお前が天才なだけ
540 ：仕様書無しさん：2018/05/01(火) 21:27:30.27 .net: うむ、天才にしか理解できないオブジェクト指向は我々凡人とってはそこらにありふれた路傍の石にすぎんのだよ
それを理解しようなどと考える事がそもそもの間違いだという事に我々はもっと早く気がつくべきだった
オブジェクト指向などただ黙って右から左にうけ流せばよいのだ
541 ：KAC：2018/05/01(火) 21:52:34.54 .net: >>535
オブジェクト指向では
オブジェクトの何に注目するかは自由。

観点を否定するなら、それに足る理由が必要。
542 ：仕様書無しさん：2018/05/01(火) 21:59:18.22 .net: 生物種アナロジーでクラスを騙っている奴はOOPを
理解できてないよっていってまさか理由を求められるとは思わなかった。
そんなの感覚的にわかるだろ？
感覚的にわかることなんだから理由はいらない
それぐらいのレベルの話なのに、理由を説明しろとかセンスが無いよ
543 ：仕様書無しさん：2018/05/01(火) 22:03:10.51 .net: >>522
> エンジンという抽象クラスの派生クラスとしてロータリーエンジンだのディーゼルエンジンだのを考えれば良いんじゃないのかな
そうなるやろ？
ロータリーエンジンは継承元のエンジンからなにを引き継いでいるのか？
詳しい人ならわかるのかもしれないが、普通はさっぱりだな。

> エンジンは自動車や発電機に搭載するためのメソッドを持ってて云々
エンジンは自動車、発電機の他、船、航空機、芝刈り機、などなどに
搭載するためのメソッドを持っていて・・・

ほら、神クラスになっちゃったｗ
こっちの方だよ、神クラスになるのは
自然な流れで証明できたじゃないかｗ
544 ：仕様書無しさん：2018/05/01(火) 22:04:34.28 .net: 対象重視型
545 ：仕様書無しさん：2018/05/01(火) 22:11:27.98 .net: んー
じゃ哺乳類クラスを拡張して猫クラスを作って
546 ：仕様書無しさん：2018/05/01(火) 22:15:08.76 .net: >>545
じゃああんたはエンジンと自動車の方をお願いね
547 ：仕様書無しさん：2018/05/01(火) 22:15:50.25 .net: エンジンや自動車を拡張って無理だろｗｗｗ
548 ：仕様書無しさん：2018/05/01(火) 22:19:13.62 .net: >>545
先に書いておくね

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66
>>413
有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる

class 哺乳類 {
　哺乳類の一般的な特徴
}

class 猫 extends 哺乳類 {
　猫特有の特徴
}

class アレ extends 哺乳類 {
　哺乳類だけど、哺乳類の一般的な特徴に当てはまらないものはここでオーバーライドする
}
549 ：KAC：2018/05/01(火) 22:19:15.37 .net: >>542
理由を説明できないからって誤魔化し始めるのは関心しない。

「お前の考え得る範囲では思いつかない」
と言うことだけは解ったが、
それは他人の設計を否定するものでは無い。
550 ：仕様書無しさん：2018/05/01(火) 22:20:33.98 .net: >>549
生物種アナロジーでクラスを騙っている奴はOOPを
理解できてない

ここだけは認めろ
これは真理だ
551 ：仕様書無しさん：2018/05/01(火) 22:23:04.21 .net: よくヤンキーが自動車を拡張してるな
552 ：仕様書無しさん：2018/05/01(火) 22:27:45.45 .net: え？自動車を広くするの？俺もしたい

って勘違いされやすい。
やっぱりだめだなｗ
553 ：仕様書無しさん：2018/05/01(火) 22:27:56.72 .net: なんだまたバカどもが藻掻きだしたなw
554 ：仕様書無しさん：2018/05/01(火) 22:29:06.33 .net: バカどもへ
生物種アナロジーでクラスを騙っている奴はOOPを
理解できてない。これは真理だから理由を説明する必要はない
555 ：仕様書無しさん：2018/05/01(火) 22:30:33.44 .net: >>554
おまえもやw
556 ：仕様書無しさん：2018/05/01(火) 22:38:13.26 .net: >>551
> よくヤンキーが自動車を拡張してるな

自分だけのオリジナルアバターを作るような感じだと思うが
自動車の拡張は継承ではないな
557 ：仕様書無しさん：2018/05/01(火) 22:49:08.26 .net: バカ「これが真理」

ワロタw
558 ：仕様書無しさん：2018/05/01(火) 23:08:45.44 .net: もうファイルとかディレクトリとかでよくね？
559 ：仕様書無しさん：2018/05/01(火) 23:11:40.89 .net: オリエント指向
560 ：KAC：2018/05/01(火) 23:28:13.79 .net: >>550
うん。
お前には理解できていない。

これだけは理解した。
561 ：522：2018/05/02(水) 00:18:51.14 .net: >>543
要は動力を提供するインターフェースだけなのにどうして神クラスってことになるんだか

あー、いやいや口出して悪かった。
こりゃ議論にならなそうだ。
562 ：仕様書無しさん：2018/05/02(水) 00:40:19.73 .net: >>561
だからエンジンの例えがダメなんだってｗ
証拠あがってるじゃないか

エンジンはなんでも搭載できるわけじゃない
自動車に搭載するなら、自動車に登録するためのインターフェースが必要だし
船に搭載するなら、船に搭載するためのインターフェースがエンジンに必要

エンジンが全てのインターフェースを持っていたらそれは変なので
エンジンからは何も継承するものはない。継承なのになｗ
563 ：仕様書無しさん：2018/05/02(水) 06:34:06.21 .net: エンジンに搭載インタフェース付けたらいいんじゃないの？
自動車や船にそれぞれの搭載の実装書いてエンジンはエンジンの仕事するだけ
564 ：仕様書無しさん：2018/05/02(水) 06:37:50.41 .net: 継承なんて使わないしな
565 ：仕様書無しさん：2018/05/02(水) 07:11:39.04 .net: >>563
アダプターパターンの理解も深まっていいよね
やっぱりエンジンと車の方がわかりやすい
566 ：仕様書無しさん：2018/05/02(水) 07:14:14.15 .net: 生物種アナロジーでクラスを騙っている奴はOOPを理解できてないってのは本当に真実で

ものづくりの世界に生物を持ってきてはならないのだよ。

生物は誰に作られたか考えれば答えは自ずとわかるだろう。
567 ：仕様書無しさん：2018/05/02(水) 09:05:39.99 .net: エンジンというクラスがあると、子はレシプロだのロータリーなど、
レシプロの子に直６だの水平対向だの、分類上は子ができるし、
意味的にメソッドの継承もできるけど、結局ハードとして別個体であって
独立したものだからソフトウェアとしてのOOPでは意味をなさないんだよね。
概念として継承できるけど実装としてそれは独立であり無価値。
568 ：仕様書無しさん：2018/05/02(水) 09:09:20.55 .net: ところが解析的な要因特性で親子構造を構成した場合、共通部と独自部という
形で概念的な継承が意味を持つ。エンジンだとDRBFM的なものの見方をしたときには概念的な階層構造は省力化に大いに役立つ。
569 ：仕様書無しさん：2018/05/02(水) 09:18:18.60 .net: >>567
同じ企画のネジが使えるのは、ネジの形が一緒だからだろ？
でもそれぞれのネジは別個体だ。

クラスってのはどこまでも企画であって、実態はインスタンスだろう？

何も問題ないじゃないか
570 ：仕様書無しさん：2018/05/02(水) 09:36:48.64 .net: >>569
表現不能な個体差がある可能性のある物理的なものはOOPで表現できない
571 ：仕様書無しさん：2018/05/02(水) 09:42:56.67 .net: >>569
問題はそこまでしか説明できないってこと
継承はどこに行ったね？
572 ：仕様書無しさん：2018/05/02(水) 09:52:41.99 .net: >>570
何がいいたいのかよくわからなかった。

俺とお前のiPhoneは同じように見えて、お前のiPhoneは傷だらけだよ？
そんなことはプログラミングの世界では起こらないよね？だからてきかくではないよね？
って事がいいたいの？

どうぶつよりマシだと思うんだけど
573 ：仕様書無しさん：2018/05/02(水) 09:53:35.11 .net: >>571
継承がどうした？流れが早くてわからん。何が知りたいの？
574 ：仕様書無しさん：2018/05/02(水) 09:54:02.30 .net: >>569
厳密に同じにならない。
同じに見えるのは、同じに見える程度の薄っぺらい理解しかしていないから。
575 ：仕様書無しさん：2018/05/02(水) 09:55:22.21 .net: >>574
ごめん君は犬派なの？車派なの？それともまた別なアレなの？
576 ：仕様書無しさん：2018/05/02(水) 09:55:29.02 .net: >>573
ネジを使ってオブジェクト指向を説明するのが難しいって話
どうしても専門的な話になって普通の人にはピンとこない
犬や猫のように文字化な例を使って説明する方がいい
という結論に持っていきましょうｗ
577 ：仕様書無しさん：2018/05/02(水) 09:56:05.40 .net: >>572
お前の持っているiPhoneもエンジンもプログラミングの世界で表現可能なものならばそうなのだろうな。
578 ：仕様書無しさん：2018/05/02(水) 09:58:59.48 .net: 本来は同じクラスでもインスタンスごとに属性が違ってる。
メソッドは同じだが属性は違うのが普通

同じ規格のネジの場合、全てのインスタンスの属性が同じに見えてしまう
どのネジでも同じように使えるから
メソッドが何に相当するのかもわからない

これでオブジェクト指向を説明するのは難しいな
579 ：仕様書無しさん：2018/05/02(水) 10:01:58.83 .net: >>576
別に車とエンジンじゃなくても生物じゃなければいいんだ

>>567が、子クラスが別個体だとか意味わかんないこと言うから
クラスってのは全部設計書であって個体はインスタンスだよね？って主張したくて
ネジの話を持ってきたが、すまん、余計にややこしくなったのでネジの話は忘れてくれ
580 ：仕様書無しさん：2018/05/02(水) 10:04:02.70 .net: >>577
表現可能じゃん

VRの世界に存在するスマホの中でAndroidが立ち上がればいいんでしょ？
581 ：仕様書無しさん：2018/05/02(水) 10:52:15.12 .net: 哺乳類をどんなに拡張しても猫にはならない
なぜなら哺乳類は分類であってクラスじゃないから

DNAがクラス
生物はそのインスタンス
進化はDNAの継承

でOOPはスッキリ理解しましょうｗ。
582 ：仕様書無しさん：2018/05/02(水) 11:02:46.94 .net: >>580
だから、それがお前が認識している表現可能なすべてであるなら、
それでいいんじゃない？
他の人はそうは思わないというだけのことだよ。
583 ：仕様書無しさん：2018/05/02(水) 11:07:02.84 .net: >>581
クラスは分類であって拡張じゃないんだがｗ
584 ：仕様書無しさん：2018/05/02(水) 11:16:34.00 .net: >>582
はいはい、逃げ乙
585 ：仕様書無しさん：2018/05/02(水) 11:20:36.22 .net: VRでiPhoneを再現可能とか、進んでるなぁｗ
586 ：仕様書無しさん：2018/05/02(水) 11:21:53.96 .net: >>585
しかもAndroidが立ち上がるらしいぞ
587 ：仕様書無しさん：2018/05/02(水) 11:41:52.87 .net: >>585
>>586
大切なのはそれが可能である事が明確であることだよ
だからわかりやすいんじゃん。

生物はソフトウェアの世界に作れない。
もちろん、物質もソフトウェアの世界には作れないが近いものは作れる。それは、ゲームやったことある人ならわかるだろう？
588 ：仕様書無しさん：2018/05/02(水) 11:55:15.12 .net: >>587
生物も物質も作れないよ、現在の技術じゃ
できると思っているならそれは傲慢だ
589 ：仕様書無しさん：2018/05/02(水) 11:59:28.80 .net: >>588
ごめん、読み返してもらっていいかな？
590 ：仕様書無しさん：2018/05/02(水) 11:59:29.25 .net: 俺のiPhoneをVRの中にdeep copyすると寸分たがわず同じものが再現できるの？
同じものじゃないけど近いものならできるって？
それはお前が勝手に近いと判断しただけのまがい物だろ？って話だよねｗ
591 ：仕様書無しさん：2018/05/02(水) 12:00:16.20 .net: >>590
iPhoneはソースが公開されてないから
アンドロイドにしてくれ
592 ：仕様書無しさん：2018/05/02(水) 12:01:59.99 .net: オブジェクト指向じゃなくて技術崇拝だなこりゃ
マジキチ
593 ：仕様書無しさん：2018/05/02(水) 12:03:30.99 .net: 統失なんだろうな
自分と他者の境界が曖昧で「我思うすなわち真理」状態に入ってるんだよ
594 ：仕様書無しさん：2018/05/02(水) 12:05:34.51 .net: 叩くことでしか反論できないバカどもめ
ファーーーwww
595 ：仕様書無しさん：2018/05/02(水) 12:10:27.76 .net: 昼になったら変なのが増えたｗ
こんな日に出勤とは社畜の鏡だなｗ
596 ：仕様書無しさん：2018/05/02(水) 12:54:27.05 .net: まとめるとこうかな。

①
システムを設計するのは難しい。だから、わかりやすい解釈（例え）が人間には必要だ。特に初心者にはね！

②
オブジェクト指向の例えとしてよく使われるのが動物や犬猫を使った話だ。これは一見わかりやすく思えるが、根っこに大きな罠があるため、アンチパターンとなる。

③
犬猫の例えがダメな理由は、それが生物を使った例えだからだ。生物とは神の手によって創造されたものであり、人間には作れないものだ。人間に作れるものはカラクリであり、命を創造することはできない。

④
よってオブジェクト指向の例え話は、生物を使わない例えを使用したほうが良い。その例えの候補は、エンジン、タイヤ、ハンドルを使った車の作成の例えである。（ほかにもっといい生物を使わない例があったら教えて）

というわけだ。

現実の猫と区別がつかない猫をVRの世界で作れたら、俺は負けを認める。
597 ：仕様書無しさん：2018/05/02(水) 13:00:27.30 .net: 現実と区別がつかないものを作るための技法じゃないんだよなぁオブジェクト指向って
598 ：仕様書無しさん：2018/05/02(水) 13:03:38.41 .net: ①
システムを設計するのは難しい。だから、わかりやすい解釈（例え）が人間には必要だ。特に初心者にはね！

②
オブジェクト指向の例えとしてよく使われるのが動物や犬猫を使った話だ。これは一見わかりやすく思えるが、
根っこに大きな罠があるため、アンチパターンとなる主張しているが、その罠もアンチパターンも示されていない

③
犬猫の例えがダメな理由は、それが生物を使った例えだからだ。生物とは神の手によって創造されたものであり、
人間には作れないものだ。人間に作れるものは子供だけであり、セックス以外で命を創造することはできない。
同様に勇者、村人、モンスター、命あるものはソフトウェアで表現することはできない
最大の生物である惑星の地球シミュレータなんてもっての外だ。作れるのは神だけだ

④
よってオブジェクト指向の例え話は、生物を使わない例えを使用したほうが良い。その例えの候補は、
エンジン、タイヤ、ハンドルを使った車の作成の例えである。エンジン、タイヤ、ハンドルは
ソフトウェアで作ることができる。3Dプリンタを使えば良いのだ。
599 ：仕様書無しさん：2018/05/02(水) 13:04:51.47 .net: >>597
そうだよ、だから現実に存在する猫は作れないって話ししてんじゃん
600 ：仕様書無しさん：2018/05/02(水) 13:06:33.26 .net: >>598
おまいはどっちの味方なんだww
601 ：仕様書無しさん：2018/05/02(水) 13:06:38.16 .net: >>599
なんで現実に存在する猫を作らないといけないの？
602 ：仕様書無しさん：2018/05/02(水) 13:09:13.68 .net: 3Dプリンタ作ってもいいけどさ、
エンジンを作ることができるクラス設計
というものを見せてほしいんだが。

クラスにあるメソッドとプロパティはなにか？
それがあるとエンジンが作れるんだろう？

エンジンが作れるほどのクラスがあるとするなら
それは形と材料のデータの集まりでしかなく
ソフトウェアのクラスとしては使いものにならないと思うが？
603 ：仕様書無しさん：2018/05/02(水) 13:09:43.01 .net: × 3Dプリンタ作ってもいいけどさ、
○ 3Dプリンタ使ってもいいけどさ、
604 ：仕様書無しさん：2018/05/02(水) 13:10:06.56 .net: >>600
> おまいはどっちの味方なんだww
バカの見方ではないことは確実だなｗ
605 ：仕様書無しさん：2018/05/02(水) 13:10:39.71 .net: >>601
それができたら「ソフトウェアの世界で生物を作れる」と考えてもいいことになり
オブジェクト指向の例えに犬猫を使ってもいいと思えるからだよ
606 ：仕様書無しさん：2018/05/02(水) 13:12:31.56 .net: >>605
だからなんで、クラスの意味を教えるだけなのに、
生物を作らないといけないの？って話をしてるんだが

お前の理屈だとクラスの意味を教えるだけなのに
エンジンを作らないといけないってことになるんだが？
607 ：仕様書無しさん：2018/05/02(水) 13:13:40.24 .net: ぶっちゃけ、オブジェクト指向だけで、
エンジンは作れないよ。

だってエンジンの材料は元をたどれば
全て神が作った物質だから
608 ：仕様書無しさん：2018/05/02(水) 13:16:11.10 .net: >>606
？？？

何回も言ってるけど、おれが言ってるのはオブジェクト指向の例えで動物使うのって混乱の元だよね？って話だよ

車の例えは適当に言ったから、もっとわかりやすいのがあるかもしれないけど、有力なのが他に思いつかないから、生物を使わない例えの一例として言ってるのだよ。

実際、動物より車の例えのほうがいいでしょ。生物っていう作れないものを相手にしてないんだもん。諸悪の根源がなくなって明確だ
609 ：仕様書無しさん：2018/05/02(水) 13:18:39.17 .net: 実装がすでにある生物やエンジンから、逆にOOPの設計を起こそうとしたって
意図を完全に掌握しなければ完全な設計はできないんだよ。
それが神であれ他人であれ。
エンジンならできる気になっているのは知識が薄っぺらいからに他ならない。
なので、いまあるものをOOPで表そうとしている時点で不可能なことに挑んでいる。

あくまで自分で設計し掌握しているものを記述するのがOOP。
ここをはき違えるとエンジンなら再現可能みたいな馬鹿なことを言い出す。
610 ：仕様書無しさん：2018/05/02(水) 13:19:19.04 .net: >>607
それは認めてるって。ソフトウェアの世界は全て実体がないんだから。
611 ：仕様書無しさん：2018/05/02(水) 13:24:47.92 .net: >>609
言ってる事がめちゃめちゃだよww

エンジンを設計したのは人間だ。
オブジェクト指向を使ってアプリを設計するのも人間だよ。

土俵は違うけど、これは設計できる（作れる）ってことじゃん。

おれが言ってるのは人間が作れないものを持ってくるなって話。
612 ：仕様書無しさん：2018/05/02(水) 13:26:28.18 .net: オブジェクト指向だけじゃネジすら作れない。

ネジのクラスか属性になるかは置いといてピッチ（ネジのギザギザ）の幅を
情報として持たせる必要があるだろう。でも単にM6（ネジ山の間隔が1.0mm）と
もたせた所で、ここから3Dプリンタでネジが作れるわけじゃない

3Dプリンタでネジを作ろうと思ったらCADデータが必要
そのデータはクラスの持ってる属性とはまったく別物になるだろう。
ピッチという情報もいらない。形情報があれば済むことだから

つまりオブジェクト指向でクラスに持たせるための情報というのは
現実のものを表現したものではなく、人が持ってる"概要"でしかない。
概要から実際のネジなどの物質が作れないの当然の話

だから動物の場合でも、DNAをクラスの中に持たせるっていうのは
CAD情報をクラスの中に持たせるのと同じで意味不明な理屈
動物の場合でも概要であれば、クラスに持たせられる。

クラスというのは、DNAやCADデータじゃないのだよ
613 ：仕様書無しさん：2018/05/02(水) 13:27:59.92 .net: >>611
おまえエンジン自力で作れるつもりなの？
そこまで究極の馬鹿だったんか？
614 ：仕様書無しさん：2018/05/02(水) 13:29:48.13 .net: >>613
「頑張れば作れる」と「頑張っても作れない」の違いは、大差がないとでも言いたいの？
615 ：仕様書無しさん：2018/05/02(水) 13:30:34.58 .net: >>612
なかなか好感もてた
616 ：仕様書無しさん：2018/05/02(水) 13:32:26.63 .net: >>609
> 実際、動物より車の例えのほうがいいでしょ。生物っていう作れないものを相手にしてないんだもん。諸悪の根源がなくなって明確だ

なんで人間が作れるのかどうかが焦点になってるのか分からんのだが？

人間が作れようが作れまいが、それをソフトウェアで表現するのがクラスだよ。
あくまで表現。実際に作れって話じゃない。実際に作る話だとクラスからじゃ無生物も作れない

オブジェクト指向の設計というのは、すでにあるなにかをオブジェクト指向で表現すること
つまりオブジェクト指向よりも前に、表現したい何かはすでに存在しているということ

だから、人間が作るよりも前に存在している生物は「すでに存在している」ということを
満たしており、むしろ生物の種別をどのように分類するかという試行錯誤が
オブジェクト指向の設計の試行錯誤に近く、よりたとえとして適切

エンジンやネジなんかに例えると、お前がすでに勘違いしているように、このクラスから
実際にエンジンやネジを作れなければならないという話になって、すでにある物の表現ではなく
CADデータの作成の話になってしまう。クラスからエンジンやネジを作れないといけないという話になってしまう
617 ：仕様書無しさん：2018/05/02(水) 13:34:12.24 .net: >>614
現時点で作れないだろ？
お前にとって、エンジンを完全に掌握した他人はエンジンに関しては神にも等しい存在だろ？
できる存在がいることと、お前がそれを設計できることを混同するなよ。
その意味で「大差はない」が答えだ。
618 ：仕様書無しさん：2018/05/02(水) 13:36:00.71 .net: あー馬鹿の相手は疲れるなぁ。
設計から生まれていないものを設計に帰することができるのは神だけだよ。
619 ：仕様書無しさん：2018/05/02(水) 13:37:08.44 .net: エンジンは経験から生まれたもので設計から生まれていない、ってのは常識。
620 ：仕様書無しさん：2018/05/02(水) 13:37:16.84 .net: あー馬鹿の相手は疲れるなぁ。
CADによる設計から生まれたものなら、CADによる設計に帰することができるんだよ
クラス設計ではなくCADの設計な
621 ：仕様書無しさん：2018/05/02(水) 13:37:22.13 .net: >>616
なるほどね
622 ：仕様書無しさん：2018/05/02(水) 13:42:03.05 .net: こいつはCADの設計とクラスの設計をごっちゃにしてるってことでFAだなｗ
623 ：仕様書無しさん：2018/05/02(水) 13:43:53.97 .net: まともに読んでないからこいつが誰なのかわからないけど、
喩え話が下手な奴に喩え話をさせてはいけない、ってのは
よくわかる。
624 ：仕様書無しさん：2018/05/02(水) 13:46:28.14 .net: >>616
プログラミングはものづくりだから、作りたいものがプログラミングによって作れるかどうかは大切だと思ってるんだけど違うの？

あと、実際に作れなんて話、俺してないからね！クソッタレが3Dプリンターとか言い出したせいで、流れがおかしくなったけど、今まで俺が話してきた「作る」って意味は「実体なき存在としてソフトウェアの世界に作る」って意味に決まってんじゃん。

クラスが表現って話は面白いので、もっと語ってくれ
625 ：仕様書無しさん：2018/05/02(水) 13:46:52.29 .net: >>622
だから俺じゃねーから！！
626 ：仕様書無しさん：2018/05/02(水) 13:48:14.02 .net: たのむから>>596を読んでくれ
627 ：仕様書無しさん：2018/05/02(水) 13:49:57.70 .net: >現実の猫と区別がつかない猫をVRの世界で作れたら、

こんなことを言っている時点で何も理解していない感が。
628 ：仕様書無しさん：2018/05/02(水) 13:51:01.71 .net: >>627
なぜ何も理解していない感を感じるのか詳しく。
人を馬鹿にしたお前には答える義務がある。
629 ：仕様書無しさん：2018/05/02(水) 13:51:17.98 .net: >設計から生まれていないものを設計に帰することができるのは神だけだよ。

これが真理だろ
630 ：仕様書無しさん：2018/05/02(水) 13:52:02.62 .net: >>624
> プログラミングはものづくりだから、作りたいものがプログラミングによって作れるかどうかは大切だと思ってるんだけど違うの？

その場合の「もの」とはソフトウェアであって、
現実にある物体ではありません。

> 「実体なき存在としてソフトウェアの世界に作る」って意味に決まってんじゃん。
え、なに？ CADソフトを使ってエンジンやネジを設計するの？

それクラス設計じゃないよねｗ
クラス設計というのは、実体があろうがなかろうが人間が作ろうが神が作ろうかは関係なく
何かを人間が捉えている形に近い形で簡潔に表現しただけのものです。
人間が捉えられてるものなら、生き物だってクラス設計できます。
631 ：仕様書無しさん：2018/05/02(水) 13:52:45.44 .net: >>628
一人でVRVR騒いでなにやってんの？
632 ：仕様書無しさん：2018/05/02(水) 13:53:05.14 .net: >>626
それは前提が間違ってるので的外れ。

クラス設計は、シミュレータではない
ネジのクラス設計は、CADでネジそのものを作ることではない
633 ：仕様書無しさん：2018/05/02(水) 13:53:26.06 .net: >>627
VRなんて言ってんのCAD厨のお前だけじゃんｗ
634 ：仕様書無しさん：2018/05/02(水) 13:53:55.84 .net: >>630
だからCADの話やめてくれない？言い出したの俺じゃないから
635 ：仕様書無しさん：2018/05/02(水) 13:53:58.60 .net: な？俺が最初にかいたとおりになったろ？

414 自分：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66
>>413
有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる
636 ：仕様書無しさん：2018/05/02(水) 13:54:14.04 .net: >>629
哲学的表現で煙に巻こうとしても逃げられないよ？ｗ
637 ：仕様書無しさん：2018/05/02(水) 13:54:55.59 .net: だからCADなんてひとこともいってねー！！！
もうおまえらばか！！ばか！！このわからずや！！
638 ：仕様書無しさん：2018/05/02(水) 13:55:26.09 .net: >>634
じゃあお前はVRの話止めてくれない？

>>596の↓な
> 現実の猫と区別がつかない猫をVRの世界で作れたら、俺は負けを認める。
639 ：仕様書無しさん：2018/05/02(水) 13:55:43.81 .net: >>637
お前のレスの先頭から4文字目～6文字目をよく見るといい。
640 ：仕様書無しさん：2018/05/02(水) 13:55:56.33 .net: >>638
いや、VRはいったよ。別に弁解もないよ
641 ：仕様書無しさん：2018/05/02(水) 13:56:38.47 .net: >>639
子供か
642 ：仕様書無しさん：2018/05/02(水) 13:57:22.17 .net: >>637
CADの話になってるって自分で気づいてないのか？

現実のネジと区別がつかないネジをVRの世界で作るには
CADデータが無いと作れないだろ。

ネジという概念を表すだけのものを作るというのなら
それは犬や猫でもできることだ
643 ：仕様書無しさん：2018/05/02(水) 13:57:54.57 .net: >>630しかまともな回答してくれないよ。
ちょっと疲れたから後で返信する
644 ：仕様書無しさん：2018/05/02(水) 13:58:28.80 .net: >>642
ネジはやめろといっただろ
645 ：仕様書無しさん：2018/05/02(水) 13:58:33.81 .net: >>641
一言も言っていないというから、そうではないことを示しただけだが？
謝れよ。
646 ：仕様書無しさん：2018/05/02(水) 13:58:42.62 .net: > 現実の猫と区別がつかない猫をVRの世界で作れたら、俺は負けを認める。

VRのサメとかあるけどなｗ
647 ：仕様書無しさん：2018/05/02(水) 13:59:08.75 .net: >>645
うるせーガキ
648 ：仕様書無しさん：2018/05/02(水) 13:59:11.44 .net: >>644
> ネジはやめろといっただろ

なぜ？ネジは神が作ったものだからかい？ｗ
649 ：仕様書無しさん：2018/05/02(水) 14:00:38.13 .net: >>646
そのサメはどっちかっていうと遊園地のアトラクションとかのサメだろ。
本物のサメとは違う。人間が作ったものは全てカラクリなんだよ
650 ：仕様書無しさん：2018/05/02(水) 14:02:27.49 .net: >>648
うるさいなww

ネジの話は、サブクラスが実体だみたいなこと言う奴がいたから、インスタンスが実体でしょ？っていうのをわかりやすく説明しようとして失敗しただけ。

もうネジの話はおしまい。
651 ：仕様書無しさん：2018/05/02(水) 14:02:40.48 .net: エンジンでも一緒だよな。現実の世界と区別がつかないエンジンを
VRの世界で作るなら、エンジンのCADデータと高度な物理演算機能を
搭載したシミュレータが必要

そこにVRゴーグルつけた俺がエンジンを手にして、
その重さと臭いを感じられるようにするには・・・
まだまだいろいろ足りないな。

で、クラス設計の話とはまったく違う話になったなｗ
652 ：仕様書無しさん：2018/05/02(水) 14:03:27.86 .net: >>649
> そのサメはどっちかっていうと遊園地のアトラクションとかのサメだろ。
> 本物のサメとは違う。人間が作ったものは全てカラクリなんだよ

故に、人間が作ったエンジンはカラクリですね
653 ：仕様書無しさん：2018/05/02(水) 14:04:17.77 .net: >>652
そのとおり、やっと分かってくれたか
654 ：仕様書無しさん：2018/05/02(水) 14:06:03.77 .net: >>653
おや？だからクラスで生物もエンジンなどの人間が作ったものも
表現することはできないって話なんだが、
そうかやっと分かってくれたかｗ

そうだよな。生物だとDNAに相当するCADデータがないと
VRの世界で本物そっくりのものは作れないしな
655 ：仕様書無しさん：2018/05/02(水) 14:08:00.86 .net: まとめ

生物を作るには生物の設計図であるDNA
機械を作るには機械の設計図であるCADデータ
が必要だが、

クラス設計というのは、それら実際にあるものを人間が
どう捉えているかを表現するものなので、
生物でも機械でもクラス設計を行うことはできる
656 ：仕様書無しさん：2018/05/02(水) 14:08:46.44 .net: クラスを初心者にわかりやすく説明するなら、
身近な例である犬猫で表現したほうが良いってことだな
657 ：仕様書無しさん：2018/05/02(水) 14:17:37.47 .net: >>651
もうつかれたよ。

現実世界にエンジンの生成マシンがあったら
ボタンを押せばエンジンは作れるよね？

これをプログラミングの世界に持ってくると
クラスはエンジン生成マシンと言えるし
実体を作るにはnewすればいい。

わかりやすいでしょ？

でも猫はどお？猫生成マシンなんて現実にはないし
newボタンを押して命を人間が創造するなんて聞いたこともない

だから猫を作ったときは、それは猫型ロボット、つまりドラえもんってことさ、うんこうんこ
658 ：仕様書無しさん：2018/05/02(水) 14:22:46.89 .net: >>657
だから現実世界のシミュレータを作ろう！って
話なんかしてないんだって

仮想世界の猫は、仮想世界の猫生成ボタンで作れる
地面に魔法陣かいて、悪魔召喚することで悪魔を
newできる仮想世界で何を言ってるんだ？
659 ：仕様書無しさん：2018/05/02(水) 14:22:50.89 .net: エンジン推しの言いたいことはわかる。共感はしないけど。

逆に、犬猫で理解できない奴は抽象化ができないってことで、オブジェクト指向に向いた考え方ができるかどうかのふるいになりそうだね。
660 ：仕様書無しさん：2018/05/02(水) 14:24:22.73 .net: >>658
その猫は猫型ロボットであり、猫ではない
661 ：仕様書無しさん：2018/05/02(水) 14:24:52.52 .net: >>657
現実にはない猫生成マシンを
仮想世界には作ることができる。

現実に作れないものは仮想世界にも作れないという
思い込みをしてしまうから、その説明は害悪
662 ：仕様書無しさん：2018/05/02(水) 14:26:14.12 .net: >>661
なるほど、たしかに。

でも作れない動物を作れると思わせる例も同時に害悪だろう
663 ：仕様書無しさん：2018/05/02(水) 14:26:35.78 .net: >>660
> その猫は猫型ロボットであり、猫ではない
当たり前でしょｗ

ソフトウェアで表現したものは猫でもネジでも
本物ではない。本物でなくていいんだよ？

本物でなければならないという思い込みを
してしまってるので、お前はすでに勘違いの
度合いが極限まで進んでしまってる
664 ：仕様書無しさん：2018/05/02(水) 14:27:54.57 .net: >>662
> でも作れない動物を作れると思わせる例も同時に害悪だろう

テレビの中にいる人間は、本物だと思いこんでいる人？

変だな。誰もソフトウェアの中にいるネジが本物だと
思ってる人はいないはずだがｗ

お前、すでに頭がおかしくなってるよ
現実と想像の区別がつかなくなってるよ。
665 ：仕様書無しさん：2018/05/02(水) 14:28:01.92 .net: >>663
だって「オブジェクト指向は現実をそのままソフトウエアに表現する」とか意味わかんない解説よくされるし
666 ：仕様書無しさん：2018/05/02(水) 14:28:49.54 .net: >>664
人のことを糖質みたいに言うなww
667 ：仕様書無しさん：2018/05/02(水) 14:29:44.24 .net: ツリーっていうデータ構造があるけど、図解するときは決まって頂点がルートで、リーフは下方向に広がっている
本物の木はそういう構造をしてないから、ツリーという名前もしくは図解の仕方は害悪
初心者の理解を妨げてる
668 ：仕様書無しさん：2018/05/02(水) 14:30:00.73 .net: >>665
されてないよ
669 ：仕様書無しさん：2018/05/02(水) 14:31:12.16 .net: >>668
え、うそ？されてるでしょ
670 ：仕様書無しさん：2018/05/02(水) 14:33:26.12 .net: >>665
> だって「オブジェクト指向は現実をそのままソフトウエアに表現する」とか意味わかんない解説よくされるし

あ「表現」という言葉の意味がわかってないのね。

https://yuuma7.com/ラリベラの岩窟教会群を歩いて観光してみた感想/
> ゴルゴタ聖堂（ベテ・ゴルゴタ）
> ラリベラ王の墓所だったともいわれるのがゴルゴタ聖堂だ。その名の通り、
> イエス・キリストが処刑された地を想って造られた教会で、
> 角ばった建造物には形の違う窓が3つあり「三位一体」を、
> ｂｭりぬかれたクャ鴻Xは「キリスャg」を表現してｂ｢る。

はい、くりぬかれたクロスは「キリスト」を表現していますが、
くりぬかれたクロスは「キリスト」なのでしょうか？

違いますね。「表現」とは本物でも本物を再現することでもありません。
「表現」しているだけです。
671 ：仕様書無しさん：2018/05/02(水) 14:34:54.54 .net: >>670
ソフトウェア自体が実態の出さないものだから全て表現だわな
672 ：仕様書無しさん：2018/05/02(水) 15:30:38.86 .net: >>667
作業の都合上の理由で上下が逆になってるだけで同じ構造では？
673 ：仕様書無しさん：2018/05/02(水) 16:04:07.98 .net: ＞クラスは分類であって拡張じゃない

犬猫モデルの犠牲者がここにも
674 ：仕様書無しさん：2018/05/02(水) 16:39:06.74 .net: >>673
なんか言えよｗ
675 ：仕様書無しさん：2018/05/02(水) 18:14:09.43 .net: クラスは類なんだよなぁ

インスタンスはクラスを拡張してるわけじゃないんだよなぁ
676 ：仕様書無しさん：2018/05/02(水) 20:33:11.74 .net: ネコ型ロボットはどちらになりますか？
677 ：仕様書無しさん：2018/05/02(水) 20:38:46.35 .net: >>676
文脈次第
ネコ型ロボットをプログラム中でどう扱いたいかによる
そういう質問が出てくるのはオブジェクト指向を理解できていない証拠
678 ：仕様書無しさん：2018/05/02(水) 20:40:32.07 .net: AIBOはどうでしょうか？
679 ：仕様書無しさん：2018/05/02(水) 20:46:50.11 .net: >>678
エンジンと同じ扱いでどうでしょうか？
680 ：仕様書無しさん：2018/05/02(水) 21:38:58.45 .net: >>675
クラスはクラスやな
バカはホンマに例えが好きなんやなあw
681 ：仕様書無しさん：2018/05/02(水) 21:40:05.74 .net: クラスがわからない人への説明で、クラスはクラスで終わってどうするｗ
前提が分かってない
682 ：仕様書無しさん：2018/05/02(水) 21:41:28.22 .net: >>681
未知の概念は何かに例えて理解できるものではないんやなあw
バカは例えで曲解するけどw
683 ：仕様書無しさん：2018/05/02(水) 21:48:58.61 .net: 頭で考えて理解出来るものでもないな
ある日突然悟るものだし
684 ：仕様書無しさん：2018/05/02(水) 22:03:15.81 .net: > 未知の概念は何かに例えて理解できるものではないんやなあw

理解できるだろ？
何を言ってるんだろうか？
685 ：KAC：2018/05/02(水) 22:03:46.43 .net: >>680
それ以上説明できないってのは
内容を正しく理解できていないって事。
686 ：仕様書無しさん：2018/05/02(水) 22:05:59.13 .net: 元彼がなんというかものの例えが
理解出来ない人だった。

具体的に言うと
福山雅治のスコールという歌が私は好きでよく聞いてたんだけど
その歌が
「汗をかいたアイスティーと
取りすぎたポラロイド写真」
って歌詞から始まるんだけど元彼が聞くたびに
「アイスティーが汗かくわけないじゃんwwwwww」と失笑する。
最初はスルーしてたけどあまりにも
何度も言うからくどいなと思って
いや、机に置いてあるアイスティーの氷が溶ける程長くその場にいたとか
夏の暑さの表現でしょ。と言っても

「でもアイスティーは無機物だから汗かかないから日本語おかしいじゃん？｣

とこちらをバカにしたように言ってきたり、その他にも歌詞とか宣伝の
「まるで〇〇のような～」とか「××みたいな～」とかの例え話に
「いや、でもそれは〇〇とか××とは違うじゃん。俺現実主義者だから」
と真顔で言い始めたので
この人本当に例え話が理解出来てないんだ、と思ったら冷めた。
現実主義者とは全く意味が違うのにそれも理解してなかった。
687 ：仕様書無しさん：2018/05/02(水) 22:12:31.97 .net: >>684
そら例えは理解できるやろwそれを曲解と言うとるんやなあw
688 ：仕様書無しさん：2018/05/02(水) 22:18:06.04 .net: >>686
よく見たらおまえ例えもわかっとらんやんw
689 ：仕様書無しさん：2018/05/02(水) 22:18:18.15 .net: 自分にとってデメリットしか無いのに
なぜ素直に受け取らないで曲解するの？

もしかして「曲解」の意味もわかってない？
「表現」の意味も知らなかった人と同じかな

> きょっ‐かい〔キヨク‐〕【曲解】
>
> ［名］(スル)物事や相手の言動などを素直に受け取らないで、ねじまげて解釈すること。
690 ：仕様書無しさん：2018/05/02(水) 22:22:18.76 .net: >>688
それコピペだよ♪
691 ：仕様書無しさん：2018/05/02(水) 22:26:07.47 .net: >>690
なんやwあまりにもおまえらっぽすぎてガチやと思ったわw
692 ：仕様書無しさん：2018/05/02(水) 22:29:09.90 .net: >>691
こんなものに引っかかったのか
マヌケだな
693 ：仕様書無しさん：2018/05/02(水) 22:31:19.10 .net: >>692
でもおまえも例えすらわかっとらんのやろw
694 ：仕様書無しさん：2018/05/02(水) 22:32:52.70 .net: >>693
じゃあ例えの意味言ってみ
695 ：仕様書無しさん：2018/05/02(水) 22:35:24.65 .net: >>694
なんでこのタイミングでいきなり命令口調やねんwそもそもがアホやんおまえw
696 ：仕様書無しさん：2018/05/02(水) 22:36:56.07 .net: 例え話の効果はかなり高いからなぁ
多分うまいたとえ話に嫉妬してるんやろう
697 ：仕様書無しさん：2018/05/02(水) 22:38:56.15 .net: クラスを犬や猫に例えるのは
わかりやすいし確かに良い例えだよね
698 ：仕様書無しさん：2018/05/02(水) 22:53:09.34 .net: 犬やネコを見たことない人には不適切だな
やはり食い物がいいよ
699 ：仕様書無しさん：2018/05/03(木) 02:11:10.62 .net: でも、犬クラスも猫クラスも派生クラスだけどな。
700 ：仕様書無しさん：2018/05/03(木) 09:50:29.16 .net: モデリングの意味も知らない奴が「例え話」とか言って誤魔化すから余計意味不明になる。
701 ：仕様書無しさん：2018/05/03(木) 11:54:02.45 .net: >>699
うーん、50点
702 ：仕様書無しさん：2018/05/03(木) 11:59:12.12 .net: >>699
ある人が考えた設計が、生物学的に正しい必要はないわけで、
トカゲクラスが犬クラスの派生でも、別に構わないんだけどね。
納得させられるだけの理由があれば。

Personクラスを設計した時に、親クラスに猿人クラスを
設計しないだろ？設計で問われるのは主体がなんなのかということだ。
703 ：仕様書無しさん：2018/05/03(木) 12:12:17.19 .net: >>702
お前のモデリングセンスどうなってんの？
なんでPersonを抽象化したら猿人になんの？
704 ：仕様書無しさん：2018/05/03(木) 13:25:59.67 .net: >>703
なんでPersonを抽象化したら猿人になんの？なんて言ったの？
705 ：仕様書無しさん：2018/05/03(木) 13:35:35.91 .net: person is-a 猿人
706 ：仕様書無しさん：2018/05/03(木) 13:42:22.89 .net: ほらね、こう言う事が起きるから生物は使うべきじゃないんだよ
707 ：KAC：2018/05/03(木) 13:45:45.70 .net: 自動車とか言いだしたから猿人が出てきたんだろう。。。
708 ：仕様書無しさん：2018/05/03(木) 13:52:31.02 .net: >>707
(ﾟДﾟ)ﾊｧ?
709 ：仕様書無しさん：2018/05/03(木) 13:54:24.82 .net: 自動車の基底クラスは馬車
710 ：仕様書無しさん：2018/05/03(木) 13:55:33.19 .net: なんや結局おまえら形を変えた美少女うんこ問題をやりたいだけなんやろw
素直になれやw
711 ：仕様書無しさん：2018/05/03(木) 13:55:33.98 .net: >>706
> ほらね、こう言う事が起きるから生物は使うべきじゃないんだよ

は？ Personクラスを設計した時に、親クラスに猿人クラスを
設計しないだろ？
当たり前過ぎて、親クラスに猿人クラスを設計しないだろ？

このように間違った設計をしないから、
生物を使ったほうがわかりやすいって話なんだが。

なんでオマエは勘違いしたの？
それはオマエの頭の問題だよね？
そうかオマエは親クラスを猿人クラスにするんだーｗ
712 ：仕様書無しさん：2018/05/03(木) 13:56:17.36 .net: >>708
円陣といえばわかるか？
713 ：仕様書無しさん：2018/05/03(木) 14:04:10.08 .net: でもこの恥ずかしい間違いのおかげで>>702は学ぶことができた

だが俺はなにも得ていない
もうこのスレで時間を無駄にするのはやめるわ

じゃあの
714 ：仕様書無しさん：2018/05/03(木) 14:17:05.97 .net: >>自動車の基底クラスは馬車
これが正しい認識

>>自動車の基底クラスは車両
は間違った認識
715 ：仕様書無しさん：2018/05/03(木) 14:42:25.62 .net: >>美少女の基底クラスは人間
これは正しいのか？
716 ：仕様書無しさん：2018/05/03(木) 14:53:47.01 .net: 自動車の基底クラスは馬車
自動車の基底クラスは車両

こういう間違った解釈をするから
自動車はたとえとして不適切なんだよな
717 ：仕様書無しさん：2018/05/03(木) 17:12:48.22 .net: ここは底辺連中が程度の低いところでお互いにマウント取り合おうとしてるスレですね
718 ：KAC：2018/05/03(木) 17:21:12.75 .net: >>715
美少女とは違うが、
>アイドルの基底クラスは人間
これを誤りだと主張する奴は少なからず居る
719 ：仕様書無しさん：2018/05/03(木) 17:34:55.87 .net: >>718
それはアイドルが人間かどうかじゃなくて
アイドルはクラスとすべきかって話だよ

ゲームのジョブみたいに一つしか選べないならクラスで良いかもしれないけど
現実には、アイドル兼農家兼ロリコンという職業もあるわけだし
まあ多重継承するって手もあるけどさ
720 ：仕様書無しさん：2018/05/03(木) 18:06:01.27 .net: 自転車と自動車があるだろ、どっちもタイヤがあるだろそれならこれを抽象化して呼び出したときに画像だけ変えてコード量を減らそうとかな
共有できる処理は基本クラスにして継承してから独自のはここで書き足せば綺麗に楽にするということ
721 ：仕様書無しさん：2018/05/03(木) 18:33:26.55 .net: 画像だけ変えるのにわざわざ別のクラスにすんなよ
722 ：仕様書無しさん：2018/05/03(木) 18:37:35.43 .net: >>720
ゲームならそれでいいが、俺達が住んでるのはゲームの世界じゃない
現実世界だ。現実世界で自転車と自動車で共通する処理なんて無いぞ。
自転車と自動車の違いは画像だけじゃないからな
現実世界と同じように表現できるのがオブジェクト指向だろう
723 ：仕様書無しさん：2018/05/03(木) 19:02:22.85 .net: オブジェクト指向って現実世界を表現できるの？
すげー
724 ：仕様書無しさん：2018/05/03(木) 19:24:29.29 .net: >>719
全然違う
うんこをしないのに排便メゾットを持つべきかって話だよ
725 ：仕様書無しさん：2018/05/03(木) 19:38:30.30 .net: >>724
その話は潰したはずだが？
726 ：仕様書無しさん：2018/05/03(木) 20:41:22.28 .net: >>725
おれにはずっと美少女うんこ問題をあつかっとる様にしか見えんがw
727 ：仕様書無しさん：2018/05/03(木) 21:23:46.95 .net: だから、キャットドア課題をなんとかしろよ、お前らは。
728 ：仕様書無しさん：2018/05/03(木) 22:17:38.96 .net: ほらな。他のたとえを使うと>>726-727のような意味不明な展開になる。

クラスは犬猫で例えたほうが判り易いやろ？
729 ：仕様書無しさん：2018/05/03(木) 22:57:02.61 .net: >>728
いや全然。
プロセス指向からの切り替えだって事説明出来ないまま、犬猫とか出しても有害なだけ。
730 ：仕様書無しさん：2018/05/03(木) 22:58:36.93 .net: じゃー、説明すればいいだけじゃないですかねー、またわかりやすい例えでー
731 ：仕様書無しさん：2018/05/04(金) 00:20:25.97 .net: オブジェクト指向の話をすると、なんで継承の話がメインなんの？
732 ：仕様書無しさん：2018/05/04(金) 00:20:59.32 .net: >>727
ラッカー乙
733 ：仕様書無しさん：2018/05/04(金) 00:22:50.14 .net: それが一番よく使われるからじゃないですかねー
734 ：仕様書無しさん：2018/05/04(金) 00:59:26.21 .net: 継承って密結合になるからフレームワーク使う側なら継承あんま使わなくね？
735 ：仕様書無しさん：2018/05/04(金) 01:00:44.62 .net: オブジェクト指向の本質はオブジェクト同士が協調し合って事を成し遂げるところにあるのであって、継承って二の次三の次だろ
736 ：仕様書無しさん：2018/05/04(金) 01:15:27.22 .net: 継承が話題になるのは、有効活用するのが難しいからでしょうね
データとそれに対する操作をオブジェクトとしてまとめるというのは、誰にでも理解できるから
737 ：仕様書無しさん：2018/05/04(金) 06:13:42.41 .net: >>735
そうそう、もともとはオブジェクトがメッセージをやり取りし合うって概念だしね。
究極を求めるとErlangこそが真のオブジェクト指向であるという噂だし。
738 ：仕様書無しさん：2018/05/04(金) 07:27:26.03 .net: >>736
継承で注意が必要なのは、diamond継承などの矛盾解決や、継承のonoffコントロールの癖だね。
言語によっては、継承に似た別機構で問題を回避してるものもある（Rubyのmixinなど）。
739 ：仕様書無しさん：2018/05/04(金) 07:34:28.59 .net: >>737
実装はそのとおりだけど、更に何故オブジェクト指向が必要になったかと言うと、理由の一つは「システム稼働中の動的入替え」を出来るようにしたかったから。
Erlangは、連続運転の世界規模通信システムを想定していたので、動的入替えの仕掛けを標準で持っている。
740 ：仕様書無しさん：2018/05/04(金) 10:29:35.73 .net: 最初の頃は、継承をどんどんしろ、
だったのが、今は、継承を使うな、
がセオリーだったか？
やれと言われたり、やるなと言われることが変わりすぎて
わけ分からなくなってるのがオブジェクト指向。
741 ：仕様書無しさん：2018/05/04(金) 11:21:51.39 .net: >>740
そんなセオリー有ったかな？
バズワードで購読数稼ごうとしてる孫引き解説記事ではそういう文言見たことあるけど。
継承がどの程度必要かが事前にわかるのは、ルーチンワークを機械化するときくらい。
今時のプロジェクトは大抵は、途中で構成の見直しが必要になる。
なので、継承の構造自体を変える訳だが、期待通りに変わったかどうかのチェックは自動テストで確認するってのが多い。
742 ：仕様書無しさん：2018/05/04(金) 12:18:50.16 .net: > 今時のプロジェクトは大抵は、途中で構成の見直しが必要になる。
> なので、継承の構造自体を変える訳だが、

意味不明
743 ：仕様書無しさん：2018/05/04(金) 12:36:18.62 .net: web限定の話やろw
744 ：仕様書無しさん：2018/05/04(金) 12:50:34.64 .net: web業界が一番進んでるからね。
最新の手法が採用されるのはweb業界
745 ：仕様書無しさん：2018/05/04(金) 12:59:33.16 .net: >>742
ルーチンワークの機械化で済む仕事は減ってきてるからね。
ここ20年くらいのコンピュータ利用ってのは、OA化。
つまり過去数世紀に渡ってやってきた事務作業の機械化だった訳だが、それもほぼ一巡してしまった。
新しい事を試みようとすると、「やってみるまではよく分からない」部分が多いので、ある意味割り切って、途中で構成変更出来るように考えておく。
746 ：仕様書無しさん：2018/05/04(金) 13:42:19.34 .net: どんな仕事でもある程度はやってみなければわからない部分があるが、アホほど見通せる範囲が狭い
不確実性を言い訳にちんたらやってる奴は、少しでも遠くを見渡せるようにスキルアップしてほしい
747 ：仕様書無しさん：2018/05/04(金) 14:26:48.66 .net: 見通せるって豪語してる連中はよくいるけど、見通した気になってるだけの奴が大半
748 ：仕様書無しさん：2018/05/04(金) 14:39:04.77 .net: 不確実性うんぬん言ってる奴はよくいるけど、大して新規性もないのに応用力のなさゆえに
新しい問題に見えてしまってるだけの奴が大半
749 ：仕様書無しさん：2018/05/04(金) 14:48:15.91 .net: まあ俺は20年前にインターネット時代が来ることも
10年前にスマホ時代が来ることも予想していたし、
10年後がどうなっているかも確実に見通してる
750 ：仕様書無しさん：2018/05/04(金) 14:50:31.15 .net: 見渡せる見渡せないは重要じゃなくて
見渡せない部分があることを素直に認めて対応する余地を確保することが重要
これができてない人は仮に全部見渡せていても論外
751 ：仕様書無しさん：2018/05/04(金) 14:55:11.42 .net: 最初から完璧なら後から修正する必要がなくなる
752 ：仕様書無しさん：2018/05/04(金) 15:01:49.31 .net: >>751
こういうカン違いが最悪
ビジネスは常に変化する
それはシステム開発中にでもだ
753 ：仕様書無しさん：2018/05/04(金) 16:24:23.36 .net: >>745
継承の構造自体を変えるってのがわからんので具体例教えて
754 ：仕様書無しさん：2018/05/04(金) 17:52:22.66 .net: オブジェクト前入れ替えじゃねか
755 ：仕様書無しさん：2018/05/04(金) 21:53:29.75 .net: >>753
聞くんなら、自分のコンテキスト教えたほうが良くね？
例えば趣味なのか、仕事なのか、計算モデルは何なのかとか。
俺はDDDに関心あるから、その前提で責務分担の見直し方法に関心がある。
756 ：仕様書無しさん：2018/05/04(金) 21:55:04.32 .net: >>752
ピープルウェアとかデッド・ラインに出てくる「プロジェクトをダメにする自称管理者の勘違い」だもんなあ・・・
757 ：仕様書無しさん：2018/05/04(金) 22:45:58.66 .net: >>755
バカは口出ししないでくれる？
758 ：仕様書無しさん：2018/05/04(金) 22:49:29.79 .net: バカにはもっとキツい言い方せんと理解できんよw
759 ：仕様書無しさん：2018/05/04(金) 23:05:33.89 .net: 計算モデルはなんなのかww
760 ：仕様書無しさん：2018/05/04(金) 23:33:53.03 .net: エンジンと車の解説は、継承なんて使わないよ！コンポジションを使うんだよ！という隠れた意図がある。

だからエンジンと車の例えがイケてるってわけさ
761 ：仕様書無しさん：2018/05/04(金) 23:39:14.97 .net: >>760
なるほど、先に継承はなにかが分かってないと
いけないってことだな
762 ：仕様書無しさん：2018/05/04(金) 23:58:28.63 .net: まあ、処理なんかどこに書いたって見積りは変わんないけどね
763 ：KAC：2018/05/05(土) 01:17:38.83 .net: >>760
そういう喩えでは、
「コンポーネント分ければCで問題なく組めるけど？」
と言う疑問に対して優位性が解りづらい。
764 ：仕様書無しさん：2018/05/05(土) 07:23:08.54 .net: >>763
どういうこと？
765 ：仕様書無しさん：2018/05/05(土) 07:35:28.89 .net: >>761
もちろんそうなるさ

だけど犬猫を使って継承を説明するとワナにかかるから
生物を使わないで継承を説明すればいいってこと。

いろんな種類のエンジンがあって、好きなのを車に搭載できる。スーパークラスってのはその様々なエンジンに共通するインターフェースなんだよ。

って説明するだけで良くない？たしかにマニアックかもしれないけど、もしそうならiPhoneケースでもいいし。

バッテリーを拡張できるスマホケースとか、裏にリングが付いてて持ちやすいケースとかいろいろあるでしょ？
でもiPhoneケースはAndroidスマホには搭載できない。
スーパークラスってのは、iPhoneケースのカメラ部分に穴が空いているといったiPhoneケースの共通点を抽出した規格のことを言うんだ。
もちろんソフトウェアの世界に形はないから、その共通点は機能や役割として抽象化されるんだ。

でわかるじゃん
766 ：仕様書無しさん：2018/05/05(土) 08:46:58.03 .net: >>765
それだとインターフェースの説明にしかならないよな
継承そのものではなく、その利用のしかたのひとつ
767 ：仕様書無しさん：2018/05/05(土) 08:49:21.31 .net: 何処で覚えなさったら知りませんが、
動的入れ替えはOOPとは関係ありません。
768 ：仕様書無しさん：2018/05/05(土) 11:35:07.04 .net: > いろんな種類のエンジンがあって、好きなのを車に搭載できる。
搭載できないよ。車ごとに搭載できるエンジンは決まってる
769 ：仕様書無しさん：2018/05/05(土) 11:44:13.22 .net: 同じエンジンに交換した場合は問題ないけど
違うエンジンに変更した場合は、そのままでは車検が通らない

違うエンジンに変更することをエンジンスワップという
エンジンスワップした場合は構造変更申請が必要
770 ：仕様書無しさん：2018/05/05(土) 11:44:55.02 .net: 横型エンジンには大きく分けて6V系と12V系に大別できます。

6V系はさらに分かれますが、これらの系統間では大きな変更があり、オイ
ルポンプ、クランクシャフト、ピストン、ミッション、キックギアなどが
異なっており、流用は困難か、加工が必要です。

また、同じベンリー（CD）の12Vでも、50ccと90ccではクランクシャフ
ト、ヘッド、ミッション、クラッチが異なっており、流用の際には注意が
必要です。

12V系の機種間の互換性も、モンキー・ゴリラのリターン式、ベンリー
（CD）のロータリーになりますので、この点でも問題になります。

エンジンまるごとの載せかえでは、12Vではモンキー、ゴリラ、カブ、ベ
ンリー（CD）間では可能ですが、マグナについてはできません。
また、その場合でも左クランクケースカバーが違いますので、モンキーに
ベンリー（CD）のエンジンを載せる場合は加工が必要です。
771 ：仕様書無しさん：2018/05/05(土) 11:45:45.94 .net: 同じ駆動方式同士でのスワップは比較的簡単(!?)にエンジン換装は出来ますね。
数年前だとS13シルビアに13B搭載やR31タイプMにVG30搭載などは
エンジンスワップが得意なチューニングショップでは結構ありましたね。
1G搭載車には7Mも比較的加工も少なくスワップ出来ます。
データとノウハウを持ってるお店もいくつかありますしね。
大昔で言えばマツダシャンテ(360ccの軽自動車)に12Aターボぶち込みとか・・
(そんな事考えるのはひとりだけだけど・・・笑)　

で駆動方式の違う物同士でのスワップは無理に近いでしょう。
それこそ新しく作り変えるくらいの作業が必要でしょう。
エンジンのマウントはなんとかなったとしてもそこから先が
かなりな作業になるでしょうね。
それこそ車一台買える以上の金額が必要になるかと・・・。
という事で＃3のおっしゃってる86系のスワップ以外は一般的な作業ではないですね。
772 ：仕様書無しさん：2018/05/05(土) 12:05:23.14 .net: OOPに限らず
ソフト業界って妙な例え用語が多くて
「そのプロセスをキルするんだよ」
とか傍で聴いている一般人はビックリするよね

妙な例えしないほうが解りやすいな
773 ：仕様書無しさん：2018/05/05(土) 12:19:24.00 .net: エンジンや自動車に例えるのは
詳しい人でないとピンと来ないってところなんだよね
774 ：仕様書無しさん：2018/05/05(土) 12:22:59.50 .net: >>772
例えじゃないし一般人もビックリしませんが
775 ：仕様書無しさん：2018/05/05(土) 12:24:41.98 .net: オブジェクト指向は言語に制限されないんだから、ここでCがどうのC#がどうの言うのってスレ違いだよね？
776 ：仕様書無しさん：2018/05/05(土) 12:26:37.57 .net: >>773
じゃあ今後はiPhoneとiPhoneケースでよろしく
777 ：仕様書無しさん：2018/05/05(土) 12:32:00.24 .net: iPhone8を継承して作られたiPhoneXは
大きさも違って、iPhone8用ケースが使えなくなる
こんな感じかな
778 ：仕様書無しさん：2018/05/05(土) 12:32:29.49 .net: プログラマって、たとえ話で説明すると必ずたとえ話の重箱隅を突き始めるバカが湧いてくるよな
会話のエッセンスを抽出して理解、発展させる事ができないのかね
779 ：仕様書無しさん：2018/05/05(土) 12:38:53.71 .net: それは例えた例が悪いからじゃね？
780 ：仕様書無しさん：2018/05/05(土) 12:40:45.03 .net: >>778
そうそう

大切なのはアイディアを出し合って
よりベターな例えを見つけることだ

車とエンジンが例えとしてイケてないのは事実だし
プログラミングの世界に想像できない生物を持ってくる事がイケてないのも事実。

じゃあ、生物を使わないでわかりやすい例えはなんだろう？
それを俺たちでみつければいいのさ
781 ：仕様書無しさん：2018/05/05(土) 12:48:10.80 .net: >>778
> プログラマって、たとえ話で説明すると必ずたとえ話の重箱隅を突き始めるバカが湧いてくるよな
な？俺が最初に言ったとおりだろ

414 名前：仕様書無しさん[sage] 投稿日：2018/04/28(土) 19:37:19.66
>>413
有害なのはお前。
わかりやすく説明するために例え話を使ってるのに、
そこに生命を表すにはどうするんだと言い出すから
お前が混ぜっ返してる
782 ：仕様書無しさん：2018/05/05(土) 12:49:04.27 .net: 例えなきゃならないのは、具体的な案件が諸事情で出せないからだけどな。
社内じゃ例えなんか使わないでダイレクトに案件固有の状況で話すから。
783 ：仕様書無しさん：2018/05/05(土) 12:50:27.24 .net: >>782
あのー、オブジェクト指向が分かってない人への
オブジェクト指向の説明の話なんですけど？
784 ：仕様書無しさん：2018/05/05(土) 13:04:08.74 .net: >>781
お前そのコピペ大好きだなほんと

初心者にはイメージが大切なんだ。
で、プログラムの世界をイメージするのに最適な世界って
ゲームの世界だよな。

そしてプログラミングで大事なのはモジュールという概念だ。
んで、オブジェクト指向では、クラスでモジュールを作成する。

モジュールってのは初心者にわかりやすく説明するならパーツやマシンのことだろう？

そしてそのパーツやマシンを組み合わせて、プログラマが作りたいものを作れるのがプログラミングでありオブジェクト指向じゃないか。

レースゲームでタイヤ変えたりするのが、オブジェクト指向のイメージにぴったりだと思うのは何か間違ってんの？？
785 ：仕様書無しさん：2018/05/05(土) 13:23:28.46 .net: >>783,784
ところでおまえら自身がわかってないのに
どうしてわかってない人への説明などという無謀な挑戦をするのや？
786 ：仕様書無しさん：2018/05/05(土) 13:24:59.69 .net: >>785
と、意味不明な供述をしており・・・
787 ：仕様書無しさん：2018/05/05(土) 13:59:34.24 .net: >>785
もっと意味ある投稿してよ
788 ：仕様書無しさん：2018/05/05(土) 14:44:42.49 .net: >>785
継承が表現できてないから駄目だな
789 ：仕様書無しさん：2018/05/05(土) 15:11:03.82 .net: >>784
お前なにか勘違いしてないか？
犬猫に例えるのが駄目だって言ってるんだよ。
レースゲームがどうとかいう話はしていない
790 ：仕様書無しさん：2018/05/05(土) 15:27:06.19 .net: >>789
話を次のステップに進めたいんだよ俺は

犬猫がダメな理由は犬猫が生物だからだろう？
その次の話をしたいの。生物を使わないわかりやすい例えはなんだろうねって
791 ：仕様書無しさん：2018/05/05(土) 15:37:54.17 .net: > 犬猫がダメな理由は犬猫が生物だからだろう？
理由になってない
792 ：仕様書無しさん：2018/05/05(土) 15:40:38.44 .net: 犬猫が良い理由も犬猫が生物だからなんだけどね

生物であるがゆえに、最初に構造を自分で考える必要がない
なにも知らないで自分で考えるよりも
最初にあるものを例にしたほうがわかりやすいから
793 ：仕様書無しさん：2018/05/05(土) 16:10:35.71 .net: 哺乳類という分類をどんなに拡張しても猫にならない
なので犬猫モデルはダメダメ
794 ：仕様書無しさん：2018/05/05(土) 16:11:35.70 .net: >>791
>>793が理由になってる
795 ：仕様書無しさん：2018/05/05(土) 16:14:56.72 .net: >>793
> 哺乳類という分類をどんなに拡張しても猫にならない
なるぞ？
796 ：仕様書無しさん：2018/05/05(土) 16:16:04.25 .net: エンジンという分類をどんなに拡張しても
ディーゼルエンジンにはならない
797 ：仕様書無しさん：2018/05/05(土) 16:16:09.66 .net: >>784
スーパークラスは規格なんだよ。お家のコンセントが、家によってバラバラだったら家電使えないでしょ？

タイヤにもコンセントみたいな規格があって、その規格にあわせていろんなタイヤを作るから
タイヤが交換できるんだよ。

で、説明可能（ドヤッ
798 ：仕様書無しさん：2018/05/05(土) 16:16:58.29 .net: OOPがモデリングの世界という事を理解してない奴が多いな
犬猫クラスは簡略化された犬猫のモデルであって厳密な犬猫の定義ではない
なので現実の犬猫はああだこうだと細かく指摘するのは無意味
799 ：仕様書無しさん：2018/05/05(土) 16:17:45.97 .net: ごめん>>797は>>788の返信ね
800 ：仕様書無しさん：2018/05/05(土) 16:18:04.20 .net: >>797
でもコンセントの形は各国でバラバラだぞ
801 ：仕様書無しさん：2018/05/05(土) 16:21:08.53 .net: >>795
哺乳類のダメなところは規格きよる分類として
プログラミングと相性が悪いところなんだよ

哺乳類の規格なんて答えられるやついるか？？反面、乾電池の規格はわかりやすいし、
その規格に適応させることで連携稼働するという結果も見られる。
802 ：仕様書無しさん：2018/05/05(土) 16:21:20.93 .net: タイヤの規格を拡張したものがタイヤです
803 ：仕様書無しさん：2018/05/05(土) 16:22:04.15 .net: >>801
> 哺乳類の規格なんて答えられるやついるか？？

哺乳類にあるのは規格じゃなくて性質ですが？
804 ：仕様書無しさん：2018/05/05(土) 16:22:17.63 .net: >>800
そこで、アダプターパターンの説明すれば
オオッ！なるほどデザインパターン大事ですね！ってもっと良いじゃん
805 ：仕様書無しさん：2018/05/05(土) 16:23:12.81 .net: >>803
だからダメなんじゃん。

プログラミングは性質なんて曖昧なもんで繋がってない。
806 ：仕様書無しさん：2018/05/05(土) 16:23:31.71 .net: 「オブジェクト指向の説明に生物は不適切！だからUserクラスとか定義したらダメ！」
807 ：仕様書無しさん：2018/05/05(土) 16:23:53.99 .net: > 乾電池の規格はわかりやすいし、
あ、はい

http://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 直径㎜高さ㎜
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 ：仕様書無しさん：2018/05/05(土) 16:25:01.18 .net: >>805
> プログラミングは性質なんて曖昧なもんで繋がってない。

性質が駄目なら属性でもいいけど？
809 ：仕様書無しさん：2018/05/05(土) 16:25:29.63 .net: >>807
おまえ乾電池使ってる人が全てその認識あるとおもってんの？
もしそうおもってないなら乾電池がわかりやすく使いやすい証明になるんだけど
810 ：仕様書無しさん：2018/05/05(土) 16:25:55.15 .net: >>804
余計混乱するだろうなｗ
811 ：仕様書無しさん：2018/05/05(土) 16:26:21.52 .net: >>809
> おまえ乾電池使ってる人が全てその認識あるとおもってんの？

だからだめなんだよね。
身近な例じゃないから分かりづらい
812 ：仕様書無しさん：2018/05/05(土) 16:27:53.28 .net: >>810
混乱する人にはまだ早いだけでしょ
アダプターパターンを理解するのにこれ以上わかりやすい説明あったら教えてよww

できるなら動物使って説明してみてよwww
813 ：仕様書無しさん：2018/05/05(土) 16:28:35.85 .net: やっぱりわかりやすい
https://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak3/S3-3-1.html

分類概念の上下関係にもとづいてクラスの継承をきちんと作成していくと、「実際にはインスタンスを作成する必要のないクラス」が存在することになります。

例えば、ペットブリーダーを支援するアプリケーションを作成していたと考えてみましょう。様々な動物をプログラム上管理する必要があるため、

哺乳類
犬
柴犬
チワワ
コリー
猫
…
といった形でクラスを定義していたとします。

実際に、ペットブリーダーが育てるのは、「(芝犬の)ポチ」や「(コリーの)ラッシー」です。この場合に、「哺乳類」
「犬」「猫」といったクラスは、主として分類の適切な階層を形成するために存在し、実際のインスタンスは
作成しないことになります。(なんだかよくわからない「哺乳類のインスタンス」をペットブリーダーが対象にすることはありえません)。

こうしたクラスを抽象クラスと呼びます。抽象クラスの「抽象」とは、決して「具体的なインスタンスが作成されない」
という意味になります。(これに対し、実際にインスタンスが作成されるクラスを「具象クラス」とよぶ場合があります)。
ただし、抽象クラスの持つ「属性の定義」、「操作の定義」、「操作の実装」は依然としてサブクラスで継承され、利用されることになります。
例えば「哺乳類」には、「平均体温」といった属性の定義を行っておくことができ、「犬」には「お手
」「おすわり」といった操作の定義、実装をすることができます。

抽象クラスは分類の概念をきちんと整理するのに役立ち、また、継承によるコードの再利用も促進します。
814 ：仕様書無しさん：2018/05/05(土) 16:29:39.30 .net: >>812
> アダプターパターンを理解するのにこれ以上わかりやすい説明あったら教えてよww

だからそうじゃなくてい、今はオブジェクト指向が分かってない人向けの説明
小学生にいきなり高等数学お教えても理解できないんだよ
815 ：仕様書無しさん：2018/05/05(土) 16:30:07.38 .net: そうだな。クラスとかインスタンスとか分かってないレベルの人には
犬猫で例えたほうがわかりやすいだろう。
816 ：仕様書無しさん：2018/05/05(土) 16:32:23.65 .net: >>806
大切なのはエンジニアがプログラムの世界に生物はいないって認識を持つこと。

そしたらUserクラスを作っても、これはUser自体を指すのではなく
アプリケーションがもつユーザに関するデータや機能がある装置（パーツ）なんだって正しい認識ができるじゃん
817 ：仕様書無しさん：2018/05/05(土) 16:33:13.62 .net: > 大切なのはエンジニアがプログラムの世界に生物はいないって認識を持つこと。

な？いきなりプログラムの世界という馴染みのない世界での話をする
それじゃ、分かってない人は理解できないよ
818 ：仕様書無しさん：2018/05/05(土) 16:34:09.60 .net: 重要なのは相手の立場になって考えること。
プログラムの世界にいない人はいるが
現実世界であれば誰でもいる
その現実世界で例えるから理解しやすい
819 ：仕様書無しさん：2018/05/05(土) 16:34:19.91 .net: >>815
かもしれない。

けど、クラスを作れるようになったら犬猫の概念が邪魔になるから忘れろ！っていうのもおかしな話だ
820 ：仕様書無しさん：2018/05/05(土) 16:34:52.42 .net: >>817
はいはい
ゲームの世界ならわかるでしょ
821 ：仕様書無しさん：2018/05/05(土) 16:35:29.08 .net: 乾電池といっても場面によって様々だ

オンラインショップでは特別なクラスでは無く単に商品クラスの1インスタンスになるだろう
商品説明プロパティに通称や規格といった情報がドキュメントとして含まれるかもしれないがそれが振る舞いに影響することはない

中高生向け教材用の回路シミュレーターでは電圧など簡略化された物理特性が定義されていれば十分で規格や通称などは無視されるだろう
この場合の乾電池クラスは素子クラスを継承しているかもしれない

乾電池の現実的なあらゆる側面を考慮してクラス化しようとするから無理が生じる
乾電池クラスはあくまで簡略化されたモデルでしかないのでリアルな乾電池の全てを正確に表現する意味はどこにもない
822 ：仕様書無しさん：2018/05/05(土) 16:35:56.79 .net: >>819
じゃまにはならんよｗ

>>820
> ゲームの世界ならわかるでしょ
ゲームの世界の犬や猫ってことですね！
823 ：仕様書無しさん：2018/05/05(土) 16:39:48.57 .net: >>822
いや、なってるよ！

継承よりコンポジションやDIが大切なのに
それが行われずに何でもかんでも共通機能は
全部親クラスに定義して神クラスが出来上がるのは犬猫のせいだろ！

犬の臓器をコンストラクタで代入するなんて発想、初心者には意味不明すぎ。だから神クラスができる。
824 ：KAC：2018/05/05(土) 16:40:53.29 .net: >>793
オブジェクト指向を理解してから発言したほうがいい
825 ：仕様書無しさん：2018/05/05(土) 16:46:02.25 .net: >>823
ほんと理解できないやつだなｗ

分かってない人向けの説明だって言ってるだろ
まず犬猫で継承を理解してからだって
コンポジションやDIなんてオブジェクト指向に必須のものではない
826 ：仕様書無しさん：2018/05/05(土) 16:47:40.97 .net: >>814
深掘りする質問されたらレベルが深くなるのは当たり前なんですけど。バカなの？
827 ：仕様書無しさん：2018/05/05(土) 16:47:44.87 .net: >>825
コンポジションが必要じゃないわけないだろ
お前のクラスのフィールドは全部プリミティブ型なのか
828 ：仕様書無しさん：2018/05/05(土) 16:48:47.76 .net: >>825
こいつはオブジェクト指向を理解したつもりになってます
829 ：仕様書無しさん：2018/05/05(土) 16:50:18.73 .net: 初心者には継承より先にコンポジションを説明するべきだと思うほど重要だろう
830 ：仕様書無しさん：2018/05/05(土) 16:51:57.79 .net: 継承を知らない人に継承は良くないですよって
言っても理解できない
831 ：仕様書無しさん：2018/05/05(土) 16:52:55.92 .net: どんなことでも基本が大事
オブジェクト指向の機能はクラスと継承だ
832 ：仕様書無しさん：2018/05/05(土) 16:54:02.55 .net: >>831
クラスとインターフェースだろう？
833 ：仕様書無しさん：2018/05/05(土) 16:55:00.58 .net: 継承は重要な概念だが重要な機能ではない
重要な概念かつ重要な機能であるインターフェースを学ばせるほうが有益
834 ：仕様書無しさん：2018/05/05(土) 16:56:11.74 .net: あ、先に言っておくとインターフェースって、スーパークラスとinterfaceの両方を含む意味のことね！
ポリモーフィズム的視点から見たらどっちもインターフェースだから
835 ：仕様書無しさん：2018/05/05(土) 16:56:38.95 .net: >>833
君とは仲良くなれそうだ
836 ：仕様書無しさん：2018/05/05(土) 17:07:49.70 .net: 自作自演かよｗ
837 ：仕様書無しさん：2018/05/05(土) 17:11:58.64 .net: >>836
(ﾟДﾟ)ﾊｧ?
838 ：仕様書無しさん：2018/05/05(土) 17:13:04.36 .net: 継承は基本だからオブジェクト指向しっていて知らないのは潜りだぞ
839 ：仕様書無しさん：2018/05/05(土) 17:14:13.01 .net: >>838
お、おう
そうだな
840 ：仕様書無しさん：2018/05/05(土) 17:15:52.03 .net: 結局、犬猫がだめな理由が出てないんだよね。
生物だからだめだー。ただこれだけ
841 ：仕様書無しさん：2018/05/05(土) 17:21:25.89 .net: >>840
>>823よく読めよ
842 ：仕様書無しさん：2018/05/05(土) 17:33:19.46 .net: >>841
それがどうかしたの？
構造体使えばいいのに何でも配列を使うのは
配列を教えたせいだ！って言ってるようにしか見えないなぁｗ
843 ：仕様書無しさん：2018/05/05(土) 18:00:29.78 .net: >>842
ただ否定したいだけじゃん
ガキ
844 ：KAC：2018/05/05(土) 18:02:37.60 .net: >>833
インターフェースは、継承の概念に基づいた実装の一つ。
多分、抽象クラスの話題と混同してる。

というか、作ったインターフェースを継承しないの？何故気付かないのか。。。
845 ：仕様書無しさん：2018/05/05(土) 18:14:54.99 .net: >>844
インターフェースは契約の集合であって継承とは異なる概念だけどまあ言ってもわからんだろうね
846 ：仕様書無しさん：2018/05/05(土) 19:55:30.15 .net: >>845
C++で多重継承してひどい目にあったことがある。

いろいろおもったことはあったけど、そこから学んだことは「多重継承はアンチパターン」ってことと「インターフェースであれば多重継承問題が起こらない」ということだった。

詳しいみたいなので聞きたいんだが、これ以外にツッコミどことか知っておくべきことってある？
847 ：仕様書無しさん：2018/05/05(土) 20:35:38.69 .net: 多重継承は使うな、
ってのは今じゃなくても
オブジェクト指向が流行りだした
かなり初期の頃から言われてたじゃん。
848 ：仕様書無しさん：2018/05/05(土) 20:39:23.43 .net: >>847
多重継承がよく使われるっていうのは、インターフェースの多重継承ではなくて？
849 ：仕様書無しさん：2018/05/06(日) 07:03:33.92 .net: インターフェースっていろんな意味で使うから、こういう議論では混乱する
850 ：仕様書無しさん：2018/05/06(日) 09:52:46.73 .net: >>849
それな
851 ：仕様書無しさん：2018/05/06(日) 10:16:14.10 .net: Objective-C等のプロトコル（Swiftにも受け継がれた）やその影響で作られたJava等のインターフェイスは
クラスの継承を安易にデータ型の派生に流用したことで生じた問題を
両者を分離することで解決しようとした試みの一つだよ
852 ：仕様書無しさん：2018/05/06(日) 10:41:36.97 .net: ふむ、JavaのinterfaceやC++の実装を持たないクラスであれば
多重継承しても複雑化問題は起こらないという認識で間違っていなかったようだ。

そもそも継承自体ほとんど使わないからな。
既存のモジュールはそのまま使うことが多い。オーバーライドして拡張したことなんてほとんどの人が無いのでは？

また、その必要があるときは継承するのではなくコンポジションを使うしね。

ちょっと前にも話があったけど、画像が変わるだけで継承することもないし。

ゲームの場合はEnemyクラスを継承したいろんな敵を作ったりするかもだけど、その場合でさえ不要なことがありえる。

ほとんどの場合、継承が必要なのはロジックの差し替えだから、簡易的なスクリプトの利用が許されるなら、ロジックすらDI可能になるしね。

つまり、継承はオブジェクト指向の基本だが、その利用は分野によってほとんどの場合限られるというわけさ
853 ：仕様書無しさん：2018/05/06(日) 10:47:14.41 .net: つまりまとめると、オブジェクト指向には色々な概念があるけれど
オブジェクト指向に踊らされないために心がけるべきことはDIとコンポジション、そしてインターフェースに対してプログラミングするという、この3点なのだよ。

もちろんデザインパターンとかMVCとかも重要だけど、継承に騙されて神クラス地獄に落ちることを回避することが大切で

その回避の第一歩となるのがコンポジションなのさ
854 ：仕様書無しさん：2018/05/06(日) 10:50:45.74 .net: ごめん、DIと、コンポジションはほとんど同じ意味だった。

依存性注入（DI）と、疎結合（ポリモーフィズムなど）と、モデリングの3点に訂正させてくれ
855 ：仕様書無しさん：2018/05/06(日) 11:01:41.14 .net: 例えば…

数値型の金額と、enumの通貨記号の二つの変数で「金額」を表現しているプログラムがあったとする。
・馬鹿な新人が、JPY+USDとかしてた
・お客に頭を下げたり休出してデータメンテしなければならない事が良くあった

これをイミュータブルな「金額クラス」にした
・加算減算メソッドは、同じ通貨記号を持つ金額インスタンスとだけ足し算可能
・乗算除算メソッドは、ただの数値(QTYとか税率とか利率とか)と掛け算が可能

これによって
・馬鹿な新人の、HKD+EURを止められるようになった(例外は出るけど、データの破壊は防げる)
・ソースコードに学習効果が生まれて、そのうち新人の知性がちょっとだけ増えた
・ムカつく客に頭下げずに済むし、休日のんびりシコれてハッピー

こんな感じで「目的」にフォーカスしてクラスという単位に切り出す事によって、複雑さを下げて物事を理解しやすくする。
…てのが、オブジェクト指向の一つの側面なのかなーと思ってる
DIとか多態性とかデザインパターンは、難しすぎて俺には手に負えない
856 ：仕様書無しさん：2018/05/06(日) 11:26:33.93 .net: >>855
それはただ単に計算をカプセル化しただけで
オブジェクト指向でなくてもできるのでは？

DIとか多態性とかって聞くと拒否感あるかもしれないけど
DIは「そのクラスで使いたい機能はnewするときにコンストラクタに渡して使おうぜ！」って話だし
多態性は「抽象（インターフェース）に対してプログラミングしたら、そのコードは流用性あるよね」ってだけのことさ
857 ：仕様書無しさん：2018/05/06(日) 12:15:37.96 .net: ウィキペにも（そうとはわかりにくく）書いてあるけど、オブジェクト指向には
あらゆる局面での遅延結合性を重要視する「メッセージング」のオブジェクト指向
http://metatoys.org/oxymoron/oxymoron.html

と、ユーザー定義のデータ型をクラス（あるいはインターフェイス等それに準ずる言語機能）で実現する
「抽象データ型」のオブジェクト指向がある
http://www.stroustrup.com/whatis.pdf

端的には前者は「オブジェクトにメッセージを送って…」、後者は「カプセル化、継承、多態性」がお題目のやつ

継承がどうこういうのは後者の問題で、前者ではデータ型自体を意識することがないので
（Smalltalkなどの前者寄りに作られた言語で後者を部分的に実践する場合を除き）
ほとんど問題にならない

両者の考え方を完全に分離できたなら現在のような混乱は生じていないのだけれども
本来後者で完結されるべきオブジェクト指向設計や分析の提唱者の多くが
Smalltalkなど前者に重きを置く言語のシンパでもあったりして前者の要素を含ませてしまったため
いろいろと面倒なことになって久しい
858 ：仕様書無しさん：2018/05/06(日) 12:52:25.89 .net: >>853
最低限solidは守ってくれ
859 ：仕様書無しさん：2018/05/06(日) 13:00:45.16 .net: まあ、何だかんだ言ってるが、まともに動かない設計して最後はいつもパッチワークして貫通トンネル工事するんだろ？
860 ：仕様書無しさん：2018/05/06(日) 13:02:54.87 .net: だからOOPの本質は疎結合
861 ：仕様書無しさん：2018/05/06(日) 13:20:18.54 .net: で、下手に隠蔽しちまって、参照出来ねーとか完全に設計ミスな実装しやがる奴の多い事…。
862 ：仕様書無しさん：2018/05/06(日) 13:20:34.01 .net: >>856
> DIは「そのクラスで使いたい機能はnewするときにコンストラクタに渡して使おうぜ！」って話だし

AとBというクラスがあってAがBを使う
その時Bの内部実装について、Aはまったく知らないのがいいはずなんだが、
newするときコンストラクタに渡すってことは、Bが内部で使うクラス全てに依存するってことか
ひどい実装だなｗ

class A {
　foo() {
　　b = new B(new File)
　　b.run()
　}
}

Bが内部でファイル読み書きに加えとあるライブラリを使うようになったので
Aを修正してください。

class A {
　foo() {
　　b = new B(new File, new Hoge)
　　b.run()
　}
}
863 ：仕様書無しさん：2018/05/06(日) 13:24:34.19 .net: コンストラクタの後に初期化じゃダメなん？
つうか、コンストラクタに色々詰め込んだらダメっしょ？
864 ：仕様書無しさん：2018/05/06(日) 13:26:52.02 .net: >>862
そのとおり
君のような賢いプログラマはDIなんて使わなくていいぞ全くもって同意だ
結論がでたからこの話はここで終わりにしよう
バイバイ
865 ：仕様書無しさん：2018/05/06(日) 14:02:42.07 .net: 初心者しかいないな
866 ：仕様書無しさん：2018/05/06(日) 14:08:26.64 .net: DIだと日付クラスを使いたい時、
中でnewしないで、外部から渡してもらう
867 ：仕様書無しさん：2018/05/06(日) 14:11:21.81 .net: >>858
せやな
868 ：仕様書無しさん：2018/05/06(日) 14:14:26.70 .net: >>862
内部でnewしてどうすんねん
依存性注入してくれ
869 ：仕様書無しさん：2018/05/06(日) 14:14:31.04 .net: >>866
それって当たり前じゃね？
中でnewって、今の日付けしか取得出来なくね？
値渡すのが目的なんだから、値設定して渡すんだろ？
870 ：仕様書無しさん：2018/05/06(日) 14:16:36.65 .net: >>869
その当たり前が>>862のようにできない人が多いのさ
だからスーパークラスに共通機能を実装しだして
神クラスのスパゲティになる
871 ：仕様書無しさん：2018/05/06(日) 14:16:53.34 .net: DIで粗結合にするのって、オブジェクト指向がどうこうじゃなくて、ユニットテストのために（仕方なく）やるのが
ほとんどなので、スレのテーマとはちょっと違うかなー
872 ：仕様書無しさん：2018/05/06(日) 14:18:08.36 .net: >>871
それよく言われるけど絶対間違ってる
ユニットテストとはまた別の話
873 ：仕様書無しさん：2018/05/06(日) 14:18:31.85 .net: 日付は値なので注入しない
注入するのはカレンダーとか現在時刻プロバイダー
874 ：仕様書無しさん：2018/05/06(日) 14:19:23.73 .net: >>869
さあね。どう当たり前なんだろうね。
例えば言語によってはIntegerもクラスだったりする
関数もクラスだったりする
875 ：仕様書無しさん：2018/05/06(日) 14:20:46.66 .net: >>871
solidについて調査してレポートして
弊社だと新人研修で叩き込むことだけど
業界を見渡すとsolidすら知らん素人が紛れ込んでるんだよな
あの会社は教育体制大丈夫なのかなと他人事ながら心配になる
876 ：仕様書無しさん：2018/05/06(日) 14:20:51.45 .net: >>874
IntegerとかStringのような低レベルなクラスは
疎結合とか気にしなくていい
877 ：仕様書無しさん：2018/05/06(日) 14:23:19.16 .net: >>872
じゃあ日付オブジェクトを外部から渡すことによるテスト容易性以外の実利ってなによ
日付オブジェクトをあとから同一インターフェースの別実装に変えたりしないっしょ
878 ：仕様書無しさん：2018/05/06(日) 14:23:36.85 .net: >>876
いや気にしろ
注入する必要はないが必ずValueObjectでラップしろ
879 ：仕様書無しさん：2018/05/06(日) 14:24:17.49 .net: >>877
日付は注入しねえつってんだろ
880 ：仕様書無しさん：2018/05/06(日) 14:24:56.26 .net: >>878
どういうこと？
881 ：仕様書無しさん：2018/05/06(日) 14:27:14.26 .net: 箱と中身がごっちゃになってるカオスw
882 ：仕様書無しさん：2018/05/06(日) 14:28:26.39 .net: >>879
じゃあ現在時刻プロバイダをDIするテスト容易性以外の実利でもいいよ
883 ：仕様書無しさん：2018/05/06(日) 14:34:20.91 .net: >>857
メッセージングオブジェクト指向と
抽象データ型オブジェクト思考の違いがよくわからなかったんだけど
動的型付けか静的型付けかで分類されてるってこと？
884 ：仕様書無しさん：2018/05/06(日) 14:37:09.86 .net: >>880
俺らが業務で扱うような文字列ってのは全て単純な文字列じゃない
例えばあるシステム上に注文番号という概念があるとして
この注文番号は文字列表現を持つかもしれないが文字列そのものではない
だから注文番号を扱うクライアントが注文番号ではなく文字列に直接依存してはならない
注文番号というValueObjectを通じて文字列との結合を排除しなければならない
885 ：仕様書無しさん：2018/05/06(日) 14:38:20.08 .net: >>882
タイヤやエンジンの車の話じゃダメなん？

レースゲームでカスタマイズするときにタイヤやエンジンを依存性注入して車を作れば
いろんな組み合わせの車が作れるじゃん
886 ：仕様書無しさん：2018/05/06(日) 14:39:54.65 .net: >>884
ああ、そういうことね
文字列をそのまま使うな、モデリングしてから使えと。
887 ：仕様書無しさん：2018/05/06(日) 14:43:53.00 .net: そう言う型のデータクラスを扱うって話と、データ自身を自ら生成するのかって話がごっちゃになってるだけ。
888 ：仕様書無しさん：2018/05/06(日) 14:45:36.54 .net: >>863
別にプロパティにインジェクションしたりしてもいいし
単にLazy使えばいい場合も
889 ：仕様書無しさん：2018/05/06(日) 14:46:32.95 .net: >>882
・クライアントは現在時刻プロバイダが現在時刻を供給するということだけを知っていればいい
クライアントは現在時刻の定義などを気にしなくてよくなり本来の仕事に集中できる

・クライアントに現在時刻を供給したり自給自足する責任が無いことを依存性として明示することにより可読性・保守性が向上する

・クライアントと現在時刻を取得する具体的な実装を分離したことによって
現在時刻を取得する方法を容易に切り替えることができる
890 ：仕様書無しさん：2018/05/06(日) 14:49:58.52 .net: >>877
サーバーの時刻とユーザーから見える（見たい）時刻の標準時が違う場合
891 ：仕様書無しさん：2018/05/06(日) 14:52:05.93 .net: >>863
DIを使うとむしろコンストラクタはシンプルになる
ほとんどの場合ヌルチェックとフィールドへの代入だけでよい
色々やる必要がある場合はFactoryが代行する

コンストラクタの後に初期化する方法もある
プロパティインジェクションやメソッドインジェクションと呼ばれる
ただしこれらの方法はオブジェクトが不完全な状態を一時的に許すことになる
なので神経質なプログラマはコンストラクタインジェクションを好むようだ
892 ：仕様書無しさん：2018/05/06(日) 14:53:49.58 .net: >>889
1つめと2つめ
クライアントは使用するオブジェクトの実装に依存しないというオブジェクト指向一般の話であって
DIを説明してるわけじゃないっしょ

3つめ
実際にそれやるのって、現実的にはユニットテストのためだけであることがほとんど
893 ：仕様書無しさん：2018/05/06(日) 14:56:30.10 .net: >>891
100点！
894 ：仕様書無しさん：2018/05/06(日) 14:57:00.67 .net: >>892
日本向けのアプリしか考えたことのない人
895 ：仕様書無しさん：2018/05/06(日) 15:03:31.06 .net: >>890
あるモジュールがそのロジックの中で使ってる現在時刻プロバイダが、サーバー時刻を提供するものであったり
ユーザー向けの時刻を提供するものであったりする状況って例えば？
896 ：仕様書無しさん：2018/05/06(日) 15:11:08.77 .net: >>892
1つめ
クラスを直接参照する場合には暗黙に実装にも依存が発生してしまう
例えば現在時刻プロバイダがタイムサーバーにアクセスしている場合クライアントの開発者はタイムサーバーへアクセスできる環境を強いられることになる
またインターフェースに存在しないメソッドを知ってしまうというリスクがある
あなたの後任者がそのメソッドを呼びだしてクラス間の結合度を高めることを防ぐことは難しい

2つめ
返しとして不適切

3つめ
現在時刻プロバイダの実装が間に合っていない場合
現在時刻プロバイダが依存するインフラストラクチャが高価な場合
など実装を交換する理由はいくらでもある
897 ：仕様書無しさん：2018/05/06(日) 15:15:06.28 .net: >>895
？
898 ：仕様書無しさん：2018/05/06(日) 15:16:16.87 .net: >>895
日本のサーバーで日本のユーザーという状況しか考えたことのない人
899 ：仕様書無しさん：2018/05/06(日) 15:18:29.82 .net: UTCの話？
900 ：仕様書無しさん：2018/05/06(日) 15:18:37.29 .net: >>883
メッセージングのOOPは「システム内での決定をどう遅らせるか」
抽象データ型のOOPは「データ型をどう簡単かつ安全に定義、運用するか」
901 ：仕様書無しさん：2018/05/06(日) 15:19:34.28 .net: このように、オブジェクト指向というのは、理想的なモデルを追い求めればいいというものではなく、
開発者の都合に合わせてモデルの形が変わっていく泥臭い世界なのです
902 ：仕様書無しさん：2018/05/06(日) 15:20:19.84 .net: そりゃあ、ITドカタだからなぁ
903 ：仕様書無しさん：2018/05/06(日) 15:22:18.26 .net: >>896
テスト容易性の話ですね
904 ：仕様書無しさん：2018/05/06(日) 15:25:22.92 .net: >>901
人員も要件も予算も千差万別
たったひとつの理想を追及するよりも柔軟に様々な状況に対応可能なモデリングツールのほうが優れているね
905 ：仕様書無しさん：2018/05/06(日) 15:29:02.96 .net: >>898
内部的にはUTCを使ってロケール依存の部分だけユーザーのロケールに従うので、
同じオブジェクトに対してサーバー時刻をインジェクトしたりユーザー時刻をインジェクトしたりはしませんね
906 ：仕様書無しさん：2018/05/06(日) 16:05:46.51 .net: DIはオブジェクト指向によって不要なもの
なぜなら全てのオブジェクト指向言語に
DI用の機能が搭載されていない
907 ：仕様書無しさん：2018/05/06(日) 17:32:45.11 .net: だって言語機能だけでできるもん
全部のクラスをmain関数でnewして、依存クラスはコンストラクタに突っ込んで
すべてmain関数で構築すればよい

パッケージを使わず依存の排除をつきつめていくと結局そうなって
これＤＩと一緒じゃねーかと気が付いた
908 ：仕様書無しさん：2018/05/06(日) 17:33:22.74 .net: パッケージじゃなかったＤＩフレームワーク使わずに
909 ：仕様書無しさん：2018/05/06(日) 17:38:16.63 .net: >>907
キチガイ
910 ：仕様書無しさん：2018/05/06(日) 17:39:26.07 .net: なぜに
911 ：仕様書無しさん：2018/05/06(日) 17:40:23.90 .net: >>910
え？
912 ：仕様書無しさん：2018/05/06(日) 17:47:03.57 .net: >>907
> 全部のクラスをmain関数でnewして、依存クラスはコンストラクタに突っ込んで
> すべてmain関数で構築すればよい

main関数が神クラスならぬ
神関数になってるわけかｗ
913 ：仕様書無しさん：2018/05/06(日) 17:47:06.63 .net: >>906
依存インスタンスの生成を消費クラスの外部で行い渡して使わせる
依存インスタンスへのアクセスはインターフェースのみを通じて行う

DIとは極論するとこれだけ
これをサポートしてないオブジェクト指向の言語を探すのは難しいだろう

DIコンテナは便利だけど必須ではない
DIコンテナはDIと名前に付いてるがDIそのもではなく単なるFactoryのバリエーションでしかない
914 ：仕様書無しさん：2018/05/06(日) 17:52:45.63 .net: >>912
やってることは割と単純だから長くてもそんなにスパゲッティにはならないはず
915 ：仕様書無しさん：2018/05/06(日) 17:54:35.09 .net: >>907
君とは仲良くなれそうだ。
俺もそこに行き着いたぜ
916 ：仕様書無しさん：2018/05/06(日) 17:57:52.95 .net: >>912
メインクラスってのは、そもそもアプリケーション（自分が作ろうとしてるもの）なわけだよ。
それが神クラスのようになって何が問題なんだい？
メインクラスはnewしまくれる唯一の場所なんだよ
917 ：仕様書無しさん：2018/05/06(日) 18:00:06.69 .net: DIっていうのもうやめようぜ。
いつもこの話すると関係ないユニットテストやらDIコンテナの話がでてくる。
これからはコンストラクタインジェクションって言おう
918 ：仕様書無しさん：2018/05/06(日) 18:01:12.16 .net: >>907
それも悪ではないが生成の責務はFactoryにもたせたほうが良い
規模が大きくなるとすぐにmainが破綻する
919 ：仕様書無しさん：2018/05/06(日) 18:04:18.19 .net: >>913
> これをサポートしてないオブジェクト指向の言語を探すのは難しいだろう

カプセル化を実現する機能としてprivateというものがある。
privateを使うことで、どうやっても外部からアクセスできなくなる
これが言語のサポートという

> 依存インスタンスの生成を消費クラスの外部で行い渡して使わせる
> 依存インスタンスへのアクセスはインターフェースのみを通じて行う

これを制限する機能が搭載されている言語はない。
あくまでそういうルールにしたから守りましょうという紳士協定のみ
こういうのは言語のサポートとは言わない
920 ：仕様書無しさん：2018/05/06(日) 18:04:40.84 .net: >>918
せやな。
newしまくれるmainの性質を、クラスに抽出したのがFactoryと言えるしな
921 ：仕様書無しさん：2018/05/06(日) 18:05:26.07 .net: >>916
> メインクラスってのは、そもそもアプリケーション（自分が作ろうとしてるもの）なわけだよ。
> それが神クラスのようになって何が問題なんだい？

カプセル化が破壊されるから。
例えば、外部のライブラリを使おうと思っても、そのライブラリが
使用するもの全てをmainで作らなければいけなくなる
922 ：仕様書無しさん：2018/05/06(日) 18:05:57.29 .net: 何でも作れる工場なんて作らないぞw
923 ：仕様書無しさん：2018/05/06(日) 18:07:33.55 .net: 例えば、Windowsでメッセージボックスを表示しようと考える。
その時、簡単な関数だけでYES/NOが返ってくるAPIではなく

メッセージボックスが必要とするボタンまで、main関数で作って渡さなければいけなくなる。
メッセージボックス程度ならまだいいが、より複雑な
ファイル選択ダイアログボックスの場合、
main関数でリストビューまで作らなければいけなくなる
924 ：仕様書無しさん：2018/05/06(日) 18:07:44.67 .net: >>919
つまりインターフェースがサポートされていればDI用の機能が搭載されていると言える
925 ：仕様書無しさん：2018/05/06(日) 18:08:40.11 .net: >>924
それはジャンプ命令が搭載されていれば、
例外用の機能が搭載されていると言ってるのと同じ
926 ：仕様書無しさん：2018/05/06(日) 18:08:44.53 .net: >>919
紳士協定は必要だろう？
それぞれのプログラマが言語の枠で自由にやられたらどの言語使っても困ることになる
927 ：仕様書無しさん：2018/05/06(日) 18:09:36.50 .net: >>921
それの何が問題なの？そしてなんのカプセル化が破壊されてるの？
928 ：仕様書無しさん：2018/05/06(日) 18:12:47.48 .net: >>927
private MyClass myClass;

というプライベート変数まで外からインジェクションしないといけなくなる
カプセル化の破壊
929 ：仕様書無しさん：2018/05/06(日) 18:23:27.81 .net: >>922
その通り

複数の工場を考えればよろしい
各工場はある程度関係性があるプロダクトをまとめて生産する
ある工場は別のある工場のプロダクトに依存して自分のプロダクトを生産する
工場間のプロダクトの流れを正しく決めてやればたとえなんでも生産する工場などではなくとも複雑で大きなプロダクトを生産することができるわけだ
930 ：仕様書無しさん：2018/05/06(日) 19:08:46.27 .net: DIの目的がテストになってる時点で
オブジェクト指向はテストがし辛いってことを意味する

コンポジションがその一番の元凶
コンポジションをなくせばDIは必要なくなる

DIが言語に搭載されずDIコンテナというフレームワークが
必要になるのは、DIがオブジェクト指向にとって
ふさわしくないものであることを意味する

かと言ってその問題を解決する手段が見つかっていない
オブジェクト指向に根本的な問題があるからだ
931 ：仕様書無しさん：2018/05/06(日) 19:14:18.12 .net: オブジェクト指向かどうかは関係ない
インフラを始めとして他の何かに依存するコードはテストしにくい
それはパラダイムのせいじゃない
932 ：仕様書無しさん：2018/05/06(日) 20:09:45.92 .net: 依存の問題って関数しかない言語でも普通にあるよね
933 ：仕様書無しさん：2018/05/06(日) 20:24:22.76 .net: >>930
だから誰もユニットテストやDIコンテナの話なんかしてないから
コンストラクタインジェクションって解釈してくれる？
934 ：仕様書無しさん：2018/05/06(日) 20:25:29.10 .net: >>928
それはカプセル化の破壊とは言わない
935 ：仕様書無しさん：2018/05/06(日) 20:34:56.96 .net: ヘビィクラスには成長してるね
936 ：仕様書無しさん：2018/05/06(日) 20:35:49.30 .net: 俺はちょっとぽっちゃりぐらいが好きだぜ
937 ：仕様書無しさん：2018/05/06(日) 20:51:27.31 .net: >>933
> コンストラクタインジェクションって解釈してくれる？

コンストラクタ引数を潰すもの

>>934
> それはカプセル化の破壊とは言わない

いう
938 ：522：2018/05/06(日) 21:52:47.57 .net: >>928
これってC++でヘッダファイルをincludeするときの問題を言ってる？
としたらそれはC++言語がきちんとオブジェクト指向プログラミングに適合できてないって話であってOOP自体の問題じゃない
C++でもpimpl使って回避するのが定跡
939 ：仕様書無しさん：2018/05/06(日) 22:17:40.03 .net: >>937
言わない
940 ：仕様書無しさん：2018/05/06(日) 22:20:10.14 .net: ったく、コンストラクタインジェクションでカプセル化が崩壊するなら
コンストラクタでインスタンスを受取る全てのクラスがカプセル化崩壊してんじゃねぇか

なんでそんなに堂々と誤ったこと言えるのかね
その自信どこからくるのまじ。
941 ：仕様書無しさん：2018/05/06(日) 22:24:44.23 .net: このスレで話し合ってわかったことは
オブジェクト指向は素晴らしいけれど
混乱が多く、人類には早すぎたということだ
942 ：仕様書無しさん：2018/05/06(日) 22:25:04.25 .net: コンストラクタインジェクションの問題は
手続きの中で関連を設定しないといけないことだ

ＤＩフレームワークを使えば静的宣言的に依存関係を定義できる

でもＪａｖａとかC#のxml使ったＤＩフレームワークって
設定ミスのエラーとか実際動かすまでわからんから
宣言的で何がうれしいのかいまいちよく分かってない
943 ：仕様書無しさん：2018/05/06(日) 22:26:43.38 .net: >>940
> ったく、コンストラクタインジェクションでカプセル化が崩壊するなら
> コンストラクタでインスタンスを受取る全てのクラスがカプセル化崩壊してんじゃねぇか

何いってんだ？

もともとコンストラクタで渡す必要がないものを
渡すように変更したから破壊だって言ってるんだよ。

仕様としてインスタンスを渡すならそれは問題ない
DIのためだけにコンストラクタを改変したんだろうが
944 ：仕様書無しさん：2018/05/06(日) 22:31:03.17 .net: コンストラクタはメソッドじゃないから壊しても破壊じゃないやい
945 ：仕様書無しさん：2018/05/06(日) 22:33:51.33 .net: >>943
なるほどね

でも、渡す必要の無いものをコンストラクタインジェクションで渡す行為を「カプセル化破壊」と
名付けるのはセンスに欠けますな
946 ：仕様書無しさん：2018/05/06(日) 22:34:37.29 .net: >>945
DIなんてものを使わない場合、
内部に閉じていて外から見えないものなのだから
破壊だろう
947 ：仕様書無しさん：2018/05/06(日) 22:36:02.54 .net: >>946
はい？ごめんどういうこと？
948 ：仕様書無しさん：2018/05/06(日) 22:39:22.98 .net: 頭の悪い人はごめんだな
949 ：仕様書無しさん：2018/05/06(日) 22:40:18.95 .net: え、だっていうこと急に逆転したから意味わかんなくて
950 ：仕様書無しさん：2018/05/06(日) 22:40:25.37 .net: >>767
うーん、こういう知ったかが一番始末悪いんだよなあ。
否定だけして理由は言わない・・・ってまるで今の野盗。
951 ：仕様書無しさん：2018/05/06(日) 22:42:49.15 .net: >>950
ほんとそれ

ちゃんと議論すればみんなハッピーなのにさー
プログラマのくせに生産性にかけることしちゃうんだもん
笑えるよ
952 ：仕様書無しさん：2018/05/06(日) 22:46:42.70 .net: そういえば次スレどうする？
953 ：仕様書無しさん：2018/05/06(日) 22:54:52.32 .net: 次スレは要らんだろ
teratailかstackoverflow jpに移動しよう
954 ：仕様書無しさん：2018/05/06(日) 22:56:09.27 .net: 日本語じゃなくてソースコードで会話しろよ…
こういうことでいいのか？
最初から、コンストラクタの引数の変更なんて想定されないよな。

//ClientはBaseInterfaceを知ってるが派生クラスを知らない
class Client {
BaseInterface b_;
　Client(BaseInterface b) {
　　b_ = b;
　}

foo() {
　　b_.run()
　}
}

//bFactoryはBaseInterfaceの派生クラスのインスタンスへの参照を返す
Client c = bFactory.CreateInstance(file , ...);
c.foo();
955 ：仕様書無しさん：2018/05/06(日) 23:28:24.35 .net: 何がしたいのかわからないな
もう少し具体的な例にしないか？
956 ：仕様書無しさん：2018/05/06(日) 23:31:08.99 .net: >>940
俺はしてると思うな
インスタンス保持は禁じ手だと思うし
957 ：仕様書無しさん：2018/05/06(日) 23:58:23.22 .net: >>956
いやごめん、コンストラクタインジェクション【すると】
カプセル化破壊されるって話だったよね？

内部で具象であるnew使ったら具象に依存して疎結合性が失われるのは理解しておるよ
958 ：仕様書無しさん：2018/05/06(日) 23:59:53.96 .net: >>953
なんだかんだ楽しかったんだが
次スレは無しかー
959 ：仕様書無しさん：2018/05/07(月) 09:46:58.06 .net: 非OOPではどう書くか
それをOOPではどう書くか
その結果、何が良くなるのか

そこらへんが良くわかんないんだよねー
よく分からないまま、客先のコーディング規約から外れないようにしつつ、既存ソースコピペしてるよ
960 ：仕様書無しさん：2018/05/07(月) 09:56:48.10 .net: オブジェクトをコレクションで使うと良さがわかるよ
961 ：仕様書無しさん：2018/05/07(月) 09:57:44.62 .net: 結論は犬猫エンジン禁止で良いね
962 ：仕様書無しさん：2018/05/07(月) 10:08:09.44 .net: >>942
>C#のxml使ったＤＩフレームワークって設定ミスのエラーとか実際動かすまでわからん
StructureMapですらそんなのなくしたのに？ASP.NET CoreのデフォルトのDIでもそんなことしないし、いつの時代の話だよ…
963 ：仕様書無しさん：2018/05/07(月) 11:32:03.05 .net: 次スレ

オブジェクト指向を分かりやすく例えて教えてくれ 2
https://medaka.5ch.net/test/read.cgi/prog/1525660302/
964 ：仕様書無しさん：2018/05/07(月) 11:34:11.07 .net: DIフレームワークはなくして
言語機能に取り入れるべき

どうせテストにためにしか利用しないんだから
そのためにアプリケーションの設計まで変更するのはおかしい
965 ：仕様書無しさん：2018/05/07(月) 11:39:54.04 .net: >>964
ねーよ
966 ：仕様書無しさん：2018/05/07(月) 12:20:55.39 .net: >>964
DIがユニットテストのためにしか使われないとか言う謎の考え方はどこから生まれたんだろう
967 ：仕様書無しさん：2018/05/07(月) 12:53:58.74 .net: 次スレでだいたい言いたいこと書けたから良かったわ。
次の住人にまで混乱が及んだら話が進まない
968 ：仕様書無しさん：2018/05/07(月) 13:39:43.96 .net: >>966
テストコードと本番コードを入れ替えるのにしか使わないから
使えないんじゃなくて、使わない
969 ：仕様書無しさん：2018/05/07(月) 13:43:40.69 .net: >>968
どうも生きている世界が違うようだ
970 ：仕様書無しさん：2018/05/07(月) 14:38:42.77 .net: >>969
そうみたいだな
971 ：仕様書無しさん：2018/05/07(月) 15:22:27.14 .net: じゃあ具体的に例を出せばいいじゃない
972 ：仕様書無しさん：2018/05/07(月) 15:24:50.49 .net: テストのために
アプリケーション設計は変えるもんよ
973 ：仕様書無しさん：2018/05/07(月) 17:48:04.01 .net: >>972
たしかに
974 ：仕様書無しさん：2018/05/07(月) 18:06:53.60 .net: テストのためにっていうか
もともとはSolidな設計を実践して美しいシステムを作るためのベストプラクティスだからなDIって
DIでSolidを実現した結果の付加価値としてテストも容易になるってだけ
975 ：仕様書無しさん：2018/05/07(月) 18:12:02.47 .net: インスタンスを差し替える予定もないのにDIするアホ
976 ：仕様書無しさん：2018/05/07(月) 18:25:36.45 .net: >>975
コンストラクタの引数の数が増える嫌悪感より
疎結合性が失われる嫌悪感の方が強いんですけど
977 ：仕様書無しさん：2018/05/07(月) 18:29:03.84 .net: >>975
変更されると困るオブジェクトコンポジションはDIしないほうがいいけど、大抵の場合
内部定義すると疎結合性が失われるから大体DIする感じにならん？
978 ：仕様書無しさん：2018/05/07(月) 18:30:25.27 .net: >>974
いいこと言うね！ほんとそれ
979 ：仕様書無しさん：2018/05/07(月) 18:47:54.68 .net: 泣きながら人のバグ治すよりも
切り分けできる設計にしといた方が
後々楽よ。
980 ：仕様書無しさん：2018/05/07(月) 19:41:17.40 .net: ジェンガみたいなプログラムはゴメンだね
ダルマ落としぐらいシンプルにしてくれないとやってらんないよ
981 ：仕様書無しさん：2018/05/07(月) 19:46:20.13 .net: >>975
> DIでSolidを実現した結果の付加価値としてテストも容易になるってだけ
それはおかしいSolidを実現すれば、DIコンテナなんてものは不要になるはず
言語仕様の範囲では実現できないから、DIなんてのが必要になってる
982 ：仕様書無しさん：2018/05/07(月) 19:48:27.95 .net: >>976
> コンストラクタの引数の数が増える嫌悪感より
> 疎結合性が失われる嫌悪感の方が強いんですけど

既存のライブラリで、コンストラクタでDIできるライブラリがないのはなぜ？
983 ：仕様書無しさん：2018/05/07(月) 20:04:18.65 .net: >>982
へ？
984 ：仕様書無しさん：2018/05/07(月) 20:11:04.49 .net: しらばっくれるても意味ないよ

既存のライブラリ、ソースコード見れるのも多いだろ
内部でクラスをたくさん使っているはずだが、
それをコンストラクタで入れ替えられるようになっているものはまず無い
985 ：仕様書無しさん：2018/05/07(月) 20:17:01.66 .net: >>977
DIにするべき箇所が切り分けられない奴の特徴
DIにできそうな箇所はすべてDIw
986 ：仕様書無しさん：2018/05/07(月) 20:25:09.36 .net: >>982
どうしてそういう発想に至ったｗｗｗ
987 ：仕様書無しさん：2018/05/07(月) 20:33:43.85 .net: >>984
ASP.NET Core
988 ：仕様書無しさん：2018/05/07(月) 20:33:51.81 .net: >>984
Cake
989 ：仕様書無しさん：2018/05/07(月) 20:34:09.22 .net: >>984
IdentityServer
990 ：仕様書無しさん：2018/05/07(月) 20:34:51.70 .net: >>984
結局内部ではコンストラクタインジェクションしてるライブラリも多いけどこいつの頭の中が理解できん
991 ：仕様書無しさん：2018/05/07(月) 20:44:33.21 .net: >>987-989
あのー、クラス名で言ってくれませんかね？
992 ：仕様書無しさん：2018/05/07(月) 20:50:41.57 .net: >>991
ソースコード見れるのも多いだろ
993 ：仕様書無しさん：2018/05/07(月) 20:54:40.57 .net: >>984
？
994 ：仕様書無しさん：2018/05/07(月) 21:55:07.21 .net: >>985
それだけの情報で極端な診断されても困るんですけど
995 ：仕様書無しさん：2018/05/07(月) 21:56:49.18 .net: newしたら疎結合性が失われるものは大体メインクラスかファクトリでDIでしょ
996 ：仕様書無しさん：2018/05/07(月) 21:59:31.98 .net: >>994
図星乙
997 ：仕様書無しさん：2018/05/07(月) 22:11:07.72 .net: >>996
何故か理由を説明しないで叩くだけっていう
998 ：仕様書無しさん：2018/05/07(月) 22:45:16.47 .net: >>997
理由ならもう教えてやっただろアホ
999 ：仕様書無しさん：2018/05/07(月) 22:45:28.69 .net: 梅
1000 ：仕様書無しさん：2018/05/07(月) 22:45:51.72 .net: 梅
1001 ：2ch.net投稿限界：Over 1000 Thread: 2ch.netからのレス数が1000に到達しました。

総レス数 1001
248 KB

掲示板に戻る全部前100 次100 最新50

read.cgi ver.24052200