ふらっと C#,C♯,C#(初心者用) Part134
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C#(初心者用) Part133
http://mevius.5ch.net/test/read.cgi/tech/1510056685/
■関連スレ
C#, C♯, C#相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured enumなんて存在すら忘れてた
もうクセでデータ保持するクラス作っちゃってたわ
やっぱ固定値の列挙はenumの方がええんやろか >>411
それでいいよ
ビジネスが入り組んできたらクラスにリファクタリングすればいい
俺は最初からクラスにしてるけどね >>410
> システムにばら撒かれたenum100個なんて管理しきれないよ
enum 使ったことないのか?
なんか実務を知らないのに
http://iwa4.hatenablog.com/entry/2013/03/04/180521
とかを見て switch は悪 ⇒ enum 不要
とか拗らせてるって感じ w enumをクラスにするという考えがあることが根本的な設計のセンスの無さを感じる そのenumを置き換えたクラスを使う場所が100個あって後段でそれぞれ違う処理(メソッド)が必要なら
100個のクラス*100のメソッド=10000必要になる
本当に管理しきれるのかな
記号は記号でしかないと思う 君たちはさC#を使ってるけどOOPはできてないんじゃないかな?
たぶん昔ながらの手続き型のパラダイムから進歩してない
フィールドやプロパティは丸出しで
データベースの物理構造を色濃く反映したDTOを
ネストしまくり分岐しまくりのやけに長いトランザクションスクリプトで処理する
そんなコードばかり書いてるんだろ? >>416
仕切れるよ
疎結合高業務で責務がしっかり分けられてるからね
というかそれで管理できなかったらクラスという枠組みを失い無秩序状態になった同じ数(経験上もっと多くなるが)の処理なんて余計に管理できないだろ >>417
キミ自身、キミの言う「昔ながらの手続き型のパラダイム」でキミの考える最強の「OOP」をしとるんやで
もう少し脳を鍛えようか?ね? 滅茶苦茶レベルの低いところで仕事してるんだろうなあってのは伝わってくる >>418
いや、あんたの主張は疎結合どころか、enum相当のクラスに結合しまくりだろう。 >>421
疎結合だよ
クラスにすればenumを使う側はenumの振る舞いの実装を知らなくていい
クラスにすればある値と他の値の処理が同じスコープで干渉しなくて済む
こんな基本もわかってないんだよなぁ
ま、初心者スレってことか \
 ̄ヽ、 _ノ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
