ふらっと C#,C♯,C#(初心者用) Part137
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。 他のスレッドでは書き込めないような低レベルな質問、 質問者自身なんだか意味がよく分からない質問、 ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。 内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。 なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。 C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください >>980 を踏んだ人は新スレを建てて下さい。 >>980 が無理な場合、話し合って新スレを建てる人を決めて下さい。 ■関連スレ C#, C♯, C#相談室 Part95 http://mevius.5ch.net/test/read.cgi/tech/1508180530/ C#, C♯, C#相談室 Part93 https://mevius.5ch.net/test/read.cgi/tech/1492818720/ ■前スレ ふらっと C#,C♯,C#(初心者用) Part136 http://mevius.5ch.net/test/read.cgi/tech/1520057345/ ■コードを貼る場合は↓を使いましょう。 http://ideone.com/ https://dotnetfiddle.net/ ■情報源 https://msdn.microsoft.com/ja-jp/library/gg145045.aspx https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index https://msdn.microsoft.com/en-us/library/gg145045.aspx http://referencesource.microsoft.com/ VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured 前スレ>>993 , >>998 例外が発生しないようなコードを書くべきというのはそのとおりだと思いますが、例えば ファイルパスが適切であることを確認してファイルが存在することも確認して、その上で オープンしようとしてもそのタイミングでファイルが消されている、といった状況だと例外が 発生しますよね 流石にそういうケースでは例外で止めるべきだというのも一つの考え方ですが、それを 検出して処理を戻したいケースもあるだろう、と思っての質問でした >>4 誰かが編集中なときもあるし そもそもぶっ壊れてるときもあるし アプリの動作も含めて仕様を決めないとどうしようもないじゃん まあ、最初から言ってるように、抽象的な質問には抽象的な答えしか返しようがないw 例外に対処するイディオム的な物を教えてくれ、と言ってるように聞こえるけど そんなものはないとしか... なかなか意図するところが伝わってないのですが、「例外処理をループの中に閉じ込めて、 例外が発生しなかった場合だけループを抜ける」という書き方を知りたかったのです 処理の内容とかはどうでも良くて、ループの囲い方とその抜け出し方を なので、以前レスいただいたように、whileで無限ループを作って、tryブロック内にbreakを 置いてループを抜ける、という回答で私には十分でした 試してみれば一発で分かる話だったのですが、tryブロックから外側のループを直接抜ける ことができると思っていなかったので、それに気づかなかったということです 皆様お付き合いいただいてありがとうございました また質問をした際には付き合っていただけると幸いです 困っているわけじゃないんだけどちょっと気になってることがあるので分かる方がいたら教えてください 次のコードを実行すると y に true が代入されますが、これはどういうときに使うのでしょうか string x = null; bool y = x is var z; // y に true が代入される private void button1_Click(object sender, EventArgs e) { if (sender is Button b) { } } 方法: as 演算子と is 演算子を使用して安全にキャストする (C# プログラミング ガイド) https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/types/how-to-safely-cast-by-using-as-and-is-operators public class Test { public int Id{get;set;} public string Text{get;set;} public string Other{get;set;} } このようなクラスを他プロジェクトやライブラリで ICollectionの型として使い回したい場合 どのような依存をすればいいのでしょうか? インターフェースでこの型実装を強制させるとかでしょうか? インターフェースを使わないで他の参照方法のが望ましいのでしょうか? >>11 悪口言いたくないんだけど、俺様用語が多過ぎて何を言ってるのか全然分からないよw >>13 List〈Test〉等を他のプロジェクトでも扱いたいのでTest型で返す関数を作成して それをこれをパッケージした時に他のプロジェクトでも受け取れるようにしたいって事ですね public Test GetTest(); みたいな関数でTest型を使いまわせるようにしたいです >>12 Abstractって指摘も入ってるので 型クラス(Test)を実装しておき これをベースにして public Test GetTest(); を継承先に実装するようにするのが一番賢い設計ですかね・・・? 機能というよりはC♯を使った設計の質問と少し抽象的な話なのでスレチだったらすいません >>14 publicな型はそれを含むプロジェクト(アセンブリ)を参照する別のプロジェクトからも 普通に使えると思うけど、そういう話ではなくて? >>16 dll状態だと戻り値Test型って何?ってならないかと思って構造どうすればいいのか悩んでましたけど そもそもそういう事を考えること自体がおかしかったかもしれないです・・・ Test型のみを他のプロジェクトに流用させたい時とかも考えていたんですけど そもそもその設計自体がおかしいと思い至りました >>11 もうちょっと掘り下げて質問し直します EntityFrameworkを使ってSQLにTest型の入出力をするクラスと WebからスクレイピングしてTest型を返すクラスを作りたいのですが ここでTest型を両方で共通で使いたいと思ってます Test型はプロパティが減ることは無いですが追加はしたいものとします この時Test型はどのように実装するのが好ましいのでしょうか? 今だとSQLに接続したい時とスクレイピングする時に読み込むクラスが分けれないので困っています >>18 これはTestクラスを作成して単独でビルドし これを参照させたSQLクラスとスクレイピングクラスに継承させて扱うのが正解なのでしょうか? C#というよりクラスタイプoop全般の話だと思うのですが、クラスを呼んだ時のパラメータは、コンストラクタに与えるのが良いのでしょうか、メソッドに与えるのが良いのでしょうか 両方できるので無造作に使ってるのですがOO的に間違った事をしていそうで よろしくお願いします >>21 インスタンスを作るのとメソッドをコールすることと意識が混ざっている素人で失礼しました インスタンスを作る時にパラメータを渡すのと、メソッドの引数にパラメータを渡すの、oo的にはどちらが正しいのかお聞きしたかったです >>22 oo的にはこう、というのは無く、スマートに記述できる方で良いという感じでしょうか? 今自分は気分や雰囲気で使い分けてるのですが、実はルールがあるのではと心配しておりました >>24 正直何が聞きたいのかよく分からんけど、 いろいろ想像してみると、たぶん本当に聞きたいことはコンストラクタ云々じゃなくて あるデータをプロパティとしてオブジェクトに持たせるかどうかをどういう基準で決めるか、 じゃないのかな。 例えばSystem.Timers.TimerにはpublicなプロパティIntervalがあるけど、 これをprivateかprotectedにしてユーザーからアクセスできないようにして、 Startメソッドの引数として与える仕様でも同じじゃないのかと >>25 理解が浅く説明が拙くすみません そのような事です どちらでも出来てしまいますが、使い分けのルールや指標はあるのかなと そのパラメーターが変更可能なのかどうかでやり方がいろいろある インスタンスを作るときに最初に決めたパラメーターを変える必要がないもしくは変えたくないなら コンストラクタで渡してしまえばいい 毎回変えるかもしれないならメソッドで渡せばいい >>26 そんなもの無い その時々で苦悩して答えを出すしかない プログラミングってそういう仕事 >>20 教科書的にはメソッドの引数しかありえない >>26 基本的には全部引数でも間違いではない あくまで関数が主であって、オブジェクトは関数のコンテキストに過ぎない、と考えるのが今時のプログラミング 端的に言えば、毎回同じ引数を渡すのが面倒だと思うならクラスにすることを検討するというだけの簡単な話 >>26 いや、プロパティとして持つべきデータかの判断は一般的にはそんなに難しくないはず。 上に例に挙げたTimerだって、Startの引数でIntervalを指定する方式だと 問題や不自然さがあることはちょっと考えれば分かるはず >>31 別に問題も不自然さも無いよ System.Timers.TimerやSystem.Windows.Forms.Timerのインターバルがプロパティなのは、デザイナで設定できる必要があるからだ 実際、デザイナに貼れないSystem.Threading.Timerはコンストラクタかメソッドで周期を設定する (ライブラリではなく)アプリケーションの開発に関して言えば、データクラス以外でプロパティを使う必要があるケースは稀だよ データクラスを除けば、一度設定した値を取り出したくなるのは殆どの場合設計が間違っている >>20 ・コンストラクタで渡す var a = new Test(1, "A"); ・メソッドで渡す var b = new Test().SetId(2).SetName("B"); ・オブジェクト初期化子で渡す var c = new Test{ id = 3, name = "C", }; 通常はコンストラクタで、メソッドチェーンはファクトリパターンでよく使う オブジェクト初期化子は閉じてるクラスの可読性を上げたいときに使う まあ統一性さえ確保出来ていればどれを選んでも大差ないよ >>32 System.Threading.Timerがプロパティを持たないのは何か意図があると思うが 使ったことがないのでよくわからない。(軽量であることが「コンセンプトだから? あるいんた単に設計者の頭が古いだけかもしれない} TimerのIntervalをプロパティとして実装しなかった場合。 (1) タイマー動作時にIntervallを変更するためにはStartを実行することになるが、 OOP的に不自然 (2) そもそもTimerオブジェクトは、少なくとも動作時にはIntervalの値を保持している。 だったらこれをプロパティとして公開する方が自然 >>34 動作中にIntervalの値を変えられると困る場合、 Start時のみ設定可能にするのは別に不自然でもないよ OOPの目的はメンテナンス性と事前の徹底したバグ潰しだから、値を変更できるルートを予め絞っておくことは理に適ってる 色々とアドバイスありがとうございます 統一性があれば、後はデザパタに従うか等で決定するのが一般的と解釈しました 田舎の中小1人情シスでコードレビューもされないので世間の動向が分からず参考になります 都会の大手の人は切磋琢磨し洗練されたコードを書くんだろうなと憧れます >>28 あまり我流過ぎるとチーム開発の時に混乱するという心配がありまして >>38 対象を無視してオレオレナントナク基準で決めるほうが我流 物事にはそれぞれ特性があり最適な答えはいつも違う それを導き出すには都度考えて議論を重ね実験を繰り返すしかないんだよ 見積り終わってるのに時間かけても無駄 一円の利益にもならない 今回の開発で黒字でなければ2回目はない よって一番時間がかからない方法が正義 業務系はそれでいいのかもね 保守するのは自分でも自社でもない ならどんなに汚いコードでも早くしあげたほうが勝ち ただし納品された顧客はとんでもない借金を背負うことになる 罪悪感ってないのかね >>41 いや 君のやり方だって怪しいもんじゃない? 具体的に○○さんのコードは見易くてわかりやすいですねって言われた実績あるの? 無いのに勝手な妄想で自分のコードを保守しやすいと思い込んでない? >>43 お前なんか全身elseで強化した俺の敵じゃねぇ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる