オブジェクト指向ってクソじゃね？

**デフォルトの名無しさん** · 2018/08/24(金) 13:32:09.36

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

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

一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96

**デフォルトの名無しさん** · 2018/09/27(木) 08:20:57.92

昔はgetter/setterを使うべきと言ってたような気がする。
でもその時にそれに疑問を持っていた人達もいたと思うんだ。

結局、クソなのはこういう手法が良いですよという言を真に受けて無理に採用する所じゃね?
このなんとかキブスが自分にぴったりくるなら採用すれば良いし、おかしいと思うなら採用しなくて良い。
オブジェクト指向も一緒でぴったり来てねえのに採用するのは良くないと思う。

**デフォルトの名無しさん** · 2018/09/27(木) 08:24:56.86

グローバル変数をそのまま使うよりは
ゲッターセッターをかぶせた方がマシだけど
使わないにこしたことはないってこと

**デフォルトの名無しさん** · 2018/09/27(木) 09:26:17.13

>>294
状態を持つと単純にテストがしにくい

あるクラスにprivateでドキュメントにも記述のないメンバ変数が10個あって
その内包するクラスにもメンバが10個あって・・・なんてプログラムだと
そのクラスの持つ状態は10*10*・・・
みたいに増えていく
完璧にプログラムを制御しようとすると
その全てを把握しなければならない
実際にはそれは不可能なのでオブジェクト指向的に組んだプログラムはそもそもバグっている

**デフォルトの名無しさん** · 2018/09/27(木) 09:32:35.44

>>295
あんたは使うべきの意味を理解してないよ
使うべきっていうのは今も一緒。

まずクラスのpublicフィールドを直接読み書きしたらいけないというルールがある。
そしてもう一つ、クラスのインターフェースを頻繁に変更してはいけないというルールがある

この２つのルールにより、publicフィールドを直接読み書きしていて、あとから読み書きに
何かしらの制限を書けたくなったときにgetter/setterに置き換えたらインターフェースが変わってしまう。
例えば obj.foo だったものを obj.getFoo() に書き換えないといけない
だから常にgetter/setterを使いましょうと言われていた

だけど今はプロパティを備えた言語ができた。
プロパティを備えた言語であれば、クラスのpublicフィールドというインターフェースを変えることなく
getter/setterにできるためあえて禁止する理由がなくなった
（obj.foo = 1 とかいて obj.foo に代入してるように見えて実は関数呼び出しになってる）

今はインターフェース（名前）を変えることなく、フィールドからgetter/setterに変更できるので
言われてないだけ。でもこれはプロパティを備えた言語に限った話

**デフォルトの名無しさん** · 2018/09/27(木) 09:32:48.24

んで思うのが
どうもアメリカらしくないなと
あれだけメリットとデメリットと数値化にこだわる国がなんでこんな丼勘定やねんと

オブジェクト指向なんて出回った頃にはもうすでに向こうではプログラミングは
無意味な公共事業の一環になっていたのではないか？
そしてそれにはもはや意味がなくて
できるだけ時間がかかる方法だけが採用されたと

**デフォルトの名無しさん** · 2018/09/27(木) 09:34:56.57

>>297
オブジェクトが状態を持つとテストがしにくいからといって
オブジェクトに状態を持たせなかったとしても、
状態を持ってるアプリケーションから状態を消し去ることは不可能なわけで
どこかに状態が存在するので、結局その部分のテストはしにくくなるよ
単にテストしにくい場所が変わるだけの話

**デフォルトの名無しさん** · 2018/09/27(木) 09:35:52.22

>>299
メリットとデメリットにこだわってるから
オブジェクト指向を使ってるのでは？

**デフォルトの名無しさん** · 2018/09/27(木) 09:45:20.17

>>300
まず、それが見えているかどうかが問題
引数から渡す形ならドキュメントに記述を強制できる
さらに同じ引数で実行したらなるべく同じ結果が返って来ることも保証できる
これで気をつけるのはファイルアクセスやDBアクセス、日時、通信などに限定できる
オブジェクト指向は全てのクラスが失敗作であると言える

**デフォルトの名無しさん** · 2018/09/27(木) 09:59:43.55

>>302
いや、どんな言語で作ろうが、
アドベンチャーのフラグ管理は大変だよ
関数型言語なんか、実装が不可能なレベル

