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

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

[前50を表示]
100:デフォルトの名無しさん
20/06/24 19:25:00 vlqGopWc.net
>>96
いや、そもそもできちゃうじゃん
そして別にできてもいいじゃん
それが嫌だとしたらそれをドキュメントに書いとけよ
ソースには書けないし書いても消せるからさ

101:デフォルトの名無しさん
20/06/24 19:30:57 6CkV8gwI.net
>>96
いや、周囲や協力会社(依頼元クライアント側プログラマ)
にこれやるやつゴロゴロいるんだって
ソースファイルでもテーブルでも何でも他人が書いたやつ
複製して仕様変更に対応するんだわ。
privateとかカプセル化なんて笑っちまうよマジで
でも意外と何とかなってる、複製したあとはレガシーコードは
全部捨てちまうんだわ

職場で新人研修で「抽象クラスって何のために作るんですか？」
って毎回のように訊かれるけど
「俺にも分からない。必要性を感じたことも、便利だと思った
事も無い。」って正直に答えてる。
オブジェクト指向の入門書に当然のようにabstract紹介
されてるけどそれの有用性を的確に説明している
教科書を見たことがない
interfaceのほうは重要性は分かるしちゃんと説明している

102:デフォルトの名無しさん
20/06/24 19:4

103:2:39 ID:J59L1bOF.net

104:デフォルトの名無しさん
20/06/24 19:53:36 GEcMOOIw.net
>>75
これだろ
URLﾘﾝｸ(ja.m.wikipedia.org)モデル

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

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

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

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

URLﾘﾝｸ(ja.m.wikipedia.org)

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

インターネット・プロトコルの目指す「単純化」という原則に反することもあることが明記された。

105:デフォルトの名無しさん
20/06/24 20:04:30.89 GEcMOOIw.net
>>75
ググったら日本語訳もあった
URLﾘﾝｸ(www5d.biglobe.ne.jp)

106:デフォルトの名無しさん
20/06/24 21:01:40.99 7L466iYI.net
>>98
抽象クラスは単なるテンプレ
クラスを作る際の約束事を規定できる
具体的には実装忘れやメソッド名を間違えるのを防げる
自分のような忘れぽい人間には役立つ

107:デフォルトの名無しさん
20/06/24 22:26:02.81 z1f+Mb2g.net
>>98
> 「俺にも分からない。必要性を感じたことも、便利だと思った事も無い。」って正直に答えてる。
正直なのはいいけど...なんで、privateの有効性がわからないのに、カプセル化を批判するのか。
無知の批判ほど、初心者が誤解を生む原因になるからやめてほしい。
例えばだよ。
何の言語をよく使うのか不明だが...標準ライブラリってあるじゃん？
その標準ライブラリのクラスに「呼び出したら破綻する(内部処理実装用の)メソッドや変数」が定義されていたら、どうする？
クラスを使う人に呼び出してほしくない機能はprivateにするべきでしょ。
実装する側の都合だけじゃなくて、クラスを使うユーザーのことも配慮して使うものだよ。
OOPアンチとOOP活用者の絶対的な違いは自作したクラスを使う人のことを深く考えているかどうか。そこだよ。

108:デフォルトの名無しさん
20/06/24 22:30:44.22 MQA513Hf.net
>>103
使う側と作る側が完全に分離した環境に当たったことがない
win32apiや.netframeworkを作る人以外にそんな需要ってあるの？

109:デフォルトの名無しさん
20/06/24 22:31:32.44 evfa9tXu.net
>>104
win32apiや.netframeworkを作る人には需要があるって認めたの？

110:デフォルトの名無しさん
20/06/24 22:32:45.63 z1f+Mb2g.net
って、わからないのは抽象クラスかいッ！
なんか、アンカを間違えたような間違えていないような微妙な回答をしてしまった...。
まぁ、抽象クラスは >>102に書かれている通りって事で。

111:デフォルトの名無しさん
20/06/24 22:34:51.23 MQA513Hf.net
>>105
俺が作るならいらん
状態をクラスのインスタンスが内部に保持してしまうのは害にしかならない

112:デフォルトの名無しさん
20/06/24 22:42:26.10 MQA513Hf.net
なんか今までノリでクラスで作ってきたのを止めると物凄くスキルアップするぜ
一度はオブジェクト指向をやってみるのもいいかもなってのは思う
クラス構造で便利なものとそうでないものは当然ながらこの世にはあって
そのほとんどが実はクラスにしないほうがうまくいくものばかりだ
大半の処理は
入力→処理→出力
の繰り返しであってこれのまとまりが
機能となる
ただ極稀にクラス構造で考えた方が便利な構造のものもある
役に立つのはその時だけだ
そしてそのケースは極めて稀である

113:デフォルトの名無しさん
20/06/24 22:43:14.13 z1f+Mb2g.net
>>104
.netは勿論、Android、iOSネイティブ、バックエンド node.jsやPython、mbed(組み込み)、
まぁ、一部private機能をサポートしていない環境はあるけど、作る側・使う側の意識は常に持つよ。
.netを知っているってことは、Nugetのことは知っていると思うけど...
gradleとか、npmとか、github等と連携させて他人の作ったライブラリの自動追加及びアップデートの仕組みはいくらでもある。
てか、自分で作ったコードですら、作る側・使う側は意識するよ。
過去に作った自分のソースなんて、他人が作ったソースみたいなものだし。
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。

114:デフォルトの名無しさん
20/06/24 22:44:48.06 evfa9tXu.net
>>107
> 俺が作るならいらん
つまり、俺が作らないなら、必要だって言ったのと同じことだよね

