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おじさん、貴方は駄目だ。
俺のような細かいことを気にしないレベルの人間ですら駄目だわ。
昔からオブジェクト指向を批判し続けて初心者に誤解を与える老害だから見つけ次第、徹底的に叩く。
251:デフォルトの名無しさん
20/06/26 22:42:23.17 Pmgb6tek.net
オブジェクト指向を勉強してる意識高い系のアホが
引数も戻り値も使わず、全部インスタンス変数使ってる例を見て
僕はstaticおじさんになっちゃいそう
252:デフォルトの名無しさん
20/06/26 22:49:00.20 TcIyIoqu.net
>>241
必要なものだけを公開するってことは
必要じゃないものは公開しない、つまり隠蔽しているんだから同じじゃない？
“隠蔽”の捉え方が違うのかな
253:デフォルトの名無しさん
20/06/26 22:50:30.87 Pmgb6tek.net
構造化プログラミングをできるようになって
データと関数をオブジェクトとしてまとめるともっと良いかもと
オブジェクト指向を身につけるならいんだけど
オブジェクト指向では名詞を抜き出すんだ
そうやってオブジェクトを分ければ良いプログラムができあがるんだと
オブジェクト指向に幻想抱いてるアホが作ったプログラムは手に負えん
254:デフォルトの名無しさん
20/06/26 22:50:54 0CWC8I0Q.net
>>244
隠蔽を必須としてる、隠蔽のことだけをカプセル化と言ってるやつがいる
それが間違いということ
255:デフォルトの名無しさん
20/06/26 22:51:29 0CWC8I0Q.net
>>245
オブジェクト指向に幻想抱いてる天才が作ったプログラムなら手に負えるだろ？
256:デフォルトの名無しさん
20/06/26 22:52:06 Pmgb6tek.net
>>247
天才は幻想を抱かない
257:デフォルトの名無しさん
20/06/26 22:52:57 Pmgb6tek.net
僕は天才だからわかる
僕のどこが天才なのかは説明できないけどわかって
258:デフォルトの名無しさん
20/06/26 22:53:19.24 0CWC8I0Q.net
>>248
どうでもいいよｗ
プログラムが手に負えるかどうかは、アホかどうかが焦点だろって話
お前が長々と書いてることに意味がない
259:デフォルトの名無しさん
20/06/26 22:54:34.05 Pmgb6tek.net
>>250
焦点はそこじゃない、どこみてんのよ！
構造化プログラミングの実装技術の先にオブジェクト指向があることを
理解してない人間をアホと言ってるんだよ、焦点はそっち
260:デフォルトの名無しさん
20/06/26 23:08:18.29 0CWC8I0Q.net
>>251
だからオブジェクト指向自体には問題がないって言ってるんでしょ？
261:デフォルトの名無しさん
20/06/26 23:08:49.57 0CWC8I0Q.net
人の話と技術の話の区別ぐらいつけよう。
人をいくらアホだ馬鹿だと叩いても
技術を否定したことにはならない
262:デフォルトの名無しさん
20/06/26 23:09:53.77 Pmgb6tek.net
ListやStack、HTTP Clientといったものはオブジェクト指向と見事に調和するんだけど
それは変えられることがないから、これはこういう機能のものだってのが決まっていて
システムの仕様が変わっても変更されることがない
いっぽうでビジネスドメインにオブジェクト指向を適用しようとすると
仕様がころころ変わるから最初の設計ではうまくいかなくなることが多い
仕様が変わったらオブジェクトの設計もやり直せるならいんだけど
一度システムが動き出したら数万～数億の人が影響受けるから
なかなか変えられないのが実際のところ
カプセル化されると困るというのはそういう状況の話じゃないかと僕は思いました
ドメインの安定性によってオブジェクト指向の適否は左右されると天才の僕は提言します
263:デフォルトの名無しさん
20/06/26 23:12:02.84 Pmgb6tek.net
>>252
オブジェクト指向に幻想を抱くアホを作り出すオブジェクト指向の功罪は大きい
実装と離れて語られるオブジェクト指向は宗教と言っても良い
264:デフォルトの名無しさん
20/06/26 23:18:57.04 0CWC8I0Q.net
>>255
お前がそうであってほしいと願ってるのはなぜ？ｗ
265:デフォルトの名無しさん
20/06/26 23:20:58.30 Pmgb6tek.net
>>256
何いってんだお前
266:デフォルトの名無しさん
20/06/26 23:21:20.47 Pmgb6tek.net
僕が願ってるのは世界平和だけ
267:デフォルトの名無しさん
20/06/26 23:35:54.37 n1YsnRgt.net
カプセル化するなら
一切ソースコードレビューしなくていいんだな
変数やメソッドの命名もインデントも全部
適当にやるからな
文句つけるならテストの結果だけで文句を言って
くれよ、ソースコードには文句言うなよな。
例外をキャッチする必要もないな。
俺が利用するクラスで発生した問題はそのクラス内部の
責任だ。内部事情は意識しなくてもいいんだからな。
おっとロギングも内部事情だからやる必要ないな。
そんな事情は利用側は知りたくもないし結果だけが
欲しいんだもんな。
逆にこれらを押し付けるなら全部publicで問題ないよな。
クラスの内部を知りたいってことだからな。
「↑こいつはカプセル化が何なのかを理解してない。」
カプセル化おじさんがどうせこう言うだろうから先に
言っておいたわ。
268:デフォルトの名無しさん
20/06/26 23:45:57 0CWC8I0Q.net
>>259
「↑こいつはカプセル化が何なのかを理解してない。」
いや、先に言っておくと言っても、俺も同じこと言うんだが、
それで言われることを予測していたんだろ？
反論までは用意してないの？
269:デフォルトの名無しさん
20/06/26 23:50:21 ks+n8Bmz.net
珍しくこの手のスレでは比較的、リアルな批判がでたかも。
汎用性の無いビジネスドメインをオブジェクト指向を意識しながらクラス化したところで、メリット薄いよね？って話はまぁ、理解できる。
でも、ビジネスドメインを構成するクラスを汎用性の高いクラスだけで構成させることができれば、大分スッキリする。
いや、ほんと、そこがオブジェクト指向信者の腕の見せ所なんだがな。
たぶん、ビジネスドメインの責務分割の仕方を誤って神クラスを作ってしまうパターンにはまってるのかも。
270:デフォルトの名無しさん
20/06/26 23:56:26.67 ks+n8Bmz.net
でも、まぁ...開発者の立場次第にもよるのかも。
俺みたいに自社開発しているエンジニアだったら、利益を上げるレベルの品質を根拠にいくらでも納期を伸ばしてもらえるので、ド丁寧なオブジェクト指向プログラムを書く余裕があるけど、受託開発になると納期がギリギリに設定されがちだし(偏見？)、そんな最中、丁寧なコードなんて記述できるかって言われると...まぁ、どうなんだろうね。
271:デフォルトの名無しさん
20/06/26 23:58:23 34AfLaws.net
「状態によって挙動が変わる」ものが何十個も何百個も集まったら凡人には把握しきれない。
ましてや内部の状態が読み取りすらできないとなれば絶望的なことになるのバカでもわかる。
ウェブシステムや業務システムみたいにデータベースという巨大グローバル変数群を構造体にコピーしては書き戻すというのを繰り返すだけだと深い階層化が発生しないから問題は起きないんだろうね。
272:デフォルトの名無しさん
20/06/26 23:59:12 5Zl1C0wL.net
>>260
お前が俺の書いたことに反論してみろ
お前が言う真のカプセル化とやらを説明しろ。
273:デフォルトの名無しさん
20/06/26 23:59:54 TcIyIoqu.net
>>259
前半はコードの品質をどういう観点から担保するかという話
例外やロギングはどういう責務/役割をどこに持たせるかという話
どちらもオブジェクト指向特有のものではない
274:デフォルトの名無しさん
20/06/27 00:00:02 ihk0yOtr.net
問題が起きやすいのはハードウェアに近い低層と、ライブラリ層と、ビジネスロジック層なんかに分業している分野だろうね。
275:デフォルトの名無しさん
20/06/27 00:05:48.57 n2G2JMaM.net
>>261
お前の主張の最大のメリットであるスッキリがお前の主観でしかない
そもそも設計書とソースの構造を一致させるための設計技術ではないのかな？
276:デフォルトの名無しさん
20/06/27 00:09:26.27 ihk0yOtr.net
データベースを使っているようなシステムはまず深い階層化は起きない。
RDBと階層化は相性が悪いからね。
それなのに深い階層化を使っている気分になっている人が多い。
ハードウェア制御絡みの本当に深い階層化を経験している人とは住んでいる世界が違う。
だから話が噛み合わない。
277:デフォルトの名無しさん
20/06/27 00:31:59 npRplKHX.net
みんな難しく考えすぎｗ
オブジェクト指向はインテリセンスが効くんで便利
それで納得しろよ これがないとダルいだろ
278:デフォルトの名無しさん
20/06/27 00:33:18 0UrSdNRf.net
>>267
> お前の主張の最大のメリットであるスッキリがお前の主観でしかない
事実を主観でしかないと批判されましても困るね。
実際、汎用性の高いクラス...それこそ、listやstack、http cliant並みに汎用性の高いクラスだけでプログラムが書かれてたらスッキリするだろ。
代替案があるなら、どうぞ。
> そもそも設計書とソースの構造を一致させるための設計技術ではないのかな？
何の話？
279:デフォルトの名無しさん
20/06/27 00:47:38 eG65KKvD.net
スッキリって何？コードが短くなるの？
頭悪いから50行以上は読めないんだけど
280:デフォルトの名無しさん
20/06/27 00:51:39 n2G2JMaM.net
>>270
いや、スッキリの定義は？
俺が見たらねっとりしてることない？
281:デフォルトの名無しさん
20/06/27 00:53:32.69 kHv6hhb8.net
>>263
その深い階層を扱うのはC言語でしょう？
C言語はオブジェクト指向です！
282:デフォルトの名無しさん
20/06/27 01:
283:02:58.36 ID:kHv6hhb8.net
284:デフォルトの名無しさん
20/06/27 01:03:48.38 0UrSdNRf.net
いや、普通にOOPのコードだけど...。
逆に、list,stack並みに...で、なぜ伝わらない。
当たり前すぎて伝わらなかったのか、初めて聞いた単語だから伝わらなかったのか。
このスレの連中だと高低差激しすぎてコミュニケーションが難しいな。
285:デフォルトの名無しさん
20/06/27 01:04:44.30 0UrSdNRf.net
>>274
あっ、はい。そうです。
286:デフォルトの名無しさん
20/06/27 01:08:16.33 0UrSdNRf.net
>>274
強いて言うのなら、ドメインが安定しているところに見える範囲がオブジェクト指向信者とオブジェクト指向使いとstaticおじさんで、どれくらい違うのかな
287:って感じですが。
288:デフォルトの名無しさん
20/06/27 01:11:06.46 kHv6hhb8.net
こうなるんだったらもっとこういうオブジェクトにすれば
良かったと思うことがザラにある
今最高にきれいでも未来の仕様変更でど汚くなることもある
いま汚くても未来の仕様変更がきれいにできることもある
その見極め方が僕には未だにわからない
289:デフォルトの名無しさん
20/06/27 01:11:51.83 F7GoDPAy.net
>>269
いや動的になる分、効きづらくなるだろばか。
それでもモジュール切り離しの視点で良いこともあるってのがオブジェクト指向の旨みなわけだが。
依存逆転のモジュール構造が作りやすいってだけの話なのにバカが変な哲学持ち出すから
カスみたいな輩がお前はわかってない、俺が真の意味を理解してるとか言い出すわけだよ。
290:デフォルトの名無しさん
20/06/27 01:20:22.14 kHv6hhb8.net
依存性を逆転させて良いことがあるっていうんですか！？
291:デフォルトの名無しさん
20/06/27 01:27:34.87 BNc+T5Ob.net
１万行超えてもスクロールして作業するのか？
292:デフォルトの名無しさん
20/06/27 01:28:03.05 kHv6hhb8.net
業務で扱うようなある程度複雑な仕様をどう設計して実装するか
みんなでプログラミングして比較してみたいねー
293:デフォルトの名無しさん
20/06/27 01:31:55.47 kHv6hhb8.net
>>281
内容によるんじゃないかな
みっちりコントロールフローが1万行あったら嫌だけど
御経がほとんどを占めてたらわかるだろうし徳が高まりそう
294:デフォルトの名無しさん
20/06/27 02:14:37 n/FbqQvh.net
>>282
業務というのはIBM（International Business Machines ）より
パンチングカードの集計から始まっているので
主にアンケート調査結果や在庫管理プログラム
の設計ということになるだろう
295:デフォルトの名無しさん
20/06/27 06:21:43.43 pgI/H4Wp.net
>>282
業務に限らず、OOPに限らず
そもそもはそれが問題なんよ
複雑さそのものが
ある程度以上複雑なモンは人類にはムリなんよ
それが人類とプログラミングの関係なんよ
サンプルプログラムや学校の課題書いたり
趣味で小さいの書いてる連中と
ある程度以上複雑なモンを書いてる連中とはまずそこからして
想定してるもんが違いすぎる
296:デフォルトの名無しさん
20/06/27 07:01:10 U90iCGW6.net
>>285
きっと>>282は
小さな趣味プログラムでも大きな業務プログラムでも
ほらね、カプセル化したコーディングだとあーだこーだ
だからいったじゃん
「カプセル化は絶対にやめろ！」
という結論にもっていきたいだけだお
297:デフォルトの名無しさん
20/06/27 07:42:28.66 e0+LQFD/.net
「オブジェクト指向は高度で複雑な事をやる技術者
だけが恩恵を受けられるもので簡単なシステム
書いてるような凡人プログラマは恩恵を
感じにくい。」
だったら入門書でそんなもの教えるな
初心者プログラマにソケット通信や
システムコールやカーネルみたいな話を
いきなり教えるんか？
298:デフォルトの名無しさん
20/06/27 07:44:28.06 e0+LQFD/.net
凡人にとってオブジェクト指向は
邪魔でしかないんだよ。
高度な技術者の勝手な利便性を
凡人に押し付けるな。
凡人の方が大多数なんだよ。
299:デフォルトの名無しさん
20/06/27 07:54:23.66 BNc+T5Ob.net
何でプログラムやってるんだ？
もっと簡単なことがあるだろ
300:デフォルトの名無しさん
20/06/27 08:29:03.79 0UrSdNRf.net
>>286
どうだろ。
staticおじさん(「オブジェクト指向ってしっくりこないんです」の記事を書いて炎上、詭弁を重ねて意固地にstaticを薦めた有名な老害)じゃないのなら、まだ、大丈夫なんじゃね？
301:デフォルトの名無しさん
20/06/27 08:38:52.96 0UrSdNRf.net
それ以前に、カプセル化は絶対駄目の結論に持っていこうとしているのか？
日が変わるとID変わるから、誰が誰だかよくわからなくなってきた...。
302:デフォルトの名無しさん
20/06/27 09:43:50.27 8YCrt6Qf.net
何事も程度次第
ただ丁度良い程度を知るのは少数の天性のセンス持ちだけで
凡人には理解できなかったり極端に走ったりする
俺は凡人とセンス持ちの間、というか凡人の域を超えられないのかなあ
プログラム書くたびにどの程度で済ませるか、いつも迷ってる
303:デフォルトの名無しさん
20/06/27 10:00:13.69 pgI/H4Wp.net
OOP批判の大半はクラス設計の難しさによる
OOPによってもたらされたクラスライブラリが
十分に使いやすいのに対して
自分でクラスやインタフェースを作ろうとしたとき
納得の行かない結果になる
問題の切り分けが出来ず
再利用性のある単位ぴったりにフォーカスできず
一緒にあるべきものを別にしたり
別にあるべきものを一緒にしたり
縦に割る物を横に割ろうとしたり
いろんな判断をあやまった結果
最後に、クラス設計が悪いのではなくてOOPそのものが悪いと断ずる
304:デフォルトの名無しさん
20/06/27 10:09:46.57 twDHZDh4.net
>>287
別に初心者だってオブジェクト指向の恩恵は受けられるだろう。良くあるコンテナや文字列とかの基本的なものだってオブジェクト指向的なものだし。
それに初心者の内からオブジェクト指向について知っておく、慣れておくことは重要だろう。
世の中の便利なライブラリやフレームワーク等の多くはオブジェクト指向で作られているからそれを使えるようになるために必要。
自分で設計するのも初めは難しいが、理屈や理論を学びながら実例に触れ、試行錯誤しながら徐々に慣れていく。
何より、初心者だからとオブジェクト指向をまったく触れずに手続き型のみで経験を積んで、ある程度自分なりのノウハウや経験論を身に付けてから別のパラダイムを取り入れようとすると、中にはアレルギー反応を起こして適応できなくなってしまう人もごく稀にいるから。
305:デフォルトの名無しさん
20/06/27 10:47:57.21 n2G2JMaM.net
長い上に全く中身がないな
スッキリ以上のオブジェクト指向のメリットは出てないからね
これで技術者やってるつもりなんだから早く死ねよ
306:デフォルトの名無しさん
20/06/27 11:57:57.12 0UrSdNRf.net
>>295
お前の無駄口程、無駄な発言は無いけどな。
307:デフォルトの名無しさん
20/06/27 12:40:58.84 ut+wnsgT.net
カプセル化って別に外部からのアクセスを不能にすることじゃないよ
外部から『直接的』にアクセスさせることを避けて、そのかわり外部向けにわかりやすい何かを提供すること
現実のカプセルのように、扱いにくいものを隠して扱いやすく提供すること
別にカプセル化してもリフレクションやその他諸々で遠回りなアクセスが可能なこともある
カプセル化ってのはかなり意味の広い言葉で、「臭いものに蓋」みたいなこと全般をカプセル化と呼ぶ
極端な例だと、関数にわかりやすい名前をつけることで関数内部を見なくて済むようにすることもカプセル化と呼ぶ
308:デフォルトの名無しさん
20/06/27 12:43:14.13 npRplKHX.net
>>288
いやいや兵隊がよくわからないのに使えるするのが
オブジェクト指向の利点の一つだろ つかそれができないなら
オブジェクト指向にする意義がない まあ兵隊がよくわからないのに
使えるぐらいのオブジェクト指向ができるなら、設計した本人たちは
そもそもオブジェクト指向にしなくても出来ちゃうって逆説はあるわな
309:デフォルトの名無しさん
20/06/27 13:14:49.52 e0+LQFD/.net
>>293
その通りだと思う
オブジェクト指向で作られたOSSの、ライブラリは
とても便利だし、役に立つと思う。
なら初心者や凡人へはクラスをインポートして使い方
のみを教えるべきで、クラスの作り方なんて
教えない方が親切だと思う
正直、自分でクラスなんて作りたくないし
組織内のメンバーが作成したローカル内の
クラスなんて利用や継承したくないし
自分が作ったクラスを誰かに利用して
欲しくない、使い捨てで十分。
再利用性は以前自分が書いたコードを複製
して微修正すればいいよ、
自分が書いたコードだから修正箇所は
把握して
310:る。 JavaScriptやpyみたいな言語はオブジェクト指向 導入してるけどクラスの作成は必須じゃない だけどJavaみたいな静的言語はクラスの作成が 必須になってる。ここがおかしいと思う。 クラス作ること強制してる言語仕様やフレームワークは おかしいと思う。
311:デフォルトの名無しさん
20/06/27 13:26:54.01 eG65KKvD.net
再利用しない前提ならそりゃ無用の長物だわな
312:デフォルトの名無しさん
20/06/27 13:45:44.90 ssxfEnBq.net
そして再利用しようとすると微妙に仕様が変わって結局中身を改造しないといけなくなる罠。
汎用的なパーツ以外はクラス化すると余計手間かかるな。
313:デフォルトの名無しさん
20/06/27 13:51:13.06 eG65KKvD.net
なんというかprivate云々とかそういう次元の話じゃないよねこれ
なんか脱力した
314:デフォルトの名無しさん
20/06/27 13:56:46.31 kHv6hhb8.net
再利用しなくてもテストしやすくなったりするからオブジェクトは素敵な概念だと思うよ
315:デフォルトの名無しさん
20/06/27 13:58:08.98 kHv6hhb8.net
修正が必要になったとき、それを使う側に影響を与えないっていう性質があっていっぱいちゅき
316:デフォルトの名無しさん
20/06/27 13:58:50.41 kHv6hhb8.net
まあ修正の程度にもよるんですけどね！(げきおこ
317:デフォルトの名無しさん
20/06/27 14:06:34 UiFDXh57.net
JavaをdisるJava全否定のスレッドなのね
318:デフォルトの名無しさん
20/06/27 14:13:22 UrcM2fcl.net
このスレタイの主張、可能なら複数の言語で、
オブジェクト指向で書かれたそれなりの量のコードを、
それより機能的で保守性があって行数も少なくて万人が読みやすいようにリファクタリングするとかして証明して欲しいなあ
それがプログラマの矜持ってもんだと思う
コードで語れってね
319:デフォルトの名無しさん
20/06/27 14:22:56.55 Z/pHF8i9.net
>>273
カプセル化はC言語でもできる。
320:デフォルトの名無しさん
20/06/27 14:23:12.65 1p1mL4Jd.net
バカなやつほど長文で演説した挙げ句オブジェクト指向のメリットをスッキリ以上のモノを挙げられない
レスしにくるなよ惨めだから
321:デフォルトの名無しさん
20/06/27 14:26:38.74 Z/pHF8i9.net
>>282
一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
データベースに出し入れする際の受け皿となる構造体が1層あるくらいだろ。
そもそもRDBは階層構造そのままぶち込めないし。
322:デフォルトの名無しさん
20/06/27 14:34:40.99 Z/pHF8i9.net
>>307
最近流行りのPythonで作られたシステムを見て回れば？
カプセル化は言語仕様で禁止されてるから強制的に>>1の言うとおりに作るしかない。
323:デフォルトの名無しさん
20/06/27 14:37:58 Z/pHF8i9.net
>>307
というか最初の開発で問題になるようなことではないからソースコードでは比較できないでしょ。
機能追加・改修案件で発生する問題の話だし。
324:デフォルトの名無しさん
20/06/27 14:50:29.02 1p1mL4Jd.net
初めに赤字が出たら続きはねーよｗ
325:デフォルトの名無しさん
20/06/27 15:01:24.90 Z/pHF8i9.net
これオブジェクト指向の善し悪しじゃないよね。
改修発生時に雲の上で決まった無茶な追加仕様にどれだけ耐えられる構造にできるかという話だ。
ただオブジェクト指向は昔ながらの教科書どおりにやると耐えられない構造になりがち。
もちろんオブジェクト指向でなくても発生する。
C言語でも発生する。
そうならないようコーディングの約束事を決めよう。
そうなってないかコードレビューはしっかりやろう。
326:デフォルトの名無しさん
20/06/27 15:03:08.36 kHv6hhb8.net
>>311
へーPythonにはアクセス修飾子がないんだ知らなかった
命名規則でこれはprivateなものだよと示すわけね
JavaScriptみたい
327:デフォルトの名無しさん
20/06/27 15:04:29.05 qJyof1ZF.net
>>311
>カプセル化は言語仕様で禁止されてるから
ソースは？
328:デフォルトの名無しさん
20/06/27 15:09:38.92 kHv6hhb8.net
Pythonにアクセス修飾子がないことはググればわかるじゃん
329:デフォルトの名無しさん
20/06/27 15:09:51.10 kHv6hhb8.net
ソースは僕だ！
330:デフォルトの名無しさん
20/06/27 15:10:07.03 Z/pHF8i9.net
>>316
URLﾘﾝｸ(www.python.org)
331:デフォルトの名無しさん
20/06/27 15:10:51.38 kHv6hhb8.net
マヨネーズの君とソースの僕
332:デフォルトの名無しさん
20/06/27 15:12:52.88 qJyof1ZF.net
>>310
構造体が別の構造体を参照してる
333:データ構造は階層構造とは呼ばないということかな？ 階層構造の深さがカプセル化やオブジェクト指向と何の関係があるの？
334:デフォルトの名無しさん
20/06/27 15:13:38.77 kHv6hhb8.net
そう言えば日本の業務形態には貧血ドメインの方がよく適合するなんて話があったなあ
貧血って言うと悪い印象があるからシンドメインとかスリムドメインに言い換えて
スリムドメインの方が優れてるんだって風潮がそろそろ出てきても良いと思う
335:デフォルトの名無しさん
20/06/27 15:14:18.21 qJyof1ZF.net
>>317
“アクセス修飾子がない” == “カプセル化が言語仕様で禁止されてる”
=> False
336:デフォルトの名無しさん
20/06/27 15:15:51.79 Z/pHF8i9.net
>>321
それただのポインタだろ
337:デフォルトの名無しさん
20/06/27 15:18:13.32 e0+LQFD/.net
そもそも、一昔前ならソフトウェアは
製品化して値段を付けて売るって考えがあったから
保守や仕様変更の影響範囲について関心が高かった。
だからオブジェクト指向は必要だったかもしれない
だが現在ではソフトウェアは基本無料が当たり前だし
プロジェクト依頼元の依頼を受けてオーダーメイドで
システムを作るから依頼元だけが金を払ってくれるの
であって
あとはスマホアプリを無料配布して
そのアプリで課金してもらって金を稼ぐみたいな
稼ぎ方だから、ソフトウェア自体に売却する価値はない。
売却する資産価値がないからオブジェクト指向で
保守する価値がない、使い捨てにすればいい。
実際、スマホアプリとかのほとんどが軽微なバグ
とか沢山潜んだままリリースされていて、ずっと
放置されてたりするじゃん。
338:デフォルトの名無しさん
20/06/27 15:19:44.46 Z/pHF8i9.net
>>321
ポインタは横の繋がり
上下関係ではない
深い階層化というのは、雲の上で決まった仕様に底辺開発者は意見できないということ。
深い階層化というのは、底辺開発者が受けてるパワハラなど雲の上は知らないということ。
339:デフォルトの名無しさん
20/06/27 15:20:21.12 kHv6hhb8.net
>>323
では君と僕のカプセル化の定義が異なるだけじゃん
君のカプセル化の定義で僕が言ってることを解釈するからFalseになる
僕が言ってることは僕の定義で解釈したらTrueになる
アクセス修飾子が存在することをカプセル化可能と定義します
よろしくおねがいします
340:デフォルトの名無しさん
20/06/27 15:23:36.87 qJyof1ZF.net
>>327
“カプセル化可能” == “言語仕様でカプセル化を禁止している”
#=> False
341:デフォルトの名無しさん
20/06/27 15:25:23.02 kHv6hhb8.net
>>328
だからさー君のカプセル化の定義を知らないしそれを言ってもらわないことには
真偽値だけ言われても僕どうしたらいいかわからないよーえーん(T_T)
342:デフォルトの名無しさん
20/06/27 15:26:25.05 kHv6hhb8.net
カプセル化とはアクセス修飾子でprivateにできることを言います
343:デフォルトの名無しさん
20/06/27 15:28:46.34 UrcM2fcl.net
本当に？
344:デフォルトの名無しさん
20/06/27 15:31:32.87 qJyof1ZF.net
>>326
>>310
>一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
このレスに書いてる”階層構造”の定義を聞いてるに
全く違う”階層化”の話を出されても困る
特に考えてなかったんなら別にそれで構わない
345:デフォルトの名無しさん
20/06/27 15:32:44.69 qJyof1ZF.net
>>328
バグってた
“カプセル化不可能” == “言語仕様でカプセル化を禁止している”
#=> False
346:デフォルトの名無しさん
20/06/27 15:40:51.44 Z/pHF8i9.net
>>332
データベースで深い階層化が起こるとすれば、
・データベースの出し入れはストアドプロシージャ経由のみ
・誰かが作ったストアドプロシージャを叩くライブラリ
・末端開発者が見えるのはライブラリのみ
という状況
347:デフォルトの名無しさん
20/06/27 15:45:38.60 kHv6hhb8.net
>>331
ホントっす
348:デフォルトの名無しさん
20/06/27 15:46:26.65 ut+wnsgT.net
ちがうよ
349:デフォルトの名無しさん
20/06/27 15:46:32.04 kHv6hhb8.net
>>333
なんでFalseになるか説明できる？
できないんだったら君は間違ってる
350:デフォルトの名無しさん
20/06/27 15:47:10.15 kHv6hhb8.net
>>336
何が違うんですか！？なんでですか？説明してください！
351:デフォルトの名無しさん
20/06/27 15:47:49 UrcM2fcl.net
内包してない？
352:デフォルトの名無しさん
20/06/27 15:48:03 ut+wnsgT.net
>>338
定義が違うから説明しろと言われても困る
353:デフォルトの名無しさん
20/06/27 15:48:32 kHv6hhb8.net
>>340
説明くらいできるだろハゲ、横着すんな
354:デフォルトの名無しさん
20/06/27 15:48:33 PPBVSkWl.net
ぬるぽ
355:デフォルトの名無しさん
20/06/27 15:52:34 ut+wnsgT.net
>>341
>>294
356:デフォルトの名無しさん
20/06/27 15:53:17 ut+wnsgT.net
>>341
安価ミス
>>297
357:デフォルトの名無しさん
20/06/27 15:53:25 kHv6hhb8.net
>>343
なるほどね、アレルギーが、そういうことね
358:デフォルトの名無しさん
20/06/27 15:53:46 kHv6hhb8.net
恥かいた
359:デフォルトの名無しさん
20/06/27 15:54:37 kHv6hhb8.net
安価ミスってんじゃないよ！！
納得した僕が馬鹿みたいでしょうが！！
360:デフォルトの名無しさん
20/06/27 15:55:00 ut+wnsgT.net
馬鹿なんじゃないの？
361:デフォルトの名無しさん
20/06/27 15:56:18 e0+LQFD/.net
ああもうめちゃくちゃだよ！
362:デフォルトの名無しさん
20/06/27 16:01:21 7UzCd1n0.net
何やってんだおめーら。
そのへんでやめとき。
363:デフォルトの名無しさん
20/06/27 16:02:43 kHv6hhb8.net
カプセル化には強度があります。
C言語のヘッダやJavaのprivateといった言語機能として
カプセル化できることを強カプセル化と言います
JavaScriptやPythonのように命名規則によって使用者に
知らせるカプセル化のことを弱カプセル化と言うのです。
>>348 僕のこと見直してくれてもいいです
364:デフォルトの名無しさん
20/06/27 17:08:00.05 WDOSBdwF.net
カプセル化こそ
すでに時代遅れだったんじゃねーの？
365:デフォルトの名無しさん
20/06/27 17:38:28.03 ut+wnsgT.net
>>351
頭悪そう
366:デフォルトの名無しさん
20/06/27 17:59:51.27 kHv6hhb8.net
>>353
嘘つき！
367:デフォルトの名無しさん
20/06/27 18:27:35.27 e0+LQFD/.net
>>351
これまでの話を統合した結論として、
いまはgitなどバージョン管理差分確認ツールや
エディタやIDEの機能が充実してるから
言語機能でカプセル化して
「内部を意識しない」ように隠蔽したり制限するのではなく
開発ツールを駆使して内部を意識はするけど
ソースの仕様変更切り替えに対応しやすくなっている
やり方が主流
開発ツール進化によりカプセル化はその役割を終えた。
継承や抽象クラスやオーバーライドも非推奨
これをやると同じ名前のメソッドが沢山あって
IDEによるプロジェクト内キーワード全文検索を
阻害するから
368:デフォルトの名無しさん
20/06/27 18:38:03.92 kHv6hhb8.net
>>355
カプセル化しなかったら仕様変更がしやすいのか、なるほど
369:デフォルトの名無しさん
20/06/27 18:45:55.84 e0+LQFD/.net
>>356
読解を間違えています
カプセル化をしないことで仕様変更しやすくなるのではなく
カプセル化を「しなくても」代わりに
開発ツールが充実してるから
ブランチ切り替えや差分確認でスマートな
仕様変更と仕様切り替えが可能です。
だからカプセル化はもう不要になりました。
370:デフォルトの名無しさん
20/06/27 18:50:33.85 UrcM2fcl.net
それはカプセル化の使用有無に関係ないのでは
371:デフォルトの名無しさん
20/06/27 18:52:34.90 kHv6hhb8.net
>>357
カプセル化せずに発生するオブジェクトを破壊するような変更を
差分確認で見つけ出せるわけですね、差分確認が重要ですね
372:デフォルトの名無しさん
20/06/27 18:54:31.03 twDHZDh4.net
>>355
×これまでの話を統合した結論として
◯これまでの話はすっ飛ばしてボクの言いたいことだけを言うと
373:デフォルトの名無しさん
20/06/27 19:01:29.07 7UzCd1n0.net
IDEの助けがあるとは言え、grepした時の重複は勘弁して欲しい。
どれやねんっていつも思う。
本当にOOPってメンテしやすいんだろうか？
374:デフォルトの名無しさん
20/06/27 19:03:28.66 kHv6hhb8.net
わかりました、grepを禁止します！
375:デフォルトの名無しさん
20/06/27 19:07:51.73 kHv6hhb8.net
世界的超人気言語はC言語、Java、Pythonと変遷していってるわけだけれども
たしかにカプセル化の機能は時代とともに弱まってるように見える
376:デフォルトの名無しさん
20/06/27 19:10:52.99 e0+LQFD/.net
>>359
そのオブジェクト破壊って一体何を意味してる？
多少オブジェクトが破壊されたところで
アプリは動くし すぐバグになる訳じゃないだろう。
多少経験あるプログラマなら知らないオブジェクトへの
破壊的代入は軽率にはやらないだろうし、
オブジェクトのバックアップ変数作ったり少し考えれば
それくらいやるだろう。
やる時はどうしてもやる時はそうせざるを得ないからやる訳で
破壊するのにもそれなりの理由があるんだよ。
それをprivateとかprotectedするなんて余計なお節介
もいいところ
そして、そういう操作の是非は
gitでコードレビューできるだろ。
377:デフォルトの名無しさん
20/06/27 19:13:53.12 npRplKHX.net
カプセル化って一種の安全装置なわけだし、作業性とはトレードオフに
なるわな どちらかを選択するなら当然安全装置を選択するが
378:デフォルトの名無しさん
20/06/27 19:26:08.84 D2Sdnpa5.net
使い捨てだの再利用しないだの
素晴らしい含蓄をみずほレベルの巨大案件に適用してれば歴史が変わっていたかも知れない
379:デフォルトの名無しさん
20/06/27 19:29:44.84 kHv6hhb8.net
>>364
Javaでいうところのprivateやprotectedの値を書き換えたり参照したりといったことを
オブジェクトの破壊と言ってます
コードレビューできるっていうのはそれをやらないと洗い出せないってことでしょ
カプセル化の機能を使っていれば実装時に気付けることをレビューまで先延ばしにすることによって
得られることがそんなに多いのですかね
380:デフォルトの名無しさん
20/06/27 19:37:50.49 kHv6hhb8.net
たとえばこの先Pythonが、名前が_から始まるメンバに外からアクセスすると
構文エラーになるようになった場合、動作するプログラムにカプセル化を破壊するような
操作がないことは明白になるのでとても便利だと思います
381:デフォルトの名無しさん
20/06/27 19:42:29.28 npRplKHX.net
Pythonぐらいの緩さが一番バランスいい気がする
人気があるのも納得
382:デフォルトの名無しさん
20/06/27 19:44:24.05 7UzCd1n0.net
>>368
dart的な感じ？
383:デフォルトの名無しさん
20/06/27 19:50:55.69 kHv6hhb8.net
>>370
そうです、そのdart的な感じです
dartを使ったことがないので僕は知りませんけど
384:デフォルトの名無しさん
20/06/27 19:53:28.59 kHv6hhb8.net
アクセス修飾子でアクセス制限をかけてしまうと
テストすることさえできなくなります
これがカプセル化の圧倒的な弱点です
385:デフォルトの名無しさん
20/06/27 19:55:33.60 kHv6hhb8.net
privateではありつつもテスト時などにアクセス可能なバックドアが必要で、それが現代のプログラミング言語には欠けていると思います
386:デフォルトの名無しさん
20/06/27 20:15:27.61 7UzCd1n0.net
>>373
そのへんJavaとかリフレクション駆使して回避してるので構造的、致命的な欠点とは言い切れないと思うよ。
リフレクションがバックドアと言われたらそれはその通りなので反論できないけど。
387:デフォルトの名無しさん
20/06/27 20:17:13.10 mehAi5n4.net
グローバル変数使用禁止の
public staticが唯一無二の解決策だというのにわからん奴がいるな
388:デフォルトの名無しさん
20/06/27 20:34:22.57 gS37C1rZ.net
>>373
テストでアクセスするならそれはpublicにすべきもの
言い換えると、テストですらアクセスしないものをprivateにする
389:デフォルトの名無しさん
20/06/27 20:35:14.22 gS37C1rZ.net
>>372
テストするならpublicにすればいいだけ
390:デフォルトの名無しさん
20/06/27 20:39:11.40 e0+LQFD/.net
まず重要な前提として
システムの仕様変更というのは
appのソースコードの変更だけではない。
データベースの変更や接続してる外部サーバや
ストレージに関連する仕様変更とかもある。
そして、カプセル化を初めとするオブジェクト指向の
設計技法はメモリ内の瞬間的なごく狭い範囲の
事しか考えてない。
外部環境の仕様が変わったり、フェイルオーバーなどの
不具合が起きてシステム全体のデバッグしたり
不具合調査するときに、app層がカプセル化されていたり
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
想像に難くないと思う。
仮想化やクラウド化が進んでる最近では
こういう外部環境の隠蔽は逆に困るんだよ。
391:デフォルトの名無しさん
20/06/27 20:46:30.95 npRplKHX.net
>>378
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
逆説的だがこれが利点の一つなんだ 手続き型だと
直したつもりになることが多々あり 新たなバクを生む
時間が多少かかっても形式的に処理するべき
392:デフォルトの名無しさん
20/06/27 20:59:08.97 kHv6hhb8.net
>>376
それはないわー
テストは全メソッドやるでしょ
全部publicにしなければいけないなんて間違ってると思います！
僕はそれ間違ってると思います！
393:デフォルトの名無しさん
20/06/27 21:00:30.56 kHv6hhb8.net
>>377
publicにしたら別のオブジェクトからアクセスされちゃうじゃん
そのメソッドは内部の状態と深い関わりがあって勝手に呼ばれると困っちゃうの
みたいなことあるじゃんテストのときだけpublicにするのはヤリマンだし
394:デフォルトの名無しさん
20/06/27 21:03:21.73 kHv6hhb8.net
テストを別オブジェクトにするのが間違ってるのかもわからんね
データと関数をセットにしたものをオブジェクトと呼ぶように
データと関数とテストをセットにした自己メンテナンス完結型のものをアクターと呼ぶことにしようよ！
395:デフォルトの名無しさん
20/06/27 21:13:44.71 gS37C1rZ.net
>>380
> テストは全メソッドやるでしょ
全メソッドやるかどうかはその人次第
テストするならpublicにする
それだけの話
テストするということは、そのインターフェースは
外部から使用しても良いということを意味する
テストされてるんだから仕様が変わったりしない
396:デフォルトの名無しさん
20/06/27 21:14:19.20 gS37C1rZ.net
>>381
> publicにしたら別のオブジェクトからアクセスされちゃうじゃん
アクセスしても問題ないだろ？
アクセスしても問題ないようにテストしてるんだから
397:デフォルトの名無しさん
20/06/27 21:32:11.55 kHv6hhb8.net
>>384
いやいや、公開する必要のないメソッドを公開する意味がない
呼ばれちゃいけないタイミングはある、テストしてるかどうかとは関係ない
テストしてないコードはバグってるよ
人の問題で片付けてはいけない
398:デフォルトの名無しさん
20/06/27 21:33:25.71 kHv6hhb8.net
テストやるときって前提となる状態を作ってからやるじゃん
公開して自由にアクセスできたら前提が成り立たない状態でアクセスされちゃうじゃん
テストエアプかい？
399:デフォルトの名無しさん
20/06/27 21:34:14.35 kHv6hhb8.net
ちなみにだけど僕は自動化テストは書いたことがない
書いたことないけど僕はテストにすごく詳しいんだ、わからないことがあったら聞いて
400:デフォルトの名無しさん
20/06/27 21:36:38.34 kHv6hhb8.net
privateなメソッドにテストが必要ないと思ってる人がいるのが僕は不思議
むしろprivateなメソッドこそテストするべきでpublicなメソッドはただのインターフェース
401:デフォルトの名無しさん
20/06/27 21:38:48.09 kHv6hhb8.net
privateなメソッドにロジックが書かれていてそのテストを内包してるオブジェクトのことをアクターと呼ぶことにしようか
402:デフォルトの名無しさん
20/06/27 21:45:24.83 OC6QjUii.net
publicにしたからと言って緩和するだけで結局状態の保持をされて意味不明な動作をするところは変わらんで
staticおじさんの言うことを聞きなさい
403:デフォルトの名無しさん
20/06/27 22:12:18.34 gS37C1rZ.net
>>385
> いやいや、公開する必要のないメソッドを公開する意味がない
テストするのだから公開する必要があるだろ
なにいってんだおめぇ
404:デフォルトの名無しさん
20/06/27 22:15:42.36 kHv6hhb8.net
>>391
お前が何いってんだハゲ
privateだとテストできないのが困るのよねえと言ってんだろうが
405:デフォルトの名無しさん
20/06/27 22:16:57.07 kHv6hhb8.net
テストエアプか？
テストのためだけにpublicにするなんてありえない
406:デフォルトの名無しさん
20/06/27 22:18:03.01 pxtmQ7+k.net
>>393
じゃあ、どうすんだよ
って聞いてみたい
407:デフォルトの名無しさん
20/06/27 22:19:08.38 UrcM2fcl.net
外部からアクセスするテストをしなくて済むのがprivateだと思います^^
408:デフォルトの名無しさん
20/06/27 22:19:09.22 kHv6hhb8.net
>>394
同じオブジェクトにテスト書けば良いと僕は思います
データ、メソッド、テストを備えたオブジェクトを特別にアクターと呼ぶことにしましょうという
のが僕の提案です
409:デフォルトの名無しさん
20/06/27 22:20:26.71 gS37C1rZ.net
>>388
テストをするということは、それはインターフェースとして仕様がきっちりしていて
長い期間にわたって変更しない（されにくい）ということなんだよ
インターフェースが適当だったり変わりやすいものは
変わるたびにテストも変えなくてはいけなくなる
つまりテストのメンテナンスのコストが増えてしまう
インターフェースが適当だったり変わりやすいものを作るなという話じゃない
そういうのは作ってもいいがprivateにして、他のpublicメソッドを通して間接的にテストする
privateはテストしなくていいとかテストできないとかじゃなくて
インターフェースが（まだ）明確に決きめずに後回しにできるというメリットが有る
一方テスト可能な段階になったなら、それはインターフェースの仕様が明確に定義されているということ
（明確に定義されてないものをテストなんかできない）
明確に定義されたのならpublicにしていいわけ
410:デフォルトの名無しさん
20/06/27 22:20:30.54 nVWlQ22s.net
ジャップにオブジェクト指向は100年早いみたいだな
脳死で全てにpublic staticって書いとけ
411:デフォルトの名無しさん
20/06/27 22:20:37.43 kHv6hhb8.net
>>395
あら、あーたはprivateなメソッドのテストはなさらないの？
それで平気
412:なの？
413:デフォルトの名無しさん
20/06/27 22:22:06.34 gS37C1rZ.net
>>393
テストというのはオブジェクトを使用するときの例でもあるんだから
テストがやってることは、テスト以外でもやって良いんだよ
テストでしか呼び出してないからって、privateにする必要はない
414:デフォルトの名無しさん
20/06/27 22:22:39.57 kHv6hhb8.net
>>397
そんなの関係なくメソッド書いたらテストもするでしょ
テストされてないコードはすべてバグだよ
public通してテストするのは粒度が大きすぎる
415:デフォルトの名無しさん
20/06/27 22:23:50.09 gS37C1rZ.net
>>401
だからprivateをテストするということは、
そのメソッドは仕様が明確に決まったということなので
publicにしていいんだよ
416:デフォルトの名無しさん
20/06/27 22:23:52.28 gUUFl8tS.net
>>400
じゃあ、全部テストするときは全部publicだね
417:デフォルトの名無しさん
20/06/27 22:24:28.59 kHv6hhb8.net
>>400
テストするときは前提の状態を用意してからやるもので
テストは実装が正しいか確認するためにやる
publicにして他のオブジェクトから自由に呼び出して良いですというものとはわけが違う
テストで呼んだから別のところでも呼んでいんだなんて道理は存在しない
テストエアプか？
418:デフォルトの名無しさん
20/06/27 22:25:10.97 kHv6hhb8.net
>>402
言い訳がない、privateにするのはよそからアクセスさせないため
テストするためにpublicにしていいわけがない、オブジェクト指向エアプか？
419:デフォルトの名無しさん
20/06/27 22:25:22.83 gS37C1rZ.net
>>403
仕様が明確に決まってないようなものは
privateにしてテストをサボることができる
サボると言ってもpublicメソッド経由でテストするわけだが
あくまでメソッド単体でのテストをサボるだけ
420:デフォルトの名無しさん
20/06/27 22:25:38.25 zbAPoACG.net
>>404
だからどうすんだよ
421:デフォルトの名無しさん
20/06/27 22:26:14.09 gS37C1rZ.net
>>405
> privateにするのはよそからアクセスさせないため
テスト（よそ）からアクセスするのでpublicです
422:デフォルトの名無しさん
20/06/27 22:27:02.78 kHv6hhb8.net
>>407
そこで、僕に名案があります
テストを同じオブジェクトの中に用意するんです
そうしてデータ、メソッド、テスト、この3つを備えたオブジェクトをアクターと呼ぶことにしましょう
プログラミングパラダイムはアクターが主流の時代に突入します
423:デフォルトの名無しさん
20/06/27 22:28:17.85 kHv6hhb8.net
>>408
テストのためにpublicにしたらオブジェクトが壊れるため
テストのためにpublicにするのはオブジェクト指向的にありえない
オブジェクト指向エアプか？
424:デフォルトの名無しさん
20/06/27 22:28:55.27 gS37C1rZ.net
>>410
> テストのためにpublicにしたらオブジェクトが壊れるため
壊れないよ。
425:デフォルトの名無しさん
20/06/27 22:30:05.59 kHv6hhb8.net
テストという概念がオブジェクト指向の中にないからこのようなジレンマに陥るのです
そこで、オブジェクトの中にテストを入れてしまおうというのが僕が提唱する新時代の
プログラミングパラダイム、アクター指向です
426:デフォルトの名無しさん
20/06/27 22:30:26.61 kHv6hhb8.net
>>411
壊れるに決まってるだろ、いい加減なこと言うなハゲ
427:デフォルトの名無しさん
20/06/27 22:30:40.41 kHv6hhb8.net
privateなめんなよ
428:デフォルトの名無しさん
20/06/27 22:30:57.83 gS37C1rZ.net
>>413
なんだよｗ根拠言えないのかよｗ