オブジェクト指向ってクソじゃね？
レス数が1000を超えています。これ以上書き込みはできません。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>1
ケイちゃんの言うレシーバオブジェクトは
ネットワーク越しにアクセスできるコンピュータだから
プライベートのキーワードはなくても
必然的にプライベートになるんじゃないかな 砂糖(シンタックスシュガー)を加えて関数型言語っぽくしているが、臭いまではごまかせない オブジェクト指向が無くなった場合
メソッドは全部グローバル関数になるの？
PersonRename(Person p,string newName);
PersonSetAge(Person p,int age);
PersonGetAge();
FirePersonCreate(Person p);
FirePersonRename(Person p,string newName);
FirePersonSetAge(Person p,int age);
FirePersonGetAge(); 訂正
PersonRename(Person p,string newName);
PersonSetAge(Person p,int age);
PersonGetAge();
FirePersonCreate(Person p);
FirePersonRename(FirePerson p,string newName);
FirePersonSetAge(FirePerson p,int age);
FirePersonGetAge(); 文系がこねくり回して、結果的に無駄にコード量増やすようなイメージしかない。 カプセル化が原因で開発ができなくなるとするならオブジェクトの分け方が不適切なのだろ、開発が進むに連れてオブジェクトの役割が変遷したのだろ、設計やり直せないなら地獄だな 設計のないスタティックおじさん方式は柔軟かもわからんね↓ >>61
正しく組めば重複が減ってコード量は減る
>>64
普通はカプセル化しないことで
開発できなくなることの方が多い
グローバル変数を使うとか オブジェクト指向で描くロバストネス図なんてのは
構造化プログラミングの前のフローチャートそのものじゃないか
オブジェクト指向は現代のGOTO文なんだろ？ >>67
https://thinkit.co.jp/article/13487
> ロバストネス図を書くにあたっては、以下のルールを遵守する必要があります。
>
> ・アクターはバウンダリのみ関連線（矢印）が引ける
> ・バウンダリはコントロールとアクターのみ関連線が引ける
> ・エンティティはコントロールのみ関連線が引ける
> ・コントロールはコントロール同士とバウンダリのみ関連線が引ける
残念ながらフロー（流れ）を示す線は書けないので
フローチャートにはならない。特に条件分岐やループなどがない >>67
どちらかというとロバストネス図は
ユースケース図の方が近くて
フローチャートと同じってのはおかしい /** リストの要素をゼロで置き換える **/
private void clearList() {
for (Integer el : someList) {
el = new Integer(0);
}
}
なかなかファンキーなロケンロールだぜ >>68
条件分岐はあるで
ループもあるで
GOTOだからわかりにくいけど
線はフローを表すんやで
ロバストネスエアプか？ >>69
ユースケース図はユースケースを並べたものですよね
ロバストネスはユースケースごとに処理フローを
書くわけでフローチャートそのものですよ 構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ >>75
違うけど、意味がわからないから例をあげてみて
「簡単な処理」とは何かライブラリを使えば難しい処理は簡単な処理とみなせるのか？ インターフェースを切って実装を分離することを言ってるんじゃないか？ そもそも、継承関係で隠蔽しちゃい合うのが問題なだけで、
インスタンス握り合うだけの仲なら、相手の陰部まで見に行く必要性なんて無いだろ。 >>70
そのサイトには賛成できる部分と反対の部分がある
「クラスとはデータ構造」で
「責務はクラスではない」というのには大反対
クラスは責務そのものという方が
オブジェクト指向の主流の教え方 >>75
当たってる部分がなくもないけど
たんに関数に分割するんじゃなくて
抽象化するのがオブジェクト指向 >>79
ゴトーが主流の時代もあったわけで
主流じゃないからという理由で反対するのは
いけないことだと思います！ 責務ごとにクラスを作るのがどうして主流だよね？ってことですよ >>81
それもそうか
>>82
変更コストが下がるから
>>83
いやむしろ凝集度は上がるよ？
凝集度を上げるっていうのは
でかいクラスを作ることじゃないよ？ ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな？
どうもUI部の設計は苦手だ。 >>84
データに関わる処理を一箇所に集められますよ
凝集度は高くなります ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです >>85
肥大化するのが設計が甘いと言われればその通りでしょ
ただ最初から一発で分からないことも多いので
リファクタリングするのも大事だと思う >>86
＞データに関わる処理を一箇所に
複数のデータの処理を一箇所でやるという意味なら
凝集度は下がる
>>87
ドメインオブジェクトの数が増えていくのは普通だが
1オブジェクトの行数が増えていくのは肥大化 >>89
そんなバカな
行数でオブジェクトを捉えるべきじゃない
振る舞いがどこにあるべきかで考えないと
行数が増えたからオブジェクト分けましょうなんてのは
オブジェクト指向の理念に反する
データをカプセル化してデータに対する責務を持つのが
オブジェクトなんだよ データに対する振る舞いが集まるんだから凝集度は高まるんです オブジェクトが何かを考えないと行数で判断するという
前世紀のような事が起こるわけです
行数が多いからこのオブジェクトは頑張ってるんだな
と思ってしまうわけです
大きな間違いです、オブジェクト指向の根幹はカプセル化です
次に多態性、オブジェクトに適切なフルマがあって初めて
多態性を実現できます 皆が言ってることはもちろん分かる。
分かった上でViewのコートが大きくなりすぎて例えばC#ならついついpartial使ってファイル分けちゃう。
MVVMでも結局はViewか大きくなっちゃう。
いや、分かるよ。俺がViewの設計が下手っぴなのは認める。 >>93
ごめん、間違えた。
肥大化するのはViewじゃなくってViewModelだわ。 >>90
もちろん行数は目安でしかない
責務ごとにクラスを作るのが本筋
>>91
>>83
別人の発言かもしれないがこの発言の関係に疑問が残る
責務ごとにクラスを作ることで凝集度が上がるのであって
複数の責務をひとつのクラスに混ぜたら凝集度は下がるよ >>92
もちろん行数は目安でしかないが
行数が増えすぎたときに
リファクタリングするのは実践的には大事
>>93
大きくなったら分割するのは何も悪くない
全体の規模が大きくなっていく時に
ひとつのクラスの行数が増えるのが肥大化
クラス数を増やしていくのが正しいOOP つか、ワンオブジェクトワンファイルなんてルールは無いから。 このｽﾚにいるような池沼が作らなければ
ｸﾗｽﾗｲﾌﾞﾗﾘも階層や種類で作るからな
低い階層に行けばいくほど単純な簡単な機能を提供するｸﾗｽになる
階層は完全に分離させて独立したﾗｲﾌﾞﾗﾘにする
そして明確に種類の異なるﾌﾟﾘﾐﾃｨﾌﾞがある場合は
ﾗｲﾌﾞﾗﾘを完全に分離させて独立したﾗｲﾌﾞﾗﾘにする
その上にｱﾌﾟﾘｹｰｼｮﾝを実現するｸﾗｽ群がのっかる
低学歴知恵遅れが作るとすべて同じ階層で同じ種類になる クラスに階層があるなんて寝言は寝て言うべきだと思うの このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ 当然、低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群は
ｼﾛｳﾄでもないかぎり完全に分離するからな
低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘは
当然、中間層のｸﾗｽﾗｲﾌﾞﾗﾘやｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を
参照することはまずない
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘは
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を参照することはまずない
低学歴知恵遅れが作ると酷い依存関係ができる
ｺﾚはｵﾌﾞｼﾞｪｸﾄ指向関係なくﾗｲﾌﾞﾗﾘの基本だからな >>99
継承はクラス間の階層構造だろ？
>>100
行数だけの問題じゃないけど
プログラムを単純化するために
間接的なクラスを作ることはあるぞ？ × このクラスの責務は行数を減らす事です
○ fooクラスに別のクラスに責務を分離できる処理を見つけたので分離しました。
その結果fooクラスの行数が減りました。
「行数を減らす」は「責務」ではない。「責務」を分離することで
得られる結果（メリット）の一つだ >70のサイト読んでると
プログラミングでどの様にしてプログラミングするか
というのと
実際のシステム要件なんかからどうやって設計するか
というのがごっちゃに書かれている感じがする 責務とｱﾎみたいなこといってるわ
組織でたとえるならこうなるからな
経営者ｸﾗｽ 社員をこき使う
↓
社員ｸﾗｽ ← 派遣をこき使う（職階ごとの複数の中間層）
↓
派遣ｸﾗｽ ← ｷﾐﾗが担当するような低ﾚﾍﾞﾙな部分の単純作業（つまりｷﾐﾗ）
派遣は社員の作業も役員の作業もしない
社員は役員の作業はしない
行数が多いのは
作業を整理して作業を手順化して
派遣にうまく単純作業を割り当てれてないのと同じだからな
つまり、人に仕事させないと自分の作業が増える
ｷﾐﾗは派遣だからな、そういう作業はできないのは分かる
作業ﾐｽ（例外）が発生してｽﾙｰし続けてたら上までいくからな 例えば扱うﾋﾞｼﾞﾈｽの領域が違えば
部門を分けることになる
会社に複数の部門があっても一つの会社だからな
種類で分けるというのはそういうことになる
ｷﾐﾗみたいな一種類の単純作業しかしてないﾔﾂﾗには関係ない というわけでな
ｷﾐﾗは刺身にﾀﾝﾎﾟﾎﾟのせる作業に戻りなさい
ｷﾐﾗにはﾑﾘ あ、ｵﾏｴは刺身の醤油入れに醤油つめる作業だったか
いや、醤油入れのｷｬｯﾌﾟをしめる作業だったか
ともかく、ｷﾐの細かい作業なんかｵﾚは知らないからな
作業ﾐｽが発生したらちゃんと報告するようにな
まずｷﾐの直属の上長にだ
分かった？ >>106
それだと上位が下位に依存して
組織が硬直化する
インタフェスを挟んで依存関係を逆転させる
(経営者クラス → 社員インタフェス) ← (社員クラス → 派遣インタフェス) ← 派遣クラス
これがInversion Of Control >>112
それどこの定義？
それと同じような説明をしてる場所教えて Inversion of Controlパターンでコンポーネント間の結びつきを弱める：CodeZine（コードジン）
https://codezine.jp/article/detail/60
こことか ただのﾘﾌﾚｸｼｮﾝやんけ
昔のｳﾝｺMFCのｺﾝﾄﾛｰﾙのﾘﾌﾚｸｼｮﾝとほとんど同じ
結局親のｺﾝﾄﾛｰﾙに大量のﾘﾌﾚｸｼｮﾝのｺｰﾄﾞを埋め込むことになる
ｺﾝﾄﾛｰﾙごとに処理記述するほうがはるかに分かりやすい ×結びつきを弱める
○もともと末端ではなにもしない処理にする 何もしないだと・・・
じゃあたんぽぽ担当は何のために いちいちﾀﾝﾎﾟﾎﾟ載せてる作業経過報告はいらない
作業の補助とか、いちいち次になにをするかとかとか指示はしないからな
ﾀﾝﾎﾟﾎﾟが地面に落ちたとかこのﾀﾝﾎﾟﾎﾟのﾊﾅ小さいとか
そういう報告もいらない
捨てときなさい
それぐらい分かるだろう
ﾀﾝﾎﾟﾎﾟが足りなくなりそうになったら
この台帳に書いときなさい
ｺﾚだけはたまに見といてやるからな DBのテーブル数や列数が少なくて
テーブル設計が洗練されているならオブジェクト指向っていいんだろうね。
でも現実のシステム考えるとアホみたいにテーブルの数が多くて
アホみたいに列の数が多くて、整理もされていないわけじゃん。
そしてアホみたいに文言の定数定義とかも多い。
そうすると、階層構造作ってレイヤの数を増やして
結果的1つの機能を達成するのに作るファイルの数が増えるほど、
それらのアホみたいに多くて長い列名をレイヤの数だけ書きまくる
みたいな苦行が待っているわけじゃん。
少しでも項目名の変更があったらそれらのファイル部書き換えたり
クラス名に変更がありでもしたらファイル名やフォルダ名とか、
テーブル名、import文とか全部書き換えになるわけじゃん。
それにオブジェクト指向でどう頑張っても最終的に値を
埋め込む画面が汚くなるのは避けることができない。
そうするとオブジェクト指向設計で無理にファイルを分けて
構造化するリスクってやばいと思う。
そうなると少ないファイルオブジェクト指向クソ喰らえみたいな勢いで
構造化プログラミングだけでゴリッと書くほうが早いと思うんだよね。
命名規則もいちいち気を使わないで勢いで書くんだよ。
ファイルの中関数定義だらけになるが、
その中で似たような処理の関数見つけてきて、複製して、
今必要な処理ができるように改変して新たな関数を作る。これで十分だ。
1ファイルの中で完結しているんだから不具合は波及しない。
ファイルをまたいでimportして無理にファイルの昨日使う必要性なんて
どこにも有りはしないだろ。ファイルの頭からimportやextend inplementだらけ
とか吐き気がするよ。
オブジェクト指向ってファイル間の関連性追ったり、
ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。 >>122
簡単に言うと短期間しか使わないシステムなら
構造化＋DBで組むのも良いと思うけど
長期間使う大規模なシステムは
オブジェクト指向で組んだ方が
保守まで含めた全体のコストは下がる
だから企業もOOを採用している >>122
それオブジェクト指向の問題じゃなく、システムの基本設計が破綻してるだけ。 >オブジェクト指向ってファイル間の関連性追ったり、
>ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。
それはその通りだと思う
ただ関連性はプログラムではなくてクラス構造図やオブジェクト生成手順図みたいなので判断するもので所謂上から下に辿って見て行く物でも辿って出きる物でも無い
オブジェクト指向プログラミングをすると設計図をちゃんと描いてから作ってる
って感じがするし
ただまともに且つ効果的に作るのは難しくて解っていない人が無理やり作ってしまうと反って酷くなる
そういう風にしか作れなかったりそういう風な人しか居ないならオブジェクト指向プログラミングは止めておいた方が良いそういう風な所はcobolみたいなのが一番向いていると思う
ただしオブジェクト指向プログラミングに効果的な使い方が有り実際に行われているのでオブジェクト指向プログラミングその物がおかしいというのは間違い
多くの人が
使えるか?
使うべきか?
となるとそれは無理なのかなぁ
とは思う
どっちかって言うと解らないなら無理して使うなという物だと思う
解らない人が有る程度居る?沢山居る?ということならプロジェクトで使わないという判断する
というのが重要なんだと思う
解らない人には苦痛でしかないし解らない人が作った物は本人にも他に人にも迷惑でしかないだろうなぁ オブジェクト指向がよくわからんド素人俺にはlinqは感動した。
web系フレームワークの真似事+継承だらけのコードのメンテは地獄だった。素人が手をだしたらアカン代物だわ。 >>128
そのブログ前も見たけど説明が下手だなあ……
何でデザインパターンが必要なのかとか
自分の言葉でほとんど説明できてないじゃん
分かりやすさ以前に分かる説明をしていない >>125
そらーオブジェクト指向はオブジェクト使うからオブジェクトの構造をちゃんと綺麗に作れば問題は起きないな
オブジェクトの構造と言えばオブジェクト同士の繋がり方関連性も含まれるだろうからそのまま全体像にも繋がるから個々のオブジェクトさえちゃんと作れば全部が良くなるとも言えるはず
問題はシステムの基本設計が破錠しないように作ればいい、ということではなくて破錠しやすいという所にあるような >>134
そやな。俺が知ってる唯一の情報がオブジェクト指向はシステムの基本設計が破綻するってだけだからな。 俺が知ってる情報は次の２つだ
1.バカが使うとどんな言語でも破綻する
2.>>133-135はそのバカに属する >>136
問題はそこからやな
バカが使わなければ破錠しないのか、隠蔽のコスパが手続き型や関数型で作るコスパを本当に上回ってんのか オブジェクト指向は複雑な構造を構築するわけだから
別に破綻はしないだろう
むしろ見た目は良い オブジェクト指向の弱点はクラスとクラス間の関係を設計しないといけないこと 小規模ならいいが大規模だと設計必須
とりあえず書き始めると最後に詰まるのがオブジェクト指向
小っちゃいパーツを作ってって最後に組み合わせるとき全然組み合わなかったり
つなぎ目の形が合わないのがオブジェクト指向
普通は小さいパーツが出来てるならある程度楽できるはずなのに逆に苦しくなる
本当におかしい クラスの関係の設計を軽減するためにクラスには最低限の機能しか実装しないようになっていく
インターフェイスを考えた上の設計がないと後で詰まる
当たり前に思ってるけどそれはオブジェクト指向の限界というか弊害 つまりクラス間の関係を排除して、Mix-inだけできるようになればいいのかな >>140
境界定義なんて、モノリシックアプリでも必須なんだが？
その認識もないままオブジェクト指向とかマイクロサービスに手を出すとグダる。
開発チームを苦しめるマイクロサービス（翻訳）
https://techracho.bpsinc.jp/hachi8833/2018_01_29/51135 >>142
限界？ 弊害？
>>142のどこに限界や弊害が書いてあるの？ >>145
あんまりそこにしっかり書かれていないから語弊ありきで言うんだが
その抽象的間接的に作らなきゃいけないてことやな
作ってもいい、じゃなくて作らなきゃいけないという >>146
そりゃ大規模プログラムをメンテナンス性あげて作ろうとしたら
オブジェクト指向に限らず、考えなきゃいけないことだろな。
でも破綻していいなら、別に抽象的間接的に作らなくていい。
小さなツール程度ならゴットクラスで破綻状態でもなんとかできるだろうさ
そういう点で、オブジェクト指向の限界でも弊害でも何でも無い >>147
いや俺の言う破綻てのは別にオブジェクトオンリーにこだわって
細かいとこをクロージャで逃げたり、その場しのぎ的に小さいオブジェクトで茶を濁すのもダメって意味じゃないんよ
小さいオブジェクトならオブジェクト同士やシステムが密結合になりえないだろうしな
オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな > オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな
因果関係が逆
密結合の時・・・問題や破綻が起きる（オブジェクト指向に限らない）
話はこれだけだろう？単純だろうが まあオブジェクト指向は密結合を観察する際の一つの指針にはなるかな。
〜指向全般に言えるけれど、結局は一つの指標みたいなもんで
指標上げることが目的になったらクソになるのは当たり前だよね。 オブジェクト指向に継承って要る？
もともとのオブジェクト指向の発想からすれば、別に無くてもいいっていうか、むしろ邪魔じゃね？ >>154
継承でコードを書く量を減らせるってのはあるが、他の仕組みで代わりになるなら無くても良い ああでもルートクラスのメソッドを全部で使えるってのはでかいかなあ >>149
ちゃうねん
複雑で大規模なモノは何で組もうが問題や破綻が起きやすくなる、って話と
オブジェクト指向は複雑で 大規模なモノを作ると破綻する、ってのは意味が違う
何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。話の流れで言うと前者により後者が悪質な形で発動する
ただ当然理想論言えば問題を元々起こさなきゃいいっちゃいい話よ理想を言えば > 何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。
前提が間違っているから話にならん。
まず標準ライブラリの時点ですでに大規模で複雑
それが隠蔽されてるから単純に見えるってことに気づいていない
大規模で複雑なものを作るためだけのものだからというのなら、
ほとんどのものが大規模で複雑なんだから、オブジェクト指向を
使うのは当然ということになる
そして隠蔽されている部分は無視するという話なら、（オブジェクト指向の）
標準ライブラリを使うだけの簡単なコードは作れる
例えば、Rubyでprint "hello world"と書いただけでもオブジェクト指向が使われてる
オブジェクト指向であっても、小規模で単純なものを作れるものである証拠 >>158
オブジェクト指向言語の標準ライブラリとか1番破綻しないオブジェクト指向のパターンじゃないか？
そりゃ全てのオブジェクト指向で作った物が全て破綻することはないだろう
大規模に向いてるオブジェクト指向をあえて小規模なもの作るに都合いいから流用するのはいい事だろう。個人的には自分で作ったクラスを多数のところで使い回してるならそれぞれ小規模でも全体でみたら中、大規模じゃんってなる所はあるけども
とわいえ、それでもやっぱりオブジェクト指向は大規模なものの為”だけ”にあって、そのため”だけ”の機能があって、そのせいで破綻するってのが俺の考えよ >>159
だからオブジェクト指向で小規模なものを作る例あげたじゃん。
馬鹿なの？
大規模なら破綻するのは、オブジェクト指向で無くても同じ
つまりお前の理屈は
オブジェクト指向・・・小規模は作れない、大規模は作れる
？？？指向・・・小規模は作れる、大規模も作れる
って言ってるだけでしょ
で大規模であれば、破綻するのはどちらも同じなんだから
大規模に置いてはオブジェクト指向も？？？指向も変わらない
だからオブジェクト指向で、小規模は作れないと言ってるだけだよね？
（実際にはオブジェクト指向で小規模なものが作れる） この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる
①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止
ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる >>160
そりゃ作れないなんて言ってないがな。
「オブジェクト指向は大規模なモノを作る為だけにある」って話であって「オブジェクト指向は小規模なモノは絶対に作れない」とはならんからな
ただオブジェクト指向で小規模なモノ作ったらデータをオブジェクトでラッピングしやすいてのがあるけど
あれ完全に全くの偶然でデータをオブジェクトにまとめるのがオブジェクト指向の本丸じゃないように、オブジェクト指向の本丸ではないサブシステムが運良くそこにハマったってだけで
特にそこもオブジェクト指向は大規模なモノを作る為”だけ”にあるってのは意味は変わってないからな
俺が言ってるのは一般的にモノが複雑になれば破綻しやすいという話ではなくて
、”その上で更に”オブジェクト指向は独特の破綻を招くって話であって >>163
あー、わかったわかった、つまりこういうことだろ？
墜落事故は飛行機特有の問題だ
自動車は飛べないから墜落自体ありえない
自動車で遠くにいくなら時間はかかるし
距離も長いから事故の確率も上がるし大変だが
飛べないから墜落事故は起きないのだ そう主張することで、飛行機の何を否定しているのかわからんのと
どうように、オブジェクト指向の何を否定しているのかわからんがなｗ おまえら破綻しすぎじゃね？w
どうやったらそんなに破綻を量産できんねんw >>164
オブジェクト指向の話で悪い例え話したら1番イカンやろ。抽象的なもんの取り扱いなんだから。しかも何言ってるかわからんけど多分それは違うしな
>>166
いやまさにそういう事よ。多人数が動く大規模で抽象的な流れは上手くいくはずがないわ。しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する >>167
> オブジェクト指向の話で悪い例え話したら1番イカンやろ。
は？なんで？
反論できない言い訳にもほどがあるわ > しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する
しない。
オブジェクト指向を使わないほうが破綻するし、
破綻した後のリカバリーはオブジェクト指向よりも大変
お前は単に両方とも破綻するが
オブジェクト指向的破綻をするのはオブジェクト指向だけと言ってるだけだろ
破綻する時点で問題なんだよ。オブジェクト指向の方が破綻しない >>169
>オブジェクト指向的破綻をするのはオブジェクト指向だけと
そういう事や。楽をするためにそれをするメリットが上回ってデメリットのが下回らなきゃいけないのはオブジェクト指向の完全必須項目なんだが
大規模複雑はこの完全必須項目がどんどん難易度が上がってくる。
途中の間違い失敗のリカバリのコストは確実にオブジェクト指向のが上
理想論一般論で言えば間違えなくちゃんと作ればいい、どの作り方でも大きいのは大変は大変、以上！て言えばそりゃそうだが
その問題を防ぐための記法が裏目に出て逆効果なら理想論一般論で片付けたらいかんでしょ >>170
ほらな。
> >オブジェクト指向的破綻をするのはオブジェクト指向だけと
> そういう事や。
墜落事故を起すのは飛行機だけだと言ってるのと同じ
だからなの？状態なんだよｗｗｗ 結局、小規模アプリでも大規模アプリでも
オブジェクト指向のほうが良いって結論なわけだよ。
そして、大規模で破綻するのはオブジェクト指向じゃなくても同じこと ﾊﾞｶに限って抽象化とかいって
ｻﾙみたいにうれしがって継承するからな
破綻はそこから始まる
しばらくたつと
ﾃﾞｰﾀ受け渡しするために
無秩序に相互参照しはじめる
こうなったら終わりの始まり 同じものを作る時、オブジェクト指向はオブジェク手と指向破綻をしやすいが
オブジェクト指向じゃないものを使うと、オブジェクト指向じゃない破綻をする
って言ってるだけ。
オブジェクト指向だと大規模なものを作れる。
オブジェクト指向じゃないと大規模なものは作れない オブジェクト指向じゃなくしたから
大規模なシステムを作れるようになった
って話はあまり聞かない ただモジュール境界を明確にしただけなのをオブジェクト指向って言い張ってるだけだろうな。
「オブジェクト指向じゃないと大規模なものは作れない」
この結論ありきで論法を組み立てるとそうなる。 >>171
そのアカン例えを使うなと
事故が多発しないはずのシステムでそのシステム特有の事故が多発したって話やな
まぁ、その、悪い例えにあえて乗っかるなら自動車で事故りそうだから飛行機に乗ったら墜落事故起こしたって、だからなんだよって言ったらそりゃダメだよってなるような話で
いややっぱアカンやろこの例え、設計を抽象的な部分から見直せ まぁオブジェクト指向は「銀の弾丸」じゃないですからね
オブジェクト指向の採用による成功事例は数多く存在する一方で、
オブジェクト指向を採用したにもかかわらず失敗した事例も
少数とはいえ存在するのも事実
たとえば、以下は「一貫性」という設計哲学が無視されてしまったため、
標準ライブラリ設計に失敗した言語の例
http://mevius.2ch.net/test/read.cgi/tech/1491491123/44-45/
http://mevius.2ch.net/test/read.cgi/tech/1530664695/527/
スレタイに沿って返すとすれば：
・あらゆる言語においてオブジェクト指向ってクソじゃね？
=> いいや、そんなことはない
・Pythonにおいてオブジェクト指向ってクソじゃね？
=> たしかに、Pythonではクソかもしれない >>180
とりあえずお前が馬鹿だっていうのはわかった
大規模なものはどちらにしろ問題が発生する。
オブジェクト指向的問題か
非オブジェクト指向的問題かの
どちらかだ。
オブジェクト指向を使わなかったら
今度は非オブジェクト指向問題が発生するだろ >>181
Pythonで大規模アプリ作って失敗したら
Python的問題が発生したということさ
C言語で失敗したらC言語的問題が発生したということさ 仮にオブジェクト指向設計を採用せずに
構造化設計を採用したとしよう。
大規模プログラムで密結合になってると失敗する
そうすると構造化設計特有の問題が発生したということで
それはオブジェクト指向よりもリカバリーが大変 >>182
んなもん当たり前だろ別のやり方すれば別の問題があるに決まってやろ
そんな何にでも通ずる一般論じゃないの
オブジェクト指向がそれ専用なのに逆効果だから色々言ってるの
これは何にでも通ずるフラットな一般論じゃないぞ？何故ならオブジェクト指向はそれ専用なのに逆効果だからな、いわばイレギュラーで根本的な問題 そう。ただの言葉遊びしてるだけだからどうでもいいこと
結局は構造化設計を選んで失敗したから
構造化設計に問題があると言ってるだけなんだから
自分の非を認めたくないからそういことをしてる
あ、オブジェクト指向が使えないんだっけか？ｗ >>186
いつからオブジェクト指向がそれ専用になったんでーすかーｗ
おかしいですねｗｗｗ 構造化設計は大規模に向かないのである
構造化設計で大規模をやると
失敗する確率が大幅に上がる
構造化設計＋大規模でなんども経験している
そしてオブジェクト指向で設計すると
失敗する確率は大幅に下がるわけだが
それでも失敗してしまったら文句を言おう
オブジェクト指向が問題だったんだー！ >>188
>いつからか
そらー最初からやな。そのため”だけ”やしな >>189
おっ？そうだなオブジェクト指向が問題が問題だったんだ。なんだかんだ同意見やったんやな >>189
>そしてオブジェクト指向で設計すると
>失敗する確率は大幅に下がるわけだが
ここは同意しますけど、
>それでも失敗してしまったら文句を言おう
>
>オブジェクト指向が問題だったんだー！
勘弁してください
数ある言語の中でも失敗してるのはPythonだけなんですから(>>181)、
失敗をオブジェクト指向のせいにしようとしても
それに納得するのはPython信者だけですよ
>>183でもご自分で「Python的問題」と語っていますから、矛盾してます >>190
> そらー最初からやな。そのため”だけ”やしな
そのためって、オブジェクト指向は大規模のときに使うってこと？
ってことは、大規模で問題が起きたら、
それはオブジェクト指向が原因ではないってことだね
だって、単に大規模だからオブジェクト指向を使ったってだけで
大規模で失敗するのは構造化であっても同じだから
>>191
皮肉もわからんのかーｗｗｗ まとめ
構造化・・・大規模に適していない
オブジェクト指向・・・大規模に適している
構造化で小規模・・・失敗しにくい（所詮小規模なので）
オブジェクト指向で小規模・・・失敗しにくい（小規模に使えないとは誰も言ってない）
構造化で大規模・・・適していないので失敗しやすい
オブジェクト指向で大規模・・・適しているので失敗しにくい
構造化で大規模で失敗・・・失敗して当然。構造化に問題があった
オブジェクト指向で大規模で失敗・・・適した道具を使っても失敗した
使ってるやつの能力に問題がある
責任転嫁としてオブジェクト指向使ったから失敗したんやーと叫ぶｗ Cで書かれたOSはくさるほどある
C++で書かれたOSなんかあんの >>192
もう謎のテンション上げで冷静な会話無理やろ、
1レス目の冷静そうな語り口調急にが帰ってきたらそれはそれでキモイけど、、 >>196
お前の会話が非論理的だからしょうがない。
オブジェクト指向に問題があったんじゃなくて
大規模で密結合にしたから失敗があっただけだろ？
構造化であっても密結合にしたら失敗するんだから
で、構造化使って密結合にして失敗したら構造化のせいにせずに
オブジェクト指向を使って密結合にして失敗したら
オブジェクト指向のせいにしてるんだろ？ どちらにしろ
構造化よりもオブジェクト指向のほうが大規模に強いのは変わらん
オブジェクト指向が大規模のために作られたと言っても
小規模で使えないことにもならない
実際に小規模でも使える
オブジェクト指向で失敗するようなら構造化でも失敗する。
能力不足が原因だからな。
で、能力不足を認めたくないから、
オブジェクト指向のせいにしてるんだろ？ そもそも破綻している、と言える状態はどんな場合だろうか だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる 馬鹿「オブジェクト指向で失敗したら、オブジェクト指向特有の・・・」
じゃあ、構造化で失敗したら構造化特有のやり方が原因なんやな？
馬鹿「ぐぬぬ」
↑イマココ で、ｳﾝｺｽｸﾘﾌﾟﾄで
山盛りのｳﾝｺをつくる
rubyとpython作ってるような
ｳﾝｺｽｸﾘﾌﾟﾀｰ ｺｲﾂﾗの場合
ｳﾝｺｽｸﾘﾌﾟﾄﾌﾚｰﾑﾜｰｸ（）使っても
破たんさせるほどの特殊能力がある
だいたいこういうの使ってるﾔﾂﾗは
そういうﾔﾂﾗだ >>198
皮肉もわからんのかーwwwとか言うやつが急に非論理的だ、とか笑わせに来てんのか貴様は
なんだろうなお前の言い分は都合が悪いと全部一般論にして逃げてる感あるな、大規模なモノが破綻するのはオブジェクト指向に限らずみんな一緒とか。
それを言うならオブジェクト指向使わず手続き型で組んでも破綻しないように組めばいいじゃんってなるんだよな。
その先が見えないわけよな。もはや何の為にオブジェクト指向使ってるんという >>200
オブジェクト指向の破綻はルール守る為に手続き型のコストを超えた時やろな ﾉｰﾀﾘﾝ言語の開発現場には
ﾉｰﾀﾘﾝが集まる
ｺﾚは宿命 >>207
上でな、オブジェクト指向は壊れると言ったら壊れないように作ればいいという身も蓋も事を言われたんや
言語はそういう人のために作らないといけないかもしれん >>208
当たり前だろ
どんなものでも壊れるというのは大前提
どれだけ壊れにくいか？という壊れにくさの話をしてるのに、
お前は「オブジェクト指向は銀の弾丸でなければならないが
銀の弾丸でないことが判明したらどうする？」と言ってるだけだろ？
誰もオブジェクト指向が銀の弾丸なんていってない
だが強力な武器なんだよ。 とりあえずオブジェクト指向で作るってことがなんなのかから判別しようか。
例えばlinux kernelはオブジェクト指向でバリバリ作ってると思われてんのかね？ ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題 ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ
ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない
ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物
ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常軌を逸してる
ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪 オブジェクト指向って何ですか？
C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？ X11やMS Windowsもｵﾌﾞｼﾞｪｸﾄ指向で設計されてる
ただ、低学歴知恵遅れでは、C言語でそれを実現することはできない
そしてそれを簡単に実現できる言語を使うと
なにが便利であるか核心的な部分が理解できずに使って
別のろくでもない問題をおこすわけ ﾊﾝﾄﾞﾗやｺﾝﾃｷｽﾄつかって
ｵﾌﾞｼﾞｪｸﾄを操作するのはまさしくｵﾌﾞｼﾞｪｸﾄ指向の便利な部分だからな
UNIXのi/oなんかもﾊｰﾄﾞｳｪｱがうまく抽象化されてる
ﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀ使って簡単に読み書きができるからな >>215
> C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？
大変だけどできるよ
作りやすいかどうか、失敗しやすいかどうかだから 結局の所、小規模なものはオブジェクト指向使っても失敗しない
大規模なものは、オブジェクト指向を使うと失敗しにくくなる
って所が重要なんじゃないですかね？
失敗したときにそれがオブジェクト指向的な原因か
構造化的な原因か、なんてことよりよりも 低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
日本では、ITﾄﾞｶﾀは低学歴底辺がなる職業だからな
だいたい程度がしれたﾔﾂﾗが群がってくる
この板みれば分かるとおり う～ん、ここ見てるとオブジェクト指向はクソと言いたくなるね。
何らかの問題を解決したい、もっと便利で問題の発生しない手法は無いだろうかというような要望があって、
それを実現するためにオブジェクト指向なるものが発明されたとすれば、
同じ考えでオブジェクト指向を採用するのも良いだろうけど、
最初からオブジェクト指向ありきはダメなんじゃないの?
なんかさ、なんでも右ならえで無理に採用してるような気がするんだよなあ。
オブジェクト指向に限った話じゃ無いけど、特に日本では。 >>222
お前の書き込みは、オブジェクト指向がクソだということが目的になっていて、
その他の何かが、オブジェクト指向よりも優れているという話になってない >>221
優れた人が優れた道具を使う
それに対抗するために、もっと優れた道具ができたとしても
それだって優れた人が使ったほうがもっと効果が高いわけで
優れてない人が、優れてない道具を使って勝つには
人海戦術しかないんだよね ぜんぜん分かってないわ
刃物は道具でもあるし
人を殺すこともできる >>223
いや、オブジェクト指向をクソだなんて思ってないよ。
むしろ好きな方なんで。
でも、肯定派の人ってありきでしょ。
それは違うかなって。 教育ｺｽﾄはものすごいかかるが
手続き型言語でｵﾌﾞｼﾞｪｸﾄ指向をみっちり体験してから
ｵﾌﾞｼﾞｪｸﾄ指向の教育に移行したほうがいい
この手順踏んだほうが間違いが少ない
そうでないと
ID:csv6kfNU ← ｺｲﾂ
みたいに頭悪いのが大量に量産され続ける >>228
バカにコストかけて教育するのもなんだかなー
バカとハサミは使いよう、というけれど、なかなか良い使いようが見つからんね。 オブジェクト指向のメリットって何？
この問いに今だかつて一人も答えてくれた事は無い
どっか他の文献指差して丸投げとか
逃げと食い下がりを駆使して結局答えないとか >>230
困ったことにどっかの文献ですら
ちゃんと理詰めで仕組みを解説してるものは皆無
完全なオカルトテクノロジー >>230
いびつな答え方するんだがそりゃ間違いなくパーツや責任関係の切り分けからーの作りやすくなるってことやろな
俺は嘘だと思う 色んなサイトでオブジェクト指向の説明してるけど説明が下手すぎねえか？
設計図とか野菜や動物に例えるとか理解してんのかと思うわ
雛形作ってからそこに入力規格を統一したデータをぶち込むって例えでいいだろ オブジェクト指向とは雛形作ってそこに入力規格統一したデータをぶち込むってことだぞ さっぱりわからない
オブジェクト指向のメリットとか特に オブジェクト指向とは関数仕様があってそこに仕様通りの引数渡すことなのね。
すごい、ようやく俺でもオブジェクト指向が理解できた！ >>215
＞オブジェクト指向って何ですか？
オブジェクトを中心に組むこと
クラスベースの言語ならクラス
Cは関数で組むけどC#はクラスで組む
＞C言語では
できる
けどCは向いてない
C#とかJavaとか
最初からOOをサポートしてる言語の方がやりやすい >>230
＞オブジェクト指向のメリット
プログラムの変更コストが下がること >>243
どういう理由で？
オブジェクト単位に分けると仕様が消えるの？ >>245
それって君が想定した変更のときだけだよね？ そうでなければむしろ最強レベルの苦痛を伴う変更になるんだよね？
無意味じゃない？ >>246
想定外の変更があったとしても
オブジェクト単位の方が変更しやすい >>248
別れてるからこそ変更しにくいって状況になったことがない？
経験不足じゃない？ 例えばさヘッダーと内容と記述者と更新日時がある条件を満たしたときに
ヘッダーにある文字列を入れて欲しいと
でもヘッダーは他の全てを知らないので関連するオブジェクト全てに手を入れなければならないと
こういうの想像できないの？
レベル低くね？ >>249
いやいやそれこそ
オブジェクト指向開発での経験不足 >>250
＞ヘッダーと内容と記述者と更新日時
たとえばブログのエントリのように
それらの情報に関連性があるのであれば
ひとつのオブジェクト（クラス）にする
そのオブジェクトは当然関連するデータを知っているので
変更もスムーズにできる
一方オブジェクト指向でない場合には
それらのデータがバラバラになっているから変更しにくい
この場合は疎結合というより高凝集の側面が出ている
オブジェクト指向で正しく組むと高凝集疎結合になる >>252
って変更を各オブジェクトに入れないとできないよね？
c言語だと普通に処理書くだけやで オブジェクト指向は設計思想として好きだけど
オブジェクト思考的パラドックスに陥っている気がする これだけ前もって言っといた方がええやろ
データとメソッドをオブジェクトで綺麗にまとめることを自慢する輩はオブジェクト指向ですらないと データとメソッドをオブジェクトで綺麗にまとめられるのは事実
別に自慢はしてない
オブジェクト指向を勘違いしている人はオブジェクト指向を、
不可能なことを可能にする技術だと勘違いしておいて
不可能なことを可能にしてないと（自分の勘違いを）批判してる
オブジェクト指向は従来のやり方でも可能ではあるが
大変なことをより分かりやすく簡単に実現するための技術 >>253
＞c言語だと普通に処理書くだけ
大規模になると「普通に」って言っても
関連のある変数を探すのが大変になってくる
だからオブジェクト指向の方が変更しやすい オブジェクト指向は大規模開発のために作られた
だが小規模開発で使用しても問題ない 強制的にOOに慣れるためのプログラミングスタイル、ってありませんか？ >>256
> オブジェクト指向を勘違いしている人はオブジェクト指向を、
> 不可能なことを可能にする技術だと勘違いしておいて
> 不可能なことを可能にしてないと（自分の勘違いを）批判してる
こういう意見おなかいっぱい
「OOPのメリットはXXXです」
以外の文章はもういい 流れを追っていくとOOPのメリットはリファクタリングにかかるコストが安いって読めるけど
これじゃあダメなのか？ オブジェクト指向のデメリットが単純にコードの段取りや量が増えて鈍臭いんだから
メリットは必然的にその分作りやすくなるって事に消去法でなるやろ
まあ嘘である >>260
適当に読んだけどええ事書いてるな
そうそう抽象化っていうのはこの位しないとダメよな セッター、ゲッター、プロパティを使わない。
これはカプセル化を強いる抜本的なアプローチだ。
これはDependency Injectionアプローチの実装も必要になるし、
"言え、訊くな"という格言の遵守も必要となる。
おれの居るところ真逆のプロジェクトだ使いまくりでワロタ セッター、ゲッター、プロパティを使うなってのはクラスは全て操作だけで実装しろってことなのかな？ >267
イメージ的にはそうだと思う
ただ操作対象を設定する必要は有るから全く使わないという事では無い
ゲッターセッターの一番の問題点は
それを不用意に使ってしまうとグローバル変数をただ面倒な手順を増やして使うだけになってしまい易いから
不用意に使わないようにする
という訓練の為に
使うな
と言っているのだろう
あくまでオブジェクト指向プログラミングが全くと言って出来ない人向けなんだろう
というよりそう書いて有るけど
オブジェクト指向プログラミングの最大の問題点は
標準教範が存在していない事なんだよなぁ
そのギプスなんたらは教範の一部に成れる可能性が有るかもしれない >>268
納得できる説明なのにおかしな改行で台無し・・・ メタプログラミングが不要な用途だけなら、オブジェクト指向知らなくても組める。
まあいつまでももそれだと、大規模システムの仕事は無理だが。 ゲッターセッターの悪いのは
インタフェースありきの設計の中に
実装上の変数がうっすら見えてきちゃうこと
そんなもんを前提に設計してはならない
実装に対してプログラミングするのではなく
インタフェースに対してプログラミングするのだ
同じ理由で、それを書き易くしたC#のプロパティみたいなもんは糞
池沼の要望に迎合したような糞 >>271
メソッドとプロパティ (setter, getter) は本質的に同じものだよ
オブジェクトのメソッドの大半はオブジェクトの状態を取得または変化させる
（状態を参照しないならそのオブジェクトに持たせる必要はないわけで）
オブジェクトのメソッドのうち、一つの変数を変更するものがsetterで
一つの変数を取得するものがgetter・・・になってることが多いが別にそうする必要はない。
例えば内部変数が配列で要素の0番目を読み書きするsetter/getter
要素の1番目を読み書きするsetter/getterを作っても良い
もちろんsetter/getterではなくメソッドでやっても良い
どちらでも同じことができる。
言い換えると、システムを作るのに、メソッドだけでも実現できるし
プロパティ (setter/getter) だけでも実現できるということ
メソッドとプロパティ (setter/getter) の違いは
UMLのクラス図を書いたことがあればわかる。
UMLのクラス図には操作と属性の両方が存在するんだよ。
なぜか？ それは人間の思考を反映させた結果だから
実装段階の思考ではなくて設計段階の思考ですでに操作と属性が別れてる。
メソッドとプロパティは本質的には同じものでコンピュータから
見れば同じものとして扱えるが、我々は人間なんだ。
人間がそれは操作、それは属性って分類して考えてるから、
それをコードに反映させられる記述能力の高さを求めた結果
メソッドとプロパティができたんだよ
しかたないね。人間だもの > メソッドとプロパティ (setter, getter) は本質的に同じものだよ
> （以下ポエム略）
？？
なぜそれを俺にレスしたのか不明 だが実際にはクラスを半グローバル変数の格納構造体みたいに使って
setter/getterでアクセスして外側から中の実装を多角的に覗くような記述をし
そこに更に継承を使って依存でスパゲティー状態になっちゃうから
ソフトウエアの表現方法としての有効性に疑問を持ち始めた人が現れてきたんじゃないかな >>275
つまり、
× getter/setterが悪い
○ getter/setterの間違った使い方が悪い 刺身にﾀﾝﾎﾟﾎﾟのせてるﾔﾂが
ちゃんとｷﾘｷﾘ働いてるか
その働きぶりをたまに覗きたいことはある
こっちからなにをするということはない >>276
確かに悪い使い方が都市伝説みたいに普及しすぎて、ろくろくまともな開発したことの
無い輩まで頓珍漢なｵﾚｵﾚオブジェクト指向論を吹聴するにいたったブームには参ったが、、
使い方の問題のみならず、そういう表しにくい構造がソフトウエアそのものにあるじゃないかと思う。
非常に表しにくい場合が少なからずあり、小さいサンプルコードの断片で説かれるOOの美しいはずの
メリットは実践で適用の場が乏しいということ >>260
このギプスのサイトに書いてある方法は
すごく制約した方法であり、
いろいろ大変かも知れないけど
守れば副作用の少ないモジュラリティーと
深すぎない階層設計が可能になるかもしれないのはよく分かる。
でも、守るためには強い規律とメンバのスキルと
工数のゆとりが必要だと思った。
つまり、現実にはなかなか難しい話だろうなと。 いや、単純にオブジェクト指向なんてやったって地獄に落ちるだけ
クラスっていうゴミ箱に突っ込んで臭いものに蓋してる状態じゃいつまでたってもバグなんて取れないんだよ
単純にプログラムを
入力→処理→出力
という繰り返しの塊にしなければならない
メソッドを呼ぶたびに状態が変化
するようなもん誰も管理できない オブジェクト指向の解釈が多彩なので、あれだけど
オブジェクトscopeは有効な場面は多々あるんだよな
closureとか部分適用とか ｵﾌﾞｼﾞｪｸﾄ指向でも
詳細化したらﾃﾞｰﾀﾌﾛｰ図に落とせる設計でないと
お話にならない 状態を持ってしまうのがまずい
いや、持つだけなら好きにすればいい
内包してしまうのがまずいと言うのが正確か？ 以前(>>161)にも書いたとおり
ｺﾚ以外方法はない
この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる
①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止
ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる 単純にメソッドの成功条件に内部で持たれているメンバの見えない奴が関わってたりすると最悪
プログラムのどこでそいつが変更されるのかわからん
こういう問題が起きるたびに途方も無い労力を支払うのが単純に無駄
オブジェクト指向を考えた奴はわざと技術者の仕事を作るためにこれを考えたのではないか？
というぐらい一切メリットがない >>284
だからな
お行儀のよいクラス作るほど
その実開発者は地獄を見るんだよ
オブジェクト指向がクソな原因は
簡単で内部に状態を保持することなんだよ 単純な入れ子構造になっているか分かりにくい
ランダムに依存しうるネットワーク構造は管理しにくい
しかもノードインスタンスごとに状態を持っていたり
何の×ゲームだよ 割と真面目にオブジェクト指向は将来的に絶対破滅するという想定で作るといい気がしてきた
上で出てる上手くいく方法とかは「延命措置」とみなして
そう考えたら何かすっきりする そう。1000年後には絶対破滅するという想定で、
今の仕事を全力でやればいい。
今必要なら、必要ってことさ、AHAHAHAHA～ >>260
部分的に構造化プログラミング養成ギプスのような気がする >>283
公開されてるメソッドの呼ばれ方による状態繊維が簡易なレベルならば問題ない
といったところ。
通信ソケットの実装みたいなものはどうしても状態を持つのは仕方ないけど、
でもそれもできる限り小さく持つってのが最近の感覚じゃないかね。
内部に巨大で複雑なオブジェクトをガツガツ作る様なメソッドがある場合は
なんか問題ある気がする。 状態を持つなって言ってるのは関数型の考えから？
常にオブジェクト指向言語の方がメジャーなんだが 昔はgetter/setterを使うべきと言ってたような気がする。
でもその時にそれに疑問を持っていた人達もいたと思うんだ。
結局、クソなのはこういう手法が良いですよという言を真に受けて無理に採用する所じゃね?
このなんとかキブスが自分にぴったりくるなら採用すれば良いし、おかしいと思うなら採用しなくて良い。
オブジェクト指向も一緒でぴったり来てねえのに採用するのは良くないと思う。 グローバル変数をそのまま使うよりは
ゲッターセッターをかぶせた方がマシだけど
使わないにこしたことはないってこと >>294
状態を持つと単純にテストがしにくい
あるクラスにprivateでドキュメントにも記述のないメンバ変数が10個あって
その内包するクラスにもメンバが10個あって・・・なんてプログラムだと
そのクラスの持つ状態は10*10*・・・
みたいに増えていく
完璧にプログラムを制御しようとすると
その全てを把握しなければならない
実際にはそれは不可能なのでオブジェクト指向的に組んだプログラムはそもそもバグっている >>295
あんたは使うべきの意味を理解してないよ
使うべきっていうのは今も一緒。
まずクラスのpublicフィールドを直接読み書きしたらいけないというルールがある。
そしてもう一つ、クラスのインターフェースを頻繁に変更してはいけないというルールがある
この２つのルールにより、publicフィールドを直接読み書きしていて、あとから読み書きに
何かしらの制限を書けたくなったときにgetter/setterに置き換えたらインターフェースが変わってしまう。
例えば obj.foo だったものを obj.getFoo() に書き換えないといけない
だから常にgetter/setterを使いましょうと言われていた
だけど今はプロパティを備えた言語ができた。
プロパティを備えた言語であれば、クラスのpublicフィールドというインターフェースを変えることなく
getter/setterにできるためあえて禁止する理由がなくなった
（obj.foo = 1 とかいて obj.foo に代入してるように見えて実は関数呼び出しになってる）
今はインターフェース（名前）を変えることなく、フィールドからgetter/setterに変更できるので
言われてないだけ。でもこれはプロパティを備えた言語に限った話 んで思うのが
どうもアメリカらしくないなと
あれだけメリットとデメリットと数値化にこだわる国がなんでこんな丼勘定やねんと
オブジェクト指向なんて出回った頃にはもうすでに向こうではプログラミングは
無意味な公共事業の一環になっていたのではないか？
そしてそれにはもはや意味がなくて
できるだけ時間がかかる方法だけが採用されたと >>297
オブジェクトが状態を持つとテストがしにくいからといって
オブジェクトに状態を持たせなかったとしても、
状態を持ってるアプリケーションから状態を消し去ることは不可能なわけで
どこかに状態が存在するので、結局その部分のテストはしにくくなるよ
単にテストしにくい場所が変わるだけの話 >>299
メリットとデメリットにこだわってるから
オブジェクト指向を使ってるのでは？ >>300
まず、それが見えているかどうかが問題
引数から渡す形ならドキュメントに記述を強制できる
さらに同じ引数で実行したらなるべく同じ結果が返って来ることも保証できる
これで気をつけるのはファイルアクセスやDBアクセス、日時、通信などに限定できる
オブジェクト指向は全てのクラスが失敗作であると言える >>302
いや、どんな言語で作ろうが、
アドベンチャーのフラグ管理は大変だよ
関数型言語なんか、実装が不可能なレベル オブジェクト指向を捨てたGO言語を使おうってこと？ 実は倍精度浮動小数点数のインスタンス変数があったら2^64個の状態があるって話だ
もしくは10x10x10と10+10+10がほぼ一緒の値という主張だよ >>297
そんなことない
本格的なオブジェクト指向では
>>260みたいに小さなオブジェクト数にして
状態数も減らして単体テストしやすくする
むしろ関数型で複雑な状態遷移を実装するのは難しい
現にゲーム制作ではぜんぜん関数型が流行ってないからな >>306
何年か前にOOPのそのトレーニングやったけど
今にして思えばおかしなことをしてたなって思う
素直にGO使ったほうがいいよ
今は制約を気にせず非常に楽にコードが書ける
それでいてOOPのころの糞コードからかなり離れている
GOのおかげ GOのtypeは非常に見通しがいい
c/c++のヘッダファイルはなんだったのかと 状態を持たないオブジェクトwww
もはやオブジェクトちゃうやんw何の受け売りやそれw アクセスパターンを限定化する
これを理解出来ないなら
オブジェクト思考プログラミングはし無い方が良い
どういう訳か
凄まじい自信の有る人程解っていない
というのがこの界隈 OOPで良いとされているが一番の間違いは
単機能の小さなクラスを沢山作ること
これはクラス数の爆発を産んでるので一番の害悪
例えば特定のファイルを読むためのクラス
そしてそのインターフェイスとDI用のクラスとテストケース
本当にこれが無駄
内部の状態に依存せず単機能でいいなら関数でつくればいいと気が付いた >>310
不変オブジェクトがあっても別にいい
>>312
＞単機能の小さなクラスを沢山作ること
小さなクラスをたくさん作るからこそ変更しやすくなる
クラスの数を大きくして数を減らしてしまうと
作るときは一見楽に見えても後で変更コストが上がる >>313
それはOOP自体が悪いからそう見えるだけ
クラス数の爆発のほうが本当の害悪
上のトレーニングもクラスをちいさくする良い理由の一つとして
エディタの一画面にはいるから…
クラスが一ファイル内にないといけないその言語の制約だろう
パッケージ内に在ればいい言語に乗り換えよう クラスが小さいと困ることがある
インスタンス変数を２つに絞るのは愚か
確実にクラス設計が困難になる
変数をどこが持つべきかを設計しないといけない
そしてそれが間違っていた場合大規模な再設計とコーディングが必要になる
中程度のクラスにある程度必要とされる変数が入れておく方が開発工数は減る 状態を持たない
そもそもが小さい
ならクラスじゃなくて関数を使え >>313
不変ゆうんは状態を持つから不変なんやぞw
受け売りでイキるのやめときw >>260
改めて書くけどこれはほとんどがもう古いし
本当の意味でOOPの弱点をカバーしてない TCP接続をOOPで書くとして、オブジェクトの外側でTCPの例の状態遷移を気にする必要あるんかいな 不変オブジェクト自体が一つの状態であることは確かだと思うが、語弊がありそうだな。
可換原則的には互換性のある小さなクラスをたくさん作る、が正しいだろうけど、
実際にそれすると、とんでもないバカが現れて瞬時に全壊するのも見たことあるし。
やっぱり一概には言えないと思うわ。 >>316
関数でもいい場合はあるが
クラスにするメリットもある
>>317
それは難癖でしかない
再代入しないことによって
状態変化のデメリットが生じないので問題ない >>319
気にする必要が無いように組んでもいいし組まなくてもいい
でもテストは全状態に対して行わなくてはならない
現状はおそらくそれをやってる奴が少ないのがまずい
ここではさもやるのが当然とばかりに主張はするがそのテスト方法は提案すら挙げられない雑魚 はっきりさせておかないといけないのは
オブジェクト指向と関数型で条件が違う比較をしてるってこと
つまり
「オブジェクト指向で状態を扱う必要がある問題」
VS
「関数型言語で状態を扱わない問題」
という違った問題で比較している
アプリケーションから状態をなくすのは不可能なので
「関数型言語で状態を扱う問題」を解かなければいけないのだが
なぜか状態はすべてなくすことができるんだという間違った前提で
状態がない優しい問題を解いているだけになってる >>323
これはそうだな
状態遷移が複雑なシステムをどう組めばいいか
関数型主義者から具体案を聞いたことがないね おれは関数型主義じゃじゃないけど適切にルール組んでその通りにやればいいだけじゃないか？
関数型はオブジェクト内に状態が隠蔽されてないから
やりやすいだけ Cだと構造体がなければほぼ全部シグネチャーに書きださなければならなかったけど
関数型は関数で組み合わせてあるから楽なんだろうなとは思う オブジェクト指向でもやりようによっては状態の遷移がわかりやすくはかける
fluxとかじゃ状態はイミュータブル
actionを適用したらその都度新しい状態オブジェクトを作ってストアしてる
古い状態は書き換えられずに破棄される 状態が複雑になる場合もなるべく明示した方が嬉しいよねってのが関数型のスタンス
Haskellは状態を持つ部分をモナド型クラスのインスタンス(=型)にするし、ML系は非数値状態を型に持たせて型検査の形で明示する
個人的には基本関数型で組んで、状態が必要不可欠な問題に対しては意味論的に隠蔽されているのが正しいならprivateでそれ以外はミュータビリティと型で制御が妥当かなと
その後でパフォーマンスが必要ならその部分をミュータブルなクラスベースOOPにする >>324
まあ冒頭副作用的な臭いからひっぺがしのモナドが思いつくなこれは オブジェクト指向ってウェブサイトの構築以外でどうやって使うんだ？
phpとかrubyはわかるがjava、c#やらでどういうシステム作れるか教えて poco使ってc++でwebｻｰﾊﾞｰの振る舞い自体を組み込みで書く >>330
＞オブジェクト指向ってウェブサイトの構築以外でどうやって使う
一般的なアプリケーション作成全般
よほど高速な実行速度が要求されるもの以外 >>324
functionalは状態の管理手法じゃないのになに言ってんだ。
functionalは構造の再帰的分割による細分化やリスト処理の宣言的記述に有効であって
状態は必要なければなるたけ持たないほうが良いのはいろはのイ、セオリーだぞ
そして状態遷移は本当に必要ならオブジェクト指向を流用するのではなく
状態をきちんと管理するんだよ。
それをgetter/setterで要らぬところに状態持ち込んでishaだのhasaだの言ってるから
子供にまで後ろ指差されて笑われるんだよ。
言っとくが別にオレはfunctionalﾏﾝｾｰじゃないぜ。 オブジェクト指向はWebよりjavaとかc#のイメージのが強いな
Webのがメジャーな人もいるのか >>334
何言ってんの……？
＞状態は必要なければなるたけ持たないほうが良い
あのね、ビジネスソフトには状態が必要なの！！
いくら関数型が状態を排除するのが理想だからって
ビジネスを道具の方に合わせることはできない
そんなことも分からないんだから嫌になる
これじゃいつまでたっても関数型が普及しないよな
＞状態をきちんと管理する
だからその具体案を聞いたことがないんだって
本当馬鹿じゃないかと思う >>335
Spring, ASP.NET Core >>336
>何言ってんの……？
何言ってるか理解にすら至ってないようだな… システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がおると聞いて >>338
その「何言ってんの？」は
何を言ってるかわからないという意味じゃなくて
お前は何（馬鹿なこと）を言ってるの？って意味だろ
日本語の時点で オブジェクト内部に状態は持たないほうがいいと言うのは当たり前すぐる気がするけどね >>341
そこは「オブジェクト外部に状態を持ったほうが良い」と言わなきゃだめ
状態をなくせるわけじゃないんだから オブジェクト外部に状態持っても、結局そのオブジェクトを包含している上位のオブジェクトがあるので、行き着くところは「アプリケーションオブジェクトの外部に状態を持ったほうが良い」ってならない？
どこでラインを引くかはセンスってことでOK？ 他のオブジェクトの持つ変数を必要とする事自体がおかしい。
必要な引数を渡したら、処理を任せて、必要な値をリターンさえしてもらえればよい。 >>343
そのアプリケーションオブジェクトの外部ってのが
なんのことかわからない。
ファイルに保存のことなのかもしれないが、保存するまでは
総てのデータはアプリケーション内部にあるわけで
結局、仮想的なストレージ（ようするにメモリ）に
保存するしか無いでしょう？ >>345
そうだよ、俺もそう思うのでアプリの外に状態はあり得ないだろうと。
なのでどこかで線引きをしないといけないんだけど、結局それはセンスという便利かつ曖昧なな言葉で片付けられちゃいそう。 >>343
ん？それでテストできるならやれば？
実際は制御不能でしょ？
だから駄目だって言ってんの >>347
んんん？
じゃ、具体的にアプリケーションオブジェクト以下に状態を一切持たなくてどうやって実装するのん？
BrowserでもOfficeでもいいから、一般的なアプリでアプリケーションオブジェクト外部に通信中にファイルオープン済みか否かやなんやらかんやら全ての状態を無理せず実装するエレガントな方法教えて。
一切の状態をアプリに持ってたら駄目だよ。
いくらなんでもこれは反論する自信あるわ。 >>347
分かってると思うけど、今どの画面が表示されてるとか項目の何が選択されてるかも全て状態だからね。
さぁ、エレガントな説明してみて。 いつまでずれた馬鹿な話してんの？
例えば犬クラスがあってポチオブジェクトがあった
そいつに餌を毎日おなじ餌をあげてたけど（戻り値 完食）
ある日半分しか食べなかった（戻り値 半分）
後でわかったけどポチは病気だった
かわいそうなポチ
犬クラス内部に状態があって同じメソッドを使ってても動作変わってるのが厄介だと言ってるんだろ
それがわからないのかなあ？ ポチはたまたま病気だとわかったけど
わからなかったら何で半分しか食べないのかわからない
事前に誰かが餌をやったのかもしれない
失恋でショックだったのかもしれない
気分がたまたまそうじゃなかったとしたら解剖しても理由はわからない
未来のテクノロジーでその時の内部状態を再現した無数のポチを作って条件に分けて
えさやり動作チェックするなんて考えただけでも寒気がする >>350
厄介だけど、どこかのレイヤで病気か否の状態は必要だろ？
それがアプリケーションレイヤよりさらに上なんてのはあり得ない。 ポリモーフィズムは参照先インスタンスに依存するので、それは間接的とはいえ状態そのものやね。 >>353
だから対象オブジェクト内部に値を持たせないで関数のシグネチャーにして渡せと
関数に
病気かどうか
失恋かどうか
気分が悪いかどうか
前食べてからどのぐらい時間がたったか
と餌の量を値として渡せと >>355
そのシグニチャを渡すのは誰？
全ての状態を人間であるユーザーが渡すのん？ >>356
関数を使うものが渡す
その関数は勝手に知らない場所にある値を使わない
同じ値の組を与えたら必ず同じ値を返す >>348
え？誰がそんなこと言ったの？
内部に持ってアクセスできないのが駄目だって何度も言ってるじゃん
関数実行したら出力全部出せよ
同じ引数で実行したら絶対同じ結果を返せ >>357
関数を使う、突き詰めればOfficeのユーザーがどの設定画面のどのタブでどのチェックボックスが有効でどのボタンを押したかを一度に伝えるのん？
俺はそんなことはしてないなぁ。
少なくともどの画面が表示されてて何が選択されてるかはアプリの状態に依存してるわ。 何でモデルとアプリの状態の話を混同してるかがわからない >>358
OKボタン押したら絶対に同じ結果になるのん？？
仮に条件によりOKボタンが押せないなら、それはOKボタンを押せない条件がアプリにあるってことになる。 >>362
普通は分かるけどへんに誤解があるかもなので訂正。
誤 OKボタンを押せない条件
正 OKボタンを押せない状態 >>362
引数は同じなの？
お前さっきから人の話聞いてるのか？ >>362
そもそもお前のアプリって
同じ画像保存してもクリックするたび画像変わるんだろ？
さっさとクビ吊れよ 俺がはなっから言ってるのは、アプリ以下のどこかに状態は必要なはずで、それよりも外に状態を追い出すのは無理があるってことだけ。 >>365
お前のアプリは画像選択もしてないのに突然エロ画像表示するのかw
児ポで捕まっとけw システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がハッスルしちゃっとると聞いてw >>323-324
それな
関数型言語っつうのも所詮そんなもん システム、つまりアプリの状態は少なくともアプリケーションオブジェクト以下が制御してるので、全てのオブジェクトが状態を管理しないってのは無理があるって話。
最初からそう言ってる。 つか関数型餌やりだと餌やり関数から出力される犬は入力された犬のクローンじゃないのか？ >>366
理由は？
outputでstatusも出しゃいいじゃん
ハイ、論破 >>371にどう答えるかでバカのレベルが計れるw
いまのとこ華麗にスルーした>>372がキングやねw >>372
具体的にどんな大多数のアプリがそう実装してるの？
悪魔の証明を避けるにはお前に実証責任があるからね。 >>374
今はおまえがしゃべっていい時間やないで >>375
あ、すんません。
誰が喋っていい時間なのかよく分からないけど黙っときます。 >>376
うむ、おまえは既に名誉バカの称号を持っとるからここに参戦すべきやない
すこしおとなしくしとけ >>374
c言語でグローバル変数使わなかったら他どんな組み方があるの？
引数か戻り値で渡すしかないでしょ？
グローバル変数使用禁止が作法のように語られてたんだから
昔の人は何をするべきかわかってたんだよ OOPは糞かもしれんが
じゃあ何がいいのかと言われたら別に他にこれといってないのが現状 頭悪いﾔﾂにかぎって
うれしがってなんでも継承して抽象化とかいってるからな
ﾎﾓを人間ｸﾗｽから派生するぐらい愚かなことやってる 基本は当たり前すぎて、階層化であり局所化であり
順序回的な「無用な」状態保持は極力回避し組みあわせ回路的・関数的構造にし、、、、
関連はﾈｯﾄワーク構造よりもツリー構造を指向して見通しよくし、
関連性の強い物は近くにおき(遠くのファイルからあちこち継承してクロスファイルでmethod取り込むようなことはせず)、
といった、、、アー効けく茶後期ﾂのための基本セオリー。
その表現技法は言語のパラダイムによって変わるだろう。
問題はオブジェクト指向がそういった基本セオリーに反するような手法として普及してしまったことだよ。 >>382 ひでえ誤字すまん
×「アー効けく茶後期ﾂ」
○「アーキテクチャー構築」 ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない たとえば関数型であれば、クロージャーや部分適用を使うことにより、
クラスをｲﾛｲﾛ作ったり状態instance変数でオブジェクトに特徴をもたせ分けるより
非常にシンプルに表現できるし、
また、解法を関数の段階的 細分化で構成することにより、
内側の回関数は小さくなるにつれ速やかに単純な構造になる上、
(再帰も含めた)関数呼び出しの引数リストと帰り値のスタック階層および局所変数が、
自然と個々の階層の参照する「近くにあるべき」状態を単純な木構増階層のかたちで保持できる。
ちなみに上にも書いたけど俺はfunctinalﾏﾝｾｰじゃないからな。 >>385
俺の周りでは、素人に毛がはえたか分からんような又派遣さんが、
専門学校でインチキ教わったのか知らないが、
そういう薀蓄をたれながら、くそコード量産して要らぬバグ入れて
残業大会やってるよ あえていえば
できるだけ自律的であることが適切で
なおかつそのようにほぼ自律的に振舞うように実装されていれば
内部状態が保持されることは実装として適切
ただし、すべて外部的な要因で翻弄される続けるｵﾌﾞｼﾞｪｸﾄが内部状態を保持することは
適切な理由がないかぎり、できるだけ避けるべきといっていい 問題によってどうしても必要な内部状態というものはあるからな。
そこまでだれも否定はしてない 刺身の上にﾀﾝﾎﾟﾎﾟ乗せる作業なんか
ほっといってもいい
そのｸﾗｽだけでほぼ完結できる > 外部的な要因で翻弄される続けるｵﾌﾞｼﾞｪｸﾄが内部状態を保持する
まぁアンタの言うように避けたようがよさげにも見えるが
ここでふと思い出されるのはコンテクストとかビルダの働き
java.awt.Graphicsみたいなコンテクストオブジェクトをグニグニいじったり
java.lang.StringBuilderのようなビルだオブジェクトをグニグニいじったり
そういうところこそにOOPの楽しみがあるように俺には少し思えるんだ ボタンやチェックボックスがGUIの共通の振る舞いを制御する親クラスがいるのはC++で書かれる前から実装継承するように設計されていた。
一方、普通預金、当座預金、定期預金の共通関数があったとして、預金というスーパークラスを書いているシステムはないぞ。メガバンクの情報系であってもな。 お、キングを抜いた奴がでたでw
今は>>389がバカキングなw 普通はそれってオブジェクト指向エクササイズっていうんだけど
同じ表現だから同じひとなんじゃないかな そいやオブジェクト指向てデザパタとかメジャーなのに肝心のこっちは影が薄いな ﾊﾞｶでも作れる処理は
入力の構造体と出力の構造体を関数に渡す程度で済む処理 >>398
IDEと組み合わせるには相性がよかったのかもね
あと典型的なGUIのパーツであるとか
インスペクトしたときズラズラっと出るのが気持ち良いような物に対しては >>403
確かに浅いな
オブジェクト指向のメリットは全くわからなかった
解説してる内容もそもそもクラスを使う側が構造を知ってないと使えない例で書かれてて笑う キータって参考になる記事あんまりないんだよな。ある程度の知識もっているのが前提になってるし
プログラミング関連で検索すると常に上位でヒットするのが嫌だわ >>402
こういう嘘歴史書いて悦に入っちゃう自称識者のほうがゴリラみたいな底辺コンサルよりずっと始末が悪い ゴリラコンサルの所業
朝礼で歌を歌わせる、挨拶の練習
○○（会社の名前）イズムの継承と言ってブラック労働を肯定する
定期的に変なセミナーに通わされる qiita.comは動機が不明
なぜ頼まれもしないのに不確かな二次情報を書き散らすのか
なぜ頼まれもしないのにノイズをせっせとネットに増やすのか
あれってお金でももらって記事を書いてるのか？
stackoverflow.comは単純
質問者がいて、答えてあげたい人が要る
質問にも回答にも評価がされるようになっており
有益な情報が共有できるようにつくられてる
質問者、回答者、閲覧者の動機がよくわかる stackoverflow で答えてあげたい人と大差ないだろ 教えたがりのクズのくせに答えたあげたいとか言っちゃう気持ち悪さw >>412
書いたことあるけど、昔はもうちょっと面白い場だった。
こんなの面白かったよ、とか試してみた、とか。
今は何かというとポエムやら言う奴が出てきたり、本気でレベル低い人も何番煎じかわからん記事書いたりして、収拾ついてない。
コミュニティとしては死んでいってると思う。 >>412は便所の落書きのアホさ加減が光る書き込み qiitaはメモ帳として結構便利
家で調べて纏めて仕事ですぐ使えるようにする
githubにテンプレートを置いとくと尚良 俺は結構便利だと思ってるけどな
新しいことのとっかかりにしたり
頭の中にない情報を得るのに使ってるわ
まあゴミ記事も多いけど 技術的な事読みたいのにポエムばかり上位にくるqiita そもそもなんでqiita検索しとんねんwアホやろw ほんの少しだけいい記事もある。
今オブジェクト指向に関するポエムが乱立してるのはアホみたいだがな。 qiitaみたいなしょうもない個人の日記帳読んでるﾔﾂいるの 便所の落書きはむしろ健全なんだよ
書くほうも読むほうももうそれは分かってるから
>>417
> 何番煎じかわからん記事
ほんとそれ
検索結果を汚すのはもうやめて…
つべの歌ってみたレベルで悲しい 何か上から目線だけどどこのサイトでもいいから
自分で正しいこと書けばいいんじゃないの？
それで次に言うのは
「ゴミポエムだらけでオレの記事が正しく評価されない」 >>432
結果として自分のブログに戻ったよ、俺は。
まあゴミに埋もれる程度ならその程度の評価だと思うし。 > 自分で正しいこと書けばいいんじゃないの？
何で分かってくれないの…
自分で正しいと思ったことを「書かないで」と言ってる
歌ってみた？歌わんでいい
書いてみた？書かんでいい 全てを分かってるやつが嘘っぱちを自信満々で流すのが厄介 オブジェクト指向とは何で
何が良くて
何が悪くて
そしてどうしたらよかったのかとか
纏められるといいんだけれどもねえ 目的指向というよりも
手段指向というか方法論指向で始終しちゃって
明後日の方向に愚民を導いて
混乱をもたらしたのは
なんともむなしい 日本の失われた20年とちょうど時期が重なる
日本のITの暗黒時代 >>441
手強いよ
さらに誰に金もらってるのか
特定の言語や商品の悪評を流すことを目的としてるから 260はいい記事やったけど402はイマイチやったな。てか全部読んでないけど 邪魔する奴の中に
単純に自分を有利にしておきたいから他人が自分の居るレベルまでこれ無い様に邪魔をする
という奴も居るからな
相対的な位置で報酬は決まるから他人を蹴落とす
というのを息をするようにやる奴がかなり居る
全体が進展するより停滞させて自分だけ有利にしようとする下劣な奴が結構居る
教育を変える必要が有るのに今のままでいい
とか言ってる奴もそういう連中 >>412
stackoverflow.comって初めて知ったわ。
teratailよりいい？ >>448
teratailなんて比較対象にすらならない まさか日本語版とかいうゴミ見てるんじゃないだろうな…まさかな… 英語版なんて読めないよ・・・
コードはなんとなくわかるが質問文が >>444
その時期に書かれたコードでOOPを正しく実践してるものなんて見たこと無い
OOPが悪いのではなくOOPじゃなかったから悪いということになるな 海外でHelp me, Stackoverflow. You’re my only hope.って書かれたTシャツ着たやつ見るくらい >>454
今なら正しくOOPを実践してるコードばかりなの？
そもそも正しいOOPってどんなものなの？
第一デザパタは前の方がさかんに取りざたされていたじゃない。
振り返って今だからこそ分かるんじゃじゃないの？
世に流布していたOOPはくそコードを量産した元になったと。 我々はね、間違うのよ
だいたいのことを間違うの
OOPだから糞コードになったんじゃなくて
OOP関係なく、糞コードにしかならないの
その一点についてすら自覚が無いの main関数から始まるc++はオブジェクト指向か？
（オブジェクト指向をちっとも理解してないものの意見です） >>459
C++はオブジェクト指向（をサポートした）言語だよ
Cと違って継承や多態の機能が標準であるでしょ？
今からふり返ると中途半端な部分もあるけど
ただそのC++を使って書いたコードが
オブジェクト指向らしく書けているかは別の話
OOPとOOA（D）の違い >>458
OOPの弊害について議論して来たのに
「OOP関係なく、糞コードにしかならない」と言われると、
OOPは糞コードの元となる害なかった無関係だと暗にほのめかしているようで
論点をすり替えてずるくごまかされたような印象を受けるよ OOPが原因で糞コードになるんなら
どうすればいいか一目瞭然じゃん
よかったな世界が平和になって 本当はいいものとなる筈だったのに、
ボタンを掛け違えたのか、変な使い方が一人歩きして普及しちゃったというか
なんというか、、、
最近は継承を廃止したり
他のパラダイムも併せた言語がどんどん出てきて
より良い解はいっぱい出て来るでしょう んなもん使い方しだいにきまっとろうが
基本的に依存が込み入る元なので
十分静的に設計し尽くしてよほど律して使用するならともかく
変なテクニックを披露するため乱用したら害だろうな
悲惨だわ 関数型の弊害の話をしたら必然的にオブジェクト指向の弊害の話になると思うの これがオブジェクト指向を吹聴していた者たちの反論か…
科学的工学的有効性のかけらも無い >>469
アアン!?
何ガン飛ばしてんじゃコラァ!
みたいなやり取りばっかだよねｗ >>467
オブジェクト指向と関数型に何の関係があるんだ？ >>472
プログラミングパラダイムという同じ上位概念を持つ
関係があるやろ >>473
その理屈だと、むしろ無関係なもの探す方が難しいなw クソとか言っている人間の方がよっぽど
>科学的工学的有効性のかけらも無い
と思うけど べつにオブジェクト指向の概念は関数で実装しなくてもいいんだよ？
メッセージでもいいしな。 OcamlやF#のようにオブジェクト指向と関数型パラダイムを合わせて持つ言語もあるが、
内容は覚えていないけど本質的・理論的にはこの二つのパラダイムは相反するものだと聞いている。
確かに局所的、ミクロに上手くかかれた関数型の呼び出しは
型クラスのような複合構造の使う余地はもはや無く、自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
相反するのもうなずける話だと思っている。
OcamlやF#は詳しくないがどのレイヤでオブジェクト指向と関数型を使うかが分かれるんじゃないかな
numpyで関数の返り値が気がつくと内部クラスのオブジェクトになってた、みたいな。 >自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
この辺が気になる
オブジェクト指向プログラミングの場合は
クラス内に操作対象(変数)を封じ込めてクラス外からアクセス出来ないようにして
グローバル変数が各所からアクセスされることで無限のアクセスパターンになるというのを避けている
というのが肝なんだと自分は思ってるんだけど
関数プログラミングは難しくてさっぱり且つ入門もまともにやった事ないんだけど
状態なんかを副作用?とか呼んでなるだけ外に出す
という方法で対処する
みたいだそうなんだけど?
その辺どうなんだろうか?
少し上の方にその話になりそうな流れが有って少し期待してたんだけど
違う方向に流れたようで残念だったんだけど >>479
俺の書ける範囲で述べると、
身近な局所変数＞一層外側のブロックの内部変数＞。。。＞大外側の大域変数
というスコープ階層は知ってるよね？
これに加えて関数呼び出しの階層
特に相似的階層構造の再帰で自然に繰り返しの表現（最終的には末尾再帰を
最適化で単純なloopに変換したコードが生成されるのだけれども)
この論理的（≠物理的）関数呼び出し階層構造では、
各階層における引数リストと返り値リストの相似的階層構造が
型クラスとその継承や委譲による階層構造のようなランダムで管理しにくいﾈｯﾄワーク構造としなくても
管理しやすい入れ子のスコープおよびエクステントの階層構造としてメモリ上に構築し自然に
アクセスできるイメージ
これで伝わるかな… >>480
lexical scope・extentと
関数呼び出し階層のネスト・木構造
で複雑なデータ構造の関連性が自然に細分化できる
同時に処理の細分化も速やかにできる
勉強している人にはこれで伝わると思う
型クラスとかアクセサでカプセルかとか継承とか全いらない 関数型というかHaskellのええ所は>>260でいうパーツの切り分けが強制的になる所もあるよな
全てパターンマッチのワンライナーで関数が細かくブツ切りで出来るから後の編集しやすい ただまぁ万能ではなく、
別の弱点(副作用のｱﾙ処理の扱い、学習コスト含む)
もあるので俺はfunctionalﾏﾝｾｰではないけれど 多態性についても文句あんだよねおれは。
あんあもの動的言語ではそもそも意識する必要も無い空気みたいなもの
それを変に応用して話をややこしくして…
まあ別途機会があれば書くかもしれないけれど。
かかないかおもしれない。
あどオブジェクト指向とその変な一時的流行で迷惑したのは
非科学的で誤ったオブジェクト指向論を信条として、それを宗教のように吹いてまわり
周りに強制し、反論すれば非難。でも自分ではたいしたソリューションのためのソフト開発できない
みたいな工程論・方法論者が跋扈して
開発者を煩わせたこと 書籍も全部一色だったし
MSが金出してただろうししゃーない
雑誌社も何の根拠もないのにオブジェクト指向マンセーだったよね
本当に技術を見定める能力があればそれが詐欺であると気づいたんだろうな
多くの人間はそうでは無かった 本当に有効な機能だけ自律して使えば有効な面もあったかもしれないけど
人間てそんなに器用じゃないし
群衆や社会問題って
チコちゃんの言う氷河期からそんなものだったのかもしれない 今でもオブジェクト指向からDNNやAiにステージを移して
同じようなことが続いている でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
ソフトウエアの構造を表現している。そしてすごいスピードでreviseする。
べらぼうな才能と手間と時間をかけてクラスベースOOPでソフトウエアを表現しようとしている
あれは(個人的に好きではないけど)見事だとうなってしまう。
優秀な者が活躍して、採用したパラダイムが茨の道に密だとしてある水準まで力強く構築しようとしていると思う。
翻って上のレスで揚げたような日の本のオブジェクト方法論指向論者は
なんと
プアーなことか
同じOOPでも同列にみなしてはいけないんだろうな ちなみにpythonの言語仕様自体は
涙なくして語れないほどのクソだと俺は思っている
なんか文句あるか？
＿＿_
／ ＼
／ ─ ─ ＼
／ （●） （●） ＼
| （__人__） | ＜かかってこいよ
,.ﾞ-‐- ､ ｀⌒´ ,／ おらー
┌､. / ヽ ー‐ ＜.
ヽ.X､- ､ ,ﾉi ハ
⊂＞'">┐ヽノ〃 / ﾍ
入 ´／/ ﾉ } ,..,.._',.-ｧ
／ ｀ｰ''"´ ,' ｃ〈〈〈っ<
/ __,,..ノ ,ノヽー'"ﾉ
{ ´ / ｀`¨´
/´¨`'''‐､._ ,'＼
∨´ ｀ヽ、 ﾉ ﾞヽ
∨ ヽ _,,..-'" ｀ヽ
∨ 〈-=､.__ }
ヽ、 } ｀`７‐-. /
ヽ ﾘ /′ ノ
/′ , { / ／
{ ! ,ﾉ ,/′
! / / `‐-､
! ,/ ﾞー''' ｰ---'
', /
{ }
ﾞY ｀ヽ､
ﾞｰ--‐' pythonにprivate変数はありません。
pythonにswitch文はありません。
pythonのクラス関数はselfを第一引数に
命名規則は決められたものを守りましょう
インデントはスペース4つ
括弧の書き方でsetになったりdictになったりします
一列の文字数は79文字以内
（一部言語仕様でないのも書いてるけど）利点でもあり欠点でもあるな >>181
まとめると：
Python のオブジェクト指向はクソ >>490
一番クソなのは初期の段階でブロックとlexical scopeを配慮して言語設計しなかったこと
今でも引きずっている ID:LmyRE988
↑なんでこいつすぐポエってしまうん？ >>493
飲んで2chにポエﾑ書くことくらい大目に見なよ >>492
blockは無いし頑なに追加しようとしないけど
lexical scope な言語ではあるだろ
何か勘違いしてるんじゃない？用語の意味わかってる？ >>495
・関数の大外のfile scopeの変数を外部から参照させることが出来ない
classにする必要が無くてもclass objectを作ってclass変数とし無ければならない
・関数の内側は平坦なlocal scopeのみ、また外側の変数は参照のみ、更新できない（かった<3)
・block(てきなもの)がnestしてもscopeがnestしない
したがって関数bodyがでかくなると見えなくて良い遠くの変数を隠せない
>>492
で配慮していないと一言で言おうとしたのは
具体的にはこういった欠点 >>495
モダンな言語なら必ず備えているコードのlexicalな階層構造と
変数のscopeの階層の明確な対応が出来ているとは
とても言いがたい さて、三連休だ、旅行に行ってくるわ。
あばよ、ﾉｼ だから一言blockが無いで良いじゃん
lexical scopeは関係ない
それにpython 3だけで大抵の言語のシェアを上回ってるのに、
未だに2の批判するのも意味分からん >>496
＞>>495
＞・関数の大外のfile scopeの変数を外部から参照させることが出来ない
これ意味分からんかったわ
どういうこと？ >でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
>よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
>ソフトウエアの構造を表現している。
numpy、tensorflowがオブジェクト志向？
そんな気は全くしないんだが、定義が全く違うのかな？ それと pythonでnonlocal や global を使いたくなるケースは
根本的に設計間違ってるから、クソコード撒き散らす前に設計見直した方が良いよ >>501
numpyやtfの中のコードの事だろ
使う側は手続き型で書ける
tfは計算グラフを構築してから実行するから宣言型かもな >>501
そいつはここで気持ちよくポエりたいだけだから
レス返しても有益な情報は得られないよ
ポエ逃げしたいだけの人種だから >>503
まとめると：
・numpy や tf は C/C++ で書かれ内部はオブジェクト指向で設計された
・それらライブラリのAPIを Python は手続き的に利用している
つまりスレ的には、「Pythonのオブジェクト指向はクソ(>>181)」であると、
Python信者が認めたわけだ numpyの中身は知らんがtensorflowのどこがオブジェクト指向？
ホントにコード読んでんのかよ。。
なんか胡散臭い奴しかいねーな。。 >>506
数式を表現するのにオブジェクト指向なんていらん
行列演算したいだけなのにオブジェクト指向なんて強制されたらクソだわ
あ、数式使わないドカタの反論は不要なのでよろしく
ドカタには分からん世界があるんだよ >>508
Python信者からも賛同意見を頂けるとは嬉しい限り
・次世代言語12 Go Rust Swift Kotlin TypeScript
http://mevius.2ch.net/test/read.cgi/tech/1530664695/963/
>> 失礼な！！Python は FORTRAN/COBOL/BASIC に代表される
>> 伝統的な手続き型言語の正当な後継スクリプト言語、
>> 次世代の純粋手続き型言語です
>>
>> 関数型？オブジェクト指向？
>> そんなのは飾りです、偉い人にはそれが分からんのですよ（必死 >>480さんへ
479です
自分は関数型に関しては完全に素人なのでなかなかに難しいです
単純に受けたイメージだとなんか凄くモノリシックに大きくなってしまいそう見えてしまう
関数型って何時もどういう風に制御するのか解らないなぁという感じで
基本的に難しい物なので自分には理解できないという感じなんだろうと思いつつ
今回は状態を通して何か掴めるかな?
と思いましたがそんなに甘くない感じですね
何にしても回答どうもです
関数型ってオブジェクト指向プログラミングシステムより更に難しいそうなのでオブジェクト指向より使える人が増えないような予感がします・・・ >>502
そもそも nonlocal やら global などという
スコープ宣言に限定した予約語が存在するのは
Python が(歴史上、おそらくは)唯一の存在である、
という事実を忘れてやいませんか？
言い換えると、スコープに関して Python2 以前の
新規リリースの時点から「根本的に設計を間違えていた」のがPythonなわけ
で、根本的解決を採用せず、行き当たりばったりに
nonlocal やら golobal といった泥縄式対策を採用したのがPython3 ゴローバルってなんかカッコええやん。
ゴローさん風味が出ててさ。 nonlocalってセンスがウケるなｗ
いっそのことnonglobalも用意したらどうかｗｗｗｗ オブジェクト指向のスレでなんで延々と特定言語の言語実装の話してんの？
バカなの？ OOPの結果としては
クラスライブラリとかは文句なしに使いやすいと思うんだけどね
String, Map, List, Set, Threadなんかは十分使いやすいよね？
その点を否定するやつはさすがにおらんやろ？ やっぱりクラスライブラリは使いやすいよね
文字列をポインタで操作してたCの時代に戻りたくない そうなんよね
その点で見ればOOP大成功に見える
ただ、自前でクラスやクラスライブラリを書けつったときに
とたんにゴミの山になりかねないという >>516
何と比べて？
別に同じ機能の関数あればええで >>516
使いやすいが、そこまで一般的なインターフェイスにするまで
いろんなソフトウェアの歴史があってこそなわけだ。
ユーザー定義でそのレベルのものを用意しようとすると途端に何も進まないか
クソインターフェイスをひたすら強要される現場となる。 クラス単体はオブジェクト指向だけど結局それを使うところでは手続き型にしてしまう。 ならC++のﾒｿｯﾄﾞをすべてｽﾀﾃｨｯｸで書けばいい
そうすればﾒﾝﾊﾞ変数も不要
ｽﾀﾃｨｯｸのﾒｿｯﾄﾞは当然ﾒﾝﾊﾞ変数にはｱｸｾｽできない
手続き型なら、入力の構造体と出力の構造体を関数を別で渡す程度で済むﾊｽﾞ
ｵﾌﾞｼﾞｪｸﾄの状態を常に外側で管理する必要があることになる
MS-WindowsのAPIは
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗをひとつのｵﾌﾞｼﾞｪｸﾄとみなして
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗを経由して操作や設定を行ってる
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗも一つのｵﾌﾞｼﾞｪｸﾄで入力も出力もできるｼﾛﾓﾉになってるからな UNIXｸﾛｰﾝのｼｽﾃﾑ関数にもwriteやreadがある
readやwriteはﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀを経由して
なにかしらに読んだり書いたりする関数だからな
つまりﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀをｵﾌﾞｼﾞｪｸﾄとみなして
読んだり書いたりしてるとみなしてると考えて差し支えない
ｺﾚはC++のようなｵﾌﾞｼﾞｪｸﾄ指向言語で継承して実現できる内容と同じとみなせる オッカムの剃刀の逆を地で行ってるなｗ
オブジェクト指向の何がダメか腑に落ちた気がするよ。ありがとう。 全部スタティックにするってそれ
スタティックおじさんじゃねーか！ >>511
モノリシックに大きくなってしまうという印象は杞憂。
むしろ関数呼び出を一行ずつ言い切りみたいにつらねた宣言的書き方に近づく
リスト = 関数 リスト;
リスト = 関数 関数 リスト;
...
見たいな感じ。
状態は、本当に必要なもの以外は自然に登場してこなくなりその分複雑さを低減できる感じ。
どうしても状態管理が必要な処理は、
副作用の排除された純粋な言語の場合モナドみたいな物を持ち出さなければならないかもしれないが
副作用も許容している言語では、手続き的書き方をして状態を管理する形になると思われ、
どうしても必要な状態管理の煩雑さを関数型パラダイムで根本解決できるとはｵﾚ的にはちょっと考えにくい。
難易度に関して言えば確かに学習コストは若干かかるけど、
いまはJavaやC++にもStreamやfoldなど関数型的なプログラミングのための機能が大急ぎで(かなりあせっている感じ)
取り入れられつつあるのであんまり肩肘張らないで、
ttps://qiita.com/stkdev/items/5c021d4e5d54d56b927c
https://ubiteku.oinker.me/2017/05/08/purpose-of-functional-programming/
といった導入的な情報などを参考にｍ日々の設計・開発の
局所的なコーディング範囲でもいいから使えるとことから使っていけば技術的な視野が広がるんじゃないかと思う。
ちなみに俺はそのサイトとは何の関係もないし、functionalﾏﾝｾｰではない ミドルウェアは天才が書くから天才の好む言語で書く
クライアントコードはアホが書くからアホでも分かる手続き型で書く
開発者の能力に応じて分業可能にした功績はある
だいたい天才とアホが同じ言語使ってたのが頭おかしい発想だった アホはひらがなだけ使え
漢字を使うと他のアホが読めなくなる いやレイヤーや粒度によって向き不向きな言語、パラダイムがあるってだけだろ。
天才とかアホとか関係ねーわ。
まあそういう判断しかできない奴は例外なくアホだろうけれど。 まあ例外なくアホとかいう恥ずかしい書き込みをするような奴は例外なく知的障害者だろうけど。例外なく、なｗ >>516
それらlibraryレイヤははよく練り上げられてまぁ使いやすいと思うよ。
でもよく考えてみてよ、納品を決められ短期間に仕様の策定からQAまでこなさなければならない
アプリケーションソフトウエア開発とそういった長年同じような機能のライブラリが繰り返し作り
直されてきたものは同一に論じることは無理でしょ。
それにレイヤが全然違うじゃない。
下から見れば数百個程度の機械語＞言語の文法レベル＞ｱﾙｺﾞﾘｽﾞﾑのライブラリレベル
＞それらを組み合わせ具体的なあるぴにための処理を折りませたアプリレイヤ＞…
レイヤによって全然特性が違うんだよ。適した表現手段は当然違うと俺は思う。
つまりｱﾙｺﾞﾘｽﾞﾑのライブラリレベルに適した表現手段が必ずしもその上位にある
複雑な応用レベルの表現には適しているとは言いがたいのではないかということ。(ここ伝わりにくいと思う)
これは今でも俺も日々とても悩まされている問題。でもまそれはしｚでんげんしょうみたいなものでしょうがないいんだよ。
誰も悪くないし。
本当に問題は、オブジェクト指向の名の下に非科学的非合理的で変な表現手段が流布し
（一部の人間が意図的に拡散させ）ソフトウエア開発の技術的水神をを後退させ混乱させてしまったこと。
俺はこの一点を問題視しているんだよ。
また飲みながらのポエムで悪いな。 >>533 誤記多いなｽﾏｿ
しｚでんげんしょう → 自然現象
技術的水神 → 技術的水準 >>533
大変申し訳ないが今後一切のポエムは不要ですんで分かってください >>535
そんなことよりポエムでもいいからなんか内容を書けよ
なんかむかついたのかｗ だからねえ、凡人プログラマがいきがってOOを語るなっつーの
それなりに名が売れてる人以外、講釈垂れ禁止にしたいよね そしたら日本にいないぞ
>>540 も >>541 も 論外、対象外だし
おれはそもそもOOの講釈をたれたことは無いので自由だ。 日本人がプログラミングで実績残せないのはなぜだろうと思うけど
(まつもとゆきひろとか神レベルを除く)
講釈垂れは、１億円程度の案件でも沸いてくるんだわ
しかもたいていＦランとか専門卒の地頭の悪さを自認できない語り部
俺のガンダムはさー、とか言い出す小学生と変わらんのよ そういう非論理的揚げ足取り未満のレスが着き始めると
ああ、OOP信者はねた切れなのかあるいは
そもそも何か問題のある人たちだったとつくづく思う 細かいところの揚げ足取りで、議論になり得ないのも底辺の特徴ね
なので2ちゃん５ちゃんみたいな底辺８割の落書きでOOのメリットデメリットが議論できるわけがない
数年前はちょっと期待してたけど そうだけどそれでも決して悪いことではないと思う。
別に理想の場をもとめて誰もきているわけじゃない
しかしその一方、これもひとつの社会の縮図で
そのなかで自分も生きていくことには変わりは無い が、しかしだ。
オブジェクト指向ってのは実はクソだったと思う。
そして講釈をたれて変なオブジェクト指向を吹聴していた奴らはクソだった。
これは変わりない。 新しいものを無条件に礼讃するのはヲタの特徴だからしかたがない
問題なのはそれを実業に持ち込むバカと語り部がいることなんだよ
この業界は敷居が低いからヲタの比率が高くなりがちで、困るのは自己顕示欲が大勢な新しモノ知ってるぞヲタ このスレはレッテル張りばかりで中身のないレスが多いな 日本のIT産業産業全体にいえることじゃん。
いま世界で絶賛ぼろ負け中だけど。
やITに限らない、はば広くぼろ負け中。絶賛衰退中。
OOP現象も同じだと思うんだよ。
純粋な技術的問題じゃないんだよね、社会的問題というか、人の問題というか。
CMMIもISO9000も 俺もこの業界に長くいて新三大嫌悪感があるのが、多重請負、ISOとか監査もの、OOやDIの語り部
どれもこれも欧米被れというか、日本人が背伸びして、品質と生産性を落としてるだけだわ
そういえば技術じゃなくて社会的な問題かもね 腹黒い奴がどう他人を操るかの手法として利用されてきたか側面はあると思う
洩れの周りでの話だけれど、OOPのカプセル化、getter/setter、
継承による(後付の)コード再利用性による開発量削減・コスト低減を社内でうたい始めた奴は
実は自分ではコードは書けず無論設計は出来ず、マネージメントもできず、忖度と口先でしのいできて
くいっぱぐれるまえにJavaの流行を察知して社内OOP論者になり、布教に励み
それが下火になるとCMMI,IPISOの流行にのってQA論者に衣替えした それにさんざだまされてうっかりJava信者になって
いまも問題点に気がつかず変なコード書いてる、あるいは部下や外注さんに強要して
迷惑がられている奴ら多数
これを暗黒時代と言わずしてなんというのだろうか んなこたどうでもいい。
結論
オブジェクト指向はクソだった
都市伝説みたいな迷信だった。
沢山の人がだまされた
以上。 つぎに
関数型はクソだった
って言うｽﾚが建てば一過言あんだけれどもな… OOPに批判的な奴は最初から一定数いたよな
ちょろい奴を操る手法もまあ腹黒いが、批判を無力化する手法の方がもっと腹黒い 俺の会社では語り部は淘汰されたけど、糞コードは負の遺産として急には捨てられなくて困ってる
ロジックをトレースしづらいだけの継承とか、呼び出し順が分かりにくいだけのテンプレートメソッドとか、背伸びしまくりの知ったかぶりOO OOPって、それじゃあ全然ﾀﾞﾒだったかというとそうでもなくて
頑張ればそれを使って(向いてないレイヤ・アプリでも)何とかソフトウエアを構成できたんだよ。
それはgotoを乱用してもがんばれば何とかソフトウエアを構成できたのと実は大差ないことだと
俺は思っているんだけれど。
それが厄介ごとの元。
上手くいかなかったときはOOPの理解が足りないからだとか、
低学歴には無理ｗとか批判されて、
そう、自分ではまともなコードををかけない奴に批判される
一体OOPは何のための手法なんだろうか ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな >>565
手続き型とオブジェクト指向てscopeのもちかたとその応用以外特に差はないよ 低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな
ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ 手続き型言語で取り返しのつかない設計ミスって結構あったんだよ
そういう部分でオブジェクト指向には意味があると思うんだけどな
とりあえずデザパタどおりにしとけば何とかなる的な あんたあちこちで毎日こんなレスばっかかいてるね
いろんな人がいるなこの世には
543 名前：デフォルトの名無しさん[] 投稿日：2018/10/08(月) 00:05:22.29 ID:SHTmPUE+
と低学歴知恵遅れの底辺がいってもな
567 名前：デフォルトの名無しさん[] 投稿日：2018/10/08(月) 01:12:22.52 ID:SHTmPUE+
ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな
569 名前：デフォルトの名無しさん[] 投稿日：2018/10/08(月) 01:14:58.10 ID:SHTmPUE+
低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな
ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ >>571 は ID:SHTmPUE+ 宛
念のため
>>570
デザパタとか言うけどsingletonとか後論されつくしている通り
糞だぞ この必死さ
自己評価だけは高い低学歴知恵遅れで底辺にありがち
低学歴知恵遅れで底辺であるからこそそうであるといえることが、
同様のｻﾝﾌﾟﾙをみるにつけ、最近段々と経験から分かるようになってきた
残念なことにすぐに分かっちゃう 人間が持つ分類の概念が似ているもの、GUIとか、そのサブクラスで違和感なくロジックがdispatchできるものが適用範囲なんじゃね？
欧米人のように、複数のオブジェクトが協調しあうような高度、かつうまく行くようなクラス設計できるようなセンスの持ち主が日本のIT業界に割り当てられるとは思えんし、実際に出くわしたこともない
絵空事のパワポの達人にはよく出くわすけどな >>574
応用レイヤのclass設計で言うと見事と思えるものは海外にはある？ この必死さ
自己評価だけは高い低学歴知恵遅れで底辺にありがち
低学歴知恵遅れで底辺であるからこそそうであるといえることが、
同様のｻﾝﾌﾟﾙをみるにつけ、最近段々と経験から分かるようになってきた
残念なことにすぐに分かっちゃう 低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな
ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな >>576
オープンじゃないけど時価配信でObserverパターンになってるのはよく見るな
GUIだとDelphiだね、古いけど基本は同じだろう ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題 ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ
ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない
ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物
ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常軌を逸してる
ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪 だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる >>584
お前さんの今までのレスをコピペして遊んでいただけだよ ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない ID:B/yxkRYZ
ID:j/6nk0eH
ID:cRG95Xcq
ID:Kxio7RVg
ID:pq96CSzd
ID:k5h2WtG4
ID:IuTgmxg/
ID:R8M7QKDK
ID:mIq+f5AO
ID:SHTmPUE+
このｽﾚのｵﾚのﾚｽはｺﾚがすべてだ
ｵﾏｴみたいな内容のない低学歴知恵遅れと違って
たくさん有益なﾚｽをしてる
低学歴知恵遅れには理解できないし読めないのはわかる
知能に著しい欠陥があるからな 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる >>590
乙。暇だね。
これはあくまで親心で申し上げるが、頭の病院いったほうがいいレベルですよ。 ﾊﾞｶは自分がﾊﾞｶであることに気づけないからな
ｷﾁｶﾞｲには健常者がｷﾁｶﾞｲにみえるのと同じ いやなら別に病院に行かないでそのままひとり病んでてもいいけど
他人にはつくづく迷惑かけないようにね ﾊﾞｶは自分がﾊﾞｶであることに気づけない
つまりﾊﾞｶは一生治らない
まずﾊﾞｶはﾊﾞｶの自覚をもつことができない つかこんなにレスしてたんだ
ぱっとみノイズレスだと思って読んでなかった 病んでるのは間違いなくｵﾏｴだからな
低学歴知恵遅れで底辺になると発症する病気にかかってる まあｵﾏｴはｵﾂﾑの病院へいったほうがいいわ
ｵﾂﾑが壊れてる
間違いなく軽度の知的障害がある つーかいい子だからもうオナニーでもしてネナヨ
おじさんは忙しいんだから クラス単体のプログラムが出来るのは利点だと思う。
そのクラス同士のまとめが難しい ID:5FzXpRZO大発狂しちゃってるやん…
応酬見てると半角のほうがまだまともに見えてくる件ｗ
>>574
みたいに人種に原因を求めるのは実は面白いと思う
本人たちが従ってる働き方に既に問題があって
そこに疑問を持たないしどうしようとも考えない
足並みそろえて稲植えてたら収穫できるって発想
たがいの独立性や多様性をベースとした協調
直交性のあるもんを組み合わせるという日常
ってのはやっぱあちらさんに向いてるんだろうね 自由で独立した人間は因果関係に縛られないんだぜ
原因はこれだから結果は必ずこうなるとか思ってない 思い込みではなく分類
因果関係に逆らえないのはモノや動物のように扱われる
それ以外が人間 思い込みではなく分類というのは話が噛み合ってない
そういう分類があるという思い込みなんだから
思い込み or 根拠がある という話なんだから、
思い込みじゃないなら根拠を示すべき >>607
それはお前の思いこみだな
こんな糞レスへの反論なんてこれで十分なんじゃね？ いや、こういうのでいいんだよ
分類に根拠がないという意見と、OOPに根拠がないという意見は似ている >>611
だから分類の話はしてない。
> 自由で独立した人間は因果関係に縛られないんだぜ
> 原因はこれだから結果は必ずこうなるとか思ってない
↑これが思い込みだって話をしている どや？ 話をずらそうとしても、毎回戻されるのって苦痛やろう？ｗｗｗ 半角さんは逃げてこんなスレでも足りない知識でドヤしてるんだwww GUIみたいに誰もが抽象化のイメージがわきやすいクラスと、Webフレームワークのような、使う人が継承して使えばなんとなく便利なクラスでは、抽象化のやりかたそのものが学問になりそうだよな
一般人はおとなしく継承したクラスの中に、業務ロジックを構造化プログラミングしてなさいってこった >>617
GUIの座標とか描画とか、共通関数にするよりもスーパークラスに持たせた方が共通処理と分岐処理が別れて、分岐判断の引数とか減るだろ？
別にオブジェクト志向言語じゃなくても構造体でも出来るし、事実、WindowsだってCで書かれてるけどな >>618
いや別に分岐が必要な仕様じゃないんだけど >>619
分岐が必要な仕様じゃないってことは、
分岐が必要な仕様の場合は？ >>622
なんで不分岐が必要ない仕様とか言い出したの？
自分が都合がいい例にしたかった？ｗ >>623
いや、テメーで勝手に分岐が必要なブッサイクなクラス作っておいて
それはないなと
それにクラス構造で分岐しないでくんない？
読み辛い
はっきり言ってクソ
仕様書にどんな条件で分岐してるのか書きにくい
控えめに言って死ね >>623
こういう奴がパラダイムの違いを理解しないまま書くからOOPが害悪になるんだよな windowsでは普通にｲﾍﾞﾝﾄ分岐処理でもswitch文使う
それを隠蔽化するために仮想関数にして実現するどうかは作るﾔﾂのｾﾝｽで決まる >>626
それすげーやめてほしい
こっちはテメーが作ったただでさえうんこみたいな設計書に
そう書いてあるから見に行ったのに
そのとおり作ってないとか設計書ゴミ箱に捨てんぞ糞が いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。Windowsの低レベルプログラムは。 >>628
> いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。
オブジェクト指向で作らないからそうなる MFCのメッセージマップは嫌いだった。
switchのほうが100倍分かりやすい。 MFCが出てくる前は、Cでゴリゴリ書いてたのよ
MFCが曲者っつー話はさておき、
Cでクライアントプログラムを書くわけだが、Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる >>626
＞windowsでは普通にｲﾍﾞﾝﾄ分岐処理でもswitch文使う
pedzold では終始一貫して switch なのは、ちょっとどうかな、と当時でさえ思っていました
＞それを隠蔽化するために仮想関数にして実現するどうかは作るﾔﾂのｾﾝｽで決まる
今思うに、これは悪手なのではないかと >>631
＞Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる
それ、今でもよくわからないですね
::RegisterClass() ってコンストラクタに該当するのですか？なぜ ::CreateWindow() とは別に定義したのでしょうか？私はこの二つはラッピングしちゃってます… WindowsをCで書くわけにはいまさら中々いかないだろう。
かといってgcのある言語やインタプリタのようにアプリ寄りの言語で書くのは不可能だろ。
そうやってnative codeを出せかつOSの記述も(苦労するが何とか)記述可能な言語は
消去法でC++しかなくなる。DとかRustじゃ無理。
また、Windowsと言う位だから、上位には何らかのOOP GUI IFを提供しなければならない。
別にC++のOOP機能が優れていたからWindowsがC++が記述されたわけではない。
ここ勘違いしないように。 WindowsがOOそのものの思想、と言うのはハンドルまみれなAPI群があるので素直に同意できないけど、ウィンドウ周りは多少は頑張った感あるよね。
>>633
ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時にメモリが節約できるというメリットがあるかと。 シグナルが何とかならないかと思うけど
atomとかもう使いたくない >>526さんへ
示された所じゃなくて
その下に有ったリンク先を読んで解った事が有った
https://qiita.com/hiruberuto/items/26a813ab2b188ca39019
読んでいて何が自分に難しいのか?
関数型の場合
処理対象全域を考えて関数で並ぶように作らないといけない
副作用やその他の物を一時に頭に入れて整理し無いといけない
(リンク先にはそうではないと書かれているが自分にはそう見える)
けどオブジェクト指向の場合
対象となる処理を分割して個々に作っていく
分割して個々に作っていった物を連携させて
最終的にはその集合体が出来上がれば機能する
という方が自分に向いている
頭が悪い人間と言うのは広く色んな要素が一編に出て来る物の状態を正確に把握して
それを組み立てる
というのが苦手なのよ
関数型プログラミングは間違いなく
使える人が限られる
そういう物になるだろあなぁ
でもc++なんかでも標準ライブラリーに既にそれっぽいのが有るから
使える程度には理解しないといけなくなるんだろうねぇ
その程度ならなんとかなるかなぁ(笑)
何にしても参考になりました >>637
バカじゃん
テメー以外の奴が作ったときに
privateにされたらそれでしめーだろーが
そういう当たり前の想像力が欠落してるからテメーは何考えても
ダメダメのうんこちゃんなんだよ メソッド呼ぶたびにクソクラスの内部のウンコがどうなってるのか
ケツアナほじって掻き出さなきゃいけねーんだよ 標準ライブラリのprivateメソッドとか
もうソースコード読みまくりだからな >>635
＞ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時に
同じウィンドウクラスを使いまわすっていうのが、そういうことをやる機会があるかどうか、という点でいまいち、なんです
つまり現状のウインドウクラスにてウィンドウプロシージャを設定する、というのが疑問でして、ウィンドウプロシージャが ::CreateWindow() の引数だったら、使いまわす、ってことも検討したかもしれませんが >>637
foreach, map, reduce, filter などを使うことによって、
for ループやif分岐や一時変数を使う助長で古典的な書き方から脱却し
リストの要素間の多対応・変換を宣言的に記述し切っていく、
既存言語に拡張されつつある関数プログラミングパラダイムの
限定的でも美味しいとこ取り的な使い方からはじめても全然いいんジャマイカ あと、詳しく書くと長くなるので一言ずつ書くと
繰り返しではなく末尾再帰を使えるところでは活用する
クラスを設けて多様性をあらわすのではなく、クロージャーや部分適用で簡潔に表現する
遅延評価や関数変換を使って有効なところで使う
とか 関数型とオブジェクト指向は実は相性がよくて、
オブジェクト指向でオブジェクトとしての構造を
そしてオブジェクト指向の中で使う関数は関数型と
組み合わせて使うのが最強なんだ >>644
だからそれはレイヤやグレインの観点から上手くいかないんじゃないかって
上で書いたのに。
上手くいく方法があったら披露してよ 末尾再帰の話が出てきたから、知識の浅い人に説明しておくと
関数型は再帰で実装するから手続き型のループを使う方法よりも遅いという常識を
特定の条件を満たしている場合にループに変換することで、遅くならない
というもの。決してループよりも速くなるわけではない >>645
何ができたらうまくいくってことになるんだ？
俺にとっては開発が楽になることがうまくいくことだ
楽になってるのでうまくいっている >>644
あとcontinuationとかyieldとか使うと幸せになることがたまにあるぜよ >>647
何の言語で何をどう作ってんだか知らないが
上手く言っているなら方法論を披露プリーズ >>650
方法論ってなにがほしいのか知らんが、
関数型言語で作ったライブラリは状態を持たないから
汎用的な関数ライブラリになる。
それを便利にオブジェクトで使用する オブジェクト指向のメリットは説明できたかい？
定期的に貼らないと関係ないこと主張する奴がわくからな
これが説明できないならクソ オブジェクト指向のメリットは状態を
簡潔にわかりやすく持たせることができる
アルゴリズムならともかくシステムから
状態をなくすのは不可能なので
それをどれだけ直感的に扱うか不可欠になる
それが関数型に対するオブジェクト指向のメリット OOPのメリットを教えてくれる奴なんていくらでもいたよな
それでOOPが普及して
ふと気付いたらメリットが何だったのか思い出せない
ここでまたメリットを教えられても無限にループするだけだ >>656
そう。3歳の子供でも、リンゴとミカンの色や形
犬や猫の鳴き声の違いぐらいわかるだろう。
それぐれいオブジェクト指向は人間の思考と一致している 型クラス、クラスscope、オブジェクトscope,
同じ名前の多態(振る舞いの違い)、
継承によるあっちこっちに無難格納したソースファイルの
似たmethon部分の短冊のような共有による依存性のジャングル
これらについて理論的、科学的に有効性を述べないとだめだよ そう、そしてそれらがある程度規模の大きく複雑な
アプリケーションレイヤのソフトウエアの構造表現として
どう有効なのか理論的、科学的に述べないと… 確実にメリットがあるなら人には教えないで独占する
それが理論的で合理的
確実ではないギャンブルなら人に教える ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな たまに見るけど100%でない=0%の人の思考はどうなってんだろうね 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる 1bit思考の中で最悪なのは、需要と供給
買う方が100%自己責任と思ってるから売ってる側は罪悪感0 その論点から起こしてだね、
オブジェクト指向の有効性を非論理的、寝技的に布教しようとするのは
いくらなんでももう、無理があるよ ここの議論でもそうだけどカプセル化とかインターフェイスに対するプログラミングとか
ここの要素について話すのは意味があるが
「オブジェクト指向」って言葉でまとめると途端にクソ議論になる。
その意味ではやっぱり失敗だろう。 >>672
その辺はポジティブな意味合いが強いからな
ただメリットがあるからってデメリットがどうなるかは別問題として カプセル化とかは「学習コスト」だから100%ネガティブ
コストを消費する代わりに何かメリットがないとポジティブどころか中立にもならねえ 今になって思うのは、オブジェクト指向にまつわる説明で特徴的な何々は何々であるだから何々があるはずだ的な事は製作者側の考え方の根本だったんだろうな。
ここに共感してないから触ってても疑問がつきまとう。
それでもってこういう考え方をする奴は布教的な奴が多い。こういう奴らは本当本当に嫌いだわ。人のその後に対する考えなんてみじんも無い。
例えばウェブ上で人気の言語的なランキングで上位に入ってる言語と周りを見渡して実際触られる言語の食い違いがひどい。
他の奴の意見見てると大体同じ感覚で変な笑いがでる。 オブジェクト指向の宗教的側面と、Rubyの宗教的側面がかけ合わさって
ドン引きするレベルの狂信者が出現した
もはや言語は死につつあるのに狂信者は毎日板を荒らし回ってる >>674
学習コストはなんにでも適用できる
一般的すぎて無視できる
プログラムを作るにはカロリーを消費すると
言うようなもの、そらそうだで終わり カプセル化してしてデータを閉じ込めることこそ
オブジェクト指向の真髄、データに対する責務を
集約する事でプログラムを作りやすく堅牢で
メンテナンスしやすくできる >>678
コストがあるから見返りにメリットが必要だったんだが
コストを無視するならもうメリットがあってもなくてもいいぞ >>680
一般論過ぎてオブジェクト指向の話になってないやん 赤信号なら止まると良いぞと言ってるようなもの
当たり前やん オブジェクト指向テクニックを使うと外から壊されにくい
堅牢なデータ構造を作ることができてプログラムの
完全性を保証できる、オブジェクトを組み合わせて
より大きなプログラムを作れるっていうのが
オブジェクト指向のメリット 当たり前すぎるってあれだよな
反証不可能ってやつ
反証したい勢力と対立煽りするくらいがちょうどいいんだよな データ隠蔽が有害っていうのは嘘だ
データは隠してなんぼ、オブジェクトを使う側に
データの存在を意識させないようにする事で堅牢な
プログラムを構築できる 大規模開発はオブジェクト志向が、
とか喧伝する低偏差値信者もおとなしくなり、
一歩下がって、そんなに良いものだったっけ？と振り帰られる雰囲気がでてきたのは良いこと
いつまでも熱狂信者の思惑通りにはいかないよ
時がたてば、本当にコストペイするものだけが生き残る >>685
テストもできないのが不味い
結局使用する側が状態を意識しなくてもいい造りなら問題はおきない
でもinitメソッド連発で呼ばれると死ぬだろ現実
initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ
ってのが呼ぶ側の主張 >>687
> でもinitメソッド連発で呼ばれると死ぬだろ現実
> initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ
どんな場合でも初期状態に移行すればいいだけでは？ >>691
別スレッドでアクセスさせなければいいだけ >>690
でも実際はハードに近い部分のinitだったりするとそうはいかないケースがあるよね？
って可能性が想定できないなら君は設計を語るレベルにないんじゃない？ >>694
自分の都合がいい条件じゃないと当てはまらないと
認めているようなもんじゃないかｗ >>695
いやいや、この場合そういうケースがあることを説明できればいいよね >>696
じゃあそういうケース以外には当てはまらないってことでいいよね
例外中の例外なんてどうでもいいわ メソッド呼ぶほうが呼び出し順にナーバスな設計というのが糞
内部を隠蔽できてねーやんというだけのこと >>697
問題はオブジェクトが状態を内包しちゃってることなんだけど？ んでそれを踏まえて
お前のクソクラスは息してんの？
って話
レアケースだから死ぬわってお前
言ってるように聞こえるけど
バカなん？ >>689
うるせぇエビフライぶつけんぞ
,.、,､,..,､､.,､,､､..,_ ／i
;’｀;、､:、. .｀ﾞ:.:ﾞ｀’’’:,’.´ -‐i
‘、;: …: ,:. :.、..; .;;.‐’゛￣ ￣
ヽ(´･ω･)ﾉ
| /
UU >>700
オブジェクトが状態を内包するか
オブジェクトの外に状態を置くかの違いでしか無いですね >>703
だからその一点でクソだって言い続けてるじゃん
カプセル化がどうとかバカの妄想だろ
テメーの状態がわからねーのが一番のリスクなんだよ
何がカプセル化だよ
早く死ねよ localなデータを局所に隠蔽するべきなのはソフトウエア工学上、
当然のことでカプセル化の専売特許ではない。
ほぼすべての最近の言語はlocal scopeを持っている。
だがオブジェクト指向のカプセル化によるデータの内包とアクセサは
他の言語の持つモダンな階層的scopeに管理工学的にはるかに劣る。
ここ勘違いしないように。 まあ、forループの回数カウンタなんかローカルで充分だしな。 >>704
ようするにテストはプライベート変数を見たいってだけですよね？
テスト以外では必要ないですよね
カプセル化バンザイですよね？ どれくらいのアクセス度がいいかはそのクラスのそれぞれによるところはある。
STLのvectorなんて見方によってはかなりオープンだけれどあれはあれで適切な開け方。 内部の状態が心配なら
ちゃんとｸﾗｽに内部の状態を（ｺﾝﾎﾟｼﾞｼｮﾝなら当然再帰的に）ﾀﾞﾝﾌﾟする関数ぐらいつけてんだろうな
つけてないならお話にならない
外部で状態を管理して
外部で構造体を監視するのと
そう変わらない >>710
テストだけではないな
その関数が同一の結果を返す条件を固定したい
っていうかできねープログラムなんてぶっちゃけクソもいいとこだろ 仕事関係なく趣味でソフト作ったやつの意見は尊重できる。仕事だけで横文字多様してる奴のはフィルター推奨だな。 本当にそれは状態として動的に管理すべき対象なのか
十分吟味してないだろ >>716
ん？
じゃあ、クソインスタンスがどんな状態でメソッドを呼んでも絶対同じ結果返すんだな？
その時点でメンバ変数いらねーけど >>717
日本語読めるようになってからレスした方が良いよ >>713
お前は現在時刻を返す関数は一生使うなよ
クソなんだろ？ Haskellでいう副作用なら標準入出力、ファイルio、時間、ランダムなどが副作用なるな
モナド並にリッチなシステムをオブジェクト指向で組んで副作用を過敏排除するなら楽しそうやんけ >>713
> その関数が同一の結果を返す条件を固定したい
引数Aにaを入れる、引数Bにbを入れる、引数Cにcを入れる
引数A、B、Cで関数funcを呼び出す
メソッドAでaを入れる、メソッドBでbを入れる、メソッドCでcを入れる
メソッドfuncを呼び出す
関数の引数に値を入れる代わりにオブジェクトに入れるだけの違いでしか無い >>719
現在時刻しか返ってこねーだろ？
テメーのは指定してもいないのにサマータイム返すクソだろ >>721
でも入力値は使用する側が意図的に入れるものだけど
メンバ変数は何になっているかわからない
この差がデカイ >>713
>その関数が同一の結果を返す条件を固定したい
同じ条件で違う結果が返ってくる関数ってハードウェア乱数発生器とかしか思い浮かばないんだけど、具体的にこんな関数ってのある？ >>714
結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。
簡単な事を冗長的にフレームワークのようにしたコードが多くてただの社内での点数稼ぎなんだろうと伝わってくる。そして少し環境を変えてシステムを構築し直す時に問題が出て来るのって大抵そういうコードだったりする。 >>723
> でも入力値は使用する側が意図的に入れるものだけど
> メンバ変数は何になっているかわからない
変数に文字列入れたって、それがどういうフォーマットで入っているかなんてわからんだろ
文字コードは何なのか、内部エンコーディングなのか
文字列の最初に文字列長情報がついているのか
文字の終わりは\0なのか
変数に数値入れたって、それがどういうフォーマットで
入っているかなんてわからんだろ
32bitで保存されているのか、64bitなのか
変数に入れようがメソッド呼び出そうが
ある一定の手順の操作を行えば、それで状態は確定するんだよ >>725
> 結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。
あぁ、プロの将棋を素人が見ても、凄さを理解できないのと同じだな
んで、何やってるか理解できないから、直すこともできない 凄さを理解されなくても半分諦めてるプロって
ラノベ主人公でよくあるやつじゃん 素人とプラグラマーに根本的な差を感じてる奴はちょっと怪しいな。 素人だからこそ言い切れる。プログラミングって9割はツールを使いこなせるでしか無いよ。
将棋に関してもたぶん君は将棋について詳しくない人だと思うな。 ま、分かったじゃあそう思っとけ。このご時世どんなに賢ぶってもそんなに凄いプログラマーが日本に溢れてないのが透けて見えてるんだけどな。 俺もオブジェクト指向を中途半端にかじった中途半端な優等生が、
これ見よがしに作った自社製フレームワーク(全然便利ではない)しか
見たことないわ
作ったのは一流大卒の大手ベンダーの開発推進チームなんだが、
日本人ってその程度だと思うよ
Stringクラスって便利ー！ぐらいのほうが幸せになれるぞ 中途半端な優等生の成果物がその程度なんだから、
三流大卒のおまいらの成果物なんて推して知るべくだよな プログラミングセンスと学力ランキングは比例しないんだよなぁ むしろ個人の性格の方がそのまんま実装に現れて来るからな。 学力ランキングを批判するだけなら良いぞ
だが、学力の対案は性格っていうのがダメだ
おかしな対案を出すより何も出さない方がマシ >>736
分かる必要がないよね。
どうせ関数型だって内部メモリの構造なんてわからないんだから >>733
大手企業のフレームワークは派遣さんがアホなことをしないようにあえて機能を制限してる
生産性が多少犠牲になっても非常識な派遣さんがやらかしてしまうリスクを減らすことが重要と考えたんだね
そういう意味ではオブジェクト指向の基本であるカプセル化は非常に役に立っていると言える >>741
なら派遣を使うことがリスクなのでそれをやめればいいと思います。
本当のリスクは・・・無理なコスト削減なのでは？
コスト削減のために、無駄なコストをかける。
うーん、馬鹿なのでしょうね 既存のフレームワークにケチつけたい人は
それ以上のものを作れる人なの？
それとも、作れないし作ったことも無いけどケチつけたい人なの？
煽りじゃなくて純粋な疑問
ぜひ、小学生のような瞳をしてそっと教えて欲しい それを教えないのが正義っていうのが情報隠蔽、カプセル化 >>742
派遣さんを切ったら中抜きで稼いでる人達が困る
派遣さんは使う、でもバカな真似はやらせたくない
このバランスが大事 最近は中抜きはまだまともな行為だと思えてきた。
バカがクソみたいな意見押し通してくるよりマシだ。
そういう意味でベイシックインカム賛成。 >>747
結局、中抜きで困るからっていうのが本当の理由なのね（笑） >>740
え？グローバル変数使わなければ戻り値か引数が全てだけど？ んじゃクロージャ出たから
オブジェクト指向で末端の人、要は上の誰かが作った仕組みやクラス使って自分はそこからオブジェクト弄るだけの人は可能な限りクロージャ使いまくった方がと思うんだよな
よく委譲処理でこのふたつどちらか選ぶ事あると思うんだが末端なら即クロージャ >>714
仕事は範囲が限られているからね
その仕事でやらなければならない範囲だけ出来れば
後は何が出来ようが出来まいが関係なくなるからね
一言で言えば視野が狭い
横文字を多用する人は狭い世界で通じてそれでokになっちゃってる
多種ではないし世界が兎に角狭い
実際ゲームなんかでは敵クラスを作って敵が増えるたびにオブジェクトを生成する
ってやると感覚的に凄く簡単 >>752
どんな話題が面白いの？
このスレ的にはオブジェクト指向のメリットが説明できなければ
終わりなんだけど 逆でしょ？説明されれば終わりなのがいやだから
答えが出てるのに、同じことをくり返し聞く >>756
え？メリット出てる？
見たことないよ
毎回、バカが長文書くだけで
品質向上なのか工数削減なのか、それが起こるロジックが全くの謎 犬がワン、猫がニャン
→なにそれ美味しいの？
大規模じゃないとメリット説明しにくいよ
→説明できないって、大規模なプログラムを経験して体で覚えろと？
要するに、簡単には説明できないよ
→だったら学習コストとの天秤では？
俺の中ではこんな感じ 品質向上だし工数削減にもなる
馬鹿はそこでなぜか品質向上と工数削減のために
追加作業が増えるとダメだと話を聞かない >>753
関数ポインタと汎用のvoidポインタ渡すインターフェイスより明らかに良いとは思うけど、
ガベコレない言語では上手くいかんだろ。
その場合は継承させるしかないっていうc++の選択は間違いじゃない。 ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない だいたいわかる
低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる >>762
全く解消されてないだろ。。
キャプチャーしてる変数の寿命を考慮してなきゃならんし、こんなん使わねーわ。 型の問題と寿命の問題を分離しない
OSとGUIを分離しない
フルスタックな環境を作る密結合指向って感じ >>769
その設計にオブジェクト指向が関与していると疑われている
その問題の解決にオブジェクト指向は全く寄与しない、と宣言すれば疑いは晴れる >>770
いや、どう見ても設計の機能分けの問題
オブジェクト指向の前にレイヤーってあんだろ？ オブジェクト指向信者もDI信者も同じ臭いがするね
【Java】DIコンテナって本当に便利か？
http://mevius.5ch.net/test/read.cgi/tech/1219242206/
次は何を担ぐのやら
外国で流行って育っていくのだから、それなりのメリットはあるんだろうけど、なぜか仕事では恩恵にあずかったことはない 設計のセンスの無い奴はどんな流行が来たって糞な設計しか出来ないんだよなぁ
センスがある奴はなんとなくどんな流行のスタイルでもこなして来るからなぁ どーでもいーけどコーディングの事設計てゆーのいーかげん恥ずかしくね？w は？
設計はコーディングじゃねーよw
四角い箱描いて矢印や電線で繋げて遊ぶ奴だぞ。 ある一定以下に対して理解できるような教範が出てこない
だから一部の人しか使えないようになってる
結局は出来る人の間で持て囃されるだけになってしまう
この何か新しいやり方を創造するのと一般に使えるようにする
というのは本来両輪なんだけど
普通以下の人達が使えるようになる教範を作る
というのはかなり難しい上に
それをやる人には余りメリットがないから
なかなか出てこない
だから
オブジェクト指向プログラミングにしても
関数型プログラミングにしてもその他の技術にしても
広く(普通程度以下)使われるのは難しいし
このスレのタイトルみたいな感想を持つしかなくなる
後は自分が出来るけど他の人が出来ないままのほうが出来る人には得だから妨害する
みたいなのが居るくらいだろうかねぇ あー電線繋げては遊ばないわ、危ないしw
点線の間違いだわ。 >>772
DIはほんと便利
めちゃくちゃ開発が楽になった 少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない 少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない 日銀短観のDIは便利
池沼あげのDIはtraitsなみにｳﾝｺくさい 今時DIも使いこなせない人材とか組織にとってのリスクでしか無いよ
あっちこっち結合しまくったクソコードを社内リポジトリにばらまくとか悪夢そのものじゃん DI使っても結合しまくったくそコードはくそのままだ
業務分析の時点でコケて役割分担がぐちゃぐちゃなんだからDI導入したって解決しない >>785
DIを使わないから業務分析の時点でコケて役割分担がぐちゃぐちゃになるのでは？
設計者にDIを学習させてDIを使う前提で設計させればそのあたりの分担がキレイになるように意識して設計するようになるよ cのたくさんの構造体にいっぱい変数や関数ﾎﾟｲﾝﾀもたせて
それ入力にして処理するのと同じ DIはたしかにきれいな設計になるが、めんどくて工数がかかる。
作業者にはYAGNIのほうが優先度高いから勝手に採用できない
だからそういうのはトップエンジニアが最初に管理方針としてきめとくもんだ
末端のプログラマーに責任押し付けるのは酷 今のDIはめんどすぎる
既存コードをいじらないで中身をすげかえる
もっと楽な方法はないものか DIは言語自体に組み込まれるべきもの
高級言語はどんどん高級になるべきだが
ガベコレ搭載あたりで停滞してしまったからね
本来はDIやデザインパターンやユニットテストや
フレームワークまで高級言語の仕様に含めなきゃいけない ｲﾝﾀｰﾌｪｰｽを決め打ちにしたﾃﾝﾌﾟﾚｰﾄ作る間抜けな作りと
大してかわらないからな 使用者との合意の無いインターフェースほどクソなモンは無い
独りよがりで考えたものは全部クソなので誰にも見られないうちに捨てて欲しい 逆に言えば使用者との合意のあるインターフェースは問題ない
ということになってしまう。 >>795
あ、そうだって認めたねｗ
つまり、お前はインターフェースに問題があるとしようとしていたようだが、
俺はインターフェースには問題ないという話への誘導に成功したわけだ ｸｿが余計なことをして
余計にｸｿなｺｰﾄﾞを生産するｻｲｸﾙが途絶えることはない SEが余計なことをして
クソコードを量産することになるのは
よくある話だな DIを使わないと結合部分に余計なコードが入り乱れて大変なんだよな なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの？
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。 ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね Banana Monkey Jungle Solution
まで読んだ 結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ 現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ アクセス修飾子について分かりやすい説明しているサイトない？
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか >>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない setget時にログ出したいときに一括でできるぐらいか？ >>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ
多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい >>816
色々サイトみてるけど不要論も結構あるんだよな
よくわからないけどありがとう 言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね？ それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔 今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。 セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う
設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ >>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる >>821
> セットなんちゃらって書く場面を考えると
セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更 いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん
本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな そこででてくるのがプロパティだよ
ageは属性かメソッドかといったら属性だろ？
一見属性にアクセスしているようで、内部では
いろんな処理を行って値を返す。
それがプロパティ >>825
盲点でも何でも無いよｗ
例えば、Configクラスであっても、いつの時点のConfigかわからんだろ？
一年前の設定がほしいかもしれない。 >>826
引数が渡せるプロパティじゃないとね
c#使いなんだけどｃ#は引数を渡せない 状態状態ってよく悪者にされるけどOOPの肝はのへんににあると思う
#include <iostream>
struct logger {
std::ostream *out;
logger() : out(0) {}
void p(const char *s) {
if (out) *out << s << std::endl;
}
};
void f(logger &l) {
l.p("foo");
l.p("bar");
}
int main() {
logger g;
f(g);
g.out = &std::cout;
f(g);
g.out = &std::cerr;
f(g);
return 0;
}
ログの有効無効なんかをこうやって切り替えるのって
そんなに悪いこと？ Delphiなら配列の構文で引数付きプロパティを扱えたりするが
そんなことするぐらいならpersonからはbirthdayだけ見せて
今何歳かなんて呼び出し側で勝手に計算しやがれって思うわw Nameも不変じゃないし身長体重性別だって不変じゃない
商品の値段も不変じゃない
不変のものなってまず無いだろう。
つまりは、オブジェクトの状態の過去のスナップショットを
オブジェクト自身に持たせるのが正しい設計かという話 >>831
だから>>824は時刻を引数で与えるよう提案しているわけだ。最初からそういう話
personクラスが中で勝手に現在時刻を取得してたりしたら複数インスタンスのageの基準がずれたりして
使い辛くてかなわんだろう >>833
その理屈だと結婚などでNameが変わることもあるから
Nameにも日時を与えるようにしないといけなくなる 本質は>>832に書いたとおり
> つまりは、オブジェクトの状態の過去のスナップショットを
> オブジェクト自身に持たせるのが正しい設計かという話 誕生日だけが提供されていたらコードのあちこちで年齢を出すメソッドが別々に書かれるかもしれない
同じ処理が複数で書かれてそれも同じ処理とも限らない
ロジックが散らばるのはよくないからクラスが持つべきではないかと思う 大小比較のアルゴリズム自体を引数で渡したり、
オブジェクト指向っぽくてエレガントに見えはするけど、
一般プログラマには可読性低いなー
と思ったり。
一昔前のオブジェクト指向設計が売りの会社たちは、
オナニー会社として、まるで奮わなかったもんな
やっぱ適正レベルってもんが大事だよね >>837
そこは、年齢に限らず単に時刻の差を計算する処理として
dateクラスのメソッドかグローバル関数であるべきでは C++はベターCとして、文字列いじるときとか楽できればいいんじゃね？
でもmallocとかメモリ管理が面倒だから、C#やJavaに流れるよね
要員確保できるもの >>839
間違っても年齢を出す処理はdateクラスに持たせるべきではない
誕生日から年齢を出すのは実は結構めんどくさい
日本での年齢は日本の法律にのっとって決まってる だいたいそういうのは業務共通クラスとしてstaticメソッドてんこ盛りで置いておくよね つーか簡単だろ？
日付クラス。もしくは日付補助クラスに
2つの日付の差を年で返すメソッドを追加する
Personクラスには、誕生日とageプロパティをもたせ
ageプロパティは、誕生日と今日の日付の差を
さっきの年で返すメソッドを呼び出すだけにする
テストは日付クラスのメソッドはそのまま年計算のメソッドのテストを書けばいいし
Personクラスのテストは、単体テストの観点から日付クラスが
外部モジュールになるので年計算のテストは不要（すでにやってる）
年計算のメソッドを期待したとおりの引数で呼び出していることの確認と
返り値をそのまま戻しているかを確認すればいい
特定の年月日の年齢が知りたいなら、誕生日プロパティと特定の日付から
日付クラスの年計算メソッドを呼び出して差を計算するか、
適切な場所があるならそこにメソッドをおけばいい >>841
> 間違っても年齢を出す処理はdateクラスに持たせるべきではない
理由ぐらい書けよな dateクラスに持たせるべきではないというのなら
年齢計算クラスに持たせればいいだけだな >>841
すまん、ならdateクラスは撤回する
国にも依るとなると尚更personにも持たせたくないな
単にグローバル関数にするか、いっそそれ用のクラスツリーをでっち上げて後々多態できるようにするか、かなあ >>843
じーちゃん132歳とか出るパターンじゃね？ 国によって年齢計算のアルゴリズムを変えたいというのなら
ストラテジーパターンの出番だなｗ 俺やったらageプロパティやageオブジェクト作るんじゃなくて
ageクラス作ってpersonのデリゲートメソッドにageクラスオブジェクト返すものを作る。これで年齢とはそもそもなんぞや定義はの面倒な過程の話にも対応出来る
だが書く途中でゲッターですませやとキレだすと思う 普通に考えたら person と基準日を表すオブジェクトから年齢を返す関数を作るってことになると思うんだが。 >>852
定義がわからんからオブジェクト指向やろう
というか俺はプロパティで済ますわ もうメンバー変数とメンバー関数が混在するクラスは作るな
関数しかないinterfaceで十分
関数が一つしかないならlambdaでいい 正直必要かどうかはわからない
ただおまえが欲しい
だめか？それだけじゃ？ その低学歴知恵遅れが作ったﾒｿｯﾄﾞは
うるう年考慮してなさそうで変なﾊﾞｸﾞが入ってそうだわ
2000年10月20日生まれなら
普通にintで
(20181016-20001020)/1000
でしまいだからな そもそも常識的に
特殊なｹｰｽを除いて日付の引き算で
経過年数がかえってくるという発想はないからな
経過日数はあったとしてもな (20181016-20001020)/10000
こうだな
危ない。。。 このとおり、
やっぱりな低学歴知恵遅れが
ｵﾌﾞｼﾞｪｸﾄ指向にふれるのは危険
ｵﾚぐらいのﾚﾍﾞﾙがないとﾑﾘ >>832
勝手に変わるか、と言う意味では、生年月日は不変だけど、年齢は変わるんでは？
>>833
なるほど。そもそもそれはプロパティとは言ってなかったんだな。
それはおっしゃるとおり、関数にすべきだと思う。 >>857
年齢はその前日の満了を持って加算される、のルールで抜けるパターンがあるんじゃね？
半角さんは間抜けなの？ 大抵の場合、正しく理解せずに中途半端な実装してる案件にぶち当たって嫌な思いした奴がここに集うんだろ？ 実装レベルの議論してるやつと設計レベルの議論してるやつ
さらにもーちょい上から俯瞰して物を言ってるやつ
全部ごちゃ混ぜになってて面白いね 自分はプログラムの観点からだけで話してる
上にあった英語の奴もプログラムが主だったなぁ
設計は知らない
話題をスレで分けた方が良いのかねぇ? やっぱ平年の3/1に、うるう年の2/29に生まれた人の年齢が狂うな。
しかしこういう知ったかぶりが、ひどいバグを生んで改修大変になる。
と言うか、これを保存時にやられるとデータ修正ものなので、場合によっては偉いさんが頭下げに行って、出世の道が遠のくパターン。 設計って、機能ごとに必要な処理をリストアップしたら、そのまんまオブジェクト指向なんじゃね？ 「誕生日の前日が終了する瞬間（すなわち誕生日をむかえる午前0時00分の直前）
に1歳を加えることになる」の部分の解釈には
前日に1日加えると解釈される場合と
当日に1日加えると解釈される場合の2種類がある >>871
一番問題になる学教法にならうべきじゃないんかな。
前日に歳を取る、ただし前日の24:00を使用する。表記や概念的には、って感じで。
だから、4/1生まれは4/2生まれと学年が違う。4/1生まれは、3月中に歳をとってるから。 誕生から１年経過することに１つ年を取るというのが定義であって
誕生日なんて全く関係ありませんよ。人間のクズども。 学校教育法17条 「保護者は、子の満六歳に達した日の翌日以後における最初の学年の初めから・・・」 年齢の扱いをどうするかは法律で強制されているわけじゃないので
システムによって異なってもOK
だからどういう実装でも公平な実装であれば問題ないといえる。
例えば20歳おめでとうキャンペーンで、20歳になっていなくても
その月に20歳の誕生日を迎える人を対象にしても良いわけだ
だから何が正解かを議論することに意味はない
仕事の話をするなら
年齢の計算はどうしましょうか？と客に仕様を聞くべきか
年齢の計算はこのようにしますがよろしいですか？と客に仕様の確認するべきか？
そういったことを考えたほうが良い 式の間違い云々よりも、皆ageはただの例示であることは前提とした上でOOPでどう表現するかの話をしてたのに
いきなり実装に踏み込んでくる思考が謎い Personインスタンスのageのゲッターで計算しとく。
Personインスタンスが無い時にも年齢の計算が必要になったら、クラスメソッドにしてPersonのゲッター内部から使う プロパティが優れているのは
ageのように、
年齢？そんなものオブジェクトのフィールドにしておけばいいだろ？
え？生年月日から計算するようにしたい？
なら、そのフィールドをプロパティにして計算して返すだけだな
とクラスのインターフェースを変えることなく
実装を関数に変更できるところにある >>881
俺もこれ見たよ
肥満の指標・BMIは営利目的で生まれたもので医学的根拠がない？「何を信じれば」と驚愕の声や「そやろな」と納得の声など #初耳学
https://togetter.com/li/1275152 >>882
いやw年齢だとシンプルすぎるかなと思っただけw >>882
マジかよ保険会社最低だな
バレンタイン広めた菓子会社と同じくらい最低 >>876
まあ、わかってて公平な実装と、それで良いと思ってるけど漏れがある実装は、仕様と不具合と大きく異なるけどね。
>>878
ほんといつも、半角さんがでしゃばった上に間違うからこんな事になる。
でもAgeはオブジェクトのプロパティとしては俺はおかしいと思うよ。
環境によって刻々と変わったり、恣意的に変えられる値は、オブジェクトとオブジェクトの演算で出るべきだと思う。
環境オブジェクトなり、指定時刻オブジェクトなりの、時刻を表すオブジェクトと、Personを組み合わせて、初めてAgeが出るんだし。
Personを含む生年月日があるオブジェクト.ageAt(時刻オブジェクト point)で年齢オブジェクトが出るなら理解できる。 言い換えると、オブジェクトのプロパティはそのオブジェクトだけで表現可能なものに縛ったほうが良いと思う。 誕生日はプロパティにしてもよく、年齢は日付けに依存するから関数か 特定の日時の年齢が必要になったら
getAgeからgetAgeAt呼べばいいだけやん
言語によっていろいろやり方あるけどね
getAgeAt(Date.Today)しか書かれてないプログラムとかマヌケじゃん
既存クラスにメソッド追加できる言語なら
最終的にはDateにyears_between何ちゃら書く事になりそうだが それで言ったらPersonオブジェクトがどういう扱いなのかによってもAgeがプロパティか関数か違いそうだな。
データベース的な一回表示するだけだったら関数でも良いけど、ゲームやSNSのアバター的なのだったら、ステータス表示するたびに計算してたら無駄が多い。
誕生日イベントでもない限り1日くらいは1歳違う程度は許容されるなら、オブジェクト作成時(ログイン時)に計算して結果をAgeに入れるだけとか、誕生日イベント発生時に計算して入れるだけとかした方がよくないか？
モバイルゲームとかなら尚更。 くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
それが答えだ バッチが日付またぐけど開始した日で計算したいとなると「当日」をそういう扱いにするようにプログラム書くんだろうがインターフェースを変更する必要は無さそうだな プログラミング系の文章は長いのが多いｗ
Qiitaも無駄に長いし そらそうよ。
一体何に細かく指示してると思ってんの。
それに比べれば全然短いわ。 保守性がどーでもいいならスマートUI + 振る舞いレスオブジェクト + トランザクションスクリプト + スパゲティクエリで短期的な生産性を上げることができる
保守性と生産性を同時に上げる方法は残念ながらオブジェクト指向しか知らない 言語の解説本でもムダに長いからな
ポケットリファレンス程度でいいのに 低学歴知恵遅れは日付ｸﾗｽにそんな頭悪いｺｰﾄﾞを入れると書いてるからな
>>843 ← このとおり 普通に考えてな
日付ｸﾗｽにそんな頭悪いｺｰﾄﾞなんかいれない
低学歴知恵遅れはいろんなもんに利用する日付ｸﾗｽに
年齢求めるｺｰﾄﾞをいれると書いてる
低学歴知恵遅れがｸﾗｽを設計（）すると
こういうﾊﾞｶな作りになるという典型的な例といっていい
この板にいるような低学歴知恵遅れにはやっぱりな
ｵﾌﾞｼﾞｪｸﾄ指向なんかﾑﾘ ただの起算日の違いの問題だからな
計算方法はかわらない
そもそも日付ｸﾗｽ（）なんかやるようなもんじゃない >>901
日付クラスに入れるのは、年の差を計算するロジックやで？
日付同士の差を求める演算。結果の年だけを取得する
誰が年齢の差のはなししてるんだよｗ 確かになー。。。
と言うか、大抵のフレームワークに日付クラスがあるのに、わざわざ改造して年齢計算メソッド付けるって発想が浮かばない。
普通はPersonに付けるだろうし、スマホゲームとかならクライアントに計算させてバッテリー減り過ぎも困るから、場合によっては鯖側に管理クラス作ってそっちに付ける。 アタマが悪いと短いレスすら誤解して読んでしまうらしい
ほんとかな？ >>906
日付クラスに入れるのは日付の計算（もちろんすでに入ってるのならそれを使う）
年齢はPersonクラス、仕様が一致してるなら日付クラスのメソッドを呼ぶだけでいい
日付の計算と年齢の計算は（仮にロジックが一致していたとしても）別物
そういうことを考えるのが抽象化 >>909
入ってるのは今の所見たことないけど、メソッドにする程か？
日付クラス同士の足し算引き算出来るはずで、年数計算って結局ただの引き算やぞ。
別に駄目とは言わんが、Ageメソッド内で「今日の日付－生年月日」するのと、「日付クラス.年数計算(今日の日付,生年月日)」するのと手間は同じ。
むしろ長くなる。 operator - が日付クラス内で定義されてる例なんていっぱいあるでしょ >>910
Personクラスの属性にしていれば、
内部の実装が変わってもインターフェースを
変えなくてすむんだよ。
それにオブジェクト指向の特徴だが人間のメンタルモデルに近いから
理解しやすい。例えば「あなたの年齢は？」みたいに聞くだろう？
年齢を知りたいときに、あなたの生年月日は？って聞いてからわざわざ計算しないだろ？
"あなた"が知っていることは、"あなた"に問い合わせればよい。
というのが人間にとって一番理解しやすいんだよ 日付ｸﾗｽの - ｵﾍﾟﾚｰﾀｰで
経過日数ではなく経過年数を返す作りになるのか。。。
さすが低学歴知恵遅れがいうことは斬新だわ やっぱり低学歴知恵遅れって感じ
もうすぐに分かってしまう
まともな教育を受けてればでてここないような発想が
ﾎﾟﾝﾎﾟﾝでてくる
低学歴知恵遅れのﾚｽってすぐにわかる
いちいち低学歴知恵遅れですと自白するからな。。。 ﾊﾞｶはﾊﾞｶであることに気づけない
ﾎﾝﾄになよくわかるわ 関数型論者だったら「人」はDNAだけで表し、生まれた日、場所、その他その瞬間の宇宙の諸環境をすべて引数で与えて最後に経過時間も与えるのかな？
なんだ、関数型論者って決定論者だったんだな。 >>910が日付の計算が日付クラスのメンバーになっているのを見たことがないと言っているので
それに対して俺は>>911で知らないうちに演算子オーバーロードの恩恵を受けているのではと言っているだけ
「今日の日付－生年月日」は日数で「日付クラス.年数計算」の「年数」とは一致しないが
そんな事は気にせずに単にdateの計算をどこに置くかの話をしているだけ
繰り返すが日付自体がただの例示だから、単位だの閏年だの細部を詰めることに意味はないと皆わかってる
そこから一人実装を始めたり短絡的にoperator -で年数を返すと変な結びつけ方をしたりして
自分が作り上げた架空の敵相手に憤ってしまうのがもうね >>917
それは関数型論者でなくて適切な抽象度が理解できないただの抽象馬鹿だろ。 >>913
あれ？日付クラス(Date)の中にYaer、Man、Dayって年クラス、月クラス、日クラスって無かったっけ？
すまんね。
だいぶ離れてて、うろ覚え。
>>912
うん？
だからPersonクラスがAgeプロパティだかメソッド持つんだろ？
日付クラスだか時間クラスだかが年数計算メソッド持つ必要は無い。
時間はただ時間、日付はただ日付。
年齢もただ年齢ってのもある意味じゃ正しい。
システム上不都合なら管理クラスに計算させて、結果を受け取るだけでも良い。
オブジェクト指向は、必ずしも現実と同じ区分けでなくて良い。
責任分担をキッチリするための道具でしかない。
保守性に問題なければ、システムの特性に合わせてどちらが管理するのか決めれば良い。
(むしろ現実と離れることが多いから、あんまり現実だとこうだから～とか、こだわり過ぎない方がいい) 生年月日は、属性・インスタンス変数
年齢は、computed・算出プロパティ Ruby で、年齢をクラス化したもの
誕生日から年齢を計算するhappybirthday gemをリリースしました
https://takanamito.hateblo.jp/entry/2018/05/15/091820 >>918
年齢計算や年数計算は大事な場所じゃ無かったし、言う通り日付クラスに年数計算メソッド付けるべき？が話題の中心だったと思う。
年齢計算や年数計算は
_______日付クラスA = 今日の日付 － 生年月日(または任意の年月日)
return 日付クラスA.Yaer
とかだった気がする。
うろ覚えだが。 難しい物なんだから
話が長くなるのは当たり前
既に知っている事を話す以外だと
相手に解る様に話すのに分量が掛かる
当然だろう >>924
日付（年の差）計算と年齢計算をごっちゃにしてはいけない
日付クラスにつけるのは年の差計算処理
年齢の計算のことは考えてはいけない
Personクラスにつけるのは年齢プロパティ
中で日付クラスを使うかどうかは実装による
年齢計算の方法が複数あるというのなら、ストラテジーパターンを導入し
アルゴリズムを切り替えられるようにしておけばいいだろう
>>843で書いたことの繰り返しだがな いや低学歴知恵遅れは
頭ﾜﾙｲという病気
不治のﾔﾏｲ >>921
これ言うと元も子もないが、実際にはアカウント作る際に生年月日と年齢を別々に書かされる通り、計算なんて何処もしちゃいない。
気が付いたらユーザーが書き直してねって。
お勉強でもなけりゃ年齢計算はしない。
年計算用途の方が実践で使われてるかもね。 >>926
うーん？
誕生日を生年月日にしただけで、同じ意見に見えるが。。。
閏年に誕生日が～とかも含めるって事？
だから、実際のサイトじゃ年齢も入力させる形なのかね？ class Age {
public DateTime BirthDay { get; }
private DateTime Today { get; }
public int Years { get {
int b = BirthDay.Year * 10000 + BirthDay.Month * 100 + BirthDay.Day;
int t = Today.Year * 10000 + Today.Month * 100 + Today.Day;
return (t - b) / 10000; }}
public Age(DateTime b, DateTime t) { ...
class Person {
public DateTime BirthDay { get; set; }
private DateTime Today { get; set; }
public Age Age => new Age(BirthDay, Today);
public Person(DateTime b, DateTime t) { ... >>912
その質問は暗黙に(今の)が入ってるんじゃない？ 半角さんは設計スキルないんだからもう書き込むなよ。
実際間違った実装を想定して設計の話ししただろ？ >>930
電子カルテだとまあまず患者マスタに年齢は持たないよ。
いつ時点に、何歳か、って方が大事だから。
どのタイミングで年齢計算するかとなると、入院中に歳を取るパターンがあるので結局毎日計算するハメになる。
それこそ業務によると思うが。
ただ普通のウェブサイトでも、生年月日聞くところで年齢を聞かれる事はあんまり無いんじゃないかな。 >>935
なるほど、カルテだったら閏年で何歳ってより、生物として生まれて何年目、的な意味合いの方が重要だし、有りかも。
年齢まで求める場所減ってるか知らないけど、情報的な価値は低いかもね。
統計的に扱うだろうから、生年月日で何年生まれか分かれば十分だし。 手術した日から何年経ったか表示してと言われて裏で誕生日クラスが使われる >>891
＞くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
＞それが答えだ
これで解決する議論をぐだぐだとまあ…
何がしたいんだ？
年齢にまつわる宇宙の真理をクラス化したいのか？ >>936
何歳って概念も結構大事で、6歳未満にはできない、とか、6歳未満だからいくら、とか結構決まり事があるんよ。
それ守らないと保険組合からお金がもらえない。
暦の上の、いわゆる法律上の年齢も無視できないんよ。
それは、医師の指示を実施した日で計算するとか、日付の取り方も色々ある。
医学的に必要になってくるとすると、何ヶ月早産児の何ヶ月児が、正規産だと何ヶ月児だよ、とか。
こっちは、だいたい週計算する。 日付クラスを継承して誕生日クラスとか作り出す奴がいるから無駄に複雑になる。 無駄にクラス化しようとする奴も同罪。だからオブジェクト指向がクソと言われる。 だから業務共通クラスの１メソッドにしとくんだろ、普通
バッチが日跨ぎしても基準日は変えないとか、業務やシステムの要素と切り離しできるなら話も変わるけど クラスもいいけど、共通処理は単なる関数ライブラリの方がありがたいよな。 >>940
継承は間違い
日付型のフィールドを持つだけの誕生日値オブジェクトクラスを作るのが正解だな ２つの日付けを引数にしてその日数を返す関数あれば、それだけでよくね？
変にクラス内に閉じ込めてもメリット無いと思うんだけど？
少なくともpersonクラスには誕生日を返すくちがあればそれでいいと思うよ。
それをどう加工するかは、表示クラスだったり年金計算クラスだったりでやればいいんだよ。 >>946
コンピュータの立場で考えるのではなく
人間の立場になって考えるようにしましょう
Personクラスはどういう属性を持っているか？
それを考えるのが設計。実装のことは一旦忘れましょう 関数型や手続きだとこんな議論にならん辺りやっぱオブジェクト指向はアカンな 誕生日から年齢導くだけの処理に、幾つのファイルとどの位のコストが必要なのかねぇ。
保守性とはホント真逆だわ。 >>949
年齢を整数のまま扱うといつか誰かが
Xピクセル=10歳+50kg
みたいな奇妙な演算をやらかす
それは困るからクラス化して保守性をあげよう それよりも複雑化によるデメリットの方が計り知れない。
そもそもコード量を減らすためにクラス化とかあるのに逆に増えるってどんな呪いだよ。 >>951
重複コードがほぼ一掃されるので全体のコード量は減る
利用者側は年齢にまつわる詳細なルールを知らなくても使えるようになるから複雑性も解消される 設計がおかしいとおかしなクラスが乱造される
一クラス一機能をつら抜いてFileRemoverとかFileRenamerクラス作ってる人は死んだほうがいい
MultiFileRemoverとか本当に必要なら作れよと思う >>952
だから呪い。実際、出来上がってるものの大半は真逆の事になってるんじゃないかね。 オブジェクト指向は書く量と段取りを増やすデメリットをもって
パーツや責任関係の切り分けを行う作業と理解しております 日付型とかあるじゃん
あれ中身はただの整数値だけどだからってじゃあ整数値のままでいいじゃんとはならない
なぜなら整数値を日付とみなして注意深く扱うよりも
さっさと日付型を作ってしまったほうが間違いが減って問い合わせや演算が楽になり理解しやすくなるから
同じことをドメインでもやりましょうというだけの話なんだけど何をそんなに恐れてるのだろう 架空言語にて
private Name name=new Name()
public Person(string name){
Name tmpName=new Name(name);
if(tmpName != null){
this.name=tmpName;
}
} >>947
そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
ある程度はどっちに比重置くか考えて作った方がいい。
そういう所こそ設計の腕の見せ所。 > そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
全く無関係の話をされても困るんだが？ 理想と現実は違うって事。
人間のこと考えたいけど、仕様変更繰り返すうちにグダグダになる。
出来る事は破綻しない様に事前に想定される事に対処して、その後も破綻しない様に管理することだけ。 >>963
だからオブジェクト指向が必要なんだよね >>964
そう。
そのはずだ。
入門書でAnimalクラスを継承してDogクラスとCatクラスが～とか例えた弊害か、人間の事をとかなる。
人間の事を考えるなら顧客の事だ。 >>938
エキスパートと思われる人にヒアリングしたら
そいつが「年齢にまつわる宇宙の真理」とか求め出すというクソ案件はたくさんある。 >>947
だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
それじゃ無いと、様々な業務に適用させる度に微妙に違う属性を返さなきゃならんくなるだろ？ > だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
Personクラスはそもそも業務に特化したクラスだろう？
現実世界の人間を完全シミュレートする。それがオブジェクト指向だって
考えてるのはお前だけやで >>969
いや、そもそもオブジェクト指向はパーツの使い回しがテーマだからな。 パーツの使い回しはオブジェクト指向じゃなくてもできるんで
それは全然違いますー いやはや驚きだ。これが馬鹿というものか
まさか、どんな業務にでも通用する
Personクラスを想定していたとは
世界にたった一つPersonクラスがあれば
ゲームから業務まで何でも使えるものを想定していたとはな
愚かとしか言いようがない 少なくとも会社や自分の作るアプリで使い回す為にオブジェクト指向で作るんだからな。
おまえみたいに毎回特定業務に特化してフルスクラッチから作るとかバカしかやらんぞ。 >>973
え？お前こういったじゃん
> やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
お前は、使い回すために業務クラス作ってんのか？
どんな業務でも汎用的に使えるもの = 業務クラスだったのか？ 使い回さ（せ）ないもの = 業務クラス
Personクラスは使い回せない = 業務クラス
俺はこう言ってるだけなんだが、
こいつは何を言ってるんだろうか？ アホに構ってしまった。
personなんて一般的な名前で個別に特化したクラスを作るあほは社会の迷惑だからしんでくれ。 >>976
キミはネームスペースというものを知ったほうが良いぞ
多くの言語ではクラスはネームスペースの中に入れるから
一般的な名前が使えるんだよ 名前空間内に入っていてその業務に特化したpersonという標準クラスはok派。
それを継承して使いまわしてもいいじゃない。 名前空間のせいで型名が長い
その反動で関数名は短すぎるから型を省略したら情報が少なすぎて読めない
型を宣言する言語としない言語の対立が最も激しくなる仕組み personに関わる宇宙の真理を考えてる奴がマジでいてクソワロタwww オブジェクト指向で作った時点で失敗
メンバ変数の状態の数だけパターンが増えていく
これを仕様で固定せず
オブジェクトの状態数×オブジェクトの状態数
の工数爆発を汎用性による品質の向上とか思ってるキチガイばっかで救いようがない
無限の汎用性とは無限のバグ数を持っていることを悟るべき > オブジェクト指向で作った時点で失敗
いきなり結論ありきｗ 人類ｸﾗｽからﾎﾓｸﾗｽを導出するぐらい頭ﾜﾙｲことを平気でするからな オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない >>973-974
あー。。。
オブジェクト指向は素晴らしいかもしれん。
だがな。
納期に追われた焦った脳で扱うには手が余る。
精々次の一回使い回せたら使えたってのが現実。
(と言うか、そんなんだから継承は悪とか言われるわけで)
上で誰かがライブラリ的な方が嬉しいとか書いてたろ？
あれが真実。(誓って書いたのは俺じゃあない)
流石にまんま関数をライブラリにしなくて、関数とクラスをまとめたライブラリにするが。(むしろ気持ち悪いかこれは)
だから言ったろ？
現実と理想は違うって。
理想を追い求めて納期間に合わなくて、クビになったら元も子もないやろ？
いつかは。。。とか思いつつ、その連続よ。 >>988
お前の現実の話なんか
他人には関係ない 一番頭ﾜﾙｲやつが大量にﾚｽしてるわ。。。
まさに典型的な頭の悪さ >>988
Personのような業務クラスは使いまわしできるわけがないのは常識で
どうせ作る力ないんだから作るな。使え。
オープンソースなんかの汎用クラスを使え
見事にオブジェクト指向で世界中使い回し出来てるんだから。 業務でどこの馬の作ったか分からんような
ちゃんと試験されたかどうかすらわからんようなｺｰﾄﾞを使うとかな
ｺｲﾂは間違いなくﾆｰﾄ ちゃんと試験すればいいだけじゃね？
どうせ自分で作っても試験するんだから
他人が作ったものを試験するほうが
作るコストが節約できる
第一そもそも作る能力がないレベルなんだから
他人のが使えませんと言っても
自分で作ることもできませんっていうのが落ちだろう ｸｿﾆｰﾄの世界では手続きとういもんがないのは分かる ダメな奴は
できる方法を考えるのではなく
できない理由を考える ｵﾏｴはこのｽﾚで頭わるいことばっかり書きこむまえに
ﾊﾛﾜへいく必要がある >>984
状態をクラスにカプセル化することによって独立性を保てる境界ができる
すると状態の組み合わせ数が激減するんだよ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 55日 10時間 15分 8秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
