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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 21:32:32.95

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 21:41:40.86

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 21:48:33.25

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 21:56:27.84

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:02:59.89

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:08:52.32

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:45:50.27

ム板でやれ

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:49:38.04

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:55:41.61

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:57:29.91

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:07:50.71

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:10:39.92

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:11:12.03

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:17:43.49

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:34:02.35

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:43:32.60

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:45:23.62

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

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:54:34.76

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:57:08.75

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

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:57:13.32

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:04:32.27

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

こんなのを作るより

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

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:04:33.82

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:06:06.52

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

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:10:18.02

>>23
もっともですねぇ

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:13:36.43

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

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

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

public Image(Pixel[][] bitmap)

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

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

書きだす時は

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

こんなもんでよくね

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:15:00.08

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

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:17:24.64

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:17:43.59

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

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

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:35:15.50

極端に汎化するなら、こういうインターフェースを作るかな
interface ImageProcessor {
　　/// <summary>指定されたファイルがサポートされているかどうかを判定します。</summary>
　　bool Supported(string fileName);
　　/// <summary>指定されたファイルを読み込んで、オブジェクトを初期化します。</summary>
　　void Load(string fileName);
　　～
}
本体側は
AssemblyからImageProcessorを継承してるクラスを全部引っ張ってきておいて、
private static readonl List<T> processors;
private ImageProcessor processor=null;
private Load (string fileName){
　foreach (var p in processors){
　　if (p.Supported(fileName)){
　　　processor=p;
　　　break;
　　}
　}
　if (processor==null) throw new NotSupportedException(string.Format("{0}は未対応のファイル形式です", fileName));
　processor.Load(fileName);
}
みたいな。こうすれば、処理本体側は変更なしで対応形式の追加が出来るだろうし。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:35:54.03

まあ別にいいんだけどねこれでも

public Image(Func<Pixel[][]> reader, Action<Pixel[][]> writer)

public void Load()
{
　Pixels = reader();
}

public void Save()
{
　writer(Pixels);
}

これでinterfaceと大体同等だけど最初に入れてから入れ替えができなくて無意味に汎用性が下がるし
呼び出し側もメソッドの中で何が起こるのか分からなくなってソースがわかりにくくなるんで
必要がなければ避けるべき形だよね

public void Save(Action<Pixel[][]> writer)
{
　...　
}

処理の汎用化が必要でも、こんな風にライブラリ側だって必要なときに必要な物だけ渡してくれた方がわかりやすいし使う側も使いやすい
interfaceを使うと呼び出す場所(たとえばSaveを実際に呼び出すところ)とそれが定義されてる場所(Save処理を実装したクラス)が離れちゃうからわかりにくくなる
なにより「interfaceにそのメソッドが必要かどうか」という難しい判断をする必要がなくなるから問題がすごく簡単になる

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:40:53.37

まあ、やりたいことにあった方を選べば良いんじゃないかな。
実際、その二つの方法を提供しているライブラリも多いよ。
俺もそういうやり方することあるし。処理が端的に済む場合なんかは特に。

で、じゃあどっちかしか使わないか、っていうと、時と場合に依った。
どっちでも実現できる場合もあれば、どっちかじゃないとどうにもならん、とか
一方のやり方だとやたら遠回りなやり方になる、とか色々あったさ。

ライブラリを公開する、って観点で言うと、>>30みたいなやり方の方が使いやすいだろうな。多分。
実際、interfaceを定義する、っていう手間はあれで結構大変だし、ホントやりやすい方でやればいいと思うよ。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 01:33:59.48

ただ、制限がクリアできるならabstractの方が便利だけどね
interfaceで同一視したいクラスって、共通の処理がある程度有るし

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 01:37:13.24

（　・ω・）ｙ─┛～～

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 02:38:49.18

まあ実際、interfaceとabstract classどっちが多いかっつったら、
今まで書いてきたような目的下だと、abstract classの方が多いな。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 10:42:30.93

>>22
ゲームで必要な機能だけを、ある程度そのゲームに特化した形で抽象メンバにする
間違っても汎用的なライブラリを作ろうなどと考えてはいけない

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 18:00:55.53

落ちた？

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 21:16:46.38

そんな早くdat落ちするのかこの板

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 22:23:13.82

しないね。サーセン誤爆だ。

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 22:24:15.68

基本プログラミングっていうのは自分でライブラリを書いて自分で使うことの繰り返しだからな
汎用性が高く使いやすいライブラリを書いていくと良いプログラムになる
使いにくく汎用性が低いライブラリを作るとソースがなんだかわからなくなったり仕様変更できなくなったりする

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 22:33:08.75

最初はそれも上手く行かなくて辛いけどな。試行錯誤を繰り返していく内に、
どうすれば汎用性が上がるかが分かってきて楽しい。

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 09:55:22.97

さんざ苦労してライブラリ作っても、意外と使わなかったりするな
使わずに温存してるうちに陳腐化したり、もっといいライブラリが登場したり…

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 13:38:00.37

今必要じゃないライブラリ作ってもしょうがないよな
テストもろくに出来ないだろうし

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:13:44.11

それあるよな。必要な物書いていったらいつのまにかライブラリになってたってのが理想的。

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:16:01.56

もはやライブラリを作るほうが本来の目的になってる時、あるよねw

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:20:20.22

作りたいツールを思いつく→ツールに必要なパーツを作る

→そこで満足する、または飽きる

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:24:44.61

そこが楽しさだからなぁ
完成が見えた時点でやる気が無くなる

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:45:24.02

デバッグが一番大変だわ
コード書いてる時は楽しいんだけど
バグを出すために色々やってみるとかキツい
自分が使うツールじゃなかったらまず無理

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:39:37.48

>>44-47
よう、おれ

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:42:49.73

前スレ埋まったw
ここに移動すんのか？