yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2018/10 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
 垂オ訳ございませんが、現在このブログではトラックバックを受け入れていません。

 この記事に対してリンクされる場合には、こちらのURLをご利用ください。
http://void.yamicha.com/blog/blog.cgi?mode=view&number=627
 上記URLをトリプルクリックされますと、簡単にURL全体の選択が行えます。

※以下の記事がトラックバックされます。
ギョーザ及びその周囲の恐怖
2008/02/04(Mon)02:27:01
 以前に「生ゴミギョーザ」なる問題がありましたが、今度は農薬ギョーザが発見されました。中国製か否かを問わず、危ない食品というものはたびたび問題になりますが、今回ばかりは「単なる食中毒」では済まされません。期限切れのものが少々入っていたり、せいぜい消化不良を起こすといったレベルではなく、食べて死に掛けた人も存在するのです。
 混入ルートは諸説あるようですが、未だにはっきりとしたことは分かっていません。一部のパッケージには穴が開いており、何者かがここから毒物を混入した可能性も指摘されていますが、パッケージに穴が開くことは必ずしも珍しくありません。そもそも人為的なものであるとするなら、誰が何の目的でどのようにそれを行ったのかが分かりません。何らかの事故の可能性も高いのですが、それにしても不明な点が多いようです。
 混入の経緯については調査を待たなければなりませんが、ここで注意すべきことを1つ述べておきましょう。中国産の食品がたびたび問題になっているのは事実ですが、日常生活から中国製品を根絶することはほぼ不可能です。特に加工食品の材料は中国産が少なくないと考えるべきですし、材料は日本産でも中国で加工・生産しているかもしれません。産地に注意するのは悪いことではありませんが、「日本から中国製食品を根絶せよ」と声高に主張する行為には本質的に意味がありません。食料自給率からしても、日本のメーカーの中国依存度からしても、物理的に無理なのです。
 つまり、中国産を完全に排除することはまず不可能なのですが、それなら一体何に注意すべきなのでしょうか。答えは簡単、「中国製品の問題に乗じてひと儲けしてやろう」ともくろむ、国内の浅ましい連中に注意すべきなのです。無論、これは日本国内で良質のものを作ろうと努力している第一次産業の方々のことではありません。中国産の危機をことさら強調して無用な社会不安をあおる連中のことです。
 確かに中国産のリスクは国産より高いとみられます。しかし、「中国産を買うな」などとことさら騒ぎ立ててみたところで意味はありません。そもそも国内でも様々な偽装が存在していることを考えれば、「日本産は買うな」という声が出ても何ら不思議ではありませんが、そのような声を見かけることはありません。今回の問題では命に危険が生じた人も出ており、その点では重大な問題ではあるのですが、国内でも同等以上に重大な問題は発生しています。雪印食中毒やO-157問題を忘れてはいけません。
 念のために明記しておきますが、私は中国を弁護しているわけではありません。もしこのギョーザ問題が中国側の責任によるものであれば、オリンピックなどに現を抜かしている場合ではありません。しかし、人々の危機感を無用にあおって利益を得ようなどという行為は社会不安の原因にもなり、到底容認できません。例えば、「ゲーム脳」などという多くの学者から否定されているインチキ学説を危機感をあおって売り込む評論家、「学力低下」の危機感を必要以上にあおって少子化時代のシェア占有を狙う塾産業、少年犯罪が数十年前から激減している事実を伏せて「少年犯罪・キレる子どもたち」と大々的に恐怖をあおる書籍など、例を出せばきりがありません。
 さらに言えば、日本国内を含めてどこで作られた製品であっても、100%事故や偽装を起こさないことはあり得ません。そして、事故や偽装を完全に防止することができない以上、取引量が多い国の製品に対して「これは危険」と言っていれば、確率論的に見てもじきに必ず的中するのであり、「中国産が危険」なのはある意味当たり前です。
 危険な食品から身を守ることも大事ですが、危険な情報から身を守ることも同様に大事です。中国産に不安を抱かざるを得ないのは事実ですが、このような時こそ立ち止まって冷静に考えてみるべきでしょう。

 一般にも大きく報じられましたが、MicrosoftがYahooに買収提案。これ自体はさほど驚くべきことではありません。MSはGoogleに対抗しうるだけの検索技術をかなり欲しているはずであり、そのためにYahooを買収しようと考えたとしても予想の範囲内です。ちなみに日本のYahooは米Yahooよりもソフトバンクの影響が強いため、米Yahooが買収されても大きな変化はないと考えられています。
 米国のソフトウェア業界自体、ここ数年が転換期となっている印象は否めません。事実上Yahooが占有していた検索シェアをGoogleが切り崩して占有し、MacromediaはAdobeに買収され、GoogleがYouTubeを買い取り、SunがMySQL ABを買収することになりました。いずれも性質が違うこれらの全事象をまとめて扱うのには無理がありますが、いずれもここ最近の大きな動きです。
 ちなみに、YouTubeや今回のYahooとMSの問題こそ日本で報じられましたが、その他の様々な買収問題が日本で大々的に取り上げられることはまれです。したがって、これら以外の買収問題を知らない方も多いはずですので、以下に簡単な概要を述べておきます。
 まずAdobeはPhotoShopやAcrobatで有名な企業であり、日本の官公庁は無駄にAcrobat文章を使用する癖があるなど、同社のソフトウェアは多くの場所で使われています。買収されたMacromediaはShockWaveで有名ですが、Web開発ツールなども手がけています。デザインソフトウェアなどではAdobeの分野と重なる部分も多く、それが買収の動機の1つでしょう。なお、ShockWave及びFlashはメジャーなWebプレイヤー技術であり、Javaアプレットのライバル関係となる存在でしたが、ほどなくJavaはサーバー分野に進出し、この両者が明確なライバルと見なされることは少なくなりました。
 現状において、Javaの開発元であるSunが率いるJava陣営とライバル関係にあるのが、MS率いる.NETです。そして、ここからが少々複雑なのですが、Sunに買収されるというMySQL ABは「データベース」と呼ばれるソフトウェアの開発会社であり、この会社が作成した「MySQL」は世界で最も多く使われているデータベースソフトウェアとされています。YahooやGoogleなどの有力企業もこれを使っているようです。
 さらに複雑なことに、商用データベース分野で最も有名な会社はおそらくOracleですが、このOracleはJava陣営に所属しています。Oracleは先にInnoBase社を買収していますが、これはMySQLで多く使われている「InnoDB」と呼ばれるストレージエンジン(いわばデータベースソフトウェアのパーツ)の開発元で、MySQL ABはInnoBaseとの契約によって期限付きでInnoDBを使用する権利を得ています。データベース分野でMySQL ABとOracleはライバル関係にあるため、Oracleが期限更新を拒む可能性を考えて、MySQL ABは独自のストレージエンジン開発に乗り出していました。そのMySQL ABをSunが買収するわけですから、かなり込み入った状況であることが分かります。
 Googleについても取り上げておくと、Googleは以前にとあるインタビュー記事で「MSとは争うが、Oracleと争う気はない」との方針を述べています。実際、MSは今でも検索分野に力を入れようとしており、さらにYahoo買収提案で検索分野への大々的な進攻を企てているのを見ての通りですが、GoogleとMSが正面衝突する可能性は非常に高い状況です。
 さらに付け足しておくなら、SunはOSである「Solaris」の開発社でもあり、OS分野でもMSとは一応のライバル関係です。また、最近はオープンソース(プログラムのコードが公開されたプログラム)と呼ばれる動きが活発ですが、MySQLはそもそもオープンソースであり、Javaもオープンソース化が進んでいます。Unixと呼ばれるOSの多くもオープンソースなのですが、Mac OSも最近はUnix系オープンソースOSからの派生のようです。そのMac OSの開発元であるAppleは、今まで延々と独自のCPUを発注・開発していましたが、このほどIntelのCPUへの転向を表明しています。
 MSは検索エンジンであるMSNの他、「SoapBox」なる動画投稿サイトも開始していますが、これは明らかにYouTubeの成功を受けたものであり、前述の通りYouTubeはGoogleに買収されています。このような様々な事情からして、MSが手を打っておこうと考えるのは無理もない話です。
 Yahooを買収しようとする最も直接的な理由が「Googleに対抗するため」であることは否定できませんが、上記のような様々な事情も影響していると考えるのが最も自然でしょう。

 せっかくGoogleを取り上げたのですから、ここでもう1つ。皆様、「谷歌」をご存知でしょうか。日本の漢字表記で正確に書くなら「穀歌」となるようです。字面から連想する限り、どこかの山奥の民族に受け継がれてきた伝統か何かでしょうか。「穀物の実りや収穫を祝う伝統的な歌と踊り」のイメージです。
 ところが、実はこの「谷歌」または「穀歌」、Googleの中国名なのです。先進的なイメージが完全に崩壊しており、実際にインターネット上では反対運動まで起こったそうです。Googleは検索の他、様々な技術によるソフトウェアやWebアプリケーションを提供していますが、「谷歌」や「穀歌」からそれを連想することは不可能です。
 さて、なぜここでそのようなことを取り上げるのかといいますと、朝日・読売・日経が共同で提供するサイトの名前が「新's」(あらたにす)であると分かった時に、上記の「谷歌」を連想してしまったためです。はっきり言って「あらたにす」なる名前に「新た」なイメージは全く感じませんし、ひらがなで表記されたものを読むと見間違えそうです。どうせ同じように「ダサい」のなら、いっそ「谷歌」などの方が分かりやすいだけマシというものです。
 しかし、たかだか社説を読み比べできるサイトなどに、現代のインターネット利用者が価値を見出すとは到底考えられません。「MSがYahooを買収」などと大騒ぎされているのに比べ、日本の提携や合併は何と「みみっちい」のでしょうか。

 MSは「.NET戦略」を称しており、C#やVBなどの開発言語を提供しています。開発ツール一式が完全無償のJavaに散々苦戦させられたためか、今ではMSも開発ツールを無償で提供しているのですが、導入するためにはWindows XPのSP 2以上が必要です。ところが、このPCでだいぶ前にSP 2を導入したところ、完全再起不能に陥りました。はっきり言ってあれはウイルスです。
 つまり、このままでは.NETは使えません。しかし、C#言語の存在はかなり魅力的です。何としても開発環境を整備したいものです。ちなみに、新しい技術や言語にも存続するものと滅びるものが存在しますが、この両者の違いは何でしょうか。その時のパラダイムや時の運なども大きな要素ですが、それ以外に1つ重要な差が存在します。
 「企業の要求する機能がそろっているか」などという意見が出てきそうですが、全く違います。最終的にはその言語や技術が面白いか否かです。この点を勘違いしてはいけません。いくら必要な機能を山ほど積み込んでも、面倒であったり面白くないものは邪険にされます。例えば3.0以前のEJBはその代表的な存在です。技術や言語はまず面白く魅力的でなくてはなりません。面白く魅力ある技術や言語には開発者が集まり、自然にコミュニティも大きくなります。仮にその言語が重要な汎用的処理APIを提供していなかったとしても、誰かが必ず標準となるものを作ってくれます。つまり、一言で言い表すなら、面白くない言語に存在する意味はないのです。企業の都合だか何だかで面白くもない言語を作ったところで、経団連におもねるのと何ら変わりません。開発者には相手にされないことでしょう。
 ともかく、.NET戦略だの何だのはどうでも構いませんが、C#は面白そうです。何としても習得したいものです。そこで何とか入手したのが「Mono」でした。これはNovell開発の無償で利用できる.NETコンパイラ及びランタイムであり、C# 3.0の多くの機能に対応しています。言語が英語であり、MS純正品ほど統合した環境を提供していないというデメリットこそありますが、C#を覚える分には何ら問題はありません。
 ちなみに導入方法は極めて簡単で、Monoのサイトからインストーラをダウンロードして実行するだけです。英語など読む必要もありません。インストール終了後には、スタートメニューの「Mono-(Version) for Windows」フォルダ内に「Mono-(Version) Command Prompt」ショートカットが登録されますので、これを実行します。
 これの実体はバッチファイルで、環境変数PATHにmonoのbinディレクトリを設定する効果を持っています。つまり、binディレクトリにあるバッチファイルなりexeなりの名前を指定するだけで、そのプログラムを実行できるようになります。
 それではコマンドをいくつか。
