C#, C♯, C#相談室 Part95
■ このスレッドは過去ログ倉庫に格納されています
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら http://www.visualstudio.com/downloads/ ■コードを貼る場合はこちら http://ideone.com/ ■前スレ C#, C♯, C#相談室 Part94 http://mevius.2ch.net/test/read.cgi/tech/1492843013/ ■次スレは>>970 が建てる事 建てられない場合は他を指定する事。 ユニットテストを意識するようになればメソッドやクラス構成マシになるのに、どうせ単体テストやるしと数百行のメソッド大量生産の俺社 メソッドは原理原則通り20行まで・・・ってのはやりすぎかもしれんけど 全ては関数にわけられるだけわける 1つの関数に2つ以上の機能があれば冗長だとは思う 関心事が1つであるべきだよ 機能数は複数あってもいい 例えば顧客オブジェクトを取得する/作成する/更新する/削除するための顧客リポジトリ こいつの機能は4つだが関心事は顧客オブジェクトの永続化という1つだけ >>602 でもやたら関数に分けまくるのもやり過ぎの悪例だからなぁ 一行メソッドのたらい回しとか可読性低すぎて引き継いだとき殺意が湧くし 1行でも意図が明確化するならメソッドにする C++とかやってきた人なら当たり前の感覚なんだけどね Expression Bodyのプロパティやメソッドがなぜ導入されたのか 1行のプロパティやメソッドはそれだけ使用頻度が高いってこと バカが書くオブジェクト指向()を舐めるなよ? あいつら『かめはめ波()』の機能を か() め() は() め() 波() にするレベルでバカだからな 意味を理解しておらず側だけ真似するからそうなる 猿は木の実でも取ってろ 独立している機能なら一行でも良いが 一連の塊で動いてる機能を再利用性の欠片もないパーツに切り分ける奴は頭が悪い しかもその切り分けた関数で他の関数を実行してたらそれはもうただの難読化だ >>606 これが答えだよ Microsoftや達人プログラマ達は1行メソッドの価値を理解して言語仕様まで変えてしまった それほどまでに重要なものってことだ 一方で雑魚プログラマのお前らは価値を理解できずにぐちぐちと文句を言う 程度の低さを伺えるね コメント代わりに関数使う>>611 みたいなのが害悪なんだよな プログラム構造が見渡せる行数になれば、ソレ以上の細分化は無意味なんだけどね メソッドの分割は中身を理解しやすくするのが最大の目的で、それを阻害するほど分割したら意味がない 俺もコメント代わりに分けまくる派 純粋関数で責任が明確なら可読性は上がるよ 一目見たら分かる処理をオレオレ命名で飛び地化 お一人様開発なら良いがチームでやんなよ void MoveAX(unsigned short val); >>613 コードで表現できるものをコメントで書くバカが本物の害悪だよ >>618 コードで表現出来てることをわざわざ関数名で伝えようとするバカが何だって? >>614 中身を理解しやすくするのは実装の仕事 メソッド化する最大の目的は実装と意図を分離すること 僕が引用したリンク先でマーティン・ファウラーがわかりやすく説明してくれてるからぜひ読んで欲しい 三行で書かれてるコードならその場でその三行を修正するだけで済むが、 それを三つの関数に分けるとわざわざ別の行までスクロールして修正する作業が三回発生する どちらが効率的で生産性が高いのか普通なら考えるまでもなく分かることだが、自意識過剰なバカには分からないのかも知れない 何せ自分のことを『達人』とか思い込んでるレベルのバカだし >>620 コードで表現していることを関数名で抽象化するんだよ 抽象化はプログラミングをする上で最上級に重要な概念だけどどうもIQが凡人以下だと理解できないらしい 物事を理解するにはその内容に応じた知能がどうしても必要になる 凡人が数学者や物理学者に成れない 難しい概念がわからないという感覚は人としてどうしようもないものなんだ だからこのスレにも抽象化がわからない人が居てもおかしくはない >>622 場合によるんじゃないかな? その一行が何度も出てくるなら関数化したほうが修正が楽 何百回修正するか 一回修正するか >>622 そのコードがなんのためにあるのかということを考える作業が3回も発生する そのコードを変えて他に影響がないか確かめる作業が3回も発生する 同じことを他の場所でしていないか確かめる作業が3回も発生する 酷い無駄だ 関数化で抽象化はされる 抽象化された関数で何をやってるか詳しく関数名に入れると無意味なことになることもある むずかしいよね bool IsEmpty() => this.Length == 0; このレベルの実装であれば何も文句はないが、大半はそうじゃないのが現実 適切な直行化ができてれば、一連の処理の流れに関わる多数の関数を一緒に修正するなんてことはそうあるものではない その程度のスキルレベルなら分け過ぎはよくないのは同意する もともと一行関数だったものが徐々に成長していくこともある でも呼び出し元のコードは変わらない ロジックが変わってないからね これは大変素晴らしいことだと思う 十分に責任の明確化ができている関数は中身を見る必要が無くなる 不要になって消すことはあっても中身を弄ることはめったにない この名前でこの引数を受け取るならこの結果が返るのが当然、と思えるのが正しい関数だ >>627 をバカが真似した例 void Increment(ref int a) => a++ (※現実にあったコードです) >>631 そのレベルの現場ならCOBOLみたいにMOVE羅列してる方マシだね 世の中そういうところばかりではないから文句があるならさっさと転職しろ コードを書いてる時点で将来をすべて予見できるような素晴らしい環境にいるならいいけど 大体はそんなことはない 仕様を考えたのが他人であろうと自分であろうと >>631 範囲を扱うアルゴリズムに使わせる目的で使うイディオムだよ こうしておけばプリミティブの数値も数値っぽい型(例えば巨大整数クラス)も同じように扱える ようするにただのストラテジだな まあ正直C#で>>631 は無意味とは言わないまでも違和感あるけどな >>631 もC#だけでなくc++とか経験してみるとこういう短い関数の真価を理解できるんじゃないかな 巨大整数とか仕様にカスリもしない未来を妄想して複雑化して「これがシンプルなんだよ!」と強弁するとかアホの典型だな グループ開発の経験もない無職かよ 最初から無駄に俺様カスタマイズしたがるのはこじらせたC++erによくあるYAGNIだね そして、Incrementの例のように基礎的な部分には異常に拘るくせに普通のアプリケーションコード部分は巨大なメソッドを生産する奴が多い その割にはポインタ演算は大好きで、配列操作になるとウッキウキしてクソ低レベルなアスタリスクと++だらけのコードを垂れ流す そういう連中だよ ふらっとも伸びているようだし承認欲求に飢えているアホどもが暴れているのか >>638 でもそれってお前の妄想じゃん c++の仕事任されるほどスキルないっしょ? >>641 「巨大整数にも対応してるオレ様のフレームワークを使えー!」 どんな面白い問題で盛り上がってるのかと思ったらしょうもな。 (1) 道具が多すぎる道具箱は使いづらい からと言って (2) 短すぎるメソッドは「無駄な道具」である などと言えるわけがない。 そうである場合もない場合もあるに決まってる。 こんなくだらない話でよく盛り上がれるな >>643 だから無駄な道具を乱造して散らかす奴が悪いんだろ? いくら「これが正しい!」と喚いてもゴミ屋敷をスマートとは言えんわ なんかずれてんな いやわざとか? みんな「1行コードはクール」 みんな「いや害悪だ」 >>631 「1行コードにはこんな意味不明な頭悪いコードが実在するんだぜぇ」 >>634 「いやーそれはストラテジでしょ。普通のコードだよ」 あほ「巨大整数ガー!ゴミ屋敷ガー!」 途中から明後日の方向に向かってんだよ 一例に過剰反応バカが湧いてきたあたりからね 一つ言えるのは、一行コードをセンスが無いやつが書くとゴミクズになるってことだな まあ何行でもゴミと言えるかもしれんが、一行のゴミはメンテする時腹が立つ 1行メソッドの利点を理解できないアホが逆ギレしてるだけのパターンもあるということは忘れないで 一行のゴミにも何か利点はあるはずだと頑なに改めようとしない>>647 なのであった マジでゴミ屋敷の主だな >>645 はstrategyも理解してないアホの子だから許してあげて ただのラッパーを戦略と勘違いしてるなんて、きっと今年の春から働き始める新人だから 上司「なんでこのインクリメントを関数に分けてんの?」 新人「様々な型に対応する為のストラテジです!巨大整数などにも対応できます!」 何というか無能な働き者って言葉がしっくり来るな たぶんこいつは誰からも理解されずに五月病患って数ヶ月で退職するわ インクリメントの(多相じゃなくて正しい意味での)ストラテジって何だろうね ++とInterlocked.Incrementを切り替えるとか? エイプリルフールネタにもならんな ここには初心者スレに行ったほうがいいような連中しか居ないようだな ゆとり世代はなんでも揃ってるところからスタートだから楽でいいよな iteratorの実装なんて考えたことすらないんだろう 羨ましいよ >>650 何で巨大整数に対応する必要ない状況を前提としてるの? 対応すべきという状況を前提とした途端に真逆の結論になると思うけど 仕様上ありえない予測 それを人は 妄想 と呼ぶのだ 巨大整数対応を勝手に仕様上あり得ないことにしている点 「○○にも対応できるように」の○○に巨大整数を入れるのはあくまで一例であり他にも山ほどあり得る点 この辺りが問題かな 言われた通りの物を納品すればいい所謂IT土方系の環境なら問題にならないんだろうけど >>656 対応すべきという状況を前提にしたとしても、>>650 の新人がストラテジパターンを誤解している阿呆であるという結論は覆らない >>631 を型ごとに用意するのは一般にはパラメータ多相、あるいは単にオーバーロードと呼ぶんだよ すまん訂正 パラメータ多相じゃなくてアドホック多相だな この手のっていつも「自分の前提」の元に議論初めてかみ合わないんだから止めとけよ ネタが下らないことだし、そんなことにこだわるしかやることないのかよ int型をBigInt型に切り替える必要が生じたとして、 型宣言から書き直さないといけないのにインクリメントを分離しておいて何が効率化できたというのかと そもそもオブジェクト指向に則ればその型自体にインクリメントを備えるだろっていう 現実に設計したこともない新人が本の知識で言ってるだけだなこりゃ 正しい設計 INum num = new Num() // INum num = new BigNum() ←クラス名を変えるだけ num++ ←機能は型で規格化されてるので変更無用 間違った設計 Num num = new Num() // BigNum num = new BigNum() ←型から変える必要がある Increment(ref num) ←何これ? void Increment(ref Num n) 処理 void Increment(ref BigNum n) 処理 ↑型の数だけオーバーロードする必要がある どーでもいいことかもしれんが、セミコロンがないのが凄く気になる >>660 はぁ? どう見てもストラテジだろカス void func<T>(T mi, T mx, FuncObj<T> increment) { for(T i = mi; ! i.Equals(mx); increment.Exec(i)) { // } } class BigIntIncrent : FuncObj<BigInt> { public Exec(ref BigInt x) { x = x.Add(1); } } >>663 なんでBigIntのソースが手元にある前提なんだよ まあ素人は標準のパッケージ以外を持ってきて使うなんて経験はないのかもしれんから間違えても仕方がないか 君素人っぽいし >>665 惜しい。一旦クールダウンしてよく考えよう。 同じ入力(コンテキスト)に対して複数のStrategyを定義し、状況によって使い分けるのがStrategyパターンだ。 一方incrementの場合、実装は入力の型に応じて一意に決まるだろ?「同じ入力」に対して複数の実装があるわけじゃない。 そういう、引数の型に応じて静的に実装を選択するのを一般に「多相」という。 特に、君のコードは関数型言語で型クラスと呼ばれるものに近い。ググってみると勉強になるよ。 >>667 1つ飛ばしでイテレートしたい場合とか同じ型でも幾らでもバリエーションは考えられるわけだがわかんねえだろうな用意されたもの使うだけのゆとりには >>665 なにこの頭悪すぎるゴミ 意図が読めない典型じゃん >>669 あらゆる物事に対してそれを理解するために必要な知能の下限が存在する これって1つの真理だと思うのよ >>670 funcって何? funcObjって何? miって何? mxって何? Execって何?どういう機能? BigIntでAdd?コレクションなん? パッと見ただけでこれだけ疑問が湧くんだが、 プログラマ百人に聞いたら百人が死ねって返すレベルのクソだぞこれ 命名だけでバレる実力なら無理して書くなよ >>668 そうだね。確かに君の言う通りだ。 じゃあ君はなぜ>>665 でわざわざジェネリックを使ったのかな? >>665 を見た殆どの人は、型に応じて++の実装を切り替えたいのだろうと思うだろうね。それを君はストラテジだと言っている。 このままでは誤解してしまう人もいるだろうから指摘したんだよ。 君自身はもしかしたら本当は正しく理解してたのかもしれないけど、衆目に晒すにはあまりにも不適切なレスだ。 文脈読めない、中心になってる話題を理解して枝葉末節を気にしない、っての実践するにもある程度の知能が必要なんだろうなー そういうの苦手な人ってミーティングの時とか相当鬱陶しがられてると思うから注意したほうがいいよ >>665 これforでローカルに代入してるが値型のつもりなのか? >>673 悪いけど、文脈を読んだら>>665 のコードは100人中100人が型++を切り替えようとしてるのだろうと解釈すると思うぞw >>672 ジェネリックかどうかは関係ない話だろ この例も仮にスクリプト言語だったら型引数は無くても動作する たまたま型の指定が必要な言語を例に使ったからジェネリックになっているだけ しかしそのエッセンス自体は何も変わってない まずはそこを理解しよう >>665 を読むとこいつうちにいた新人より頭悪い気がする ストラテジとか言いながらやってることが関数型だし これでデザパタのつもりなら学校通い直すのを勧める ここでいうエッセンスというのは * 処理の一部を外部から与えることによってアルゴリズムを交換可能にするテクニックをストラテジーパターンと言う * ストラテジーはしばしばインクリメント処理のように非常に小さな処理になることがある * その一例が>>631 であり>>631 馬鹿げたコードでもなんでもなく実用的なコードの断片である という3点のことな >>678 λや関数オブジェクトがサポートされる言語では暗黙的にストラテジーの考え方が利用されている そうと意識してないだけだ ちょうどいい時期だ上司に頼んでお前も新人研修受けてこい 何も見せてなければ何とでも言えたろうが、 >>665 を見せてしまったらもう無理だな レベルの低さが露呈してるから言い訳にもならない 正直>>665 を見たあとだと>>631 が優秀に見えるくらいだし >>680 世間一般的にstrategyというのは>>663 の例を指す お前のは違う そもそも関数の細分化は可読性を損ねるって話なのに、 抽象的で省略しまくりの名前付けてる時点でな 設計に口出すのは十年早いと思うわ どうでも良いが>>665 をよく見るとこいつrefの使い方すら知らないど素人くさいな 値次第でループバグ起こす構造だしこんなコード実務で仕込まれたら俺ならテロ認定する 本気で書いたコード貶されたら 「あれは手抜きだからw」と言い出す まあリアルにいるよな ミーティングとか言い出して露骨に話題を避けようとしてるの笑える stringが参照型ってことはさ string str; void Reset() => str = ""; とするより string str; string None = ""; void Reset() => str = None; と生成済みのテキストを使い回した方が効率良いの? >>692 null代入するのはC#8.0で警告対象 >>690 変わらないと思われ string Func0(){return "test";} string Func1(){return "test";} string Func2(){return "te"+"st";} string Func3(){return "TEST".ToLower();} string a=Func1(), b=Func2(); Console.WriteLine(Object.ReferenceEquals(a,b)); >>693 非推奨になるのか! って、C#5.0から変える気が無いけどもw >>690 これILはどっちも一緒の結果にならないのかね ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる