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

**デフォルトの名無しさん** · 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/24(月) 23:07:18.05

転ばぬ先の杖
STOP ｵﾌﾞｼﾞｪｸﾄ指向

**デフォルトの名無しさん** · 2018/09/24(月) 23:31:05.04

>>230
いびつな答え方するんだがそりゃ間違いなくパーツや責任関係の切り分けからーの作りやすくなるってことやろな
俺は嘘だと思う

**デフォルトの名無しさん** · 2018/09/25(火) 08:11:13.05

色んなサイトでオブジェクト指向の説明してるけど説明が下手すぎねえか？
設計図とか野菜や動物に例えるとか理解してんのかと思うわ
雛形作ってからそこに入力規格を統一したデータをぶち込むって例えでいいだろ

**デフォルトの名無しさん** · 2018/09/25(火) 08:46:47.22

>>235
意味不明すぎてふいた

**デフォルトの名無しさん** · 2018/09/25(火) 08:48:25.26

オブジェクト指向とは雛形作ってそこに入力規格統一したデータをぶち込むってことだぞ

**デフォルトの名無しさん** · 2018/09/25(火) 08:48:47.92

わかってんのかお前ら

**デフォルトの名無しさん** · 2018/09/25(火) 11:00:50.48

さっぱりわからない
オブジェクト指向のメリットとか特に

**デフォルトの名無しさん** · 2018/09/25(火) 12:27:26.16

ぶち込んだ経験ないやつには難しいやろな

**デフォルトの名無しさん** · 2018/09/25(火) 12:30:49.14

オブジェクト指向とは関数仕様があってそこに仕様通りの引数渡すことなのね。
すごい、ようやく俺でもオブジェクト指向が理解できた！

**デフォルトの名無しさん** · 2018/09/25(火) 15:04:59.78

>>215
＞オブジェクト指向って何ですか？
オブジェクトを中心に組むこと
クラスベースの言語ならクラス
Cは関数で組むけどC#はクラスで組む

＞C言語では
できる
けどCは向いてない
C#とかJavaとか
最初からOOをサポートしてる言語の方がやりやすい

**デフォルトの名無しさん** · 2018/09/25(火) 15:05:47.22

>>230
＞オブジェクト指向のメリット
プログラムの変更コストが下がること

**デフォルトの名無しさん** · 2018/09/25(火) 17:07:50.15

>>243
どういう理由で？
オブジェクト単位に分けると仕様が消えるの？

**デフォルトの名無しさん** · 2018/09/25(火) 18:10:21.54

>>244
疎結合になるから

**デフォルトの名無しさん** · 2018/09/25(火) 18:52:32.16

>>245
それって君が想定した変更のときだけだよね？

**デフォルトの名無しさん** · 2018/09/25(火) 18:58:18.78

そうでなければむしろ最強レベルの苦痛を伴う変更になるんだよね？
無意味じゃない？

**デフォルトの名無しさん** · 2018/09/25(火) 19:02:25.86

>>246
想定外の変更があったとしても
オブジェクト単位の方が変更しやすい

**デフォルトの名無しさん** · 2018/09/25(火) 19:05:45.05

>>248
別れてるからこそ変更しにくいって状況になったことがない？
経験不足じゃない？

**デフォルトの名無しさん** · 2018/09/25(火) 19:10:47.09

例えばさヘッダーと内容と記述者と更新日時がある条件を満たしたときに
ヘッダーにある文字列を入れて欲しいと

でもヘッダーは他の全てを知らないので関連するオブジェクト全てに手を入れなければならないと

こういうの想像できないの？
レベル低くね？

**デフォルトの名無しさん** · 2018/09/25(火) 19:16:48.81

>>249
いやいやそれこそ
オブジェクト指向開発での経験不足

**デフォルトの名無しさん** · 2018/09/25(火) 19:22:34.13

>>250
＞ヘッダーと内容と記述者と更新日時
たとえばブログのエントリのように
それらの情報に関連性があるのであれば
ひとつのオブジェクト（クラス）にする