**デフォルトの名無しさん** · 2018/09/27(木) 10:51:21.68

オブジェクト指向を捨てたGO言語を使おうってこと？

**デフォルトの名無しさん** · 2018/09/27(木) 11:05:48.54

実は倍精度浮動小数点数のインスタンス変数があったら2^64個の状態があるって話だ
もしくは10x10x10と10+10+10がほぼ一緒の値という主張だよ

**デフォルトの名無しさん** · 2018/09/27(木) 11:44:32.68

>>297
そんなことない

本格的なオブジェクト指向では
>>260みたいに小さなオブジェクト数にして
状態数も減らして単体テストしやすくする

むしろ関数型で複雑な状態遷移を実装するのは難しい
現にゲーム制作ではぜんぜん関数型が流行ってないからな

**デフォルトの名無しさん** · 2018/09/27(木) 11:52:41.46

>>306
理由が全くねーじゃん

**デフォルトの名無しさん** · 2018/09/27(木) 12:15:48.09

>>306
何年か前にOOPのそのトレーニングやったけど
今にして思えばおかしなことをしてたなって思う

素直にGO使ったほうがいいよ
今は制約を気にせず非常に楽にコードが書ける
それでいてOOPのころの糞コードからかなり離れている
GOのおかげ

**デフォルトの名無しさん** · 2018/09/27(木) 12:17:39.22

GOのtypeは非常に見通しがいい
c/c++のヘッダファイルはなんだったのかと

**デフォルトの名無しさん** · 2018/09/27(木) 12:19:15.86

状態を持たないオブジェクトwww
もはやオブジェクトちゃうやんw何の受け売りやそれw

**デフォルトの名無しさん** · 2018/09/27(木) 12:24:21.66

アクセスパターンを限定化する
これを理解出来ないなら
オブジェクト思考プログラミングはし無い方が良い
どういう訳か
凄まじい自信の有る人程解っていない
というのがこの界隈

**デフォルトの名無しさん** · 2018/09/27(木) 12:31:34.84

OOPで良いとされているが一番の間違いは
単機能の小さなクラスを沢山作ること

これはクラス数の爆発を産んでるので一番の害悪

例えば特定のファイルを読むためのクラス
そしてそのインターフェイスとDI用のクラスとテストケース
本当にこれが無駄

内部の状態に依存せず単機能でいいなら関数でつくればいいと気が付いた

**デフォルトの名無しさん** · 2018/09/27(木) 12:37:21.63

>>310
不変オブジェクトがあっても別にいい

>>312
＞単機能の小さなクラスを沢山作ること
小さなクラスをたくさん作るからこそ変更しやすくなる

クラスの数を大きくして数を減らしてしまうと
作るときは一見楽に見えても後で変更コストが上がる

**デフォルトの名無しさん** · 2018/09/27(木) 12:43:37.80

>>313
それはOOP自体が悪いからそう見えるだけ
クラス数の爆発のほうが本当の害悪

上のトレーニングもクラスをちいさくする良い理由の一つとして
エディタの一画面にはいるから…

クラスが一ファイル内にないといけないその言語の制約だろう
パッケージ内に在ればいい言語に乗り換えよう

**デフォルトの名無しさん** · 2018/09/27(木) 12:47:39.73

クラスが小さいと困ることがある
インスタンス変数を２つに絞るのは愚か
確実にクラス設計が困難になる

変数をどこが持つべきかを設計しないといけない
そしてそれが間違っていた場合大規模な再設計とコーディングが必要になる

中程度のクラスにある程度必要とされる変数が入れておく方が開発工数は減る

**デフォルトの名無しさん** · 2018/09/27(木) 12:49:58.82

状態を持たない
そもそもが小さい
ならクラスじゃなくて関数を使え

**デフォルトの名無しさん** · 2018/09/27(木) 12:53:47.09

>>313
不変ゆうんは状態を持つから不変なんやぞw
受け売りでイキるのやめときw

**デフォルトの名無しさん** · 2018/09/27(木) 12:55:53.67

>>260
改めて書くけどこれはほとんどがもう古いし
本当の意味でOOPの弱点をカバーしてない

**デフォルトの名無しさん** · 2018/09/27(木) 13:18:51.56