最新版 C# のコンパイル
smcs filename

旧バージョンのコンパイル
gmcs filename
mcs filename

Visual Basic のコンパイル
vbnc filename

旧バージョンのコンパイル
mbas filename

JScript のコンパイル
mjs filename

DLL の登録(標準以外のライブラリを使う際に必要)
gacutil -i dll_file

exe ファイルの実行(CLR)
mono exe_file
 コマンドプロンプトで作業できる辺りがJavaライクで面白いです。せっかくですからMonoに.NETコンパイル用Antも同梱してはもらえないでしょうか。
 さて、首尾よくC#を導入できたら、今度はC#の言語仕様を学ばなければならないのですが、これが実にすさまじく簡単です。C#に限らず、JavaといいPHPといい簡単なのですから。現代のプログラマは幸せです。
 それでもC#やJavaのどこが簡単なのか分からないとおっしゃる皆様、以下の黒魔術を習得するのとどちらがマシでしょうか。
void parse(int data[][2][2] , int max){
	for(int i = 0; i < max; i++){
		int (*d)[2] = data[i];
		int value = d[0][0];
		for(int d3 = 0; d3 < 2; d3++){
			for(int d2 = 0; d2 < 2; d2++){
				d[d2][d3] = value;
				value *= 2;
			}
		}
	}
}

