カプセル化の有害性、オブジェクト指向は愚かな考え

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/06/18(木) 23:47:36.69ID:l/2SQUll
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。

かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性」として「カプセル化は絶対にやめろ」としている。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)
2020/06/24(水) 01:13:12.47ID:ZBvJ9IFx
カプセル化の弊害とかいいつつ
カプセル化すら理解してなくて草生える
2020/06/24(水) 01:57:06.31ID:W7e3ICMc
>>76を見てると、オブジェクト指向を批判しているのはバカが過剰に騒いでいるだけなんだなと良く分かるw
2020/06/24(水) 02:39:07.65ID:gVxDDgwX
今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな
2020/06/24(水) 03:02:02.88ID:irp07WaX
>>81
匿名性のSNSの限界。
記名性だと色々と能力が分かって、無視される。
2020/06/24(水) 04:52:29.63ID:evfa9tXu
>>76
何がいいたいのか全くわからん。

例えばお前が言ってる頭の悪いやつが、
ローカル変数をグローバル変数に変えるかもしれんよな？
そういう場合、なんだっていうんだ？
ローカル変数が悪いって話をしてるのか？
それを止められないからローカル変数は邪魔といいたいのか？
2020/06/24(水) 07:20:27.23ID:ib1NZqNH
>>84
まあ、しょうがねぇよなって話じゃん
2020/06/24(水) 07:21:13.77ID:ib1NZqNH
初めの書き手が悪いんじゃなくてあくまで変更したやつの責任
2020/06/24(水) 12:20:09.25ID:irp07WaX
>>76
というか、MFCみたいに修正が推奨されて無い場合は除いて、
自社開発のプログラムであれば、能力がある人にはあなたが修正するのを
上司が許可してくれると思うんだ。
もし、修正を許可してもらえないなら、実績が足りて無いか能力のアピールが足りてない。
2020/06/24(水) 12:31:25.83ID:bZ0w8eld
オブジェクト指向の肝は擬人化と依頼だからな
頼む相手の内部状態を勝手に変えないってのは
無茶重要でしょ　
2020/06/24(水) 13:17:22.34ID:U8BVWvkL
>>88
>オブジェクト指向の肝は擬人化と依頼だからな
初めて聞いた
2020/06/24(水) 13:54:42.95ID:bZ0w8eld
擬人化キャラ（クラス）の関係性で物語を生成する＝オブジェクト指向
そんなかんじで習ってそのまま理解してたな　ちなみに学校は恥ずかしくて
言えないような底辺学校
2020/06/24(水) 14:29:54.72ID:+bJy5A36
依頼はどことなく委譲って分かるけど擬人化はただのスケベじゃん
2020/06/24(水) 14:40:07.82ID:bZ0w8eld
>>91
頭わるくてまともな学校にいけない奴らに
教えるために先生が工夫してくれたんだろうね　依頼ってのも困ったら
依存心の高い奴らに教えるのにそういう言い回ししたんだろうね
いま思えばなかなか立派な先生だったな　口は臭かったが
2020/06/24(水) 15:16:35.37ID:W7e3ICMc
>>92
分かりやすく噛み砕いて教える方法としては良いと思うけど、>>88のように一般的に通じるつもりでいきなり独自用語を使うと話が変な方にいくから、不特定多数を相手にするときは一般的な用語を使った方がいいぞ。
2020/06/24(水) 16:47:31.01ID:ZBvJ9IFx
>>91
本来人間相手にしかに使わない依頼や委譲って言葉を使ってる時点で擬人化してる
2020/06/24(水) 16:51:31.16ID:ZBvJ9IFx
擬人化と依頼のメタファは一般的
オブジェクト指向に限らないけどOOを説明する際によく使われたから

Tell Don’t Ask
http://media.pragprog.com/articles/jan_03_enbug.pdf
https://martinfowler.com/bliki/TellDontAsk.html
2020/06/24(水) 19:00:14.27ID:z1f+Mb2g
>>76

