はじめに
作った動機を箇条書きにすると、こんな感じです。
- どうしても長くなってしまう操作・処理がある
- いわゆる手続き型プログラミング
- 例えば、イベントリスナー
- 何かの前処理や後処理を一箇所で書けて、かつ呼び出しも自動的に行われるから便利
- 目的ごとに、複数のリスナーを用意しているが、それでもビジネス要件によってやることは増える
- 例えば、コマンド
- バッチ処理など、手動または自動で実行される処理をCUIで呼び出すことができて便利
- オプショナルの引数が増えるなどして、少しずつ処理が複雑になっていく
- とにもかくにも、いったん何かの単位でコードを分割したい
最初はそんな動機で何か既にある素晴らしいライブラリがないか探しました。
league/pipeline を使うだけで良さそうに思えた
league/pipeline を見たときは、「ああ、これだよ。これでいいじゃん」って思いました。
しかし、結論からいうと、今回は車輪の再発明覚悟で自作することにしました。
今回、一度、構築したパイプライン（callableの配列）に、コールバック（callable）を後から差し込みたかったのですが、そのインターフェイスがなかったというのが最大のポイントでした。
league/pipelineを参考にしつつも、自分なりにライブラリを作ることに
自作するにあたって、league/pipelineを真似した部分とそうでない部分があります。
league/pipelineを真似した部分
-
callableの配列を順番に処理する
-
callableであれば良いので、__invokeを実装したクラスでもOK
-
-
Be immutable.防御的コピーを活用して、状態が不変（イミュータブル）になるようにしました
league/pipelineを真似しなかった部分
-
callableの配列に追加する際、配列のキー（int型）を指定できるようにした- 配列は
ksortによって並べ替えられるので、後からcallableを任意の位置に挿入することが可能に
- 配列は
-
PipelineBuilderのかわりに、Pipesを作成し、PipelineはコンストラクタでPipesを受け取るようにした-
Pipelineのコンストラクタでarrayを受け取っていたのでは、callable以外のものを突っ込まれる可能性があるので
-
-
ProcessorInterfaceでProcessorを入れ替えられるようになっているが、用途が思いつかないので、採用しなかった - コールバック（callable）の引数は、
array $payloadではなく、Contextオブジェクトを渡すようにした -
StatusをisStoppedに変更することで、処理を途中でやめることができるようにした
ということで公開しました
小さいライブラリなので、Scrutinizer-ciのスコア10点満点、カバレッジ100％にして公開しました。
おわりに
お手伝いしている現場でも実際に使ってみて、長い処理をひとまず分割していけたらと思います。
league/pipelineがこれを真似してくれたら、嬉しいですね。
実際、本番で動くようになったら、様子をみて、v1.0.0にしたいと思います。
ではでは。