パラメタでルーティングがしたい(ASP.NET)

こんにちは。

11月11日です。
ポッキー食べましたか？
世の中真っ直ぐな食べ物なんてたくさんあるのに、確固たる地位を築いているのはすごいですね。

ちくわ&ちくわぶの日だっていいし、なんならそうめん&スパゲティの日だっていいわけです。
でももうポッキー&プリッツの日です。広まったら勝ちです。強い。

さて、今日はASP.NETのお話。
.NET Coreでもできるかもしれないけど、とりあえず.NET Frameworkということで。

ルーティングを設定しよう

VisualStudioで「ASP.NET Webアプリケーション(.NET Framework)」のプロジェクトを作成すると、
自動的にこんなRouteConfig.csが作成されます。

public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}

で、Controllerを作ってあげてlocalhostにアクセスすると(書くの面倒なので、ポート番号は脳内で補完していただくということで)、
デフォルトのルーティング設定が読み込まれて無事にHomeControllerのIndexメソッドが呼ばれるわけですね。

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return Content("Index");
    }
}

次にHomeController にメソッドを追加して、localhost/Home/Hoge/にアクセスしてみると、
今度はHomerControllerのHogeメソッドが呼ばれますね。

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return Content("Index");
    }
    
    public ActionResult Hoge()
    {
        return Content("Hoge");
    }
}

パスじゃなくてパラメタでアクションを設定したいのだ

そんな場面あるかい！って言われてしまったら終了なのですが、
URLのルールを変えられないなんてことは稼働中のサービスとかだとあるんですよ。
え、ない？まぁまぁそう言わず…。

とりあえずMapRouteに引数でパラメタって設定できないのかなとか見てみると、
制約をつける「constraints」と名前空間を指定する「namespace」しかありませんでした。そりゃそうか。

とりあえず、他にもパラメタはあるだろってことは完全に無視してこんなルーティングを追加してみます。

routes.MapRoute(
    name: "Hoge",
    url: "?action=Hoge",
    defaults: new { controller = "Home", action = "Hoge" }
);

はい、だめでした。

いやそもそも「defaults」って書いてあるくらいなんだから、
ルーティング設定なんて追加しなくてもパラメタに「controller」と「action」を指定して、
localhost?controller=Home&action=Hogeとかにアクセスしてあげれば…。

当たり前ですが、パラメタとは別管理です。

しょうがないので自分でルーティングしよう

とりあえずActionが実行される前になにかの値を差し替えてしまえばいけそうなので、
OnActionExecutingをoverrideして、ActionExecutingContextの中身を覗いてみると…

「RouteData」というのが多分ルーティングの設定でしょう。
ということは、こんな感じで書けば。

protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
    var parameter = filterContext.HttpContext.Request.Params;

    if (parameter.AllKeys.Contains("action"))
    {
        filterContext.RouteData.Values["action"] = parameter["action"];
    }

    base.OnActionExecuting(filterContext);
}

だめでした。
ExecutingってことはもうActionがExcuteされてるんですかね。
じゃあこれならどうだ。

protected override IAsyncResult BeginExecute(RequestContext requestContext, AsyncCallback callback, object state)
{
    var parameter = requestContext.HttpContext.Request.Params;

    if (parameter.AllKeys.Contains("action"))
    {
        requestContext.RouteData.Values["action"] = parameter["action"];
    }

    return base.BeginExecute(requestContext, callback, state);
}

やったー。

というわけで

BeginExecuteでRouteDataを差し替えてあげれば、Actionは自分で決められるようです。

他にもっと簡単な方法はあるんでしょうか？
誰か教えてくださいまし。

nullチェックしたらNullReferenceException

こんにちは。

秋ですね。
ようやく暑さも収まりましたが、体調が安定しません…。

なんだか謎掛けみたいなタイトルですが、
変な罠に引っかかりそうになったので備忘録。

なぞなぞ

