Moonmile Solutions Blog

月7$ 払って github にプライベートレポジトリを作ればいいんだけど、その前にお試し的に Bitbucket で作って運用してみるテスト。大抵の場合は、面倒なので public で github で作ってしまえばいいのだが、ちょっと内部的なのだと非公開で作りたいときもあるので、メモとして。

既存のものからアップロードしようとしたり、あれこれやったんだけど、なんかうまくいかない。したかがない（？）ので、Bitbucket の手順に従ってちまちまやるのが一番手っ取り早いです。

リポジトリの作成から、新規リポジトリの作成

新しいリポジトリが作成できたら、コマンドラインの「私はゼロからスタートします」をコピペしながら実行する。「SourceTreeにクローン」のほうは、Firefox で動かなかったので

mkdir /path/to/your/project
cd /path/to/your/project
git init
git remote add origin https://moonmile@bitbucket.org/moonmile/sample.git

git init と git remote を使って、新規作成したレポジトリをローカルの PC に作れば ok.

あとは、ローカル PC で、Visual Studio でプロジェクトを作るとか、他に保存してあるプロジェクトをコピーするとかして、commit, push すればよい。

他の PC や Mac では git clone すればよいので、これでコードの同期が簡単にできる。

アリスはリフレクションがお嫌い | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/8092

の続きで、属性／アノテーションの話を追記。

リフレクションはクラスに対して static な情報だということが解ったら、じゃあ「属性」ってのも static な情報というのが分かるので、このあたりは同根なんだなというのが分かる。ケント・ベック氏の「テスト駆動開発入門」に、とあるプログラム言語を学ぼうとしたときに自動テストツール（xUnit）を書いてみると、パターンが網羅されていて学びやすい、ということが書いてある。実際、xUnit のツールにはデザインパターンが多く使われていて、その実現をそれぞれのプログラム言語がどうやって実装しているのかというのを見ることができる。
よくあるテストメソッドとテストクラスの情報収集の方法に

– C++ の場合は、あらかじめ登録が必要
– Java の場合は、先頭にTestがくっついている
– C# の場合は [TestMethod] 属性を付ける

という違いがある。今だともうちょっと違っているけど、初期のころの xUnit のコードを見ると、その当時の文法で駆使されていて、その後にちょっとずつ他の言語の流儀が取り入れられているのが分かります。
C++ の場合は、リフレクションがないので、テストメソッドをいちいち登録するしかない…けど、テンプレートを駆使して明示的には登録しているようにみえないけど、実は登録してるって方法を取ってる。

TEST_CLASS(UnitTest1)
{
public:
	TEST_METHOD(TestMethod1)
	{
		auto m = new Prada();
		m->setStyle(10);
		m->setColor("Pink");
		auto plist = m->properties;
		for each ( auto prop in plist )
		{
			auto n = prop.first;
			auto v = prop.second;
			void*x = v(m);
		}
	}
};

最近の VC++ でテストプロジェクトを作ると、TEST_CLASSとTEST_METHODというマクロが定義されていて、うまく登録できるようになっている。

初期の Java の場合は、属性／アノテーションがなかったので、実行したいテストメソッドと普通のメソッドを区別するために、メソッドの先頭に「Test」とつけておく。でもって、リフレクションを使って先頭が Test になっているメソッドだけを実行するという方式をとる。
これは、結構シンプルでよいのだけど、メソッドの名前自体に意味を持たせてしまうのが、なんだかなーという感じだったので、最近の JUnit では、「@Test」というアノテーションが付けられる。

public class JunitExampleTest {

    @Test
    public void testFoo() {
		JunitExample example = new JunitExample();
        assertEquals(1, example.foo())
    }
}

Java の後発になる C# の場合は、リフレクションだけでは足りないとみて、属性（Attribute）というのものを付けている。実際の使い方はアノテーションと同じだ。

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void TestMethod1()
    {
        var m = new Prada { Style = 10, Color = "Pink" };
        var ti = m.GetType().GetTypeInfo();
        var plist = ti.DeclaredProperties;
        foreach (var prop in plist)
        {
            var n = prop.Name;
            var v = prop.GetValue(m);
            Debug.WriteLine($"prop: {n} value: {v}");
        }
    }
}

当初、属性というものが使われていたときに、他の言語にはアノテーション自体の機能がなかったのと、アスペクト指向が流行り始めていて、そのアノテーション（装飾）と区別がつかなかったという経緯もあって、なんかいまいちな言語仕様な感じがしたのだが、MVCパターンのように動的に Action メソッドを呼び出すようなスタイルを考えたとき、ちょっと便利に使える。