TCP接続をOOPで書くとして、オブジェクトの外側でTCPの例の状態遷移を気にする必要あるんかいな

**デフォルトの名無しさん** · 2018/09/27(木) 14:18:04.82

不変オブジェクト自体が一つの状態であることは確かだと思うが、語弊がありそうだな。
可換原則的には互換性のある小さなクラスをたくさん作る、が正しいだろうけど、
実際にそれすると、とんでもないバカが現れて瞬時に全壊するのも見たことあるし。
やっぱり一概には言えないと思うわ。

**デフォルトの名無しさん** · 2018/09/27(木) 14:21:34.40

>>316
関数でもいい場合はあるが
クラスにするメリットもある

>>317
それは難癖でしかない
再代入しないことによって
状態変化のデメリットが生じないので問題ない

**デフォルトの名無しさん** · 2018/09/27(木) 15:03:29.89

>>319
気にする必要が無いように組んでもいいし組まなくてもいい
でもテストは全状態に対して行わなくてはならない
現状はおそらくそれをやってる奴が少ないのがまずい
ここではさもやるのが当然とばかりに主張はするがそのテスト方法は提案すら挙げられない雑魚

**デフォルトの名無しさん** · 2018/09/27(木) 15:09:59.98

はっきりさせておかないといけないのは
オブジェクト指向と関数型で条件が違う比較をしてるってこと

つまり
「オブジェクト指向で状態を扱う必要がある問題」
VS
「関数型言語で状態を扱わない問題」
という違った問題で比較している

アプリケーションから状態をなくすのは不可能なので
「関数型言語で状態を扱う問題」を解かなければいけないのだが
なぜか状態はすべてなくすことができるんだという間違った前提で
状態がない優しい問題を解いているだけになってる

**デフォルトの名無しさん** · 2018/09/27(木) 15:43:16.13

>>323
これはそうだな

状態遷移が複雑なシステムをどう組めばいいか
関数型主義者から具体案を聞いたことがないね

**デフォルトの名無しさん** · 2018/09/27(木) 17:55:02.31

おれは関数型主義じゃじゃないけど適切にルール組んでその通りにやればいいだけじゃないか？

関数型はオブジェクト内に状態が隠蔽されてないから
やりやすいだけ

**デフォルトの名無しさん** · 2018/09/27(木) 17:57:15.64

Cだと構造体がなければほぼ全部シグネチャーに書きださなければならなかったけど
関数型は関数で組み合わせてあるから楽なんだろうなとは思う

**デフォルトの名無しさん** · 2018/09/27(木) 18:00:53.71

オブジェクト指向でもやりようによっては状態の遷移がわかりやすくはかける
fluxとかじゃ状態はイミュータブル
actionを適用したらその都度新しい状態オブジェクトを作ってストアしてる
古い状態は書き換えられずに破棄される

**デフォルトの名無しさん** · 2018/09/27(木) 19:04:14.07

状態が複雑になる場合もなるべく明示した方が嬉しいよねってのが関数型のスタンス
Haskellは状態を持つ部分をモナド型クラスのインスタンス(=型)にするし、ML系は非数値状態を型に持たせて型検査の形で明示する

個人的には基本関数型で組んで、状態が必要不可欠な問題に対しては意味論的に隠蔽されているのが正しいならprivateでそれ以外はミュータビリティと型で制御が妥当かなと
その後でパフォーマンスが必要ならその部分をミュータブルなクラスベースOOPにする

**デフォルトの名無しさん** · 2018/09/27(木) 22:11:06.04

>>324
まあ冒頭副作用的な臭いからひっぺがしのモナドが思いつくなこれは

**デフォルトの名無しさん** · 2018/09/27(木) 22:52:16.03

オブジェクト指向ってウェブサイトの構築以外でどうやって使うんだ？
phpとかrubyはわかるがjava、c#やらでどういうシステム作れるか教えて

**デフォルトの名無しさん** · 2018/09/27(木) 22:55:44.14

poco使ってc++でwebｻｰﾊﾞｰの振る舞い自体を組み込みで書く

**デフォルトの名無しさん** · 2018/09/27(木) 23:41:51.25