115:デフォルトの名無しさん
20/06/24 22:47:38.19 evfa9tXu.net
最初からオブジェクト指向は大規模なものを
複数の人で作るためのもので
それをわかってないから、
「俺が一人で作るようなものならいらん」
なんて発言が出てしまうんだよな

116:デフォルトの名無しさん
20/06/24 22:52:50.78 7L466iYI.net
>>109
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。
まあこれだよね　
頭いいやつには必要ない技術かもね　凡人には必須だとおもうけどな
あと設計思想とかそんな面倒な話じゃなくてシンプルに補完ができるのが楽　

117:デフォルトの名無しさん
20/06/24 22:54:20.40 VGKuFIs7.net
>>107
内部に保持するのが良いとは言わんが外部に公開すれば良いってもんでも無いでしょ
いつ何時外部から状態が変更されても破綻しないように責任持てと言われても
僕は頭が悪いから無理です

118:デフォルトの名無しさん
20/06/24 22:55:53.79 evfa9tXu.net
そもそもprivateっていうのはコミュニケーションの道具で
privateって書いていなければ、好き放題アクセスしてOKという意味に
捉えられるかもしれないわけだ。
コメントの高度版なのだからコメントなくてもできるのは当たり前
だがそうすると修正が難しくなる
俺が作るなら～っていうのはコミュニケーションが
必要ないから言える話

119:デフォルトの名無しさん
20/06/24 22:58:49.48 z1f+Mb2g.net
>>112
まぁ、そうだな。
ただ、面白いのが...
頭のいい人がOOPに漬かると、余裕ができた分、コンピューターの仕組みにとらわれずエンドユーザーの事を全力で配慮した品質の高い製品を作れるようになる。

120:デフォルトの名無しさん
20/06/24 22:59:48.33 z1f+Mb2g.net
アンカまた間違えた...

121:デフォルトの名無しさん
20/06/24 23:00:40.93 z1f+Mb2g.net
間違えてなかった。もうダメだ...

122:デフォルトの名無しさん
20/06/24 23:26:13.24 MQA513Hf.net
>>113
構造体でまるっと渡してやるよ

123:デフォルトの名無しさん
20/06/24 23:27:50.80 MQA513Hf.net
>>111
逆だな
デカければでかいほどオブジェクト指向で組むのはやめた方がいい
内部の状態遷移を誰も理解できない

124:デフォルトの名無しさん
20/06/24 23:31:43.79 MQA513Hf.net
そもそもさ
クラスで状態を保持するソースってさ
実装全部見て
何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
これが最高にダルイ
もう年取ったしこんなの付き合ってらんない面倒臭くて

125:デフォルトの名無しさん
20/06/24 23:32:23.15 fkg3GZzF.net
単なるモジュール切り離しのための技術の一つだよ。
バカが騒ぎまくったせいでクソみたいなインターフェイスによる切り離しで
逆に見通しが悪くなることが多くなった。
細かい粒度で使うような技術じゃない。

126:デフォルトの名無しさん
20/06/24 23:41:46.40 MQA513Hf.net
>>121
いや、単純に面倒臭いだけでメリット皆無じゃん

127:デフォルトの名無しさん
20/06/25 00:13:01.48 JeYxH76v.net
内部に状態変数をもたれたらグローバル変数の比ではないほど厄介。
単体テストやデバッグが壮大なことになる。

128:デフォルトの名無しさん
20/06/25 00:16:04.75 JeYxH76v.net
「状態によって挙動が変わる」ものが何十個も何百個も集まったら誰も把握しきれない。誰も制御しきれない。

129:デフォルトの名無しさん
20/06/25 01:13:10.51 h5MGZkZK.net
>>119
>内部の状態遷移を誰も理解できない
使う側は内部の状態遷移なんて理解する必要ない
理解しないと使えないようならその設計が悪い

130:デフォルトの名無しさん
20/06/25 01:41:45 Q34w5rfS.net
内包してる初期化フラグ一つで
全く同じ入力に対して全く異なる出力が出てくるんだから
こいつは厄介だよ

勘がいいやつはこれだけでこの仕組みを使わない

131:デフォルトの名無しさん
20/06/25 03:09:24.52 9YSX2wtH.net
>>124
だからオブジェクト指向で小さくするんだよね

132:デフォルトの名無しさん
20/06/25 03:13:43.10 AD4h9H61.net
>>110 君頭悪いねってよく言われない?

133:デフォルトの名無しさん
20/06/25 03:15:57.10 9YSX2wtH.net
>>128
言われない。むしろお前のほうが言われてるだろ。

134:デフォルトの名無しさん
20/06/25 04:09:57.03 3STWDldz.net
お前ら頭悪いね

135:デフォルトの名無しさん
20/06/25 05:35:58 AD4h9H61.net
レス番まで指摘されても自分のおかしい発言に気づけないとはいとあはれ

136:デフォルトの名無しさん
20/06/25 05:40:21 hNcIaCHg.net
いいぞ、もっとやれ

137:デフォルトの名無しさん
20/06/25 07:10:48 MncJLzSh.net
内部を知る必要ない。インターフェースだけ守れ

