著者アーカイブ 杉浦

著者:杉浦

言語横断パッケージ検索サービスLibraries.ioの紹介

Libraries.io – The Open Source Discovery Service
Libraries.ioはパッケージ検索サービスです。パッケージ検索自体はよくありますし、大体パッケージマネージャの本元が強すぎて特色を出しにくいです。Libraries.ioは複数言語のパッケージマネージャを横断的に検索できる点で特別です。GitHubの中でリポジトリを探す感じです。

　特に有効的に使えるのは使用言語が自由で特定の目的を達成したい時でしょう。使用言語選定の一評価指標になります。例えば、dxf(図面用のフォーマットの1種。独自フォーマットA->dxf、dxf->独自Bの様に中間形式で使われやすい)で検索すると次のように出ます。

　Go言語やJavaScriptで層が厚そうです。pythonもいくつか選択肢があります。dxfを扱うプログラムを作るなら言語はこのあたりを使った方が手っ取り早くできそう、と判断できます。

著者:杉浦

テーブルと1対1になるモデル以外のモデルを増やす時

　webプログラミングのMVCデザインパターンにおいてモデルとは大体DB（データベース）のテーブルそのものです。しかもモデルとテーブルは1対1のことがほとんどです。これはフレームワークがそう扱った方がやりやすい様に自動生成コマンドやクラス、メソッドを仕込んだり、例を用意しているからというフレームワークの用意した道筋が一因です。これは悪いことでなく実際、簡単なロジックを扱うプログラムならばモデル1つはテーブル1つとした方がシンプルにまとまり直感的なコードで要件を満たすことになり、いいことづくめです。無暗にリポジトリやらエンティティやらの概念を持ち込んで一つのテーブルにアクセスするのに二つ三つもクラスやメソッドを経由させられるより遥かに賢明です。
　しかしデータベースのテーブルと1対1だとどうにも収まりが悪い時があります。

　例えば、1つのユーザアカウントで様々なサービスの恩恵を受けられるプログラムの時です。こういった時、ユーザは何かを購入する、何かにメールを送る、何かを出品する、ブログを書く、などさまざまな操作をします。これらの操作がある上で、usersテーブルは一つだからモデルはUser一つだけ、とするとUserモデルは大爆発します。こういった時には各処理におけるUserモデルである購入者モデル、メール送信者モデル、出品者モデル、ブロガーモデル、を用意して全てusersテーブルに対応させる様にすることで対応できます。
役割駆動設計で巨大クラスを爆殺する – Qiita
　例えば、しょっちゅうまとめて参照されるテーブルがある時です。こういった時は複数のテーブルをselect, joinするクエリを必ず発行するモデルを作ることで対応できます（DB上でview作ってそれを読みこむのもありかも）。エンティティ（参照オブジェクト）の考え方はこういった時、役に立ちます。
【PHP】Adapterパターンであるカラムの値によって大きく振る舞いを変えるテーブルの扱いを多少マシにする – 株式会社シーポイントラボ ｜ 浜松のシステム開発会社
　例えば、そもそもDBを参照しないがデータを参照する時です。ある外部サービスから吐き出されたファイルを読みこんで扱う時にはDBに関係ないモデルを用意してファイルの情報を持たせる様にするべきでしょう。
【Laravel】データベースと無関係のEloquentっぽいモデルを作るためのFluentクラス – 株式会社シーポイントラボ ｜ 浜松のシステム開発会社
　例の様に単にデータを扱うモデルを考えるだけでも、こういった複雑な時にはテーブルと1対1になるモデル以外のモデルを作った方がやりやすいです。
　原義に基づくならばMVCのモデルとは”業務領域のデータと振る舞い”です。データベース設計が優れていてそれで設計が完結できる時は、モデル=DB関連の操作をまとめたモノとするのが正しいし適した形ですが、DB上で扱うとどうにも複雑になる時は”振る舞い”も別途モデル化するのが良いでしょう。
　余談ですが、振る舞いのモデル化はサービス化です。振る舞いの含意は広い為、多くの動作がサービスと言えなくもないです。サービスと定義できるからと何でもかんでもサービス化すると、オブジェクト指向を実現するためのMVCなのにオブジェクト指向から離れて手続きプログラミングと化します。なるべくサービスにせず、より適した場所を見つけたいものです。

著者:杉浦

カプセル化となんちゃってカプセル化のアンチパターン

　カプセル化はオブジェクト指向の中で述べられている手法の一つです。オブジェクトに関する詳しい処理や情報をオブジェクト内部に閉じ込めておき、外部からは必要な分だけのまとまった簡単な部分にのみにアクセスできるようにする方法です。よくある例えに車の例えがあります。運転手はアクセルを踏めるしギアも変えられるが、エンジンのシリンダー一つ一つや空気の流入量を操作することはできない、というものです。これは動力のカプセル化で、車の内部を深く知らず瞬時に燃料の爆発に最適な環境を計算できない多くの人間からエンジン内部の詳しい動作を隠し、まとまった操作であるギアとアクセルにだけアクセスできる様にしています。こうすることで誤った操作を減らし、操作の混乱を防ぎます。
　コーディングにおけるカプセル化は例えば次の様になります。