>>330
＞オブジェクト指向ってウェブサイトの構築以外でどうやって使う
一般的なアプリケーション作成全般
よほど高速な実行速度が要求されるもの以外

**デフォルトの名無しさん** · 2018/09/28(金) 00:59:07.19

そもそもｽﾄﾗｳﾌﾟﾄのC++がまずかったんだよ

**デフォルトの名無しさん** · 2018/09/28(金) 01:09:58.28

>>324
functionalは状態の管理手法じゃないのになに言ってんだ。
functionalは構造の再帰的分割による細分化やリスト処理の宣言的記述に有効であって
状態は必要なければなるたけ持たないほうが良いのはいろはのイ、セオリーだぞ
そして状態遷移は本当に必要ならオブジェクト指向を流用するのではなく
状態をきちんと管理するんだよ。
それをgetter/setterで要らぬところに状態持ち込んでishaだのhasaだの言ってるから
子供にまで後ろ指差されて笑われるんだよ。
言っとくが別にオレはfunctionalﾏﾝｾｰじゃないぜ。

**デフォルトの名無しさん** · 2018/09/28(金) 02:01:07.68

オブジェクト指向はWebよりjavaとかc#のイメージのが強いな
Webのがメジャーな人もいるのか

**デフォルトの名無しさん** · 2018/09/28(金) 02:06:06.17

>>334
何言ってんの……？

＞状態は必要なければなるたけ持たないほうが良い
あのね、ビジネスソフトには状態が必要なの！！

いくら関数型が状態を排除するのが理想だからって
ビジネスを道具の方に合わせることはできない

そんなことも分からないんだから嫌になる
これじゃいつまでたっても関数型が普及しないよな

＞状態をきちんと管理する
だからその具体案を聞いたことがないんだって

本当馬鹿じゃないかと思う

**デフォルトの名無しさん** · 2018/09/28(金) 05:08:03.15

>>335
Spring, ASP.NET Core

**デフォルトの名無しさん** · 2018/09/28(金) 08:02:53.14

>>336
>何言ってんの……？

何言ってるか理解にすら至ってないようだな…

**デフォルトの名無しさん** · 2018/09/28(金) 08:05:29.06

システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がおると聞いて

**デフォルトの名無しさん** · 2018/09/28(金) 10:00:32.06

>>338
その「何言ってんの？」は

何を言ってるかわからないという意味じゃなくて
お前は何（馬鹿なこと）を言ってるの？って意味だろ

日本語の時点で

**デフォルトの名無しさん** · 2018/09/28(金) 12:17:05.53

オブジェクト内部に状態は持たないほうがいいと言うのは当たり前すぐる気がするけどね

**デフォルトの名無しさん** · 2018/09/28(金) 12:54:45.76

>>341

そこは「オブジェクト外部に状態を持ったほうが良い」と言わなきゃだめ
状態をなくせるわけじゃないんだから

**デフォルトの名無しさん** · 2018/09/28(金) 13:12:28.51

オブジェクト外部に状態持っても、結局そのオブジェクトを包含している上位のオブジェクトがあるので、行き着くところは「アプリケーションオブジェクトの外部に状態を持ったほうが良い」ってならない？
どこでラインを引くかはセンスってことでOK？

**デフォルトの名無しさん** · 2018/09/28(金) 13:19:48.03

他のオブジェクトの持つ変数を必要とする事自体がおかしい。
必要な引数を渡したら、処理を任せて、必要な値をリターンさえしてもらえればよい。

**デフォルトの名無しさん** · 2018/09/28(金) 13:32:05.28

>>343
そのアプリケーションオブジェクトの外部ってのが
なんのことかわからない。

ファイルに保存のことなのかもしれないが、保存するまでは
総てのデータはアプリケーション内部にあるわけで
結局、仮想的なストレージ（ようするにメモリ）に
保存するしか無いでしょう？

**デフォルトの名無しさん** · 2018/09/28(金) 15:21:40.87

>>345
そうだよ、俺もそう思うのでアプリの外に状態はあり得ないだろうと。
なのでどこかで線引きをしないといけないんだけど、結局それはセンスという便利かつ曖昧なな言葉で片付けられちゃいそう。

**デフォルトの名無しさん** · 2018/09/28(金) 18:23:35.77

