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

2021/03/23(火) 12:58:24.10

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part149
http://mevius.5ch.net/test/read.cgi/tech/1608085775/
■関連スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・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
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

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

2021/05/02(日) 13:26:41.16

インターフェースって継承以外でインスタンス化してフィールドに持たせるように使う場合があるけど、それって違う場所に定義している関数を呼び出して使うような感じ？
いまいちインターフェースの使い方がわからぬ

2021/05/02(日) 13:41:54.97

「コントロールがきかない、再コンパイル依頼が効かない」第三者にバイナリのdllを公開してかつ、3年5年と更新しつづけていけばいやでもわかる。

2021/05/02(日) 13:48:58.41

オブジェクト指向の言語やってて、デザインパターンの勉強しない奴とか居るんだな。

2021/05/02(日) 13:51:59.04

それぐらいなら別にinterface要らんけどな
自社DLLの指し替えOKならメソッドの中身変えるのはできる
TypeScriptのinterfaceぐらいになったら便利だけどC#やJavaのinterfaceはそこまで重要じゃない

2021/05/02(日) 14:46:34.33

>>638
実装を入れ替え可能にするために使う
インターフェースを使う側はインターフェースがどう実装されてるかを気にしない
関心事の分離や責務の分割というやつ

public class CustomerService
{
private readonly ICustomerRepository customerRepository;

public CustomerService(ICustomerRepository customerRepository)
{
this.customerRepository = customerRepository;
}
}

CustomerServiceはcustomerRepositoryがどういう永続化技術を使ってるか関知しない
RDBMSを使った実装からKVSを使った実装に変更したとしてもCustomerServiceクラスは変更する必要がない
単一責任の原則や依存性逆転の原則というオブジェクト指向設計の基本原則に従ってる

2021/05/02(日) 14:53:27.70

>>638
全然違うものを透過的に扱いたい場合ってあるでしょ？
例えばビデオゲームで入力デバイスとしてゲームコントローラーだけでなく、
キーボードやタッチパネルも使えるようにしたいとか。

とりあえずはInterfaceはそういう要求を満たすためのものだと
理解しておけばいいよ。それ「だけ」ではないけどね

2021/05/02(日) 15:09:58.26

汎用性を高めるためって考えた方が分かりやすいかもね。

昔テレビデオってあったけど、世の中にHDMIみたいなインターフェイスが存在せずに
ああいうモノリシック構造の機械しか存在しなかったらどんだけ不便か考えれば
インターフェイスの意味なんてイチコロだと思うけどな

2021/05/02(日) 16:17:56.85

最近はそういうのは関数を渡すんでよくなってる

2021/05/02(日) 17:53:29.91

関数を渡すとしても、引数なり戻り値なりの型を定義しないとならんしな。
実装を含まない定義を切り出しておかないと、容易に循環参照になってクリーンビルド出来なくなるぞ。

2021/05/02(日) 18:03:29.16

>>645
デリゲートで済む用途に（無理に）インターフェイスを流用しなくて済むようになっただけ。

2021/05/02(日) 18:14:35.65

インターフェイスつかってるとVisualStudioで定義に飛んでもメソッドの実装見れないから腹立つんでやめてください。

2021/05/02(日) 18:16:04.86

>>648
逆に、実装を見るなという意思表示では？

2021/05/02(日) 18:24:40.27

>>649
見られたくない恥ずかしい実装してるってことですねわかりました

2021/05/02(日) 18:25:03.65

