オブジェクト指向システムの設計 170

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 411 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:15:33.64 ID:ZPhk/eMO.net] 和田さんは日本語でテスト関連のことを調べていれば 必ずヒットするんだよ。 それを知らないってことはテストに興味が無いと言うのと同じこと。 412 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:15:52.46 ID:gXar6Rt9.net] >>400 xUnit使ったことある？ もしあるなら>>354みたいな質問は出ないはずなんだけど 釣り？ 413 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:16:02.23 ID:ZPhk/eMO.net] >>402 俺のほうがすごいって言うなら技術を実感させる回答すればいいのに 414 名前：デフォルトの名無しさん [2016/06/04(土) 00:16:33.12 ID:Sbqo4kno.net] 異常な和田連呼まじワロタｗ 415 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:17:19.91 ID:Sbqo4kno.net] >>404 使った上での疑問。 で、回答は？ 416 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:19:41.01 ID:Sbqo4kno.net] お前らの相手してるのアホが移りそうだからしばらく放置するわ。 俺に認めて欲しいなら質問にまともな回答を返してくれよ。 技術的にまともな回答が付いていたらそいつのことは評価するよ。 技術のある技術者は好きだから。 417 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:20:27.20 ID:gXar6Rt9.net] >>407 もしかしてコードが変わったらテストスクリプトも変えるってことか だったら>>396 418 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:21:29.06 ID:gXar6Rt9.net] テストスクリプトって ユニットテストを実行するTestRunnnerのことかと思った 419 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:22:00.25 ID:Sbqo4kno.net] >>409 基本ユニットテストは対象クラスのメソッドに1対1ならメソッドが変わったらテストも変えなきゃだめだろ。 420 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:23:10.14 ID:Sbqo4kno.net] >>410 テストコードだな。 最近スクリプトのテストを書いていたもんで間違った。 421 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:25:12.27 ID:ZPhk/eMO.net] >>408 俺のほうがすごいって言うなら技術を実感させるセリフいえばいいのにｗ 422 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:25:17.37 ID:gXar6Rt9.net] >>411 変えるよ でもリファクタリングでメソッドが複雑化する方向にはならないでしょ クラスとしての既存の振る舞いは変えないんだから 新たに追加するんだったら 別にTDDとかユニットテストじゃなくてもリグレッションテストやるから一緒じゃない？ 423 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:29:02.08 ID:Sbqo4kno.net] >>414 ある奴が「クラスもメソッドもどんどん変える」と言ったからそんなことしたら 工数が膨れるのでは？って話。 インタフェースを変えない範囲に限定して修正するのが基本だと言ってる？ 424 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:29:14.32 ID:gXar6Rt9.net] リファクタリングするときは クラスやメソッドが肥大化して単一責任でなくなった時に分離 重複コードをまとめる 必要に応じて依存性の注入くらいかな 425 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:30:46.54 ID:Sbqo4kno.net] >>416 そもそもリファクタリングの話は俺はしてないって…。 426 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:33:36.95 ID:gXar6Rt9.net] >>415 おそらくその「ある奴」は俺のことだと思うけど 「ユニットテストや結合テストによって全体の整合性が保たれてるから 局所的なクラスはどんどんリファクタリングする」くらいの意味 前提条件と言葉がたりなかったね APIというかインタフェースを変えるときはメンバーに相談とかレビューとかしっかりするよ 427 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:37:18.78 ID:Sbqo4kno.net] 俺の理解が足りないのか、言葉使いが不正確なのか分からんがすっきり理解できない。 まず、ユニットテストは一部だけをテストするんだから全体の整合性が保たれる理由になるのが不明。 次に、局所的なクラスはどんどん改修する場合、テストもそれに合わせて改修するんだろ？ 認識のずれを生じるとめんどくさいから悪いけどそれぞれについて分けて回答欲しい。 428 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:39:15.95 ID:Sbqo4kno.net] もしかして、局所的なクラスの改修ってメソッドとしての動作は変えない （変えたとしても修正）範囲の修正ってことか？ 429 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:40:09.16 ID:ZPhk/eMO.net] >>419 次に、局所的なクラスはどんどん改修する場合、に 他が壊れてないか、どうやってテストするんだって話だろ。 430 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:50:54.06 ID:Sbqo4kno.net] どうも>>420っぽいな。 その範囲の変更を「クラスもメソッドもどんどん変える」と言うなよ…。 お互い時間を無駄にした。 431 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 00:53:56.58 ID:pn86qigp.net] 微妙なリファクタリング 微ファクタリング 432 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 01:34:22.66 ID:U+sUBqw0.net] 完全に横だが、、、 お前らもうちょっと話を噛み合わせる努力をお互いにしろよなと。 以下はお前らがやり合っている間に俺がググった内容だ。 >>316の本の内容は、テストコードのデザインパターンだ。 > devtesting.jp/pekema/?0001%2FTopics 要するに、オブジェクト思考が「変更に強い」なら、テストパターンもまた同様に気を使えば「変更に強く」なるって事だ。 TDDは和田卓人本人が認めているように、 > テスト駆動開発に「完壁主義の呪い(完壁な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念)」を解いてもらってからは > xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E8%91%97%E8%80%85/%E5%92%8C%E7%94%B0%20%E5%8D%93%E4%BA%BA OOPや従来型の「しっかり設計してからコーディング」とはやり方が根本的に異なる。 デタラメでもいいからコーディングし、単体テスト/レグレッションテストの環境を構築してから、 リファクタリングで目的のコードを得ることを目指す。つまり、事前に「完壁な設計」は必要ない。 433 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 01:34:44.80 ID:U+sUBqw0.net] 説明として分かりやすかったのは以下で、まんまそのまま書いてある。長いがそのまま引用する。 > では、どんなときにTDDを採用すべきではないか。 > 筆者の個人的な感想ということをあらかじめ断っておくが、 > 恐らくオブジェクト指向のモデリングを重視して行うプロジェクトは、TDDと相性が悪いだろう。 > というのは、TDDではコードの重複を取り除き、リファクタリングを行っていく過程で、クラスが生まれたり消えたりするからだ。 > 例えば、『テスト駆動開発入門』に出てくる例でも、クラスが生まれたり消えたりする過程が描かれている。 > もし、個々のクラスが存在することに必然性があり、個々のクラスが特定の役割を担うことが期待されるなら、 > コードの重複を取り除く、というような目的のために、クラスが生まれたり消えたりすることは受け入れられるものではないだろう。 > このような問題は、オブジェクト指向モデリングという技法を支持しない筆者のようなプログラマであればまったく問題はないが、 > もっぱらオブジェクト指向モデリングを通してプログラムの構造をイメージする「オブジェクト脳」の持ち主には厳しい制約かもしれない。 > www.atmarkit.co.jp/fdotnet/special/tdd/tdd_04.html 434 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 01:35:25.53 ID:U+sUBqw0.net] TDDと従来型手法のどちらが効率がいいのかはよく分からない。 ただ事実として従来型は「設計」ありきなので、「設計」できない奴はそこで止まってしまう。 或いは意味不明な設計をして無駄が大量発生してしまう。 だからそのレベルに達していない奴なら、 TDDの方が動かしながら設計＝必要/不必要なメソッドが分かりやすいので、捗るだろう。 で、言っちゃ悪いが>>1は達していない。（これは多分みんな思っている） 「設計」出来る奴ってのはつまり、仕様を聞いたらおぼろげながらも「最終コード」が思い浮かぶ奴であって、 必要ないクラスやメソッドをぐちゃぐちゃやっているような奴は駄目だ。 ただ、ある程度「設計」出来る奴が使った場合にどちらが早いのかは分からない。 例えば上記サイト、 function add(x,y){return x+y;} で説明しているのだが、当たり前だがこの仕様なら誰しも最初からこの最終コードに到達できる(＝「設計」出来る)ため、 このような状況ではTDDよりも従来型の方が確実に早い。 しかしこれがどこの規模まで行けるかということで、 さすがに最終コード（数千行）を最初からベタ打ちでいきなり動かせる奴なんていないので、 その時にどうなるのかはやってみないと分からない。 ただ、確実に言えるのは、進捗管理はおそらくTDDの方がやりやすいだろう。 >>1みたいにアホな設計をしていると全部無駄になってしまうが、TDDなら曲がりなりにも着実に進む。 435 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 02:39:38.93 ID:ZPhk/eMO.net] TDDは出来るできないというよりも 慣れの問題なので、どんなにダメな奴でも やろうと思えば出来る。 ただしダメな奴は苦痛になるだろう。 なぜならば、従来は目視でやっていたものを コードで書くから、コードを書くことが苦手な人は苦痛。 そうでない人は面倒さを乗り越えるだけ。 ただ中には長ったらしいコードを書くことが苦痛と思わないやつが居るらしく、 そういうやつにTDDやらせると、通常のコードはもちろん テストコードもコピペだらけでメンテナンス不可能なものになる。 436 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 02:48:16.27 ID:8pa3f3ig.net] 合わせ技というのは考えないのか？ 設計段階で大体のところを決めておいてさ というのも大まかにでも分けないと分担作業ができないからね 一人で書く場合でもソースコードは複数に分けるから まず大体にでも分割しないと何もできないよね 細かな部分は実際に書いてみるまで問題が発覚しない場合もあるから その、TDDとかいうのに任せてもよいんじゃね？ 究極的には一つの関数の中でだったら、ある程度プログラマの自由なんだから 自分一人で勝手にTDDしても周りに迷惑かけないよね もう少し視点を広げれば、外部に公開しない部分であればTDDでも通用するんじゃないかな そういう意味では俺は君と考え方が全く逆だね 俺は能 437 名前：力が無くても大まかになら設計できるものだと思っている どんなに規模が大きくても、二つ三つに分けろと言われたら、まぁ分けられるでしょう ただ、細部に至って完璧に把握して問題を洗いざらい神経質に取り除けるかというと これは能力がいると思っている 従来型とTDDは別に相反しているとは思わないね 大まかな設計するのは当たり前だし、今書いている局所的なコードの一片に関してはTDD的だろうし ただ、それらがどこで出会うか、どのレベルで扱うかというだけの問題でしょう 一つの考え方だけで全てをこなさなきゃならないわけでもないでしょう [] [ここ壊れてます] 438 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 03:41:02.75 ID:8pa3f3ig.net] 従来型の設計と名指しされている方法は、どう考えてもトップダウンのことだし TDDとかいうのは、とりあえず書けるところから書いていくというのであれば、どう考えてもボトムアップの方法だし すでにこう言った言葉があることからもわかる通り、古くからある考え方で、珍しくもない 飲み会するとき、どこの店に行くかはトップダウン的に決めるが 何を注文するかはその時の気分でメニュー見てから決めるし、「とりあえず」生中っていうのと一緒で 大体の人が勝手に使い分けている 未来のことが大事だから良く考えるってのも分かるし 未来のことは分からないから今できることをするってのも分かる ちょうどよいバランスというものがあるし、中間層のグラデーションの部分が難しい ま、偏る必要はないでしょう 439 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 05:57:33.01 ID:Ux1fTD3c.net] >>353 そのリンク先ちゃんと読んだか？ テストのリファクタリングはテストコードを書いた直後の話だし テストの重複の話に至ってはその和田某氏は重複を許容（=リファクタリングしない）って言う発言すらしてるぞ w 440 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 05:59:48.64 ID:Ux1fTD3c.net] >>354 なるけど、それってリファクタリングじゃないよね 441 名前：デフォルトの名無しさん [2016/06/04(土) 06:32:15.41 ID:T5kdlzfl.net] 人の名前を知ってたらオブジェクト指向ができるのかな 442 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 06:39:15.47 ID:QdGQjCl9.net] 32 ：まちがって名前消しちゃいました。：2013/04/28(日) 23:55:48.52 ID:??? >>29 自分こそインベーダーさえも作れないんだろ？ｗｗｗ どうでもいい言葉の揚げ足取りばっかして 結局口先だけで何にもアップロードできねーじゃんｗｗｗ お前が古臭い口先だけで何も作れない、絶対的な証拠ｗｗｗ 出来るものならアップロードしてみろよ、老いぼれジジイがｗｗｗ 33 ：まちがって名前消しちゃいました。：2013/04/28(日) 23:55:59.93 ID:ikP5EXjcコンソーレの文章中の単語は、コンソーレがいじめを受けた時の単語なわけ、 だからコンソーレが吐き出す単語がすべて、コンソーレ自身に当てはまる。 34 ：まちがって名前消しちゃいました。：2013/04/28(日) 23:56:47.74 ID:??? >>31 ハブられてるのはお・ま・え 勘違いするな基地外 35 ：まちがって名前消しちゃいました。：2013/04/28(日) 23:59:26.06 ID:??? >>31 なーんで、インベーダーのスクショの画像で 座標がマイナスになっているのかねーーーｗｗｗｗ フォントが切れているっていうか、頭の血管切れてるんじゃねーの？ｗｗｗ 443 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 07:55:59.43 ID:n7HRsF8B.net] テスタビリティを追い求めるなら純粋関数の集まりで 機能を構成したほうがいいしオブジェクト指向はそのようになっていない モックオブジェクトやスタブといった複雑なテスト機構が必要になる 1.オブジェクト指向はテスト容易ではない また部分適用がないからインターフェースのシグニチャをどうするかという問題が非常に痛い そのためシグニチャを簡潔にしようとする、引数で状態を渡すという純粋関数的なアプローチを否定せざるを得ない クラスはプライベート変数を多く持ち、アクセサメソッドが必要になる。 プライベート変数をテストするためには.ToStringのオーバーライドがほぼ必須であり、 クラスを作るごとに必要になるであろう。 2.オブジェクト指向はテスト出来る状態にするために行数がかかる 　なぜならば、ユーザーだけでなくプログラマからみても状態という最も重要な情報が隠蔽されているからだ 何をするにしてもクラスクラスクラス クラスを定義するごとに、そのクラス専属のメソッドを書かなければならない 非常に似ているデータ構造があったとしても、統一的な関数でなく、クラスの「継承」によるメソッドの受け渡しを与儀なくされる 似ているデータ構造は所詮似ているだけで、別個のクラスなのだ 多重継承をサポートしているならいいが、単一継承しかサポートしていない言語にとって 複数のアスペクトからなるクラス構造を書くためにはどうすればよいか？また新たなシンタックスを追加すればよいだけだ 3.オブジェクト指向には再利用性がない クラスというものに単一の役割を持たせるのが好ましいというが、 本当に単一の役割を志向するならば、単一の機能をもった関数のほうがよほど簡潔に書ける クラスという概念そのものが、データ構造とふるまいという複数の役割を持っている オブジェクト指向システム設計という言葉が示唆するもの、それは単なるシステム設計ではないということだ 設計行為というのは性能、機能、品質、保守性といったトレードオフを人の手でバランス調整するということだが、 それは適切なデータ構造を定義し、抽象化された汎用性の高いアルゴリズムを書けば済むことで、 それらを一緒くたにし、SRPに反しているオブジェクト志向という土台が、設計行為の役に立つとは思えない 444 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 08:08:05.81 ID:n7HRsF8B.net] 然るにオブジェクト志向という概念を理解できるかどうかというのは一つのバカの壁だということだ 本来、概念を理解できることが知性の証であるが、オブジェクト志向に限ってはそうではない オブジェクト指向を理解できると主張することのほうが、無知蒙昧の証なのである これは全くの仮構の理論であり、虚構の設計手法であり複雑な土台を軸として、複雑な設計ができる人間などいない 人間の計算資源は限られている less is more 最小限の直交したブロックをうまく組み立てることこそ設計であり、 この複雑なブロックをどうすれば扱えるようになるか？ということに議論の中心が行くということは ただ単に議論がしたいだけで、仕事がしたくはないのだ こういった議論は性能や品質といった極めて常識的かつ合理的な設計対象から目をそらすのにはちょうどいいものだ クラス設計者は、性能を議論できない彼らは設計者ではなく、単にUMLでお絵かきしたい幼児でしかない 445 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 08:26:51.69 ID:n7HRsF8B.net] 設計者と単なる教義に従順な信者かを見分ける方法が一つある それは　「有る目的を実現するために”複数の方法”が思いつくか？」ということだ これは言語を複数またいでいる人間にとっては容易なことだが、言語を一つだけしか知らない人間にとっては厳しい問題になる そしてさらに設計者と信者を見分ける方法がもう一つある。 信者がなんとか複数の方法をでっちあげたとしても、これの答えでわかる。 それは「複数の方法があるとき”どのような基準”でどちらの方法を採用するか？」ということだ。 信者は例えばファウラーのリファクタリングという本にこういうことが書いてあったので、方法Aを採用するというだろう しかし待って欲しい、リファクタリングは矛盾している記述も多い いつ仲介者を介すべきで、いつ仲介者を介さないべきか、あの本でわかった人間はいただろうか。 我々設計者はそうではない、複数の案があるなら、複数の案を試作してみて パフォーマンスや行数を計測し、ただただ設計目標に邁進するだけなのである、 それがオブジェクト志向的か？なんてことには興味が無い。 そういうことを気にする人間はそもそもシステム設計をやるつもりなんてないし、その力量もない その力量もないからこそ、「オブジェクト志向システム設計」という奇っ怪なものにすがってしまう その設計指針が絶対的なものだと考えてしまう さらに言えば、信者はコーディングができないのであろう コーディングができないからこそ、パフォーマンスを計測するという最も単純な評価基準すらもたずに議論に邁進してしまう まあ私も一般的なオブジェクト指向言語でコーディングしろと言われたら拒否する おっくうでおっくうで仕方がない、シンタックスは山盛りで私が望むシステムを記述するためには あまりにも面倒で仕方がない、IDEでなんとかなるものではない だからこそオブジェクト志向主義者はオブジェクト志向言語を使いこなすことはできないだろう 彼らにとっては机上での再利用性が第一で、実際にコードを書くということに興味が無い コードをかいて様々な言語をトライしてみたら、「あっ、これはダメだ」という感覚がわかるだろう コードを書かないから、感覚もないし、自分自身で「テスト」できない、そんな人間がテスタビリティを語る 446 名前：デフォルトの名無しさん [2016/06/04(土) 08:38:02.62 ID:T5kdlzfl.net] テストすることが目的じゃないでしょうに 447 名前：憲法に守られる在日スパイ・創価・ヤクザ mailto:sage [2016/06/04(土) 08:48:09.66 ID:SVOilD6U.net] 皇室の危機に気づいていますか？　 日本は、2,000年以上続く皇室のおかげで、世界最古の国として、 ギネス認定されているそうです。 自民党は憲法の改正で、日本の国家元首＝天皇陛下と条文に明記することで、 天皇制廃止をもくろむ帰化人スパイ勢力（政党、憲法学者、弁護士・言論人等）から、 皇室を守ろうとしています。 ※イギリス、オランダ、ノルウェー、デンマーク、スペインなどは国王を国家元首と 　憲法上に定めている。（日本同様、政治の実権は有さない。） ※日本で支配的な「護憲派」憲法学者の多くは反天皇。憲法から天皇の条項ごと削除したい 　人たちなので、本来は改憲派である。（「象徴天皇制度と日本の来歴」坂本多加雄著より） 公明党「天皇は日本の国家元首ではない」　 hayabusa3.2ch.net/test/read.cgi/news/1363226509/ 自民党・西田昌司 「橋下さん（おおさか維新）の憲法改正は、国柄を破壊することが目的」（自民とは真逆） https://www.youtube.com/watch?v=sRkdQ2Rlwxs 日本共産党 「目標としては天皇制をなくす立場に立つ」「天皇制のない民主共和制をめざす」 www.jcp.or.jp/jcp/22th-7chuso/key-word/b_1.html#Anchor-0507 反天皇、反皇室で共謀する民主党（現民進党）と田原総一朗 blog.liv　edoor.jp/fjae/archives/51968115.html 田原総一朗「天皇は、働かないで国民の税金で食ってる。」 https://youtu.be/6Kd1LwY9e0I?t=280　（4：40〜） ※ただし、自民単独（カルト公明党抜き）で２／３議席以上与えない限り、 野党と公明党に骨抜きにされる。　 ↓ 自民・船田氏…「野党・公明党のみなさんと協議し、衆参両院の３分の２をこえる人が 賛成してくれなければ発議はできない。だからこれから大いなる妥協が始まる。 自民の憲法草案は、 ズタズタになると思って結構だ」 hope.2ch.net/test/read.cgi/seijinewsplus/1425226082/ 448 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 08:49:06.93 ID:Ux1fTD3c.net] にちゃんで長文書く奴はもれなくバカの法則 449 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 08:57:11.64 ID:n7HRsF8B.net] オブジェクト指向だとリファクタリングということすら「機械的」に処理できないよな リファクタリングを正しく記述してみてよ、間違いなく長文になり、 個人個人によってそのやり方、ニュアンスが微妙に違い、 場合によっては真逆のことを指しているかもしれないから 俺にとってリファクタリングとはただ単に 「関数の中にある述語などの評価式をより小さな関数として切り出すこと」でしかないが オブジェクトだとフィールドをあっちのオブジェクトに移籍させたり、 フィールドを増やしたり、いろんな手順があるだろ？ だいたいリファクタリングを語るのに300-400ページの本がある事自体まさしく 「長文書く奴はバカ」の法則にひっかかりまくってるよな、ファウラー自身が 450 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:05:18.77 ID:wWz/yuFg.net] 毛の壁さんが出張してきたのかな？ はやく巣にお帰り。 451 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:08:50.19 ID:gXar6Rt9.net] クロージャーはpoor man's objectsだって言われてるの知ってる？ 452 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:10:24.49 ID:n7HRsF8B.net] なんで質問に対して質問に返すのかな？ そんなメソッドや関数って普通あるっけ？ リファクタリングとは何か？ こんな単純な質問にすら答えられないのに、一体何を設計できるんだろうな？ 453 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:14:49.00 ID:n7HRsF8B.net] ああそうか、質問に対して別のやつに質問するメソッド（デリゲート）はあるわな つまり君たちに質問しても君たちは答えられないわけだ 君たちは単なるラッパークラスであり、実体は別の人間が知っていればよいと それがオブジェクト指向であると 実際そんな無知蒙昧なオブジェクトが「設計行為」できるわけないけどな 454 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:20:26.52 ID:gXar6Rt9.net] chain of responsibilityね？ 455 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:24:16.89 ID:ZPhk/eMO.net] >>430 重複を許容 ≠ リファクタリングしない バカすぎ 456 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:50:23.15 ID:Ux1fTD3c.net] >>443 > リファクタリングとは何か？ >>327 457 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:51:41.72 ID:Ux1fTD3c.net] >>446 >>353 のリンク先読んでそんなこと言ってるなら恥ずかしいだけだぞ w 458 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:51:49.72 ID:OPSrDWPX.net] OOPするしないに関わらず設計と言うのは大きな概念から考えてその大きな概念を実現するために枝葉に至るべきである 大きな目的を定めず小さな目的に拘泥するのは馬鹿な行為である これはプログラムの設計に限らず絵などでも同様で細部をバラバラに描くから全体のバランスの悪い崩れた物しか描けない 末節のクラス設計にこだわり、総体としてのプログラムの構造を見ていない馬鹿がOOP信者には多い 抽象化に失敗してるOOPもどきは醜悪の一語だ 一方で大きな概念が適切に抽象化されていれば順次それを具象化していく段階でOOは優れた手法である 前段で述べた一部の馬鹿な信者を見てOOP全体を否定するのは馬鹿なOOP信者と同様に馬鹿な行為である 間違ってる馬鹿を見過ぎたか手法を理解できないのかはわからないがこちらも全体を見ていない 馬鹿と馬鹿が議論をしたところで結論なんか出るわけがないのである、どっとはらい 459 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 09:58:03.84 ID:ZPhk/eMO.net] >>448 >>353のリンク先を読んだよ > テストのリファクタリング > 実装にコードの重複や無駄はあるでしょうか? 現時点ではリファクタリングの余地がないほどシンプルですね。 > ではテストコードはどうでしょうか? …かなり重複が見られますね。テストを書いたすぐ後のタイミングで、 > テストコードの重複も積極的に排除していこう、というのが最近の考え方です。テストの「リファクタリング」というと > 厳密にはもっと難しく、タイミングが遅れるほど困難なものですが、テスト実装直後では自分の頭にもテスト設計が > 残っているでしょうし、このタイミングでは大胆に行動できます。では重複を排除していきましょう。 460 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:06:47.58 ID:h8gmrQ4h.net] なんか、２ｃｈって、ちょっと長め（一般基準からすれば、十分に短文なものだが）の文章を目にすると、頭がスタックオーバーフローになっちゃう人たちが多いの？ 461 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:25:12.33 ID:Ux1fTD3c.net] >>450 そっちじゃねーよ w 俺のレスすら理解してないのかよ... 462 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:38:44.34 ID:ZPhk/eMO.net] >>452 これは和田さんのブログなんだが、 お前は何がいいたいのだ？ リファクタリングとは重複を全く無くすって意味じゃないんだが？ 463 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:44:06.85 ID:n7HRsF8B.net] >>449 一方で大きな概念が適切に抽象化されていれば順次それを具象化していく段階でOOは優れた手法である ないない、もっとも抽象化された構造というのは、結局計算コストが高くつくものだから 継承するにもスレッドをブロックするにもコストがかかるってことわかってないよね 必ずしもハイパフォーマンスである必要はないが、ある機能拡張が 深刻にパフォーマンスに問題をきたすとき、それがOOのできる拡張の限界 建築でも同じだが単なるお絵かきデザイナーに、強度計算や構造計算はできないし、 そんなお絵かきデザイナーのいうことを真に受けないといけなくなったIT業界に まともなプロダクトは出せていないことは、この15年で証明済みだろ 464 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:44:11.73 ID:ZPhk/eMO.net] 俺も和田さんと同じ意見なんだが、 テストコードのリファクタリングというのは テストを読んだだけで、理解できるようにシンプルな形にすると言うもの。 テストコードのリファクタリングは重複を省くことじゃない。 重複があってもいいが、テストコードのテストとか意味不明なわけで そういうものを作らないためにテストコードは人間が読んだだけで 理解できるほど単純じゃないといけない。 単純にするためにリファクタリングする。 465 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:55:59.85 ID:Sbqo4kno.net] ID:ZPhk/eMOは誰と闘ってんだ？ >>1ってお前じゃないの？ｗ まともな設計ができないことを正当化するために何某のブログを引用しているだけじゃん。 そんな奴知らないからそいつがほんとにそんなことを言いたいのか知らんけど。 で、疑問に対する回答がまったくなされていないという…。 テストコードが作られるとして、テストコードはクラス・メソッドを前提としている。 �@クラス・メソッドを変えたらテストコードの修正が必要になるのでは？ �Aクラス・メソッドが変わっても対応できるテストコードの書き方なんてある？あるならどんな書き方なんだ？ 同じ質問を無視してただただ持論を繰り返すってコミュ障かよ。 自分の主張をするだけなら自分のブログに書いてろｗ 466 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:57:47.40 ID:ZPhk/eMO.net] クラス・メソッドを変えても、動作が変わらないならばテストコードの修正は不要 当たり前の話だと思うが？ 467 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:58:23.57 ID:Sbqo4kno.net] >>454 建築業界には設計図を書けない設計者がいると思ってんのか？ 脳みそ腐ってるｗ 468 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:58:59.82 ID:Ux1fTD3c.net] >>453 だれも「全く」なんて言ってないのに... 人の話聞くの苦手なの？ w 469 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:59:04.36 ID:ZPhk/eMO.net] > >>1ってお前じゃないの？ｗ ぜんぜん違う。 お前こそ>>1と戦ってるんだろ？ 俺に戦いを挑むなよｗ 470 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:59:21.59 ID:oaV48IC8.net] 前スレの1とこのスレの1は別人だよな 前スレの1は固定つけてくれたほうが分かりやすくて助かるんだが 471 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 10:59:31.60 ID:Sbqo4kno.net] >>457 メソッドを使わないテストコードって何それ？怖い。 472 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:00:58.59 ID:ZPhk/eMO.net] >>459 > だれも「全く」なんて言ってないのに... >>430で言ってるだろｗ > テストの重複の話に至ってはその和田某氏は重複を許容（=リファクタリングしない）って言う発言すらしてるぞ w 重複を許容（=リファクタリングしない）って。 それとも自分の意見を変えるのか？ 重複を許容（＝でもリファクタリングはしない） 473 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:01:32.08 ID:ZPhk/eMO.net] >>462 「メソッドを使わないテストコード」ってどこに書いてあるの？ｗｗｗ 474 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:03:00.27 ID:ZPhk/eMO.net] >>463訂正。 × 重複を許容（＝でもリファクタリングはしない） ○ 重複を許容（＝でもリファクタリングはする） それともこっちのほうがいいか？ｗ 重複を（一部）許容　（＝その一部以外は重複を省くためのリファクタリングをする） 475 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:03:15.46 ID:Sbqo4kno.net] >>464 「クラス・メソッドを変えてもテストコードの修正は不要」なんだろ。 テストコードでクラス、メソッドを利用しているなら クラス・メソッドを変えたらテストコードも変更が必要なのでは？ どういうことなのか合理的に説明しろ。 476 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:03:54.53 ID:ZPhk/eMO.net] >>466 クラス・メソッドが変わっても動作が変わらないならば テストコードの修正は不要。 477 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:04:42.44 ID:Sbqo4kno.net] >>464 それともクラス・メソッドを「変えても」の意味が不明ないのか？ 「変えても」とは>>420の意味か？ 478 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:05:45.72 ID:ZPhk/eMO.net] 例えば、設定をYAMLに保存する、クラス・メソッドがあったとして、 それをXMLに保存する、クラス・メソッドに置き換えた時、 何に保存するかを隠蔽されている状態でのテストコードは修正が不要 479 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:06:57.96 ID:Sbqo4kno.net] >>469 つまり>>420ってことだろ？ YesならYes、違うならお前の言葉で正確に定義してくれ。 480 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:10:25.36 ID:Ux1fTD3c.net] >>457 ホワイトボックステストって知ってる？ 481 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:10:26.64 ID:Sbqo4kno.net] どうした？ 変更範囲の正確な定義も認識せずにこんだけ主張してたの？ インタフェースは変えないことが前提なんだろ？ 482 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:10:48.42 ID:ZPhk/eMO.net] >>470 二通り有る。 クラス・メソッドを変える時、正確に言うとテストより先に変えるとき、 それはリファクタリングや実装の変更（挙動は変わらない）ものしかやってはいけない。 クラス・メソッドの仕様が変わる → ならば テストを変えるのではなく。 仕様が変わったら、テストコードを先に修正する。 そして実行したらテストに失敗する。それは「バグがある（もしくは未実装）のクラス／メソッド」と 同じ扱い。テストが通るように、クラス・メソッドを書き換える。 クラス・メソッドを変えてもテストコードの修正は不要 テストコードを修正した場合には、クラス・メソッドの修正が必要 483 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:12:03.63 ID:ZPhk/eMO.net] 補足 クラス・メソッドを変えてもテストコードの修正は不要 テストコードを修正した場合には、クラス・メソッドの修正が必要 ただし、テストコードのリファクタリングの場合には、当然クラス・メソッドの修正は不要 484 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:14:33.02 ID:Ux1fTD3c.net] >>463 で、どこに「全く」なんて入ってるんだ？ w 重複コードの排除はリファクタリングで普通にやられてますよ objectclub.jp/technicaldoc/refactoring/refact-smell#1 485 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:15:47.82 ID:Sbqo4kno.net] >>473 これは設計中の変更と普通は呼ぶ。 当然あるけど、お前が主張する設計ができてなくてもテストから開始するという プロセスとは関係ないので、これはお前の言ってる話からは除外しよう。 >クラス・メソッドを変える時、正確に言うとテストより先に変えるとき テストから開始するというプロセスを前提にしてインタフェースを帰る場合は >テストコードを修正した場合には、クラス・メソッドの修正が必要 となるだろ？ これもYesならYes、違うならお前の言葉で正確に説明してくれ。 486 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:18:11.64 ID:ZPhk/eMO.net] >>475 > 重複コードの排除はリファクタリングで普通にやられてますよ それ以外のリファクタリングもあるだろｗ ↓これお前が言ったセリフな 「重複を許容（=リファクタリングしない）」 重複を許容するが長すぎるメソッドを短くする objectclub.jp/technicaldoc/refactoring/refact-smell#2 これは、重複を許容していてもリファクタリングだろ。 487 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:19:30.24 ID:ZPhk/eMO.net] >>476 > これもYesならYes、違うならお前の言葉で正確に説明してくれ。 さっきから、俺の言葉で正確に説明してるだろ。 アホかｗ 488 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:21:49.03 ID:Sbqo4kno.net] >>478 俺の理解があってるならYes。 何か違うならどこが違うか説明しろってことだが。 お前のやり取りって、他の人とのやり取り見てても認識がずれてるから ちゃんと確認してるんだよ。 で、はっきり回答しろ。 489 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:22:50.08 ID:ZPhk/eMO.net] >>479 だから、Yesって言わないで、 何か違うから、俺の言葉でずっと説明してるんだが？ 490 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:23:38.96 ID:Sbqo4kno.net] >>480 >>476に対する返事はない。 491 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:26:28.37 ID:ZPhk/eMO.net] >>481 > テストから開始するというプロセスを前提にしてインタフェースを帰る場合は > >テストコードを修正した場合には、クラス・メソッドの修正が必要 > となるだろ？ > > これもYesならYes、違うならお前の言葉で正確に説明してくれ。 となるだろ？と言われても意味不明なんだが？ Yesもなにも、それは俺が>>473で言ってる言葉だｗ 492 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:33:29.79 ID:Sbqo4kno.net] >>482 >>473がおかしいんだがｗ お前はテストから開始するというプロセスについて主張してるのに 「クラス・メソッドを変える時、正確に言うとテストより先に変えるとき」 ってお前が言ってたプロセスと違うじゃん…。 何言ってんだ？って状態だから確認してるんだけど。 493 名前：デフォルトの名無しさん [2016/06/04(土) 11:35:05.80 ID:AIJuo/HE.net] Haskellを使えばテスト必要ない。 494 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:38:09.90 ID:ZPhk/eMO.net] >>483 > 「クラス・メソッドを変える時、正確に言うとテストより先に変えるとき」 > ってお前が言ってたプロセスと違うじゃん…。 正確に引用しような？ｗ 「クラス・メソッドを変える時、正確に言うとテストより先に変えるとき、 それはリファクタリングや実装の変更（挙動は変わらない）ものしかやってはいけない。」 何も違ってないじゃん？ テストよりも先に変えるって言ってる。 テストよりも先に作るなんて言ってない。 それは即ちテストがすでにあるということ。 クラス・メソッドを変える時にはテストがすでにある。 言い換えるとテストを先に作っている。 クラス・メソッドをテストよりも先に変える時、 それはリファクタリングや実装の変更（挙動は変わらない）ものしかやってはいけない。 495 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:40:47.53 ID:Sbqo4kno.net] >>485 意味分からん。 これとか謎過ぎる。「テストよりも先に変える」のに「即ちテストがすでにある」って時系列がどうなってんだ？ >テストよりも先に変えるって言ってる。 >テストよりも先に作るなんて言ってない。 >それは即ちテストがすでにあるということ。 テスト、設計、変更とかのステップの順序を正確に書いてくれ。 496 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:43:51.80 ID:ct4DNQD3.net] 48 ：まちがって名前消しちゃいました。：2013/04/29(月) 00:46:16.62 ID:??? それでCPU云々ぬかしてるとか、バロスｗｗｗｗｗ 49 ：まちがって名前消しちゃいました。：2013/04/29(月) 00:47:53.21 ID:??? コンソーレは、ポインターの使い方を知らない。 497 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:44:07.65 ID:Sbqo4kno.net] >>485 結論としてはインタフェースを変更するならテストコードも変更するんだろ？ テストコードが先にあるのにインタフェースを変えてもテストの変更がいらないケースがあるなら どういうケースなのかちゃんと説明しろ。 498 名前：デフォルトの名無しさん [2016/06/04(土) 11:45:12.68 ID:AIJuo/HE.net] コンソーレはポイントゥの使い方を知らない・・・の方が良いのでは。 499 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:45:18.46 ID:pn86qigp.net] visualstudioが提供するような ユニットテストはいらんなぁ uwscで一巡出来ればいい感じ 500 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:47:15.90 ID:ZPhk/eMO.net] >>486 あー、わかったｗ コードをテストコードよりも先に変えるときはリファクタリングしかしないから 結果的に既存のテストは変えないよｗ そうだね。そこは間違った。 たいていリファクタリングする前には、既存のテストは変えないが 追加して不足しているテストを書くことが多いので勘違いした。 501 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:49:24.99 ID:ZPhk/eMO.net] >>488 > 結論としてはインタフェースを変更するならテストコードも変更するんだろ？ インタフェース（仕様）を変更したいならテストコードを先に修正してから バグが有るコードの状態にしてからコードを修正する。 これは一般的なTDDのやり方どおりだ。 502 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 11:51:19.80 ID:Sbqo4kno.net] >>492 インタフェースを変更するならテストコードも変更するってことだな。 となると、インタフェースの変更はテストコードと本体のコードの両方の変更が必要になり 工数の負担が大きくなる。 503 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:02:21.37 ID:ZPhk/eMO.net] >>493 何と何を比べてるのだ？ インターフェースを変更したときに、それを手動でテスト（全部をね）するか テストコードで自動でテストするかだろ。 テストコードを書かなかったら、工数の負担はもっと増える。 504 名前：トの名無しさん mailto:sage [2016/06/04(土) 12:03:36.51 ID:gXar6Rt9.net] あるいは更新されない仕様書とかね 505 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:03:44.99 ID:Sbqo4kno.net] >>494 設計からやる場合との比較。 設計中の変更はテストにもコードにも影響しない。 テストを設計により先にやるならインタフェースの変更はテストにもコードにも影響する。 506 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:05:11.04 ID:ZPhk/eMO.net] >>496 その3つだけで言うならば、 設計 → テストコード → コード の順番だろ。 507 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:05:48.96 ID:Sbqo4kno.net] というか、テストを設計により先にやるべきだと提唱してる人なんていないと思うぞ。 何か誤解してるのでは。 508 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:06:47.90 ID:ZPhk/eMO.net] > テストを設計により先にやるべきだと提唱してる人 え？ そんなこといい出した(>>496が初出）のお前じゃねｗ 509 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:06:48.91 ID:Sbqo4kno.net] >>497 それって設計を先にやってるじゃん。 テストを設計の前に開始するって謎プロセスは何だよ？ｗ 510 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:07:48.23 ID:ZPhk/eMO.net] > テストを設計の前に開始するって謎プロセスは何だよ？ｗ 何だよって言われても、それお前以外誰も話ししてないんですが？ 511 名前：デフォルトの名無しさん mailto:sage [2016/06/04(土) 12:10:26.85 ID:Sbqo4kno.net] >>500 これはお前の書き込みかと思ってた。これについては同意しないと？ >>424 OOPや従来型の「しっかり設計してからコーディング」とはやり方が根本的に異なる。 デタラメでもいいからコーディングし、単体テスト/レグレッションテストの環境を構築してから

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef