---

必要な画面パーツが出揃ったところで、次は必要なオブジェクトや関数を書き並べる作業に入ります。


プログラミングそのものにいつ入るんだって、経験のない方なら思うかも知れませんけど、ぶっちゃけプログラミングなんてこういったドキュメントに沿って打ち込んでいけばいい作業なのであって、一番大事なのはこの設計の部分なんですよね。
紙ベースでこうやって設計しておけば、後で致命的な誤りを見つけた際修正が簡単ですが、既にコードとして書いてしまっていた場合地獄を見ます。



何度もそういう地獄を見てきた僕が言うんだから間違いありません。この日記なんて最たる例です。メンテナンスしたい部分はたくさんあるのに、非合理的なプログラムになってるのでもう手が加えられません。（）



ただ、僕みたいな初心者は最初からいい感じの設計なんてできないので、とにかくデザインパターンというのを積極的に取り入れつつ開発したいなあと思うわけです。
こういうのは実際に使ってみないとわからんところがあるので、実際に使用してみてその使い勝手というか、使うべきところを見てみたいなあと思ったりしています。


ということで、今回から導入してみるパターンとしてファクトリークラスというのを活用してみたいと思います。


具体的にどういうものかっていうのは、まだコードを書いてないのでコピペはして来ませんけど、インスタンス生成のための専門クラスを作るということです。
似たようなパラメータを持つけどびみょーに違うインスタンスをいくつか作る際とかに効果を発揮しますけど、これに関してはわりと思考停止で導入しちゃっていいかなって印象がします。


これの恩恵は、インスタンス生成そのものを外部に丸投げすることでコードを共通化することができるということですね。
インスタンスを使う側は、それがどのように作られているのかは意識する必要がなく、ただ結果だけを受け取ることができるのでもし何か大きな変更を加える際にもやりやすくなったりします。たぶん。
調べている中でどっかで見た気がするんですけど、原則的にはクラスのインスタンスをnewする時は大概そのファクトリークラスを通すので、不用意にnewしているクラスがあると気持ち悪さを感じるそうです。




この前書いて撮っておいた設計の写真には肝心なファクトリークラスは書いてないんですけど(笑)、たぶんそのうち参考としてコード載せてみようと思います(笑)
ちなみにこの設計、書いてる現在ではもっと使い勝手のいいコードを思いついたので一旦没にして書き直しという作業が発生してたりします。実際にコード打ち込んでるとこういうのできないんですけど、設計段階ではこうやって一旦ぶっ壊すこともできるのでラクですね。頭の悪い設計のせいで首が回らなくなってるというのはカクテルDBでも発生していますからね（）


ほんとはもっと深いレベルの話があったりします。ファクトリクラスを通すことで、後で動的に生成されるオブジェクトのクラスを変えることもできたりします。
まぁそんな話もあるんですよー程度で今は留めておいて、後で実際のコードを書く際にもーちょっと突き詰めていこうかなーと思っております。



うーん、めちゃくちゃ浅い記事になってしまった(笑)(笑)(笑)