そのオブジェクトは当然関連するデータを知っているので
変更もスムーズにできる
一方オブジェクト指向でない場合には
それらのデータがバラバラになっているから変更しにくい

この場合は疎結合というより高凝集の側面が出ている
オブジェクト指向で正しく組むと高凝集疎結合になる

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

>>252
って変更を各オブジェクトに入れないとできないよね？
c言語だと普通に処理書くだけやで

**デフォルトの名無しさん** · 2018/09/25(火) 19:40:26.69

オブジェクト指向は設計思想として好きだけど
オブジェクト思考的パラドックスに陥っている気がする

**デフォルトの名無しさん** · 2018/09/25(火) 19:54:06.59

これだけ前もって言っといた方がええやろ
データとメソッドをオブジェクトで綺麗にまとめることを自慢する輩はオブジェクト指向ですらないと

**デフォルトの名無しさん** · 2018/09/25(火) 20:13:12.32

データとメソッドをオブジェクトで綺麗にまとめられるのは事実
別に自慢はしてない

オブジェクト指向を勘違いしている人はオブジェクト指向を、
不可能なことを可能にする技術だと勘違いしておいて
不可能なことを可能にしてないと（自分の勘違いを）批判してる

オブジェクト指向は従来のやり方でも可能ではあるが
大変なことをより分かりやすく簡単に実現するための技術

**デフォルトの名無しさん** · 2018/09/25(火) 20:53:51.26

>>253
＞c言語だと普通に処理書くだけ
大規模になると「普通に」って言っても
関連のある変数を探すのが大変になってくる
だからオブジェクト指向の方が変更しやすい

**デフォルトの名無しさん** · 2018/09/25(火) 21:06:16.95

オブジェクト指向は大規模開発のために作られた
だが小規模開発で使用しても問題ない

**デフォルトの名無しさん** · 2018/09/25(火) 21:51:35.20

強制的にOOに慣れるためのプログラミングスタイル、ってありませんか？

**デフォルトの名無しさん** · 2018/09/25(火) 21:56:25.48

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

**デフォルトの名無しさん** · 2018/09/25(火) 22:15:26.66

>>260
thx a lot !!!

**デフォルトの名無しさん** · 2018/09/25(火) 22:46:19.22

>>256
> オブジェクト指向を勘違いしている人はオブジェクト指向を、
> 不可能なことを可能にする技術だと勘違いしておいて
> 不可能なことを可能にしてないと（自分の勘違いを）批判してる

こういう意見おなかいっぱい
「OOPのメリットはXXXです」
以外の文章はもういい

**デフォルトの名無しさん** · 2018/09/25(火) 22:57:23.11

流れを追っていくとOOPのメリットはリファクタリングにかかるコストが安いって読めるけど
これじゃあダメなのか？

**デフォルトの名無しさん** · 2018/09/26(水) 00:31:24.02

オブジェクト指向のデメリットが単純にコードの段取りや量が増えて鈍臭いんだから
メリットは必然的にその分作りやすくなるって事に消去法でなるやろ

まあ嘘である

**デフォルトの名無しさん** · 2018/09/26(水) 00:44:41.52

>>260
適当に読んだけどええ事書いてるな
そうそう抽象化っていうのはこの位しないとダメよな

**デフォルトの名無しさん** · 2018/09/26(水) 04:39:27.51

セッター、ゲッター、プロパティを使わない。
これはカプセル化を強いる抜本的なアプローチだ。
これはDependency Injectionアプローチの実装も必要になるし、
"言え、訊くな"という格言の遵守も必要となる。

おれの居るところ真逆のプロジェクトだ使いまくりでワロタ

**デフォルトの名無しさん** · 2018/09/26(水) 06:02:50.00

セッター、ゲッター、プロパティを使うなってのはクラスは全て操作だけで実装しろってことなのかな？

**デフォルトの名無しさん** · 2018/09/26(水) 08:59:38.32

