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

**仕様書無しさん** · 2018/03/24(土) 14:39:26.84

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

**仕様書無しさん** · 2018/03/24(土) 15:27:32.69

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

**仕様書無しさん** · 2018/03/24(土) 16:36:10.31

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

**仕様書無しさん** · 2018/03/24(土) 16:57:08.73

OOPはポインタ

**仕様書無しさん** · 2018/03/24(土) 17:27:25.63

全部staticでいいじゃん

**仕様書無しさん** · 2018/03/24(土) 17:29:16.62

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

**仕様書無しさん** · 2018/03/24(土) 18:50:15.40

ウンコ

**仕様書無しさん** · 2018/03/24(土) 19:05:28.24

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

**仕様書無しさん** · 2018/03/24(土) 20:20:18.00

オブ脳本でも読めば？

**仕様書無しさん** · 2018/03/24(土) 20:43:41.24

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

**仕様書無しさん** · 2018/03/24(土) 21:30:17.97

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

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

**仕様書無しさん** · 2018/03/24(土) 22:14:51.56

>>11

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

**仕様書無しさん** · 2018/03/24(土) 22:15:36.11

なんてこったい
オーノー

**仕様書無しさん** · 2018/03/24(土) 22:24:50.59

>>1
使ってる言語は？

**仕様書無しさん** · 2018/03/24(土) 22:31:51.65

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

**仕様書無しさん** · 2018/03/25(日) 00:08:40.33

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

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

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

違うか？

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

**仕様書無しさん** · 2018/03/25(日) 00:14:32.10

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

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

**仕様書無しさん** · 2018/03/25(日) 00:35:27.13

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

**仕様書無しさん** · 2018/03/25(日) 01:28:13.49

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

**仕様書無しさん** · 2018/03/25(日) 11:24:17.96

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

**仕様書無しさん** · 2018/03/25(日) 12:02:46.92

まだ進化論信じてんだ

**仕様書無しさん** · 2018/03/25(日) 12:03:24.49

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

**仕様書無しさん** · 2018/03/25(日) 13:46:32.99

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

**仕様書無しさん** · 2018/03/25(日) 14:44:38.63

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

**仕様書無しさん** · 2018/03/25(日) 15:05:25.89

>>23

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

**仕様書無しさん** · 2018/03/25(日) 15:07:37.24

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

**仕様書無しさん** · 2018/03/25(日) 21:56:10.25

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

**仕様書無しさん** · 2018/03/26(月) 22:22:24.17

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

**仕様書無しさん** · 2018/03/26(月) 23:09:46.00

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

**仕様書無しさん** · 2018/03/26(月) 23:25:05.78

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

**仕様書無しさん** · 2018/03/27(火) 01:55:18.27

全て乾巧って奴の

**仕様書無しさん** · 2018/03/31(土) 02:03:04.50

>>27

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

**仕様書無しさん** · 2018/03/31(土) 02:14:23.88

タービンだっけ？

**仕様書無しさん** · 2018/03/31(土) 04:05:36.68

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

**仕様書無しさん** · 2018/03/31(土) 04:43:13.93

進化の石がないだけやで

**仕様書無しさん** · 2018/03/31(土) 06:53:43.60

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

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

**仕様書無しさん** · 2018/03/31(土) 08:46:12.73

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

**仕様書無しさん** · 2018/03/31(土) 09:09:40.69

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

**仕様書無しさん** · 2018/03/31(土) 09:36:45.70

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

**仕様書無しさん** · 2018/03/31(土) 09:40:53.28

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

**仕様書無しさん** · 2018/03/31(土) 10:21:23.83

何をするメソッドなのか

**仕様書無しさん** · 2018/03/31(土) 10:24:50.01

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

**仕様書無しさん** · 2018/03/31(土) 10:54:48.19

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

**仕様書無しさん** · 2018/03/31(土) 11:06:35.55

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

**仕様書無しさん** · 2018/03/31(土) 12:16:16.90

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

**仕様書無しさん** · 2018/03/31(土) 12:19:33.53

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

**仕様書無しさん** · 2018/03/31(土) 12:22:24.94

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

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

**仕様書無しさん** · 2018/03/31(土) 12:22:35.99

Animalじゃなかったその下

**仕様書無しさん** · 2018/03/31(土) 12:33:04.42

Animalの下っていうと
Humanか？

**仕様書無しさん** · 2018/03/31(土) 13:20:04.83

class Human extended Ameba

**仕様書無しさん** · 2018/03/31(土) 13:32:39.80

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

