Repositoryに移行する
- なんかバグっとるのを修正した
- 自動テストを二つ作成した
- AIの導きによりPlaywrightでドラッグ&ドロップする関数を見つけた
- ドラッグ&ドロップでの操作のテストを実装する
- 要素の指定がむずい
- 一日寝かせたらできた
- Repositoryを作る
- RelationRepositoryを作成する
- PostRepositoryを作成する
- AIでやったらバグりよった
- リファクタリング
Decoratorを使い回すために、共通のIRepositoryを作ろうとしていたんだけど(つまりIRepositoryに命令を出すための万能なパラメーターオブジェクトを作ろうとしていた)、executeメソッドを持つICommandを作って、それにDecoratorを着せればよさそうということに気づいた。
ずっとグネグネしてたやつがようやく収まった。
ただの関数オブジェクトじゃねっていう気がしなくもない。
うっ、executeコマンドに引数が欲しい。いや、コントラクターでパラメーターを渡せばいいはず。
『なぜ依存を注入するのか DIの原理・原則とパターン』に答えが書いてあった。引数の型として総称型を使えばよい。
Repository周りをきっちり作り込みたいけど車輪の再発明してる感じがすごくする。ライブラリを使ったほうがいいかも。でもライブラリに依存したくないかも。うまくライブラリを使いつつ依存しないようにするのが設計の腕の見せ所かも。ライブラリを探そう。クラス図を書こう。
一旦Repositoryで動くようにはなったが、複数のRepositoryに同一のDecoratorを着せられるようにしたい。後々のことを考えると、今のうちにきっちり作りこみたい。
サーバーサイドでの処理をレポジトリに置き換えようとしていたが、バチクソに沼っているので、全部捨ててクライアントサイドでの処理をレポジトリに置き換えた方が良い気がしてきた。1回全部捨てることにはなるが。
サーバーサイドでもうちょっと頑張ることにした。
なぜ私は「CommandパターンのCommandをメソッドで逆ポーランド記法や」とかやってんですかね。
やっと収束しつつある。長かった……。
とはいえまだ頂上を越えたところで、テストを通す必要があるし、コードを整えなければいけない。
昨日直せなかったバグがやっと直せた。
AppSyncのエラーメッセージがもっと親切だったら簡単に直せたものを。
もともとの設計が密結合なせいで、一箇所を変えようとするとどんどん波及してしまう。
ただ、今の知識なら、徐々に粗結合にしていけるはずだ。