> お前らの言う頭の悪い奴は元のクラスのprivateを
> publicに変えるかもしれないし
> Personというクラスの隣に
> Person2と言うクラスを複製してそっちの方をpublicに
> 変えて利用するかもしれない。

ねーよw
もう少し基礎知識学んでから出直してこい。
まず、ライブラリの中身を書き換えること自体、ありえない。

たぶん、見ず知らずの人達が書いたコードを共有する仕組みから知らないのだろう。
2020/06/24(水) 19:25:00.99ID:vlqGopWc
>>96
いや、そもそもできちゃうじゃん
そして別にできてもいいじゃん
それが嫌だとしたらそれをドキュメントに書いとけよ
ソースには書けないし書いても消せるからさ
98デフォルトの名無しさん
垢版 |
2020/06/24(水) 19:30:57.72ID:6CkV8gwI
>>96
いや、周囲や協力会社(依頼元クライアント側プログラマ)
にこれやるやつゴロゴロいるんだって
ソースファイルでもテーブルでも何でも他人が書いたやつ
複製して仕様変更に対応するんだわ。
privateとかカプセル化なんて笑っちまうよマジで
でも意外と何とかなってる、複製したあとはレガシーコードは
全部捨てちまうんだわ

職場で新人研修で「抽象クラスって何のために作るんですか？」
って毎回のように訊かれるけど
「俺にも分からない。必要性を感じたことも、便利だと思った
事も無い。」って正直に答えてる。
オブジェクト指向の入門書に当然のようにabstract紹介
されてるけどそれの有用性を的確に説明している
教科書を見たことがない
interfaceのほうは重要性は分かるしちゃんと説明している
2020/06/24(水) 19:42:39.07ID:J59L1bOF
>>98
abstractは
上の方の人達が未知の設計概要として会議で使う
コーダーじゃない営業や客とのコミュニケーション用
2020/06/24(水) 19:53:36.46ID:GEcMOOIw
>>75
これだろ
https://ja.m.wikipedia.org/wiki/DARPAモデル

DARPAモデルとは、インターネットの持つべき通信機能を階層構造に分割したモデルである。

アプリケーション層、トランスポート層、インターネット層、ネットワーク層の4層で構成される。

DARPAモデルという呼称は、インターネットの研究開発を行っていたDARPAに由来する。
元々は確固たる仕様や定義はなく、IPやTCPやUDPなどの仕様中に個々に、あるいは暗黙の前提として存在していたものだが、後からRFC 1122で1つにまとめられた。


IP群はプロトコルとサービスをカプセル化する事によって抽象化する。
通常、より上位層のプロトコルはその目的の達成に役立てるために、より下位層のプロトコルを用いる。
これまでIETFはインターネット・プロトコル・スタックをRFC 1122で定義された4層から変更した事はない。
IETFは7層からなるOSI参照モデルに従うような試みはせず、また標準化過程（Standards Track）にあるプロトコル仕様やその他の構造上の文書をOSI参照モデルに対して参照する事もしない。

https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:UDP_encapsulation.svg

RFC 3439では、インターネット構造に関して第3章の序文に"Layering Considered Harmful （階層化の有害性）"と題された節が有り、
「階層化」という考え方が概念的および構造的にさまざまな利点を持っているが、
実装面では層単位で同じような最適化が繰り返し発生することによる無駄な処理により効率的な実装を阻害し、複雑化を招くことがあり、
また低層部分のみに存在するデータにアクセスできない場面が発生するなど、

インターネット・プロトコルの目指す「単純化」という原則に反することもあることが明記された。
2020/06/24(水) 20:04:30.89ID:GEcMOOIw
>>75
ググったら日本語訳もあった
http://www5d.biglobe.ne.jp/stssk/rfc/rfc3439j.html
2020/06/24(水) 21:01:40.99ID:7L466iYI
>>98
抽象クラスは単なるテンプレ
クラスを作る際の約束事を規定できる
具体的には実装忘れやメソッド名を間違えるのを防げる
自分のような忘れぽい人間には役立つ
2020/06/24(水) 22:26:02.81ID:z1f+Mb2g
>>98
> 「俺にも分からない。必要性を感じたことも、便利だと思った事も無い。」って正直に答えてる。