**仕様書無しさん** · 2018/03/31(土) 13:51:09.60

ムカデサポート

**仕様書無しさん** · 2018/03/31(土) 14:30:15.36

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

**仕様書無しさん** · 2018/03/31(土) 14:42:40.12

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

**仕様書無しさん** · 2018/03/31(土) 16:20:17.18

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

new 鶴();
new 亀();

**仕様書無しさん** · 2018/03/31(土) 16:23:18.96

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

**仕様書無しさん** · 2018/03/31(土) 16:31:46.26

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

**仕様書無しさん** · 2018/03/31(土) 16:37:23.87

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

**仕様書無しさん** · 2018/03/31(土) 16:44:28.00

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

**仕様書無しさん** · 2018/03/31(土) 16:44:38.04

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

**仕様書無しさん** · 2018/03/31(土) 17:00:27.55

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

**仕様書無しさん** · 2018/03/31(土) 17:08:55.16

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

**仕様書無しさん** · 2018/03/31(土) 17:16:12.31

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

**仕様書無しさん** · 2018/03/31(土) 17:19:26.00

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

**仕様書無しさん** · 2018/03/31(土) 17:20:05.19

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

**仕様書無しさん** · 2018/03/31(土) 17:59:40.91

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

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

**仕様書無しさん** · 2018/03/31(土) 18:04:25.37

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

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

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

**仕様書無しさん** · 2018/03/31(土) 18:38:22.52

そして神クラスへ

**仕様書無しさん** · 2018/03/31(土) 18:52:44.69

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

**仕様書無しさん** · 2018/03/31(土) 19:05:10.25

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

**仕様書無しさん** · 2018/03/31(土) 19:11:54.45

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

**仕様書無しさん** · 2018/03/31(土) 19:22:06.32

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

**仕様書無しさん** · 2018/03/31(土) 20:14:55.74

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

**仕様書無しさん** · 2018/03/31(土) 20:21:53.30

>>32
OA進化論者か・・・

**仕様書無しさん** · 2018/03/31(土) 20:54:12.34

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

**仕様書無しさん** · 2018/03/31(土) 20:58:55.10

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

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

**仕様書無しさん** · 2018/03/31(土) 22:11:19.03

唐傘小僧参戦決定!

**仕様書無しさん** · 2018/03/31(土) 22:12:23.68

>>76

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

**仕様書無しさん** · 2018/03/31(土) 22:15:10.00

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

**仕様書無しさん** · 2018/03/31(土) 22:25:52.42

キメラクラス

**仕様書無しさん** · 2018/03/31(土) 22:38:26.54

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

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

**仕様書無しさん** · 2018/03/31(土) 22:40:33.48

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

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

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

**仕様書無しさん** · 2018/03/31(土) 23:11:56.15

>>81

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

**仕様書無しさん** · 2018/03/31(土) 23:13:21.90

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

**仕様書無しさん** · 2018/04/01(日) 00:12:58.66

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

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

**仕様書無しさん** · 2018/04/01(日) 00:19:02.73

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

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

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

**仕様書無しさん** · 2018/04/01(日) 00:41:04.84

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

**仕様書無しさん** · 2018/04/01(日) 00:42:54.88

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

**仕様書無しさん** · 2018/04/01(日) 00:45:07.79

class スライム:ウンコ

**仕様書無しさん** · 2018/04/01(日) 01:53:24.59

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

**仕様書無しさん** · 2018/04/01(日) 02:42:16.23

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

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

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

**仕様書無しさん** · 2018/04/01(日) 02:53:57.04

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

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

**仕様書無しさん** · 2018/04/01(日) 02:59:36.14

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

**仕様書無しさん** · 2018/04/01(日) 03:00:57.96

>>90
こんな感じじゃね？

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

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

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

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

**仕様書無しさん** · 2018/04/01(日) 09:42:34.11

>>92
カプセル化、全否定かよ

**仕様書無しさん** · 2018/04/01(日) 09:48:34.07

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

**仕様書無しさん** · 2018/04/01(日) 10:53:24.38

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

**仕様書無しさん** · 2018/04/01(日) 11:00:52.39

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

**仕様書無しさん** · 2018/04/01(日) 11:02:50.87

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

**仕様書無しさん** · 2018/04/01(日) 11:04:28.90

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

**仕様書無しさん** · 2018/04/01(日) 11:19:29.37

なんでだよヴァカ

**仕様書無しさん** · 2018/04/01(日) 11:20:49.02

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

**仕様書無しさん** · 2018/04/01(日) 11:25:54.85

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