`'ー '´
○
O
,.- ‐── ‐- 、
,r'´ `ヽ
,イ jト、
/:.:! j i.::::゙,
i:.:.:| _,, ,、--、 !:;;;;|
|;;;;j ,r''"二ヽ r'⌒ヽ !;;;!
,ヘ;;i! ,,_r ・,ン.:! {〈・_,>、,, jヘi!
〈 j>j、 "´, イ `ヽ ,':::〉!
`ゝ.`, ノ、__,入 j::rソ
`゙i / ,r===ュ, `, '.:〔_
}! ! i.:::::::::::.:! ;! .!::::j::`` ー----─r- 、
, イ.:ト、 ゙===='′ ,イ!:::::!::.:.:.:. ゙, `ヽ
_ノ /j.:::!:トヽ、 ´ ̄` ,ノ´ ,リ::::.:!:::.:.. i. \
,.r'´ /.::!:::::::| `ヽ`"""´ /ノ.:.:.:.:.::!:.:. | !
/ .:|.:.:.:::ト、 リ / !:. ! |
/ l , へ\! /'7ヽ |: j |
. / l/^ヾ:::ト、! j! l 〉、 | | . |
/ i .::| i| j! | / `ー'′ ! j! ! はい!
ID:1RSLLPBxの勝ち!w
おまえらドンマイw enumの使い所を間違えるようなレベルの人間でないと共感は得られないと思う ステータス(状態)をクラスにしちゃうと色々と説明が必要になっちゃうけどな
もっと素直に設計できねぇの?
お前らの剣は無駄な動きが多過ぎる すみません。質問ですが、例外とエラーの違いって何ですか? 状態に複数の要素が絡んだ時、彼はどうクラスを設計するだろうか >>425
>>427
>>429
負け惜しみが見苦しすぎるw 例外は制御がぶっ飛ぶやつ。
エラーは、正常に処理ができなかったという意味。 状態数も20くらいまでなら把握できるが…それ以上はいやだねえ… >>428
ここで言っている例外はtry-catchでcatchで受けられる処理(Application Exceptionの類)の話
そのエラーの意味が何に対するエラーなのかわからないので違いは説明できない enumだらけの.net frameworkを、enumじゃなくてクラスにしろよなんて思いながら使ってないだろうよ >>434
ベーシックライブラリと業務システムのドメインロジックを同じ感覚で書くプログラマは居ないよ >>435
だから普通は使い所をわかってるから、こんなこと何の議論も起こらないよねって話じゃん このスレ来ている時点でみんな初心者。スレタイに「初心者用」ってちゃんと書いてあるから 初心者ならいいんだけど、初心者を卒業したと勘違いしてる ID:1RSLLPBx が痛々しいだけ 計算量の観点で比較すると
switchはコンパイラが2分探索にしてくれる場合がある O(log2(N))
クラス化はインスタンス生成された時点で仮想関数テーブルが紐付く O(1)+ディスパッチのコスト
で合ってる? >>443
switch でも状況によってジャンプテーブルにしたりするんじゃね? >>444
C#はジャンプテーブルも使うみたいですね
この比較はあんま意味ない気がしてきたので閉めます 俺以外でここまで書き込んだ奴は明日朝一で中央線に飛び込んで死ね 仮想メソッド呼び出しはJITがインラインキャッシュで展開するからコストはほぼゼロのはず 補足
展開っていってもインライン展開するわけじゃないよ
静的なメソッド呼び出しに置き換えるということ >>449
vtable を間に噛むんじゃないか? shapeクラスをベースに持つrectangleとcircleクラスの挙動をswitchで制御してるならOOPに反すると思うけど
確固たる概念も実体もないものをわざわざクラスにしてまでenumを消す理由はない
普通のマジックナンバー代わりの記号がenum
オブジェクト間でクラスがメッセージをenumで渡すだけ
上手に使えばいいだけ >>453
お前も勝利宣言しとけよ
明日以降やられてもたまらん 実体の無い物をクラスにしたらドキュメント書けよと
それだけだけどな
書かないでやってる奴はギルティ メッセージがただの記号だったのにクラスになるとオブジェクトの生成や
必要に応じてライフタイム管理が必要になる
しかも作ったオブジェクトに処理を移譲したり他のオブジェクトを渡したりして新たなオブジェクトと結合が密になる恐れがある
そこまでしないなら記号の受け渡しで済んだものがクラスの管理が増えるだけでメリットは薄い > オブジェクトの生成
状態変わらないのだからpublicなstaticメンバで持てばよい
> ライフタイム管理
そんなに気になるのならstructにすればよい
> 処理を委譲したり(最後まで)
全く意味不明 一晩経っても負け惜しみ言ってるやつ居てわろた
せめて反論したらどうなの?
>>457
メッセージを列挙値で済ませようとする発想がまずチープだがまあいい
RegexOptionsみたいな場合もあるからな
問題はドメインオブジェクトを列挙値で表現してしまうケースな
昨日から議論してんのはメッセージの話じゃないんだよそもそも
君はまだそこを理解してない どうしてもenumにこだわりたいのなら
Attribute付加
拡張メソッド作る
こんな手段はある 他のオブジェクトとの関連云々ってさ
べつに列挙値からオブジェクトにしたから急に関連が出てきたものじゃないんだよね
ドメインの性質としてもともと本質的に関連があるものなんだよそれは
それがオブジェクトにしたことによって可視化されただけ
列挙値のままだと関連があるのにそれがハッキリと見えず暗黙の結合状態になってるだけ
それはまさに最悪の状態だよ 設計書の構造に箱ができないものをクラスにするのはセンスが悪いな
こんなゴミクラスたくさん作っちゃってクラス図でどうやって説明するの? 汎用ライブラリにでもぶち込むならともかく
こんな枝葉までクラスにされるとソースの粒度に統一感がでない
ステータスなんかクラスにすんなよ
ドキュメント書くのが面倒くせえだろ
それはイコール他人に説明する手間が増えてることだと気づけよ
どーせドキュメント書かないんだろお前馬鹿だから 他人に説明するためのドキュメントは確かに書かないな
ソース見たほうが早いし間違いがない
ソースコードが設計書である
俺が馬鹿かどうかに関係なく、
アジャイルやGOAでやるとどこでもそうでしょ >>466
ワケのわからんソース書くやつに限ってお前みたいなこと言うのな ちょっと昔な感じだな
今は当たり前にドキュメントを書いてる時代だと思うけど おはようございます。(改行大杉で怒られたので行間を詰めています。
現在押し付けられて困っていることがありご教示いただければと思っております。
環境:フレームワーク4.71 + MVCフレームワーク5OS:Win2012
現在上記環境で動いているシステムがあり、
いくつかのリクエスト文字列と画像ファイル1つをマルチパートで受け取るシステムがあります。
今回、アンドロイド側のJAVAアプリからデータをマルチパートでPOSTしてくる予定だったのですが
時間不足で実装できないと言われ、データを以下のように送ると言ってきています。
(AndroidといえどJavaと同様なのでマルチパートのOutputStreamを作成して送ってくるだけだと思うのですが…。)
1.ファイルをバイト配列に変換
2.そのバイト配列をBase64エンコード
3.最終的にUTF-8の文字列にして通常のリクエスト文字列として送信
上記の仕様だそうです。
そこで上記の逆手順を…と思い
考えれる範囲で
1.リクエスト文字列をUTF-8バイト配列に変換
2.そのバイト配列をChar[]に変換
3.Char[]をFromBase64CharArrayでバイト配列に変換
とやってみたのですが
System.FormatException: 入力は有効な Base-64 文字列ではありません。
上記例外が当然のように発生します。
単純にアンドロイド側からBase64で送ってもらえればそのままデコードできるのですが
それも突っぱねられて困っています。
そもそもこの逆変換が技術的に不可能なようであれば相手側に強く言うこともできるのですが
その根拠が示せず言い出せません。
1.そもそも可能なのか?
2.手順的にはどのようにするのがよいのか
ヒントだけでも構いませんのでご教示いただければと思っております。
以上です。 >>470
欲しい形の文字列とどう違うのか比較してみろよ >>471
ありがとうございます。
あぁ、なるほど!
該当ファイルをBase64文字列にして
その差を比較してみて両者が合うように変換していってみる
ということですね。
ちょっとコツコツやってみることにしてみます。 >>470
リクエスト文字列を直接Char[]にせずバイト配列にいったん変える意味が分からない
リクエスト文字列がBASE64の文字列でなければFromBase64CharArrayは使えない
https://msdn.microsoft.com/ja-jp/library/vs/alm/system.convert.frombase64chararray(v=vs.71).aspx/html switchを無くせって話、WPFとかのMVVMにちょっと似てるね
どっちの場合も原理主義者が主張するような美しい理念がワークするのは、
ある一定の条件というか閾値を超える事例だけであって、それ以外の場合は
かえって可読性とか保守性とかが低下すると思うんだけど、原理主義者がそういう現実を
無視して何にでも適用可能な万能の方法みたいにごり押ししてる感がある 多少冗長になっても1つのルールに沿って全部書いた方が読みやすいだろ もういい加減組めちまってる奴は
次の課題を自分で探さないといけない
プログラムスキルは組めるようになったら
そこでMaxなんだよ
さっさと次の課題を探さないから
どーでもいいことが意味ありそうに思えてくる >>378みたいなケースでswitchをなくせ
って言うのはそりゃそうだなって思うけど
そもそも>>378の最初の方の組み方がおかしいだけでenumの問題じゃない
それを>>378の例だけでswitchをなくせと言うならまだしもenumなくせとか言い出すから頓珍漢なことになってるだけ >>743
レスありがとうございます。
相手が手順的にBASE64のバイト配列をUTF8文字列にして送ってくるようだったのでその手順が必要なのかな…と思いまして。
そもそも何故バイト配列からBASE64の文字列にダイレクトにしなかったのかと…。おもいつつです。 >>470
元の仕様
1.ファイルをバイト配列に変換
バイト配列ができる
2.そのバイト配列をBase64エンコード
ファイルをBase64エンコードした文字列ができる(仕様上UTF-8でもシフトJISでも同じ)
3.最終的にUTF-8の文字列にして通常のリクエスト文字列として送信
これが何の変換かわからない(2.の理由により必要がない)
まず元の仕様を勘違いしていないか?
その上で逆手順のテストコードバグっているから不必要にややこしくなってる ファイルをバイト配列に格納→をBase64に変換
↓
Base64をバイト配列に変換→バイト配列をファイルとして保存 >>470
あとBASE64の文字列の長さは4の倍数でConvert.FromBase64CharArrayにそれ以外の長さのChar[]を指定するとエラーになる
不足分を自分で埋める('='で埋める)必要があればそれもやらないと 多分UTF-8のBOMの有無でずれているんだろうな
手順がいくら増えようが不可逆になることはない >>477
誰もenum無くせとは言ってないぞ
ドメインクラスをenumで表現するなって言ってる ドメインが理解出来ていないからすれ違いのままなのかな >>483
お前が誰か知らんけど
>>376
> ダメとは言わないがコード整理するとenumが自然と消える
とか言ってたアホがいるって話 >>485
外人?
ダメともなくせとも言ってないじゃん はいはい、言葉尻にしか反論できないってことね
可哀想だな w goto文をなくせの頃から何にも変わってないな
gotoをなくせ
enumをなくせ
switchをなくせ
シングルトンをなくせ
ヘルパークラスをなくせ
一応どれも正しい
間違ってはいない
でもこういうルールは別に守らなくてもいい
どうでもいいルールなんだよ
DRY原則とかOpen/Close原則とかの設計原則の方がより重要あってね どっちでもどうでもいいよ
どうせ動くんだし
テストをしっかりすればいいだけ gotoとenumの間にはかなり差がある気がする
前方へgotoは絶対悪だから使用厳禁
ドメインのenumと同じかw
もうちょっと緩いと思うが
switchはパターンマッチとして使うのは推奨なご時勢だけどC#のswitch構文は力不足だね gotoは後方への方が凶悪だろ
前方だけに使う分にはbreakやtry-catchと大差ない 書いてから気付いたが前方参照の意味での前方か
失礼 >>490
ルールと呼ぼうが原則と呼ぼうが本質は何も変わらんよ
要するにバカの暴走を制限する為の足枷でしかないw >>495
〇〇をなくせというルールが馬鹿にたいする足枷でしかないのは全くその通り
だから俺みたいな賢人にはどうでもいい
逆に馬鹿に設計原則は理解出来ないだろう
SOLID原則が理解出来るならそいつは馬鹿ではない >>496
表面的な理解で原理主義に陥いってしまう奴は沢山いるし
本質的にそいつはバカなんだと思うよw
それは理解してないのだと言われればそれまでだがw 抽象的な話になると必ずこういうレスがつくなw
これもバカの典型w 初心者用スレで難しい話すんなよ
俺みたいな趣味グラマーが楽しめないだろ >>500
必ず?
今まで何度も辛い目に逢ったのかな? w tensorflow+keras+c#で
エロ画像を自動分類するソフトを
作って欲しいと頼まれたんだけど
c#から出来そうですか?
参考になるサイトないですか? ■ このスレッドは過去ログ倉庫に格納されています