>>343
ん？それでテストできるならやれば？
実際は制御不能でしょ？
だから駄目だって言ってんの

**デフォルトの名無しさん** · 2018/09/28(金) 18:37:56.35

>>347
んんん？
じゃ、具体的にアプリケーションオブジェクト以下に状態を一切持たなくてどうやって実装するのん？
BrowserでもOfficeでもいいから、一般的なアプリでアプリケーションオブジェクト外部に通信中にファイルオープン済みか否かやなんやらかんやら全ての状態を無理せず実装するエレガントな方法教えて。
一切の状態をアプリに持ってたら駄目だよ。
いくらなんでもこれは反論する自信あるわ。

**デフォルトの名無しさん** · 2018/09/28(金) 18:41:30.51

>>347
分かってると思うけど、今どの画面が表示されてるとか項目の何が選択されてるかも全て状態だからね。
さぁ、エレガントな説明してみて。

**デフォルトの名無しさん** · 2018/09/28(金) 18:57:00.64

いつまでずれた馬鹿な話してんの？

例えば犬クラスがあってポチオブジェクトがあった
そいつに餌を毎日おなじ餌をあげてたけど（戻り値　完食）
ある日半分しか食べなかった（戻り値　半分）
後でわかったけどポチは病気だった
かわいそうなポチ

犬クラス内部に状態があって同じメソッドを使ってても動作変わってるのが厄介だと言ってるんだろ
それがわからないのかなあ？

**デフォルトの名無しさん** · 2018/09/28(金) 19:01:55.81

ポチはたまたま病気だとわかったけど
わからなかったら何で半分しか食べないのかわからない

事前に誰かが餌をやったのかもしれない
失恋でショックだったのかもしれない
気分がたまたまそうじゃなかったとしたら解剖しても理由はわからない

未来のテクノロジーでその時の内部状態を再現した無数のポチを作って条件に分けて
えさやり動作チェックするなんて考えただけでも寒気がする

**デフォルトの名無しさん** · 2018/09/28(金) 19:02:47.77

それはポリモーフィズムを理解してないだけでは。

**デフォルトの名無しさん** · 2018/09/28(金) 19:03:10.43

>>350
厄介だけど、どこかのレイヤで病気か否の状態は必要だろ？
それがアプリケーションレイヤよりさらに上なんてのはあり得ない。

**デフォルトの名無しさん** · 2018/09/28(金) 19:08:25.24

ポリモーフィズムは参照先インスタンスに依存するので、それは間接的とはいえ状態そのものやね。

**デフォルトの名無しさん** · 2018/09/28(金) 19:11:12.35

>>353
だから対象オブジェクト内部に値を持たせないで関数のシグネチャーにして渡せと

関数に
病気かどうか
失恋かどうか
気分が悪いかどうか
前食べてからどのぐらい時間がたったか
と餌の量を値として渡せと

**デフォルトの名無しさん** · 2018/09/28(金) 19:13:30.49

>>355
そのシグニチャを渡すのは誰？
全ての状態を人間であるユーザーが渡すのん？

**デフォルトの名無しさん** · 2018/09/28(金) 19:18:47.60

>>356
関数を使うものが渡す
その関数は勝手に知らない場所にある値を使わない
同じ値の組を与えたら必ず同じ値を返す

**デフォルトの名無しさん** · 2018/09/28(金) 19:19:57.74

>>348
え？誰がそんなこと言ったの？
内部に持ってアクセスできないのが駄目だって何度も言ってるじゃん
関数実行したら出力全部出せよ
同じ引数で実行したら絶対同じ結果を返せ

**デフォルトの名無しさん** · 2018/09/28(金) 19:22:08.98

>>357
関数を使う、突き詰めればOfficeのユーザーがどの設定画面のどのタブでどのチェックボックスが有効でどのボタンを押したかを一度に伝えるのん？
俺はそんなことはしてないなぁ。
少なくともどの画面が表示されてて何が選択されてるかはアプリの状態に依存してるわ。

**デフォルトの名無しさん** · 2018/09/28(金) 19:23:07.62

犬に餌をやらなくても満腹にできる魔法

**デフォルトの名無しさん** · 2018/09/28(金) 19:24:11.70

何でモデルとアプリの状態の話を混同してるかがわからない