**仕様書無しさん** · 2018/04/01(日) 11:27:36.67

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

**仕様書無しさん** · 2018/04/01(日) 11:28:07.57

trello

https://trello.com/

**仕様書無しさん** · 2018/04/01(日) 11:35:30.27

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

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

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

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

**仕様書無しさん** · 2018/04/01(日) 11:38:17.87

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

**仕様書無しさん** · 2018/04/01(日) 11:44:16.63

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

**仕様書無しさん** · 2018/04/01(日) 11:58:05.21

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

**仕様書無しさん** · 2018/04/01(日) 14:26:36.47

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

**仕様書無しさん** · 2018/04/01(日) 14:33:16.18

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

**仕様書無しさん** · 2018/04/01(日) 15:12:47.23

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

**仕様書無しさん** · 2018/04/01(日) 15:36:20.72

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

**仕様書無しさん** · 2018/04/01(日) 18:48:36.51

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

**仕様書無しさん** · 2018/04/01(日) 19:49:08.77

>>87
ステータスの管理だけならば構造体でも良いけど、
実際には>>94のような攻撃や防御といった自分の動作まで記述するから
メインルーチンからはさらに手間がかからなくなる
スライムの攻撃や防御のロジックを別で書くと管理が面倒になる

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

**仕様書無しさん** · 2018/04/01(日) 19:56:19.28

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

**仕様書無しさん** · 2018/04/01(日) 21:29:46.71

例え話の正しい使い方

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

例え話に対する反論方法

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

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

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

**仕様書無しさん** · 2018/04/01(日) 21:41:14.57

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

**仕様書無しさん** · 2018/04/01(日) 22:49:51.85

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

**仕様書無しさん** · 2018/04/01(日) 22:52:09.26

>>119
自己紹介乙

**KAC** · 2018/04/01(日) 23:08:32.06

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

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

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

**仕様書無しさん** · 2018/04/02(月) 10:10:08.67

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

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

**仕様書無しさん** · 2018/04/02(月) 12:11:56.92

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

**仕様書無しさん** · 2018/04/02(月) 12:39:42.79

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

**仕様書無しさん** · 2018/04/02(月) 12:59:33.19

>>124
うん。

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

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

**仕様書無しさん** · 2018/04/02(月) 16:14:28.23

人間の認識に近いんよ

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

**仕様書無しさん** · 2018/04/02(月) 17:45:05.58

>>125
ソースは？

**KAC** · 2018/04/02(月) 18:13:59.61

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

**仕様書無しさん** · 2018/04/02(月) 20:33:04.06

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

**仕様書無しさん** · 2018/04/03(火) 11:20:33.32

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

**仕様書無しさん** · 2018/04/03(火) 20:02:23.79

>>130
そんな事実はない

**仕様書無しさん** · 2018/04/03(火) 23:20:42.41

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

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

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

**仕様書無しさん** · 2018/04/03(火) 23:22:07.73

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

と言いたいんだろうなｗ

**仕様書無しさん** · 2018/04/03(火) 23:28:37.78

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

**仕様書無しさん** · 2018/04/03(火) 23:43:06.63

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

**仕様書無しさん** · 2018/04/03(火) 23:47:11.47

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

**仕様書無しさん** · 2018/04/04(水) 04:46:26.02

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

**仕様書無しさん** · 2018/04/04(水) 08:20:43.18

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

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

**仕様書無しさん** · 2018/04/04(水) 08:56:46.85

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

**仕様書無しさん** · 2018/04/04(水) 12:47:34.68

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

程度の認識だわ

**仕様書無しさん** · 2018/04/04(水) 21:10:53.00

指向だからええんじゃね

グローバル変数禁止で

**仕様書無しさん** · 2018/04/05(木) 00:28:53.41

ALLシングルトン

**仕様書無しさん** · 2018/04/05(木) 07:01:04.00

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

**仕様書無しさん** · 2018/04/06(金) 01:03:31.62

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

**仕様書無しさん** · 2018/04/06(金) 07:34:51.82

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

**仕様書無しさん** · 2018/04/06(金) 11:39:18.39

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

**仕様書無しさん** · 2018/04/06(金) 19:47:11.73

俺もお前もシングルトン

**仕様書無しさん** · 2018/04/06(金) 19:49:43.96

そしていつでも疎結合

**仕様書無しさん** · 2018/04/07(土) 04:32:57.07

ガバガバなんですね

**仕様書無しさん** · 2018/04/08(日) 16:13:10.05

OOPの本質は疎結合

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

**仕様書無しさん** · 2018/04/08(日) 16:39:24.28

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