void main(){
	int data[][2][2] = {
		{
			{1 , 0} ,
			{0 , 0}
		} , {
			{4 , 0} ,
			{0 , 0}
		} , {
			{16 , 0} ,
			{0 , 0}
		}
	};

	parse(data , 3);

	int *p = (int*)data;
	int sum = 0;
	for(int i = 0; i < 12; i++){
		sum += p[i];
	}

	printf("%d" , sum);	// 315
}
 ざっとポインタ及び配列の用例を示しただけですが、これだけで少々意味不明になっています。その点、C#やJavaは非常に恵まれた言語なのです。
 C#言語は当初「Javaの模倣」と言われただけはあり、非常にJavaに似ています。つまり、Javaさえ覚えていればC#も簡単に習得できます。さらに、C++から持ってきたらしい構文が非常に多いのも特徴です。
// クラスの継承記述及び親コンストラクタ呼び出し
// C++
class Child : public Parent{
public:
	Child(int);
};
Child::Child(int i) : Parent(i){
}

// Java
public class Child extends Parent{
	public Child(int i){
		super(i);
	}
}

// C#
public class Child : Parent{
	public Child(int i) : Parent(i){
	}
}
 ということで、C++を覚えていると非常に通りが良いのです。苦労して習得しておいて助かりました。C#では多重継承は禁じられていますが、「class Class : ClassA , InterfaceB」といった具合にC++の構文で継承クラスとインタフェースを並べることができます。クラスとインタフェースの両方を継承する場合には、クラスを1番前に置くようです。多重継承ができませんので、virtual継承はなくなっています。また、C++ではあまり必要とされていなかったためか、private及びprotected継承の構文はないようです。
 メソッドには仮想メソッドが存在し、C++同様に仮想メソッド(仮想関数)でないメソッドを親クラス型から呼び出すことはできません。さらに、仮想メソッドを継承する際にはoverride、継承しない際にはnew宣言を付加し、開発者の意図を明確にしなくてはなりません。