[Produces("application/json")]
[Route("api/People")]
public class PeopleApiController : Controller
{
    private readonly ApplicationDbContext _context;

    public PeopleApiController(ApplicationDbContext context)
    {
        _context = context;
    }
    // GET: api/People
    [HttpGet]
    public IEnumerable<Person> GetPerson()
    {
        return _context.Person;
    }
    // GET: api/People
    [HttpGet]
    [Route(&quot;search/name/{value}&quot;)]
    public IEnumerable<Person> GetPersonByName([FromRoute] string value )
    {
        return _context.Person.Where( t => t.Name.Contains(value));
    }
    // GET: api/People
    [HttpGet]
    [Route(&quot;search/age/{value}&quot;)]
    public IEnumerable<Person> GetPersonByAge([FromRoute] int value)
    {
        return _context.Person.Where(t => t.Age >= value);
    }

これは、ASP.NET MVCアプリケーションのルーティングのテスト用に作ったサンプルコードだが、たくさんの属性が使われている。要は、クラスに対して static な情報を属性に詰め込めばよいので、Produces属性でJSON形式を返すとか、Route属性でURL呼び出しの形式を設定するとか、HttpGet属性でGETメソッドだけに呼び出しを限るとかの設定ができる。
これらの情報はDI（インジェクション）という形で、設定ファイルなどに追い出すことも可能なのだが、そもそも設定ファイルとこのControllerクラスが1対1になっているのだったら、その「設定」自体をコードで書こうと外部の設定ファイルに書こうと意味は同じはずだ。ならば、属性で、ということになる。当然、コードに埋め込まれてしまう欠点もあって、ちょっとだけルーティングを変えようと思っても、このコードを変えないといけないので、そういう場合は DI のように設定自体を外付けしてしまったほうがよい。
これは、属性とDIのどちらがいいという話ではなくて、利用するときの状況によりけり、というパターンかなと思っている。一般的な使い分けとしては、コーディング時に決定してしまうもの（あとからの設定では変えられないもの、代替できないもの）は属性に、動作環境によって変わるもの（データベースの接続文字列とか）は設定ファイルに出せばよい。

属性を使わないで実装する

じゃあ、本題として、ルイスはアリスが属性／アノテーションが嫌いだから、属性を使わないで自前で実装するんやという話になっているので、ASP.NET MVC っぽい Action メソッドの呼び出しをどうやって実装するのかを考えてみる。初期の JUnit のように諸々の規約をメソッド名に追加してもよいのだが、あれこれ設定するのは大変だ。

class AliceAttribute : Attribute { }
class DefaultAttribute : Attribute
{
    public string Name { get; set; }
}
[Alice]
class Prada
{
    public int Style { get; set; }
    [Default(Name = "White")]
    public string Color { get; set; }
}

こんな風な Alice 専用の Prada クラスを作ってみる。クラスの属性に「Alice」を付けておくと、Alice 専用のクラスという訳だ。ついていない場合は、普通のクラス。
あと、デフォルトの値を設定できるように、Default属性を作ってみる。

public void TestMethod3()
{
    var m = new Prada { Style = 10, Color = "Pink" };
    var ti = m.GetType().GetTypeInfo();

    var attr1 = ti.GetCustomAttribute<AliceAttribute>();
    var attr2 = ti.GetProperty(&quot;Color&quot;).GetCustomAttribute<DefaultAttribute>();

    Debug.WriteLine($&quot;prop: Color attr: {attr2.Name}&quot;);

}

C# での属性呼び出しは、GetCustomAttributeメソッドを使えばよい。GetCustomAttributeで null が返ってきたら属性が設定されていないという訳で、Alice 属性がついているかどうかが分かる。全ての属性を取りたい場合は、GetCustomAttributes メソッドを使うが、どんな属性にも対応するということはないのであまり使わないだろう。クラス特性を調べるときとかに使うかな。
Default 属性で設定した Name プロパティは、そのまま属性オブジェクトの Name プロパティで見れる。この属性オブジェクトが、クラスやメソッドに設定したときにクラス情報と一緒にくっついてくるというイメージでよい。結局のところ、GetTypeInfoメソッドを呼び出してクラス情報を取るので、リフレクションと同じ方式になる。

これを C++ で書き直してみると、

class AliceAttribute {};
class DefaultAttribute {
public: 
	std::string Name;
	DefaultAttribute(std::string &name) { this->Name = name;  }
};

class Prada2 {
private:
	int _style = 0;
	std::string _color = "";
public:
	int getStyle() { return _style; }
	void setStyle(int v) { _style = v; }
	std::string getColor() { return _color; }
	void setColor(std::string v) { _color = v; }
public:
	static AliceAttribute *Alice;
	static DefaultAttribute *DefaultColor;
	Prada2() {
		Prada2::Alice = new AliceAttribute();
		Prada2::DefaultColor = new DefaultAttribute(std::string("White"));
	}
};
TEST_CLASS(UnitTest2)
{
public:
	TEST_METHOD(TestMethod1)
	{
		auto m = new Prada2();
		m->setStyle(10);
		m->setColor("Pink");

		auto alice = m->Alice;
		auto color = m->DefaultColor->Name;
	}
};

適当な属性クラス（AliceAttribute、DefaultAttribute）を用意して、Prada2クラスの static メンバとして設定しておく。汎用的に作る場合は、リフレクションのときと同じように map を使うのだが、クラス自身の属性とメンバの属性があるので2つ作らないといけないのがちょっと面倒…だけでも、まあできないことはない程度にはわかるだろう。

逆にいえば、クラスの情報として、static で設定しているメンバ変数は属性に置き換えられる、ということだ。リフレクションを使うので、呼び出し側でひと手間かかるが、この設定の命名規約があれこれと悩むよりも、Attribute クラスを適当に作ってしまって属性に対する設定のほうで、あれこれと変えるということもできるということだ。
そういう意味で、

– クラスが外部公開する const 変数
– 属性
– DI の設定

を使い分けていくことになる。

長年使っていた Perl+C# の WordPress 投稿ツールを、.net core を機会に F# に直そうとしている途中なのですが、そのなかでふと、リフレクションを使わずに XML-RPC を実装するのはさぞしんどいことではないか？
ということに思い至りました。いや、もともと使っていた XMLRPC.NET はインターフェース形式なのであれこれとややこしくなっているんですよね。そのあたりで使い勝手が悪くなってしまっているのと、ストレス発散ののためにも F# で書き直しをしています。

実は、MVCパターンのControllerの呼び出しにもリフレクションが使われます。ブラウザから呼び出されたURLアドレスからActionメソッドの呼び出しがそれで、Controllerクラスのメソッドをあらかじめ登録しているのではなくて、実行時にメソッドを探します。ASP.NET MVC だといちいちコンパイルをしないと駄目だけど、CakePHPのようなパターンだと動的言語なのでスクリプトを直接修正することができます。

そんなわけで、XML-RPC だと

class Prada
{
    public int Style { get; set; }
    public string Color { get; set; }
}

なクラスを

<struct>
  <member>
    <name>Style</name>
    <value>
      <int>10</int>
    </value>
  </member>
  <member>
    <name>Color</name>
    <value>
      <string>Pink</string>
    </value>
  </member>
</struct>

な風にXML形式に直します。実際はmethodCall要素があったり、今だったらJSON形式のほうが楽だろうってことなんですが、WordpressにXMLRPCで投稿すると楽なので自作ツールを作って使っています。

リフレクションを使う

じゃあ C# でXML形式に直すことを考えると、PradaクラスのStyleプロパティとColorプロパティをどうにかして持ってこないといけないので、プロパティを列挙するリフレクションを使えばいいんだね、ということになります。

using System.Reflection;

public void TestMethod1()
{
    var m = new Prada { Style = 10, Color = "Pink" };
    var ti = m.GetType().GetTypeInfo();
    var plist = ti.DeclaredProperties;
    foreach (var prop in plist)
    {
        var n = prop.Name;
        var v = prop.GetValue(m);
        Debug.WriteLine($"prop: {n} value: {v}");
    }
}

こんな風に、GetTypeInfoメソッドでクラス情報を取ってきて、DeclaredPropertiesコレクションでプロパティの一覧を取得、その後で名前と値を取ってきます。GetValueメソッドで取ってきたものは object 型なので、実際に利用するときは元の型に戻さないといけません。型自体は、PropertyType プロパティで取って来れるので、これをそれぞれの型と is 演算子で比較するか、乱暴な場合は as でキャストしてしまいます。
XML-RPCのときは最終的に文字列に直してしまうので、ToString で代用させています。

ちなみに、F# で書くとこんな感じになります。

type Prada() =
    member val Style = 0 with get, set
    member val Color = "" with get, set

[<TestMethod>]
let TestMethod1() =
    let m = new Prada( Style=10, Color=&quot;Pink&quot; )
    let ti = m.GetType().GetTypeInfo()
    let plist = ti.DeclaredProperties
    for prop in plist do
        let n = prop.Name
        let v = prop.GetValue(m)
        System.Diagnostics.Debug.WriteLine(String.Format(&quot;prop: {0} value: {1}&quot;, n, v ))

この列挙したプロパティを使って XML 形式に直すわけですが、そのあたりは XElement を使うと楽にできるので、ちょっと省略。

で、アリプラの本題にいきます。
これって、リフレクションを使うと「クラス情報」を取れることになるけど、内部実装的にはどうなっているんだろうか。いや、そもそも、C++ のようなクラス情報を持たない言語の場合は、どうやって実装すればいいんだろうか？

という話になります。クラス情報なんだから、クラスに紐づいているわけで、new で作成したオブジェクトとは別ですよね。なので、いくつもオブジェクトを作ったとしても、クラス情報とかプロパティの型とかは一種類しかないわけです。Javascriptのようにプロトタイプで後からどんどん付け加えていくというパターンもあるので、プロパティやメソッドが固定というわけではないけれど（実装的には、後付け用のコレクションを用意するわけだし、dynamic型みたいな感じになる）、もともとの固定のプロパティやメソッドをどうやって扱おうかということになります。

リフレクションもインターフェースも使わないで実装する

なので、アリスは「リフレクション」も「インターフェース」も嫌いなので、ルイスは何か別の方法で実装しなければいけません。本来ならば、インターフェースを作ってという話になるけど、できるだけリフレクションっぽい形にしたい。あと、クラスの属性のように付加情報も取り入れたい。

class PradaNew
{
    public static string ClassName = "PradaNew";
    public static Dictionary<string, Func<PradaNew, object>> Properties =
        new Dictionary<string, Func<PradaNew, object>>
    {
        {&quot;Style&quot;, m => m.Style  },
        {&quot;Color&quot;, m => m.Color }
    };
    public int Style { get; set; }
    public string Color { get; set; }
}

そんな訳で、ルイスは「PradaNew」クラスを作って、付加情報を独自に追加しました。なんか、それっぽい形で取れるように、クラス名と、プロパティ名を渡すと値が取れるような仕組みを作っておきます。
両方とも static プロパティなので、クラスのみに紐づいた情報になりますね。

でもって、PradaNew を使ったリフレクションっぽい形の例がこっち。

public void TestMethod2()
{
    // リフレクションを使わないパターン
    var m = new PradaNew { Style = 10, Color = "Pink" };
    var ti = m.GetType().GetTypeInfo();
    var plist = PradaNew.Properties;

    foreach (var prop in plist)
    {
        var n = prop.Key;
        var v = prop.Value(m);
        Debug.WriteLine($"prop: {n} value: {v}");
    }
}

プロパティ名を Key で、値のほうを Value で取ってくるのが多少乱暴ですが、先のリフレクションと同じようなスタイルになります。
ここにクラスの属性として「HttpGet」とか加えたいときも、ClassName プロパティのように static なプロパティを追加すれば ok ですね。static なプロパティなので、オブジェクトが大量に増えてもメモリは増えません。また、値を取ってくるところは適当にキャッシュしてやれば、通常のメソッド呼び出しと遜色ないスピードが出せそうだということがわかります。

これを、ちょっと C++ で直してみます。

#include <map>
#include <functional>

class Prada {
private:
	int _style = 0;
	std::string _color = &quot;&quot;;
public:
	int getStyle() { return _style; }
	void setStyle(int v) { _style = v; }
	std::string getColor() { return _color; }
	void setColor(std::string v) { _color = v; }

public:
	const std::string className = &quot;Prada&quot;;
	static std::map <std::string, std::function<void*(Prada*)>> properties;

	Prada() {
		auto func = [](Prada* m) { auto v = m->getStyle(); };
		Prada::properties.insert(std::make_pair(std::string(&quot;Style&quot;), [](Prada* m) { auto v = m->getStyle(); return &v; }));
		Prada::properties.insert(std::make_pair(std::string(&quot;Color&quot;), [](Prada* m) { auto v = m->getColor(); return &v; }));
	}
};
std::map <std::string, std::function<void*(Prada*)>> Prada::properties;;

int main()
{
	auto m = new Prada();
	m->setStyle(10);
	m->setColor(&quot;Pink&quot;);
	auto plist = m->properties;
	for each (auto prop in plist)
	{
		auto n = prop.first;
		auto v = prop.second;
		void* x = v(m);
		// void* から元の型へ戻すには？
	}
	return 0;
}

元の型に戻すのには、プロパティの型を調べる必要があるので、もう少し手を入れないといけないけど、だいたいはこんな感じ。map にしてラムダ式を返すようにしたのでややこしいことになっていますが、構造体を作ってプロパティの型を調べるところと、値を取得するところを作ったほうが楽かも。

まあ、こんな実装は普通はしないわけで、内部的にはこんなことになっているなーと思いつつ、リフレクションを道具として使うとよいのではと思った次第。