ふらっと C#,C♯,C＃（初心者用） Part160

2024/02/11(日) 09:17:20.44

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を3行冒頭に書くこと（1行分は消えて表示されない為、もう1行は予備）
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください。見かけたらNGしましょう。相手してしまったらあなたも荒らしです
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part159
http://mevius.5ch.net/test/read.cgi/tech/1691454079/
■関連スレ
C#, C♯, C＃相談室 Part97
https://mevius.5ch.net/test/read.cgi/tech/1671585518/
■コードを貼る場合は↓を使いましょう。
https://ideone.com/
https://dotnetfiddle.net/
初心者はまずVisual Studioを使いましょう。なおVisual Studioの使い方などに関しては各バージョンで違うので専用スレでお願いします
http://www.visualstudio.com/downloads/
■情報源
https://learn.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://learn.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://learn.microsoft.com/en-us/dotnet/standard/class-libraries
https://referencesource.microsoft.com/
https://source.dot.net/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html
++C++; // 未確認飛行 C
https://ufcpp.net/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2024/07/15(月) 20:16:10.09

>>535
2つの文字列間のレーベンシュタイン距離やジャロ・ウィンクラー距離を計算するといい

2024/07/29(月) 02:37:13.47

>>535
AIで

2024/07/30(火) 19:59:54.73

以前ここでドメイン駆動設計について質問させていただいた者です
ドメイン駆動設計入門を読み終わり、多少理解が進んだと思うのでまた質問させてください
・仕様パターンどドメインサービスの違いについて
　この二つの違いが良く分らないのですが、仕様パターンはドメインサービスのうち、評価とフィルタの処理に特化したものと考えていいですか？
・ドメイン層について
　ドメイン層はクラス外と繋がる部分をDIで差し替えれるようにするものという認識です
　例えばパケット送受信などの実装もドメイン層として問題ないですか？
　本やネットでは、DBを扱う層となっているので気になりました

すみませんが、ご回答のほどよろしくお願いいたします

2024/07/31(水) 00:13:39.43

本を本当に読んだのか疑問なんだけど…

2024/07/31(水) 00:13:54.84

仕様パターンはエンティティや値オブジェクトの特定の条件やルールを評価するための小さな部品。

ドメインサービスは複数のエンティティや値オブジェクトを使って、ビジネスロジック全体を実行するための大きな単位。

2024/07/31(水) 01:00:17.43

>>540
ありがとうございます
ドメインサービスって特定のドメインオブジェクトに属さないビジネスロジックを記述しますよね？
それが仕様パターンととても似ていると思うんです

あと・2つ目ですが、ドメイン層でなくインフラストラクチャ層(リポジトリ)の間違いでした
失礼しました

2024/07/31(水) 10:14:08.49

>>541
どちらもビジネスロジックであるという点が似ていると感じるのかも

仕様パターン
・あるエンティティが特定の条件を満たすかどうかを判定したい場合に使う
→ スコープが特定の条件に特化
・ビジネスルールをシンプルに表現する
・他のロジックとの組み合わせて使う
・戻り値がboolやenumが多い

ドメインサービス
・複数のエンティティや値オブジェクトを操作する複雑なビジネスロジックで使う
→ スコープが広範囲なドメインをカバー
・シンプルではなくドメインを詳細に使う
・複雑なビジネスロジックをカプセル化して使う
・戻り値が新しいオブジェクトなど様々

2024/07/31(水) 10:16:31.37

なんだ、石ころと地球の違いか

2024/07/31(水) 13:24:29.59

>>541
DDD用語でのドメインオブジェクトというのは一般的にエンティティかValueオブジェクトのこと
Specificationはビジネスルールを別個のValueオブジェクトに切り出したものでドメインオブジェクトの一つ

2024/07/31(水) 17:36:25.49

仕様パターンはデザインパターンのようなオブジェクト指向のパターン
便利だからそれをDDDに効果的に導入している

概念が違う

〇　○○は仕様パターンで実装されている
×　○○は仕様パターンである

