カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性」として「カプセル化は絶対にやめろ」としている。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) 大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。医学的にいえば「手術ができない存在」であるといえる。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
実例
XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。
ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。
世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。頂点データをGPUに送信した直後にGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。
しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。
さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。
カプセル化は恐ろしいね！！
仕様変更
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。
オブジェクト指向云々ではない。
シンプルなほうが解読しやすいよね
散逸して現物しか残ってない場合とか特に
副作用の起きない処理はpublicでも問題ないだろうな
問題が起きるとすれば運用側の問題
データベースに出し入れするだけの業務システムなんかは問題ない。
データベース上のデータなんてグローバル変数となんら変わらない。
クラスは構造体としてしか使わないから深い階層化も起きないし。
>>2
C++が流行りだしたころに、これ言ったら変な目で見られたわ。
設計能力と未来を見通す能力がある人限定なんだよ。
大人数だと低い方に合わされるから、大人数プロジェクトには不向き。優秀な少数精鋭プロジェクトなら良いんだけどね。 日本の場合はカプセル化されてようがいまいが基底クラスなんて弄ったら再テストしなきゃいけないから
同じ機能を持ったクラスを作るので意味が無い
そもそもアランケイの考えたものと今のオブジェクト指向が違うっていうね
オブジェクトなんて名前を使ったせいでオブジェクトが重要だと勘違いしてるし全員
よって失敗
ただ発展には貢献したそれだけ
昔作ったクラスを継承したり再利用したりなんて殆どない
データと関数数個だけで済むものを
無駄にクラス化して
ヘッダと実装にわけて無駄にコード追いにくくするのはあかん
>>4
この実例は良くないよね
Modelクラスが何かにラップされてるならその元を探して改良すべきなのに
それやらないでトリッキーな方法で回避するから余計面倒になってる >>13
その相手が壮大なオープンソースのフレームワークで
改変した修正パッチが開発チームから拒絶されたら死ぬ。
フォークしても誰がメンテナンスするんだよ オブジェクト指向で設計やるとしばしば手段が目的化してしまって不必要に複雑化する
privateの考え方自体は悪くないんだが、
privateの必要性を理解できる人間はそもそもprivateを必要としないんだよ
そしてprivateが必要な人間はprivateの本質を理解せずにおかしな使い方をしてしまう
こういうジレンマは何にでもある
カプセル化は机上の空論ってのは頭いい人しかいないチームでしか通用しない
日本のIT土方みたいに想像を絶する馬鹿が無限に湧いてくる現場ではコードを守るために不可欠
あとになって公開できないなら隠蔽するなってことだろ
ずっと保守し続けて、公開してくれって言われたらすぐ設計変更して公開できるなら別にかまわん
でもずっと保守し続けるかどうかは予算や人事で決まるんだから、それらに関われないと責任持てんわな
想像を絶する馬鹿が想像を絶するカプセル化をしてしまうんだよなあ……
特定の事例はオブジェクト指向とかクラスが悪いわけじゃなくて
その設計が失敗してるだけですね
>>4
OpenGL ESはファイルからテクスチャ1枚読み込むのにもアホみたいに面倒臭いからなw
OpenGLの手法すら使えないとか何故そこまで削った…って感じだし OOPにすらついていけない本物のバカには無理ってだけ
まあOOPが無理ならどんなプログラミングも無理だけど
路線バス、タクシー、レンタカー、自家用車の4つを使ってオブジェクト指向を説明して欲しい。
難しすぎて全然頭に入らない。
余計な例えは無意味
そもそも変数とか関数とか引数とか理解しとんのか
オブジェクト思考は糞
関数の引数と戻り値だけ信用すれば良い
オブジェクトに状態持たせるフィールドなんて可読性落ちるだけなのに理解できない一周も二週も遅れてるやつが声高に叫んでるのは笑えるw
>>4
頂点データは常に見られるようじゃないとダメだろ…
レンダリングエンジンとの結びつきどうなってるんだ？ >>31
そんな仕様変更が入る方がおかしいんじゃないかな カプセル化は新人や増援部隊に変な事させない為の仕組み
開発者全員が高度なプロフェッショナルならただの足枷でしかない
オブジェクト原理主義者のコードを引き継ぐ事になった時の絶望感は異常
iPhoneアプリ開発に必須のobjective-cやswiftもカプセル化はできない。
人工知能で大流行のpythonもカプセル化はできないようになってる。
これらはアクセス非推奨だがアクセス自体はできる
「カプセル化は悪」「カプセル化はオブジェクト指向ではない」というのがやっと広まりだした。
>>4
そもそも設計が間違ってるのをオブジェクト指向のせいにしてるんじゃねーよハゲ >>45
XNA作ったマイクロソフトの超エリートたちですら設計ミスをするくらいオブジェクト指向は難しい。 > オブジェクト指向の発案者であるアラン・ケイもコーディング規約
> （頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、
> アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
つまり
1. privateという概念（アンダースコアという概念）自体はOK
2. ただしprivateでも外部からアクセスできるようにすること
という話
経験的に言えば、ライブラリや部品的なクラスでは、カプセル化はかなり有効で、
安全になる。
ところがアプリ自体の中にクラスの場合、隠蔽しても余り意味が無い事が
分かって来た。
ファイルツリービューの中のデータを隠して、メインウィンドウのクラスからいじれないように
しても、アプリの場合にははっきり言って意味が無い。
>>49
そのアプリを複数人でいじってるんなら、ライブラリやらの恩恵と同じ効果があるんじゃね？
カプセル化の是非は、グローバル変数の弊害の話と本質は同じだよね
影響範囲を狭くした方がミスは防げるが、柔軟性は失われる >>48
ちょっと違うな
ST80でもOWでもVWでも共通だが
privateはあくまでもプロトコルの一つという設計だから外部からアクセスできるように・・という考え方ではないよ
具体的な扱われ方としてはインスタンス専用のローカルメソッドのような使われ方をする
なおprivateプロトコルは全てではないが
他のオブジェクトからコールするとデバッガに落ちるように仕組んでたりする
（外部からは使わせないよってこと） >>49
データを誰が保持するのかって問題はMVCの当初から大問題にはなってたからね
単純にModelが必ず持つという形にすると指摘した問題が必ず発生するから
経緯的にPluggableMVCへと変遷しどこからでもupdateプロトコルを受け付けることができるようになった
データはMVCのどれも保持しなくなり、ひとまずの決着がついたが
この形式であっても誰がどのようにupdateをかけているのか逐一コーディングしなければならない問題が残ってた
そこで現在ではデータを保持するAspectAdaptor系は
いわゆるアクセサを書く必要もなくなり通知を受け取るだけで動作するようになっている
（updateのためにアクセサを呼ぶなどということはしない） >>51
> 他のオブジェクトからコールするとデバッガに落ちるように仕組んでたりする
殆どの言語はprivateにアクセスできる OOは業務システム向き
組み込みだと細分化し過ぎるんじゃね？
>>53
目的が違うので
private配下のメソッドは外部から呼ばれることを意図しない（ことになっている）
のとbehaviorにさえアクセスを許さなかったりする
ただこれは言語仕様としてコントロールしているわけではないので
あくまでも慣例として扱われてる
適当なクラスを作ってprivateプロトコルに適当なメソッドを組めば好きに外部から呼び出すことは出来る
そうは言っても慣例破ってるコードはすぐ見つかってしまうのでまあよろしくないことになる >>11
アランケイのは、完璧なものから取り除いていくような感じだったな >>55
private配下のメソッドは外部から呼ばれることを意図しない（ことになっている）
頭文字にアンダースコアを付けるなどの命名規則で縛る程度のも、外部から呼ばれることを意図しない（ことになっている） >>54
業務システムだとDBいじくるだけだから深い階層構造に関わることはまずないだろ。
DBというグローバル変数をクラスという名の構造体にコピーして、編集して、書き戻すという単純作業の繰り返し。 隠蔽って言うからおかしくなる
privateは一貫性を守るために変更可能性のスコープをオブジェクト内部に限定するためのものであって、内部状態の秘匿が目的じゃない
というかオブジェクトの内部状態が外から分からないようなものはテスト出来ないでしょ
ダメだろそんなクラス
>>50
>そのアプリを複数人でいじってるんなら、ライブラリやらの恩恵と同じ効果があるんじゃね？
個々のクラスをじっくり丁寧に作って、データを変更する専用のメソッドをきっちり
作り上げれば安全性は確かに高まる。
これは、人数の多いプロジェクトなら可能だと思われる。
ただ、個人製作のアプリだと、そこまでクラスを作りこむのは時間が掛かりすぎてとても
効率が悪くなる。
結局、個人製作レベルだと、ファイルツリーニューの中のデータを変更する際にやってはいけないことなどの注意事項をどこかのテキストファイルなどに書いておいて
データはpublicにしておいて、それに気をつけながら、アプリの他のクラスからでも普通に書き込みアクセスするように
した方が開発時間は少なくて済むようだ。 >>59
その気持ちも分かる。
しかし、その一方で、例えば fopen()のようなライブラリ関数を使う際、
FILE構造体の中身までしっかり公開されてなくても、fopenの使い方が
しっかり説明されいればそれで十分であり、逆にFILE構造体の中を勝手に見て、
それを前提にプログラムしすぎることは、FILE構造体の中身が変更になった
場合に問題となる。 >>60
> 結局、個人製作レベルだと、ファイルツリーニューの中のデータを変更する際にやってはいけないことなどの注意事項をどこかのテキストファイルなどに書いておいて
それをソースコードの中に書くんでしょ？ privateって 結論：privateにしたら、必ずgetterを用意しておきましょう。
>>62
昔から言われていることなんだけど、ソースコード以外の場所にちゃんと
フローチャートなり、データの構造や関数の関係図、何らかの図など
プログラム中に書きにくい注意事項をどこかに予め書いておくと、
プログラムにとても役立つんだ。 >>60
そこは考え方次第だからねー
asyncでいいならファイルツリーはすべてNodeクラス配下で汎用的に扱う方が楽なので
俺ならそうする
コードも少なくて済むし扱いやすい
常にsyncって話になるとfsevent見て反映させる
カプセル化のメリットは全体像を知らなくても扱えるように理解して努力していれば
結果的にコストが下がることにあるけれど
オブジェクト扱ってるのに中身は関数で組んでいる人が混じると割と悲惨なことに（なった） >>64
それよりもテストコードが含まれてないソースは信用できないね個人的に
コードが更新される時ドキュメントも更新されるとは限らないし
ドキュメントには本当に必要な情報がなかったりもする・・ >>66
でもチェックしにくいとこってデバイス絡みや使ってるUIのライブラリの変な仕様のとこだろ
テストコードなんて動くの？ >>68
デバイスを使う「ソフトウェアコード」のテストをするんだから、
デバイスのテストをしても意味がないぞ
「デバイス」のテストなのか、デバイスを使う「ソフトウェア」のテストなのか
どちらを対象としたテストなのかをはっきりさせよう
デバイスのテストはデバイスのテストで別にやる
両方を同時にテストしようとするな >>69
でも全部ひっくるめて正常に動いて欲しいんだろ？
どう組んだら正しいのか誰もわからないものでプログラマをぶん殴る口実がほしいと >>64
> プログラム中に書きにくい注意事項をどこかに予め書いておく
これが必要になる場面って大抵は設計が歪んでいる >>68
>でもチェックしにくいとこってデバイス絡みや使ってるUIのライブラリの変な仕様のとこだろ
そういうところを切り出してモックなら動くことを示してソフト側は悪くないって
言い張るための技術だぞ。 頭が悪いやつが多い業界だし、カプセル化は有用だと思うがな
勝手に変更させない、有用に変更しても理解できないので変更しないほうがいいって
2重の意味で
>>1
そのカリフォルニア大学ソースどこ？
むしろ、彼らの作成するソース(github)を見るとオブジェクト指向で、@private(JSDoc)を律儀に記述しているけど。
ん？JavaScript以外？C#やJava？
privateをサポートする言語でカプセル化しない馬鹿なんてこの世に存在するの？ >>74
そういうクラスを作る側が頭が良くて
利用する側がどうせ頭が悪いという傲慢さが
オブジェクト指向が批判される原因だと思うわ。
大体 既に書かれたコードの記述で
新規プログラマーのコーディングを制限しようと
言う考えが傲慢以外の何物でもない。
お前らの言う頭の悪い奴は元のクラスのprivateを
publicに変えるかもしれないし
Personというクラスの隣に
Person2と言うクラスを複製してそっちの方をpublicに
変えて利用するかもしれない。
でもそれって止められるわけないだろ？
それを言語仕様で止めようとしてる事がどうかしてる
元のクラスが使いにくくて変えたいから変えたいんだよ。
それに5重6重にカプセル化されたオブジェクトなんて
邪魔でしかないんだよ。デバッグしにくいし いや、止められるだろ。。そのままリリース出来る方がおかしいだろ
むしろクラスを作る側が>>76みたいな頭の良い人から身を守るために必要
想定してない使用法でバグった時に責任とりたくないもん
Person2に不具合があっても俺には関係ないから好きにやってくれ カプセル化の弊害とかいいつつ
カプセル化すら理解してなくて草生える
>>76を見てると、オブジェクト指向を批判しているのはバカが過剰に騒いでいるだけなんだなと良く分かるw 今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな
>>81
匿名性のSNSの限界。
記名性だと色々と能力が分かって、無視される。 >>76
何がいいたいのか全くわからん。
例えばお前が言ってる頭の悪いやつが、
ローカル変数をグローバル変数に変えるかもしれんよな？
そういう場合、なんだっていうんだ？
ローカル変数が悪いって話をしてるのか？
それを止められないからローカル変数は邪魔といいたいのか？ 初めの書き手が悪いんじゃなくてあくまで変更したやつの責任
>>76
というか、MFCみたいに修正が推奨されて無い場合は除いて、
自社開発のプログラムであれば、能力がある人にはあなたが修正するのを
上司が許可してくれると思うんだ。
もし、修正を許可してもらえないなら、実績が足りて無いか能力のアピールが足りてない。 オブジェクト指向の肝は擬人化と依頼だからな
頼む相手の内部状態を勝手に変えないってのは
無茶重要でしょ
>>88
>オブジェクト指向の肝は擬人化と依頼だからな
初めて聞いた 擬人化キャラ（クラス）の関係性で物語を生成する＝オブジェクト指向
そんなかんじで習ってそのまま理解してたな ちなみに学校は恥ずかしくて
言えないような底辺学校
依頼はどことなく委譲って分かるけど擬人化はただのスケベじゃん
>>91
頭わるくてまともな学校にいけない奴らに
教えるために先生が工夫してくれたんだろうね 依頼ってのも困ったら
依存心の高い奴らに教えるのにそういう言い回ししたんだろうね
いま思えばなかなか立派な先生だったな 口は臭かったが >>92
分かりやすく噛み砕いて教える方法としては良いと思うけど、>>88のように一般的に通じるつもりでいきなり独自用語を使うと話が変な方にいくから、不特定多数を相手にするときは一般的な用語を使った方がいいぞ。 >>91
本来人間相手にしかに使わない依頼や委譲って言葉を使ってる時点で擬人化してる >>76
> お前らの言う頭の悪い奴は元のクラスのprivateを
> publicに変えるかもしれないし
> Personというクラスの隣に
> Person2と言うクラスを複製してそっちの方をpublicに
> 変えて利用するかもしれない。
ねーよw
もう少し基礎知識学んでから出直してこい。
まず、ライブラリの中身を書き換えること自体、ありえない。
たぶん、見ず知らずの人達が書いたコードを共有する仕組みから知らないのだろう。 >>96
いや、そもそもできちゃうじゃん
そして別にできてもいいじゃん
それが嫌だとしたらそれをドキュメントに書いとけよ
ソースには書けないし書いても消せるからさ >>96
いや、周囲や協力会社(依頼元クライアント側プログラマ)
にこれやるやつゴロゴロいるんだって
ソースファイルでもテーブルでも何でも他人が書いたやつ
複製して仕様変更に対応するんだわ。
privateとかカプセル化なんて笑っちまうよマジで
でも意外と何とかなってる、複製したあとはレガシーコードは
全部捨てちまうんだわ
職場で新人研修で「抽象クラスって何のために作るんですか？」
って毎回のように訊かれるけど
「俺にも分からない。必要性を感じたことも、便利だと思った
事も無い。」って正直に答えてる。
オブジェクト指向の入門書に当然のようにabstract紹介
されてるけどそれの有用性を的確に説明している
教科書を見たことがない
interfaceのほうは重要性は分かるしちゃんと説明している >>98
abstractは
上の方の人達が未知の設計概要として会議で使う
コーダーじゃない営業や客とのコミュニケーション用 >>75
これだろ
https://ja.m.wikipedia.org/wiki/DARPAモデル
DARPAモデルとは、インターネットの持つべき通信機能を階層構造に分割したモデルである。
アプリケーション層、トランスポート層、インターネット層、ネットワーク層の4層で構成される。
DARPAモデルという呼称は、インターネットの研究開発を行っていたDARPAに由来する。
元々は確固たる仕様や定義はなく、IPやTCPやUDPなどの仕様中に個々に、あるいは暗黙の前提として存在していたものだが、後からRFC 1122で1つにまとめられた。
IP群はプロトコルとサービスをカプセル化する事によって抽象化する。
通常、より上位層のプロトコルはその目的の達成に役立てるために、より下位層のプロトコルを用いる。
これまでIETFはインターネット・プロトコル・スタックをRFC 1122で定義された4層から変更した事はない。
IETFは7層からなるOSI参照モデルに従うような試みはせず、また標準化過程（Standards Track）にあるプロトコル仕様やその他の構造上の文書をOSI参照モデルに対して参照する事もしない。
https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:UDP_encapsulation.svg
RFC 3439では、インターネット構造に関して第3章の序文に"Layering Considered Harmful （階層化の有害性）"と題された節が有り、
「階層化」という考え方が概念的および構造的にさまざまな利点を持っているが、
実装面では層単位で同じような最適化が繰り返し発生することによる無駄な処理により効率的な実装を阻害し、複雑化を招くことがあり、
また低層部分のみに存在するデータにアクセスできない場面が発生するなど、
インターネット・プロトコルの目指す「単純化」という原則に反することもあることが明記された。 >>98
抽象クラスは単なるテンプレ
クラスを作る際の約束事を規定できる
具体的には実装忘れやメソッド名を間違えるのを防げる
自分のような忘れぽい人間には役立つ >>98
> 「俺にも分からない。必要性を感じたことも、便利だと思った事も無い。」って正直に答えてる。
正直なのはいいけど...なんで、privateの有効性がわからないのに、カプセル化を批判するのか。
無知の批判ほど、初心者が誤解を生む原因になるからやめてほしい。
例えばだよ。
何の言語をよく使うのか不明だが...標準ライブラリってあるじゃん？
その標準ライブラリのクラスに「呼び出したら破綻する(内部処理実装用の)メソッドや変数」が定義されていたら、どうする？
クラスを使う人に呼び出してほしくない機能はprivateにするべきでしょ。
実装する側の都合だけじゃなくて、クラスを使うユーザーのことも配慮して使うものだよ。
OOPアンチとOOP活用者の絶対的な違いは自作したクラスを使う人のことを深く考えているかどうか。そこだよ。 >>103
使う側と作る側が完全に分離した環境に当たったことがない
win32apiや.netframeworkを作る人以外にそんな需要ってあるの？ >>104
win32apiや.netframeworkを作る人には需要があるって認めたの？ って、わからないのは抽象クラスかいッ！
なんか、アンカを間違えたような間違えていないような微妙な回答をしてしまった...。
まぁ、抽象クラスは>>102に書かれている通りって事で。 >>105
俺が作るならいらん
状態をクラスのインスタンスが内部に保持してしまうのは害にしかならない なんか今までノリでクラスで作ってきたのを止めると物凄くスキルアップするぜ
一度はオブジェクト指向をやってみるのもいいかもなってのは思う
クラス構造で便利なものとそうでないものは当然ながらこの世にはあって
そのほとんどが実はクラスにしないほうがうまくいくものばかりだ
大半の処理は
入力→処理→出力
の繰り返しであってこれのまとまりが
機能となる
ただ極稀にクラス構造で考えた方が便利な構造のものもある
役に立つのはその時だけだ
そしてそのケースは極めて稀である
>>104
.netは勿論、Android、iOSネイティブ、バックエンド node.jsやPython、mbed(組み込み)、
まぁ、一部private機能をサポートしていない環境はあるけど、作る側・使う側の意識は常に持つよ。
.netを知っているってことは、Nugetのことは知っていると思うけど...
gradleとか、npmとか、github等と連携させて他人の作ったライブラリの自動追加及びアップデートの仕組みはいくらでもある。
てか、自分で作ったコードですら、作る側・使う側は意識するよ。
過去に作った自分のソースなんて、他人が作ったソースみたいなものだし。
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。 >>107
> 俺が作るならいらん
つまり、俺が作らないなら、必要だって言ったのと同じことだよね 最初からオブジェクト指向は大規模なものを
複数の人で作るためのもので
それをわかってないから、
「俺が一人で作るようなものならいらん」
なんて発言が出てしまうんだよな
>>109
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。
まあこれだよね
頭いいやつには必要ない技術かもね 凡人には必須だとおもうけどな
あと設計思想とかそんな面倒な話じゃなくてシンプルに補完ができるのが楽 >>107
内部に保持するのが良いとは言わんが外部に公開すれば良いってもんでも無いでしょ
いつ何時外部から状態が変更されても破綻しないように責任持てと言われても
僕は頭が悪いから無理です そもそもprivateっていうのはコミュニケーションの道具で
privateって書いていなければ、好き放題アクセスしてOKという意味に
捉えられるかもしれないわけだ。
コメントの高度版なのだからコメントなくてもできるのは当たり前
だがそうすると修正が難しくなる
俺が作るなら〜っていうのはコミュニケーションが
必要ないから言える話
>>112
まぁ、そうだな。
ただ、面白いのが...
頭のいい人がOOPに漬かると、余裕ができた分、コンピューターの仕組みにとらわれずエンドユーザーの事を全力で配慮した品質の高い製品を作れるようになる。 >>111
逆だな
デカければでかいほどオブジェクト指向で組むのはやめた方がいい
内部の状態遷移を誰も理解できない そもそもさ
クラスで状態を保持するソースってさ
実装全部見て
何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
これが最高にダルイ
もう年取ったしこんなの付き合ってらんない面倒臭くて
単なるモジュール切り離しのための技術の一つだよ。
バカが騒ぎまくったせいでクソみたいなインターフェイスによる切り離しで
逆に見通しが悪くなることが多くなった。
細かい粒度で使うような技術じゃない。
>>121
いや、単純に面倒臭いだけでメリット皆無じゃん 内部に状態変数をもたれたらグローバル変数の比ではないほど厄介。
単体テストやデバッグが壮大なことになる。
「状態によって挙動が変わる」ものが何十個も何百個も集まったら誰も把握しきれない。誰も制御しきれない。
>>119
>内部の状態遷移を誰も理解できない
使う側は内部の状態遷移なんて理解する必要ない
理解しないと使えないようならその設計が悪い 内包してる初期化フラグ一つで
全く同じ入力に対して全く異なる出力が出てくるんだから
こいつは厄介だよ
勘がいいやつはこれだけでこの仕組みを使わない
>>124
だからオブジェクト指向で小さくするんだよね >>128
言われない。むしろお前のほうが言われてるだろ。 レス番まで指摘されても自分のおかしい発言に気づけないとはいとあはれ
>>122
めんどくさくて新しい(もう20年以上前からメジャーではあるが...)考え方についていけません、てだけだろw
お前が懸念している内部の状態遷移が見えないというのは、見えなくていいように作り、見えなくていい部分だけを隠すんだよ。
お前の大好きな従来の手続き型だって、下手に作れば手続きを呼び出す順序や渡すべきデータの構造や内容が訳分からない複雑なものになるだろう。
単に自分の知ってる手法では良い設計を知っていて問題点を避けられる、よく知らない手法は問題を回避する方法がわからなくて問題のある手法と思えてしまう、ただそれだけのこと。 クラスの状態はクラスが知ってれば良い
という思想なんじゃねえの？
オブジェクト指向は？
>>135
違うだろ
内部の状態が見えないのにテストなんかできないだろ
そのクラス使ってある限りそいつの状態次第で色んな動作しちまうんだから
はっきり言ってクラスは欠陥製品
特に内部に状態を保持するような使い方は害悪 >>138
お前はオブジェクトの状態として、外部に影響を与える外部仕様の状態と、外部に影響を与えない内部仕様としての状態を混同してないか？
文字列のオブジェクトが文字列"abcd"を持つとして、それは外部に影響を与えるものだから、privateのメンバとして保持されていようがテストケースとしてそれを与えて状態を設定してテストすればいい。
一方、その文字列がどういう実装で保持されているか、ヒープなのか固定配列なのか、参照カウンタやさらに複雑な仕組みを使っているのかといった内部仕様的な状態は、このクラスを他と組み合わせてテストする段階ではテストする必要がない。こういう部分は、先にクラス単体のテストで保証しておけば良い。
そういう切り分けができない作りになっているなら、それは設計が悪い。 >>139
いや、MSのクラスだってなんかよくわからん動作するのあるし
いいとか悪いとかじゃなくて状態を保持したら地獄行き
覚えといてね >>122
めんどくさいのはその通り。
テスト駆動開発の本とか読んでどういうオブジェクトを引数にすると
テストしやすいかが理解できてくるとありがたさがわかってくる。
オブジェクト設計とか言い出す馬鹿は無視しろ。 >>120
> そもそもさ
> クラスで状態を保持するソースってさ
> 実装全部見て
> 何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
> これが最高にダルイ
> もう年取ったしこんなの付き合ってらんない面倒臭くて
だ、か、ら、
それを解決するためのオブジェクト指向だ つってんだろ！
クラスをオブジェクト指向も意識せずに、ただただ構造体みたいに実装して使うから、そうなるんだよ。 >>140
どのクラスを指して言ってるのか知らないが、それはそのクラスの仕様自体の複雑さかお前の理解不足が原因で正しい挙動が分かってないとか未定義動作をさせているとかでないの？
状態を保持するのが問題なのではなく、知っておくべき状態、情報を知らずに上手くいかないのをオブジェクト指向のせいにしているだけのように見えるぞ。 状態をできるかぎり持たない方がいいってのはその通り。
ただ通信ソケットみたいなもの実装しようとすればどうしても状態を持つわな。
コネクション張るオーバーヘッドが小さくない時点で、性能出そうと思えば状態をもつしかないので。
オブジェクト指向って設計手法であると同時に
責任の切り分け手法でもあるんだよね 別の共同体（無償で手伝う気なしって意味で）
と作業する場合は必須でしょ
>>142
は？メソッド全部staticにしてみろ
大半の問題が解決する >>146
解決しねーよ！むしろ、問題が多発するわ！
それ以前に、何の問題が解決するんだよ。 >>145
いやー、クラス内で状態を保持するクラスが大量に呼ばれてて
本来はそれらの全ケースを網羅する必要があるが作業者の裁量で省略されてる状態じゃないっすか？
切り分けじゃないッスよね？
クラスAとクラスBがそれぞれチェックされててもそれらが合わさったことでバグが発生してる可能性もあるンスから
テストはちゃんとやるのであれば状態全網羅でしょう
ぶっちゃけ無理っすわ
状態を保持をやった時点で地獄行き
覚えた？確定事項よ >>147
グローバル変数さえなければ入力に対してぜってー決まった出力しか出ないのに何が問題出るの？
頭おかしいんじゃない？
○○構造のとき作りにくいってのはあると思うけど
わかりやすさでこれ以上はないよ >>148
クラスAとクラスBがそれぞれチェックされててもそれらが合わさったことでバグが発生してる
可能性もあるンスから
こうなったときにAもBも直す必要がないでしょってこと どちらかを直すかは共同体
同士のパワーバランスで決まるんだけどねｗ そこはまあ大人になるしかない >>148
> >>145
> いやー、クラス内で状態を保持するクラスが大量に呼ばれてて
> 本来はそれらの全ケースを網羅する必要があるが作業者の裁量で省略されてる状態じゃないっすか？
何いってるんだ、こいつ。
クラスの基本的な仕組みから理解していないのか。
状態はインスタンスの数だけ持つことになるけど、呼ばれるロジックは一つだよ？
一つのロジックだけをテストすればいいのに、君はstatic化することで、わざわざ一つの状態につき一つのロジックを用意しようとしている。
つまり、君は一つのインスタンスにつき、一つのロジックを記述することで膨大な数のテストをしなければいけない状況を自分で作っている訳だ。
お前のやり方の方が無理ですわ。 >>150
いや、わからないよね？
クラスCで使うためのクラスAとクラスBであるなら使えなきゃしょうがないじゃん
まあ、他でも使ってるなら安全牌はクラスC用のクラスAクラスBの複製だけどｗ しかも、１つの状態につき、一つのロジックを書くってことは...似たようなクラスが10個必要になったら、そのクラスのロジックを10回、コピペするわけだ。
で、その後、ロジックを修正することになった場合...10回、コードを書き直すの？
そっちの方が無理ですわ。
いっそのこと、staticにしないで、10個の状態が1個のロジックを参照するようにしておけば、ロジックの修正は一回で済む。
そっちの方が断然、楽だね。
>>153
ブーメラン刺さってますよ。
私は仕事するので、その間に頑張って言い訳でも考えていてね！ >>152
もしかしてインスタンスの意義がわかってないのか？
他でも使ってるなら安全牌はクラスC用のクラスAクラスBの複製だけどｗ
まさしくこの状態を作りたいからクラスAクラスBのインスタンスをつかうんだけどな クラス使わない人ってどうするんだろ
構造体？
全部インタプリタみたいな感じ？
スレ主の愚痴はオブジェクト指向かどうかと関係ない
単に設計やテストのやり方を知らないだけ
>>138
> 内部の状態が見えないのにテストなんかできないだろ
ん？全部publicにしておけばテストできるって話じゃないの？
もしくはprivateであっても、privateを読み書きできる機能があればテストできるでしょ？ クラス使っても、staticにするとか訳のわからない事を言い出すし、根本的にオブジェクト指向を理解していない人達が愚痴っているだけだよな。
むしろ、何でもstaticにするのはC言語やC++言語から入った初心者なら誰もがやる失敗。
そんな初心者の失敗をいい歳したおっさんが、オブジェクト指向を批判しながらstaticを勧めるから駄目なんだよ。
我々からすれば、俺らの黒歴史時代の経験を何で上から目線で偉そうに語っているんだ？って感じだね。
流石に、上から目線で語る程、俺の黒歴史は酷くなかったぞ。
カプセル化が要らない、と言うのなら、
誰もがデータを読み書きできる状態でどうやってアトミック処理を保証するのか
を教えて欲しいな。
もしかしたら大発明かも。
>>160
内包されるよりいくらかCool
ただ、そこまでpublicにできるならstaticにしてほしい
実行時にstatesがnoneでないと正しく動かないんですよこのメソッドって
言われても知らねーよそんなのって感じ
じゃあstatesはどうやってnoneにするんだべって
俺に調べさせるのやめてもらっていい？
もっと言えばstaticにすればそんなことないじゃん？ そもそも、クラスって正常に動く前提で使うものであって、なんで、クラスを使う側がクラス内部動作をテストしないといけないのかわからん。
クラスのテストは、クラスを実装する側の責任だろうに。
...というツッコミをそろそろしてもいいかな？
>>165
それに類することをすでに>>139で指摘したんだが、自分考えに凝り固まった意固地なおじさんには通じなかったようだ。 >>163
そのstatesがnoneでなければならないという仕様は、そのクラスの使い方として外部に明示すべき仕様だろう。そそういう情報が示されていないならドキュメントの不備だし、そういう仕様が公開されていても外部からstatesの値を参照または設定できないのなら設計の不備だろう。
延々と繰り返し指摘しているように、それはオブジェクト指向そのものの問題でなく正しく設計、運用がされていない問題だろう。 カプセル化の最大のメリットは中で何をしているかどうなっているかは気にせずに
外からは引数を与えると仕様通りの値が戻ってくるというところだよね?
グローバル変数に格納されている値で関数の挙動が変わるより悲惨だぞ。
グローバル変数が見えないんだから。
ここまで話の通じない奴だと思うと相手するのがバカらしくなってくるね。まさに徒労という言葉がふさわしい。
>>39
カプセル化こそが善
カプセル化こそがOOPのうまみ 全部staticってどうするんだろう
メソッドの引数すごいことになってそう
オブジェクト指向のあらゆる用語が
ノムリッシュみたいになってると思う
JavaScriptが発展して、クラス名と同じ名前の
ファイル名にしなくていい事が分かったわけじゃん
それどころかクラスすら必要なしでオブジェクトが作れる事が
分かったわけじゃん
クラス名と同じ名前のコンストラクタなん定義しなくても
オブジェクトが作れる事が分かったじゃん
オブジェクトとは詰まるところ連想配列と大して違いが
ないキーと値で構成された入れ物でしかない事がわかった。
この「連想配列と違いがない」というシンプルな真実が
どれだけありがたいことか
クラスを始めとする様々なルールは
ソフトウェア設計上の重要な概念かと思ってたら
単なるJavaの変な言語仕様でしかなかったわけだ。
変数を「フィールド」
関数を「メソッド」
関数を「コンストラクタ」
こう言い換える必要がどこにある？
こんなノムリッシュなバズワードに
今までどれだけ煙にまかれて
シンプルな真実が見えなくなってたことか
それに加えて
「継承」「抽象クラス」「オーバーライド」
「カプセル化」「ポリモーフィズム」
こんな用語は必ずしもやるのが正しいものではないし
やればやるほどシステムを必要以上に複雑にして
邪魔にしかならないものばかり
それなのに
「オブジェクト指向の本質は継承とカプセル化とポリモーフィズムだ。」
なんて馬鹿げた事を言い始めるノムリッシュな奴が出始めて
JavaScriptならオブジェクトの内部に
別のオブジェクトを入れるという一瞬の操作で
終わるものを「委譲」など余計な用語を定義して
わざわざ定義しなくてもいいようなくだらない
小難しそうな用語だらけになって
「お前はooの概念を正しく理解してない」
という偉そうな批判がどれだけ飛び交うことか
webフレームワークの
MVCの「モデル」ってそんなに重要ものなのか？
「モデル」なんてものがSQLやDBMSを隠蔽して
何がありがたいと言うのか
むしろ隠蔽されて困ることの方が多いんじゃないか？
何故一度テーブル作成時にて定義した
大量の列定義を
またモデル層のフィールド定義で2度もやり直さないといけないのか
要らないだろ。「モデル」なんて
最近は従来軽視されてきたクライアントサイドJavaScriptの
方がよっぽど重要なことが分かってきて
ReactやVueのようなクライアントサイドフレームワークが
重要視されてるわけじゃん
「オブジェクト指向」って結局何がありがたいのよ？
> 「オブジェクト指向」って結局何がありがたいのよ？
多くの人で作業分担し、協力してプログラムを作れる所
>>177
Javaなんてクソを
オブジェクト指向の代表として考える
かわいそうな子 >>183
Javaはオブジェクト指向を採用した言語の一つだよ
いつから代表になったのさ
お前が代表だと思っていて、代表だと思ってる自分自身を批判してるだけじゃんｗ >>185
お前の文章の話をしてるんだが。
そもそも読んでないのに、抽象化が何の関係があるんだ？ >>184
>>177
＞クラスを始めとする様々なルールは
＞……
＞単なるJavaの変な言語仕様でしかなかったわけだ。
で、「いつから代表になったのさ」がなんだって？
数スレも遡れないようじゃ生きていくの大変だろうに…… 関数化したりクラス化したらプログラムが高速化したんだけどGCが発生するタイミングが細かくなったってことでええんか？
オブジェクト指向は整理術
棚なんて要らん棚があるから余計な物も管理する羽目になると床置する人が現実に居るのと同じ
まああまりに糞な抽象化だともう全部publicでレコードとして扱えやとは思うな。
抽象化を万能なものと思い込みすぎな馬鹿が多すぎるからオブジェクト指向に対する誤解が生まれる。
っていうか抽象化ってどんな仕様のどの部分を一括に扱ってるのか？
ドキュメントがないと最悪
ここの仕様は特殊だからこれとは別にしないとなって話ができない
ドキュメント書かないなら抽象化するな
害悪でしかない
>>190
直置きはダメだが
ほとんどの場合「棚をしまう為の棚」
「それをしまう為の棚、それをしまうための棚…」
ってなってる
で、「ハサミ使いたいんだけどどこにあったっけ？」
って探すのに非常に苦労する。
見つけやすくするための棚だったはずなのに。
それどころか
棚「ハサミは内部で使うから自分で使わなくていいです。
『切る 』という目的だけに集中して、そう命令してください」
と、棚に言われる。
しかし切られた結果を見ると自分が欲しかった結果と微妙に
違うことがよくある。
だから「もう俺が直接切るから、いいからハサミをよこせ」
っていう話になる。
あと抽象化については
「これは抽象的な棚なので中には何も入っていません。
私を参考にした具体的な棚が何処かにあると思うのでそれを
探してください。」となる。
じゃあ「具体的な棚って一体どれだ？なんか長い名前の棚が
やたら沢山あるけどどの棚から探せばいいんだ？？」
となる >>193
たとえ話はややこしいだけで何の意味もないから
具体的な事例で言えよ 具体的に何のことを言ってるのか
考えなきゃならんようなたとえ話に価値はねーからな
説明が下手すぎる
>>193
整理が下手なやつの例をあげて、だから整理はすべきでないと言ったって意味がないだろう。 このスレにstaticおじさん、絶対沸いてるだろ。
>>193
だから具体的な問題>>162に答えてくれよ。
複数のプロセス・スレッドが勝手気ままにデータを処理しても問題ない、というならおめでたいわ。 >>198
そんときだけ使えばいいじゃん
それ以外じゃ使うなよ >>198
アルゴリズムレイヤーでアクセスを無駄に禁止するようなクラスは有害でしかない。
適切なpublic具合というものがある。
例えばc++のstd::vectorなんかはかなりオープンアクセスなクラスだがあれが適切なんだよ。
でもって馬鹿に適切なアクセス制御なんて無理ってこと。
変に細かくするな。
馬鹿はクラスレベルで制御なんかしないでいいからモジュールレベルでアクセスするapiだけ公開してろってこった。 トレードオフを理解できてないうちはどっちもどっち
物事の一面しか見れてない
>>190や>>193の比喩は理解の程度が知れるという意味ではすごく有意義 >>200
たぶん、162はクラスユーザーが呼び出した処理を実行している最中に内部処理を呼び出したら破綻するけど、いいのか？って言いたいのだと思う。
適切なアクセス修飾子をつけろは同意だが、彼に言うことではないと思う。 まぁ、スレッドがどうこうは...private関係あるのかな？って感じですが。
>>199
好き勝手にデータに読み書きできるのに、どうやって「その時だけ」を保証するんだよ。
結局カプセル化必須じゃねぇか。
何のアイディアも無しか。アホらしい。 >>206
そういう場所だけそうすればいいじゃん
全部そうなら無能過ぎてプログラム組む前にもっとやることあるんじゃないかなぁ 大昔、Javaやりだしてイキりだしたやつらが、オブジェクト指向もできない
老害とか騒いでいた歴史がある。そんな老害から見ると、gcに難しい事をまかせて、
馬鹿を吊り上げる仕組みなんだよなあ〜と皆言っていたのを思い出した。
今はPythonね。もっさ〜として、ダサすぎ。でも「俺AIの最前線だぜ」とか勘違い。
歴史は繰り返すのだ。
atomicityを保証するのを
呼び出し側の責任とするのか呼び出された側の責任とするのかは
pros/cons考えて使い分ければいい話でカプセル化必須とかにはならないよ
使う前にopenして終わったらcloseしてください的なAPIと
open/close含めて全部やってくれるAPIの違いと同じこと
>>208
> イキりだしたやつらが、
> 馬鹿を吊り上げる
> ダサすぎ。
うわぁ。典型的老害だな。 すげえ、スレタイも日本語になってなくて、さらにまともな議論にすらなってないのに盛り上がってるw
オブジェクト指向じゃないやつのオブジェクト指向型言語のコード見れると思ってきたが、カオスだなw
staticおじさんの詭弁ばかりで議論にすらならないから、もう、staticおじさん隔離スレ作った方がいいかもね。
【隔離】オブジェクト指向アンチスレ
みたいな感じで。
>>212
もういっそのこと、こんなんでどうだろうか？
【老害】staticおじさんと戯れるファンの集い【詭弁】 カプセル化はオブジェクト指向に限らずあるんだが
privateにして外からアクセス不能にすることをカプセル化だと思ってる奴は完全に勉強不足
privateとprotectedの使い分けってみんなどうしてる？
俺は昔はpublic以外はよほど理由がない限り全てprivateにしてたんだけど、最近はよほど理由がない限り全てprotectedにするようになったわ。
protectedはよくわからんので基本private
必要になったらprotected
必要ないならprivateでいい
変更してはいけないというルールはないんだから
オブジェクト指向は素晴らしいだろ
金正恩という概念から好きなだけ金正恩を生み出せるんだぞ
staticじゃ1匹しか生み出せない
その1匹が糖尿で死んだら北朝鮮は成り立たない
金与生は金正恩を継承したクラス
もしくは金日成の多態
将軍様クラスのプロパティに性別があったとは思わなかったけど
金正恩というデータから好きなだけ金正恩産み出すのはオブジェクト思考に限らずできるんだが
オブジェクト指向と全く関係ない
勉強不足
>>214
> privateにして外からアクセス不能にすることをカプセル化だと思ってる奴は完全に勉強不足
それな。
カプセル化はクラス使用者にとって必要な機能やデータを公開し、その他内部実装を秘匿することで標準ライブラリの如く使いやすいクラスを作りましょうという実にシンプルなものなのにね。
>>215
基本的にはprivate。自分が定義したメンバ変数やメソッドを継承先がどのように使うのか想像ができないのなら、privateにした方がいいと思っている。
継承先で意図しないメソッドの呼び出しや、変数の使い方をされたら困るからね。
当然、継承先での用途を考えた上でprotectedを使う場合もあるけどね。 いやもうお前らprivateとかprotectedとかいう言葉を使ってカプセル化を語るのやめたほうがいいよ
privateという機能がなくてもカプセル化は実現できるから
百歩譲ってデータ隠蔽だけをカプセル化と呼ぶにしても、privateのように外からのアクセスを不能にする機能がなくてもカプセル化は実現できるし
>>224
そんな方法あるんだ、どうやってやるの？ >>222
オブジェクト指向でしか出来ないことがあるとでもw pimpleパターンくらいは知っとけよ。。
てかカプセル化について馬鹿みたいにこだわる奴でまともなインターフェイス設計できる奴見たことねーわ。
リファクタリングもしないで一発で正解にたどり着けるとでも考えてるんだろうな。
pimple 覚えた pimple ニキビ 覚えたpimple pimple
オブジェクト思考言語アレルギーの老害は論外として
特定のオブジェクト指向言語を習得している人は無数にいても、
オブジェクト指向そのものを理解してる人は殆どいなそう
>>229
それってオブジェクト指向という概念そのもの
がおかしいものだからですよね？
っていう議論をずっとしてるんですが
誰にでも理解出来て納得出来ることが正しい
ことだと思うんですが > オブジェクト指向そのものを理解
どういうこと？
アランケイがどう考えたとか
OOPがどういう成り立ちだとかそういういこと？
アランケイが考えたオブジェクト指向は洗練され完成されたオブジェクト指向なのです。
初号機が最強であるのはどこの世界でも同じことです。
初期版が完成です。改良などありえません。
第一、privateサポートしてない言語なんて普通にあるしな。Javascriptなんてそうだし。
>>223
>カプセル化はクラス使用者にとって必要な機能やデータを公開し、その他内部実装を秘匿することで標準ライブラリの如く使いやすいクラスを作りましょうという実にシンプルなものなのにね。
カプセル化といった時に一般的な定義は2種類あってそれはそのうちの1つで情報隠蔽(Infomation Hiding)とほぼ同じ意味
もう一つはデータとそれを操作する関数/メソッドを一つの単位に束ねることを言う(隠蔽されてるかどうかは気にしない)
人によっては2つを合成した定義でカプセル化という言葉と使ってるので
まともな議論をしたければどういう定義でカプセル化と言ってるのか確認する必要がある 自分が議論したいというよりは...
このスレ主と>>138みたいな謎方向の議論をする人の思うカプセル化について、そりゃ違うだろって言いたいだけ。
215への回答は聞かれたから答えただけで深い意味はない。 >>235
違う違う。情報隠蔽のことをカプセル化と間違っていってる人がいるだけ
カプセル化の定義は必要なものだけをインターフェースとして提供する
必要ないものは隠蔽するってことなんだが
全部必要だから公開しているのに、カプセル化されてない！って言うやつがいるだけ >>237
>カプセル化の定義は必要なものだけをインターフェースとして提供する
>必要ないものは隠蔽するってことなんだが
情報隠蔽と何が違うの？ >>240
情報隠蔽は、情報隠蔽しなければカプセル化じゃないって騒ぐが
必要なものだけを公開するなら、情報隠蔽しなくてもカプセル化 俺は...カプセル化の本質さえ抑えておけば、言葉としての違いは気にしないけどな。
privateにすること=カプセル化だと勘違いしていても、そいつがカプセル化の有り難みを理解できているのなら、深入りしないだけだよ。
言葉の定義にどこまで拘るかは議論の相手次第。
だが、staticおじさん、貴方は駄目だ。
俺のような細かいことを気にしないレベルの人間ですら駄目だわ。
昔からオブジェクト指向を批判し続けて初心者に誤解を与える老害だから見つけ次第、徹底的に叩く。
オブジェクト指向を勉強してる意識高い系のアホが
引数も戻り値も使わず、全部インスタンス変数使ってる例を見て
僕はstaticおじさんになっちゃいそう
>>241
必要なものだけを公開するってことは
必要じゃないものは公開しない、つまり隠蔽しているんだから同じじゃない？
“隠蔽”の捉え方が違うのかな 構造化プログラミングをできるようになって
データと関数をオブジェクトとしてまとめるともっと良いかもと
オブジェクト指向を身につけるならいんだけど
オブジェクト指向では名詞を抜き出すんだ
そうやってオブジェクトを分ければ良いプログラムができあがるんだと
オブジェクト指向に幻想抱いてるアホが作ったプログラムは手に負えん
>>244
隠蔽を必須としてる、隠蔽のことだけをカプセル化と言ってるやつがいる
それが間違いということ >>245
オブジェクト指向に幻想抱いてる天才が作ったプログラムなら手に負えるだろ？ 僕は天才だからわかる
僕のどこが天才なのかは説明できないけどわかって
>>248
どうでもいいよｗ
プログラムが手に負えるかどうかは、アホかどうかが焦点だろって話
お前が長々と書いてることに意味がない >>250
焦点はそこじゃない、どこみてんのよ！
構造化プログラミングの実装技術の先にオブジェクト指向があることを
理解してない人間をアホと言ってるんだよ、焦点はそっち >>251
だからオブジェクト指向自体には問題がないって言ってるんでしょ？ 人の話と技術の話の区別ぐらいつけよう。
人をいくらアホだ馬鹿だと叩いても
技術を否定したことにはならない
ListやStack、HTTP Clientといったものはオブジェクト指向と見事に調和するんだけど
それは変えられることがないから、これはこういう機能のものだってのが決まっていて
システムの仕様が変わっても変更されることがない
いっぽうでビジネスドメインにオブジェクト指向を適用しようとすると
仕様がころころ変わるから最初の設計ではうまくいかなくなることが多い
仕様が変わったらオブジェクトの設計もやり直せるならいんだけど
一度システムが動き出したら数万〜数億の人が影響受けるから
なかなか変えられないのが実際のところ
カプセル化されると困るというのはそういう状況の話じゃないかと僕は思いました
ドメインの安定性によってオブジェクト指向の適否は左右されると天才の僕は提言します
>>252
オブジェクト指向に幻想を抱くアホを作り出すオブジェクト指向の功罪は大きい
実装と離れて語られるオブジェクト指向は宗教と言っても良い >>255
お前がそうであってほしいと願ってるのはなぜ？ｗ カプセル化するなら
一切ソースコードレビューしなくていいんだな
変数やメソッドの命名もインデントも全部
適当にやるからな
文句つけるならテストの結果だけで文句を言って
くれよ、ソースコードには文句言うなよな。
例外をキャッチする必要もないな。
俺が利用するクラスで発生した問題はそのクラス内部の
責任だ。内部事情は意識しなくてもいいんだからな。
おっとロギングも内部事情だからやる必要ないな。
そんな事情は利用側は知りたくもないし結果だけが
欲しいんだもんな。
逆にこれらを押し付けるなら全部publicで問題ないよな。
クラスの内部を知りたいってことだからな。
「↑こいつはカプセル化が何なのかを理解してない。」
カプセル化おじさんがどうせこう言うだろうから先に
言っておいたわ。
>>259
「↑こいつはカプセル化が何なのかを理解してない。」
いや、先に言っておくと言っても、俺も同じこと言うんだが、
それで言われることを予測していたんだろ？
反論までは用意してないの？ 珍しくこの手のスレでは比較的、リアルな批判がでたかも。
汎用性の無いビジネスドメインをオブジェクト指向を意識しながらクラス化したところで、メリット薄いよね？って話はまぁ、理解できる。
でも、ビジネスドメインを構成するクラスを汎用性の高いクラスだけで構成させることができれば、大分スッキリする。
いや、ほんと、そこがオブジェクト指向信者の腕の見せ所なんだがな。
たぶん、ビジネスドメインの責務分割の仕方を誤って神クラスを作ってしまうパターンにはまってるのかも。
でも、まぁ...開発者の立場次第にもよるのかも。
俺みたいに自社開発しているエンジニアだったら、利益を上げるレベルの品質を根拠にいくらでも納期を伸ばしてもらえるので、ド丁寧なオブジェクト指向プログラムを書く余裕があるけど、受託開発になると納期がギリギリに設定されがちだし(偏見？)、そんな最中、丁寧なコードなんて記述できるかって言われると...まぁ、どうなんだろうね。
「状態によって挙動が変わる」ものが何十個も何百個も集まったら凡人には把握しきれない。
ましてや内部の状態が読み取りすらできないとなれば絶望的なことになるのバカでもわかる。
ウェブシステムや業務システムみたいにデータベースという巨大グローバル変数群を構造体にコピーしては書き戻すというのを繰り返すだけだと深い階層化が発生しないから問題は起きないんだろうね。
>>260
お前が俺の書いたことに反論してみろ
お前が言う真のカプセル化とやらを説明しろ。 >>259
前半はコードの品質をどういう観点から担保するかという話
例外やロギングはどういう責務/役割をどこに持たせるかという話
どちらもオブジェクト指向特有のものではない 問題が起きやすいのはハードウェアに近い低層と、ライブラリ層と、ビジネスロジック層なんかに分業している分野だろうね。
>>261
お前の主張の最大のメリットであるスッキリがお前の主観でしかない
そもそも設計書とソースの構造を一致させるための設計技術ではないのかな？ データベースを使っているようなシステムはまず深い階層化は起きない。
RDBと階層化は相性が悪いからね。
それなのに深い階層化を使っている気分になっている人が多い。
ハードウェア制御絡みの本当に深い階層化を経験している人とは住んでいる世界が違う。
だから話が噛み合わない。
みんな難しく考えすぎｗ
オブジェクト指向はインテリセンスが効くんで便利
それで納得しろよ これがないとダルいだろ
>>267
> お前の主張の最大のメリットであるスッキリがお前の主観でしかない
事実を主観でしかないと批判されましても困るね。
実際、汎用性の高いクラス...それこそ、listやstack、http cliant並みに汎用性の高いクラスだけでプログラムが書かれてたらスッキリするだろ。
代替案があるなら、どうぞ。
> そもそも設計書とソースの構造を一致させるための設計技術ではないのかな？
何の話？ スッキリって何？コードが短くなるの？
頭悪いから50行以上は読めないんだけど
>>270
いや、スッキリの定義は？
俺が見たらねっとりしてることない？ >>263
その深い階層を扱うのはC言語でしょう？
C言語はオブジェクト指向です！ >>261
ドメインが安定してるところはオブジェクトを作って
ゆるふわなところは骨組みメソッド作る感じ？
それなら僕と同じです いや、普通にOOPのコードだけど...。
逆に、list,stack並みに...で、なぜ伝わらない。
当たり前すぎて伝わらなかったのか、初めて聞いた単語だから伝わらなかったのか。
このスレの連中だと高低差激しすぎてコミュニケーションが難しいな。
>>274
強いて言うのなら、ドメインが安定しているところに見える範囲がオブジェクト指向信者とオブジェクト指向使いとstaticおじさんで、どれくらい違うのかなって感じですが。 こうなるんだったらもっとこういうオブジェクトにすれば
良かったと思うことがザラにある
今最高にきれいでも未来の仕様変更でど汚くなることもある
いま汚くても未来の仕様変更がきれいにできることもある
その見極め方が僕には未だにわからない
>>269
いや動的になる分、効きづらくなるだろばか。
それでもモジュール切り離しの視点で良いこともあるってのがオブジェクト指向の旨みなわけだが。
依存逆転のモジュール構造が作りやすいってだけの話なのにバカが変な哲学持ち出すから
カスみたいな輩がお前はわかってない、俺が真の意味を理解してるとか言い出すわけだよ。 依存性を逆転させて良いことがあるっていうんですか！？
業務で扱うようなある程度複雑な仕様をどう設計して実装するか
みんなでプログラミングして比較してみたいねー
>>281
内容によるんじゃないかな
みっちりコントロールフローが1万行あったら嫌だけど
御経がほとんどを占めてたらわかるだろうし徳が高まりそう >>282
業務というのはIBM（International Business Machines ）より
パンチングカードの集計から始まっているので
主にアンケート調査結果や在庫管理プログラム
の設計ということになるだろう >>282
業務に限らず、OOPに限らず
そもそもはそれが問題なんよ
複雑さそのものが
ある程度以上複雑なモンは人類にはムリなんよ
それが人類とプログラミングの関係なんよ
サンプルプログラムや学校の課題書いたり
趣味で小さいの書いてる連中と
ある程度以上複雑なモンを書いてる連中とはまずそこからして
想定してるもんが違いすぎる >>285
きっと>>282は
小さな趣味プログラムでも大きな業務プログラムでも
ほらね、カプセル化したコーディングだとあーだこーだ
だからいったじゃん
「カプセル化は絶対にやめろ！」
という結論にもっていきたいだけだお 「オブジェクト指向は高度で複雑な事をやる技術者
だけが恩恵を受けられるもので簡単なシステム
書いてるような凡人プログラマは恩恵を
感じにくい。」
だったら入門書でそんなもの教えるな
初心者プログラマにソケット通信や
システムコールやカーネルみたいな話を
いきなり教えるんか？
凡人にとってオブジェクト指向は
邪魔でしかないんだよ。
高度な技術者の勝手な利便性を
凡人に押し付けるな。
凡人の方が大多数なんだよ。
何でプログラムやってるんだ？
もっと簡単なことがあるだろ
>>286
どうだろ。
staticおじさん(「オブジェクト指向ってしっくりこないんです」の記事を書いて炎上、詭弁を重ねて意固地にstaticを薦めた有名な老害)じゃないのなら、まだ、大丈夫なんじゃね？ それ以前に、カプセル化は絶対駄目の結論に持っていこうとしているのか？
日が変わるとID変わるから、誰が誰だかよくわからなくなってきた...。
何事も程度次第
ただ丁度良い程度を知るのは少数の天性のセンス持ちだけで
凡人には理解できなかったり極端に走ったりする
俺は凡人とセンス持ちの間、というか凡人の域を超えられないのかなあ
プログラム書くたびにどの程度で済ませるか、いつも迷ってる
OOP批判の大半はクラス設計の難しさによる
OOPによってもたらされたクラスライブラリが
十分に使いやすいのに対して
自分でクラスやインタフェースを作ろうとしたとき
納得の行かない結果になる
問題の切り分けが出来ず
再利用性のある単位ぴったりにフォーカスできず
一緒にあるべきものを別にしたり
別にあるべきものを一緒にしたり
縦に割る物を横に割ろうとしたり
いろんな判断をあやまった結果
最後に、クラス設計が悪いのではなくてOOPそのものが悪いと断ずる
>>287
別に初心者だってオブジェクト指向の恩恵は受けられるだろう。良くあるコンテナや文字列とかの基本的なものだってオブジェクト指向的なものだし。
それに初心者の内からオブジェクト指向について知っておく、慣れておくことは重要だろう。
世の中の便利なライブラリやフレームワーク等の多くはオブジェクト指向で作られているからそれを使えるようになるために必要。
自分で設計するのも初めは難しいが、理屈や理論を学びながら実例に触れ、試行錯誤しながら徐々に慣れていく。
何より、初心者だからとオブジェクト指向をまったく触れずに手続き型のみで経験を積んで、ある程度自分なりのノウハウや経験論を身に付けてから別のパラダイムを取り入れようとすると、中にはアレルギー反応を起こして適応できなくなってしまう人もごく稀にいるから。 長い上に全く中身がないな
スッキリ以上のオブジェクト指向のメリットは出てないからね
これで技術者やってるつもりなんだから早く死ねよ
>>295
お前の無駄口程、無駄な発言は無いけどな。 カプセル化って別に外部からのアクセスを不能にすることじゃないよ
外部から『直接的』にアクセスさせることを避けて、そのかわり外部向けにわかりやすい何かを提供すること
現実のカプセルのように、扱いにくいものを隠して扱いやすく提供すること
別にカプセル化してもリフレクションやその他諸々で遠回りなアクセスが可能なこともある
カプセル化ってのはかなり意味の広い言葉で、「臭いものに蓋」みたいなこと全般をカプセル化と呼ぶ
極端な例だと、関数にわかりやすい名前をつけることで関数内部を見なくて済むようにすることもカプセル化と呼ぶ
>>288
いやいや兵隊がよくわからないのに使えるするのが
オブジェクト指向の利点の一つだろ つかそれができないなら
オブジェクト指向にする意義がない まあ兵隊がよくわからないのに
使えるぐらいのオブジェクト指向ができるなら、設計した本人たちは
そもそもオブジェクト指向にしなくても出来ちゃうって逆説はあるわな >>293
その通りだと思う
オブジェクト指向で作られたOSSの、ライブラリは
とても便利だし、役に立つと思う。
なら初心者や凡人へはクラスをインポートして使い方
のみを教えるべきで、クラスの作り方なんて
教えない方が親切だと思う
正直、自分でクラスなんて作りたくないし
組織内のメンバーが作成したローカル内の
クラスなんて利用や継承したくないし
自分が作ったクラスを誰かに利用して
欲しくない、使い捨てで十分。
再利用性は以前自分が書いたコードを複製
して微修正すればいいよ、
自分が書いたコードだから修正箇所は
把握してる。
JavaScriptやpyみたいな言語はオブジェクト指向
導入してるけどクラスの作成は必須じゃない
だけどJavaみたいな静的言語はクラスの作成が
必須になってる。ここがおかしいと思う。
クラス作ること強制してる言語仕様やフレームワークは
おかしいと思う。 そして再利用しようとすると微妙に仕様が変わって結局中身を改造しないといけなくなる罠。
汎用的なパーツ以外はクラス化すると余計手間かかるな。
なんというかprivate云々とかそういう次元の話じゃないよねこれ
なんか脱力した
再利用しなくてもテストしやすくなったりするからオブジェクトは素敵な概念だと思うよ
修正が必要になったとき、それを使う側に影響を与えないっていう性質があっていっぱいちゅき
このスレタイの主張、可能なら複数の言語で、
オブジェクト指向で書かれたそれなりの量のコードを、
それより機能的で保守性があって行数も少なくて万人が読みやすいようにリファクタリングするとかして証明して欲しいなあ
それがプログラマの矜持ってもんだと思う
コードで語れってね
バカなやつほど長文で演説した挙げ句オブジェクト指向のメリットをスッキリ以上のモノを挙げられない
レスしにくるなよ惨めだから
>>282
一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
データベースに出し入れする際の受け皿となる構造体が1層あるくらいだろ。
そもそもRDBは階層構造そのままぶち込めないし。 >>307
最近流行りのPythonで作られたシステムを見て回れば？
カプセル化は言語仕様で禁止されてるから強制的に>>1の言うとおりに作るしかない。 >>307
というか最初の開発で問題になるようなことではないからソースコードでは比較できないでしょ。
機能追加・改修案件で発生する問題の話だし。 これオブジェクト指向の善し悪しじゃないよね。
改修発生時に雲の上で決まった無茶な追加仕様にどれだけ耐えられる構造にできるかという話だ。
ただオブジェクト指向は昔ながらの教科書どおりにやると耐えられない構造になりがち。
もちろんオブジェクト指向でなくても発生する。
C言語でも発生する。
そうならないようコーディングの約束事を決めよう。
そうなってないかコードレビューはしっかりやろう。
>>311
へーPythonにはアクセス修飾子がないんだ知らなかった
命名規則でこれはprivateなものだよと示すわけね
JavaScriptみたい >>311
>カプセル化は言語仕様で禁止されてるから
ソースは？ Pythonにアクセス修飾子がないことはググればわかるじゃん
>>310
構造体が別の構造体を参照してるデータ構造は階層構造とは呼ばないということかな？
階層構造の深さがカプセル化やオブジェクト指向と何の関係があるの？ そう言えば日本の業務形態には貧血ドメインの方がよく適合するなんて話があったなあ
貧血って言うと悪い印象があるからシンドメインとかスリムドメインに言い換えて
スリムドメインの方が優れてるんだって風潮がそろそろ出てきても良いと思う
>>317
“アクセス修飾子がない” == “カプセル化が言語仕様で禁止されてる”
=> False そもそも、一昔前ならソフトウェアは
製品化して値段を付けて売るって考えがあったから
保守や仕様変更の影響範囲について関心が高かった。
だからオブジェクト指向は必要だったかもしれない
だが現在ではソフトウェアは基本無料が当たり前だし
プロジェクト依頼元の依頼を受けてオーダーメイドで
システムを作るから依頼元だけが金を払ってくれるの
であって
あとはスマホアプリを無料配布して
そのアプリで課金してもらって金を稼ぐみたいな
稼ぎ方だから、ソフトウェア自体に売却する価値はない。
売却する資産価値がないからオブジェクト指向で
保守する価値がない、使い捨てにすればいい。
実際、スマホアプリとかのほとんどが軽微なバグ
とか沢山潜んだままリリースされていて、ずっと
放置されてたりするじゃん。
>>321
ポインタは横の繋がり
上下関係ではない
深い階層化というのは、雲の上で決まった仕様に底辺開発者は意見できないということ。
深い階層化というのは、底辺開発者が受けてるパワハラなど雲の上は知らないということ。 >>323
では君と僕のカプセル化の定義が異なるだけじゃん
君のカプセル化の定義で僕が言ってることを解釈するからFalseになる
僕が言ってることは僕の定義で解釈したらTrueになる
アクセス修飾子が存在することをカプセル化可能と定義します
よろしくおねがいします >>327
“カプセル化可能” == “言語仕様でカプセル化を禁止している”
#=> False >>328
だからさー君のカプセル化の定義を知らないしそれを言ってもらわないことには
真偽値だけ言われても僕どうしたらいいかわからないよーえーん(T_T) カプセル化とはアクセス修飾子でprivateにできることを言います
>>326
>>310
>一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
このレスに書いてる”階層構造”の定義を聞いてるに
全く違う”階層化”の話を出されても困る
特に考えてなかったんなら別にそれで構わない >>328
バグってた
“カプセル化不可能” == “言語仕様でカプセル化を禁止している”
#=> False >>332
データベースで深い階層化が起こるとすれば、
・データベースの出し入れはストアドプロシージャ経由のみ
・誰かが作ったストアドプロシージャを叩くライブラリ
・末端開発者が見えるのはライブラリのみ
という状況 >>333
なんでFalseになるか説明できる？
できないんだったら君は間違ってる >>336
何が違うんですか！？なんでですか？説明してください！ >>338
定義が違うから説明しろと言われても困る >>343
なるほどね、アレルギーが、そういうことね 安価ミスってんじゃないよ！！
納得した僕が馬鹿みたいでしょうが！！
カプセル化には強度があります。
C言語のヘッダやJavaのprivateといった言語機能として
カプセル化できることを強カプセル化と言います
JavaScriptやPythonのように命名規則によって使用者に
知らせるカプセル化のことを弱カプセル化と言うのです。
>>348 僕のこと見直してくれてもいいです カプセル化こそ
すでに時代遅れだったんじゃねーの？
>>351
これまでの話を統合した結論として、
いまはgitなどバージョン管理差分確認ツールや
エディタやIDEの機能が充実してるから
言語機能でカプセル化して
「内部を意識しない」ように隠蔽したり制限するのではなく
開発ツールを駆使して内部を意識はするけど
ソースの仕様変更切り替えに対応しやすくなっている
やり方が主流
開発ツール進化によりカプセル化はその役割を終えた。
継承や抽象クラスやオーバーライドも非推奨
これをやると同じ名前のメソッドが沢山あって
IDEによるプロジェクト内キーワード全文検索を
阻害するから >>355
カプセル化しなかったら仕様変更がしやすいのか、なるほど >>356
読解を間違えています
カプセル化をしないことで仕様変更しやすくなるのではなく
カプセル化を「しなくても」代わりに
開発ツールが充実してるから
ブランチ切り替えや差分確認でスマートな
仕様変更と仕様切り替えが可能です。
だからカプセル化はもう不要になりました。 >>357
カプセル化せずに発生するオブジェクトを破壊するような変更を
差分確認で見つけ出せるわけですね、差分確認が重要ですね >>355
×これまでの話を統合した結論として
◯これまでの話はすっ飛ばしてボクの言いたいことだけを言うと IDEの助けがあるとは言え、grepした時の重複は勘弁して欲しい。
どれやねんっていつも思う。
本当にOOPってメンテしやすいんだろうか？
世界的超人気言語はC言語、Java、Pythonと変遷していってるわけだけれども
たしかにカプセル化の機能は時代とともに弱まってるように見える
>>359
そのオブジェクト破壊って一体何を意味してる？
多少オブジェクトが破壊されたところで
アプリは動くし すぐバグになる訳じゃないだろう。
多少経験あるプログラマなら知らないオブジェクトへの
破壊的代入は軽率にはやらないだろうし、
オブジェクトのバックアップ変数作ったり少し考えれば
それくらいやるだろう。
やる時はどうしてもやる時はそうせざるを得ないからやる訳で
破壊するのにもそれなりの理由があるんだよ。
それをprivateとかprotectedするなんて余計なお節介
もいいところ
そして、そういう操作の是非は
gitでコードレビューできるだろ。 カプセル化って一種の安全装置なわけだし、作業性とはトレードオフに
なるわな どちらかを選択するなら当然安全装置を選択するが
使い捨てだの再利用しないだの
素晴らしい含蓄をみずほレベルの巨大案件に適用してれば歴史が変わっていたかも知れない
>>364
Javaでいうところのprivateやprotectedの値を書き換えたり参照したりといったことを
オブジェクトの破壊と言ってます
コードレビューできるっていうのはそれをやらないと洗い出せないってことでしょ
カプセル化の機能を使っていれば実装時に気付けることをレビューまで先延ばしにすることによって
得られることがそんなに多いのですかね たとえばこの先Pythonが、名前が_から始まるメンバに外からアクセスすると
構文エラーになるようになった場合、動作するプログラムにカプセル化を破壊するような
操作がないことは明白になるのでとても便利だと思います
Pythonぐらいの緩さが一番バランスいい気がする
人気があるのも納得
>>370
そうです、そのdart的な感じです
dartを使ったことがないので僕は知りませんけど アクセス修飾子でアクセス制限をかけてしまうと
テストすることさえできなくなります
これがカプセル化の圧倒的な弱点です
privateではありつつもテスト時などにアクセス可能なバックドアが必要で、それが現代のプログラミング言語には欠けていると思います
>>373
そのへんJavaとかリフレクション駆使して回避してるので構造的、致命的な欠点とは言い切れないと思うよ。
リフレクションがバックドアと言われたらそれはその通りなので反論できないけど。 グローバル変数使用禁止の
public staticが唯一無二の解決策だというのにわからん奴がいるな
>>373
テストでアクセスするならそれはpublicにすべきもの
言い換えると、テストですらアクセスしないものをprivateにする >>372
テストするならpublicにすればいいだけ まず重要な前提として
システムの仕様変更というのは
appのソースコードの変更だけではない。
データベースの変更や接続してる外部サーバや
ストレージに関連する仕様変更とかもある。
そして、カプセル化を初めとするオブジェクト指向の
設計技法はメモリ内の瞬間的なごく狭い範囲の
事しか考えてない。
外部環境の仕様が変わったり、フェイルオーバーなどの
不具合が起きてシステム全体のデバッグしたり
不具合調査するときに、app層がカプセル化されていたり
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
想像に難くないと思う。
仮想化やクラウド化が進んでる最近では
こういう外部環境の隠蔽は逆に困るんだよ。
>>378
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
逆説的だがこれが利点の一つなんだ 手続き型だと
直したつもりになることが多々あり 新たなバクを生む
時間が多少かかっても形式的に処理するべき >>376
それはないわー
テストは全メソッドやるでしょ
全部publicにしなければいけないなんて間違ってると思います！
僕はそれ間違ってると思います！ >>377
publicにしたら別のオブジェクトからアクセスされちゃうじゃん
そのメソッドは内部の状態と深い関わりがあって勝手に呼ばれると困っちゃうの
みたいなことあるじゃんテストのときだけpublicにするのはヤリマンだし テストを別オブジェクトにするのが間違ってるのかもわからんね
データと関数をセットにしたものをオブジェクトと呼ぶように
データと関数とテストをセットにした自己メンテナンス完結型のものをアクターと呼ぶことにしようよ！
>>380
> テストは全メソッドやるでしょ
全メソッドやるかどうかはその人次第
テストするならpublicにする
それだけの話
テストするということは、そのインターフェースは
外部から使用しても良いということを意味する
テストされてるんだから仕様が変わったりしない >>381
> publicにしたら別のオブジェクトからアクセスされちゃうじゃん
アクセスしても問題ないだろ？
アクセスしても問題ないようにテストしてるんだから >>384
いやいや、公開する必要のないメソッドを公開する意味がない
呼ばれちゃいけないタイミングはある、テストしてるかどうかとは関係ない
テストしてないコードはバグってるよ
人の問題で片付けてはいけない テストやるときって前提となる状態を作ってからやるじゃん
公開して自由にアクセスできたら前提が成り立たない状態でアクセスされちゃうじゃん
テストエアプかい？
ちなみにだけど僕は自動化テストは書いたことがない
書いたことないけど僕はテストにすごく詳しいんだ、わからないことがあったら聞いて
privateなメソッドにテストが必要ないと思ってる人がいるのが僕は不思議
むしろprivateなメソッドこそテストするべきでpublicなメソッドはただのインターフェース
privateなメソッドにロジックが書かれていてそのテストを内包してるオブジェクトのことをアクターと呼ぶことにしようか
publicにしたからと言って緩和するだけで結局状態の保持をされて意味不明な動作をするところは変わらんで
staticおじさんの言うことを聞きなさい
>>385
> いやいや、公開する必要のないメソッドを公開する意味がない
テストするのだから公開する必要があるだろ
なにいってんだおめぇ >>391
お前が何いってんだハゲ
privateだとテストできないのが困るのよねえと言ってんだろうが テストエアプか？
テストのためだけにpublicにするなんてありえない
>>393
じゃあ、どうすんだよ
って聞いてみたい 外部からアクセスするテストをしなくて済むのがprivateだと思います^^
>>394
同じオブジェクトにテスト書けば良いと僕は思います
データ、メソッド、テストを備えたオブジェクトを特別にアクターと呼ぶことにしましょうという
のが僕の提案です >>388
テストをするということは、それはインターフェースとして仕様がきっちりしていて
長い期間にわたって変更しない（されにくい）ということなんだよ
インターフェースが適当だったり変わりやすいものは
変わるたびにテストも変えなくてはいけなくなる
つまりテストのメンテナンスのコストが増えてしまう
インターフェースが適当だったり変わりやすいものを作るなという話じゃない
そういうのは作ってもいいがprivateにして、他のpublicメソッドを通して間接的にテストする
privateはテストしなくていいとかテストできないとかじゃなくて
インターフェースが（まだ）明確に決きめずに後回しにできるというメリットが有る
一方テスト可能な段階になったなら、それはインターフェースの仕様が明確に定義されているということ
（明確に定義されてないものをテストなんかできない）
明確に定義されたのならpublicにしていいわけ ジャップにオブジェクト指向は100年早いみたいだな
脳死で全てにpublic staticって書いとけ
>>395
あら、あーたはprivateなメソッドのテストはなさらないの？
それで平気なの？ >>393
テストというのはオブジェクトを使用するときの例でもあるんだから
テストがやってることは、テスト以外でもやって良いんだよ
テストでしか呼び出してないからって、privateにする必要はない >>397
そんなの関係なくメソッド書いたらテストもするでしょ
テストされてないコードはすべてバグだよ
public通してテストするのは粒度が大きすぎる >>401
だからprivateをテストするということは、
そのメソッドは仕様が明確に決まったということなので
publicにしていいんだよ >>400
じゃあ、全部テストするときは全部publicだね >>400
テストするときは前提の状態を用意してからやるもので
テストは実装が正しいか確認するためにやる
publicにして他のオブジェクトから自由に呼び出して良いですというものとはわけが違う
テストで呼んだから別のところでも呼んでいんだなんて道理は存在しない
テストエアプか？ >>402
言い訳がない、privateにするのはよそからアクセスさせないため
テストするためにpublicにしていいわけがない、オブジェクト指向エアプか？ >>403
仕様が明確に決まってないようなものは
privateにしてテストをサボることができる
サボると言ってもpublicメソッド経由でテストするわけだが
あくまでメソッド単体でのテストをサボるだけ >>405
> privateにするのはよそからアクセスさせないため
テスト（よそ）からアクセスするのでpublicです >>407
そこで、僕に名案があります
テストを同じオブジェクトの中に用意するんです
そうしてデータ、メソッド、テスト、この3つを備えたオブジェクトをアクターと呼ぶことにしましょう
プログラミングパラダイムはアクターが主流の時代に突入します >>408
テストのためにpublicにしたらオブジェクトが壊れるため
テストのためにpublicにするのはオブジェクト指向的にありえない
オブジェクト指向エアプか？ >>410
> テストのためにpublicにしたらオブジェクトが壊れるため
壊れないよ。 テストという概念がオブジェクト指向の中にないからこのようなジレンマに陥るのです
そこで、オブジェクトの中にテストを入れてしまおうというのが僕が提唱する新時代の
プログラミングパラダイム、アクター指向です
>>411
壊れるに決まってるだろ、いい加減なこと言うなハゲ 早くしろよおら、全部publicにしてプログラム書いてみろよ、ぶち、壊してやるから
アクセス修飾子はテストのために変えるものじゃない
そこに現行のオブジェクト指向の限界がある
そこでオブジェクト内にテストまで用意しましょうというのが新時代のアクター指向
現状のオブジェクト指向言語がウンコってことでいいよね
> アクセス修飾子はテストのために変えるものじゃない
当たり前だろうｗ
テストというのは外部からインターフェースの仕様が明確に決まってるからこそできること
外部からのインターフェースの仕様が明確に決まったなら
それはpublicにしてよい
>>421
はい、そう言わざる得ないのが現状です
言語が悪いんじゃないプログラミングパラダイムにまだ進化の余地があると
前向きに捉えるのが良いと僕は思います
アクター指向言語がこれから出てくることを祈ります え？privateなメソッドをテストしないって正気？
単に現状のオブジェクト指向言語と開発環境がテストのサポートできてないだけだろ
>>428
ねー意味分かんないよねー、ドン引きだよねー >>399
リフレクション使ってでもやれって言うときはやりますけど？
そこら辺はルール作ってるはずで設計以前で明言されるべき
private要素に外部からアクセスしまくるようなことを許す設計やルールはどうかと思いますけどね
というか他の読み手が安心感を得るためでもある気がしますね
全部publicなプロダクトがあったとしてそれに新しいクラスやらを追加しろって言われたら神経質にならなければいけないw
逆にアクセス修飾子なしの言語はルールだけでやってるよね、あれ怖いわ
まあだいたいが単純なプロジェクトしかなさそうな言語だけど。。 privateなメソッドをテストしないんじゃなくて
仕様が明確に固まってないからテストしてもメンテナンスのコストが増えるだけ
そういうのはprivateにしてpublicメソッド経由でテストする
それがやりにくいーっていうなら、そのprivateなメソッドの
仕様を明確に決めればpublicにすることができる
ようするに今やるか後回しにするかの問題でしか無い
>>431
仕様が固まってないからprivateにするんじゃねーんだよ
おめーさてはプログラミングエアプか？ >>431
いやいやテストプロジェクトではprivateにアクセスできるってだけでいいでしょ >>430
じゃあprivateでもテストすればいんじゃないでしょうか テストオブジェクトから呼び出すためだけに
オブジェクト内部の処理をpublicにするのはありえない
publicメソッド経由で呼び出すのは粒度が大きすぎて話にならない
リフレクション使えばテストできるんだからそういう機能を持ったテストライブラリを使うべき
インターフェース仕様にまだ決まってないだとか
確定なんて明確な区切りなんてものは
現実にはない。
まだ確定してなくても仮のものを仮定して
実装はできる。
確定した後にインターフェースを変えたくなったり
ある日根底から覆ったりする。
privateで制限した内容は顧客要求より強い効力を持つの？
だったら凄く有効だよな
でもそうじゃないだろ
リフレクションはオブジェクト指向にとっては黒魔術でしかないので正当なやり方ではない
この問題の本質はオブジェクト指向にテストの概念がないことにある
オブジェクト指向は規模の大きなシステムの品質を担保するために作られたわけだが
現代ではそれにテストも入れるべきなんだよ
データ、メソッド、テストこの3つを内包するオブジェクトを作ることこそが真のオブジェクト指向
>>432
じゃあ何のためにprivateにするんだよ？
テスト（外部）からアクセスするんだろ >>434
メソッドレベルのテストをリフレクション使ってまでやれって言われたことないですけどねw
inoutがテストしなければならないほど複雑になる１つのメソッドを書くことがおかしいし、
粒度が大きすぎてって、それはinoutを整理しきれてない設計がおかしいのでは？
何でも値が入ってきます、全部１つのメソッドで作ってテストしてください、なんて無茶ぶりだとおもいますねw >>436
privateはプログラムの話だから客は関係ないだろ
客がメソッドコールするわけじゃないからな >>440
あるよ、そしてそれが何度も顧客によって
覆ったこともな。 >>438
内部からのみ処理したいものだからprivateにするんだよ
テストはしたいけどテストのためだけに他のオブジェクトからも
呼び出せるようにはしたくないよねって話をしてるんだ僕は privateをテストするしないっていう想定自体が理解できない
privateメソッドなら当然それを呼び出しているpublicなメソッドがあるはずで
そのpublicメソッドのテストに当然privateなメソッドのテストも含まれるはず
よっぽどprivateメソッドで複雑なことしていない限りそのテストで十分だろうし
それでテストしきれないほど複雑なら別のモジュールに定義し直した方がいいだろう
>>444
それなりに複雑でメソッドを一つずつテストしたいけど
テストのためにオブジェクト分けるなんてイカれてると思うの
だってオブジェクトがテストのためにあるわけじゃないから
テストがオブジェクトのためにあるべきで、そこでですよ
オブジェクト内にテストを内包するのが正しいオブジェクト指向と結論するわけです >>442
顧客によって覆ることが何の関係があるの？ 仕様が覆るのはあたりまえじゃん
それとアクセス修飾子の話は違うわ
>>443
> 内部からのみ処理したいものだからprivateにするんだよ
テスト（外部）から処理したいんだろ
何矛盾したこと言ってるんだよｗ >>445
> それなりに複雑でメソッドを一つずつテストしたいけど
> テストのためにオブジェクト分けるなんてイカれてると思うの
複雑なメソッドは小さくしてください
設計がそもそも間違っています
テストのために小さく分けるのではなく
そもそも複雑なのが問題なのです。
問題を解決すればテスト可能になります。 >>448
だから、そこにジレンマがあるよねって話を最初からしてるつもりっす いや、この問題は言語と開発環境の問題だろ
概念は関係ないよ
visualstudioができちゃえば
できますよ
で終わりな話
>>449
僕は複雑なメソッドを大きく作ってるとは言ってないので
小さくしてくださいというアドバイスをいただいても困惑するばかりです 逆に聞きたいけどpythonとかアクセス修飾子ない言語で、大規模プロジェクトがあったら、
ルール以外でアクセスはどう統制とってるの？
そういう言語の経験はWebくらいしか知らないから、全体何百万行(ステップ数でも人月でもいい)くらいのコードでこうしてた(る)ってのあったら教えて欲しい
お前らほんとプログラムのことしか知らないのな
品質を改善するときには品質を測るな これがテストの鉄則
タグチメソッドの入門でもよめ
1．モノを作る前に品質を創れ
2．品質工学は統計ではない
3．科学的思考ではモノは出来ない
4．市場品質はすべて設計できまる
5．完全な設計は試験や検査は不要
6．品質評価はn＝1でよい
7．品質を改善するときには品質を測るな
8．評価はあるべき姿を定義して、安定性はSN比で行う
9．直交表で設計の再現性をチェックする（パラメータ設計）
10． システムは複雑でなければ、改善はできない
どこから品質の話が出てきたのか知らんが、
品質とテストの話は
> 5．完全な設計は試験や検査は不要
これですかね？
>>458はいくつか日本語の文章に問題があるな
1．モノを作る前に品質を創れ
2．品質工学は統計ではない ×「品質工学は○○である」と言おう
3．科学的思考ではモノは出来ない ×「○○的思考でモノは出来る」と言おう
4．市場品質はすべて設計できまる
5．完全な設計は試験や検査は不要 ×「不完全な設計は試験や検査が必要」と言おう
6．品質評価はn＝1でよい
7．品質を改善するときには品質を測るな ×「品質を改善するときには○○をしろ」と言おう
8．評価はあるべき姿を定義して、安定性はSN比で行う
9．直交表で設計の再現性をチェックする（パラメータ設計）
10． システムは複雑でなければ、改善はできない ×「システムは複雑なら、改善ができる」と言おう
こう偉そうなことを言ってるのに、じゃあどうすればいいかを
相手に考えさせるのって、どうなんでしょうかね（苦笑） 「品質が欲しければ、品質を測るな！」は
「品質が欲しければ、機能を測って改善しろ！」という意味みたいですな
つまりオブジェクトの品質を上げたければ
テストできるように機能を改善しろということですな
privateメソッドであれば、インターフェースを明確にして
機能に昇格させればpublicになるわけです。
>>462
ホントにタグチメソッド知らなかったのか？
その割には理解が早いな
ようするにバクをなくしたいのだろ？
それならバクがでるかどうかのテストをすることが自体がずれてるんだ
そんなことは最終段階でやることじゃないんだ どうせモグラたたきになる
最初の設計段階で徹底的にいじめ抜け
どれだけ変更に強いかをテストするんだ
品質が欲しければ，機能を測れ これにつきる >>463
では「機能を測る」とは？
どうやって測るのかを言ってみましょう
できるかな？ｗ >>463
> その割には理解が早いな
あんなもん当たり前のことを誰かがまとめただけだからね
デザインパターンと一緒。
よく知られたものに、名前をつけてるだけ >>465
複雑なものを複雑のままテストをしても意味がない
シンプルにテスト可能な形に設計を変えることがテストの目的の一つ
ようはprivateはpublicになるように設計を変えろということ 王家秘伝のレシピ教えてやるよ。
#define private public
皆には内緒だぞ。
>>469
#define ディレクティブを使用して、通常 C および C++ で行うように定数値を宣言することはできません。
C# の定数は、クラスまたは構造体の静的メンバーとして定義することができます。
そのような定数がいくつかある場合は、それを保持するための "Constants" クラスを個別に作成することを検討してください。 privateメソッドの直接テストしたいけど可視性を変えたくない場合は
リフレクションを簡単に使えるようにしてるテストフレームワークだったりライブラリ使えばいい
ちなみにGoやRustはprivateもテストできる仕組み持ってる
>>463
ソフトウェアの作り方も知らずにタグチメソッド真に受けたら、
糞みたいな品質のものしかできんぞｗ
単体テストってのは設計の一部なんだよ。品質テストとは全く異なる。
抽象論でタグチメソッドを適用しようとしてる輩が一番ヤバい。 なんだミニ四駆のモータに学ぶことでもあんのか？って思ったら
品質100%の更に上の話じゃねーか
現場の単体テストもロクにやらないクソが問題になってるITでそんなもんいらん
中の磁石が強いほどトルクが上がって回転数が下がる
磁力が弱いほどトルクが下がって回転数が上がる
privateのテストってリファクタリングの妨げじゃないのか
開発体制が複数の会社でピラミッド状の階層化されてたら指揮系統的に相当厳しいだろうね。
明示的な状態管理は、（不可能ではないにせよ）管理すべき状態の量が増えてくると非常に困難になってくるところ、関数型言語の考え方を取り込むことによってその負担を軽減できるのではないかーーという意見もあるようだけど、
このスレの人（カプセル化肯定派・否定派いずれも）としてはどう？
カプセル化の可否はともかく
階層化の有害性についてはこう思います。
例えばディレクトリを階層化のすると
親ディレクトリと子ディレクトリに同じデータを重複格納
する人が出たりしてデータの二重管理が発生
しやすくなると思います。
そのうちどれが正なのか分からなくなります。
あと単純に子供に格納するほどデータのアクセスパスが
長くなってどこにあるのか探し出すのが大変になると
思います。
これはオブジェクトの階層構造でも
JSONなどの構造についても言えることだと思います。
プログラムで階層化なんて意識したことないけど問題起こったことない
分野が違うのかな
つまり、人間関係の問題を持ってきても、技術を否定したことにはならないのです。
>>482
そこで挙げている階層化の問題だが、階層化せずフラットに格納すれば解決するのか？
階層化しないということは同じレベルに大量の物が同格に並ぶわけだが、そうなると目的の物を探すのが困難になりすでにあるデータと同じものを重複して格納する危険性があるだろう。
またアクセスパスが長くなるというが、フラットな構造で多数の物を適切に命名しようとすれば階層的な名前付けが役立つはずだが、それすら長くなると忌避するなら場当たり的に短い名前を着けていっていずれ収集が着かなくなるだけでないの？
お前さんが挙げた階層化の問題は階層化の仕方が悪い(下手な)だけで、階層化をしなければ解決するというものではなかろう。 結局、分類だったり抽象化のやり方がクソってだけの話だろ。
フラットにしようが階層にしようが、クソな分け方したらどうにもならんてだけの話だ。
>>1が例に上げてるRFC3439は「Layering Considered Harmful」という強い言葉を使ってるが
レイヤ化は万能じゃなくデメリットもあるという当たり前のことを書いてるだけ
もちろん「カプセル化は絶対やめろ」なんてことは書いてない
メリット・デメリットを把握した上で
状況に応じたトレードオフの判断ができない人(>>1)には
ソフトウェアの設計はできない なんか、privateメソッドのテストでもめているけど、なんで。
そもそも、privateメソッドを外部から呼び出してテストしないといけない場面が想像できないのだが。
クラスライブラリのコードを紛失したとか笑えないケースを想定しているの？
gitや自動ビルドツールの存在がなかった時代の
オブジェクト指向技術は淘汰されてもいいんじゃない？
昔はこれらがなかったからカプセル化で神経質に
防御してたけど
今は無理にパッケージを固めてやり取りすることが
なくなって
gitでソースを差分転送して再ビルドする方式に
切り替わった
旧仕様はブランチを切り分けといて復旧が簡単に
なって、仕様変更に対してそこまでビビらなくて良くなった。
それと自作のアプリのオブジェクトで
webからインストールしたライブラリや
フレームワークが自動生成して提供するもの以外で
それほど長時間状態を保持するような巨大なオブジェクト
構造を自作設計して作成することがあるか？
あるとすれば
webのセッションや
オープンワールドやFPSみたいなゲームくらいか
今でもSIerなんかはコード書き換えないことに固執してるから可視範囲に対して神経質なんだよ。
>>492
それは「テストの時にだけpublicに変えればいいじゃん」か「privateはpublicに内在してるから直接テストする必要ないじゃん」のどっちの意味ですか？ >>492
コード紛失してなくても他社開発のをガッチャンコだと手が出せないでしょ。 × テストの時にだけpublicに変えればいいじゃん
○ テストがやりにくいというのは設計がまずいということ
自然な形でpublicになるような設計を改善すべきだ
>>501
結合試験時に他社コードのprivateメソッドを態々呼出してテストすんの？ >>495
よくわからないが...強いて言うなら後者？
第一、クラスって実装者が責任を持ってテストするものだろう。
なんで、privateで定義されたものをpublicにして呼び出そうとするのかも、正直、わからない。
ブラックボックステストでもしたいの？
まぁ、ブラックボックステストってprivateメソッドを呼び出せば成立するかというと、違うと思うけど。
正直、何がしたいのかわからなさすぎて困惑している。 >第一、クラスって実装者が責任を持ってテストするものだろう。
これが守られてりゃこのスレみたいな議論は起こらんわ。
守るも何もクラスに不具合があれば実装者の責任だろ
って言うのが通用しないのか？
客先に納めたプログラムを客先が勝手に変更したら責任は外れる契約になってると思う
これは弊社の納めたプログラムではありませんってなるから
社内で引き継いだなら文句を言うのは自由だが任された者がなんとかしろの精神だろ
クラスごとにしっかりテストがあって
引き継ぎがしっかりされる職場ばかりなら何の問題もないだろうね。
とても幸せな世界でいいですね。
まだ続いてたか
結局問題は出来の悪いモジュールをどうするかって話だろ
違うよ
visualstudioがテストプロジェクトでprivateをpublicみたいに呼べるようにするだけ
>>503
privateを呼び出す必要があるってのはUnit Testの時で、実装者とテスターが同一人物かどうかは関係ないよ。
オブジェクト指向に限らずテスト理論の話になっちゃうんだけど、プロジェクトや規格で指定されるUnit Testの種類によってはpublic経由でprivate呼び出してたら組合せ爆発してテストドライバやスタブの開発やレビューだけで多大な工数が必要になってやってられなくなる。
なので十分に単純化されたprivateを含めて関数毎にテストする必要が出てくるのよ。 >>501
> そりゃ結合試験はするだろ
統合試験って言うことは、当然標準ライブラリの
テストも行うんだよな？例えばprintf関数のテストとか >>511
> public経由でprivate呼び出してたら組合せ爆発してテストドライバやスタブの開発やレビューだけで多大な工数が必要になってやってられなくなる。
そういうことだよね。だからそれはpublicメソッドが行ってる機能が多すぎるわけで
複数のpublicメソッドに分解するわけ。これが設計。
適切な関数の行数って思ったより短いものだから。
俺の場合、一部のcaseテーブルのようなものを除いてロジックと呼べるようなものがあるコードは
長いもので1関数30行〜40行程度半分以上は10行程度だよ >>512
何時何分何秒地球が何周回ったときに言いましたかーみたいな煽りだな >>512
そりゃprintf使うシステムの結合テストならもちろん結合テストのセンスでprintfもテストするよ。
ユニットテストの粒度とは違って「〜が標準出力されること」ってテスト項目になるけど。 テストの呼び方はプロジェクトによって違うからなんとも言えんなぁ
なんというか...コミュニケーションがまともにとれていないのでは？
恐らく、他人の作ったライブラリに対して単体テストをお前はやるのか？という意図で聞いた質問に、結合試験はするだろと回答したり、
結合試験と総合試験という字面で見ると似ているけど全然違う話を混在させたり、
似ているようで関係のない話を持ち出して混沌としているな。
語りたい事の本質が行方不明になっているように見える。
>>512は総合じゃなく統合って書いてるぞ
結合テストのことを統合テストと呼ぶところもある
結合の度合いによって結合、統合、総合とそれぞれ分けてるところもある
単なる読み間違いなのか結合 = 統合の意味で使ってるのかは知らんけど うわっ！恥ずかしいミスをしてたのは自分だったか。あとで、読み直す...。
visualstudioのテストプロジェクトが不甲斐ないってだけやし
privateメソッドテストするとか正気？
テストしなくてよくするためのprivateだろ
テストする必要があるというのは
全部書き直した方がましということだが
>>523
特大クラス一つの中に全部privateでメソッド作成したら
どういう理由で全メソッドテスト免除になるの？ マイクロソフトに頼らんで独自にテストプロジェクト作ってるような会社はできてんで
visualstudioの都合でテストやりたくないって言ってるだけだろクズども
関数どころか変数に至るまで一つ一つ丁寧に検査してましたわ。
>>525
どんだけ巨大なクラスでも全部privateだと外から一切呼び出せないデッドコードになるのでテストする意味さえないだろ。 >>528
せやかてpublic通してたら結合テストじゃんｗ >>531
せやろ、ワイの会社も結合テストのことをunit testと呼んでるわ
本当のunit testはやってない これは酷い。RFC 3439はネットワークの仕様の話であってオブジェクト志向なんか
一切関係ないし、プログラミングの話でもない。
偏差値が低い学校でだけ教えてた事実なんてないしアメリカの大規模システムは
全部OOでカプセル化が基本。
的外れすぎて開いた口が塞がらない。これ書いた人間が全く一切わかってないのはよくわかった。
>>536
わざとバカなことを言って他の人が本気で反論や議論してくるのを笑ってる可能性もゼロではないが、まあ単に本物のバカという可能性のが高いと思う >>537
本気感が凄いね。反論とかしようがない１から１０まで間違ってるレベルだし。 こんなんでもRFC確認する人なんてほとんどいないだろうし、クラウドがあるじゃないですか！
のレベルの日本ではショーンK的に通用しそうというか、結構このスレでも通用してるのがおっかない。
Javaで外クラスから内クラスのprivateメンバが見れるのはなぜですか？
超論理的思考によるとどう考えても理論に欠陥があり矛盾してる。
みなさんはこのJavaにおけるクラス体系をおかしいと思いながら割りきって使ってるのですよね？
単に道具だから自分で考えて必要なら使えば良い訳で。
カプセル化ってのはつまり部署ごとにお前のところはお前で責任を持て、
お前が変えたからって他の部署に仕事をさせるな、ということだから、
それができてればなんでも良い。
複数の開発会社が絡む大規模案件と
一社開発や個人開発の小規模案件を
ゴッチャゴチャにして同列で語り合うから、話が噛み合わないし、話が終わらないんよ。
>>542
各クラスの仕様を明確にするのか仕様を決めずに実装するかの差だよ
開発手法の差だが開発規模の差ではない >>543
仕様が明確じゃないのにテストする意味あるの？
それともprivateメソッドの仕様を明確にするの？ そもそもOOとかは大規模開発するために出てきた手法だから個人で小さいもの
作ってるなら関数でもスパゲッティでも本人わかってりゃいいわけだし、昔は
関数でも部署ごとで話し合ってちゃんとやってたけど、どうしても直接アクセスして
変更の際ぶっ壊れるようなものを作るやつが出るから、じゃあもう見せなきゃそういう
事態は起こらないということで実際それはうまくいってる。
個人のソフトとかは好きにすれば良いし、好きにできるようになってるんだから
それぞれ道具を自分の必要に応じて使って勝手にやれば良い。
>>544
「privateはxunit testingしなくていい」と言われる理由はそこだ
他のクラスとの関わりとして必要な仕様は非privateメンバのみに着目すればいい
publicメンバの振る舞いが変わらずすべてのテストをパスできるならprivateがどう変更されようが他のクラスからは関係ないからな つまりprivateをテストするってことは仕様が明確になってるわけで
publicにしても問題ないってことだよね
勢いで書いたから非privateとpublicがごっちゃになってるけどこの手の話題でpublicと書いてあったら全部非privateと読み替えて下さい
>>540
超論理的思考によるとって、論理を超えた思考なんかされたって会話にならないから、論理的思考をした上で疑問があれば相談してくれ。 Privateをテストするかどうかはプロジェクトごとのテストのやり方次第だし、
なんのテストかにもよるわけで。
デベロッパーテストなら当然するだろうし、リグレッションテストで普通は
プライベートメソッドをテストしないだろう。
その辺はカプセル化とかOOとかはあまり関係の無い話。
privateをpublicにしてもいいよねって言ってるやつは、改修で命名とかしたことないんかな
どこの現場でも通じないトンデモ理論を前面に出して話してんじゃねーぞガイジ
>>551
クラスの仕様変更でpublicになったときに追加すればいい
極端な話、複数のpublicメンバの中でprivateAとprivateBが使われてて各privateの挙動は実装者の想定と実は違ったとしてもすべてのpublicメンバの挙動が仕様通りなら(クラス仕様変更して変なバグを引く羽目になるまで)なんの問題もない
その時対処する事案 privateな状態を確認するテストのがテスト数が減る。
二つのpublicなメソッドの関連をテストする場合、
n*m になるが
状態が k 個の場合、 (n + m)*k になるわけだよ。
無理にpublicだけのテストを書くことがどれだけアホか。
Javaで外クラスから内クラスのprivateメンバが見れるのはなぜですか？
論理的思考によるとどう考えても理論に欠陥があり矛盾してる。
みなさんはこのJavaにおけるクラス体系をおかしいと思いながら割りきって使ってるのですよね？
>>555
privateテストでテスト数減るならその方がいいのは自分も同意
誤 privateはテストしなければならない
誤 privateはテストしてはならない
正 必要なテストだけ簡単になるように書けば良い >>558
それは内クラスから外クラスが見えることの説明。
わたしの質問はなぜ外クラスから内クラスのprivateメンバが見れるのか？ よく見たら全部privateか。
...いや、そんなの誰が呼ぶんだ。
しらんがな、言ったやつがコードサンプルでも出さなきゃ説明力足りてないから分からんだろ
外部クラスがどうのとか言ってるやつもな。Javaの外部内部の関係も理解が曖昧なんだろ
Javaって修飾子付けないとpackage privateがデフォルトだからその事言ってんじゃね？
package privateとは言い換えればpakage内publicと同じだから
>>554
言い訳こいてんじゃねーよ
単体テストにpublicもprivateもねーよ
全メソッドテストしろや 弊社はC2カバレッジ100%に満たないものは出荷できませんけどね。
c2の100%は分野次第だがwebや基幹程度なら無駄と欺瞞で逆に信用できない
特に組み込みはC2カバレッジが常識なんだけど、ISO26262では関数カバレッジでOKという不思議。
>>569
分野によるって言ってるだろ
人命関わらないgui優先で運用回避がまかり通る分野全般はカバレッジなしやc0カバレッジ70%(自動生成コード除く)とかなんだよ あー、ここ組み込みとかのやつらが多いのか！納得だわ
>>559
そりゃインナークラスは親クラスのメンバーなんだから
親クラスから見えるのは当たり前。
巨大クラスを作ってその中にインナークラスが大量にあるような
コードならそれはカプセル化できてない。Java使ったから自動的に
カプセル化できるものでも適切なOOの設計になるわけでもない。
それらがやりやすいような言語なだけ。
適切に使えば、インナークラスを使わなかった場合パブリックで
メンバーにアクセスさせなければいけないのに対して、インナークラスの
メンバーはアウタークラス以外には見えないわけだから、よりカプセル化は
進んでいる。 親クラスは不適切だった。インナークラスはアウタークラスのメンバーなんだから
メンバーを見られるのは当たり前。
>>572
組み込み開発やってるけど、ちゃんと最先端の勉強をしている人はオブジェクト指向理解しているよ(別にOOP自体は普及しきったノウハウだが)。
言語はC/C++言語ほぼ一択だけど。(他はRustくらいだが、まだ普及しない)
まぁ、WEBやアプリ開発等、我々から見て抽象レイヤーで使われるノウハウを軽視するおじさん上司も多いし、組み込みに残念なプログラマーが多いことは否定しないけど。 >>566
カバレッジテストとアクセス修飾子って関係あるの？
カバレッジテストを合格するためにpublicにするとか、本末転倒じゃね？ 話の流れからして、テストのためにpublicにしろに読み取れたけど、ミスリード？
まぁ、そんな馬鹿な話、あるわけねーか。
publicにしなくてもリフレクション使ったりすればええんやで
privateだからテストしないなんてプログラマとしてありえない
>>576
> カバレッジテストとアクセス修飾子って関係あるの？
当然関係ないよ。（ここらへんで関係があるとか言ってるのはアホからだ無視していい。）
privateになってようが、それはpublic経由でテストするのだから
カバレッジは変わらない
テストのしやすさが変わるだけ。もしprivateのままだとテストしづらいなら
そのprivateの仕様を明確にしてpublicにして問題ないような設計に変えるだけのこと >>584
publicにしないとテストできないってどんな言語？
privateのままテストしたらええやんけ
unit testは最小単位でテストすることでテストのコストを
最小化するものだからpublic経由でprivateなメソッド呼び出してたら
unit testの意味をわかってないアホの極みだしテストのためだけにpublicにするよう
設計に手をいれるのは本末転倒 とある大手家電メーカー勤めだが、以前までC2カバレッジ必須でやってたんだけど、色々な計測の結果じつはユニットテストでカバレッジに時間かけるよりシステムテストに時間かけたほうが品質が上がるという結果が出てからはユニットテスト必須じゃなくなったわ。
外部から使うかどうかという（間違った）考え方で
privateにするかpublicにするかを決めてると
例えば、全文検索エンジンなんか最低限
文書の登録メソッドregisterと検索メソッドsearchだけでいいってことになってしまう
しかし全文検索エンジンとかいうのは内部で
高速なデータ検索を行うためにいろんなアルゴリズムやデータ構造を
使っているわけで、それらを（実際に使用例ができるかどうかは別として）
汎用的に使えるようにライブラリとして分離すればいいわけ
privateにするかpublicにするかっていうのは、そのシステムで外部から使うか？ではなくて
オブジェクトとして外部から使うかなわけで、privateでテストしづらいようなものは
別オブジェクトに分離とするとか設計をみなすべきってことなんだよ
>>588
privateのままテストしたらオブジェクト分ける必要ないよ
privateのままテストする方法がわからないからオブジェクトわけましょうなんて愚の骨頂
愚かの極み >>585
> publicにしないとテストできないってどんな言語？
そんな話はしてない
可能不可能な話はしていない
やりやすいかどうかの話をしている
コストを考えなきゃいかんよ？
できるけど大変っていうのは、問題を何も解決してない
ちゃんと設計をせずに関数のインターフェースを定義せずに
無理やりprivateのテストをしても、private＝外部から使わない＝変更しても問題ないわけで
それに対してテストをしていると、変更しても問題ないはずのprivateメソッドを変更したら
テストが失敗するってことになるのでよくない >>589
お前はprivateメソッドを変更したときの
影響の大きさがわかってないよね >>590
privateでテストできないならpublicに設計し直すんやって言ってたじゃん
privateのままでテストするのに何も大変なことなんてない
テストのためだけに設計し直すのは頭おかしい
テストされてないメソッドが存在する方が問題だよ
外部から使わないから問題ないよねって感覚で勝手に修正されるわけないだろｗ
メソッド書き換えたらテストも修正するのは当たり前 >>591
わかってないのはそっちの方、unit testでカバーしてなかったら
仕様通り動いてるのを確認できない privateなメソッドであっても事前条件も事後条件もある
unit testでカバーしてれば壊れてないことを確認できるからリファクタリングが可能になる
大規模システムでずっと来てるけどカバレッジって初めて聞いた。調べたら
アメリカだと航空宇宙とか自動車とかでやるみたいね。
ERPで分岐ごとにやってたら多分完成まで数世紀かかるよw
privateとかpublicとかは単に現場次第だよね。正式なQAメソッドではそこまで
言わないし、どうでもいいというか、臨機応変にやるとこ。
>>595
臨機応変にやるのは会社を首にならないためですよねｗ
それは社会をどうやって生き抜いていくかサラリーマンとしての心得じゃないですか
プログラマとして品質の高いプログラムを作るためにC2 100%は最低条件ですよ >>596
プログラマって言ったってサラリーマンと対して変わりがないくらい幅広いわけで。
大規模ビジネスシステムで分岐ごと全部テストしてたらピラミッド建設みたいな事に
なりますw ちなみに臨機応変にやるとこなのは会社首とかはどうでもよくて、
ユニットテストはなに、リグレッションは、アクセプタンスはってのは
QAのメソッドとして確立してるけど、JavaのPrivateがどうするかみたいなのは
完全に現場次第だから。
世界標準はないでしょ。
>>597
大規模システムってみずほとか？
テストは組み合わせを考えると膨大になるのだけれども
最小単位のunit testだとそうでもなくてだからこそunit testは大事なんよ
Salesforceは知ってる？クラウド型のサービスでアプリ作ったりできるんだけど
カバレッジが75%以下だとデプロイできなくなってる
大規模だからビジネスシステムだからテストしなくていいはちょっと今の時代ありえない >>592
> privateでテストできないならpublicに設計し直すんやって言ってたじゃん
> privateのままでテストするのに何も大変なことなんてない
自分で答え言ってるじゃんｗ
privateでテストできないならpublicに設計し直すんだから
privateのテストは大変じゃなくて必要ないってこと >>593
> わかってないのはそっちの方、unit testでカバーしてなかったら
> 仕様通り動いてるのを確認できない
ユニットテストでカバーしないなんて一言も言ってないんだが？
何に反論してるんだよ >>598
現場次第だから現場に従うんだっていうのはそれはサラリーマンとして生き残るために
そうせざるを得ないだけだよね、品質の高いプログラムを作るなら常にテストはしないといけない
世界標準がないからいんだっていうのじゃないよ >>594
> privateなメソッドであっても事前条件も事後条件もある
> unit testでカバーしてれば壊れてないことを確認できるからリファクタリングが可能になる
最初からpublic経由でテストするって言ってるよね？ あたい知ってるよ
カバレッジテストを合格するために、privateをpublicにしてメソッドを呼び出せばいいんだよね。
あたい知ってるよ
カバレッジテストを合格するために、メソッドの中に記載されている条件文全て消せばいいんだよね。
あたい知ってるよ
カバレッジテストを合格するために、メソッドの中に記載されているコードを全部消せばいいんだよね。
>>601
privateのテストは必要だよ
privateでテストできないからpublicにすると言ってるのは君の方
僕はprivateでテストするべきだって立場 >>602
君はprivateのテストは書かないってことだから
privateのメソッドはunit testでカバーされてないよねってこと >>606
> privateのテストは必要だよ
だから何度も言ってるがprivateでテストしたいと思ったら
publicに変更するんだから、privateのテストはしなくてすむと言ってる
お前短絡思考なんだよ。
privateはprivateのままテストしなくちゃいけないんだって思ってるだろ >>604
それはunit testにならないよってこと
privateのメソッドをテストできてないよってこと >>607
> 君はprivateのテストは書かないってことだから
> privateのメソッドはunit testでカバーされてないよねってこと
なんですぐ上でprivateはpublic経由でテストするって言ってるのに
理解できてないの？ >>608
テストしたいからpublicにするのが間違ってて
privateのままテストするのがオブジェクト指向として正当なやり方 >>609
> それはunit testにならないよってこと
> privateのメソッドをテストできてないよってこと
publicメソッド経由でテストしますがなにか？
publicメソッド経由でテストするのが大変なものは
設計を変更すべきなんだよ >>610
public経由でのテストはunit testではないよってこと >>611
> テストしたいからpublicにするのが間違ってて
> privateのままテストするのがオブジェクト指向として正当なやり方
だからprivateのままpublicメソッド経由でテストすりゃいいじゃん（笑）
何度も言ってる。
それが難しいなら、それはコードがすでに複雑である証拠なので
複雑なものを直さないでテストすると破綻する >>612
だからテストのためにオブジェクト変えてるのはprivateのテストを知らないだけだから
本末転倒だってこと >>613
> public経由でのテストはunit testではないよってこと
その根拠は？お前のユニットテストの定義は？
それはどこで勉強したこと？ >>615
> だからテストのためにオブジェクト変えてるのはprivateのテストを知らないだけだから
複雑だからオブジェクトを変えてるんだよ
アホなのか？
privateのテストはpublicメソッド経由でやる
それが難しいなら、コードが複雑だから設計を治す >>599
アメリカの某有名パッケージだね。
その界隈では知ってる限りunit testでカバレージを求められることは無いし
GAFAあたりでも分岐ごとにやらないはず。エッジケースをどうするかとかは
聞かれるけど。
だいたいデベロッパーテストで全分岐をカバーしたところであまり意味はないし。
どのみちQAに回すわけで他人がやんなきゃ意味ない。
カバレージという概念を求められるのが少なくともアメリカでは航空宇宙や
自動車のようだし、良い悪いは別として、これが求められるようなところは
OOとかカプセル化とかが大事なプロジェクトとはちょっと違うよね。
千人のデベロッパーに五百人のテスターで組み込みとかやらないでしょ。
いや知らんのでイメージだけど。 >>614
public経由したらunit testではないよってこと
privateメソッドをテストすることは難しいことではないよ >>619
> public経由したらunit testではないよってこと
だからその主張の根拠は何？
お前のオレオレルールの話なんか
何のやくにも立たないだろ 誰のためにユニットテストするの？w
語ってるべき論は誰かを想定しちゃってない？w
>>616
unit testは最小単位だから、世界共通の定義
publicを経由してたら内部でどんなにprivateなメソッドを呼び出しまくってても
unit testになるなんて、定義はどこにもないのでpublic経由はunit testに当てはまらない 名前をつけるとpublicだろうがprivateだろうがテストしなきゃいけない
→つまり無名にしてその場で使い捨てればテストしなくてOK！
>>617
privateのテストはprivateを直接テストしないとunit testにならないよ >>622
> unit testは最小単位だから、世界共通の定義
> publicを経由してたら内部でどんなにprivateなメソッドを呼び出しまくってても
> unit testになるなんて、定義はどこにもないのでpublic経由はunit testに当てはまらない
それはお前の定義であって、なんの根拠もないことはわかってる >>625
> privateのテストはprivateを直接テストしないとunit testにならないよ
何度も「根拠を言わないことを繰り返す」のは
根拠がないからってことだよねｗ >>624
誰だよそれ、YouTuberか？
権威主義的に誰かにすがりつくような真似をするな！ >>627
根拠は示したけどね、理解する気がないだけなんじゃない？ >>628
> テストのために、コード書き換えてどうするんだよってね。
お前の目的は、テストがしづらい複雑なコードを変えないことなの？（笑）
それともちゃんとテストが出来るコードを開発することなの？
どっちなのさ
目的を理解してるか？ 「メソッド単位のunit テストを強制されてるのです」ww
>>631
おめーこそ、テストの目的を理解してんのか、カス。
privateが記述されているってことは、外部から呼び出したら駄目なメソッドだ。
それを外部から呼び出して単体テスト合格とかふざけんな。
テストなめてんだろ。 >>633
有名な人を自分は知ってるんだ、だから自分が正しいんだって論旨かの？
その人のことを君は知ってるんだ、すごいねｗｗｗ >>636
> おめーこそ、テストの目的を理解してんのか、カス。
> privateが記述されているってことは、外部から呼び出したら駄目なメソッドだ。
↑それ（外部から呼び出したらだめだ！）はテストの目的じゃないよｗ で、でたー！！！
有名人の権威に頼る詭弁！
流石、詭弁のプロッ！
>>637
知らない、誰それ、興味もない
人の名前覚えて品質の高いプログラム作れるようになるわけじゃないし
そういうこと頑張ってるのってただの意識高い系じゃない？ｗｗｗ >>638
> 有名な人を自分は知ってるんだ、だから自分が正しいんだって論旨かの？
そこはさぁ、専門家が言っていることは正しいんだって言うべきじゃね？ｗ
専門家以外に、誰を信じればいいのか知らんが >>641
つまりそういうこと。お前は「テスト技術」に興味がない なぜ日本でTDDの専門家といって一番目に出てくるような人を知らないで
テストの話について語っているのか？
勉強したら必ず何度も目にする名前だろうに
>>643
僕は@t_wadaさんを知らないだけですよ
有名な人の名前を知ってるから自分はテスト技術に興味があって正しい知識を持ってるんだって思ってる？
論理を無視した権威による詭弁としか思えないし、それってただのマウンティングにしかならないんじゃないですか？
俺はt_wadaさんのこと知ってんだぞ！！おめーどーなっても知らねえからな！みたいな中卒ヤンキーのマインドを
お持ちなのはわかったけど、議論の向き先としてそっちで良いのって僕は思いましたよ > 僕は@t_wadaさんを知らないだけですよ
その意味がわかってないんだろ？
お前は勉強した必ず目にする名前を知らないって言ってるんだよ
つまり勉強したことがないってこと
いいんじゃね、全てのメソッドをテストしたけりゃすればw
ただそれを強制されてることが一般的だと思って奴がいるのは滑稽だなw
>>646
人の名前覚えて悦に入る人の心境がわからないんだよなー
僕はプログラムのことにしか興味がないから
誰がそれを書いたのかよりも書いてある内容の方に興味がある
執筆者の名前を覚えて勉強した気になってるだけじゃないの？ パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。
テストできているか不安があるならテストカバレッジを確認しましょう。
別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
テスト対象の可視性を（やや）上げる
例えば Java では、同一のパッケージからのみアクセスできる可視性があり（正式名称ではありませんが
「パッケージプライベート」と呼ばれます）、テストを同一パッケージに配置することでテストから
アクセスできるような設計を行うことがあります。（ただし、この質問の場合は JavaScript なので、この手段はとれません）
プライベートのまま、リフレクションでアクセスしてテストを書く
リフレクションは最後の手段であり、強力な手段でもあります。プロダクトコードに手を入れることが
できない状況や、レガシーコード（テストコードの無いコード）に対する「仕様化テスト（Characterization Test）」を
書いているような状況では、リフレクションは唯一の、かつ強力な手段になります。プライベートメソッドに
テストを書くことのデメリットを理解しつつ、黒魔術の強力さを堪能しましょう。
（ただし、この質問の場合は JavaScript なので、この手段はとれません。JavaScript は比較的緩い言語ですが、クロージャの情報隠蔽は非常に強固です）
まとめ
繰り返すと、プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>648
> 誰がそれを書いたのかよりも書いてある内容の方に興味がある
>>649にあなたが興味があるはずの「内容の方」書きました。
本当に興味があるなら読んでね（読まないだろうけどｗ） >>650
著作権法に違反してない？ 大丈夫？
僕はt_wadaさんを知らないし、信奉する立場でもないので
t_wadaさんがそう言ってるからそうなんだと思うことはないよ
内容に興味があるっていうのは、書いてあることをそっくりそのまま
自分の考えにするということではなくて自分の経験や知識に照らし合わせて
自分の考えを持つってことだよ
僕はその文章を読んでprivateメソッドをテストするべきだと思った > 著作権法に違反してない？ 大丈夫？
もはや技術の話に反論できなくなったか
引用の範囲で著作権は関係ないな（爆笑）
> 僕はt_wadaさんを知らないし、信奉する立場でもないので
あのさぁ、お前。「t_wadaを知らない」という人の話じゃなくて
その人が言った内容についての話をしろよ
> 僕はその文章を読んでprivateメソッドをテストするべきだと思った
それはあなたの感想です。考えは何も述べていません。
>>639
> ↑それ（外部から呼び出したらだめだ！）はテストの目的じゃないよｗ
別に、デバッグ目的で一時的にprivateメソッドを呼びたいのなら、勝手に呼んでどうぞ。
だが、テスト工程...特に単体テストでprivateをpublicにするのはアウト。
本来、呼ばれないはずのprivateだったメソッドが呼ばれてしまえば、本来、不合格だったはずのカバレッジテストに合格してしまう可能性が出てくるし、privateメソッドを呼んだことで、本来ありえないクラス内部状態を作ってしまったら、単体テストの結果も変わってしまう。
テストは本番と同じ状態を保たないと駄目だよ。
プログラマーの開発工程におけるデバッグ及び動作確認とテストを混同させていないか？ >>654
> だが、テスト工程...特に単体テストでprivateをpublicにするのはアウト。
ウォーターフォール開発？
テストで問題が出ても問題を上流に戻したらだめって
バグが出ても直したらいかんのかよｗ >>654
> プログラマーの開発工程におけるデバッグ及び動作確認とテストを混同させていないか？
今はプログラマーの開発工程におけるデバッグの話ですよ？
動作確認でprivateメソッドを呼んでテストなんてしませんから >>652
大丈夫かなって正直に思っただけ、君が引用だと思っててもt_wadaさんが勝手に転載してんじゃねえ
ぶっ殺すぞと思ってたらやばいじゃん、t_wadaさんって人を僕は知らないから
君がすごくぶっ殺されたりとかしないかなって思っただけ
t_wadaさんの話を振ったのは君ですよ
t_wadaさんを知らないのかー遅れてるーうひょーって有頂天になって書き込んでたのは君ですよ
僕は内容の話をしましたよ > テストは本番と同じ状態を保たないと駄目だよ。
これを曲解されても困るから補足説明するけど、単体テストって、クラス単体のテストのことな？
クラスを動かすための環境は自由に変えてもいいけど、クラスそのものを弄りかえるなって意味だからな？
テストがでかけるアサートと本番動作は普通は異なるがな。
なんでも統一させようとして無理が出るから public, privateの議論はくだらんなと思うわけだ。
>>658
やっぱりまだ人の話を続けるんですねｗ
t_wadaさんが言った「内容」の話をしましょうね
負け組おじさんｗ >>660
クラスを動かすための環境というのはクラスの外界ってことはわかってるか？
クラスの外界は変えていいから、テストコードから呼び出すし
クラスの中で呼んでいる外界をモックやスタブで置き換えていいんだよ テストの前提として、テストされるコードをいじってはいけない
テストのためにコードをいじってテストが終わったらコードを戻すんだと
本来のコードが仕様通り動くことが保証できない
いじるのなら納品物が変わってくる
>>662
t_wadaさんを知らないのかーって言ったのは君で
これがt_wadaさんの神々しい高貴な文章なんだーと引用したのは君じゃん
僕はそれを読みました。読んだ感想を今から言います。よく聞いてください。
privateメソッドをテストするべきだと思いました。 >>665
> テストの前提として、テストされるコードをいじってはいけない
> テストのためにコードをいじってテストが終わったらコードを戻すんだと
いるじもなにもコードなんか変更しないだろ >>666
だからお前の感想は聞いてないって言ったよね？
少しはまともな意見も言えるかと思えば感想しかいない。
まあ意見を言った所で専門家よりも説得力がでるとは思えないがなｗ >>654
ユニットテストする時は原則毎回新しいインスタンス作るので内部状態はリセットされるよ。
シングルトンがユニットテストやりにくいって言われる理由はこれ。 >>666
> t_wadaさんを知らないのかーって言ったのは君で
それは違うよねｗ
俺がとある専門家の「意見」を持ってきたら、
そいつは誰だーって言い出したのはお前だよねｗ
↓はい証拠
629 名前：デフォルトの名無しさん[] 投稿日：2020/07/04(土) 11:53:42.19 ID:pmIasW6W [22/31]
>>624
誰だよそれ、YouTuberか？
権威主義的に誰かにすがりつくような真似をするな！ privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね
専門家の意見としては
パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。
テストできているか不安があるならテストカバレッジを確認しましょう。
別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
>>670
君が先にその人を出して
僕が誰それなんでそんなの書いたのって聞いただけだよ
そしたら君がt_wadaを知らないのかーって有頂天になったんじゃん
君はt_wadaさんに憧れてるんでしょ？
だからt_wadaさんが書いた文章を引用したんでしょ
憧れとは理解とは最も遠い感情だってプリキュアが言ってました
僕が誰に憧れてるかはわかりますね？ >>673
> 僕が誰それなんでそんなの書いたのって聞いただけだよ
だから人に興味があるってことだよね？
無名の人なら、そんな無名なんか知るかー
有名な人なら、権威にすがるなー
っていうんでしたっけ？ｗ
どちらにしろ意見に興味がなく
最初から「人」に文句をつけようと思って、誰か聞いたんでしょ？ >>674
t_wadaのブログってリンク提示されてもなにそれとしか思わないから
君がt_wada本人でこれが僕の考えだって示したならなるほどそういうことか
privateメソッドはテストするべきだって思うけど
議論の最中にt_wadaのブログを出されても何いってんだこいつとしか思わない
よくよく話を聞いてみると君はt_wadaさんのことが大変気に入っていて
憧れていてt_wadaさんの言うことは絶対だと思っている
君はt_wadaさんの権威にすがってるだけのつまらない人間なのじゃないかと僕は疑っています 外人が書いた本を翻訳しただけで専門家でもなんでもないんじゃない？
> t_wadaのブログってリンク提示されてもなにそれとしか思わないから
はい、内容を呼んでないと自白しましたｗ
なんのために内容の一部まで引用したと思ってるんでしょうかね
読まずに誰それと「人」に文句をつけるための
質問しかしませんでした。
>>677
どうしてその内容を引用したの？
君はそれが正しいと思ったの？ その根拠は提示できる？
できないでしょ、君はt_wadaを専門家だと思ってて
専門家の言うことは正しいのだ、だから内容が正しいのだと思い込んでいる
だからその内容を引用して何かを示した気になってるだけ >>679
根拠ない主張を繰り返すだけのやつが登場するとそうなるよｗ >>678
外人が書いた本を翻訳したら専門家なのか？ そっちの方が希望じゃん >>682
専門家という肩書の権威にすがりつく君のことかな？ >>681
正しい根拠はすでに上の方で何度も言ってるじゃんｗ
それを補完するために専門家の意見を持ってきただけで
じゃあ反対にお前の言うことが正しいという根拠はなんだよ？ >>665
その辺は結局組織がどうコードを管理するかってだけの話だ。
バカみたいにがんじがらめにした結果誰もコードをいじらない(リファクタリングしない)
ってことにしかならん。 >>683
> 外人が書いた本を翻訳したら専門家なのか？ そっちの方が希望じゃん
翻訳「も」してるだけだろｗ >>668
t_wadaさんの文章はt_wadaさんの感想でしかないよ >>688
意見と感想の違いぐらいつけようよｗ
話は簡単じゃないか
t_wadaさんの意見と
お前の感想
説得力があるかどうかだよ とりあえず、落ち着け。
議題がよくわからんが、落ち着け...落ち着くのだ。
>>687
いやいや翻訳だけが全実績じゃん
t_wadaさんがprivateメソッドをテストせずにとても
すばらしいシステムを構築していま全世界で使われてますってことないじゃん
翻訳したからまるで本物の執筆者のように思われてあたかも専門家のように思い込まれてるだけで
専門家でもなんでもなくただの翻訳者だよ >>690
君が説得力を感じたら意見になり、
説得力を感じなかったら感想になるってだけじゃんそれ
なにそのガバガバな日本語運用
わかりましたでは今から僕が君を説得してみせます、よく聞いてください
privateメソッドはテストするべきです >>693
それもそうか(諦め)
内容は読んでないけど、まぁ、ROMるか。 >>692
なんでググらないでウソ書くの？
そうやって他の人を騙そうとしてるでしょ
https://t-wada.hatenablog.jp/entry/clean-code-that-works
職業はコンサルタントであり、プログラマです。最近では技術顧問としてもいくつかの会社を支援しています。
また、自分の自由になる時間には、オープンソースソフトウェアの開発を行っています。
本業はプログラマでありコンサルタントですが、副業としては技術書の出版、具体的には監訳や翻訳に関わっています。
JavaScript でテストを書く際のハードルを大幅に下げるために開発した power-assert は、
Mocha や Jest と組み合わせて使え、 AVA には既に内蔵されており、ありがたいことに世界中で使われるプロダクトまで育ちました。
ひとつ例を挙げるなら、アリババグループで採用頂き、アリペイやアリババクラウドのテストに使われているという話です。
んで、こういう人に比べて、お前はなにかすごいことしたの？ >>696
営業努力の賜物やろな、頑張ってるんやなt_wadaさん
僕がなにかしたのかという質問ですが僕はすごいことを発見しました
privateメソッドはテストした方が良いです >>698
t_wadaさん以外にすごい人がいたら教えて下さいw >>699
他人に憧れをいだいて必要以上に持ち上げるのが僕は気持ち悪く感じます
僕はすごい人ですが、君に憧れられるのは気持ち悪いです、なのでごめんなさい 他人を必要以上に持ち上げるのって自分に自信がない人がやりがちなので
アドバイスするとしたら色々経験したがいんじゃないかということですね
根拠が聞けるかなと思ったターンで
他人の引用を持ってきて権威に頼っただけである場合
議論は終了である
続ける価値がないから
いえ、自分と同じ意見を言ってる人を持ってきただけなので
話は続いてますよ？
でもなぜか、話の続きをやめてしまっているのです。
なぜでしょうね（笑）
プログラム板でコード使って語りもしない時点で両者どちらも無能
プログラマならコードで主張
privateメソッドとしてどの程度複雑なことをやらせるか、privateメソッドをどの程度使うかについて、感覚の違う2つのスタイルがあるんじゃないか？
一方の極は、privateメソッドには極めて単純なことしかさせず、少しでも複雑な内容なら（他のヘルパークラス等の）publicメソッドに切り出すスタイル。
「privateはpublic経由でのみテストする（直接はテストしない）」という方針を採る場合には、privateメソッドの内容は非常にシンプルな内容に限らざるを得ないし、逆にそうしないと>>555指摘の組み合わせ爆発の問題を回避できない。
>>624と>>649で紹介されている議論や、>>588はこの立場なんだろう。
このスタイルでは、下記のスタイルでは1つのprivateメソッドで処理できる内容を、複数のクラスに属するメソッドの協調関係で処理することになる。
これを適切な機能分化がされていると肯定的に捉えるか、必ずしも汎用性があるわけではない小さなヘルパークラスが増えることになり、見通しが悪くなると否定的に捉えるかは考え方によるだろう。
もう一方の極は、privateメソッドだからといって、内容をシンプルに限らなければいけない必然性はないというスタイル。>>589は、こちらの立場なんだろう。
このスタイルでは、public経由でprivateのテストをするというのは現実的ではないから、privateメソッドでも直接テストの対象とすることが必要になる。言語機能の関係でprivateを直接テストすることが難しい場合には、テストのやり方に工夫が必要になる。
メリット・デメリットは前記のスタイルの反対。
こんなふうに整理できるんじゃないかと思うが、どうだろう。 >>707
主張したいことがあるんでないの？
それを示すコードもあるやろ？ >>709
でも僕無能だからコードないよ
君有能だからコードあるよ
早く出すよ >>710
俺は別にプログラムのこのスレタイについて主張したいことないからなあw
君はプログラマでプログラムについて何か主張したいんだろ？ privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね
>>714
あーこっちがきちがいだったかw
触れないようにするわ このように、コードを使わず偏った主張するやつはだいたい頭がおかしい
この板ではこうやって簡単にこういう奴をあぶり出しできるんよな
>>708
> privateメソッドとしてどの程度複雑なことをやらせるか、privateメソッドをどの程度使うかについて、感覚の違う2つのスタイルがあるんじゃないか？
privateとかpublicとか関係なく、複雑なことをやらせるなよ
関数はせいぜい一画面程度（50行）ぐらい、大半は20行以下にするもんだ 権威ある専門家が言ってることだから間違ってます
俺は認めませーんって。どういう気持で言ってるんだろうねｗ
俺は「そいつは権威ある専門家だ！」って指摘しただけで
勝ったつもりにはなれないなぁ（笑）
今までたくさんのキチガイPGを見たが
privateメソッドだからテストしないとか言ってるやつだけは許さない
テメーの金玉はここで潰す
ごりごりーごりごりー
そうだ！すりつぶした粉で大根餅作ろうよ！
>>729
問題なのは、そのprivateの挙動をどうやって確認するのかって話なのかな？
単体テスト？総合テスト？それとも実装中しながらのデバッグ作業の話？
正直、未だにどこで揉めているのかわかりません。
誰か議題教えて。 >>731
> 正直、未だにどこで揉めているのかわかりません。
自転車置き場 >>731
1. public、privateに限らずコードはシンプルにするべき
2. シンプルであるなら、privateはpublicメソッド経由でテストできる
3. publicメソッド経由でやったらprivateがろくにテストできないというなら設計が間違ってる
4. 設計上の問題はバグと言ってもいい。バグなんだから直せ
ここまではあってる >>731
設計書見ろよゴミカス
書いてないなら死にまくれ >>734
なんで、スレの流れに沿って説明しただけの俺がゴミカス呼ばわりされるのかもわからん。何このスレ。
>>576 >>578でも俺の意見ですらない部分に的外れな回答がつくし。 動けばOKって考えてる人がどれだけ多いかだな
テストを自動化するという考えがない
シンプルな設計をするという発想がない
動けば設計に問題はないと考えている
>>735
Welcome to Underground なんかやべえ流れになってるな
とりあえずつっこんどくと
1. unitテストの定義に世界共通の定義など存在しない
2. unitテストという単語はプロジェクト用語であり、プログラム用語ではない
3. マーティンはunitテストという単語と自動テストの単語わけたらいいんじゃない？と提案してる。xunit
4. publicとprivateはクラス設計のため、もっと言えばクラス間の責任範囲のために存在している
5. xunitテストのためだけにprivateをpublicにするのは誤り。本当にやりたければリフレクションでもすればいい
6. c2カバレッジ100%するかどうかは分野次第
7. 我々は十分なシステムを作るのが目的である。完璧なプログラムを作ることが目的ではない。そして十分な利益を獲得することが目的でもある
ちなみに、的はずれって100%君のことね。まぁ、そんなの今更どうでもいいか。
実際、クラスをどんな風にテストするのか興味あるね。
やだよ組み込みが普通だと思ってる人との会話なんかしたくない
まぁ、Android開発(アセンブラレベルからJavaアプリレベル)をやってるから、たぶん、大丈夫なはず。
組み込み=staticおじさんのレッテルが貼られがちだけど、
私はstaticおじさんじゃないんだけどなー...。
まぁ、アセンブラレベルの階層になると、オブジェクト指向要素なんて微塵もないけど。
>>744みたいな知的障害者が時々沸くのはなんで？ もういいや。アホくさ。こんなスレ覗いたのが間違いだったな。
人生を無駄にした気分だ。
このスレを覗く時間を使って別して作業してた方が有意義だったよ。
>>744
君はID変えながら死ね死ね連呼しているみたいだけど、気を付けた方がいいよ。あばよ、中身がない死ぬべき技術者さん。 プ板、と言うか専門板なんてそれぞれの話題を餌にマウント取り合ったり罵り合ったりする所だから。
相手にしたら負け。
言語の制約によって思考が制約されてる典型例
カマッてくれる人が量産されて>>1が喜んでる privateメソッドのテストしないとか言ってるカスとまともに会話するメリットないだろ
まあテストやるって言ってもこれくらい意見が違って揉め事になるってのは
結構普通だったりするからそういう勉強にはなってるんでないの。
このスレの結論
短くまとめると、プライベートなメソッドのテストを書く必要は 無い と考えています。
パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。
テストできているか不安があるならテストカバレッジを確認しましょう。
別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
テスト対象の可視性を（やや）上げる
例えば Java では、同一のパッケージからのみアクセスできる可視性があり（正式名称ではありませんが
「パッケージプライベート」と呼ばれます）、テストを同一パッケージに配置することでテストから
アクセスできるような設計を行うことがあります。（ただし、この質問の場合は JavaScript なので、この手段はとれません）
プライベートのまま、リフレクションでアクセスしてテストを書く
リフレクションは最後の手段であり、強力な手段でもあります。プロダクトコードに手を入れることが
できない状況や、レガシーコード（テストコードの無いコード）に対する「仕様化テスト（Characterization Test）」を
書いているような状況では、リフレクションは唯一の、かつ強力な手段になります。プライベートメソッドに
テストを書くことのデメリットを理解しつつ、黒魔術の強力さを堪能しましょう。
（ただし、この質問の場合は JavaScript なので、この手段はとれません。JavaScript は比較的緩い言語ですが、クロージャの情報隠蔽は非常に強固です）
まとめ
繰り返すと、プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
>>752
三行以上は読んでもらえないから工夫が必要。 ガワだけのクラスが出来上がるな
#include <iostream>
using namespace std;
class Test{
private:
int methodPrivate(const int x)const{
return 2*x;
}
public:
int method(const int x)const{
return methodPrivate(x);
}
};
int main() {
Test test;
cout << test.method(3) << endl;
return 0;
}
この調子で全部のメソッドにペアになるprivateメソッド作って徹底的に隠蔽してしまえば、相手から調査されることはない
そして上流の方から指定されているメソッドはスッカラカン
実質的に何もしない
名前があるだけ
この技法をprivate開発と名付けよう
相手側に技術が流出することがない
>>755
間違えた
×ぼくの主張の結論
◯ぼくがまとめた、偉い人が書いた本の受け売り情報 僕の高い知性と豊富な経験に基づく主張を聞いて欲しい
privateメソッドはテストした方がいい
>別クラスのパブリックメソッドとする
>プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
>示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
>プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
>プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
>コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
これだけは意味ある意見ではあるな。他はカスみたいな理由だが。
カバレッジ測定ツール高いし持ってないので、private直接テストしたい。
>>759
>>プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
>>示唆している場合があります
わかる
>>コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。
これは選択肢の一つであって常にそうすべきなわけではないんだよね
クラスの分割基準とテストを書く書かないの基準は別だから プライベートだとテストしにくいので、パブリックメソッドとして抽出し、普通にテストしましょう
これが本音
プライベートがテストできるということはホワイトボックスなわけでユニットテスト段階でしょ。
そもそもプライベートをテストするにはソース自体書き換えないと呼べないじゃん。
ソース自体書き換えてテストするようなことはビジネスの世界ではあんまり無いしテストと
なったらブラックボックスが普通。
てかもはやテストの話でカプセル化やOO関係ないな。
ホワイトやブラックについて語るのは時期が悪いというか、国家を危険にさらす可能性さえあるからね。
もう少し社会情勢に気を配ろうよ。
昔のホームページにはサイタマップというものがあった。
>>764
> ソース自体書き換えてテストするようなことはビジネスの世界ではあんまり無いしテストと
まさかpublic・privateメソッドのテストをテスト工程でやる、
public・privateメソッドを書いた人と別の人がやるって思ってないか？
public・privateメソッドを実装中に、その作ったもののが正しく動くかどうか
public・privateメソッドのソースを書いた人が、書いてる段階でテストするんだから
当然ソースを書いて（書き換えて）テストするに決まってるじゃん
お前は、その後の（統合）テスト工程でソースコードを変えてテストとか言ってるだろｗ >>768
なんなのその口調気持ち悪い。
大規模開発だとテスト工程を別の人間が何度もやるのは当たり前だよ。
デベロッパ個人のテストはコーディングの範疇なのでもちろん個人ではやるが
それほど大事ではない。
組み込みで車のブレーキ制御とかは全く別の話だろうがOOとかカプセル化とは
基本かけ離れた分野。 >>769
> 大規模開発だとテスト工程を別の人間が何度もやるのは当たり前だよ。
大規模開発だとpublicやprivateメソッドのテストを別の人がやるって？
テストコード専用に書く人でもいるのかよｗ
それはどこの話だ？事例の一つぐらい持ってきてから言え >>771
某アメリカ製のパッケージとかだな。
むしろテストコード専門に書く人いないのかよ。じゃあOOとかカプセル化とか
必要なほどの規模じゃないか体制がおかしいな。 > 某アメリカ製のパッケージとかだな。
だから事例は？
ユニットテストのコードを他の人が書いて、どうやってTDDをやるのか不思議なんだがｗ
先にテストコード書く人がテストコードだけ書いて、
これに通るように実装しろ！
これがTDD（テスト駆動開発）だ！
とか言ってる所とかでもあるんか？
事例を持ってきてくれ
だからユニットテスト自体が少なくともビジネス分野では大事じゃないと
上にも書いてあるが。
事例なんか出せるわけないだろ。中の人なんだから。
製品についてネットに書き込むときは、法務と企画のハンコ必要なので。
今関わってる製品とかソース10万ファイルくらいあってそれぞれのファイルに
分岐なんか少なくとも数十から数百はあると思うが、その数百万から数千万、下手したら
億の分岐を全部全パターンテストするの？
テストなんてそのあとファンクショナルやってリグレッションやってアクセプタンスやって
ってあるのに、ユニットテスト「だけ」でそれでしょ？
サグラダ・ファミリアかな？
>>775
中の人だから事例が事例を出せないってことは、
お前の会社以外でやってないってことだろｗ 正しいとか正しくないとかどうでも良いので、privateのテストをさせてほしいものですね。
>>778
> 今関わってる製品とかソース10万ファイルくらいあってそれぞれのファイルに
> 分岐なんか少なくとも数十から数百はあると思うが、その数百万から数千万、下手したら
> 億の分岐を全部全パターンテストするの？
それユニットテスト関係ないよね？
手動で全パターンをテストするの？
答えはお前自身が言えるはずだよね？ ユニットテストなんかしてねーよ
ソース修正するたびに、
億の分岐全パターン手動テストしてるんだよ！
って言ってほしいな？
まだかな？
けんか腰は知能が高いと言われるム板に似合わないんだよな。
ユーモアを交えて会話するべきだと思います。
>>779
知ってる限りGAFAでもERP各社あたりでもやってないけどね。
試しに（ドイツだが）SAPあたりにカバレージどれだけですかって聞いてみれば？
何それ美味しいの？だよ。
まあこういう人は何言っても無駄だし下手に事実いうと発狂するからもう相手は
おしまい。 ではGoogleの事例
https://feb-acchan.hat
enablog.com/entry/2018/03/11/214344
現状について
Googleでは、420万ほどのテストが存在して、1日1億5千万テストケース
実行されていて(150million test execution/dayだからあってますよね？)、
1テストケースあたり35回実行されているらしいです。
そして、これらがすべて自動テストであり、手動テスト率が驚異の0％！
ただし、UX系のテストは手動だそうです。
UIのテストなどは自動化できるが、UXはさすがにまだ人手とのことで、
人の感覚などが関係するUXテストがAIによってテスト可能で人の仕事が無くなるといった日はまだ到来していません。
自動テストですが、毎テストごとに420万テストケースを実行しているわけではなく、
全テストケースを実行するのは一定の間隔で、普段は修正に対して依存があるテストだけを実行しているそうです。 Googleの考え方
https://www.publickey1.jp/blog/11/post_144.html
テスターはデベロッパーがテストできるようにするのが仕事
このようにEngineering Productivityのメンバーのレポートラインと
所属を分けることのメリットを、Whittaker氏は次のように書いています。
ここにグーグルの品質管理の大事なポイントがあるようです。
一般にテストは製品開発の最後の段階で行われることが多く、製品チーム／開発チームの
中にテストチームを抱えても、テストフェーズ以外は手持ちぶさたになってしまうため、
多くの開発組織ではテストチームは製品チーム／開発チームとは別に存在し、
必要なときに登場してテストを行う、というケースがほとんどです。
====以下重要＝＝＝＝
ところがグーグルではEngineering Productivityに属する、テストのノウハウを持ち支援を
行うエンジニアたちは、前述のように各製品チームに所属しています。
そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。
各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストの
インフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。
テスターはデベロッパーがテストできるようにするのだ。
各製品チームは、Engineering Productivityのメンバーの支援を受けつつ、自分たちの責任で
テストを行わなければならない、ということがグーグルのテストを行う際のポリシーのようです。 https://www.publickey1.jp/blog/11/post_144.html
Whittaker氏はさらに次の記事「How Google Tests Software - Part Two」で、
エンジニアに与えられる3つの役割についても触れています。
Softweare Engineer in Test（SET）
テストのしやすさ（Testability）にフォーカスした役割。デザインレビューをし、
品質やリスクをチェック。コードをテストしやすいようにリファクタリングする。
ユニットテストや、テストフレームワーク、自動テストも書く。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 「コードをテストしやすいようにリファクタリングする。」
っていうのがまさにprivateでテストしたいのに
public経由でテストできない
ならばテストしやすいようにリファクタリングしましょうって話になってる
>>785
テスト件数が問題なのではない。オートメーションすればファンクショナルレベル
でのテストはいくらでも流せる。
新しいファンクション・メソッドを書くたびに、あるいは変更をするたびに
全ての条件を網羅して、それをテストケースにして、コード自体をモディファイして
テストした後、結果をドキュメント化してまたコードを元に戻すということはやらないという話。
プライベートのファンクション・メソッド単位でC2100%テストしていくというのは
そういうこと。 米Google、JavaScriptユニットテストフレームワーク「JS Test」をオープンソースで公開
https://mag.osdn.jp/11/10/03/1012250
米Googleは9月29日、JavaScriptユニットテストフレームワーク「Google JS Test」を発表した。
元々はGoogle社内のプロジェクトで利用されていたもので、ライセンスはApache License 2.0。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ いや、だからそういうツールがあるのなんて常識だが、privateはテストしない。
上にも書いてるがprivateはソース自体弄らないとテスト自体できないわけで、
そういうツールが自動でソースを弄ってコンパイルし直してprivateのメンバーを
全パターンするわけでは、当たり前だけど、無い。
クラス単位でパブリックのメソッドに対してテストコードもセットで書くということは
当然ある。
憶測に基づいた発言はいらないよ？
俺はGoogleやFacebookとユニットテストに関連する事例を上げただけ
完ぺきにテストしたからといって製品の完全性を保証することはできません。
したがってテストしないほうが良いのです。
ほらなｗ
完璧にテストした所で落ちない飛行機はありません
したがってテストしないほうがいいのです
と言い始めた
事例と自分の考えの矛盾を正せず、頭が狂い始めた証拠。
ここから荒らしと変貌する前触れだな
privateもテストさせていただけるとありがたいけど、禁止するのが正しいことになってるからな。
Visualstudioのテストエクスプローラを使うと考えが変わるのでは。
道具の問題かもしれない。
ユニットテストというのはプロジェクトによってかなり幅があるわけで、
当たり前の話だがテストオートメーションのプログラムが勝手にコード
弄ってコンパイルしなおしてPrivateをテストするわけが無いのだよ。
↑みたいなことを言ってるやつがGAFAは〜と
なんのソースもなしに言ってるわけだよ
こんなやつの話を聞くやつがいると思うかね？
ずれるかもしれないが下のような場合、privateにnullを突っ込んだらヌルポだが
privateをわざわざコード弄ってまで別にテストするようなことは少なくとも
ビジネスソフトでは知ってる限り無い。組み込みとかは知らんし必要ならやれば良いけど。
class ChinTester {
public void testChin(int[] len) {
if (len==null){System.out.println("You are a woman");
return;}
if (len.length<11){ uncS(len);}
else{funcB(len);}
return;}
private void funcS(int[] len){
if (len.length<9){System.out.println("Smallest");
}else{System.out.println("Smaller");}
return;}
private void funcB(int[] len){
if (len.length<14){System.out.println("Medium");}
else if (len.length<16){System.out.println("Bigger");
}else{ System.out.println("Wow!");}
return;}
}
あと日本のNTTデータから降りてくるような大企業案件とかもやったことが無いので知らん。
アメリカのビジネス系一般の話。
>>805
そのコードを見ただけで素人ってわかるよｗ 1. 関数名が意味不明
2. インデントがめちゃくちゃ
3. スペースを入れる所が統一されていない
4. lenが配列なのはなんでだ？
5. nullを情報として扱うな
6. 戻り値なしなのに関数の最後でreturnを書くな
7. 数値（長さ？）判定と文字出力を同じ関数に同居させるな
8. テストするなら、長さを入力し文字列を返す関数を作れ
なんでたったこれだけの関数で
こんなにレビューの指摘項目が存在するんだかｗ
口調が気持ち悪い人は相手しても仕方ないからほっとくとして、上の例だと(に限らず)
funcSとfuncBをテストするためにはコード弄らなきゃいけないし、そもそもtestChin()で
リクワイアメントとエッジケースは全てテストするんだから、無駄にテストが倍以上に
なるしそれも手動になる。
普通のケースだとtestChinに対するテストコード書いて、変更があればそれを流す形になる。
上にさんざコピペが貼られたテストツールはそういうのを自動で流すツール。
テストケース流したいからfuncSとfuncBをパブリックにするというのはカプセル化
できてないし、ましてコード弄ってまでテストするのを手順化するというのは普通はやらない。
書いてる最中にコードちょろっと入れて確認するようなことはあって、それもユニット
テストといえばユニットテストだが、手法としてプロジェクト単位で公式にやるような
ものでは普通は無い。
車のブレーキ制御とかならそこまでやって欲しいが、OOとかカプセル化とはちょっと
違う話。
> funcSとfuncBをテストするためにはコード弄らなきゃいけないし、そもそもtestChin()で
public経由でテストできるだろｗ
＞public経由でテストできるだろｗ
と、いうわけでPublicをテストすれば十分だしPrivateは(普通は)やらないという事を
やっとご理解いただけたようですな。
>>768ではこんな事言ってましたが。
>当然ソースを書いて（書き換えて）テストするに決まってるじゃん >>810
他の言語を勉強したほうがいいぞ
どうもお前は、絶対に来るはずがない値が引数に渡された時、
そのテストしろって言ってるようだからな
「絶対にありえない値」なんだから仕様なんて作らない
他の型がない言語だったら、引数に渡されるオブジェクトなんか
それこそ無限に値なんてありえるだから
privateでも、ソースコードを修正して引数渡せるなら
そのテストをかけって言ってるようなもん >>812
> と、いうわけでPublicをテストすれば十分だしPrivateは(普通は)やらないという事を
頭悪そうだなｗ
この場合publicメソッドを呼んだらprivateメソッドを呼び出すんだから
privateメソッドのテストになってるだろ 少なくともグーグルの面接で絶対こないからテストしないとか言ったら
速攻落ちるよ。むしろ絶対こないのをやるものだからね。
>>768で
> まさかpublic・privateメソッドのテストをテスト工程でやる、
> public・privateメソッドを書いた人と別の人がやるって思ってないか？
>
> public・privateメソッドを実装中に、その作ったもののが正しく動くかどうか
> public・privateメソッドのソースを書いた人が、書いてる段階でテストするんだから
> 当然ソースを書いて（書き換えて）テストするに決まってるじゃん
と言ってますが、今の話と何の関係があるんですか？
「誰がテストするか」の話なんですが？ >>815
だからpublicメソッド経由でテストしてるじゃんｗ
お前は、内部でprivateメソッドを呼び出しているから
publicメソッドのテストには、privateメソッドがそんな値を返そうが
そのテストは書かないのか？ 例えば>>805 の話だと
testChinがpublicメソッド、そのメソッドのテストとして
引数に1（なんで配列か知らんが）となるものを渡したら
Smallestが返ってくることというテストを書く
それは実際には内部でprivateメソッドを呼び出しているのだからfuncSのテストになってる
カバレッジを計測したら、privateメソッドであるfuncSの該当行は実行した（テストした）と計測される。 え、コーディング中にちょろっとコード書いて動作確認とかを「テスト」って
呼んでたの？そりゃ噛み合わないわ。
開発手法の話をしてる時に「テストする」というからにはテストケースを書いて、
手動にしてもコードにしても実行したログくらいは残すものだが。
君はメソッド作る時エッジケースやらネガティブテストやら考慮に入れつつケースを
書いて実行したログも残してるの？変更のたびにやるの？やらんだろ。
>>819
どれにレスしてるの？
ユニットテスト（かつ自動テスト）の話しかしてないんだが
お前がどこを呼んでそう思ったのか
具体的に指摘してみて publicをテストしたらprivateも呼ばれてるからprivate単位でテストしてる！って
ブレブレやなw
publicから呼ばれないprivateなんて一体誰がなんのために書くんだよw
>>819
> 君はメソッド作る時エッジケースやらネガティブテストやら考慮に入れつつケースを
> 書いて実行したログも残してるの？変更のたびにやるの？やらんだろ。
変更のたびって、お前変更のたびにメソッドの仕様が変わるのか？
いきあたりばったりで開発してるんだな >>821
最初からそう言ってるだろ？
ブレるも何も、最初からそう言ってる
↓
> 私の回答
> 短くまとめると、プライベートなメソッドのテストを書く必要は 無い と考えています。
>
> ほとんどのプライベートメソッドはパブリックメソッド経由でテストできるからです。プライベートメソッドは実装の詳細であり、自動テストのターゲットとなる「外部から見た振る舞い」ではありません。 あ？まさかprivate関数の処理のテストをすればいいのに
private関数単独ででテストしなきゃだめだって思ってるのかｗ
あはは、関数単位でテストするのがユニットテストだって思ってるようだな
こりゃ、お・わ・ら・い・だｗ
メソッド単位でテストしろって言うのが組み込みおじさんだから話にならんよ
日本語もjavaも通じないからどうにもならない。
突然噛み付いてくる気持ちの悪いのは100％の確率でおかしいな。
というふうに「技術」の話にレスができなくなったら
「人」（＝俺）の話にすり替えるのが常套手段な
というかお前は誰だよ。Private単位でコード書き換えてもやるって言ってる
人間がいたからPrivate単位では通常のビジネス系ではやらないという流れなのに
突然「お前は素人だあ！」とか噛み付いてきても知らんがな。
タブもスペースもトランケートされる２ちゃんでインデントがとかくだらない
ことでマウント取りにくる暇があったらまず日本語を学べ。
以上。
「privateメソッド」を直接テストしろって言う人はどうするのがいいって言うの？
a 全てprivateメソッドに対しても外部にリフレクション等を使用したテストを書くべき
b privateメソッドにアクセスできるクラスなどにpublicなテストコードを書くべき
c もっと言い方法がある、こうだ！
>>830
>>798 じゃねーの？ｗ
> 完ぺきにテストしたからといって製品の完全性を保証することはできません。
> したがってテストしないほうが良いのです。
つまり
privateにしたらテストできません。だからしないほうがいいのです。
完璧にテストした所で落ちない飛行機はありません
したがってテストしないほうがいいのです しかしよくチンコのサイズテストwにマジで噛みつけるもんだ。
>>833
あ、そういうテストだったの？ｗ
コードしか見てないよｗ Chinってちんこのことだったんだな
funcSとかfuncBとかfoo、barみたいに意味がない単語じゃん
コードがクソすぎて意味が伝わらないいい例だな
無い場合You are a womanで9以下なら小さい、16越えりゃWow！で名前が
チンテスターなんだからわかってる人間は多いだろうな。
>>836
じゃあint型の配列のlen（長さ）ってどういうこと？
配列がnullなら女で配列が複数あれば男？
何が複数なの？ ちなみにfuncなんとかというのは君の好きなグーグルあたりでも例ではよく使うわな。
BとSもbigとsmallだろうと英語得意なら当たりがつくけどね。なぜABじゃなくてBS
なのか。そもそもoutに出てんだし。
>>837
行があればChinkoクラスを作るとこだがスペースいらないで
intじゃなくてヌルポが出るものがarrayだからそれの長さで表してるだけだよ。 > intじゃなくてヌルポが出るものがarrayだから
・・・
Java知らんのか？整数かつオブジェクトでも使えばいいじゃないか
具体的には教えてやらんよ。自分で勉強しな
privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね
>>824
いや、やってもいいだろ
お前がやりたくないのは「たまたま」VisualStudioでやりにくいってだけの理由だろ
早く死んでね こういう事やって、NULLチェックが4倍に増えたー、テストも増えたーって
言ってるやつがいるなんて驚き。馬鹿かとｗ 以下擬似コードな
public func(value) {
// valueのNULLチェック
処理
処理
処理
}
↓
public func(value) {
// valueのNULLチェック
foo(value);
bar(value);
baz(value);
}
private foo(value) {
// valueのNULLチェック
処理1
}
private bar(value) {
// valueのNULLチェック
処理2
}
private baz(value) {
// valueのNULLチェック
処理3
}
そもそもprivateメソッドだからテストしないとか言ってるキチガイにまともな返答なんかいらない
そんなのどこの職場でも認められるわけないから
publicメソッド通したprivateメソッドに自分が想定したケースの値が全部入る保証なんかない
ある特定のケースのみそのメソッドの処理が欲しいときにしか呼んでないことあるだろ
つまりメソッド自体のテストはできてないしその方法でコードカバレッジ100%は無理だし
そもそもpublicから呼び出したprivateのコードカバレッジを100%にするなんて
作業が狂気過ぎてまともな脳みそ持ってるやつならやる前に無駄って理解できる
バカは早く死んでね
>>846
そいつプロジェクトで仕事したことあるのか怪しい部類じゃね？ publicを通した範囲でしかできないprivateのテストは網羅されてなく
メソッドの単体テストとして十分なテストは行われていません
あなたの意見は採用できません
できれば実際のプロジェクトを5つぐらい経験されてはいかがでしょうか？
public通したprivateは単体としては怪しいというのはその通りだけど、
そもそも呼ばれないprivateを書くバカはいないわけで、条件があるから
書いてんだよね。で、条件をpublicの段階でテストするわけだから
ほぼ通ってるわけだよ。
上のチンコテストだとnullから16まで流せば全部通る。
違いは、上の例でprivateにnull突っ込んだらヌルポだわな。そこをテストするのは
コード変えなきゃいけないし、OOの大規模ビジネスソフトではそういうことは
やらない。それをやらなきゃいけない環境なら関数型でもいけるはず。
>>849
できない時点でこの話は終わりさ
やらないわけには行かないんだから
90%できてても残り10%をどうやってもやる方法がないんだから
その方法はどうやっても採用できないし
わざわざする理由もない
別の方法ではできるんだから >>840
君のがpublic privateに関しては言ってることは正しいんだが
底抜けのバカだなあ。
整数かつオブジェクトwこのレベルの人と話してたのかw
はあ。。。
なんかいやになっちゃった。 >>850
いやだから16まで流せば全部できてるけど。
ビジネス系ではやらないよ。組み込みで全部
テストしなきゃいけないというならわかるので
すれば良い。ただOOの手法とは違う。
デベロッパー千人のところでやってるの？
やってないでしょ？ 通ってればいいっていうなら単体テスト全否定だろw
結合テストなりで全部やりゃいいって話になる。
>>853
だからその線引きをどこでやるのかっていう事で、
privateまで全部テストケース書いてエッジケースもネガティブも
全部やるなら関数型で良いんだよ。
別にバカにする気は無いし、関数型のが難しい場面もたくさんあるが、
大規模（デベロッパーだけで数百人）のOOプロジェクトやった事ある？ 上のチンコの例で言えば、funcSとfuncBのテストをテストケース書いて
コードを書き換えた上でやってドキュメントなりログなりで残すの？
だったらpublicでやれば良いし、そうやってpublicにするなら関数型でも
おんなじ事でしょ。
チンコがnullなのか16以上そこそこでかいのかまでしか関係ないわけで
privateがnullをハンドリングしてないとか無駄なんだよ。もちろん
命に関わるようなところではそれくらいの厳格さが求められる場合も
あるだろうが、普通のビジネスソフトではそこまでやらない。
他のチームが関わる場所を少なくするためにカプセル化するわけで、
そんな全部publicにしたら意味ないんだよ。
弊社はC2カバレッジ100%未満は出荷できませんけどね。
>>854
線引じゃねーよクソ野郎
publicでたまたま呼ばれた1パターンと
privateの網羅テストが同じになってたまるかアホかよ
クラスのなかにあるのでpublicから呼ばれたときだけ動けば
ルーチンとして不出来でもOKなんてあるわけないだろ
お前はクソだからもう死ねよ >>857
まあじゃあ君はprivateまでテストケース書いてやっとけば良いんじゃない？
誰も止めてないし。大規模ビジネスソフトでは世界的に言って普通ではないというだけで。
僕はあんまり関わることのないレベルの世界だけど、まあ多分一生関わらないので
君が良いならそれで良いと思うよ。 >>857
君は大変なんだねwテストがんばれーwww >>858
落としどころとしてはそんなところで良いんじゃね？
問題なのは「privateはテストするべきではない」なんて変な教義を押しつける人の方なんで。 >>856
正直QAやってたのは随分前の話だから最近のQAツールは知らんけど、
privateが全部通ってれば100％なわけで、そもそもprivateがある理由は
使われるためなんだから普通は誰も一回も使ってない場合なんかはないわな。
レベルが高くなると通らないケースも出るだろうが。だから線引きってこと。
チンコテストならnullから16までやれば100％通ってる。privateかpublicかって
のは関係ない。ただしprivateはnullをハンドリングしてない。それをどうするかって話。 >>854
お前こそ大規模プロジェクトやったことないだろw
それだけ大規模だと逆にテストコード書かんわ(nttデータとかアクセンチュアとかな)
そんなクソプロジェクトを引き合いに出されても知らんわw >>860
「べきでは無い」とは思わないけど、privateをデベロッパーの個人的な
チェックを超えてテストすることを求められるとしたら、何かプロジェクト的に
おかしいとは思う。 >>862
だから僕もNTTデータとかは知らんと上に書いてるけれども。
アメリカの大規模ソフトは中の人だし、他の会社のデベロッパも何人も知ってるので、
実際にアメリカの業界は知ってる。
君の「クソブロジェクト」ではないプロジェクトは会社名は出す必要はないが
例えばアメリカのERPとかそのレベルでなんなの？ だいたい質問を質問で返す人は答えるのに不都合がある人。
数百人のデベロッパーのプロジェクトをやったことなくても全く問題は
ないんだが（ロッキードのミサイルの制御の人とか数百人もいないし）、
「あるよ」とは帰ってこない。
>>863
だからそれは別の話なんだからさ。
「privateなら必ずしも単体テストする必要はないけどやりたいならやれば？」
これでいいじゃん。 >>866
ちょっと弱いかな。「普通はやらんけどやりたかったりやる必要があるならやれば？」
くらい？privateを全部テストケース書いてエッジやネガティブやるとなると多くの場合
サグラダファミリアになるし、普通はやらない。
でもやりたいならやれば良いとは思うのでだいたいそういう感じか。 組み込みおじさんはそこに義務感を感じ、他者に強要するのだろう
難儀なこった
組み込みとかだと多くの場合そもそもOOあんまりいらんと思うのよね。
人工呼吸器の制御とかだときびしくやらないといけないのはわかるし、
やってない人工呼吸器とか俺も付けられたくないけどさw
OOのメソッドとかはちょっと違う話だわな。カプセル化とかは数百人になると
生きてくる。個人的には自分一人の個人プロジェクトでも使うけど。
数年後にまたやる羽目になったりした時に楽なので。
>>847
それは僕も思ってた
机上の空論っぽいんだよね >>867
どこに差があるのかよくわからんが、どちらにしても一行目は問題ないにしても
二行目はここに存在しない敵を攻撃している印象。
いちいち関係ない話を絡めなくてもいいじゃんと思うが、二度も書くということは
そっちが主張したい本音ということかな？ OOPは理解している人とOOPを理解していない人が単体テストについて不毛な争いをするスレかな？
>>871
いや、元々がpublicじゃなくてprivate単位でやれという話からなんだからその話だよ。
publicでprivateの分岐通ってるなら良いじゃんといなら誰も否定していないのでは？
逆にprivateで一度も通ってない部分があっても良いじゃんとも言っていないような。
if文書くのに絶対通らない物を書く人いるわけないでしょw
ただ、公式なテストとして、privateのレベルでテストケース書いてログ残してコード
書き換えてコンパイルし直してやるというのは少なくとも普通のビジネスのソフトとしては
一般的なベストプラクティスではないし普通はアメリカの大手一流ではやらないということ。
例外はあるとしても。 幸いそういうのには当たったことはないw
上に書いたように例外は認める。
アメリカや大手や一流が正しいとは限らないけどね
ボーイングの飛行機があんなことになってるように
まあ会社的にはプログラマなら全員知ってるとこ。それ以上は言わん。
>>877
だからボーイングの制御系とかはそもそも全然別の話。
もちろん正しいとは限らないけど標準なのは確かだわな。
日本初のOOより優れたこういうメソッドがある！というなら
もちろん喜んで聞くけどね。 >いや、元々がpublicじゃなくてprivate単位でやれという話からなんだからその話だよ。
>ublicでprivateの分岐通ってるなら良いじゃんといなら誰も否定していないのでは？
そう、それが一致しているならいちいち関係ない話を絡めなくてもいいんでは？
public経由のテストで十分網羅できるのにそれでもprivateメソッド単位のテストが
必要なんて主張している人いたかな？そこに誤解があるんじゃないの？
アメリカの大手の一流がそうしてるから正しいのだという権威にすがった論理を
展開されておられたのでその会社ってどちらの会社なのって聞いてみたんだけど
そんな会社本当にあるの？
t_wadaの次はアメリカの大手一流か、議論の根拠が権威ばっかりやな
例えばこの方。
848デフォルトの名無しさん2020/07/05(日) 08:16:36.05ID:IUsMolpf
publicを通した範囲でしかできないprivateのテストは網羅されてなく
メソッドの単体テストとして十分なテストは行われていません
あなたの意見は採用できません
できれば実際のプロジェクトを5つぐらい経験されてはいかがでしょうか？
メソッド全部ちゃんとエッジケースやネガティブまでやれって業界があるのは
わかるし、必要だとも思うけど、それはOOのビジネス系だでは普通やらないということを
言ってただけなんだけど、バカだアホだお前は素人だといろんな方面から変に噛みつく
やつばかりでもう僕はいやになっちゃった。この人が噛み付いてきたということではないよ。
もちろんまともな人のが多いんだろうけどおかしな人のが目立つからね。
いちいち論点ずらすな。
お前ら、何で争ってるんだよ。
OOのビジネス系ってどんな仕事？
そんないい加減なことやっていい仕事ある？
トラブってもうちうちでなーなーで済むようなBtoBの仕事？
自社内でしか使わないシステムとか？
アメリカの大手一流が不満なら自分の業界の実例をあげたらいかがだろうか？
privateをテストケース書いて全件やってるとこなんておそらくないぞ。あるというならあげれば良いだけの話。
テストツールどうやって動いてるねん。コード自動で書き換えてコンパイルし直しか。話がおかしいのすぐわかるだろ。
まず、このスレの連中は議論する前に論理学を学ぶことをお勧めするよ。
あと、詭弁について調べろ。
>>888
アメリカの大手一流ってどこの会社なん？ >>887
だからアメリカ製のパッケージとかコンサルとの間でよく揉めてるだろ。これは「バグ」じゃないとか。DBだってよくある話だわな。
君はどんな仕事なの？ >>891
アメリカ製のパッケージとかコンサルとの間でよく揉めてる仕事なん？
なにそれ？ 何言うてんの？ 何の仕事してるんよ >>885
それは網羅してないからダメという意見では？
そこに反論するならば「privateのテストを強制すべきではない」ではなく
「public経由でも網羅することは可能」ではないかね？(できるなら) >>882
>>848
デフォルトの名無しさん2020/07/05(日) 08:16:36.05ID:IUsMolpf
publicを通した範囲でしかできないprivateのテストは網羅されてなく
メソッドの単体テストとして十分なテストは行われていません
あなたの意見は採用できません
できれば実際のプロジェクトを5つぐらい経験されてはいかがでしょうか？ >>892
アメリカの大手一流でこうしてるから、こうするのが正解なんやー
言うてたからアメリカの超一流ってどこなんよ？ と聞いたんやけど
なんで言えへんの >>870
新しい理論や手法を提唱する人には良くあることだと思うけど、その理論はある前提、ある側面では正しいけど、常に無条件に適用することは正しくないと本人は分かっていて、敢えてそういうことはわざわざ詳しくは説明しない。自分の論が有用な物だと主張したいがため、嘘はつかない範囲で相手が勝手に誤解してすごいと思わせるような物言いをする。
で、その理論に感銘を受けた人の一部が、理論の表面的な効能だけをありがたく受け取って問題点や前提条件などは正しく理解しないまま、受け売りの知識を他所で披露する。
そこで議論になると、本質をちゃんと理解してないまま自説を擁護しようとするから、無理が生じたり話が噛み合わなかったりする。
という流れでイマココなのかなと思う。 まぁ、単体テストでprivateを直接呼び出すのは変な話だけどな。
デバッグならともかく、単体テストでリフレクションによるprivate強制実行とか反則でしょ。
デバッグで許される理由は、バグを見つける可能性があるから。
単体テストで駄目な理由は、テストの合否判定が不当に変わる恐れがあるから。
というのが自分の見解だが、皆さんはどう？
スレが加速してからの途中参加だから、自分の発言に自信ないけど。
>>894
そもそもpublicを経由するのが網羅してないから、経由せずにprivate単位で
コード書き換えてテストやるべきという主張自体がOO的にはおかしいわけです。
見せたくないからprivateなわけで。
もちろんデベロッパー個人でコード入れて確認することはあるだろうけれども、
開発手順としてテストケース書いてログ残してというのは違う。
public経由で内部を網羅してるかしてないかは知ったことではない、というのが正解。
上の例で言えばfuncBやfuncSがnullをチェックしてようがしていまいが他のチームには
関係ないわけです。入り口でnullチェックしてれば。
個人的にはサイズがでかければprivateでも入れるけども、それをテストケース書いて
ログ残してと要求されたことはないし、普通はされんはず。少なくともアメリカでは。 GoogleであってもMicrosoftやOracleもバグのないソフトは作れないし
銀の弾丸的な手法があるわけもなく、アメリカ、大手、一流という箔付けに頼ってるだけでしかない
せっかく匿名で議論できるのに
「アメリカの大手一流」とか言い出しちゃうところが哀れやわ
>>805の下痢便コード出た時点でスレ終了やろ普通 >>896
君の会社はどこなの？
アメリカ大手１流でブライベート単位でのテストケース書いたりした網羅的なテストは「していない」という証明は悪魔の証明だから無理だけど。全社で働いたわけじゃないし。
逆にアメリカ大手１流でやっているという証明は一件出すだけなのでGAFAのどこでも、マイクロソフトでもアドビでも簡単にできるのでぜひどうぞ。
ただ、なんかコピペで爆撃されたオートメーションツールでは、特にコンパイル必要な言語は、直接privateテスト出来ないよ。当たり前の話。 その会社がやってるからすごいんでしょ、はよ教えてやー
もう何でもええから言うて、そしたら僕がすごーいって言うから、もうそれでええやんか
また別IDが下痢便とか発狂し始めた。
お前はほんとにウンコとかそのレベルのことが好きだな。
>>907
やって「ない」という話だけど。
まず日本語学んでやー よろしくなー たぶんアップルは単体テストやってない、SSLでアホなバグだしてたから、あの会社適当だわ、しらんけど
>>911
君が自分の名刺でもあげたら考えとくわー >>913
アメリカの大手一流ではそれが普通なんやーおりゃーってイキっておられましたよね
だから聞いたのに、教えてくれないなんて酷いです、あんなにイキってたのに酷いです >>902
> そもそもpublicを経由するのが網羅してないから、経由せずにprivate単位で
> コード書き換えてテストやるべきという主張自体がOO的にはおかしいわけです。
誰がそんなこと言ってるの？
少なく遠も俺は
1. privateはpublic経由でテストすれば十分
2. もしpublic経由でテストできないほど複雑なら、そもそも設計がおかしい
3. 設計の問題を修正して、責務を分割すれば、自然にpublicになるはず
と言ってる。
テストするためにpublicにするのではなく
問題がある設計を直せばpublicになる。と言っている。 >>914
劣等感がひどいな君は。まずはカウンセラーに
かかりなさい。OOの話はそれからしようか。 >>915
いや だ か ら この人。
848デフォルトの名無しさん2020/07/05(日) 08:16:36.05ID:IUsMolpf
publicを通した範囲でしかできないprivateのテストは網羅されてなく
メソッドの単体テストとして十分なテストは行われていません
あなたの意見は採用できません
できれば実際のプロジェクトを5つぐらい経験されてはいかがでしょうか？ >>902
ああつまり、重要度は関数仕様＞ブラックボックステスト＞ホワイトボックステストだから
テストのために仕様変更はすべきでないという主張か。
それはわからんでもない気はするけど、そういうウォーターフォールが絶対というわけでもないしな。
その是非はさておき、そこが論点なら例えばリフレクションのような形でテストできたり、あるいは
テスト仕様を書く本人が関数仕様も決定することができる条件なら全然問題ないわけだ。 >>918
正直iOSは全然知らんけどこれは酷いなw
Public Private以前にStaticだからなんにしても直接テストする部分だな。 >>919
横から狂犬が噛み付いてくるんだよ。
>>920
ウォーターフォールは関係ないし、重要度をつけてるわけでもないけれども、
普通はprivateはソースコード変えてまでテストするものではないというだけの単純な話。
そもそも「テスト」と言ってもいろんな段階があるわけだし、「ユニットテスト」にしても
プロジェクトによって意味が違うわけで。
なんにしてもprivateを（例外はあるにせよ）全部公式な形でテストしろというのは
OOの手法のプロジェクトでは「普通は」やらんというだけなのになんでこんな揉めるのか。 >なんにしてもprivateを（例外はあるにせよ）全部公式な形でテストしろというのは
>OOの手法のプロジェクトでは「普通は」やらんというだけなのになんでこんな揉めるのか。
全部やれなんて主張している人がいないから。
>>924
だからいるだろうが。本人なの？
848デフォルトの名無しさん2020/07/05(日) 08:16:36.05ID:IUsMolpf
publicを通した範囲でしかできないprivateのテストは網羅されてなく
メソッドの単体テストとして十分なテストは行われていません
あなたの意見は採用できません
できれば実際のプロジェクトを5つぐらい経験されてはいかがでしょうか？ privateメソッドが正しいことは確認する、その上でpublicのメソッドが正しいかテストするって感じ
>>925
これが「privateのテストを全部やれ」に読めてしまうのか。そこが原因だな。 >>923
> ウォーターフォールは関係ないし、重要度をつけてるわけでもないけれども、
> 普通はprivateはソースコード変えてまでテストするものではないというだけの単純な話。
テスト中に設計の問題が発覚しても
ソースコード書き換えないの？
ソースコード変えてまでテストするものではないというけど
なんでソースコードを作成＆自分が書いたそのコードをテストしてるときに
自分が作成してるソースコードを変えたらだめなの？ 普通の開発だったら
0. なにかの修正を行う必要が発生する
1. その修正のためにソースコードを修正する
2. 修正したコードが正しいかテストする
3. 1〜2を繰り返し修正したコードに問題がなければ開発完了
4. 統合テストとかより大きなテストを行う
でしょ？
public・privateメソッドをテストしたいっていうのは
この1〜2のフェーズで発生することなのに、
なんでテストがやりにくいなと思ったときに
ソースコードを修正したらだめなの？
>>926
スマホでも見やすくなったな。
あー、なるほど。
でも、サンプルみたら少し混乱してきた。
自分はクラスの単体テストをイメージしてたけど、まさか、Mainクラスの中に定義されたprivateメソッドの単体テスト(？)の話をしていたとか？
もう単体テストの意味が少し崩壊してきたが... >>928
そもそも300くらいからそういう話だから。
privateはpublicからアクセスして全部網羅できるから問題ないなんて
誰も否定してないしそういうことならもともと荒れてない。
>>929
あのさ、例えばバグが発生したらコード書き換えるのは当たり前だよね？
そんな話では当然ないよね？
privateを直接テストするためには外部から呼べないのだから、呼ぶためには
クラス内に書くしかないわけだよ。で、ソースに書き込んでクラス内に書いて
テストしたあとまたそのコードを取り除いてとかするの？それをドキュメント化
する？
普通はコード書いてる最中にテストコードを入れて確認するのは公式なテストの
メソッドでは無いし、それをドキュメント化したりするのは求められないと
思うが。
>>926
ワロタw
けどそうじゃ無い。privateで直接アクセスした時のみnullがでるということ。
intじゃ無いのは例のためにわざとそうなっている。あとchinTestが呼ばれてないし、
OptionalにisEmpty無いのでは。 >>933
> privateを直接テストするためには外部から呼べないのだから、呼ぶためには
> クラス内に書くしかないわけだよ。で、ソースに書き込んでクラス内に書いて
> テストしたあとまたそのコードを取り除いてとかするの？それをドキュメント化
> する？
誰がそんな事するって言ってんの？
お前が想像が間違ってる >>933
えっとごめんそのnullの問題は設計が下手なだけだと思ってて、設計を見直すべきかと
privateのテストをどうしますかの例として出したので問題ないっしょ
君はこのプログラムをどうやってテストするん？ よくもまあ粉薬をオブラートで包むような話でこれだけのレスで盛り上がれるなー
いやーびっくりだｗ
設計がおかしいから設計を修正するって話をしてるのに
設計を修正した後に修正前に戻すなんでやらないだろ！って言われちゃった（笑）
だーれも修正前に戻すなんて言ってないの
おかしい設計を修正して「開発完了」なの
たぶん、スレタイがスレタイだから、手続き型でプログラムを書く人のイメージする単体テストとオブジェクト指向プログラマーのイメージする単体テストで齟齬が生じているのでは？
そりゃ、サンプルみたいに関数が定義されていたらprivateだろうと関数はテストするべきって発想になるのは不思議じゃないし、オブジェクト指向に基づき設計されたクラスを単体テストする話であれば、privateをテストって、どういう意味なんだろって不思議がるだろうよ。
そして、たぶん、サンプルコードに対して真っ先に突っ込むべき点はOOPでも何でもないコードという点だと思うのだが、そこはいいのかな？
OptionalにisEmptyが無いというのは何言ってるのかわからない
本当になかったらコンパイルに失敗するよ
>>939
一人privateがテストしづらいからpublicに変更してテストして
"元に戻す" 話をしてるやつがいるみたいだが（笑） >>939
僕はOOPのコードだと思ってるよクラスが定義されてるからね
君が思うOOPのコードはこれだっていうのを君に出していただきたいかな >>935
もうお前は良いからスレを読め。
>>936
いやそうじゃなくて、publicで呼ばれるprivateを直接テストするのかという
話なので、そのためにわざわざヌルポになるように書いてるわけで、staticなら
そのままメソッド呼べば良い話。
もうこの板嫌。。。 >>943
ヌルポになるような設計はおかしいのがそれはコーディング力の稚拙さゆえ。
だから、いまはそのヌルポの問題は置いておこう。
さて、君はこのプログラムをどうテストするのか教えて欲しいっていうのが僕の要望だよ。 >>944
いやだから そ う じ ゃ な く て
privateでだけヌルポが出るように書いてるの。privateとpublicのテストの話だから。
出さないだけならnullチェック入れれば良いだけの話だが、そういうことじゃ無くて
わざと出るようになってるの。
そのプログラムならstaticなのだからそのまま呼べば良いし、
chinTestも呼ばれてないけどpublicなのだからテストしたければそのまま
呼べば良い話。 >>942
スマホだからインデントとか崩れは許してほしいが
class USBMemory ： Storage{
private：
色々定義
public：
USBMemory(ポート設定)
void open(string file)
string read()
void write(テキスト)
void close()
}
文法適当だが勘弁して
組み込みおじさんにも分かりやすいように、
組み込みを例にするが、
OOPってこんな感じのコードでしょ。
で、ユーザーは
USBMemory usb；
usb.open(ファイル指定)
text = usb.read()
usb.close()
こんな風に内部実装を知らなくても呼べる。 >>945
わざと出るように入れたのが現実の実装と乖離してるので、わざと入れる意味が無いので
気にする必要ないですよってこと
君はpublic経由でprivateをテストするんだって立場ですよね
君はどうテストを書きますかってことを教えて欲しいです
君の元のコードでもいいですよ、僕が変更したコードでも良いですよ
君はどうprivateをテストしますか？ 残念ながら、クラスを使えばOOPという認識は間違い。
>>948
僕は君の認識が間違いだと思ってる、君の方が残念 JavaScriptとかpythonとか、元々、クラスはサポートしていないのに？
プロトタイプベースはオブジェクト指向じゃないとでも？
>>947
意味がないどころか、そこにしか意味がないんだよ。
それ「だけ」を見せるためのコードなんだから。staticとか
なら話の流れとなんにも関係がないのでそれこそ意味がない。
でもあえていうなら、そもそもまず連打が好きじゃ無い。自分ならループにするけど、
それだけでもない。
まず壊すようにテストすんの。null入れたり、変なオブジェクト入れたり。
で、privateをテストするんじゃなくて、要件通り動くかどうか。nullからint maxまで
回して、要件通りの結果が全てでくるか。変なオブジェクト入れたらどうか。
そういう感じ。
でも最初に書いたように、publicとprivateの話なんだから、そこで
エラーが出るか出ないかがないとこのスレ的にはなんの意味もない。 >>952
JavaScriptにもPythonにもクラスあるよ
クラスがオブジェクト指向の本質だと気づいたから追加されたんじゃないでしょうかねー クラスの存在はOOPの大事な部分だけど、OOPの言語を使ってもほとんどOOPでは
無いというのはよくある話。巨大クラス一個とかだと頭を抱える。
>>954
現実にありえない実装見せて、ほらね、と言われても僕は戸惑うばかり
そんな現実にありえないことを想定するからまずいんじゃないですかね
現実にそういうコード書いてるんじゃないかと僕はちょっと君のコーディング力を
疑わしく思ってきたのだけれども
public経由で、標準出力に出力するようなprivateコードを一生懸命テストしますか？
がんばり屋さんだなとは思うけど、効率悪くないですかね そりゃ、クラスはオブジェクト指向を実現する上で便利だからね。大切な存在さ。でも、クラスなんて無くてもオブジェクト指向でコードは書けるし、逆に、クラスが合っても手続き型の記述をしたら、そりゃ、オブジェクト指向じゃねーわ。
つーか、クラスを使ったらオブジェクト指向ってマジで言ってる？
それってつまり、このスレで時々名前の出るstaticおじさんの書いたコードもオブジェクト指向だと言い張るつもり？
>>957
えーー、違うそうじゃ無い。多分君よくわかってない。
例なわけで実際にありえないとかありえる訳が無い。そんな話じゃ無いし
根本的な部分がわかってない。
publicでは問題がなく、private単体だと問題がでるコードなわけで。この意味はわかる？ >>959
staticおじさんの元の話知ってる？ 僕はリアルタイムであれを読んでたからよく知ってるんだけれども
staticおじさんは必要なところではオブジェクト作るよ、でもASP.NETのForm Applicationのフレームワークには
もともとリッチなオブジェクトが用意されてるから実務ではそれを組み合わせるだけで事足りることが多いよ
だからstaticメインで組み上げてオーケーさって話だったよ
オブジェクト指向信者がアホな前提置いて話を発散させただけでstaticおじさんが言ってることはわりあいまともだった
こういう議論の場で神クラスを引き合いに出して批判するという極端なことやって意味があるのかなと僕は疑問ですね いや、そもそもstaticおじさんのコードはオブジェクト指向でも何でもねーよ！
話反らすな。
>>962
staticおじさんの書いたコードもオブジェクト指向だと言い張るつもり？
と君が聞いたからstaticおじさんに対する僕の所見を述べたつもり
ASP.NETのオブジェクトを使ってるならオブジェクト指向でしょ
オブジェクト指向が為せる技だと思うよ コードあげてくれるのは偉いと思うので気がひけるのだが、上のコードは
privateとpublicの違いを表すための部分がまるですっぽ抜けてるし、そもそも
staticだし結構それ自体staticおじさん感がある。すまんw
>>963
ちげーよ。ASPがオブジェクト指向であって、staticおじさんのコードはオブジェクト指向でも何でもねーよ。 >>966
でもASP.NETのフレームワークがオブジェクト用意してなかったらstaticおじさんはコード書けなかったと思うし
staticおじさんのコードはオブジェクト指向を有効的に活用した非常に優れたコードだと思いますよ
必要もないのにオブジェクト作るのはアホですわ staticおじさんは必要な場面ではオブジェクト作るっていってるからねー
僕はstaticおじさんに詳しいんだ
物事の本質を見誤ると道を踏み外すよ
状態に依存してないのにインスタンスメソッドにしたりとか
staticメソッドを定義したらstaticおじさんと言ったりとか
そういうバカのできあがりですよ
>>967
> >>966
> でもASP.NETのフレームワークがオブジェクト用意してなかったらstaticおじさんはコード書けなかったと思うし
そうだね。
> staticおじさんのコードはオブジェクト指向を有効的に活用した非常に優れたコードだと思いますよ
お前がそう思うのなら、そう思えば。そはどうでもいい。
で？
クラスを定義すればオブジェクト指向だとまだ主張するの？
論点ずらすなや >>971
何が気に入らなくて僕に絡んでるのかわからないですが
クラスがオブジェクト指向の本質であることには変わりないですよ
クラスとはデータと処理をセットにして持つことができるものです
クラスを定義することこそがオブジェクト指向の本質です 責務ごとにオブジェクトをわけましょうなんていうのは
オブジェクト指向でプログラミングすることを前提にした設計論でしか無いです
クラスの存在こそがオブジェクト指向の本質です
>>974
いいえ、君のほうが間違いです
Mainという名前にしてるのはpaizaではMainじゃないと動かないからですよ
その辺わかって絡んでますか？ あまり僕を怒らせないほうが良いです >>972
何が気にいらないかって？
オブジェクト指向でも何でもねぇコードをオブジェクト指向と認識して今まで長ったらしい口論を続けてきたことだ。
クソみたいな時間だったな、オイ。 >>975
まぁ、いいさ。これ以上は不毛だ。スレも終わるし。
俺は俺の思う正しいオブジェクト指向で今後も楽をさせてもらうよ。
そっちも、そっちの思うオブジェクト指向とやらを使い続けるがいい。
成果が出た方が正義だ。 オブジェクト指向だから髪型は自由なのさ
彡 ⌒ ミ
(´・ω・`) 不毛とかいうな！
よし
話を一度整理しよう
privateメソッドだからテストしないとか言ってるやつはキチガイ
早く死んでね
ナイスな整理と言わざるを得ない
議論もリファクタリング可能であることを如実に示した
>>976
僕のコードはオブジェクト指向ですよ
そこんとこよろしくですよ
オブジェクトをどう分けるかって話はありますよ
しかし、それとは独立してオブジェクトは存在するので
オブジェクトを定義できるクラスの存在そのものがオブジェクト指向の本質なわけです
だからオブジェクト指向言語にはクラスが存在します
生物学の類、目のようなものです、どう分類するかは副次的な話であって
分類できることこそが最も重要な事柄です 正直あの短さでOOかどうかと（スタティックでインスタンス化もないコードだが）言うのは
不毛だけどID:JiRnWiGCの組み込みおじさんのがOO感はあるよ。
で、staticで出されてもprivateのテストがどうかと言う話には全く寄与しないわけだが、
じゃあ逆に、>>805のチンコテストのfuncSとfuncBはどうやってテストするの？
パブリック経由で全パターンと言うことならこれでこの話はおしまい。
パブリック経由でやりましょう。
違うと言うなら具体的にコードでおながいします。
smallestを9じゃなくて8にしろとかいう苦情は受け付けますw >>983
僕ならテストしないですね、全部書き直します
メソッドを行数で分割するようなことしてるからそういう下痢便コードができあがるんじゃないかと思いますよ クラスにしてもメソッドにしても責務でわけないと
行数が50行超えたから分割しなければみたいなアホなことやってるのはアホですわ
(組み込みおじさんじゃないんだけどな...組み込みもやるけど)
>>986
器用ですね、じゃあ僕との仲直りもすぐにできそうですね >>984
書き直して決め打ちコピペにstaticなんだw
結局publicとprivateの違いはよくわかってないな。
まあ頑張れ。君とはこれまでだ。
>>986
組み込みおじさんって言ってたやんけ（言ってなかったか？） >>988
staticにしたのは状態に依存してないからですね 下痢便君は10代後半から20代前半というところかなあ。
ウンコチンコのレベルと絡んでてもおじさんあんまり面白く無いんだよね。
自分でチンコテストのコードあげたけどw
でもコードあげたのは偉いと思うので頑張ってね。
あー、組み込みおじさんにも解るように だよ。
俺自身、組み込みもやるからややこしいが、ずっと前に登場した組み込みおじさんとは別人だよ。
まぁ、慌てて書いたから余計な発言だったか。
もう、この際OOPの利点さえ感じていればなんでもいいことにするよ。
スレも少ないし、ヒートダウンしたし。
あー組み込みおじさん（固有名詞）が居たのね。一般名詞のつもりでした。
この板昨日からなので。
参照透明なメソッドだとテストしやすいしバグの混入も減らせるのでおすすめ！
間違っても>>805こんな下痢便分割しちゃダメ しかし小学生の下痢便君とかと話ててもこっちは損するばかりだしなあ。
マジで。しかも下痢便君はましな方な可能性さえあるし。
予想以上だった、この板。マジやばい。ASP.NETのオブジェクトを使ってるなら
オブジェクト指向だし。
>>993
マジで！？ ID:gS37C1rZ これ絶対君だと思ってた、言ってること薄っぺらいしアホだし >>997
マジで某アメリカの誰でも知ってるとこの中の人だよ。
日本人あんまり居ないので、これ以上はやばいからどこだか
下痢便君に教えるわけが無いけど。
インデントとか言ってたの君だっけ？
そんなくだらない（しかも的外れな）揚げ足取りじゃなくて、
君のコード、根本的なとこに問題あるんだけど、わからない人に
わかれと言ってもわからないだろうからなあ。
ちゃんとOOをやったらわかるかも。頑張ってね。下痢便君w >>998
ハゲて頑張っておられる方にお詫び申し上げます lud20230205173316ca
このスレへの固定リンク： http://5chb.net/r/tech/1592491656/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「カプセル化の有害性、オブジェクト指向は愚かな考え ->画像>1枚 」を見た人も見ています：
・オブジェクト指向は愚かな考え
・「オブジェクト指向」は愚かな考え
・オブジェクト指向は愚かな考え。この世は計算式 ★3
・オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
・【嫌儲プログラミング部】オブジェクト指向は愚かな考え 排便メソッドを実装した人間クラスから美少女クラスが作れない
・オブジェクト指向とはモノに着目した考え方です←は？
・カプセル化は愚かな考え
・カプセル化は愚かな考え★3
・オブジェクト指向を教えてくれ！
・オブジェクト指向ってクソじゃね？
・オブジェクト指向を教えてくれ！★２
・オブジェクト指向はガラケー
・オブジェクト指向が無かった頃って
・オブジェクト指向システムの設計 172
・ オブジェクト指向を今すぐやってください
・オブジェクト指向って自然な文法だな 3
・オブジェクト指向システムの設計 173
・【隔離】オブジェクト指向アンチスレ
・オブジェクト指向システムの設計 174
・Javaのオブジェクト指向のサンプルほしい
・LinuxカーネルはC言語なのにオブジェクト指向
・オブジェクト指向ってクソじゃねぇよ？ Part2
・オブジェクト指向はクソじゃなかったよ Part3
・状態管理技術★オブジェクト指向 VS モナド(関数型)
・BootStrap自体がもうオブジェクト指向なんだよね
・オブジェクト指向以外のメリットを書くスレ
・オブジェクト指向ってクソじゃねぇかよPart3
・オブジェクト指向ってクソじゃねぇかよPart4
・C++はクソだがオブジェクト指向がクソなのではない
・オブジェクト指向 って結局のところなんだったの？
・オブジェクト指向プログラミングがなんたるかを理解した
・すまん、プログラミングのオブジェクト指向ってなんなん？PGモメン頼む
・パソコンの大先生ができないもの ビット演算、ネットワーク 、オブジェクト指向
・実は「オブジェクト指向」ってクソじゃね？これデスマーチの原因じゃね？
・関数型プログラミングが人気に おまえらオブジェクト指向が最高って言ってたよな？ あれ嘘だったんだな
・オブジェクト指向の活用方法を教えて下さい
・オブジェクト指向はオワコン？ (20)
・【負荷運営】白猫プロジェクト無課金スレ★2466【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2564【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2618【土肥祐介 白玉団子 麻耶子 しろそく 名無し 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2490【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2489【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2497【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2633【土肥祐介 白玉団子 麻耶子 しろそく 名無し 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2508【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2612【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2475【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2620【土肥祐介 白玉団子 麻耶子 しろそく 名無し 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2639【土肥祐介 白玉団子 麻耶子 しろそく 名無し 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2476【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2494【土肥祐介 白玉団子 麻耶子 しろそく 有害】
・【負荷運営】白猫プロジェクト無課金スレ★2638【土肥祐介 白玉団子 麻耶子 しろそく 名無し 有害】
・【たばこのパッケージ】たばこの有害性、画像で警告を 学会が財務省に要望 ※包装面の50％以上を警告文は決定
・【科学】砂糖の有害性、業界団体が５０年隠す？ 米研究者が調査…砂糖協会はこの発表を批判
・【速報】「アビガン」治験中止か 軽症者の死亡率が高すぎるため「アビガンが有効でない可能性、有害な可能性を示す」★３ [ガーディス★]
・【ワイドナショー】松本人志、上島竜兵さん訃報に涙痛み伴う笑いにも言及「あの芸が有害なんて思わない」「BPOさんどうお考えですか」★3 [征夷大将軍★]
・高瀬くるみ「ハロー！プロジェクトは『自分たちの歌いやすい環境は自分たちで作っていかなくちゃいけない』という考え方なんです」
・【中国】効率が悪くても列に並ぶ日本人は愚かなのか？＝「われわれの割り込み文化の方が進んでいる」―中国ネット[11/10]
・武蔵野市長が「吉祥寺はおおにぎわい」報道に怒り「有害でしかない」
・🤮『最も民度が低い有害なゲームランキングトップ10』が発表！！君たちのやってるゲームは何位かな？
・【有害鳥獣】ネコやハト 無責任な餌やり行為が問題化、大阪市が罰金を科す条例制定へ ★2
・【はやぶさ2】神奈川県相模原市のJAXA施設にカプセル到着。プロジェクトチームが記者会見へ [記憶たどり。★]
・エクセル指向プログラミング (34)
03:11:46 up 26 days, 13:35, 1 user, load average: 10.02, 9.26, 9.23
in 0.043174028396606 sec
@0.043174028396606@0b7 on 010717
|