正直なのはいいけど...なんで、privateの有効性がわからないのに、カプセル化を批判するのか。
無知の批判ほど、初心者が誤解を生む原因になるからやめてほしい。

例えばだよ。
何の言語をよく使うのか不明だが...標準ライブラリってあるじゃん？
その標準ライブラリのクラスに「呼び出したら破綻する(内部処理実装用の)メソッドや変数」が定義されていたら、どうする？
クラスを使う人に呼び出してほしくない機能はprivateにするべきでしょ。
実装する側の都合だけじゃなくて、クラスを使うユーザーのことも配慮して使うものだよ。

OOPアンチとOOP活用者の絶対的な違いは自作したクラスを使う人のことを深く考えているかどうか。そこだよ。
2020/06/24(水) 22:30:44.22ID:MQA513Hf
>>103
使う側と作る側が完全に分離した環境に当たったことがない
win32apiや.netframeworkを作る人以外にそんな需要ってあるの？
2020/06/24(水) 22:31:32.44ID:evfa9tXu
>>104
win32apiや.netframeworkを作る人には需要があるって認めたの？
2020/06/24(水) 22:32:45.63ID:z1f+Mb2g
って、わからないのは抽象クラスかいッ！
なんか、アンカを間違えたような間違えていないような微妙な回答をしてしまった...。
まぁ、抽象クラスは>>102に書かれている通りって事で。
2020/06/24(水) 22:34:51.23ID:MQA513Hf
>>105
俺が作るならいらん
状態をクラスのインスタンスが内部に保持してしまうのは害にしかならない
2020/06/24(水) 22:42:26.10ID:MQA513Hf
なんか今までノリでクラスで作ってきたのを止めると物凄くスキルアップするぜ

一度はオブジェクト指向をやってみるのもいいかもなってのは思う
クラス構造で便利なものとそうでないものは当然ながらこの世にはあって
そのほとんどが実はクラスにしないほうがうまくいくものばかりだ
大半の処理は
入力→処理→出力
の繰り返しであってこれのまとまりが
機能となる
ただ極稀にクラス構造で考えた方が便利な構造のものもある
役に立つのはその時だけだ
そしてそのケースは極めて稀である
2020/06/24(水) 22:43:14.13ID:z1f+Mb2g
>>104
.netは勿論、Android、iOSネイティブ、バックエンド node.jsやPython、mbed(組み込み)、
まぁ、一部private機能をサポートしていない環境はあるけど、作る側・使う側の意識は常に持つよ。

.netを知っているってことは、Nugetのことは知っていると思うけど...
gradleとか、npmとか、github等と連携させて他人の作ったライブラリの自動追加及びアップデートの仕組みはいくらでもある。

てか、自分で作ったコードですら、作る側・使う側は意識するよ。
過去に作った自分のソースなんて、他人が作ったソースみたいなものだし。
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。
2020/06/24(水) 22:44:48.06ID:evfa9tXu
>>107
> 俺が作るならいらん
つまり、俺が作らないなら、必要だって言ったのと同じことだよね
2020/06/24(水) 22:47:38.19ID:evfa9tXu
最初からオブジェクト指向は大規模なものを
複数の人で作るためのもので
それをわかってないから、

「俺が一人で作るようなものならいらん」

なんて発言が出てしまうんだよな
2020/06/24(水) 22:52:50.78ID:7L466iYI
>>109
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。
まあこれだよね　
頭いいやつには必要ない技術かもね　凡人には必須だとおもうけどな
あと設計思想とかそんな面倒な話じゃなくてシンプルに補完ができるのが楽　
2020/06/24(水) 22:54:20.40ID:VGKuFIs7
>>107
内部に保持するのが良いとは言わんが外部に公開すれば良いってもんでも無いでしょ
いつ何時外部から状態が変更されても破綻しないように責任持てと言われても
僕は頭が悪いから無理です
2020/06/24(水) 22:55:53.79ID:evfa9tXu
そもそもprivateっていうのはコミュニケーションの道具で
privateって書いていなければ、好き放題アクセスしてOKという意味に
捉えられるかもしれないわけだ。