2024/07/31(水) 21:36:07.63

以上IT言葉遊びでした

2024/07/31(水) 22:14:42.70

DDD以外の開発手法に行っても仕様パターンは仕様パターン
ドメインサービスはDDDの固有のものだからコードが同じでも違う呼ばれ方をする違う概念のものとして扱われることになるだろう

DDDには他にもデザインパターンが使われている
上に書かれているインストラクション層ではリポジトリパターンが使われている

2024/07/31(水) 22:20:55.13

インフラストラクチャ層だ
思いっきりミスってる

2024/08/01(木) 22:53:01.56

DDDは生成AIとの相性が悪いからオワコン
時代はSQLよ

2024/08/02(金) 01:59:59.79

仕様パターンとドメインサービスは概念が違うもの、というのがとてもしっくりできました
皆さんありがとうございました

>>538でもう一つ質問していますが、（ドメイン層でなくインフラストラクチャ層の間違いでした）インフラストラクチャ層にパケット送受信など記述するのはおかしいですか？
インフラストラクチャ層はDB永続化の目的だけに使うべきですか？

2024/08/02(金) 15:43:21.42

裏側の仕組みがどうであれ、それを集約としてモデリングできるなら何の問題もない
できないならDDDの範疇外だからDDD的にはお好きにどうぞとしか言えない

2024/08/03(土) 14:59:13.44

>>550みたいな新卒や未経験レベルが学ぼうとしても前提知識が多すぎて全く理解が及ばない事が容易に推測できるのがDDDのデメリット
手を出すならもっと経験を積んでからだよ最後にC#関係ねーだろカス

2024/08/03(土) 21:44:08.94

DDDの肝はアプリケーションサービスだの値オブジェクトだのといったテクニックではなく、
ユーザーと要件を詰めてビジネスドメインをオブジェクト指向モデルに落とし込む部分
それ以外は全てオマケと言っても差し支えない
誤った抽象化によりドメインエキスパートのコミュニケーションに支障をきたすようなモデルになってしまっていたら、
いかにDDDの「オマケ」を正しく使いこなした美しい設計であろうともそれはゴミなんだよ

2024/08/03(土) 22:45:02.84

DDDの勉強の前にまず就職しないと業務というものがわからんだろう

2024/08/03(土) 23:14:52.27

なんだかあまり意味のない話を書かれても

個人が自分のために開発するならそのドメインエキスパートは誰なのかと考えなくてもわかるだろう

2024/08/03(土) 23:47:05.89

DDDはそもそも開発者とドメインエキスパートが別の人間であることが前提
恋愛術を自分自身に対して実践しても仕方ないだろう？

2024/08/16(金) 12:11:24.60

address.PropertyChanged += (s, e) => {
switch (e.PropertyName) {
case "Address":
//処理の中身
break;
} };
となっているところをもっと簡素化した書き方ってできるのでしょうか？

2024/08/16(金) 12:39:59.89

君が定義する簡素化とは？

2024/08/16(金) 14:30:07.59

>>557
簡素化？とは関係ないけど
nameof使った方がいいかも

2024/08/16(金) 15:16:11.70

プロパティ名を実行時に文字列値比較するのはプログラム的に美しくない
PropertyNameがAddressの時だけに呼び出されるハンドラを定義できればベター
できなければその言語は発展途上かな

2024/08/16(金) 15:28:45.14

言語というかフレームワークの問題
別に今ならソースジェネレーターもあるのだから言語機能としては楽に実装できる訳だからな
まあ原始的に文字列比較するのは他の言語のGUIフレームワークでも往々にしてあるけど

2024/08/16(金) 16:59:52.55

>>560
>PropertyNameがAddressの時だけに呼び出されるハンドラを定義できればベター
言語的には普通にできるよ

できるけどプロパティ別のイベントとハンドラを使わずに
汎用的なイベントとハンドラが一般的に使われるのは
フレームワークがINotifyPropertyChangedインターフェースと
そこに定義されてる汎用的なPropertyChangedイベントを前提としてるから