public class Knight{
	// 武器はクラスによって変更したいため、仮想メソッドにする
	public virtual string GetWeapon(){
		return "剣";
	}
	// 分類はクラス型のものを用いるようにする
	public string GetClassified(){
		return "ナイト";
	}
}
public class DualKnight : Knight{
	// 継承するので override 宣言をしなければならない
	public override string GetWeapon(){
		return "大剣";
	}
	// new 宣言で継承しないメソッドであることを明示
	public new string GetClassified(){
		return "デュアルナイト";
	}
}

// 実行コード
Knight knight = new DualKnight();
Console.WriteLine(knight.GetWeapon());	// 大剣
Console.WriteLine(knight.GetClassified());	// ナイト
 また、純粋仮想関数を作ることもできます。この場合、C++のようにvirtualメソッドに0を代入するのではなく、Java同様にabstract宣言でメソッドを定義します。
// Developer クラス
// この時点では抽象的で、どのような言語を使う開発者かは分からない
abstract public class Developer{
	public abstract string GetLanguage();
}
// OOPDeveloper クラス
// OOP なのは分かったが、どのような言語なのかは分からない
abstract public class OOPDeveloper : Developer{
}
// CSharpDeveloper クラス
// C# を使えることが具体化
public class CSharpDeveloper : OOPDeveloper{
	public override string GetLanguage(){
		return "C#";
	}
}
 abstract宣言にはvirtualが内包され、abstractとだけ書けばvirtualとみなされます。abstractメソッドを含むクラスはabstractクラスになります。
 abstractクラスは継承して使うことが前提ですが、たとえこれを継承したとしても、継承先でabstract宣言されたメソッドを実装しない限り、抽象ではないクラス(concrete)にすることはできません。この辺りはJavaやC++と全く変わりません。
 一方、C#では抽象メソッドを実装する場合でもoverride宣言を書かなくてはなりません。オーバーライドすることなど分かりきったことですが、書かなくてはならないものは仕方がありません(ただしインターフェイスでは違います。詳しくは後述)。
 その代わり、C#ではどれが仮想関数か分からなくなる状態は回避できます。C++ではvirtual宣言された関数は子孫でも永久にvirtualされるのですが、次のような場合はそれが明確でなくなることがありました。
