C#, C♯, C＃相談室 Part98

2024/06/29(土) 19:18:41.95

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

■Visual Studio 2022 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part97
https://mevius.5ch.net/test/read.cgi/tech/1671585518/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

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

2024/12/11(水) 19:15:48.68

varばかりやわ

2024/12/11(水) 20:38:24.59

VBのVariant最強

2024/12/11(水) 20:41:39.44

それはないかなw

2024/12/11(水) 23:21:13.31

インターフェース分離の原則が分からない
「必要のない振る舞いを実装しない」のは適切だと思うんだけど、ポリモーフィズムとの組み合わせが悪いように思う

interface IBird { string Name { get; } }
interface IFlyable { void Fly(); }

// ペンギンは飛べないので IFlyableを実装しない
class Pengin : IBird { ... }
class Eagle : IBird, IFlyable { ... }

のようにした場合に、プログラムが List<IBird> birds のような形でデータを持つと、「飛べる鳥がいる」という情報が型から消える

foreach (IBird bird in birds) {
　Console.write(bird.Name);
　if (bird is IFlyable flyable) {
　　flyable.Fly();
　}
}

「飛べる鳥なら飛ばす」ようにしたい場合、インターフェースを分離する場合だと上記のように is でキャストするしか無さそう？
IBirdで扱っているのに「インスタンスは IFlyable である可能性がある」という情報に依存してるのに少し違和感があって、より綺麗な解決策があれば知りたい

2024/12/12(木) 00:16:45.29

c#スレですよ

2024/12/12(木) 08:54:59.88

そこを別々のインターフェースとして分離するのが間違ってるだでは
飛べる飛べないも”鳥”の一要素でしょ

2024/12/12(木) 08:59:12.98

プロパティで持てば解決

2024/12/12(木) 09:20:56.04

>>206
Nullableな IFrayable? をプロパティとして持たせて、飛ぶ鳥の場合はthisを返すようにするということ？

2024/12/12(木) 09:43:51.10

そこだけのインターフェース化に拘るなって言ってんだよ

2024/12/12(木) 10:34:43.14

鳥とペンギンだと近すぎて例えとして微妙だった
例えば「動物のリスト」のようなデータを持ち、動物には鳥のように飛べるクラス (Flyメソッドを持つ) と、トラやライオンのように走るクラス (Runメソッドを持つ) があるといった場合

動物の一覧を持つには List<IAnimal> のような型を使うと思うけど、これは合ってるよね？
その上で動物によって違うアクションを行わせたいとする

IAnimal側に CanFly のようなメソッドを追加していくと、例えばサルのように「道具を使う動物」が後から追加された場合、IAnimalにメソッド追加が必要になり、それはBirdなどの各クラスにも影響する
Birdクラスは「道具を使う」なんてことは知らないのに、インターフェースのために CanUseTool のようなメソッドを後から追加するのは違う気がする

そうするとやっぱインターフェース分離の形になりそうで、そうなると利用側で is でキャストするのが落としどころなのかと

2024/12/12(木) 13:06:06.44

鳥以外にも飛ぶ（正確には滑空だが滞空することに変わりはない）動物は居るし
鳥だって地面をRunするヤツは居る
鳥にも、猿程でなくてもその辺に落ちてる物を道具的に使うヤツも居る

お前の例題がそもそもめちゃくちゃなんだよ

2024/12/12(木) 13:06:59.82

あといい加減余所でやれ
C#直接関係ない

2024/12/12(木) 17:51:32.06

ここの住人はC#を使っていてSOLID原則に悩まされたことなど無いのだろうか

2024/12/12(木) 18:08:37.64

>>203
ある動物が飛べることと、鳥であることは独立なんだから、
「飛べる鳥がいる」という情報はなくても仕方なくない？
統計的な相関関係はあるかもしれないが、包含関係でないなら仕方ない。
飛べる他の動物を無視するのなら、IBirdを継承したインタフェースでIFlyableBirdを作ればいいのでは？

2024/12/12(木) 18:40:52.28

ISP自体はC#でよく出てくる問題じゃないの？
これなんかまさにそう
https://dev.to/fabriziobagala/interface-segregation-principle-452m

だけどこういった解説はISP単体の説明になっていて、泳ぐ、走るといった能力の異なるものを Animal として抽象化する方法を教えてくれない
綺麗な方法でなくても「C#ではこうすることが多い」のようなプラクティスがあれば知りたかったんだけど、そういうのは無さそうなんですかね