2024/08/16(金) 23:21:57.35

充分簡素では

2024/08/20(火) 14:42:04.36

今まできちんと動いてたソースがVS2022をマイナーアップデートしたとたんに
System.Windows.Markup.XamlParseException: 'Index was outside the bounds of the array.'
って例外でて動かなくなった
.NET8.0→9.0に切り替えたら例外出ずに動くし。もう意味が分からない

2024/08/20(火) 16:56:30.17

マイナーアップデートしたからだろ？

警備員[Lv.25] (ﾜｯﾁｮｲ 9ffe-jgWm) · 2024/08/20(火) 21:31:18.51

どこが配列超えしたのか追っかければ良いのに

2024/08/20(火) 21:49:50.51

>>564
具体的なバージョンは、17.10.6と17.11.0どっちかな
後者のような奇数番台の.0は比較的大きな変更が入ってバグだらけなことがよくあるから避けた方が無難

2024/08/20(火) 22:53:56.20

バグがあるのにライブラリもバグってて気が付かないと言う線もあるので
どこでどういう風になっているのか見直したほうがいいかも

2024/08/20(火) 23:14:46.66

>>566
MainWindowにUserControl貼ってるウインドウなんだけど
UserControlのInitializeComponent();内で例外発生。で、そこのxaml削ってくとある点で例外発生しなくなるけど今度はMainWindowのxamlで例外発生
ってな感じでいっぱい例外出る箇所あって追っかけてもどうしようもなさそうなんだ

>>567
例外出るのはPreview Version 17.12.0 Preview 1.0
アプデ前のは不明
Previewやめろって？w

2024/08/20(火) 23:21:32.92

>>569
Previewで不具合出たら寧ろご褒美だろうw
勘違いしないようにもっと嬉しそうに書いて

2024/08/21(水) 08:59:40.06

Preview入れて不具合なら報告して次をまとうだろｗ
それが嫌ならPreviewやめろは当たり前

警備員[Lv.26] (ﾌﾞｰｲﾓ MM9f-jgWm) · 2024/08/21(水) 09:14:20.66

せやな

2024/08/21(水) 09:52:00.94

x せやな
o そうですね

2024/08/21(水) 12:11:33.60

せやね

2024/08/21(水) 12:35:04.54

x せやね
o そうですね

2024/08/21(水) 12:38:55.38

せやせや

2024/08/21(水) 13:40:44.38

x せやせや
o そうだそうだ

2024/08/21(水) 13:51:19.97

せやろ

2024/08/21(水) 16:14:47.22

x せやろ
o そうだろ

2024/08/21(水) 16:20:43.88

なんや（多義語）

2024/08/21(水) 16:41:36.58

せやからなんちゅーねん

2024/08/22(木) 10:49:22.21

しらんがな

2024/08/22(木) 11:03:28.50

しぇからしかっなんばいうとっと

2024/08/26(月) 10:11:56.65

ぼくのC#の基本書は独習C#新版2017年12月初版なんですけど
独習C#は新しい版が2022年7月に出てます
新しいのを買ってもう一度読み直した方がよいのは分かってるのですが、4000円もするので正直買いたくないです。でもネットでまとまった情報を入手してアタマにいれるのも苦手です
そこでみなさんに新しい版を読まない事によるデメリットを力説してもらいたいのです
よろしくおながいします

はいどうぞ

2024/08/26(月) 10:34:41.16

モダンな書き方にこだわらないのなら新しい版は買って読む必要も無いんじゃね？

2024/08/26(月) 10:41:52.10

>>584
初版だとC#7ぐらいだったっけか
他の人とコードを共有するとか他人のコードを読むとかしないのなら別に困らないんじゃね？
C#8以降の新機能って大きいところだと
null許容型
record型
トップレベルステートメント
switch式
とかそのへん？抜けてるのあるかもしれんけど
知ってると便利だけど、知らなくてもそこまで致命的ではないんじゃね？

ようするに、一人でやってるのなら好きにすればいいと思うよ