class Parent{
public:
	virtual void Function();
};

class Child : public Parent{
public:
	// virtual を書かなくても暗黙のうちに virtual
	void Function();
};

class GrandChild : public Child{
public:
	// したがって、これも仮想関数
	// ...なのだが、Child を見るだけでは分からない
	void Function();
};
 C#ではこのようになります。
public class Parent{
	// 仮想メソッド
	public virtual void Function(){
	}
}

public class Child : Parent{
	// override がついているので、virtual メソッドの継承であると分かる
	public override void Function(){
	}
}

public class GrandChild : Child{
	// これも virtual メソッドの継承であることが分かる
	public override void Function(){
	}
}
 それから、忘れてはならないのがアクセサ機能です。これはプロパティに干渉するメソッドとでも呼ぶべきもので、JavaBeansのget/setに相当します。
// 市民
public class People{
	private string name;
	private string nation;
	// 名前
	public string Name{
		get{
			return name;
		}
		set{
			// value にはセットされた値が入っている
			name = value;
		}
	}
	// 国
	public string Nation{
		get{
			return nation;
		}
		set{
			nation = value;
		}
	}
}

// 呼び出し方
People p1 = new People();
p1.Name = "Ada Smalltalk";
p1.Nation = "USA";

People p2 = new People();
p2.Name = "配 孫";
p2.Nation = "China";

People p3 = new People();
p3.Name = "四都 蘭";
p3.Nation = "Japan";
 このように、アクセサにはプロパティと同様にアクセスできます。その際にはアクセサの記述が呼び出されるため、値の正当性チェックなどを行うことができます。また、get及びsetのどちらか片方を書かないことも可能であり、getだけ書けば読み取り専用、setだけなら書き込み専用のアクセサとなります。
 さらに、アクセサはオーバーライドしたり、抽象化したりすることが可能です。先ほどの「市民」クラスを継承して開発者を作ってみましょう。
// 言語のリストを取得するインターフェイス
public interface DevelopmentSkill{
	// 抽象アクセサ
	List<string> Languages{
		get;
	}
}
// 開発者
public class Developer : People , DevelopmentSkill{
	private List<string> languages;
	public List<string> Languages{
		get{
			return languages;
		}
		// インターフェイスで義務付けられているのは get のみだが
		// 任意で set を実装しても構わない
		set{
			languages = value;
		}
	}

	public Developer(){
		languages = new List<string>();
		languages.Add("C++");
		languages.Add("C#");
		languages.Add("Perl");
	}
}

// 使い方
Developer d = new Developer();
List<string> langs = d.Languages;

foreach(string lang in langs)
	Console.WriteLine(lang);
 なお、基底クラスと派生クラスで同じ名前のアクセサを作る場合、メソッド同様にvirtualとoverride宣言が必要です。オーバーライドしないこともできますが、その場合はnew宣言が必要です。
 上記ソースではついでにインターフェイスも使用してみましたが、Javaのインタフェース及びC#のabstractのみのクラスとは次の点で違いがあります。