2024/12/12(木) 19:18:32.74

実装を伴わない抽象化の話ってなんの身にもならないからやめなさい
それとインターネットサービスプロバイダの話は他所でやってくれ

2024/12/12(木) 19:18:50.89

求めてそうなプラクティスは見た事ないなぁ
個人的には、飛ぶにしても走るにしても動物という存在の態様のひとつだから
動物IFのプロパティに含めるでいいんじゃないかと思うけどね

2024/12/12(木) 19:36:28.62

var unko = new Unko()

より

Unko unko = new()

の方が良くね？

2024/12/12(木) 19:46:48.91

もっと地球規模の視野で考えろよ
うんこも地球の一部だろ？つまりうんこは地球とも言える
わかるか？

2024/12/12(木) 19:55:04.36

>>217
まぁ、後者ができるようになったの後になってからだから

2024/12/12(木) 22:38:48.07

>>214
それISP単体の説明にもなってない
class Penguin : IAnimalにNotImplementedExceptionでFly()を実装すれば即ISP違反だというのは間違い
まずは原典にあたってISPを理解してきたほうがいい
謳われてる原則をどう活用するかはその後

2024/12/12(木) 22:49:28.08

そもそも
そんな鳥のプログラムなんか一般的じゃねーし

2024/12/12(木) 22:59:54.30

>>220
「クライアントが『泳ぐ、飛ぶ、もしくは走る動物』として使うことを想定するのなら、そのインターフェースであるIAnimalにその情報を含めるのは適切」ということですかね
class Penguin としては Fly や Run などのメソッドの実装はノイズに思えるけど、IAnimalとして使われるなら、その契約に従えという感じかな
(それだと後から「道具を使う」がIAnimalに追加された際に Penguine もメソッド追加が必要で、そこがモヤモヤしてる)

こういう場合にアダプタ (ラッパー？) を使うのって適切？
純粋に Penguine としての機能を提供するクラスと、それを IAnimal として使うためのアダプタみたいなの
それだと更に複雑さを増すだけ？

OOP難しい……

2024/12/12(木) 23:02:07.06

適切とか
とりあえず作ればよくね？

適切かどうかなんてエグゼにしたら関係なくね？

それとも論点だけ考えて実際のプログラム作らないの？

それ何したいの

2024/12/12(木) 23:31:52.39

例が不適切だから混乱してるだけにしか見えないなぁ

2024/12/12(木) 23:50:28.74

SOLIDが現実のコードで使われなかったり、「オブジェクト指向は問題を複雑にするだけ」みたいなことを言われる原因

2024/12/13(金) 01:16:53.76

>>203
インターフェース分離の原則は「クラスが必要としないメソッドを実装しない」ってだけ
ペンギンのような飛べない鳥が IFlyable を実装しないのは正しい
あとは「飛べる鳥」をインターフェースで分かるようにしてやればいい
isを使う羽目になったのは飛べるかどうかわからない IBirdをListにしてるから
---
interface IBird { string Name { get; } }
interface IFlyable : IBird { void Fly(); }
// ペンギンは飛べない
class Penguin : IBird {
public string Name => "Penguin";
}
// ワシは飛べる
class Eagle : IFlyable {
public string Name => "Eagle";
public void Fly() => Console.WriteLine($"{Name} is flying!");
}
// 飛べる鳥だけを扱うリストを作る
List<IFlyable> flyableBirds = new List<IFlyable> { new Eagle() };
foreach (var bird in flyableBirds) {
bird.Fly(); // 明示的に飛べる鳥しか扱わない
}

2024/12/13(金) 01:54:21.75

こいつら病気なんか

2024/12/13(金) 01:55:37.37

だね

2024/12/13(金) 06:18:42.75

SOLIDにしても所詮理想論であって現場に即してるわけじゃないしなぁ

2024/12/13(金) 07:39:08.04

せやな

2024/12/13(金) 17:30:15.58

サイコパスの脳の違いを発見。一般の人に比べ線条体が大きいことが判明
karapaia.com/archives/52313287.html

2024/12/13(金) 20:28:57.37

関数型がいいんだね！

2024/12/14(土) 09:23:37.03

後から増えた「道具を使う」には何かいい感じにデフォルト実装つけとけば既存のクラスには影響しないんじゃない

2024/12/14(土) 12:26:32.43

それを派生というのでは？