**仕様書無しさん** · 2018/04/08(日) 16:47:56.67

>>150
シングルトンアルヨ

**仕様書無しさん** · 2018/04/08(日) 19:43:48.98

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

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

**仕様書無しさん** · 2018/04/08(日) 19:48:29.64

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

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

**仕様書無しさん** · 2018/04/08(日) 19:58:03.19

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

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

**仕様書無しさん** · 2018/04/08(日) 20:02:41.75

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

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

**仕様書無しさん** · 2018/04/08(日) 20:16:23.28

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

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

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

**仕様書無しさん** · 2018/04/08(日) 20:18:32.13

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

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

**仕様書無しさん** · 2018/04/08(日) 20:23:58.93

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

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

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

**仕様書無しさん** · 2018/04/08(日) 20:31:42.75

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

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

**仕様書無しさん** · 2018/04/08(日) 20:32:45.75

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

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

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

**仕様書無しさん** · 2018/04/08(日) 21:12:12.47

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

**仕様書無しさん** · 2018/04/08(日) 21:57:23.36

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

**仕様書無しさん** · 2018/04/08(日) 22:09:09.99

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

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

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

**仕様書無しさん** · 2018/04/09(月) 01:49:44.62

>>163
マシになってるが？

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

**仕様書無しさん** · 2018/04/09(月) 02:21:02.04

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

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

**仕様書無しさん** · 2018/04/09(月) 06:00:19.44

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

**仕様書無しさん** · 2018/04/09(月) 06:14:09.96

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

基礎からやり直したら？

**仕様書無しさん** · 2018/04/09(月) 07:23:37.69

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

**仕様書無しさん** · 2018/04/09(月) 07:34:02.61

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

**仕様書無しさん** · 2018/04/09(月) 08:06:57.70

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

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

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

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

**仕様書無しさん** · 2018/04/09(月) 08:11:52.00

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

**仕様書無しさん** · 2018/04/09(月) 21:24:10.59

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

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

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

**仕様書無しさん** · 2018/04/09(月) 22:05:50.79

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

**仕様書無しさん** · 2018/04/09(月) 22:22:45.97

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

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

**仕様書無しさん** · 2018/04/09(月) 22:27:27.23

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

**仕様書無しさん** · 2018/04/09(月) 22:29:02.46

今どきなら？

**仕様書無しさん** · 2018/04/09(月) 22:47:17.50

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

**仕様書無しさん** · 2018/04/10(火) 00:55:45.03

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

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

**仕様書無しさん** · 2018/04/10(火) 01:05:58.00

>>179
え？何が良くなったの？

**仕様書無しさん** · 2018/04/10(火) 01:10:21.61

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

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

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

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

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

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

**仕様書無しさん** · 2018/04/10(火) 01:14:07.38

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

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

**仕様書無しさん** · 2018/04/10(火) 01:18:55.41

>>182
ワロタww
その通りだよ

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

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

**仕様書無しさん** · 2018/04/10(火) 01:53:40.12

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

**仕様書無しさん** · 2018/04/10(火) 02:03:59.52

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

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

**仕様書無しさん** · 2018/04/10(火) 06:53:32.48

ここでいいよ

**仕様書無しさん** · 2018/04/10(火) 09:06:36.39

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

**仕様書無しさん** · 2018/04/10(火) 09:10:01.78

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

**仕様書無しさん** · 2018/04/10(火) 10:45:43.04

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

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

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

**仕様書無しさん** · 2018/04/10(火) 14:06:04.12

>>188
pythonの関数はどうだろう？

**仕様書無しさん** · 2018/04/10(火) 14:59:07.58

>>190
詳しく

**仕様書無しさん** · 2018/04/10(火) 23:28:17.29

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

ただ>>182-183のいう事もごもっともだとおもいます。

**仕様書無しさん** · 2018/04/11(水) 00:21:14.21

>>192
なるほど

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

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

**仕様書無しさん** · 2018/04/11(水) 00:51:38.94

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

**仕様書無しさん** · 2018/04/11(水) 04:53:13.04

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

**仕様書無しさん** · 2018/04/11(水) 22:43:47.41

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

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

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

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

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

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

**仕様書無しさん** · 2018/04/12(木) 01:08:59.73

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

**仕様書無しさん** · 2018/04/12(木) 07:07:30.91

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

**仕様書無しさん** · 2018/04/14(土) 11:50:31.79

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

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

**仕様書無しさん** · 2018/04/14(土) 11:51:40.87

コピペしなくて良いよ