2024/08/26(月) 10:54:52.78

>>585
>>586
えーそうなんですか
最後の一押ししてもらおうと思ったのですがーｗ

ありがとうございます

2024/08/27(火) 03:55:59.11

仕事で使うなら4000円程度払えないのはおかしい
趣味で使うものに4000円程度払えない奴がこんな専門スレに来るわけがない

ようは、買っちまえ

2024/08/27(火) 06:42:47.99

本なんか買って読んでから考えろ

2024/08/27(火) 10:09:49.52

日曜に本読む国だからな

2024/08/27(火) 10:36:05.57

初心者なら買う
初心者じゃないなら買わない

2024/08/27(火) 11:10:30.26

初版を買ってから何をしてたんだろ？
買って満足するタイプなら、最新版を買っても読まないだろうから無駄じゃね？

2024/08/27(火) 16:11:14.11

だいたい分かったら、あとはVisualStudioが教えてくれるだろ

**あぼーん** · NG

あぼーん

2024/08/28(水) 00:02:03.42

図書館にあるかもしれなから図書館のサイト開いて検索してみ

2024/08/28(水) 12:58:34.11

>>584
古い版はブックオフへ売却

2024/09/02(月) 10:17:07.82

MinifyされたJavaScriptのコードをChatGPTで読みやすい形式に戻すことに成功
https://gigazine.net...eering-with-chatgpt/

2024/09/02(月) 10:36:23.94

C#関係ねーだろカス
URLまともに貼ることもできねーのかよカス

2024/09/02(月) 12:39:20.92

関係ない単発スレ立てるようなやつだからな

2024/09/11(水) 15:27:18.98

>>584
C# Dev Kit がゴミすぎてヤバイから古い構文だけ使っとけ
https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csdevkit&ssr=false#review-details

2024/09/17(火) 22:53:51.66

クラス.Hoge
{
getter;
}=new クラス.Fuga

でプロパティの初期化でインスタンス生成して、以降はクラス.Hogeでゲットすることでシングルインスタンスを実現しているコードがあるんですが、シングルトンのほうが良くないですか？

2024/09/17(火) 23:24:30.21

何語だ？

2024/09/18(水) 09:46:11.92

他でnewできないように作ってあるならどっちでも良いんじゃ？

2024/09/18(水) 19:15:35.43

>>601
シングルトンにするとどういうメリットがあるの

2024/09/18(水) 20:03:41.44

シングルトンって実装概念だから、コードがどうなってようが、スマホただ一つのオブジェクトしか持たないならシングルトンだろ？

2024/09/18(水) 20:04:03.56

スマホ？

2024/09/18(水) 22:04:49.90

スマホ

警備員[Lv.30] (ﾜｯﾁｮｲ 17fe-/N6j) · 2024/09/18(水) 22:11:32.12

スマガツオ？

2024/09/19(木) 08:40:19.54

カツオじゃないけどスマガツオ

2024/09/28(土) 16:51:21.59

これでもおｋなの？

class Hage
{
private static Hage dura= new Hage();

public static Hage Dura => dura == null ? new Dura() : dura;

private Hage(){}
}

2024/09/28(土) 17:41:57.57

コンパイラー通してみればよくね

2024/09/28(土) 20:07:55.61

＞　 dura == null ? new Dura() : dura;
これを見ると3つぐらい気になってしまう

2024/09/28(土) 23:23:29.39

ここ読むといいよ
https://csharpindepth.com/Articles/Singleton#lazy

2024/09/29(日) 06:43:56.42

>>610
そもそも端からreadonlyなduraに代入してるならnullチェックいらなくなるし
そうでなく遅延生成するならdura == null ? (dura = new Dura()) : dura;ってしないとduraは一生nullのままになってしまう
ちなみに最近のC#バージョンなら「public static Hage Dura => dura ??= new Dura();」と簡潔に書ける

2024/09/29(日) 06:51:19.62

それならそもそも「public static Hage Dura { get; } = new Dura();」だけでよくね？

