最近の CustomCrafterAPI の動向と今後の方針

Maven で配信開始

プロジェクトの依存関係として使いやすいように Maven Central に置きました。 向こう 10 年間有効な PGP 鍵を発行してあれこれしたので忘れないようにどうしようかなと思っているところ。

たまにバグが存在するバージョンを配ってしまうので、そのときには p<数字> を末尾につけたバージョンを発行することで対応しています。
出しちゃったらゴメンね。

Context を乱用

ResultSupplier や *Predicate インターフェースのような「処理を利用側で書く必要があり、なおかつ背景情報が必要な場面」に Context という名前のクラスを提供しがち。
本当はちゃんとそれぞれ名前をつけてあげるべきなんだろうけど、ネストクラスにすればだいたい 親.Context みたいな感じで使うだろうから大丈夫か！と Context 一筋でやらせてもらってます。

Java 系アノテーションの追加

Java から利用しやすいように JvmStatic, JvmOverloads などの相互運用向けのアノテーションをつけて回る作業をしました。
CustomCrafterAPI って Java からも使えるんだよ！

勝手に DI 化が進行していた

DI というのは Dependency Injection (依存性注入)の略です。
CustomCrafterAPI を設計していた当時は「インターフェースって今まであんまり使ったことないし、今回はいっぱい使ってみるか〜」くらいのノリでレシピの重要なコンポーネントなどをインターフェースで定義していたのですが、開発をし続ける中で過去の自分に感謝する場面がめっちゃ増えてきたのでおすすめです。
インターフェースを適切に定義できれば内部の処理の共通化が楽だし、利用側での拡張も楽といいことづくめでした。

当初の謎命名を改名

定形・不定形レシピをそれぞれ Normal, Amorphous として列挙型で管理していたのですが、なんとも分かりづらい上に本家 Minecraft が Shaped, Shapeless をレシピのクラス名に採用しているのを見て改名しました。
作成しはじめの頃に「形のないもの、って意味のかっこよさげな単語ないかな〜」と調べて命名した Amorphous ですが、コードはかっこよさよりもわかりやすさが言わずもがな重要ですのでこんな命名をしてはいけません。

クラフト画面のカスタマイズ機能を作成

CraftUIDesigner というインターフェースを作成してクラフト画面をいじれるようにしました。
特に要望などがあったわけではないですが、プラグインの名前に Custom と入っているんだから、構成要素はなるべくカスタムできるようにあるべきだよなと思い立って作成しました。
活用してくれると嬉しい。