/**
 * @property-read int    $id    読み取りのみ可能
 * @property      string $mail  読み取りと特定形式の書き込みのみ可能
 * @property      string $name  読み書き自由
 */
class User
{
    private $id;
    private $mail;
    public  $name;
    private $secretProperty;  // 内部処理の何かしらにだけ使う完全に外から隠れるプロパティ

    /**
     * 主キーで検索.
     * @param int $id
     * @return User
     */
    public static function find(int $id): User
    {
        return DB::select()
            ->from('users')
            ->where('id', $id)
            ->first();
    }

    /**
     * 任意のプロパティにまとめて代入. 代入後の$thisと代入予定の引数が一致すればtrue, しなければfalse.
     * @param array $values
     * @return boolean
     */
    public function fill(array $values): bool
    {
        $this->name = $values['name'] ?? $this->name;
        isset($values['mail']) ? $this->setMail($values['mail']) : null;

        return $values === array_intersect_key(['name' => $this->name, 'mail' => $this->mail], $values);
    }

    /**
     * データベースに保存.
     * @return boolean
     */
    public function save(): bool
    {
        return DB::select()
            ->from('users')
            ->where('id', $this->id)
            ->updete([
                'mail' => $this->mail,
                'name' => $this->name,
            ]);
    }

    /**
     * プロパティの読み取り範囲を通常の可視性を超えて操作.
     * @param $propertyName
     * @return mixed
     */
    public function __get($propertyName)
    {
        return $propertyName === 'secretProperty' ? null : $this->$propertyName;
    }

    /**
     * setterがあるプロパティならばprivateでも書き込める.
     * setterがないプロパティならば新規追加も許さない.
     * @param $propertyName
     * @param $value
     * @return bool
     */
    public function __set($propertyName, $value): bool
    {
        $setMethodName = 'set'.ucfirst(camel_case($propertyName));

        return $this->$setMethodName($value);
    }

    /**
     * 存在しないメソッドが呼ばれたらfalseを返す.
     * @param $methodName
     * @param $arguments
     * @return bool
     */
    public function __call($methodName, $arguments):bool
    {
        return false;
    }

    /**
     * 存在するprivateプロパティに対してisset()をかまされた時にtrueを返すために必要.
     * @param $propertyName
     * @return bool
     */
    public function __isset($propertyName): bool
    {
        return isset($this->$propertyName);
    }

    /**
     * メールとして認められる文字列ならばsetして良し.
     * @param $value
     * @return bool
     */
    private function setMail($value): bool
    {
        if(preg_match('/メールアドレスを表す適当な正規表現/u', $value)){
            $this->mail = $value;

            return true;
        }

        return false;
    }
}

　id, mail, nameの三つの要素を持つユーザクラスです。それぞれの可視性と代入時の操作を設定することでカプセル化の利点の誤った操作の軽減を実現しています。プロパティの増減まで縛っているのはわかりやすさの点で微妙ですが。大体のフレームワークのモデル周りの機能にもっと洗練したものが載っているので手書きで作るよりそちらを使った方が良いです。
　カプセル化をやりたかった時に起きるアンチパターン対策として重要なのは上記の内のmailプロパティのset機能です。mailプロパティに代入する際にバリデーションが働き、mailプロパティに入っている文字列はメールアドレスとして認められる文字列だと整合性を保っています。データベースの型のみではできないバリデーションで特に有効です。この手のプロパティにアクセスする際にわざわざメソッドを増やす意味を無視するとただただカプセル化処理のめんどくささだけが残ります。
　ありがちなカプセル化っぽいことをするアンチパターンが次です。

class Engine
{
    private $gear
    
    public function setGear($value)
    {
        $this->gear = $value;
    }

    public function getGear($value)
    {
        return $this->gear;
    }
}

　ただprivateプロパティを書き換えてるだけで、こんなことをするぐらいならpublicで宣言すれば良いです。set, getメソッドの長さの分むしろ読み難くなります。これがあるあるの間違いになるのはset, getを自動で生やす機能がIDEには大体備わっているためです。適切に使えば便利なのですが、とりあえずメソッドを介してプロパティにアクセスすればカプセル化になると考える人とこの機能が組み合わせると上記アンチパターンが発生し、後に続く人がコードを読む際に苦しみます。

　正しくオブジェクト内部に留めておくと変更も楽です。これはオブジェクト内部しか影響しない、とわかりきっているコード部が増えるためです。