2024/12/14(土) 12:52:03.62

C# 8 からはインターフェースのデフォルト実装が使える

2024/12/14(土) 14:27:07.29

Win10や11のOS付属のpowershell5.1でインラインで書けるC#ってバージョンちょっと古くね
できれば新しいRoslynのC#をpowershellから使いたいのだが
なんか昔の記事しか見つからん

2024/12/14(土) 15:05:36.28

どうせ別に入れる必要があるならPowerShell 7入れれば良くね

2024/12/14(土) 16:09:38.02

>>236
起動時に出て来るメッセージすら読めないのか

2024/12/15(日) 03:52:31.32

>>238
お前はこれでも読んどけ
https://learn.microsoft.com/ja-jp/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.4
Roslyn単体で使うだけならビルドツール拾ってくるだけだが
Powershell上げるとなると仕様も大幅に変わってたりして無理だし俺が出した要件の解にもなってない

2024/12/15(日) 04:43:36.26

>>239
馬鹿が必死に調べただけの浅い知識で言い訳してる

2024/12/15(日) 09:22:53.93

今のところ互換性の為に残してあるんだろう
それを変えちゃうと問題が起こる可能性があるしMS側のメンテがめんどうなので
変えたい人は7とセットで入れろということなんだろう

2024/12/15(日) 13:32:12.27

>>239
バカの相手はしなくていいわ
その情報はありがたいが

2024/12/16(月) 00:02:44.03

PowerShellは完全に袋小路だからもう諦めた方がいい
6以降は事実上Azure専用

2024/12/16(月) 03:32:32.19

>>242
うわっ
自分の言い訳コメントに自作自演で恥ずかしい馬鹿発見

2024/12/16(月) 04:36:14.08

なんで作っては捨ててくスタイルなんかなMicrosoftは

2024/12/16(月) 06:57:26.47

作ってないやろ
買収してるだけ

2024/12/16(月) 08:17:45.85

PSはMSが作ってるが

2024/12/16(月) 09:42:40.38

Windowsに標準搭載されてる.NET Frameworkと今の.NETの時点で互換性ないのに
なんで.NETアプリであるPowerShellが叩かれるのか

2024/12/16(月) 12:31:10.08

標準搭載されてるPowerShellは.NETアプリじゃなくて.NET Frameworkアプリだからね

2024/12/16(月) 13:18:44.44

>>245
MSの社内政治に敗れたチームのプロダクトはそうなりがち
社内政治うまくやってると微妙なやつも長生きする

2024/12/16(月) 13:27:42.05

frameworkってなんでまだ存在するの？

2024/12/16(月) 15:54:22.92

.NETがFrameworkと互換性無くて捨てられないから

2024/12/16(月) 19:05:15.35

互換性ないってことは、.NETとframeworkの2つのアプリを動かしたら、GCもそれぞれで動き始めるの？

2024/12/16(月) 21:44:01.92

>>253
GCはアプリ(プロセス)毎じゃないの

2024/12/19(木) 20:41:55.41

PowerShellはWindowsにシステムワイドにインストールされた .NET Framework が存在するという前提で成立していたのに、
.NETでは.NET自体をアプリにバンドルするか、必要に応じて特定のバージョンを追加で入れるかになって完全に破綻しちゃったんだよね
一般的な.NETアプリならバンドルは可搬性が向上するから好ましいことだけど、
PowerShellの場合はシステムワイドにインストールされたいろんなモジュールと連携しなきゃいけないから.NETバンドルはありえない
完全に詰んでる

2024/12/20(金) 08:54:32.70

だからPowerShell Coreは標準装備じゃなくて追加装備

2024/12/20(金) 10:14:37.03

Windowsにそもそも入ってないなら追加インストールでいいんだけどね。問題は5が入っていること。
それによって「なぜ元々入っているのにわざわざ追加するのか」という当然の疑問を解消するコストが生じる。
開発者の好みだけでサポート期間も互換性も劣るゲテモノをゴリ押しするのは極めて困難だし、
そもそもPS書いて飯食ってるタイプのエンジニアでは最新に拘る人はそもそも少ないだろうね

2024/12/20(金) 13:01:10.12

はいそろそろC＃の話題でよろ

2024/12/20(金) 15:29:33.49

JAIST、「並行量子通信プロトコル」の完全な自動形式検証を実現
http://news.mynavi.jp/techplus/article/20241220-3090485/

