ふらっと 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/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

ID:9VBk1Szv0
ID:/WM42vypM
いい加減議論スレへ行け

ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/

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産むために定義したり。

2021/05/04(火) 14:41:32.01

>>737
はぁ…何度目だ？

質問者は明にアスペクト指向の話を求めているわけではないが、属性の有用性についてコメントを求めている

で、あるならば属性の利用形態として大きなウェイトを占めるアスペクト指向について、言及しないわけにはいかない

属性は単なるラベルであり、クライアントによって様々な利用形態が考えられることは、俺が先に説明した通り

2021/05/04(火) 14:44:33.97

そうか？
C#で属性使ってアスペクト指向ってあまり一般的じゃないだろ
ヘルスバーグがAOP嫌いなのも有名な話だ

2021/05/04(火) 14:46:49.09

>>739
属性の有用性はそれ以前の問題。
アスペクト指向に属性は実際問題必須ではない。
インターフェイスは要るがなw

単なるラベルであり様々な利用形態が、ってのは、わかってる相手に説明する方法であって、全く知らない人間に対しては何の説明でもない。せめてググるためのワードを出せよ。

2021/05/04(火) 14:50:23.97

初心者にまったく役に立たない話はここでしなきゃいいのでは？

2021/05/04(火) 14:52:35.33

別にね、アスペクト指向はルールベースでも良いのよ。
Rubyなんかだと命名でフックしたりするようにね。

2021/05/04(火) 15:04:03.10

>>741
属性はAOPに必須ではないが、ないと非常に大雑把な実装になり、挙動のコントロールが難しくなるため、実用上はほぼ必須だよ
太平洋横断に船は必須ではない、と言うようなものだ、最後の旅にならないといいね

いやいや、何もわかってない人にこそ、属性とはただのラベルでしかない、と説明したほうがいい
ただのラベルということを理解してないと、元の質問者のように属性には開発者メッセージを出力したり、色んなことができる、なにか不思議な力がある魔法の道具なのかな、と誤って認識してしまうんだ
1. 属性には本当にラベル以上の意味は何もないし、何もしない
2. 何かするのは、そのラベルを見て処理をするクライアントプログラム
3. 何をするかは、そのクライアントプログラム次第で全く異なる
これが属性の基本の基本な
このシンプルな3つの事実を教えないで、有耶無耶にはぐらかすと、初心者が属性を理解できなくなってしまう

2021/05/04(火) 15:07:33.04

ほぼ必須といったのは誤解を生むかもしれないな
デコレータのようなより洗練された機構が無く、AOPをメタプログラミングで実装する以外の選択肢に乏しい言語にとっては、ほぼ必須と訂正しておこう

2021/05/04(火) 15:16:46.55

だから、そんな話はしてないの。AOPとか。
デコレータの話が蛇足な上、その根拠のAOPの話が蛇足だったのよ。

属性はただのラベルではない。
誰かが読み取るためのラベル。
それはシリアライザだったり、コンパイラだったり、Webサーバのランタイムだったり様々だけど。
だから、Obsoleteなんかが意味を成すんであって。

現実的にC#の属性はAOPのためのものではない以上、蛇足そのものでしょ。
だから頭でっかちだと言ってるんだよ。

「ただのラベル」こそ「うやむやにはぐらかしてる」でしょ。

2021/05/04(火) 15:18:25.60

ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/

2021/05/04(火) 15:18:59.72

じゃああっちで。

2021/05/04(火) 15:42:18.40

デコーダ太郎は責任とってクビ吊れ

2021/05/04(火) 15:43:52.50

>>746
>属性はただのラベルではない。
>誰かが読み取るためのラベル。
それをただのラベルっていうんだよ
読み取る側がそのラベルを見て何らかの作用を起こすまではなにもしない
まさにただのラベルだな

2021/05/04(火) 15:54:23.06

>>750
しつこいわ。

2021/05/04(火) 16:04:50.31

>>751
ええと
ブーメランってご存知？

2021/05/04(火) 16:08:55.98

お前の理想以外聞き入れないなら、ブーメランでもなんでもないわ。

2021/05/04(火) 16:10:37.11

というブーメランなのでした
ちゃんちゃん

2021/05/04(火) 17:28:51.83

>>723
ビルド時にカスタムのエラーや警告を出したいなら
Code Analyzer使って属性をチェックすればいい

2021/05/05(水) 09:44:41.21

昨日は頭のおかしい人が大活躍してたみたいだな
策っとNGしときましょう

2021/05/07(金) 00:21:29.88

WebClient使ってWebサイトのhtmlを文字列として取得したいんですが、
読み込みに数十秒かかるような重いページだと、途中でエラーします。
そんなページでもエラー無く読み取る方法有りますか？

2021/05/07(金) 00:26:59.06

Irvine

2021/05/07(金) 00:34:48.56

>>758
それはC#から呼び出して使えますか？

2021/05/07(金) 00:39:08.58

>>757
HttpClientクラス使った方が良いと思うけど
WebClientクラスの場合は、GetWebRequest()をオーバライドして
WebRequest.TimeoutプロパティとHttpWebRequest.ReadWriteTimeoutプロパティを設定

2021/05/07(金) 00:43:50.02

>>760
ありがとうございます。
>GetWebRequest()をオーバライド
は既に試したんですが、相変わらずエラーで中断します。
>HttpClientクラス使った方が良いと思うけど
それは何故でしょうか？

2021/05/07(金) 02:50:42.19

どんなエラーが出るのよ

2021/05/07(金) 03:48:20.57

DLしたいサイトのURL教えてもらっただけでだいぶはかどるよね。

2021/05/07(金) 04:25:10.15

中華から攻撃受けてるときの重いふたばとか

2021/05/07(金) 04:39:35.33

デフォルトだとタイムアウトが足りてないだけなんじゃないの?

2021/05/07(金) 05:39:50.22

> 途中でエラーします。
エラーしますとか変な日本語使う奴の相手はしない

2021/05/07(金) 08:08:05.60

エラーいたします。

2021/05/07(金) 08:28:13.14

エラーがございます

2021/05/07(金) 08:44:51.51

エラーなさる

2021/05/07(金) 11:18:16.60

エラーになられます

2021/05/07(金) 11:23:53.77

エラー仕る

2021/05/07(金) 12:35:02.79

エラー参上

2021/05/07(金) 12:37:58.01

>>764
ふたばってもう誰も見てないだろうけどどんな理由で攻撃してくるの？

2021/05/07(金) 15:59:09.92

尖閣諸島を渡せ

2021/05/07(金) 18:28:13.92

エラー渡し

2021/05/07(金) 21:30:40.73

エラー呼吸

2021/05/07(金) 21:31:58.32

さくらタンのエラー画像キボンヌ

2021/05/08(土) 00:36:51.80

(*´Д`)ﾊｧﾊｧ

2021/05/08(土) 11:24:07.14

くだらん

2021/05/08(土) 12:22:03.93

#region って使わない方が良いのですか？
プライベートメソッドがたくさんあるとき隠すのは駄目ですか？