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

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

このスレッドは
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からない場合など、勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。

なお、テンプレ2行目が読めない回答者は邪魔なので後述のC#相談室に移動して下さい。

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

関連スレ
ふらっとC#,C♯,C＃（初心者用） Part91
http://toro.2ch.net/test/read.cgi/tech/1335089085/
C#, C♯, C＃相談室 Part71
http://toro.2ch.net/test/read.cgi/tech/1332575004/


こんな感じでソフトウェア板に立てたらどうかな

─ここは、プログラム板における同名スレにおいて、
　 IDが付与されないがため生じる定期的な荒れ進行を度々経験し、
　 疲れてしまった同スレの住人が、透明あぼーんの活用でまったりと
　 本来のスレの目的を果たし続けるために設けられた、
　 一種の避難所です。

ム板開いたのかと思ったわ
避難所part1で良かったんじゃね？

>>3
感情的になった出て行け論者が立てたスレなので、
スレタイ名がメチャクチャになってしまったんだ。すまない。

荒れ気味の板がIDなしだと大抵ろくな事にならないのは分かるが、この板でする話なのか

ム板から逃れる先として、ソフトウェア板以外に何かあるかな？

ム板でやれ

>>7
巣に帰れってことだな。言い返す言葉もないよ。
だが、避難所を同じ板に作ってもしょうがないからな。

荒れてる時はこっちに誘導したらいいんじゃないかな

まあ、あっちに来た質問を無理にこっちに誘導する気はあんまり無いんだ。
向こうでも書いたけど、あっちのスレが回答不能なレベルに達してるってわけじゃないし。
むしろ、「IDがあった方が議論しやすい」と感じた人間だけが、こっちで議論すれば良いと思ってる。

こっちを擁護しておいてなんだが、これで本スレのテンプレに
こっちのスレを追加すべき/すべきでない議論とか巻き起こるのは嫌だなあ。
テンプレ周りの変更議論はもめるし。
もめるくらいなら追加したくない。

問題は回答者がここにくるかだな

俺が一番回答してるから俺がいれば大概大丈夫だろう

>>12
俺も一応回答者。どんくらい回答したかまでは覚えてないけど。

じゃあ、ちょっと質問
インターフェイス使うと改変に強いっていうけどプロパティとどう違うの？
プロパティも内部の構造変えても他のクラスに影響がない
影響が出るとしたら、プロパティの型を変更した場合
インターフェイスも引数の型変更したら結局使いものにならないし
改変に強いって説明の仕方おかしくない？

内部の違うクラスを同じようにアクセスできるのを明示するということならわかるけどね

クラスというのは、実体を作れる型。
インターフェースとしいうのは、実体を作れない型。

「改変に強い」のは、インターフェイス自体の改変ではないよ。
改変に強い、って説明自体確かに誤解を招く表現で、
実際は「内部実装を気にしなくて良い」が正解だと思う。

インターフェイスとはちと違うけど、Streamなんかその最たるものじゃない。
Stream自体が何をソースにどうやって実現されているかは気にしなくてよくて、
処理する側はStreamクラスのオブジェクトに対して必要な処理（メッセージ）を要求すればいい。
インターフェイスを定義する、ってのはそれだけのことでしかない。

「Hoge(FileStream stream)」って定義したメソッドより、「Hoge(Stream stream)」って定義されたメソッドの方が、
汎用的に使えるじゃない。

改変に強いっていうのはどうなんだろうな
個人的には別に強くないと思うが

interfaceごしだと実装クラスを入れ替えられるけど
改変前と改変後の2つの似たようなクラスを両方保持して
interface越しにどっちを使ってるか分からなくするなんて考えただけでゾッとする
一つの具体クラスをただ書き換えるほうがずっといい

だから改変に強いと言うよりは
ライブラリを作る側が使う側に処理を実装してもらう時に使うものだと思うよ
IComparableを実装してもらってSortメソッドで使う比較関数に利用したり

まあC#3.0からラムダ式が使えるからそういう用途はもうほとんどお役御免だけどね
interface自体ほとんどお役御免といっていいと思う
ライブラリに残ってれば使うけど自作する意味は殆ど無い

ム板って取扱いと人種的に宗教戦争余裕なのに未だにIDないのか

インターフェースは、お役御免には、ならないと思うがな。

interface I{ int Hoge(); string Hoge2(); }

こんなのを作るより

class C{ public Action Hoge; public Func<string> Hoge2; } こんなのを作って

new C{ Hoge = () =>{ ... }, Hoge2 = () => "hogehoge" }

こうしたほうが早いしわかりやすいし個別に設定できて汎用性も上だから
もうinterfaceを作る意味は無いはず

例えば、UnityやXNAやDxLibなどを同じように扱えるようにするにはどうするべき？
ゲーム本体部分とライブラリとの丁度境界線上にあるクラスはどのように定義すべき？

お役ご免ってのは言い過ぎでしょう。後々機能追加が考えられる場合、
その機能追加に耐える様Interfaceを定義するコトなんて、（自分は）ザラにありますよ。
たとえば、画像ファイルに対して順次いろんな処理をするようなソフトを作ったとき、
最初はjpgとbmpしか対応しないでおいて、いずれpngとかtiffもやりたいなあ、と思った場合、

interface ImageProcessor { ... }
class JpegImageProcessor { ... }
class BmpImageProcessor { ... }

なんて。
処理自体が短ければ>>18の言うとおり、ラムダ式で十分なんだけど、
色んな段階を踏む処理の場合、処理自体をクラス化しちゃう方が後々追加し易い。

>2つの似たようなクラスを両方保持して〜一つの具体クラスをただ書き換えるほうがずっといい

っていうような懸念がある場合は、interfaceじゃなくて抽象クラスでやればいいし。
共通部分は抽象クラスで処理して、後々追加したい機能毎に変わりうる部分は具象クラスに任せて抽象メソッドを定義だけしておく、とか。

>>23
もっともですねぇ

>>23
これだと違いはファイル読み込んでビットマップ作る
ビットマップをファイルに書き出す

ところが違うだけじゃないの

具体的なクラス一個作って

public Image(Pixel[][] bitmap)

こんなコンストラクタにして

new Image(JpegLoader.Load(file))
new Image(BmpLoader.Load(file))

書きだす時は

JpegWriter.Write(image.Pixels);
BmpWriter.Write(image.Pixels);

こんなもんでよくね

まあ、オブジェクト指向を完全に理解して常に完璧な形で実現出来てる、
なんて境地には到底達せないと思うので、今の自分の実装が正しいとも言い切れないんですけど。

Rxとか見てると、ラムダ式で全部・・・なんてのも決して非現実的ではないと感じるし、
「一つ一つの処理は短く」という基礎的なことを突き詰めていけば、
そういうこともきっとできるんだろうなあ、とは思う。

ただ、それでもinterface自体が無くなる可能性は低いだろうな。
俺は逆に、Rxが駆逐しようとしているのは開発者がclassを定義する、
という行為じゃないかと感じる。

変数名につける英単語がわからなくて悩みまくる

>>25
それだと、あっちこっちで処理対象がJpegなのかBmpなのか判定しなきゃいけなくなるでしょう。
処理が読み込みと保存だけでいいなら、2箇所ぽっきりだしそれもありだと思いますけど。

Classとインターフェース作っちゃえば、インターフェースを介して処理してる本体側は大きな変更することなく、
一番アタマで対象の判定だけやって、クラスの実態をnewした後は同じ処理を続けるだけ、で行ける。