2024/12/20(金) 17:50:29.82

>>258
なんかある？

2024/12/20(金) 20:02:54.65

またペンギンやら飛べない鳥だとかの話がしたいのかい？
それともPowshellの付属物の話がしたいのかい？
どっちなんだい？

2024/12/21(土) 10:56:38.14

>>257
>それによって「なぜ元々入っているのにわざわざ追加するのか」という当然の疑問を解消するコストが生じる。
>開発者の好みだけでサポート期間も互換性も劣るゲテモノをゴリ押しするのは極めて困難だし、

ほんそれ
5が全部入りにしておくのが正解だっただろうな

2024/12/21(土) 11:18:40.67

PS for sysetmみたいなのを最小セットで入れておけば良かった

2024/12/21(土) 11:42:21.51

終わらないPS談義

2024/12/21(土) 17:53:08.76

>>264
お前がC＃の話題振ってくれりゃ乗るよ
早くしろよ

2024/12/21(土) 18:15:03.35

いや知らんがｗ
俺がC#の話題にしろ言うたわけじゃないしｗ

2024/12/21(土) 21:57:55.88

今関わってるプロジェクトがスペース2つでインデントしててちょっと面食らってしまったんだけどこれ珍しくないもの？
今まで携わってきた中で一件も遭遇したことなかった

2024/12/21(土) 22:11:41.26

過去に深いネストを大量生産する人がエラくなっちゃって、そういうルールになってしまったんじゃないかと妄想しちゃうなｗ

2024/12/21(土) 23:25:41.77

今時スペース2個は珍しいな、C#とかではあんまりない気がする
昔々はどの言語でもタブを使っていいかとか、スペースで代用するなら2個か4個かで論争があったらしい
JSは2個が主流だった気がするけど今はどうだろ

2024/12/21(土) 23:39:03.76

jsonは2だったり4だったりまちまちだけどね

2024/12/22(日) 00:09:01.63

タブのが合理的
Goみたいな標準フォーマッタがあるのが理想だけどC#はそう言う文化はないね

2024/12/22(日) 02:26:26.71

俺はスペース2個のが視線移動減って楽だと感じてるからかなり昔から2個派だよ
>>268みたいな日本人特有の右倣えのお仕着せルールに甘んず昔から超効率化してるやつらは世の中に沢山いるんだよ
勉強になったな

2024/12/22(日) 03:54:49.07

TABに統一してるけど
表示上は半角スペース2から4個で用途で変えてる

2024/12/22(日) 05:02:43.67

{}は
if(){
}
の方が好き
普通は
if()
{
}
これ？

2024/12/22(日) 05:44:22.67

逆、最初の頃は上が大多数
ブログやら初心者講座やらで下の書き方が主流担ってきてる感じ

2024/12/22(日) 06:21:31.74

スペース2個インデントって言うと、XMLやHTMLを思い浮かべるな

2024/12/22(日) 07:48:19.66

>>275
違うぞ
上のはJavaやJavaScript界隈でのデファクト

下はMicrosoft系のC#とかのデファクト

公式が出してるコーディング規約がそうなってるだけ

2024/12/22(日) 07:50:46.11

>>276
例えばC#というかasp.net系だとrazor構文でhtmlと一緒にC#のコード埋め込む
そうするとインデントは2の方が見やすい

2024/12/22(日) 07:53:26.28

>>271
C#はチェーンメソッドのドットを縦に綺麗に並べる文化が有るんでタブだと都合が悪い
2でも4でも良いけどスペースがデファクト

2024/12/22(日) 08:13:40.94

>>277
いやだから
C＃が出る前というか出始めの頃で
Cプラプラ使い達が多かった時さ

2024/12/22(日) 08:20:56.74

当時、というか関数書くときって
hoge()｛
…｝

て書くのが一般的やったん

んでDelphiが出てきたらこの｛｝をBegin…Endで囲むから
hoge()
Begin
…
End

ここらへんはVBやVBAとかにも反映されて
その後C＃で出した際にって感じかな

2024/12/22(日) 09:15:42.08

>>279
タブをインデントで使ってスペースをアライメントで使えば理論上ズレないよ
Goのフォーマッタはこれに従ってるからタブ幅は任意に設定できる

prettierみたいな途中で強制的に折り返すフォーマッタとは相性が悪いけど

2024/12/22(日) 09:22:40.24

Indent with tabs, align with spaces

https://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces

