新しく知識をつける
node.jsについても勉強したいし、JavaScriptももっと出来るようになりたいし、けど今後の開発のベースを携帯端末に変更したいし、本当に学びたいことが多すぎて大変です。
ロジックとデータベースの勉強にゲームも作ってみたい。出来ることの復習にレシピのアプリもやってみたい。
ゲームならJavaだけど、レシピならAndroidStudioで作りたいんだよなぁ。
その為にはもっと知識が必要だわ。
復習なら簡単なプログラムでお茶を濁す感じで良いか。
でも、どうせなら意義のある物を作りたい。
ゲームにしようかな...…。
サイコロ振って、パラメータと掛け合わせて当たり外れのイベント起こして、記録させるイメージだけど、計算をどうすれば良いのか、バランスは取れるのか、全く謎です。
ダメージ計算はしないですが、勝敗は運だらけなのはどうなんだろう。
構想だけで頭やられそう。
ある程度ちゃんとしなくても良いか。
オブジェクト指向の練習と割り切っても良いか...…。
抽象クラス使ってみたいな。
インターフェースだらけだったから。
それか真面目にデザインパターンの本を読むとか。確かにアダプターパターンとか使いこなせたら、開発がもっと楽だったと思うし。
Javaでオブジェクト指向の基礎をマスターしてから次の知識をつけようか。
今はまだファクトリーパターンしか知らないし、使う意味がまだ分かってないので、ちゃんとやってみるか。
クライアントから送られるデータの型に依って取得する方法を変更せずにいられるって事なのかな...…？
1個インターフェースを噛ませる事で、入力形式が変更されてもそれぞれ対応する実装クラスに割り振れるってだけの事なのかな...…？
まだよく理解できてないので身近な料理に例えて貰いました。
ファクトリーパターンを料理に例えると、特定の料理を作るための「レシピ本」と「シェフ」がいる状況に似ています。
料理の例
レシピ本（インターフェース）:
レシピ本には、さまざまな料理の作り方が書かれています。例えば、「パスタの作り方」や「カレーの作り方」など。
これがファクトリーパターンにおけるインターフェースに相当します。レシピ本は具体的な料理の詳細を知らなくても、どの料理を作るかを指定するだけで済みます。
シェフ（具体的な実装クラス）:
シェフはレシピ本を見て、実際に料理を作ります。例えば、イタリアンシェフがパスタを作り、インド料理のシェフがカレーを作ります。
これがファクトリーパターンにおける具体的な実装クラスに相当します。シェフは具体的な料理の作り方を知っており、レシピ本に従って料理を作ります。
キッチンマネージャー（ファクトリクラス）:
キッチンマネージャーは、どのシェフにどの料理を作らせるかを決定します。例えば、「今日はパスタを作るからイタリアンシェフに任せよう」といった具合です。
これがファクトリーパターンにおけるファクトリクラスに相当します。キッチンマネージャーは、クライアント（お客さん）の注文に応じて、適切なシェフを選びます。
まとめ
レシピ本（インターフェース）: 料理の作り方を抽象的に定義。
シェフ（具体的な実装クラス）: 具体的な料理を作る専門家。
キッチンマネージャー（ファクトリクラス）: どのシェフに料理を作らせるかを決定。
このように、ファクトリーパターンは、特定の料理（オブジェクト）を作るためのプロセスを抽象化し、柔軟に対応できるようにする設計パターンです。
他にも質問があれば、どうぞお知らせくださいね！
ふーん、なるほどね。
分かった気が出来ました。
じゃあ、多分、これは無意識の内に使ってましたわ。
次はアダプターパターンも聞いてみよう。アダプターパターンはイタリアンシェフに日本料理を作らせるようにする事らしい。
返答は以下の通りでした。
はい、その理解で合っています！
ファクトリーパターン
調理の内容によってシェフを変更する: 例えば、パスタを作るときはイタリアンシェフ、寿司を作るときは日本料理のシェフを選ぶようなものです。ファクトリーパターンでは、クライアントがどの料理を作りたいかを指定すると、ファクトリが適切なシェフ（具体的なクラス）を選んでくれます。
アダプターパターン
イタリアンシェフに日本料理を作らせる: 例えば、イタリアンシェフが日本料理のレシピを使って寿司を作るように、アダプターパターンでは既存のシェフ（クラス）に新しい料理（インターフェース）を作らせるための変換を行います。これにより、シェフのスキルセットを拡張し、異なる料理を作れるようにします。
まとめ
ファクトリーパターン: 料理の種類に応じて適切なシェフを選ぶ。
アダプターパターン: 既存のシェフに新しい料理を作らせるための変換を行う。
このように、両者は異なる目的と使用シナリオを持つデザインパターンですが、どちらもシステムの柔軟性と保守性を向上させるために重要です。
なるほどね。
今回の開発で何となく使ってたみたいです。
けど、もう少し効率的に使う方法はあったとも思えます。
設計の段階でデザインパターンも構想に練れるようになったら良いんだろうけど、まだ無理だな...…。
もっと一杯作ってみて、経験を積んでいかないと、多分見積も作れないや。