React.jsで将棋盤を作ってみた

React es6 設計

React,Reduxのキャッチアップ - エンジニアの勉強日記

上記記事で基本をキャッチアップしたので、もう少し実践的なプログラムを作ろうということで、将棋盤を作ってみた。

GitHub - kitabatake/react-shogi

構成

  • webpackでes6, jsxをトランスパイル

  • viewコンポーネントにReactを使用

  • reduxは使わず

はじめはreduxも使おうとしたけど、reducer, action周りをまだ上手い具合に実装できなさそうだったのと、 Practical Object Oriented Design in Ruby (以降POOD) を読んだばかりで、その辺りの知見を実践してみたいということで、Reactのみの薄い構成で作ってみた。

reduxはHPの実践サンプルをいくつか見てみた後に実装してみたい。

実装の流れ

まずViewComponentの実装は固めやすそうということで、ViewComponentと表示するのに必要な情報を定義。

この辺りreduxの影響をだいぶ受けていて、stateを持つstoreを作成して、変更を検知してレンダリングする構成で実装。

UIイベントもクリックされたセルのx, yをfireするだけというように、なるべく責任範囲を小さくするように意識した。

POODでいうドメインオブジェクトとして、盤、駒、駒台の他に、

  • selectKoma
  • candidatesMovablePositions(駒)
  • move(駒, x, y)
    • movable?(駒, x, y)

この辺りのメッセージに応えるクラスとして進行役的な役割が必要かなと考えた。

あとViewComponentからのイベントを進行役に伝搬するイベント処理の役割が必要かなと考えた。

この段階で全体的な設計を一旦決定。

いろいろな条件での駒の移動範囲の取得や、成るかどうかの判断、駒を取る処理など、進行役の責任範囲が大きくなってきてしまい、ごちゃごちゃしてきてしまったので、

駒の移動範囲の判定などの別のオブジェクトに移して、処理を委譲する形に修正。

その後は割とすんなりと実装できた。

振り返り

将棋は駒の種類が多いのと、細かいルールが結構あって処理が複雑になりがちなので、OODのトレーニングとしては結構良さそう。

Reactに関しては、最初にReactComponentを作成して、stateをsubscribeさせた後はほぼいじらなかったので、View周りほぼノンストレスで開発できた。

facilitator周りが煩雑になってしまった部分

進行役という役割を見つけたのは良かったけど、実装する前に進行役に送られるメッセージをリストアップしてみることで、責任の肥大化はある程度予測できて、あらかじめ構成要素を探すことができたかも？

ただ実装していく中で、必要なメッセージがどんどん解ってくるのは間違いないので、前もって予測するのは簡単ではなさそう。

何か責任が大きくなってきているかなと感じた時に、しっかりと問題と向き合うことが大事？

設計を見つめ直さずに「とりあえず動かす」というのを優先しがち。

POODで書いてあったように、開発を進めていく中でプログラムに関する知識が増えていき、明確になっていくので、最初に決めた設計でちょっと実装しづらいなと思った時は、すぐに一旦冷静に設計を見つめ直す意識が大事。

設計を壊してもいいという前提で、各オブジェクトを疎結合にして適切なテストを書いておけば、設計が変わっても部品レベルでは再開発しなくて済むようにできる。