>267
イメージ的にはそうだと思う
ただ操作対象を設定する必要は有るから全く使わないという事では無い
ゲッターセッターの一番の問題点は
それを不用意に使ってしまうとグローバル変数をただ面倒な手順を増やして使うだけになってしまい易いから
不用意に使わないようにする
という訓練の為に
使うな
と言っているのだろう
あくまでオブジェクト指向プログラミングが全くと言って出来ない人向けなんだろう
というよりそう書いて有るけど
オブジェクト指向プログラミングの最大の問題点は
標準教範が存在していない事なんだよなぁ
そのギプスなんたらは教範の一部に成れる可能性が有るかもしれない

**デフォルトの名無しさん** · 2018/09/26(水) 21:23:07.74

>>268
納得できる説明なのにおかしな改行で台無し・・・

**デフォルトの名無しさん** · 2018/09/26(水) 22:10:14.19

メタプログラミングが不要な用途だけなら、オブジェクト指向知らなくても組める。
まあいつまでももそれだと、大規模システムの仕事は無理だが。

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

ゲッターセッターの悪いのは
インタフェースありきの設計の中に
実装上の変数がうっすら見えてきちゃうこと
そんなもんを前提に設計してはならない
実装に対してプログラミングするのではなく
インタフェースに対してプログラミングするのだ

同じ理由で、それを書き易くしたC#のプロパティみたいなもんは糞
池沼の要望に迎合したような糞

**デフォルトの名無しさん** · 2018/09/26(水) 22:42:34.06

>>271
メソッドとプロパティ (setter, getter) は本質的に同じものだよ

オブジェクトのメソッドの大半はオブジェクトの状態を取得または変化させる
（状態を参照しないならそのオブジェクトに持たせる必要はないわけで）

オブジェクトのメソッドのうち、一つの変数を変更するものがsetterで
一つの変数を取得するものがgetter・・・になってることが多いが別にそうする必要はない。

例えば内部変数が配列で要素の0番目を読み書きするsetter/getter
要素の1番目を読み書きするsetter/getterを作っても良い
もちろんsetter/getterではなくメソッドでやっても良い
どちらでも同じことができる。

言い換えると、システムを作るのに、メソッドだけでも実現できるし
プロパティ (setter/getter) だけでも実現できるということ

メソッドとプロパティ (setter/getter) の違いは
UMLのクラス図を書いたことがあればわかる。
UMLのクラス図には操作と属性の両方が存在するんだよ。
なぜか？それは人間の思考を反映させた結果だから
実装段階の思考ではなくて設計段階の思考ですでに操作と属性が別れてる。

メソッドとプロパティは本質的には同じものでコンピュータから
見れば同じものとして扱えるが、我々は人間なんだ。

人間がそれは操作、それは属性って分類して考えてるから、
それをコードに反映させられる記述能力の高さを求めた結果
メソッドとプロパティができたんだよ

しかたないね。人間だもの

**デフォルトの名無しさん** · 2018/09/26(水) 23:05:14.04

> メソッドとプロパティ (setter, getter) は本質的に同じものだよ
> （以下ポエム略）

？？
なぜそれを俺にレスしたのか不明

**デフォルトの名無しさん** · 2018/09/26(水) 23:25:48.93

むしろおまえ以外の誰にレスしろというのか不明w

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

だが実際にはクラスを半グローバル変数の格納構造体みたいに使って
setter/getterでアクセスして外側から中の実装を多角的に覗くような記述をし
そこに更に継承を使って依存でスパゲティー状態になっちゃうから
ソフトウエアの表現方法としての有効性に疑問を持ち始めた人が現れてきたんじゃないかな

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

>>275
つまり、

× getter/setterが悪い
○ getter/setterの間違った使い方が悪い

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

刺身にﾀﾝﾎﾟﾎﾟのせてるﾔﾂが
ちゃんとｷﾘｷﾘ働いてるか
その働きぶりをたまに覗きたいことはある