nullチェックするようなロジックを書くべきではないとかいう話はまぁちょいちょいありますが、
個人的にはnull自体はそんなに嫌いではないです。

いやべつにNullableとかOptionalを否定する気はないですけど。
null条件演算子とかnull合体演算子とかもありますしね。

で、まぁこういうコードよく書きますよね。

var hoge = GetHoge();
if (hoge != null) 
{
    hoge.Fuga();
}

このコードでFugaの呼び出しの際にhogeがnullでNullReferenceExceptionが発生するのはどんなときでしょう？

なんかJSのクイズでたまに見る次のコードで「false」がアラートされるaを答えなさいみたいな感じがありますが。

if (a === a) {
    alert("true");
} else {
    alert("false");
}

正解はHogeの「==」「!=」を演算子オーバーロードをミスって書いたときです。
ちなみにJSの方の答えは「NaN」ですね。

演算子オーバロードって

演算子オーバーロードについては前に記事を書きましたので詳しくはこちらをどうぞ。
shironeko.hateblo.jp

たとえばプロパティを一つだけ持つクラスの場合、
こんな感じで演算子オーバーロードを書きたいですよね。

class Hoge
{
    public int Piyo { get; }

    public Hoge(int piyo)
    {
        this.Piyo = piyo;
    }

    public static bool operator ==(Hoge a, Hoge b)
    {
        return a.Piyo == b.Piyo;
    }

    public static bool operator !=(Hoge a, Hoge b)
    {
        return a.Piyo != b.Piyo;
    }
}

が、これをnullと比較すると第二引数にnullが入ってきて死ぬわけです。
（演算子オーバーロードは左右を意識するので、null == ～って書くと第一引数側で死にます）

public static bool operator ==(Hoge a, Hoge b)
{
    if (a == null && b == null)
    {
        return true;
    }
    else if (a != null && b != null)
    {
        return a.Piyo == b.Piyo;
    } 
    else
    {
        return false;
    }
}

public static bool operator !=(Hoge a, Hoge b)
{
    return !(a == b);
}

でまぁこんな感じかなと思って書くと、再帰になってStackOverflowで死ぬわけです。
というわけでこうですね。

public static bool operator ==(Hoge a, Hoge b)
{
    if (a as object == null && b as object == null)
    {
        return true;
    }
    else if (a as object != null && b as object != null)
    {
        return a.Piyo == b.Piyo;
    } 
    else
    {
        return false;
    }
}

public static bool operator !=(Hoge a, Hoge b)
{
    return !(a == b);
}

この辺の書き方を間違えたりすると最初の例のようにnullチェックは通るのに実態はnullでしたみたいなことになるんです。
親クラスで演算子オーバーロードしてたりするとより沼にハマりやすくなります。

そういえば

しれっと順番を意識するのでとか書いたのですが、
二項演算子のオーバーロードでは片側が自分の型であればもう片側は別の型でも問題ありません。

ということはですよ。
こんなふうに書いたらどうなるのっていう疑問がわきます。

class Hoge
{
    public static bool operator ==(Fuga a, Hoge b)
    {
        (略)
    }

    public static bool operator !=(Fuga a, Hoge b)
    {
        (略)
    }
}

class Fuga
{
    public static bool operator ==(Fuga a, Hoge b)
    {
        (略)
    }

    public static bool operator !=(Fuga a, Hoge b)
    {
        (略)
    }
}

結論としてはコンパイル通りませんでした。なんて普通なオチ…。

排他的論理和は^じゃなくて!=でよくない？

こんにちは。
ほんとに、ほんとーに毎日毎日暑いですね。
もうとろけてしまう。

で、なんだか偉い人に怒られてしまいそうなタイトルですが、
論理演算子を条件演算にしか使わないような我々には、
滅多に現れない排他的論理和をググりながら書くよりはいいんじゃないのってお話。

論理演算の種類

論理演算の種類はたくさんあるのですが、実際プログラミングで利用するものはある程度限られています。

