esa-phpをアップデートした話

January 30, 2018,
tags: php esa esa-php


このエントリーをはてなブックマークに追加

嫁が有名人になってきたので、そろそろニートになりたい。
そんな気持ちで毎日を過ごしている僕です。

この度SymfonyMeetupで@ttskch大先生より、esa-phpが使いづらいとの指摘をいただいたので修正することにしました。

指摘された内容について

  • Clientクラスがfinalでテストが書きづらい
  • ClientクラスからApiを呼び出す時にPHPStormで補完されない

Clientクラスがfinalでテストが書きづらい

Client.php
上記のコード見ていただければわかりますが、interfaceをimplimentsしているわけでもないのに謎にfinalがついている・・・。

Q: なぜそのような実装にしたのか?
A: 記憶にございません・・・。

まじでなんでこんな実装したのか覚えていないんですよね。。。
最悪ですね。

ClientクラスからApiを呼び出す時にPHPStormで補完されない

いわゆるマジックメソッド__callを使っているので補完されないパターンですね。
@method書けば補完されるけど、そもそもClientクラスの実装がイケてないので書き直しました。

何が変わったのか?

  • ApiMethodsというクラス名をApiにした
  • ClientクラスとApiクラスの関係が逆転した
  • ClientInterfaceを用意した

ApiMethodsというクラス名をApiにした

そんなに深い理由はありませんが、クラス名を変更しました。
esa-phpを利用する側の実装は、Apiクラスのみを扱えばいい、生成すればいいという気持ちを込めてクラス名を変更しています。

<?php

$api = \Polidog\Esa\Api::factory("token", "team");

こんな感じで生成できます。

ClientクラスとApiクラスの関係が逆転した

Clientの役割はなにか?ということを改めて考えてみたところ、僕が行き着いた答えは「Apiからデータを取得する役割をするのがClient」という感じになりました。
GuzzleのClientクラスを使っているだけなんですが、ここにesa-phpとしてのClientというものを用意することにより、より柔軟になる気がします。

ClientInterfaceを用意した

Guzzle気に入らないから別なHTTPライブラリをつかいたい場合にも差し替えるとか、APIのCache機能を用意したい場合に別のClientクラスを用意すればいいのかなぁーと思い、ClientInterface用意しました。
esabaのProxyクラスの実装をみて、本来これはClientで実現するべきクラスなんだろうなぁーと。

最後に

ということでv2にアップデートしました。
ぜひ使ってみてください。フィードバック待っています。

最後の最後に

最近は一人で開発することが多いので、使いやすいライブラリ、読みやすいコードなどの視点が欠けていたと反省しています。
読みやすいコードは人によって違うかもしれないんだけど、なんというか意図が伝わりやすいコードってあると思うんですよね。
あと、他の人がそのライブラリを使いやすいかって視点は本当に重要だし、自分に一番足りていない部分だと改めて痛感しました。

@ttskch大先生に申し訳ない気持ちもありつつ、OSSのコードを通じて学べたのでesa-phpを作ってよかったなと改めて思いました。

comments powered by Disqus