**デフォルトの名無しさん** · 2018/09/28(金) 19:25:06.97

>>358
OKボタン押したら絶対に同じ結果になるのん？？
仮に条件によりOKボタンが押せないなら、それはOKボタンを押せない条件がアプリにあるってことになる。

**デフォルトの名無しさん** · 2018/09/28(金) 19:32:21.07

>>362
普通は分かるけどへんに誤解があるかもなので訂正。
誤　OKボタンを押せない条件
正　OKボタンを押せない状態

**デフォルトの名無しさん** · 2018/09/28(金) 19:36:02.78

>>362
引数は同じなの？
お前さっきから人の話聞いてるのか？

**デフォルトの名無しさん** · 2018/09/28(金) 19:37:20.39

>>362
そもそもお前のアプリって
同じ画像保存してもクリックするたび画像変わるんだろ？
さっさとクビ吊れよ

**デフォルトの名無しさん** · 2018/09/28(金) 19:38:21.84

俺がはなっから言ってるのは、アプリ以下のどこかに状態は必要なはずで、それよりも外に状態を追い出すのは無理があるってことだけ。

**デフォルトの名無しさん** · 2018/09/28(金) 19:39:58.48

>>365
お前のアプリは画像選択もしてないのに突然エロ画像表示するのかw
児ポで捕まっとけw

**デフォルトの名無しさん** · 2018/09/28(金) 19:44:25.53

システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がハッスルしちゃっとると聞いてw

**デフォルトの名無しさん** · 2018/09/28(金) 19:45:26.35

>>323-324
それな
関数型言語っつうのも所詮そんなもん

**デフォルトの名無しさん** · 2018/09/28(金) 19:47:14.39

システム、つまりアプリの状態は少なくともアプリケーションオブジェクト以下が制御してるので、全てのオブジェクトが状態を管理しないってのは無理があるって話。
最初からそう言ってる。

**デフォルトの名無しさん** · 2018/09/28(金) 19:50:57.15

つか関数型餌やりだと餌やり関数から出力される犬は入力された犬のクローンじゃないのか？

**デフォルトの名無しさん** · 2018/09/28(金) 20:15:03.29

>>366
理由は？
outputでstatusも出しゃいいじゃん
ハイ、論破

**デフォルトの名無しさん** · 2018/09/28(金) 20:18:19.44

>>371にどう答えるかでバカのレベルが計れるw
いまのとこ華麗にスルーした>>372がキングやねw

**デフォルトの名無しさん** · 2018/09/28(金) 20:20:36.12

>>372
具体的にどんな大多数のアプリがそう実装してるの？
悪魔の証明を避けるにはお前に実証責任があるからね。

**デフォルトの名無しさん** · 2018/09/28(金) 20:21:59.66

>>374
今はおまえがしゃべっていい時間やないで

**デフォルトの名無しさん** · 2018/09/28(金) 20:23:45.55

>>375
あ、すんません。
誰が喋っていい時間なのかよく分からないけど黙っときます。

**デフォルトの名無しさん** · 2018/09/28(金) 20:25:39.72

>>376
うむ、おまえは既に名誉バカの称号を持っとるからここに参戦すべきやない
すこしおとなしくしとけ

**デフォルトの名無しさん** · 2018/09/28(金) 20:26:26.12

>>377
あい、すんません。

**デフォルトの名無しさん** · 2018/09/28(金) 20:28:27.44

>>374
c言語でグローバル変数使わなかったら他どんな組み方があるの？
引数か戻り値で渡すしかないでしょ？
グローバル変数使用禁止が作法のように語られてたんだから
昔の人は何をするべきかわかってたんだよ

**デフォルトの名無しさん** · 2018/09/28(金) 20:56:14.71

OOPは糞かもしれんが
じゃあ何がいいのかと言われたら別に他にこれといってないのが現状

**デフォルトの名無しさん** · 2018/09/28(金) 21:12:44.75

頭悪いﾔﾂにかぎって
うれしがってなんでも継承して抽象化とかいってるからな

ﾎﾓを人間ｸﾗｽから派生するぐらい愚かなことやってる

**デフォルトの名無しさん** · 2018/09/28(金) 21:16:43.74