138:デフォルトの名無しさん
20/06/25 07:22:24.62 /bWSJldt.net
彡 ⌒ ミ
(´・ω・`) 頭がなんだって？

139:デフォルトの名無しさん
20/06/25 07:30:13.69 p+gLKGcc.net
>>122
めんどくさくて新しい(もう20年以上前からメジャーではあるが...)考え方についていけません、てだけだろw
お前が懸念している内部の状態遷移が見えないというのは、見えなくていいように作り、見えなくていい部分だけを隠すんだよ。
お前の大好きな従来の手続き型だって、下手に作れば手続きを呼び出す順序や渡すべきデータの構造や内容が訳分からない複雑なものになるだろう。
単に自分の知ってる手法では良い

140:設計を知っていて問題点を避けられる、よく知らない手法は問題を回避する方法がわからなくて問題のある手法と思えてしまう、ただそれだけのこと。

141:デフォルトの名無しさん
20/06/25 07:32:40.30 U43KJZDw.net
クラスの状態はクラスが知ってれば良い
という思想なんじゃねえの？
オブジェクト指向は？

142:デフォルトの名無しさん
20/06/25 07:35:44.39 Q34w5rfS.net
>>136
テストするんですが～

143:デフォルトの名無しさん
20/06/25 07:53:57.86 Q34w5rfS.net
>>135
違うだろ
内部の状態が見えないのにテストなんかできないだろ
そのクラス使ってある限りそいつの状態次第で色んな動作しちまうんだから
はっきり言ってクラスは欠陥製品
特に内部に状態を保持するような使い方は害悪

144:デフォルトの名無しさん
20/06/25 08:19:04.16 p+gLKGcc.net
>>138
お前はオブジェクトの状態として、外部に影響�

145:^える外部仕様の状態と、外部に影響を与えない内部仕様としての状態を混同してないか？文字列のオブジェクトが文字列"abcd"を持つとして、それは外部に影響を与えるものだから、privateのメンバとして保持されていようがテストケースとしてそれを与えて状態を設定してテストすればいい。一方、その文字列がどういう実装で保持されているか、ヒープなのか固定配列なのか、参照カウンタやさらに複雑な仕組みを使っているのかといった内部仕様的な状態は、このクラスを他と組み合わせてテストする段階ではテストする必要がない。こういう部分は、先にクラス単体のテストで保証しておけば良い。そういう切り分けができない作りになっているなら、それは設計が悪い。

146:デフォルトの名無しさん
20/06/25 08:42:04.56 Q34w5rfS.net
>>139
いや、MSのクラスだってなんかよくわからん動作するのあるし
いいとか悪いとかじゃなくて状態を保持したら地獄行き
覚えといてね

147:デフォルトの名無しさん
20/06/25 08:57:56 rghIsJSV.net
>>122
めんどくさいのはその通り。
テスト駆動開発の本とか読んでどういうオブジェクトを引数にすると
テストしやすいかが理解できてくるとありがたさがわかってくる。
オブジェクト設計とか言い出す馬鹿は無視しろ。

148:デフォルトの名無しさん
20/06/25 08:58:07 XTsRyKlX.net
>>120

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

だ、か、ら、
それを解決するためのオブジェクト指向だつってんだろ！
クラスをオブジェクト指向も意識せずに、ただただ構造体みたいに実装して使うから、そうなるんだよ。

149:デフォルトの名無しさん
20/06/25 09:10:36 p+gLKGcc.net
>>140
どのクラスを指して言ってるのか知らないが、それはそのクラスの仕様自体の複雑さかお前の理解不足が原因で正しい挙動が分かってないとか未定義動作をさせているとかでないの？
状態を保持するのが問題なのではなく、知っておくべき状態、情報を知らずに上手くいかないのをオブジェクト指向のせいにしているだけのように見えるぞ。

150:デフォルトの名無しさん
20/06/25 09:17:11.38 rghIsJSV.net
状態をできるかぎり持たない方がいいってのはその通り。
ただ通信ソケットみたいなもの実装しようとすればどうしても状態を持つわな。
コネクション張るオーバーヘッドが小さくない時点で、性能出そうと思えば状態をもつしかないので。

151:デフォルトの名無しさん
20/06/25 09:21:43.95 H2Spozu7.net
オブジェクト指向って設計手法であると同時に
責任の切り分け手法でもあるんだよね　別の共同体（無償で手伝う気なしって意味で）
と作業する場合は必須でしょ

152:デフォルトの名無しさん
20/06/25 10:04:43.33 Q34w5rfS.net
>>142
は？メソッド全部staticにしてみろ
大半の問題が解決する

153:デフォルトの名無しさん
20/06/25 10:09:16 XTsRyKlX.net
>>146
解決しねーよ！むしろ、問題が多発するわ！
それ以前に、何の問題が解決するんだよ。

154:デフォルトの名無しさん
20/06/25 10:09:53 Q34w5rfS.net
>>145
いやー、クラス内で状態を保持するクラスが大量に呼ばれてて
本来はそれらの全ケースを網羅する必要があるが作業者の裁量で省略されてる状態じゃないっすか？
切り分けじゃないッスよね？
クラスAとクラスBがそれぞれチェックされててもそれらが合わさったことでバグが発生してる可能性もあるンスから
テストはちゃんとやるのであれば状態全網羅でしょう

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

覚えた？確定事項よ

155:デフォルトの名無しさん
20/06/25 10:11:45 Q34w5rfS.net
>>147
グローバル変数さえなければ入力に対してぜってー決まった出力しか出ないのに何が問題出るの？
頭おかしいんじゃない？
○○構造のとき作りにくいってのはあると思うけど
わかりやすさでこれ以上はないよ

156:デフォルトの名無しさん
20/06/25 10:18:17 H2Spozu7.net
>>148
クラスAとクラスBがそれぞれチェックされててもそれらが合わさったことでバグが発生してる
可能性もあるンスから

こうなったときにAもBも直す必要がないでしょってこと　どちらかを直すかは共同体
同士のパワーバランスで決まるんだけどねｗ　そこはまあ大人になるしかない

157:デフォルトの名無しさん
20/06/25 10:20:16 XTsRyKlX.net
>>148

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

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

お前のやり方の方が無理ですわ。

158:デフォルトの名無しさん
20/06/25 10:27:24 Q34w5rfS.net
>>150
いや、わからないよね？
クラスCで使うためのクラスAとクラスBであるなら使えなきゃしょうがないじゃん
まあ、他でも使ってるなら安全牌はクラスC用のクラスAクラスBの複製だけどｗ

159:デフォルトの名無しさん
20/06/25 10:28:11.21 Q34w5rfS.net
>>151
バカの相手はできんわ

160:デフォルトの名無しさん
20/06/25 10:29:59.55 XTsRyKlX.net
しかも、１つの状態につき、一つのロジックを書くってことは...似たようなクラスが10個必要になったら、そのクラスのロジックを10回、コピペするわけだ。
で、その後、ロジックを修正することになった場合...10回、コードを書き直すの？
そっちの方が無理ですわ。
いっそのこと、staticにしないで、10個の状態が1個のロジックを参照するようにしておけば、ロジックの修正は一回で済む。
そっちの方が断然、楽だね。

161:デフォルトの名無しさん
20/06/25 10:31:50.71 XTsRyKlX.net
>>153
ブーメラン刺さってますよ。
私は仕事するので、その間に頑張って言い訳でも考えていてね！

162:デフォルトの名無しさん
20/06/25 10:38:02 H2Spozu7.net
>>152
もしかしてインスタンスの意義がわかってないのか？

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

まさしくこの状態を作りたいからクラスAクラスBのインスタンスをつかうんだけどな

163:デフォルトの名無しさん
20/06/25 10:41:15 Q34w5rfS.net
>>156
え？何言ってるの？

164:デフォルトの名無しさん
20/06/25 11:34:09.20 emOdy//g.net
クラス使わない人ってどうするんだろ
構造体？
全部インタプリタみたいな感じ？

165:デフォルトの名無しさん
20/06/25 11:40:28.84 h5MGZkZK.net
スレ主の愚痴はオブジェクト指向かどうかと関係ない
単に設計やテストのやり方を知らないだけ

166:デフォルトの名無しさん
20/06/25 12:22:45 9YSX2wtH.net
>>138
> 内部の状態が見えないのにテストなんかできないだろ

ん？全部publicにしておけばテストできるって話じゃないの？
もしくはprivateであっても、privateを読み書きできる機能があればテストできるでしょ？

167:デフォルトの名無しさん
20/06/25 12:25:19.77 XTsRyKlX.net
クラス使っても、staticにするとか訳のわからない事を言い出すし、根本的にオブジェクト指向を理解していない人達が愚痴っているだけだよな。
むしろ、何でもstaticにするのはC言語やC++言語から入った初心者なら誰もがやる失敗。
そんな初心者の失敗をいい歳したおっさんが、オブジェクト指向を批判しながらstaticを勧めるから駄目なんだよ。
我々からすれば、俺らの黒歴史時代の経験を何で上から目線で偉そうに語っているんだ？って感じだね。
流石に、上から目線で語る程、俺の黒歴史は酷くなかったぞ。

168:デフォルトの名無しさん
20/06/25 12:43:43.74 KZb+gCmD.net
カプセル化が要らない、と言うのなら、
誰もがデータを読み書きできる状態でどうやってアトミック処理を保証するのか
を教えて欲しいな。
もしかしたら大発明かも。

169:デフォルトの名無しさん
20/06/25 12:49:36.79 Q34w5rfS.net
>>160
内包されるよりいくらかCool
ただ、そこまでpublicにできるならstaticにしてほしい
実行時にstatesがnoneでないと正しく動かないんですよこのメソッドって
言われても知らねーよそんなのって感じ
じゃあstatesはどうやってnoneにするんだべって
俺に調べさせるのやめてもらっていい？
もっと言えばstaticにすればそんなことないじゃん？

170:デフォルトの名無しさん
20/06/25 13:01:46.41 9YSX2wtH.net
>>163
内包したらテストできないだろ？

171:デフォルトの名無しさん
20/06/25 13:06:39.24 XTsRyKlX.net
そもそも、クラスって正常に動く前提で使うものであって、なんで、クラスを使う側がクラス内部動作をテストしないといけないのかわからん。
クラスのテストは、クラスを実装する側の責任だろうに。
...というツッコミをそろそろしてもいいかな？

172:デフォルトの名無しさん
20/06/25 13:17:56 p+gLKGcc.net
>>165
それに類することをすでに>>139で指摘したんだが、自分考えに凝り固まった意固地なおじさんには通じなかったようだ。

173:デフォルトの名無しさん
20/06/25 13:23:03 p+gLKGcc.net
>>163
そのstatesがnoneでなければならないという仕様は、そのクラスの使い方として外部に明示すべき仕様だろう。そそういう情報が示されていないならドキュメントの不備だし、そういう仕様が公開されていても外部からstatesの値を参照または設定できないのなら設計の不備だろう。
延々と繰り返し指摘しているように、それはオブジェクト指向そのものの問題でなく正しく設計、運用がされていない問題だろう。

174:デフォルトの名無しさん
20/06/25 13:29:58.05 XTsRyKlX.net
>>166
あっ、ほんとだ。

175:デフォルトの名無しさん
20/06/25 15:28:55 xmAi/11M.net
カプセル化の最大のメリットは中で何をしているかどうなっているかは気にせずに
外からは引数を与えると仕様通りの値が戻ってくるというところだよね?

176:デフォルトの名無しさん
20/06/25 16:47:53.33 CiEXbKUP.net
グローバル変数に格納されている値で関数の挙動が変わるより悲惨だぞ。
グローバル変数が見えないんだから。

177:デフォルトの名無しさん
20/06/25 16:52:12.11 BM3o+zlw.net
ん？

178:デフォルトの名無しさん
20/06/25 17:00:47.93 XTsRyKlX.net
ID変えて振り出しに戻るって奴？

179:デフォルトの名無しさん
20/06/25 17:03:53.35 p+gLKGcc.net
ここまで話の通じない奴だと思うと相手するのがバカらしくなってくるね。まさに徒労という言葉がふさわしい。

180:デフォルトの名無しさん
20/06/25 19:27:44.23 RQlIhWFK.net
>>39
カプセル化こそが善
カプセル化こそがOOPのうまみ

181:デフォルトの名無しさん
20/06/25 19:35:56.42 oGWS7APt.net
全部staticってどうするんだろう
メソッドの引数すごいことになってそう

182:デフォルトの名無しさん
20/06/25 20:15:30.81 LQ8CyLE7.net
オブジェクト指向のあらゆる用語が
ノムリッシュみたいになってると思う
JavaScriptが発展して、クラス名と同じ名前の
ファイル名にしなくていい事が分かったわけじゃん
それどころかクラスすら必要なしでオブジェクトが作れる事が
分かったわけじゃん
クラス名と同じ名前のコンストラクタなん定義しなくても
オブジェクトが作れる事が分かったじゃん
オブジェクトとは詰まるところ連想配列と大して違いが
ないキーと値で構成された入れ物でしかない事がわかった。
この「連想配列と違いがない」というシンプルな真実が
どれだけありがたいことか
クラスを始めとする様々なルールは
ソフトウェア設計上の重要な概念かと思ってたら
単なるJavaの変な言語仕様でしかなかったわけだ。
変数を「フィールド」
関数を「メソッド」
関数を「コンストラクタ」
こう言い換える必要がどこにある？
こんなノムリッシュなバズワードに
今までどれだけ煙にまかれて
シンプルな真実が見えなくなってたことか

183:デフォルトの名無しさん
20/06/25 20:22:00.90 9YSX2wtH.net
>>176
3行でまとめて

184:デフォルトの名無しさん
20/06/25 20:24:37.53 LQ8CyLE7.net
それに加えて
「継承」「抽象クラス」「オーバーライド」
「カプセル化」「ポリモーフィズム」
こんな用語は必ずしもやるのが正しいものではないし
やればやるほどシステムを必要以上に複雑にして
邪魔にしかならないものばかり
それなのに
「オブジェクト指向の本質は継承とカプセル化とポリモーフィズムだ。」
なんて馬鹿げた事を言い始めるノムリッシュな奴が出始めて
JavaScriptならオブジェクトの内部に
別のオブジェクトを入れるという一瞬の操作で
終わるものを「委譲」など余計な用語を定義して
わざわざ定義しなくてもいいようなくだらない
小難しそうな用語だらけになって
「お前はooの概念を正しく理解してない」
という偉そうな批判がどれだけ飛び交うことか

185:デフォルトの名無しさん
20/06/25 20:31:34.09 LQ8CyLE7.net
webフレームワークの
MVCの「モデル」ってそんなに重要ものなのか？
「モデル」なんてものがSQLやDBMSを隠蔽して
何がありがたいと言うのか
むしろ隠蔽されて困ることの方が多いんじゃないか？
何故一度テーブル作成時にて定義した
大量の列定義を
またモデル層のフィールド定義で2度もやり直さないといけないのか
要らないだろ。「モデル」なんて
最近は従来軽視されてきたクライアントサイドJavaScriptの
方がよっぽど重要なことが分かってきて
ReactやVueのようなクライアントサイドフレームワークが
重要視されてるわけじゃん
「オブジェクト指向」って結局何がありがたいのよ？

186:デフォルトの名無しさん
20/06/25 21:03:02.32 9YSX2wtH.net
1行でまとめて

187:デフォルトの名無しさん
20/06/25 21:03:32.44 9YSX2wtH.net
> 「オブジェクト指向」って結局何がありがたいのよ？
多くの人で作業分担し、協力してプログラムを作れる所

188:デフォルトの名無しさん
20/06/25 21:03:50.52 9YSX2wtH.net
ReactやVueはオブジェクト指向

189:デフォルトの名無しさん
20/06/25 21:03:50.90 lu0UaGfG.net
>>177
Javaなんてクソを
オブジェクト指向の代表として考える
かわいそうな子

190:デフォルトの名無しさん
20/06/25 21:04:45.08 9YSX2wtH.net
>>183
Javaはオブジェクト指向を採用した言語の一つだよ
いつから代表になったのさ
お前が代表だと思っていて、代表だと思ってる自分自身を批判してるだけじゃんｗ

191:デフォルトの名無しさん
20/06/25 21:05:53.76 lu0UaGfG.net
>>180
抽象化を理解できないかわいそうな子

192:デフォルトの名無しさん
20/06/25 21:09:21.00 9YSX2wtH.net
>>185
お前の文章の話をしてるんだが。
そもそも読んでないのに、抽象化が何の関係があるんだ？

193:デフォルトの名無しさん
20/06/25 21:17:15.89 lu0UaGfG.net
>>184
>>177
＞クラスを始めとする様々なルールは
＞……
＞単なるJavaの変な言語仕様でしかなかったわけだ。
で、「いつから代表になったのさ」がなんだって？
数スレも遡れないようじゃ生きていくの大変だろうに……

194:デフォルトの名無しさん
20/06/25 21:43:56.18 9YSX2wtH.net
だから読んでないと言ってるｗ

195:デフォルトの名無しさん
20/06/26 02:54:16.76 uM2i3sYA.net
関数化したりクラス化したらプログラムが高速化したんだけどGCが発生するタイミングが細かくなったってことでええんか？

196:デフォルトの名無しさん
20/06/26 07:35:03 eLfJJdHb.net
オブジェクト指向は整理術
棚なんて要らん棚があるから余計な物も管理する羽目になると床置する人が現実に居るのと同じ

197:デフォルトの名無しさん
20/06/26 08:53:43.63 crXMwmqp.net
まああまりに糞な抽象化だともう全部publicでレコードとして扱えやとは思うな。
抽象化を万能なものと思い込みすぎな馬鹿が多すぎるからオブジェクト指向に対する誤解が生まれる。

198:デフォルトの名無しさん
20/06/26 09:44:19.22 8zz5Zpvs.net
っていうか抽象化ってどんな仕様のどの部分を一括に扱ってるのか？
ドキュメントがないと最悪
ここの仕様は特殊だからこれとは別にしないとなって話ができない
ドキュメント書かないなら抽象化するな
害悪でしかない

199:デフォルトの名無しさん
20/06/26 09:50:43.03 Op8/e6Io.net
>>190
直置きはダメだが
ほとんどの場合「棚をしまう為の棚」
「それをしまう為の棚、それをしまうための棚…」
ってなってる
で、「ハサミ使いたいんだけどどこにあったっけ？」
って探すのに非常に苦労する。
見つけやすくするための棚だったはずなのに。
それどころか
棚「ハサミは内部で使うから自分で使わなくていいです。
『切る』という目的だけに集中して、そう命令してください」
と、棚に言われる。
しかし切られた結果を見ると自分が欲しかった結果と微妙に
違うことがよくある。
だから「もう俺が直接切るから、いいからハサミをよこせ」
っていう話になる。

あと抽象化については
「これは抽象的な棚なので中には何も入っていません。
私を参考にした具体的な棚が何処かにあると思うのでそれを
探してください。」となる。
じゃあ「具体的な棚って一体どれだ？なんか長い名前の棚が
やたら沢山あるけどどの棚から探せばいいんだ？？」
となる

200:デフォルトの名無しさん
20/06/26 09:55:00.00 50iMo9Ym.net
>>193
たとえ話はややこしいだけで何の意味もないから
具体的な事例で言えよ

201:デフォルトの名無しさん
20/06/26 09:55:48.09 50iMo9Ym.net
具体的に何のことを言ってるのか
考えなきゃならんようなたとえ話に価値はねーからな
説明が下手すぎる

202:デフォルトの名無しさん
20/06/26 10:13:27.50 wYfFflLL.net
>>193
整理が下手なやつの例をあげて、だから整理はすべきでないと言ったって意味がないだろう。

203:デフォルトの名無しさん
20/06/26 10:36:41.37 klgKDCEw.net
このスレにstaticおじさん、絶対沸いてるだろ。

204:デフォルトの名無しさん
20/06/26 10:41:42.69 s43csjES.net
>>193
だから具体的な問題 >>162に答えてくれよ。
複数のプロセス・スレッドが勝手気ままにデータを処理しても問題ない、というならおめでたいわ。

205:デフォルトの名無しさん
20/06/26 10:42:57.59 8zz5Zpvs.net
>>198
そんときだけ使えばいいじゃん
それ以外じゃ使うなよ

206:デフォルトの名無しさん
20/06/26 10:54:38 crXMwmqp.net
>>198
アルゴリズムレイヤーでアクセスを無駄に禁止するようなクラスは有害でしかない。
適切なpublic具合というものがある。
例えばc++のstd::vectorなんかはかなりオープンアクセスなクラスだがあれが適切なんだよ。
でもって馬鹿に適切なアクセス制御なんて無理ってこと。
変に細かくするな。
馬鹿はクラスレベルで制御なんかしないでいいからモジュールレベルでアクセスするapiだけ公開してろってこった。

207:デフォルトの名無しさん
20/06/26 10:58:13.55 uqHA56uo.net
適切なpublic具合

208:デフォルトの名無しさん
20/06/26 11:23:09 TcIyIoqu.net
トレードオフを理解できてないうちはどっちもどっち
物事の一面しか見れてない

>>190や>>193の比喩は理解の程度が知れるという意味ではすごく有意義

209:デフォルトの名無しさん
20/06/26 11:38:31.41 TyDtokvS.net
適切なpublic具合＝ジャイアンルール

210:デフォルトの名無しさん
20/06/26 11:48:31.80 klgKDCEw.net
>>200
たぶん、162はクラスユーザーが呼び出した処理を実行している最中に内部処理を呼び出したら破綻するけど、いいのか？って言いたいのだと思う。
適切なアクセス修飾子をつけろは同意だが、彼に言うことではないと思う。

211:デフォルトの名無しさん
20/06/26 11:51:10.08 klgKDCEw.net
まぁ、スレッドがどうこうは...private関係あるのかな？って感じですが。

212:デフォルトの名無しさん
20/06/26 12:36:59.06 s43csjES.net
>>199
好き勝手にデータに読み書きできるのに、どうやって「その時だけ」を保証するんだよ。
結局カプセル化必須じゃねぇか。
何のアイディアも無しか。アホらしい。

213:デフォルトの名無しさん
20/06/26 13:04:36 8zz5Zpvs.net
>>206
そういう場所だけそうすればいいじゃん
全部そうなら無能過ぎてプログラム組む前にもっとやることあるんじゃないかなぁ

214:デフォルトの名無しさん
20/06/26 13:19:36.46 SlEx0yXd.net
大昔、Javaやりだしてイキりだしたやつらが、オブジェクト指向もできない
老害とか騒いでいた歴史がある。そんな老害から見ると、gcに難しい事をまかせて、
馬鹿を吊り上げる仕組みなんだよなあ～と皆言っていたのを思い出した。
今はPythonね。もっさ～として、ダサすぎ。でも「俺AIの最前線だぜ」とか勘違い。
歴史は繰り返すのだ。

215:デフォルトの名無しさん
20/06/26 13:22:51.90 TcIyIoqu.net
atomicityを保証するのを
呼び出し側の責任とするのか呼び出された側の責任とするのかは
pros/cons考えて使い分ければいい話でカプセル化必須とかにはならないよ
使う前にopenして終わったらcloseしてください的なAPIと
open/close含めて全部やってくれるAPIの違いと同じこと

216:デフォルトの名無しさん
20/06/26 14:22:11.40 d6LVEoDZ.net
>>208
> イキりだしたやつらが、
> 馬鹿を吊り上げる
> ダサすぎ。
うわぁ。典型的老害だな。

217:デフォルトの名無しさん
20/06/26 14:30:22.45 uqHA56uo.net
すげえ、スレタイも日本語になってなくて、さらにまともな議論にすらなってないのに盛り上がってるw
オブジェクト指向じゃないやつのオブジェクト指向型言語のコード見れると思ってきたが、カオスだなw

218:デフォルトの名無しさん
20/06/26 17:24:31.99 MKv++1da.net
staticおじさんの詭弁ばかり�

219:ﾅ議論にすらならないから、もう、staticおじさん隔離スレ作った方がいいかもね。【隔離】オブジェクト指向アンチスレみたいな感じで。

220:デフォルトの名無しさん
20/06/26 17:45:37.11 pGd8NqU0.net
>>212
もういっそのこと、こんなんでどうだろうか？
【老害】staticおじさんと戯れるファンの集い【詭弁】

221:デフォルトの名無しさん
20/06/26 18:11:48 QQ2hFNnS.net
カプセル化はオブジェクト指向に限らずあるんだが
privateにして外からアクセス不能にすることをカプセル化だと思ってる奴は完全に勉強不足

222:デフォルトの名無しさん
20/06/26 18:24:19.05 xc/k+9g/.net
privateとprotectedの使い分けってみんなどうしてる？
俺は昔はpublic以外はよほど理由がない限り全てprivateにしてたんだけど、最近はよほど理由がない限り全てprotectedにするようになったわ。

223:デフォルトの名無しさん
20/06/26 18:33:11.88 50iMo9Ym.net
protectedはよくわからんので基本private
必要になったらprotected
必要ないならprivateでいい
変更してはいけないというルールはないんだから

224:デフォルトの名無しさん
20/06/26 18:33:48.93 eLfJJdHb.net
オブジェクト指向は素晴らしいだろ
金正恩という概念から好きなだけ金正恩を生み出せるんだぞ
staticじゃ1匹しか生み出せない
その1匹が糖尿で死んだら北朝鮮は成り立たない

225:デフォルトの名無しさん
20/06/26 18:36:58.13 eLfJJdHb.net
金与生は金正恩を継承したクラス
もしくは金日成の多態

226:デフォルトの名無しさん
20/06/26 18:37:59.75 eLfJJdHb.net
将軍様クラスのプロパティに性別があったとは思わなかったけど

227:デフォルトの名無しさん
20/06/26 18:38:24.42 50iMo9Ym.net
つまらんよ

228:デフォルトの名無しさん
20/06/26 18:39:33 eLfJJdHb.net
北朝鮮人ならえげつない死刑

229:デフォルトの名無しさん
20/06/26 18:42:48 QQ2hFNnS.net
金正恩というデータから好きなだけ金正恩産み出すのはオブジェクト思考に限らずできるんだが
オブジェクト指向と全く関係ない
勉強不足

230:デフォルトの名無しさん
20/06/26 18:59:47 MKv++1da.net
>>214
> privateにして外からアクセス不能にすることをカプセル化だと思ってる奴は完全に勉強不足

それな。
カプセル化はクラス使用者にとって必要な機能やデータを公開し、その他内部実装を秘匿することで標準ライブラリの如く使いやすいクラスを作りましょうという実にシンプルなものなのにね。

>>215
基本的にはprivate。自分が定義したメンバ変数やメソッドを継承先がどのように使うのか想像ができないのなら、privateにした方がいいと思っている。
継承先で意図しないメソッドの呼び出しや、変数の使い方をされたら困るからね。
当然、継承先での用途を考えた上でprotectedを使う場合もあるけどね。

231:デフォルトの名無しさん
20/06/26 19:08:51 QQ2hFNnS.net
いやもうお前らprivateとかprotectedとかいう言葉を使ってカプセル化を語るのやめたほうがいいよ
privateという機能がなくてもカプセル化は実現できるから
百歩譲ってデータ隠蔽だけをカプセル化と呼ぶにしても、privateのように外からのアクセスを不能にする機能がなくてもカプセル化は実現できるし

232:デフォルトの名無しさん
20/06/26 19:12:26 fnCF+h71.net
>>224
そんな方法あるんだ、どうやってやるの？

233:デフォルトの名無しさん
20/06/26 19:34:06.00 eLfJJdHb.net
>>222
オブジェクト指向でしか出来ないことがあるとでもw

234:デフォルトの名無しさん
20/06/26 19:47:03.28 crXMwmqp.net
pimpleパターンくらいは知っとけよ。。
てかカプセル化について馬鹿みたいにこだわる奴でまともなインターフェイス設計できる奴見たことねーわ。
リファクタリングもしないで一発で正解にたどり着けるとでも考えてるんだろうな。

235:デフォルトの名無しさん
20/06/26 19:48:24.03 SG/+b/+N.net
pimple 覚えた pimple ニキビ覚えたpimple pimple

236:デフォルトの名無しさん
20/06/26 20:33:23.82 QQ2hFNnS.net
オブジェクト思考言語アレルギーの老害は論外として
特定のオブジェクト指向言語を習得している人は無数にいても、
オブジェクト指向そのものを理解してる人は殆どいなそう

237:デフォルトの名無しさん
20/06/26 20:37:52.02 Op8/e6Io.net
>>229
それってオブジェクト指向という概念そのもの
がおかしいものだからですよね？
っていう議論をずっとしてるんですが
誰にでも理解出来て納得出来ることが正しい
ことだと思うんですが

238:デフォルトの名無しさん
20/06/26 20:43:25.43 ODDHilOW.net
> オブジェクト指向そのものを理解
どういうこと？
アランケイがどう考えたとか
OOPがどういう成り立ちだとか

239:そういういこと？

240:デフォルトの名無しさん
20/06/26 20:54:59.05 0CWC8I0Q.net
アランケイが考えたオブジェクト指向は洗練され完成されたオブジェクト指向なのです。
初号機が最強であるのはどこの世界でも同じことです。
初期版が完成です。改良などありえません。

241:デフォルトの名無しさん
20/06/26 21:47:56.68 ks+n8Bmz.net
第一、privateサポートしてない言語なんて普通にあるしな。Javascriptなんてそうだし。

242:223
20/06/26 21:51:49.87 ks+n8Bmz.net
あ、ID変わっちゃった。223です。

243:デフォルトの名無しさん
20/06/26 22:03:26.05 TcIyIoqu.net
>>223
>カプセル化はクラス使用者にとって必要な機能やデータを公開し、その他内部実装を秘匿することで標準ライブラリの如く使いやすいクラスを作りましょうという実にシンプルなものなのにね。
カプセル化といった時に一般的な定義は2種類あってそれはそのうちの1つで情報隠蔽(Infomation Hiding)とほぼ同じ意味
もう一つはデータとそれを操作する関数/メソッドを一つの単位に束ねることを言う(隠蔽されてるかどうかは気にしない)
人によっては2つを合成した定義でカプセル化という言葉と使ってるので
まともな議論をしたければどういう定義でカプセル化と言ってるのか確認する必要がある

244:223
20/06/26 22:20:46 ks+n8Bmz.net
自分が議論したいというよりは...
このスレ主と>>138みたいな謎方向の議論をする人の思うカプセル化について、そりゃ違うだろって言いたいだけ。

215への回答は聞かれたから答えただけで深い意味はない。

245:デフォルトの名無しさん
20/06/26 22:21:20 0CWC8I0Q.net
>>235
違う違う。情報隠蔽のことをカプセル化と間違っていってる人がいるだけ

カプセル化の定義は必要なものだけをインターフェースとして提供する
必要ないものは隠蔽するってことなんだが

全部必要だから公開しているのに、カプセル化されてない！って言うやつがいるだけ

246:デフォルトの名無しさん
20/06/26 22:33:13 Pmgb6tek.net
>>237
それが正しいという一次ソースあるん？

247:デフォルトの名無しさん
20/06/26 22:33:39 Pmgb6tek.net
ないんだったらそれあなたの感想ですよね

248:デフォルトの名無しさん
20/06/26 22:34:17 TcIyIoqu.net
>>237
>カプセル化の定義は必要なものだけをインターフェースとして提供する
>必要ないものは隠蔽するってことなんだが

情報隠蔽と何が違うの？

249:デフォルトの名無しさん
20/06/26 22:35:17 0CWC8I0Q.net
>>240
情報隠蔽は、情報隠蔽しなければカプセル化じゃないって騒ぐが
必要なものだけを公開するなら、情報隠蔽しなくてもカプセル化

250:223
20/06/26 22:40:01 ks+n8Bmz.net
俺は...カプセル化の本質さえ抑えておけば、言葉としての違いは気にしないけどな。

privateにすること=カプセル化だと勘違いしていても、そいつがカプセル化の有り難みを理解できているのなら、深入りしないだけだよ。

言葉の定義にどこまで拘るかは議論の相手次第。

だが、staticおじさん、貴方は駄目だ。
俺のような細かいことを気にしないレベルの人間ですら駄目だわ。
昔からオブジェクト指向を批判し続けて初心者に誤解を与える老害だから見つけ次第、徹底的に叩く。

次ページ