2024/09/29(日) 10:26:30.13

>「public static Hage Dura => dura ??= new Dura();」
これはthread-safeではない

>「public static Hage Dura { get; } = new Dura();」
これはthread-safe
他のstaticメンバーにアクセスされてもインスタンス生成されるけどだいたいこれで十分
もっとインスタンス生成を遅延させたければLazy<T>

2024/09/29(日) 10:30:57.16

　　　　　　　　　　　|
　　　　　　　　　　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)また髪の話してる
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

2024/10/08(火) 20:28:55.31

WPFって例えばComboBoxの色を変更するにしてもテンプレート再定義しなきゃいけないの？
ToggleButton配下のBorderのBackgroundを変更すれば良いだけなのに、そこ変えるためだけに全て再定義し直す他ない？

2024/10/09(水) 17:45:54.17

そうだよ
CSSなら楽勝なのに、アホらしいよね

2024/10/09(水) 21:06:07.63

WPFはアイテム毎に出来る事が違うから糞、下手するとプロパティ名まで違う

2024/10/09(水) 23:24:57.23

stringになんか不明な文字列が入っているんですが、
EncodingのGetBytesしないでそのままbyte配列にする方法教えてください

2024/10/09(水) 23:27:11.58

WPFってそんな糞なのかよ
ゲーミングComboBoxを作りたくなったらどうすんだよ

2024/10/10(木) 01:11:16.37

っぱwinformsよ
Datagridviewはなんだかんだ便利

2024/10/10(木) 02:27:50.91

>>621
unsafeでstringのポインタ取れるよ

2024/10/10(木) 08:43:23.64

unsafeしたくなければ1文字ずつループしながら自前で変換

2024/10/10(木) 12:01:53.19

MemoryMarshal.Cast<char,byte>()がunsafe不要かつ効率良い
返値はReadOnlySpanだけど問題ないかと
どうしてもbyte[]が必要ならToArray()

2024/10/10(木) 13:36:13.58

stringを.AsSpan()してReadOnlySpan<char>で受けて
1要素ずつcharの値を確認しました
ありがとうございました

2024/10/10(木) 13:38:50.81

Encodingに「エンコード無し」があってもよさようなもんですけどね

2024/10/10(木) 14:42:09.62

Encoding=Binary

2024/10/10(木) 15:13:38.10

>>628
Encoding.Default

2024/10/10(木) 15:16:01.18

あ、でもCoreだとUTF8かあれ

2024/10/11(金) 06:54:42.62

FrameworkではいわゆるANSIだから結局望まれてるものではないと思うな
Encoding.BigEndianUnicodeが一番近いと思うけどこれも無効なサロゲートペアとかあるとU+FFFDに置き換えちゃう

というか今回の用途ならString.Join("-", text.Select(c => ((int)c).ToString("X4")))程度で十分じゃないかな

2024/10/11(金) 19:44:10.29

スレチなのかもしれないですけど、お借りします
データベースに接続する際に接続クラスを作るかと思うのですが、問い合わせをする場合、その接続クラスの中でクエリ生成して結果を返すほうがいいのか、接続クラス外でクエリ生成して接続クラスに投げる方がいいのか、どちらが一般的な考えでしょうか？
前者だと、クエリごとにメソッドが増えていって膨大になりそうな感じがし、後者の方が汎用に使えそうな気もしてます
どっちのほうがいいでしょうか？

2024/10/11(金) 21:08:01.94

一般的を聞きたいのか
どちらがいいかを聞きたいののか？

そもそもいいかとは？

2024/10/11(金) 21:29:38.58

汎用は不正アクセスの入り口になりやすいよな

2024/10/11(金) 22:01:16.41

よくある話だね

リポジトリパターンで実装するときに迷うけど
汎用的で単純なのはリポジトリにメソッドを用意しておく

条件などの複雑なクエリはクエリ実行用のメソッドを作っておくのがバランスが良いと思う
複雑なクエリは値を読むだけで更新は別にしておいた方がいい