基本は当たり前すぎて、階層化であり局所化であり
順序回的な「無用な」状態保持は極力回避し組みあわせ回路的・関数的構造にし、、、、
関連はﾈｯﾄワーク構造よりもツリー構造を指向して見通しよくし、
関連性の強い物は近くにおき(遠くのファイルからあちこち継承してクロスファイルでmethod取り込むようなことはせず)、
といった、、、アー効けく茶後期ﾂのための基本セオリー。
その表現技法は言語のパラダイムによって変わるだろう。

問題はオブジェクト指向がそういった基本セオリーに反するような手法として普及してしまったことだよ。

**デフォルトの名無しさん** · 2018/09/28(金) 21:17:57.02

>>382 ひでえ誤字すまん
×「アー効けく茶後期ﾂ」
○「アーキテクチャー構築」

**デフォルトの名無しさん** · 2018/09/28(金) 21:23:02.60

なんでコイツ急にポエりだしたん？

**デフォルトの名無しさん** · 2018/09/28(金) 21:25:30.29

ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない

**デフォルトの名無しさん** · 2018/09/28(金) 21:27:24.36

たとえば関数型であれば、クロージャーや部分適用を使うことにより、
クラスをｲﾛｲﾛ作ったり状態instance変数でオブジェクトに特徴をもたせ分けるより
非常にシンプルに表現できるし、
また、解法を関数の段階的細分化で構成することにより、
内側の回関数は小さくなるにつれ速やかに単純な構造になる上、
(再帰も含めた)関数呼び出しの引数リストと帰り値のスタック階層および局所変数が、
自然と個々の階層の参照する「近くにあるべき」状態を単純な木構増階層のかたちで保持できる。

ちなみに上にも書いたけど俺はfunctinalﾏﾝｾｰじゃないからな。

**デフォルトの名無しさん** · 2018/09/28(金) 21:29:55.72

>>385
俺の周りでは、素人に毛がはえたか分からんような又派遣さんが、
専門学校でインチキ教わったのか知らないが、
そういう薀蓄をたれながら、くそコード量産して要らぬバグ入れて
残業大会やってるよ

**デフォルトの名無しさん** · 2018/09/28(金) 21:33:34.54

あえていえば
できるだけ自律的であることが適切で
なおかつそのようにほぼ自律的に振舞うように実装されていれば
内部状態が保持されることは実装として適切

ただし、すべて外部的な要因で翻弄される続けるｵﾌﾞｼﾞｪｸﾄが内部状態を保持することは
適切な理由がないかぎり、できるだけ避けるべきといっていい

**デフォルトの名無しさん** · 2018/09/28(金) 21:35:43.41

問題によってどうしても必要な内部状態というものはあるからな。
そこまでだれも否定はしてない

**デフォルトの名無しさん** · 2018/09/28(金) 21:36:39.96

刺身の上にﾀﾝﾎﾟﾎﾟ乗せる作業なんか
ほっといってもいい

そのｸﾗｽだけでほぼ完結できる

**デフォルトの名無しさん** · 2018/09/28(金) 21:37:59.71

> 外部的な要因で翻弄される続けるｵﾌﾞｼﾞｪｸﾄが内部状態を保持する

まぁアンタの言うように避けたようがよさげにも見えるが
ここでふと思い出されるのはコンテクストとかビルダの働き

java.awt.Graphicsみたいなコンテクストオブジェクトをグニグニいじったり
java.lang.StringBuilderのようなビルだオブジェクトをグニグニいじったり
そういうところこそにOOPの楽しみがあるように俺には少し思えるんだ

**デフォルトの名無しさん** · 2018/09/28(金) 22:12:55.17

ボタンやチェックボックスがGUIの共通の振る舞いを制御する親クラスがいるのはC++で書かれる前から実装継承するように設計されていた。

一方、普通預金、当座預金、定期預金の共通関数があったとして、預金というスーパークラスを書いているシステムはないぞ。メガバンクの情報系であってもな。

**デフォルトの名無しさん** · 2018/09/28(金) 22:24:55.23

お、キングを抜いた奴がでたでw
今は>>389がバカキングなw

**デフォルトの名無しさん** · 2018/09/28(金) 22:51:26.95

>>259
OOコード養成ギブス
http://d.hatena.ne.jp/akkt/20080424/1209051266

置いとくぞ忘れてはならない戒め