class X: IX {
private IY y;
public X(IY yy) {y=yy;}
public T foo(U u) { ... }

↑こんなの冗長で面倒くさいだけじゃん
↓これでいいんだよ

static class X {
public static T foo(Func<...> y , U u) { ... }

C#最大の欠点はTSなどと違ってトップレベル関数を定義できないことだな
まあそのうち導入されるだろうけど

>>647
まあそうだね
そしてデリケートで済まない用途なんてのは、ないんだなこれが

2021/05/02(日) 18:48:49.12

OKでは

(1) IEnumerableと機能的に等価なものを実装してみせてほしい

(2) IComparable<T>はComparison<T>で置換できるが、
　　(a) ジェネリックでIComparableで制約をかけるのと同じことはどうやって実現するのか？
　　(b) 毎回いちいちComparisonを指定しなきゃならん煩雑さはどうしてくれる？

2021/05/02(日) 19:00:20.53

>>651
Funcの型と、Uはどこで定義した何なの？
俺ならUはインターフェイスにすると思うけど。
fooを呼ぶ側も、foo側からも参照できる型である必要があるよね。
なんとなくプリミティブしか意識してない気がする。

2021/05/02(日) 19:41:10.32

制約の問題はIComparableぐらいならコンストラクタで必要なデリゲートを指定しないと
インスタンス化できないようにするみたいなことで解決できるけど、
インターフェイスのメンバーが多かったりイベントを含んでたりするとそうもいかんね。

2021/05/02(日) 20:12:47.50

>>652
(1)
var (moveNext, getCurrent) = MyGetEnumerator(x);
シンタックスシュガーは流石にコンパイラのサポートないと無理よ

(2)
(a)言語サポートないと無理だね
逆にいうとそういう機能を言語でサポートすりゃいいんじゃない？
言語機能の利点であってinterfaceの利点じゃないよねこれ
(b)もっともらしいデフォルトを用意するだけ

>>653
Funcはシステム定義だが？
TやUは架空のコードでよくあるただのプレースホルダであって特に意味はない
どこかで定義されていると考えていいよ

2021/05/02(日) 21:45:53.38

>>655
プレースホルダはわかってる。
引数の型の定義場所が問題だって言ってんだけど。
実務したことない？

2021/05/02(日) 21:58:29.87

>>656
言ってること意味不明だから多分君なんか勘違いしてる

2021/05/02(日) 22:16:38.89

>>648
Ctrl+F12でよくない？

2021/05/02(日) 22:20:11.10

>>648
実装へ飛ぶ的な右クリックメニューがある

2021/05/02(日) 22:52:19.04

実装に移動なんてあったんだな
これかなり助かるわ

2021/05/02(日) 23:12:46.37

>>657
クラスに実装するのなら、ドメインに焦点を当てたクラスにその実装も凝集されるけど、
外部からデリゲートで渡す場合はそのデリゲートをどこに定義すんのって事じゃない？

1回しか使わないのなら匿名関数でいいけど、複数箇所から同じ用途で使うのなら書き捨てじゃなくどこかで定義しておきたいと思うし、
更にそれが一体何のための処理なのかを設計に落とし込むなら適切な場所で宣言実装しないとだし

抽象的な話してると自分の頭じゃ理解しきれないな
こういう設計の場合こうすればよくね/こういう問題があるやんっていう具体例が欲しい

2021/05/02(日) 23:55:49.46

>>657
>>661が殆ど言った。
インターフェイスはインターフェイスで切り出しておかないと、
完全に単一のアセンブリでやらない限り、循環参照しがちだぞ。
AクラスのメソッドFooがBクラス受けてて、
BクラスのメソッドBarがAクラス受けてるだけで困ったことになる。
これはA.Foo(B)→B.Bar(C)→C.buz(A)と遠回りになってもそう。

2021/05/03(月) 00:35:06.67

>>661
構文レベルでクラスで書く意味はなく、関数でこう書けばいいでしょ、って意図のレスに対して
その疑問(設計レベルの問題)って方向性ズレてるってことは理解してる？
まあいいけど

ドメイン上のある責務に関連した処理をまとめたいって意図で聞いてるなら、モジュールで分ければいいよ
クラスは要らない

例えばOOPでIY, YがリポジトリでIX, XがリポジトリのCreateメソッドを使う何らかのサービスだったとするよ

関数で書くときはYモジュールにget, update, create, deleteなどの関数を定義する
Xにはfuncを定義して、もし関連性が高い別の機能もあればまあ一緒に定義してもいい
んで実行時にはX, Yをインポートして
func(create, u);
みたいにして呼び出すだけでしょ
funcとcreateをバインドして
_func = u => func(create, u);
みたいにしてDIでやってるようなこともできる

これならインターフェースもクラスも要らんよね？
関数だけがあればいい
構文上のムダが多いクラスを使う利点はほとんどないよ

>>662
相変わらずなにが言いたいかわからん

2021/05/03(月) 00:50:26.13

>>663
なんでわからんのかな。

2021/05/03(月) 01:00:53.01

>>663
できるできないの話ならアセンブラなら何でも実現できるよw

> 構文上のムダが多いクラス
と言うなら何がどうムダなのかを書かないと単なる個人の感想にしかならないよ

2021/05/03(月) 01:42:30.76

>>665
＞できるできないの話ならアセンブラなら何でも実現できるよw
意外にこれが本質だろうね。

一昔前のOOP批判にも「構造体でも同じことが実現できる」ってのがあった。
そりゃできるに決まってるが、そういう批判には無理してそうやって
書いたコードが果たして人に理解しやすいのか、
人間の認知能力に親和的なのか、という視点が欠けていた。

2021/05/03(月) 01:44:06.35

おじいちゃんこないだから暴れ過ぎ
OOPもInterfaceも不要って何でC#使ってるんだろう

2021/05/03(月) 01:44:36.83

xview/sunview のAPIは全部構造体だったなぁ

2021/05/03(月) 01:46:57.30

>>663
構文レベルでは引っかかるところは無いので、設計レベルの質問した感じ
自分の理解があやしいのは自覚してるので質問しつつ補おうとしてる　※自分は半人前くらいなので

663読んで見えてなかった場所が見えたのだけど、
>>651のコード例でいうとIYとYの定義が無くなって、代わりにYモジュール増えてるんだよね？
差し引きで言うほど構文が楽になってる？この辺は個人の感覚だけど、そんな変わらないような気がした

ついでにいうと、Xから見たときに何やってるのか解らなくなってる気がした
インターフェース使った時であれば詳細は良くわからんけどリポジトリ用のIYインターフェース使ってそっちに任せてるんだなという隠蔽だけど、
デリゲートでやると何か良くわからん関数受け取って処理させてるわってならない？

2021/05/03(月) 02:08:36.88

>>666
関数のほうが認知しやすいよ
OOPみたいにあちこち参照しないし
interfaceのように不要なメソッドにも依存しなくなる

>>667
ぶっちゃけ昔は選択肢が少なくJavaよりC#のがマシだからって理由かな
あとは惰性

>>669
C#だとトップレベル関数がないからあんま変わらんかもな
C#も近いうちに変わっていくと思うよ
デリゲートが何やってるかわからないなら命名に失敗してるってこと
命名に失敗したらデリゲートだろうがinterfaceだろうが同じようにわからないよ

2021/05/03(月) 03:11:07.27

>>667
突き詰めるといらない
だってc言語で完成されてるし
だから場面場面で使用するメリットを説明できるかってのは重要になると思う

先読みでの将来的に～になる見込みで
先行投資を現場のPGの勝手な判断で行ったってのは相当アホな所業

2021/05/03(月) 08:08:21.32

Interfaceが不要なメソッドってのも意味がわからんのだがな。
OOPでなくとも、型のキャスト可/不可には、インターフェイスがあったほうが良い。

これはGoみたいな、トップレベル関数で書ける他の言語でも同じ。

2021/05/03(月) 08:20:32.49

ここはC#初心者のためのスレのはずなんだけど
このおじいちゃん、なんでこのスレで自分の主義主張を振りまいてるんだろう？

自分の書き方が2021年時点で一般的な書き方と大きくかけ離れた時代錯誤なものと分かったうえで
初心者にもそういう書き方を強要したいの？
それとも誰かに構ってもらうのが目的なの？自社の若手に煙たがれて敬遠されてるとこういうスレでクダを巻きたくなるのかな？

率直に言って、このおじいちゃんは
Rubyガイジ並みorそれ以上の害悪だからもうこのスレで書きこまないでほしい

2021/05/03(月) 08:36:10.53

どっちの指摘？

2021/05/03(月) 09:50:34.48

構う奴もガイジって20年前から言われてるはずだがいい加減学習できないのかねチンパン君

2021/05/03(月) 11:36:41.28

昨日は触れなかったけど、関数のメリットの中でも特に大きいのは、テストのしやすさね

インターフェースにしちゃうと、テストモック作んのが面倒くさすぎんのよ
いちおうモックフレームワークみたいなのもあるけど、ありゃプログラミングパズルみたいでマトモじゃない
長くメンテナンスするには疲弊が勝る
そもそもなんでモックが必要になるかって
、OOPでインターフェース使ってDI、なんてことをやるから無駄にオブジェクトの数とオブジェクト間の参照が増えていくからだ

関数なら簡単だ
都合のいいラムダを渡すだけ
関数には無駄なオブジェクトも参照もない
これ以上にシンプルなものはない

これを知ってしまうとOOPなんてやってられんくなるよ

2021/05/03(月) 11:37:53.09

まあ１対１のインターフェースは要らないな
複数のクラスを同じ仕組みで扱うときに有効になるものだ

2021/05/03(月) 11:42:45.35

都合の良いラムダを渡すだけ。
そのラムダの引数の型は？

普通ベースクラスかインターフェイスでは？

なんか勘違いしてる気がする。
アセンブリ1つが前提になってる？

2021/05/03(月) 11:45:24.03

>>677
そりゃそうね。

2021/05/03(月) 12:09:02.97

>>677
それ関数でいいよ

>>678
意味不明

2021/05/03(月) 12:19:41.29

>>680
関数をオーバーライドするってことか？

2021/05/03(月) 12:43:57.15

どう意味不明なのかマジでわからん。
OOを捨てて関数型推したいのはわかるけど。

IDisposableなんかはどう不要にしていく？
IEnumerableは？

IDbConnectionは不要で、クラスがだけあれば良いって話？

2021/05/03(月) 12:48:01.71

>>676
興味あるのですが、参考になるサイトとかありますか？

2021/05/03(月) 12:51:04.01

初期のC++がCにトランスレートできてたようにクラスやインターフェースなんて無くてもコードは書けるわな
その方が楽とか言うならそれでいいと思う
俺のプロジェクトに関わらない限りは

2021/05/03(月) 13:04:29.64

>>682
IDisposableとかIEnumerableのような、言語が特別扱いしてるインターフェースを代替することはできない、ないし難しいだろうね
そういう特別なインターフェースを引き合いに出して、インターフェースのほうが優れてると主張することはアンフェアだとも思う
実際きみたち、特別扱いのインターフェースでしか優位性を主張できてないよね？

ちなみにGoだとdeferという構文があって、
いちいち特別なインターフェースの実装を”強いられる”ことなく、破棄関数を遅延実行させることができる
こちらのほうが洗練されてるね
C++だとこれはデストラクタの仕事になる
インターフェース？関係ないね
C#はどういうわけか、破棄関数の遅延実行にIDisposableというインターフェースを選択したが、だからといって、それがインターフェースの優位性を示すということにはならない

2021/05/03(月) 13:14:13.33

>>685
アンフェアでもなんでもない。
IDbConnectionみたいな、何らかのデータベースへのコネクション、を表すものの代替も出来てないよね。
具象クラスでは事足りないし「データベースへ接続する関数を渡すイニシャライザ」からの返り値は同じように、汎用的なインターフェイスにキャストされてないといかん。
Goでもこれはsqlパッケージの中にインターフェイスが定義されてるよね。

と言うか、アセンブリの循環参照もわかってないんじゃないの？

Goのdefer文は破棄の遅延実行ではない。その関数を抜けるときに必ず実行する、だけ。
破棄以外にも使えるんよ。
finally節だと思えば妥当でしょ。

2021/05/03(月) 13:30:48.18

>>685
特別扱いされているinterfaceが例にあげられたのはそれがよく知られたinterfaceの一例というだけの話であって、特別扱いされていることは本筋ではないだろう

2021/05/03(月) 13:44:29.08

>>686
データベース接続も関数でいいよ
同じシグニチャの関数セットを異なるモジュールに定義して必要なものを必要な時にインポートするだけ

2021/05/03(月) 14:15:02.88

>>688
シグニチャが同じなら、引数も戻り値も同じなんよね。
DBごとに違うコネクションをどう表現するの？
GoでもDriverインターフェイスでさばくよね。DB。
具象クラスのメソッドが呼びたい時はアサーションするよね、

2021/05/03(月) 14:23:09.97

無駄をなくしたとかシンプルにしたとか言ってるけど、言語仕様側で受け持ってた制約を無駄と評して人任せにしただけに感じてしまう
>666で言われてるけど

2021/05/03(月) 14:28:16.36

その関数のシグニチャを定義して強制するのがインターフェイスじゃないのかね

2021/05/03(月) 14:43:05.66

そう。結局インターフェイスのこと言ってるの。基底になるオブジェクトとかそういう話になるだろうけど。
定義場所の問題。
そんで、それを定義だけ外に出せないのが問題だと俺は思う。

2021/05/03(月) 15:09:53.18

>>682
それを許すならコールバックのがいいなー
結局、実装見てみないとそいつらってわかんなくない？

MSが作ったメソッドなら実装されているだろう多分って言えるけど
それって組む人間の信頼性の話でさ

昔のデバイスコンテキストみたいに
え？解放されてんの？されてないの？
どっち？
みたいなのソースから無駄にわからんじゃん
こういうの欠陥品として捨てていくべきだと思うよ俺は

2021/05/03(月) 15:24:55.90

>>693
コールバックはどうかなぁ。
それこそ、呼んでくれるかどうかわからんくない？
例外のハンドリングがいよいよ大変になるから、async awaitみたいにうまく隠蔽してくれる方が良いかなぁ。

確かにまぁ、開放したはずが開放できてなくて再起動するはめになったりしたし、わからんでもないけど、それこそIDisposableなんかでハンドリングした方が良いんじゃないかな。

2021/05/03(月) 15:33:42.40

>>694
ぶっちゃけよんでるかどうかわからんのは退化だと思う

2021/05/03(月) 16:10:09.16

デリゲートvsインターフェースの戦いはつまるところ気軽に使いたい派vs丁寧に型付けしたい派の宗教戦争なのだろうな
JavaのFunctional Interface、TypeScriptのStructural Subtyping、オブジェクトリテラルがあれば両陣営とも納得すると思われる

2021/05/03(月) 17:27:13.66

>>696
むしろこうだね、

適材適所派 vs. バカの一つ覚え
あるいは

常識派 vs. 俺だけがネットde真実に覚醒したんだ！！派

2021/05/03(月) 18:11:29.08

単純に、7割位のケースで有効な方法が、銀の弾丸な気がする時期じゃない？

Interfaceなり、型クラスなり、トレイトなり、定義と実装を分離する方法は色々だけど、どの言語でも完全に無くなってない事はゆっくり考えたらわかると思うんだけど。
どっちも出来ればいいんよ。
関数型も良いけど、世の中の殆どは状態を持っているんだから、結局モナドなんかを持ち出すぐらいなら手続き型でデータドリブンぐらいでバランスが良いとか、Entityクラスを軸にするんだ、とか、色んな考え方もあるわけだし。

2021/05/04(火) 00:13:22.42

循環参照だけど、例えば、FileLoggerと、StreamWriterみたいなクラスがあるとして、両方別アセンブリになってて、
FileLoggerはStreamWriterを使ってログ出力する事もできる、とすんじゃん？
で、
ここまでは普通にビルドできる。

StreamWriterもログを出力することになって、FileLoggerを使うことにするとすんじゃん？
前回の結果からの増分コンパイルはできるけど、クリーンビルドは出来なくなるよね。

結局は、最低IWriterなりILoggerなりとして、どちらかを定義と実装に分けておいて、
具象クラスをコンストラクタなり、ラムダを渡す初期化関数なりで渡すしか無くなると思うんだが。

ベースクラスと派生クラスにしておいて、ジェネリクス使えばそれで良いのでインターフェイスは要らない、と言うのは一見それで良さそうに見えるけど、
今度はダイアモンド継承になるから、WriterでありLoggerであるものが作れない。

関数型と排他の存在ではないと思うよ。
嫌いなら、必要悪ぐらいに思っといたら？

2021/05/04(火) 00:35:29.27

Action<string> logなりAction<string> writeLineなり必要な関数を引数で渡すだけ
FileLoggerをリビルドするのはFileLoggerを変えた時だけ
StreamWriterをリビルドするのはStreamWriterを変えた時だけ
どちらもコアライブラリであるActionにしか依存しないので常に単体でクリーンビルド可能

2021/05/04(火) 01:22:47.37

>>699
受け渡しする関数のシグニチャ(=デリゲートの型)が
メソッド1つだけのインターフェースと同じ働きをするので
IWriterやILoggerがメソッドを1つしか持たないなら高階関数で処理したほうが適切な可能性もあるよ

map/filter/reduceのように毎回一つ一つの関数を渡すのが便利なものと
リポジトリのように事前に定義された一連の機能セットに互換の型を利用することで
クライアントコードは実装の詳細を気にせず使うほうが便利なものとそれぞれある

比較関数を毎回渡してソートする方式とIComparableを使ってソートする方式の違い
どういう種類の仕様変更に対してどこまで影響が波及するかを比較して考えるといいかも

2021/05/04(火) 07:53:17.60

>>700
Action<string>が、どう「ログ出力関数」になるわけ？
そんな漠然としたシグニチャになるわけ無いでしょ。
百歩譲ってAction<LogInfo>だろう。
ログレベルとか発生場所とか全部プリミティブで渡すの？ってのが、>>653だよ。そのログ出力内容が変わったらシグニチャ全部変えてくの？

>>701
うーん、まあ、それもまた然りかな。
一つしか持たないインターフェイスはたしかにそうかもしれん。
俺のイメージはLoggerもWriterも、状態を持たざるを得ないイメージだったので、IDisposableも一緒に持つイメージだった。
ログレベルとか、開いてるファイルと書き込み状態とか。マルチスレッドだとうまく排他しないとログが乱れるから。

IWriterもILoggerも、もう少しメソッドを持つイメージかな。
頑張ればLoggerは一つのメソッドでいけるかもしれないけど、LogLevelみたいなLogger側にEnumは持たせないといかんかも。
DIするなら、ILoggerの方が楽だと思う。

2021/05/04(火) 08:02:02.52

なんか「こうすると後始末が楽」ってのと、「これてもできる」ってのは違うと思うんだが。
Action<string>とかAction<int,string,string>みたいなものでログ出力関数をロガーとして関数に突っ込むのは「これでもできる」側としか思えんのだ。

それでホントに改修も含めた総工数が下がるとも思えないし、
確かに今風だけどメリットはすごく薄いし、
合理的かと言われたら俺は違うって言いそう。

2021/05/04(火) 08:21:09.46

意味不明と言い続けてたのも、
全く解決になってない方法をゴリ押しすんのも、
もしかして、OOP・Interfaceが不要と思ってるんではなくて、OOP・Interfaceの考え方とか活用法を理解できてない？
>>666
本当にこれなのかな。

2021/05/04(火) 09:40:15.42

>>702
stringでもLogInfoでもなんでも好きにしなよ
お前ずっと反論がズレまくってんだよなぁ
ただの例示のコードスニペットの重箱の隅をつついて本質に触れないのは、ワザと話をそらそうとしてんのかな？
業務で書いてるコードじゃねえんだから、細かいとこは省略してエッセンスだけ書くに決まってんだろ

>>703
これでもできるじゃなく、そのほうが楽でわかりやすい、な
DIなどでおなじみの大量生産される型定義、プライベート変数定義、コンストラクタ定義が消えてスッキリ
コードの可読性を著しく下げる予測困難なコード≒隠蔽されたコード、長いスコープ変数(メンバ変数)などが消えてスッキリ
前にも書いたが、テストしやすくてスッキリ

>>704
いや真面目に、俺が意味不明ってつけたレスは、本当に意味不明だよ
頼むから、わかる日本語で書いてくれ
ちなみに俺も昔は、OOP信者でもちろんインターフェースも大好きだった
デザインパターンを1つ学んでは、一喜一憂してたのもいい思い出だ
ま、知識をアップデートしようってことだな

2021/05/04(火) 10:04:47.13

>>705
あのさあ。ホントにズレまくってるのそっちなのよ。
逸らそうとしてるんじゃなくて、業務で使うようなコードで、イニシャライザに任意の関数を渡すスタイル「のみ」でうまく行ったパターンは無いし、どのみちその関数のシグニチャは定義することになるんよ。

Kestrelでセルフホストする時に、どちらの方法も使うことになるけど、インターフェイスを受ける、具象クラスを返すラムダで初期化したりするよね。
GenericHostBuilderExtensions.ConfigureWebHostDefaults(IHostBuilder, Action<IWebHostBuilder>
とかもそうじゃない？

スッキリはしないよ。はっきり言って。

知識はアップデートしてるつもりだが、だからこそ、高階関数で万事解決だとは思ってない。

なんでも高階関数でやればスッキリする、依存を減らそう、呼んでほしいロジックは渡せば良いんだ、って発想は一時期かぶれたけど、
結局、相互に依存してるのと変わらんことに気づいた。
別にそれ自体がテスタブルでもなんでもない。
結果的にテスタブルになっただけであって、同じように気をつけてInterface使えばどちらもテスタブルになる。

2021/05/04(火) 10:37:19.27

まだ集団ウンチしてるのだ…

2021/05/04(火) 10:37:49.24

>>706
既存のフレームワークはまだ追いついてないんだよ
中心的なフレームワークをOOPでインターフェースも使う前提で作っちゃったんだからある程度”使わざるを得ない”のは仕方がない
あとはそこから如何にして脱却していくかだな

依存を排除しようとしてるのに、相互に依存してるんならOOP、関数以前に設計が下手な可能性が高いな

テスタビリティは明らかに関数のほうが上
おぞましいモックオブジェクトの大群に襲われなくて済む
関数ならモックオブジェクトはただのラムダに置き換えられる
テストコードは短く、シンプルに、理解しやすくなり、テストのための黒魔術(モックフレームワーク)への依存関係を完全に断ち切れる
これがいかに素晴らしいことか、業務で真面目にテストを書いたことがあるなら、わかるはずだ
もしわからないなら、本気でテスト書いたことがない”ニワカ”でしょ

2021/05/04(火) 10:52:23.31

>>708
追いついてないわけではなくて、現実見てるんじゃん。

結局、相手方にラムダなり関数なりの自分の一部分を「呼ばせる」仕組みになるのであれば、それは結局は依存してるのと同義だと思うぞ、俺は。見た目上依存が排除できてるようには見えるけど。

モックオブジェクトの作り方が悪いのでは？
結局、短くて大量のラムダに襲われるだけだし。
モックフレームワークとか開発の規模感にあってなかっただけではなかろうか。

別に俺は、完全にラムダを渡すスタイルが悪いと言ってるんじゃないんよ。
インターフェイスは必要な部分では必ず必要って言ってるだけであって。

インターフェイスと拡張メソッドでめちゃくちゃ効率的にできる事もあるし、抽象的に扱う必要があるものはある。
IDbConnectionをどういう関数にするかまだ答え貰ってないけど、どうするつもり？

宗教戦争じみてきたけど、絶対にインターフェイスは要らないって言いたいだけ？

2021/05/04(火) 10:56:22.23

実を言うとね
関数には様々な利点があるわけだけど、それらの利点がもし全くなかったとしても
この”テストコードの生産性の向上”だけが理由でも、俺は関数に取り組むべきだと考えてる
レガシーコードとはテストのないコードのことだ、とは有名なフレーズだが、心から同意する
テストコード生産性の低いOOPは、レガシーコード予備軍と言ってもいい
モックフレームワークは本当に君たちの良き友人だろうか？
よく考えてみてほしい

2021/05/04(火) 11:18:30.42

そもそも論だが、モックフレームワーク自体がまず必須ではない。
インターフェイスを満たしていればそれで良い。
依存性の注入をしはじめるとそりゃモックは作る必要があるかもしれないが、フレームワークを使う必要は無い。
そもそもそれは関数やラムダを渡す方法でも同じ。もちろん関数やラムダのテストはするよね。それが、結局依存してるって言ってるの。注入してるからあたり前よね。

なんか嫌な記憶があるんだろうけど、インターフェイスという概念が完全に使い物にならなかったら、世間はそう変わっていってる。でも、どの言語にもあるよね。型クラスだったり、少しずつ実現方法が変わることはあっても。
自分の使い方が悪いのを、ものが悪いと言うのはよろしくないぞ。

2021/05/04(火) 11:19:32.83

>>709
短くて大量のモックラムダの定義は常にテストと共にあり、全てが目に見えて、嘘も隠し事もなく、理解容易だ

モックオブジェクトの大群は全てが隠蔽されており、その実体はお世辞にも理解しやすいとは言えない黒魔術で構成されている
モックオブジェクトを扱う人間はモックオブジェクト独特の世界観を深く理解し、信仰しなければならない

僕らはただ楽に単純明快なテストを書きたいだけなのに…

2021/05/04(火) 11:23:09.70

>>712
自分で作れば、モックオブジェクトも別に隠蔽されてないし、理解しづらくも無いんだが。
必要十分なものを作れば良いと思うよ。

なんかフレームワークに振り回された思い出があるの？
それは俺にもあるからわからんでもない。

2021/05/04(火) 11:27:48.16

これ回線2つ使った自演芸やんけ
せめて文体変えようよ・・・

2021/05/04(火) 11:28:41.29

>>711
何故モックフレームワークのような出来損ないが、世の人々にありがたがられているか理解してる？
モックフレームワークを使わなければいいと、言うだけなら簡単だよ
でもねその代償に今度は、大量のモッククラスを書かなければならなくなるんだ
世の人々はそんな大量のモッククラスを書くのは嫌だ、ということでモックフレームワークを作ったんだ
苦肉の策だったんだろうけど、世の人々は薄々疑問を感じながらも自分を納得させてモックフレームワークを受け入れた
大量のクラスを書くよりは、たぶんマシだから

さてなんでこうなってしまったか、根本原因はもうわかるね？
依存性分離のためにインターフェースを採用しちゃったからだよ
インターフェースに実装を与えるのは、関数と比べるとものすごい労力かかるんだね

2021/05/04(火) 11:29:07.24

2021/05/04(火) 11:30:27.06

>>714
違うぞ。

>>715
やり方が悪い。そして関数のシグニチャはインターフェイスそのもの。

>>716
すまん、そんなスレあったのな。
ありがとう。
まあ水掛け論だろうし、もうやめとくわ。

2021/05/04(火) 11:34:02.42

>>713
僕らはテストを書きたいんだ
大量のモッククラスを書きたいわけでもない
モックフレームワークを自作したいわけでもない
モックフレームワークを利用して疲弊したいわけでもない
僕らはただたんにテストを書きたいんだ

2021/05/04(火) 11:42:00.80

ま、インターフェースなんかいらんな
データベースが当たり前になってきた頃からインターフェースを積極的に使うやつは確実に減ってきた
だってこれやっぱテーブルにしにくいじゃん
いやね
差分だけ本当にまとまってるならそういう手もありなんだけど
実際は虫食い状態の共通部と固有部分を分けるのって現実的じゃないと思うんだよね

2021/05/04(火) 12:03:51.01

属性のメリットが全然わからなくてとまどってる
obsoleteなど例外を除いて、summaryなどと違って参照時に開発者側へメッセージを呼び出すわけじゃないんだな
obsoleteのような開発時のエラーメッセージの表示を条件分岐したかったけど見当たらないし、obsolete自体が継承できないときた
メソッドの代わりとして使うしかないのか？

2021/05/04(火) 12:09:41.03

>>720
組み込み属性以外だと、リフレクションでメソッドなりクラスなりを探すときに、特定のAttributeがついてるものを対象にしたり、呼び出し元に特定のAttributeがついてるかをコールスタックから探したりするためのものでは？
あとはAttributeUsageAttributeで制限かけたりかなぁ。

2021/05/04(火) 12:36:44.27

属性は、
EntityFrameworkとかASPNETとか属性利用ありきのライブラリを使ったり自作したりしない限り
特にメリットなんてないという理解でいいと思う

逆に言えばそういうライブラリを使うときに初めて意味を持つんで
ひとまず書き方使い方だけ頭の片隅にいれておけば十分

2021/05/04(火) 13:01:40.29

>>721
ども
求めてる機能は作れそうにないや

2021/05/04(火) 13:41:23.71

>>720
属性はメタプログラミングで利用するもの
C#ではダイナミックに型情報にアクセスすることできるが、属性はその型情報に”お好みのラベル”を付与するための機構だ
ただラベルを貼り付けるだけではなんの意味もない
ラベルを解釈して振る舞いを変えるクライアントプログラムを作ることで、初めて属性に意味が生じる

同じ事をあちこちでやってるけど、クラスや関数など従来の言語基盤ではモジュール化しにくいもの
いわゆるアスペクトというものをモジュール化するための道具として使われることが多い
またIDEを初めとする周辺ツールなどからも参照できるためツールの拡張などに使われることも多い

はっきり言って泥臭い、洗練された機構ではないのでメンテナンスは大変だが、ただの利用者の立場では便利なものだ

python、TypeScriptなどでは属性より柔軟性は低いものの十分な効果が得られ、より理解、実装が容易なデコレータというアイデアが導入された(ちなみにこれは関数を受け取り関数を返す関数だ)
C#にもデコレータがあれば良いのだが……まだまだ遅れてるね

2021/05/04(火) 13:55:11.06

デコレータと属性は目的も実態も全く違うものだろ。

2021/05/04(火) 14:02:18.42

同じものってどこかに書いたっけ？

属性とはこういうものだ
他の言語では(アスペクトの実装手段として)より洗練されたデコレータというものがあっていいなあ
という文脈だが？

2021/05/04(火) 14:05:17.38

で、デコレータでどうやって開発時にObsoleteのようにメッセージを出すんだ？
Pythonみたいなデコレータじゃ実行時にしか出せないだろ

2021/05/04(火) 14:07:36.50

俺がいつデコレータで開発時メッセージを出す話をしたのかな？

2021/05/04(火) 14:08:07.94

お前がじゃなく、質問者がそう言っている

2021/05/04(火) 14:11:39.63

質問者は”属性の有用性が理解できない”と聞いてきてる
Obsoleteはその例でしかない

であるので属性の一般的な説明と用途を説明し
その後に参考としてデコレータを紹介した

2021/05/04(火) 14:17:24.30

質問自体が”開発時メッセージを表示させたい、コントロールしたいがどうすればいいか”だったら、デコレータの話はなかっただろう

2021/05/04(火) 14:17:31.82

いや質問者はObsoleteのようなことがやりたくて属性を調べたけど結局何ができる機能なのかよく分からなかったと言ってるだろ
この文脈で>>724のように書かれたらデコレータでならやりたいことができると質問者が誤解してもおかしくない
不適切というか意地悪な回答だと思うぞ

2021/05/04(火) 14:19:16.62

お前が俺を攻撃したいのはわかったが、もう少し冷静に考えてから攻撃したらどうだ？
毎回、返り討ちにされてはつまらないだろう？

2021/05/04(火) 14:19:35.90

属性とデコレータは似てるようで全然違うので、同列に扱うのがよくわからん。
TSのreflect-metadataなんかでもわかるように、あれはデコレータで属性を与えるようなものなのよ。
逆にJavaのように属性でデコレータを与えるようなものももちろんある。
javax.decoratorとかな。

属性は属性でデコレータとは本質的に無関係で同列で引き合いに出すものではない。

その言い方してると、Serializableの説明がしにくくなる。

2021/05/04(火) 14:20:23.79

>>733
攻撃したいんじゃなくて、間違ってる。
頭でっかちでしかない。

2021/05/04(火) 14:30:08.24

>>734
2回目だが同じとは誰も言ってないぞ
(アスペクト指向という)目的を達する手段が複数あり、片方がより洗練されていると言ったんだ
なぜこれで”属性とデコレータが同じものだ”になるのか理解し難い

2021/05/04(火) 14:35:07.15

>>736
誰もアスペクト指向の話は求めてないし、アスペクト指向にも使えるのは事実だが、アスペクト指向のためだけのものではない。
属性は属性。

Webフレームワークのパンドラとかロガーみたいな、特定のアスペクト指向に使う用途しか知らないならそう言いなよ。

2021/05/04(火) 14:40:27.36

データバリデーションのIndexやRequired、シリアライズのJsonPropertyとかColumnなんかは、別にアスペクト指向として割り込むためのものでも集約するためのものでもない。
XamarinのAndroidのActivityなんかはビルド時にXML産むために定義したり。