これね
これが理想だけどエンジニアのレベルが高くないとこのルールを守るのは難しいからスペースにしてるのが大半
ただしGoは強制フォーマッタでこれを解決してる

個人プロジェクトなら最初から好きなタブ幅にすればいいからタブにするメリットもあまりないし
気分でタブ幅変えれるのは結構メリットあるけどね

2024/12/22(日) 09:27:48.67

俺はずっと>>274の前者でインデントはタブだなぁ
なおタブの幅はスペース4個分

2024/12/22(日) 11:59:15.10

「自転車置き場の屋根の色」現象発生中

2024/12/22(日) 13:03:56.05

この手の話は職場のルールで決まるから個人がどうこうは関係ないよな
ただ自分のツールなんかは好きにしろだが
カッコ、演算子、型と変数の宣言の間の空白などもめる話題はいくらでもある

2024/12/22(日) 16:36:51.22

>>285
「原子力発電所の建設」について議論したいなら付き合うよ、それで議題は？

2024/12/22(日) 17:09:33.96

まあreshaperでテーム共有設定使うだけだしな

2024/12/22(日) 19:48:07.14

>>287
では失礼して
Unity製ゲームのMOD開発なんかでリフレクション使いまくるのもなんかスマートじゃないから、
aelij氏のIgnoresAccessChecksToGeneratorを魔改造させてもらってフィールド含めて全パブリック&readonly解除でゲームのコードに全アクセス出来るようになってめっちゃ捗るようになったのだけど、
欲が出て標準ライブラリにも手を出したくなってやってみたらmscorlibなんかはReferenceAssemblyだからプライベートフィールドはそもそもdll内に含まれてないから書き換えられないんだよね。
ランタイム時の実体dllを決め打って渡せばstring.m_firstCharとかList<T>._sizeとかも全てアクセスできるようにはなるんだけど決め打ち渡しもスマートじゃないからどうにか自動で解決をしたい。
ILSpyやmono.cecilにはランタイム時の実体dllを特定するコードあるんだけどbuildアクションから同じ事するのって可能だろうか？

2024/12/22(日) 19:55:36.15

はい

2024/12/22(日) 20:10:00.61

へー
なんだかもうゲームよりMOD開発、MOD開発より開発環境開発の方が長くなっちゃってますわ

2024/12/22(日) 20:35:36.44

だって、ここ
別にゲーム開発やないし

プログラムやで

2024/12/22(日) 20:50:51.80

いまだにmonoで簡単にいじられまくりゲームあるのか

2024/12/23(月) 00:10:04.98

>>289
日本語がややこしいけど
①標準ライブラリのPrivate含む全フィールドにリフレクションを使わずにアクセスして書き換えたりしたい
んで、
②実体DLLを決め打ちで渡せばアクセスできるってところまでできてる
あとは
③実体DLL取得を自動化したい
④なおかつビルドプロセスに組み込みたい
ってことか
MOD開発とか知らんけど面白そうじゃん

2024/12/23(月) 00:36:21.82

いまいち細かい要件がよくわからんけどAppDomain.CurrentDomain.GetAssemblies()で現在ロードされているすべてのアセンブリが取得できるらしいが、これ試した？
駄目だったならどういうところがダメだったのか教えてくれ

2024/12/23(月) 17:33:16.62

>>295
要するにIgnoresAccessChecksToGeneratorの話でMSBuild内のコードとして動くものだからそれやってもMSBuildがロードしてるものが返されるだけとなる
ILSpyなんかもtypeof(object)などから解決してるので上記の理屈でそのまま移植はできない

2024/12/23(月) 17:42:25.10

>>293
マルチメインじゃなくmodフレンドリーなゲームならil2cpp化せずそのまま出してるゲームも普通に多いよ
改変やチート防止のためなら難読化含めてやったところでそこまで難易度上がらないからそれ目的ならRustみたいにカーネルドライバ付けるしかない

2024/12/24(火) 18:58:01.04

個人開発の局所的な用途のマイナーツールの話が原発の建設並の重大事なのか
ちょっと難しすぎてわかんねえな

2024/12/24(火) 19:41:54.52

原発ってただの湯沸かし器じゃん
燃料がちょっとヤバイってだけで高尚なC#のプログラムと比較すんなよ

2024/12/25(水) 08:00:53.24

C#だってただの道具
しかもC#だけじゃお湯も沸かせない
高尚とかちゃんちゃらおかしい