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/10/11(金) 09:50:54.30

フォントとか配置とかやり直しはMacOSのあるあるだと思ってた

2024/10/21(月) 02:25:35.38

ライブラリを使用するために下みたいなコード書いた
ライブラリ内でIHoge.Method();の機能を上書きしたいのとHogeで設定されるさまざまな機能を使いたいがためにIHogeを実装したHogeクラスを継承してMethod();を隠蔽、そのうえでライブラリから呼び出されるようにIHogeをさらに継承？実装させてる

ちょっと無理矢理感強いけどこれはアリですか？

ライブラリの中
～
IHOGE.Method();
～

public interface IHoge
{
public void Method();
}
public class Hoge : IHoge
{
public void Method()
{
元の処理
}
}

自前で作ったクラス
public class NewHage : Hoge,IHoge
{
public new void Method()
{
上書き処理←やりたいこと
}
}

2024/10/21(月) 02:45:34.93

>>121
亀レスだけどすごいのあったぞ
中身見てないけど多分お前が望んでるやつだと思う
https://sumiox.com/cs-windowsorm-mynote/

2024/10/21(月) 08:25:43.38

>>158
Hoge.Methodにvirtual
NewHage.Methodでoverride

2024/10/21(月) 12:38:44.14

>>158
それがやりたいことなら別にいいんじゃね？

Hogeの他のメソッドがMethod()を呼ぶとか
Method()がHogeの他のメソッドを呼ぶとかの関係が出てくると
newを使わない場合に比べるとバグるリスクが高くなるような気はする

インターフェース+コンポジションにしておけばバグるリスクは低くなる
その代わりに多少書く手間がかかる

2024/10/21(月) 12:53:33.54

>>160
Hogeはライブラリの中の実装だからvirtualにできないのつらみ
>>161
なるほどありがとう

2024/10/22(火) 12:35:56.21

newで上書きしたことないな

2024/10/22(火) 19:02:31.64

>>163
なんかchatGPTが教えてくれた

2024/10/22(火) 19:03:43.61

てかVisualStudioが教えてくれた
緑波線でnewしてくださいって
public new 戻り値の型メソッド名

2024/10/23(水) 20:43:06.26

ML.NETを試してみたら思いの外お手軽で面白いな
アプリにさくっと組み込めそうだ

2024/10/23(水) 21:09:39.51

>>166
薄い本があるので入手お勧め

2024/10/24(木) 06:52:54.39

.NET MAUIで試したことあるけどWindowsはいけたがAndroidではトレーニングでエラーはいた記憶

2024/10/27(日) 08:19:05.51

>>159
サンクスです、これはすごいな
解説がおおくてわかりやすい
これのソースコードがダウンロードできたらよかったのに

2024/11/01(金) 19:03:45.14

CookieってSystem.Text.Jsonでシリアライズ・デシリアラズするとDomainKey変わっちゃってSet-Cookieで同じ名前のクッキー来ても違う奴判定されてダブるんだな
正確に言うと先頭ドット有りだと変わらないのと、BinaryFormatterやNewtonsoft.Jsonで非パブリックフィールド含む全フィールドをそっくりそのままストア・ロードさせれば変わらないんだけど

2024/11/14(木) 09:50:27.66

ZipPlaってファイル管理ソフトのソース持ってる人いる？
居たらアップして欲しい

2024/11/14(木) 10:20:27.81

>>171
ぐぐったらGitHubにForkされたのがあるようだぞ
オリジナルからどの程度手が入ってるか知らんけど

2024/11/16(土) 02:07:13.59

>>172
自分もそれは見つけたんだけど、何を変えてるのかもハッキリしないんですよね
なのでオリジナル持ってる人が居たらと思いまして

2024/12/07(土) 11:39:26.82

WinFormsってWindowのクラスネーム決められないの？
Win32のFindWindowのClassNameで探させたいのだけど

2024/12/07(土) 17:24:39.89

protectedなCreateParamsプロパティをオーバーライドしてClassNameを書き換えることはできる
独自名ならとりあえずRegisterClassは必要だけどそれだけで済むかどうかは知らん

2024/12/08(日) 10:13:10.77

C#側のプロパティは書き換えられても実際の内部の値はそういうことしないと無理そうか

2024/12/08(日) 11:19:30.20

RegisterClassExしてやろうとしたことあるけど
CreateParamsでRegisterしたClassName指定してもエラーになって
それで良く分からんまま放棄したな昔

2024/12/08(日) 11:24:39.87

流行りのAIはその辺何か教えてくれんのか？

2024/12/08(日) 11:42:31.33

はい

2024/12/08(日) 12:16:51.06

人間が垂れ流した知識を混ぜるだけのAIが、人間が知らないことを教えられるわけないだろｗ

2024/12/08(日) 12:37:03.03

世界中のどこかで語られたかもしれない事実をそこらの人間がすべて知ってると思うのがおかしい気がする

2024/12/08(日) 17:47:34.90

つーかさWin32APIのCreateWindowで作ったウィンドウをC#にAttachする程度基本的な仕組みぐらいあるやろ
あるやろ…

2024/12/08(日) 21:09:31.34

CSharp初心者が学習始めるなら何からがおすすめ？
多分IIS?使ったウェブアプリになるんだけども
Javaでのアプリ開発経験はあり

2024/12/08(日) 21:38:41.73

Paint.netのソースを見たまえ

2024/12/08(日) 21:46:52.70

これかな、ありがとちょっと見てみるわ
h
ttps://github.com/paintdotnet

2024/12/09(月) 11:14:47.99

SetWindowLong
SetWindowLongEx

2024/12/09(月) 11:15:02.52

GWL_EX_STYLE

2024/12/09(月) 13:22:41.09

科学＋ 5ch

【AI】AIはわずか2時間の対話で人間の性格をコピーできる [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1733576027/

コメントに面白いことが書かれている

**185** (ﾜｯﾁｮｲ 5f62-oAsD) · 2024/12/09(月) 17:56:14.64

PaintDotNetをインストールした

2024/12/11(水) 06:17:57.42

varなんて使うな戦争ってもう終結したの？

2024/12/11(水) 07:27:33.98

言語によりけりだから

2024/12/11(水) 08:36:42.20

盲目的にvar使うなとは思うけど、一切使うなはないなぁ

2024/12/11(水) 08:50:12.41

まあマイクロソフトのサンプルにも使ってる例あるしな

2024/12/11(水) 10:05:12.70

jsのvarと違ってただの便利機能だしな

2024/12/11(水) 12:36:15.23

varで参照型を扱うとnullableになるのはどうにかしてほしい

2024/12/11(水) 13:56:36.44

推論型なんだし、必要に応じて使えばいいんじゃね？
objectならともかく

2024/12/11(水) 14:39:24.72

varが絶対必要なのって匿名型使うときだけだから、必要に応じて使う、だとvarはほとんど用無しになっちゃう
戦争に参加するつもりはないが仮にvar使うんなら必要に応じてじゃなく基本varにしないと

2024/12/11(水) 14:54:27.03

c#は基本varでいいよね
多分大体のc#er？はvarじゃないときにだけ理由を気にするんじゃないかな

2024/12/11(水) 18:36:49.06

初期に頭のいい人は一番先に varに飛び移った
その後みんな気が付いて移行した
今でも使わないのはご老人

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書いて飯食ってるタイプのエンジニアでは最新に拘る人はそもそも少ないだろうね