論理積（AND）

条件Pと条件Qがあるとき、PとQの両方が真であることを論理積と呼びます。
（true、falseって書いたら読みづらかったので、○×にしますね。）

条件P	条件Q	AND
○	○	○
○	×	×
×	○	×
×	×	×

一般的にプログラミング言語では記号「&」を利用して、

p & q

のように記述します。

また、条件演算に利用する場合には、左から評価するとすれば、
条件Pがfalseの場合には条件Qの値にかかわらずfalseとなるため、短絡評価（ショートサーキット）することができます。
これは一般的にプログラミング言語では記号「&」を二つ重ねて、

p && q // pがfalseの場合、qの評価はしない

のように記述します。
今回の記事では深くはつっこみませんが、パフォーマンスの観点や副作用の観点から、一般的には短絡評価を使うことが多いです。

否定論理積（NAND）

条件Pと条件Qがあるとき、PとQの少なくとも片方が偽であることを否定論理積と呼びます。

条件P	条件Q	NAND
○	○	×
○	×	○
×	○	○
×	×	○

論理積（AND）の反転であることから、一般的にプログラミング言語では否定「!」を利用して、

!(p && q)

のように記述します。

論理和（OR）

条件Pと条件Qがあるとき、PとQの少なくとも片方が真であることを論理和と呼びます。

条件P	条件Q	AND
○	○	○
○	×	○
×	○	○
×	×	×

一般的にプログラミング言語では記号「|」を利用して、

p | q

のように記述します。

また、論理積と同様に、条件Pがtrueの場合には条件Qの値にかかわらずtrueとなるため、短絡評価することができます。

p || q // pがtrueの場合、qの評価はしない

こういうことですね。

否定論理和（NOR）

条件Pと条件Qがあるとき、PとQの両方が偽であることを否定論理和と呼びます。

条件P	条件Q	AND
○	○	×
○	×	×
×	○	×
×	×	○

論理和（OR）の反転であることから、一般的にプログラミング言語では否定「!」を利用して、

!(p || q)

のように記述します。

排他的論理和（XOR）

条件Pと条件Qがあるとき、PとQどちらか片方が真で、もう片方が偽であることを排他的論理和と呼びます。

条件P	条件Q	AND
○	○	×
○	×	○
×	○	○
×	×	×

一般的にプログラミング言語では記号「^」を利用して、

p ^ q

のように記述します。
（Excelの式やVB系では「^」はべき乗の意味で利用されるので注意）

また、条件Pの値が決まっても条件Qの値が決まらないと判定できないため、短絡評価はありません。

否定排他的論理和 （XNOR）

条件Pと条件Qがあるとき、PとQ双方が真または偽であることを否定排他的論理和と呼びます。

条件P	条件Q	AND
○	○	○
○	×	×
×	○	×
×	×	○

一般的にプログラミング言語では記号「^」を利用して、

!(p ^ q)

のように記述…するんですかね？あんまりしない気もしますね。

XORとかXNORって使う？

要するにAND、OR、XORとその反転（否定）があるよって話なのですが、
せっかく演算子まで用意してくれてますけど、「^」ってコード上で見ることあんまりないですよね。

めったに使う場面がないのだから、使えるタイミングでは積極的に使っていこう！っていうのもいいのですが、
自分は分かっても他の人的には混乱するかも？って思うと使いにくいのですよね。

で、そもそもの話、XORの「PとQどちらか片方が真で、もう片方が偽である」
っていうのはPとQの結果が一致していない、つまり、

p != q

なんですよね。

同じように、XNORの「PとQ双方が真または偽である」
っていうのはPとQの結果が一致している、つまり、

p == q

ってこと。

なんかこっちのほうが見慣れてるからいいかなって思うのです。

まぁ、「ここは排他的論理和が正しくない？」とかいったらかっこいいのかもしれないですけどね。
ちなみに「排他的論理積」なんて言葉はないですよ。ですよー。