コメントの高度版なのだからコメントなくてもできるのは当たり前
だがそうすると修正が難しくなる

俺が作るなら〜っていうのはコミュニケーションが
必要ないから言える話
2020/06/24(水) 22:58:49.48ID:z1f+Mb2g
>>112
まぁ、そうだな。
ただ、面白いのが...
頭のいい人がOOPに漬かると、余裕ができた分、コンピューターの仕組みにとらわれずエンドユーザーの事を全力で配慮した品質の高い製品を作れるようになる。
2020/06/24(水) 22:59:48.33ID:z1f+Mb2g
アンカまた間違えた...
2020/06/24(水) 23:00:40.93ID:z1f+Mb2g
間違えてなかった。もうダメだ...
2020/06/24(水) 23:26:13.24ID:MQA513Hf
>>113
構造体でまるっと渡してやるよ
2020/06/24(水) 23:27:50.80ID:MQA513Hf
>>111
逆だな
デカければでかいほどオブジェクト指向で組むのはやめた方がいい
内部の状態遷移を誰も理解できない
2020/06/24(水) 23:31:43.79ID:MQA513Hf
そもそもさ
クラスで状態を保持するソースってさ
実装全部見て
何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
これが最高にダルイ
もう年取ったしこんなの付き合ってらんない面倒臭くて
2020/06/24(水) 23:32:23.15ID:fkg3GZzF
単なるモジュール切り離しのための技術の一つだよ。
バカが騒ぎまくったせいでクソみたいなインターフェイスによる切り離しで
逆に見通しが悪くなることが多くなった。
細かい粒度で使うような技術じゃない。
2020/06/24(水) 23:41:46.40ID:MQA513Hf
>>121
いや、単純に面倒臭いだけでメリット皆無じゃん
2020/06/25(木) 00:13:01.48ID:JeYxH76v
内部に状態変数をもたれたらグローバル変数の比ではないほど厄介。
単体テストやデバッグが壮大なことになる。
2020/06/25(木) 00:16:04.75ID:JeYxH76v
「状態によって挙動が変わる」ものが何十個も何百個も集まったら誰も把握しきれない。誰も制御しきれない。
2020/06/25(木) 01:13:10.51ID:h5MGZkZK
>>119
>内部の状態遷移を誰も理解できない

使う側は内部の状態遷移なんて理解する必要ない
理解しないと使えないようならその設計が悪い
2020/06/25(木) 01:41:45.27ID:Q34w5rfS
内包してる初期化フラグ一つで
全く同じ入力に対して全く異なる出力が出てくるんだから
こいつは厄介だよ