・Javaではインタフェースのメンバにpublicやabstractをつけることができたが(自動的にabstractかつpublicになるため、宣言しても意味はない)、C#ではしっかりエラーを出してくる
・インターフェイスを継承したクラスでは、継承したメソッドやアクセサなどにoverride宣言が必要ではなく、つけるとエラーが出る
・メソッドとアクセサの他、イベントとインデクサの宣言も含むことができる(インデクサとはoperator []のようなもの。イベントは関数ポインタのようなものであるが、「イベントの宣言」とは関数ポインタの引数型と返り値をtypedefするようなもの)
・Javaと違い、定数を宣言することはできない
・複数のインターフェイスから同じ名前のメソッドその他をそれぞれ継承することができる

 まずイベント宣言について軽く解説しておきましょう。C++に例えるなら、イベント宣言とはこのようなものです。
// 関数ポインタ型(イベント)を宣言するクラス
// ここでは int(int,int) の関数ポインタに Type という名前をつけている
template<class T> class FuncPointer{
public:
	typedef int(T::*Type)(int,int);
};

// 何でも良いので適当なクラス
class Calc{
public:
	// int(int,int) の関数
	int plus(int a , int b){
		return a + b;
	}
};

void main(){
	// 後は簡単に使用できる
	FuncPointer<Calc>::Type fp = &Calc::plus;
	Calc c;
	Calc *p = &c;
	printf("%d" , (p->*fp)(10 , 20));
}
 これが上記より簡単に行えます。
 もう1つ、同名のメソッドを複数継承する方法も記述しておきましょう。例えば次のようなクラスを考えてください。
// 好きな食物を取得するインターフェイス
public interface Foods{
	string GetLike();
}

// I(私) クラス
public class I : Foods{
	string GetLike(){
		return "コーヒー";
	}
}
 これは見たままでしょう。Iのインスタンスに対してGetLike()を呼び出すのは、「あなたの好きな食べ物は何ですか?」と聞くのと同じです。
 しかし、人間たるもの、好きなものなど色々あるのが普通です。
public interface Foods{
	string GetLike();
}
public interface ProgramLanguages{
	string GetLike();
}
public interface MusicGenres{
	string GetLike();
}

public class I : Foods , ProgramLanguage , MusicGenres{
	public string GetLike(){
		// ...
	}
}
 さあ、私は一体何と答えれば良いのでしょうか。「好きな食べ物は?」「好きな言語は?」「好きな音楽の種類は?」の3つの質問に対して、1つの答えしか返せないのです。これでは何とも答えようがありません。
 そこで、各インターフェイスのメソッドをそれぞれ継承する方法を用います。
public interface Foods{
	string GetLike();
}
public interface ProgramLanguages{
	string GetLike();
}
public interface MusicGenres{
	string GetLike();
}

public class I : Foods , ProgramLanguages , MusicGenres{
	string Foods.GetLike(){
		return "コーヒー";
	}
	string ProgramLanguages.GetLike(){
		return "C#";
	}
	string MusicGenres.GetLike(){
		return "フォーク";
	}
}

// 使い方
// それぞれキャストなしに呼び出すことはできない
I person = new I();
Console.WriteLine(((Foods)person).GetLike());
Console.WriteLine(((ProgramLanguages)person).GetLike());
Console.WriteLine(((MusicGenres)person).GetLike());
 その他、sealedなる宣言も存在します。これはJavaのクラスやメソッドに対するfinalと同じもので、クラスをsealedすると継承できなくなりますし、メソッドをsealedするとオーバーライドできなくなります。ちなみに、C#ではvirtualされていないメソッドはそもそもオーバーライドできず、継承を許可するvirtualと継承を阻止するsealedを同じメソッドにつける行為には全く意味がありません。new宣言されているメソッドはオーバーライドではないことを明示しているわけですから、こちらもsealedする意味はありません。つまり、sealedをつけられるメソッドはoverrideメソッドのみということになりますが、その際にはoverrideの前にsealedと書く(public sealed override type Method())ようです。
 これでC#のクラス周りの仕様はおおむね全部でしょうか。C++に比べればかわいいものです。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

- Blog by yamicha.com -