こっちからなにをするということはない

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

>>276
確かに悪い使い方が都市伝説みたいに普及しすぎて、ろくろくまともな開発したことの
無い輩まで頓珍漢なｵﾚｵﾚオブジェクト指向論を吹聴するにいたったブームには参ったが、、

使い方の問題のみならず、そういう表しにくい構造がソフトウエアそのものにあるじゃないかと思う。
非常に表しにくい場合が少なからずあり、小さいサンプルコードの断片で説かれるOOの美しいはずの
メリットは実践で適用の場が乏しいということ

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

>>260
このギプスのサイトに書いてある方法は
すごく制約した方法であり、
いろいろ大変かも知れないけど
守れば副作用の少ないモジュラリティーと
深すぎない階層設計が可能になるかもしれないのはよく分かる。
でも、守るためには強い規律とメンバのスキルと
工数のゆとりが必要だと思った。
つまり、現実にはなかなか難しい話だろうなと。

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

いや、単純にオブジェクト指向なんてやったって地獄に落ちるだけ
クラスっていうゴミ箱に突っ込んで臭いものに蓋してる状態じゃいつまでたってもバグなんて取れないんだよ

単純にプログラムを

入力→処理→出力

という繰り返しの塊にしなければならない
メソッドを呼ぶたびに状態が変化
するようなもん誰も管理できない

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

オブジェクト指向の解釈が多彩なので、あれだけど
オブジェクトscopeは有効な場面は多々あるんだよな
closureとか部分適用とか

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

ｵﾌﾞｼﾞｪｸﾄ指向でも
詳細化したらﾃﾞｰﾀﾌﾛｰ図に落とせる設計でないと
お話にならない

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

状態を持ってしまうのがまずい
いや、持つだけなら好きにすればいい
内包してしまうのがまずいと言うのが正確か？

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

以前(>>161)にも書いたとおり
ｺﾚ以外方法はない

この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる

　①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
　②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
　③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
　　※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
　④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
　　処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
　　（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
　⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止

ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる

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

単純にメソッドの成功条件に内部で持たれているメンバの見えない奴が関わってたりすると最悪
プログラムのどこでそいつが変更されるのかわからん

こういう問題が起きるたびに途方も無い労力を支払うのが単純に無駄
オブジェクト指向を考えた奴はわざと技術者の仕事を作るためにこれを考えたのではないか？
というぐらい一切メリットがない

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

>>284
だからな
お行儀のよいクラス作るほど
その実開発者は地獄を見るんだよ
オブジェクト指向がクソな原因は
簡単で内部に状態を保持することなんだよ

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

もう今日は寝ろよﾊｹﾞども
ﾉｼ

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

単純な入れ子構造になっているか分かりにくい
ランダムに依存しうるネットワーク構造は管理しにくい
しかもノードインスタンスごとに状態を持っていたり
何の×ゲームだよ

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

割と真面目にオブジェクト指向は将来的に絶対破滅するという想定で作るといい気がしてきた
上で出てる上手くいく方法とかは「延命措置」とみなして
そう考えたら何かすっきりする

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

そう。1000年後には絶対破滅するという想定で、
今の仕事を全力でやればいい。
今必要なら、必要ってことさ、AHAHAHAHA～

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

>>260
部分的に構造化プログラミング養成ギプスのような気がする

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

メソッドを呼び出す順番に依存してはならない

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

>>283
公開されてるメソッドの呼ばれ方による状態繊維が簡易なレベルならば問題ない
といったところ。
通信ソケットの実装みたいなものはどうしても状態を持つのは仕方ないけど、
でもそれもできる限り小さく持つってのが最近の感覚じゃないかね。

内部に巨大で複雑なオブジェクトをガツガツ作る様なメソッドがある場合は
なんか問題ある気がする。

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

状態を持つなって言ってるのは関数型の考えから？
常にオブジェクト指向言語の方がメジャーなんだが

**デフォルトの名無しさん** · 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++がまずかったんだよ