勘がいいやつはこれだけでこの仕組みを使わない
2020/06/25(木) 03:09:24.52ID:9YSX2wtH
>>124
だからオブジェクト指向で小さくするんだよね
128デフォルトの名無しさん
垢版 |
2020/06/25(木) 03:13:43.10ID:AD4h9H61
>>110 君頭悪いねってよく言われない?
2020/06/25(木) 03:15:57.10ID:9YSX2wtH
>>128
言われない。むしろお前のほうが言われてるだろ。
2020/06/25(木) 04:09:57.03ID:3STWDldz
お前ら頭悪いね
131デフォルトの名無しさん
垢版 |
2020/06/25(木) 05:35:58.45ID:AD4h9H61
レス番まで指摘されても自分のおかしい発言に気づけないとはいとあはれ
2020/06/25(木) 05:40:21.51ID:hNcIaCHg
いいぞ、もっとやれ
2020/06/25(木) 07:10:48.49ID:MncJLzSh
内部を知る必要ない。インターフェースだけ守れ
2020/06/25(木) 07:22:24.62ID:/bWSJldt
彡 ⌒ ミ
(´・ω・`) 頭がなんだって？
2020/06/25(木) 07:30:13.69ID:p+gLKGcc
>>122
めんどくさくて新しい(もう20年以上前からメジャーではあるが...)考え方についていけません、てだけだろw

お前が懸念している内部の状態遷移が見えないというのは、見えなくていいように作り、見えなくていい部分だけを隠すんだよ。
お前の大好きな従来の手続き型だって、下手に作れば手続きを呼び出す順序や渡すべきデータの構造や内容が訳分からない複雑なものになるだろう。

単に自分の知ってる手法では良い設計を知っていて問題点を避けられる、よく知らない手法は問題を回避する方法がわからなくて問題のある手法と思えてしまう、ただそれだけのこと。
2020/06/25(木) 07:32:40.30ID:U43KJZDw
クラスの状態はクラスが知ってれば良い
という思想なんじゃねえの？
オブジェクト指向は？
2020/06/25(木) 07:35:44.39ID:Q34w5rfS
>>136
テストするんですが〜
2020/06/25(木) 07:53:57.86ID:Q34w5rfS
>>135
違うだろ
内部の状態が見えないのにテストなんかできないだろ
そのクラス使ってある限りそいつの状態次第で色んな動作しちまうんだから
はっきり言ってクラスは欠陥製品
特に内部に状態を保持するような使い方は害悪
2020/06/25(木) 08:19:04.16ID:p+gLKGcc
>>138
お前はオブジェクトの状態として、外部に影響を与える外部仕様の状態と、外部に影響を与えない内部仕様としての状態を混同してないか？
文字列のオブジェクトが文字列"abcd"を持つとして、それは外部に影響を与えるものだから、privateのメンバとして保持されていようがテストケースとしてそれを与えて状態を設定してテストすればいい。
一方、その文字列がどういう実装で保持されているか、ヒープなのか固定配列なのか、参照カウンタやさらに複雑な仕組みを使っているのかといった内部仕様的な状態は、このクラスを他と組み合わせてテストする段階ではテストする必要がない。こういう部分は、先にクラス単体のテストで保証しておけば良い。
そういう切り分けができない作りになっているなら、それは設計が悪い。
2020/06/25(木) 08:42:04.56ID:Q34w5rfS
>>139
いや、MSのクラスだってなんかよくわからん動作するのあるし
いいとか悪いとかじゃなくて状態を保持したら地獄行き

覚えといてね
2020/06/25(木) 08:57:56.71ID:rghIsJSV
>>122
めんどくさいのはその通り。
テスト駆動開発の本とか読んでどういうオブジェクトを引数にすると
テストしやすいかが理解できてくるとありがたさがわかってくる。
オブジェクト設計とか言い出す馬鹿は無視しろ。
2020/06/25(木) 08:58:07.22ID:XTsRyKlX
>>120

> そもそもさ
> クラスで状態を保持するソースってさ
> 実装全部見て
> 何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
> これが最高にダルイ
> もう年取ったしこんなの付き合ってらんない面倒臭くて

だ、か、ら、
それを解決するためのオブジェクト指向だ つってんだろ！
クラスをオブジェクト指向も意識せずに、ただただ構造体みたいに実装して使うから、そうなるんだよ。
2020/06/25(木) 09:10:36.57ID:p+gLKGcc
>>140
どのクラスを指して言ってるのか知らないが、それはそのクラスの仕様自体の複雑さかお前の理解不足が原因で正しい挙動が分かってないとか未定義動作をさせているとかでないの？
状態を保持するのが問題なのではなく、知っておくべき状態、情報を知らずに上手くいかないのをオブジェクト指向のせいにしているだけのように見えるぞ。
2020/06/25(木) 09:17:11.38ID:rghIsJSV
状態をできるかぎり持たない方がいいってのはその通り。
ただ通信ソケットみたいなもの実装しようとすればどうしても状態を持つわな。
コネクション張るオーバーヘッドが小さくない時点で、性能出そうと思えば状態をもつしかないので。
2020/06/25(木) 09:21:43.95ID:H2Spozu7
オブジェクト指向って設計手法であると同時に
責任の切り分け手法でもあるんだよね　別の共同体（無償で手伝う気なしって意味で）
と作業する場合は必須でしょ
2020/06/25(木) 10:04:43.33ID:Q34w5rfS
>>142
は？メソッド全部staticにしてみろ
大半の問題が解決する
2020/06/25(木) 10:09:16.30ID:XTsRyKlX
>>146
解決しねーよ！むしろ、問題が多発するわ！
それ以前に、何の問題が解決するんだよ。
2020/06/25(木) 10:09:53.75ID:Q34w5rfS
>>145
いやー、クラス内で状態を保持するクラスが大量に呼ばれてて
本来はそれらの全ケースを網羅する必要があるが作業者の裁量で省略されてる状態じゃないっすか？
切り分けじゃないッスよね？
クラスAとクラスBがそれぞれチェックされててもそれらが合わさったことでバグが発生してる可能性もあるンスから
テストはちゃんとやるのであれば状態全網羅でしょう

ぶっちゃけ無理っすわ
状態を保持をやった時点で地獄行き

覚えた？確定事項よ
2020/06/25(木) 10:11:45.88ID:Q34w5rfS
>>147
グローバル変数さえなければ入力に対してぜってー決まった出力しか出ないのに何が問題出るの？
頭おかしいんじゃない？
○○構造のとき作りにくいってのはあると思うけど
わかりやすさでこれ以上はないよ
2020/06/25(木) 10:18:17.66ID:H2Spozu7
>>148
クラスAとクラスBがそれぞれチェックされててもそれらが合わさったことでバグが発生してる
可能性もあるンスから

こうなったときにAもBも直す必要がないでしょってこと　どちらかを直すかは共同体
同士のパワーバランスで決まるんだけどねｗ　そこはまあ大人になるしかない
2020/06/25(木) 10:20:16.04ID:XTsRyKlX
>>148

> >>145
> いやー、クラス内で状態を保持するクラスが大量に呼ばれてて
> 本来はそれらの全ケースを網羅する必要があるが作業者の裁量で省略されてる状態じゃないっすか？

何いってるんだ、こいつ。
クラスの基本的な仕組みから理解していないのか。
状態はインスタンスの数だけ持つことになるけど、呼ばれるロジックは一つだよ？
一つのロジックだけをテストすればいいのに、君はstatic化することで、わざわざ一つの状態につき一つのロジックを用意しようとしている。
つまり、君は一つのインスタンスにつき、一つのロジックを記述することで膨大な数のテストをしなければいけない状況を自分で作っている訳だ。

お前のやり方の方が無理ですわ。
2020/06/25(木) 10:27:24.45ID:Q34w5rfS
>>150
いや、わからないよね？
クラスCで使うためのクラスAとクラスBであるなら使えなきゃしょうがないじゃん
まあ、他でも使ってるなら安全牌はクラスC用のクラスAクラスBの複製だけどｗ
2020/06/25(木) 10:28:11.21ID:Q34w5rfS
>>151
バカの相手はできんわ
2020/06/25(木) 10:29:59.55ID:XTsRyKlX
しかも、１つの状態につき、一つのロジックを書くってことは...似たようなクラスが10個必要になったら、そのクラスのロジックを10回、コピペするわけだ。

で、その後、ロジックを修正することになった場合...10回、コードを書き直すの？
そっちの方が無理ですわ。

いっそのこと、staticにしないで、10個の状態が1個のロジックを参照するようにしておけば、ロジックの修正は一回で済む。
そっちの方が断然、楽だね。
2020/06/25(木) 10:31:50.71ID:XTsRyKlX
>>153

ブーメラン刺さってますよ。
私は仕事するので、その間に頑張って言い訳でも考えていてね！
2020/06/25(木) 10:38:02.77ID:H2Spozu7
>>152
もしかしてインスタンスの意義がわかってないのか？

他でも使ってるなら安全牌はクラスC用のクラスAクラスBの複製だけどｗ

まさしくこの状態を作りたいからクラスAクラスBのインスタンスをつかうんだけどな
2020/06/25(木) 10:41:15.81ID:Q34w5rfS
>>156
え？何言ってるの？
2020/06/25(木) 11:34:09.20ID:emOdy//g
クラス使わない人ってどうするんだろ
構造体？
全部インタプリタみたいな感じ？
2020/06/25(木) 11:40:28.84ID:h5MGZkZK
スレ主の愚痴はオブジェクト指向かどうかと関係ない
単に設計やテストのやり方を知らないだけ
2020/06/25(木) 12:22:45.24ID:9YSX2wtH
>>138
> 内部の状態が見えないのにテストなんかできないだろ

ん？全部publicにしておけばテストできるって話じゃないの？
もしくはprivateであっても、privateを読み書きできる機能があればテストできるでしょ？
2020/06/25(木) 12:25:19.77ID:XTsRyKlX
クラス使っても、staticにするとか訳のわからない事を言い出すし、根本的にオブジェクト指向を理解していない人達が愚痴っているだけだよな。

むしろ、何でもstaticにするのはC言語やC++言語から入った初心者なら誰もがやる失敗。
そんな初心者の失敗をいい歳したおっさんが、オブジェクト指向を批判しながらstaticを勧めるから駄目なんだよ。
我々からすれば、俺らの黒歴史時代の経験を何で上から目線で偉そうに語っているんだ？って感じだね。
流石に、上から目線で語る程、俺の黒歴史は酷くなかったぞ。
2020/06/25(木) 12:43:43.74ID:KZb+gCmD
カプセル化が要らない、と言うのなら、

誰もがデータを読み書きできる状態でどうやってアトミック処理を保証するのか

を教えて欲しいな。
もしかしたら大発明かも。
2020/06/25(木) 12:49:36.79ID:Q34w5rfS
>>160
内包されるよりいくらかCool
ただ、そこまでpublicにできるならstaticにしてほしい
実行時にstatesがnoneでないと正しく動かないんですよこのメソッドって
言われても知らねーよそんなのって感じ
じゃあstatesはどうやってnoneにするんだべって
俺に調べさせるのやめてもらっていい？

もっと言えばstaticにすればそんなことないじゃん？
2020/06/25(木) 13:01:46.41ID:9YSX2wtH
>>163
内包したらテストできないだろ？
2020/06/25(木) 13:06:39.24ID:XTsRyKlX
そもそも、クラスって正常に動く前提で使うものであって、なんで、クラスを使う側がクラス内部動作をテストしないといけないのかわからん。
クラスのテストは、クラスを実装する側の責任だろうに。

...というツッコミをそろそろしてもいいかな？
2020/06/25(木) 13:17:56.03ID:p+gLKGcc
>>165
それに類することをすでに>>139で指摘したんだが、自分考えに凝り固まった意固地なおじさんには通じなかったようだ。
2020/06/25(木) 13:23:03.90ID:p+gLKGcc
>>163
そのstatesがnoneでなければならないという仕様は、そのクラスの使い方として外部に明示すべき仕様だろう。そそういう情報が示されていないならドキュメントの不備だし、そういう仕様が公開されていても外部からstatesの値を参照または設定できないのなら設計の不備だろう。
延々と繰り返し指摘しているように、それはオブジェクト指向そのものの問題でなく正しく設計、運用がされていない問題だろう。
2020/06/25(木) 13:29:58.05ID:XTsRyKlX
>>166
あっ、ほんとだ。
2020/06/25(木) 15:28:55.17ID:xmAi/11M
カプセル化の最大のメリットは中で何をしているかどうなっているかは気にせずに
外からは引数を与えると仕様通りの値が戻ってくるというところだよね?
170デフォルトの名無しさん
垢版 |
2020/06/25(木) 16:47:53.33ID:CiEXbKUP
グローバル変数に格納されている値で関数の挙動が変わるより悲惨だぞ。
グローバル変数が見えないんだから。
2020/06/25(木) 16:52:12.11ID:BM3o+zlw
ん？
2020/06/25(木) 17:00:47.93ID:XTsRyKlX
ID変えて振り出しに戻るって奴？
2020/06/25(木) 17:03:53.35ID:p+gLKGcc
ここまで話の通じない奴だと思うと相手するのがバカらしくなってくるね。まさに徒労という言葉がふさわしい。
2020/06/25(木) 19:27:44.23ID:RQlIhWFK
>>39
カプセル化こそが善
カプセル化こそがOOPのうまみ
2020/06/25(木) 19:35:56.42ID:oGWS7APt
全部staticってどうするんだろう
メソッドの引数すごいことになってそう
176デフォルトの名無しさん
垢版 |
2020/06/25(木) 20:15:30.81ID:LQ8CyLE7
オブジェクト指向のあらゆる用語が
ノムリッシュみたいになってると思う

JavaScriptが発展して、クラス名と同じ名前の
ファイル名にしなくていい事が分かったわけじゃん
それどころかクラスすら必要なしでオブジェクトが作れる事が
分かったわけじゃん
クラス名と同じ名前のコンストラクタなん定義しなくても
オブジェクトが作れる事が分かったじゃん

オブジェクトとは詰まるところ連想配列と大して違いが
ないキーと値で構成された入れ物でしかない事がわかった。
この「連想配列と違いがない」というシンプルな真実が
どれだけありがたいことか

クラスを始めとする様々なルールは
ソフトウェア設計上の重要な概念かと思ってたら
単なるJavaの変な言語仕様でしかなかったわけだ。
変数を「フィールド」
関数を「メソッド」
関数を「コンストラクタ」
こう言い換える必要がどこにある？

こんなノムリッシュなバズワードに
今までどれだけ煙にまかれて
シンプルな真実が見えなくなってたことか
2020/06/25(木) 20:22:00.90ID:9YSX2wtH
>>176
3行でまとめて
178デフォルトの名無しさん
垢版 |
2020/06/25(木) 20:24:37.53ID:LQ8CyLE7
それに加えて
「継承」「抽象クラス」「オーバーライド」
「カプセル化」「ポリモーフィズム」
こんな用語は必ずしもやるのが正しいものではないし
やればやるほどシステムを必要以上に複雑にして
邪魔にしかならないものばかり

それなのに
「オブジェクト指向の本質は継承とカプセル化とポリモーフィズムだ。」
なんて馬鹿げた事を言い始めるノムリッシュな奴が出始めて

JavaScriptならオブジェクトの内部に
別のオブジェクトを入れるという一瞬の操作で
終わるものを「委譲」など余計な用語を定義して

わざわざ定義しなくてもいいようなくだらない
小難しそうな用語だらけになって
「お前はooの概念を正しく理解してない」
という偉そうな批判がどれだけ飛び交うことか
179デフォルトの名無しさん
垢版 |
2020/06/25(木) 20:31:34.09ID:LQ8CyLE7
webフレームワークの
MVCの「モデル」ってそんなに重要ものなのか？
「モデル」なんてものがSQLやDBMSを隠蔽して
何がありがたいと言うのか
むしろ隠蔽されて困ることの方が多いんじゃないか？
何故一度テーブル作成時にて定義した
大量の列定義を
またモデル層のフィールド定義で2度もやり直さないといけないのか
要らないだろ。「モデル」なんて

最近は従来軽視されてきたクライアントサイドJavaScriptの
方がよっぽど重要なことが分かってきて
ReactやVueのようなクライアントサイドフレームワークが
重要視されてるわけじゃん

「オブジェクト指向」って結局何がありがたいのよ？
2020/06/25(木) 21:03:02.32ID:9YSX2wtH
1行でまとめて
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況