はじめに
※本記事はシステム設計の正しさとかを求めてる方向けの記事ではありません。
タイトルは他人への煽りとかではなく、自分自身に向けています。
知識も大事だけど実践して振り返ってまた実践して...このサイクルが大事だよという自分へのメッセージです。
これは後述するJPINでもよくおっしゃられていることですね。
SOLID原則とかDI(InversionではなくInjectionの方)とかデザパタ駆使して疎結合、高凝集にしていきましょう。出来る限り、ミュータブルではなくイミュータブルでいこう！
とまぁこういったことが大事な考えであることも、また、どうやったら実現できるのかとか、適用することで何が嬉しいのか、はたまたデメリットはなんなのか。5年目にしてやっと何となく理解出来るようになってきました。
とはいえここまで理解できるようになったのは開発現場やJPINというJavaコミュニティや、Xにいるつよつよエンジニアの方々のお陰です。この出会いがなかったら未だに設計の大切さに気づいてないと思います。感謝してます！ありがとうございます！(JPINとYPSの存在が正直めちゃくちゃでかい。コーディングに関してはRecursionに感謝)
本題
java.ioパッケージではデコレーターパターンが採用されてるとかSpringのBeanがデフォルトではシングルトンになるよう設計されてるとか、それは分かったし、知ってることで理解することが出来てもちろん楽しいけれど
実はずっともやもやというか理解できてないことがあるんですよね。
Javaの開発現場だとSpring Bootを使用したプロジェクトがほぼデファクトスタンダードだと思います。そこでSpringプロジェクトでの設計原則との紐付き？活用方法が微妙なんですよね。
多分今まで僕が経験してきた現場のパッケージ構成は駄目とは言わないけど、どちらかというと大勢が関わるということもあってイージーな構成になってたと思います。代わりに保守性とか拡張性など大きな犠牲も払っていたと思います。じゃあその犠牲となっている保守性、拡張性を高めるにはSpringプロジェクトだとパッケージ構成をどう変更したら良いのか、また、それらパッケージの役割分担をどうしたら良いのかという所が具体的によく分かってないんです。
Xでアンテナを適当に張りすぎてるせいなのか、
DDDとかの話とか色々ごっちゃになってしまってる気がしてならない。
ただ知ってるだけで使いこなせてない感がめちゃくちゃあります。
何なら設計の大切さも知らずJavaの言語仕様もろくに分からずFWを使ってずっとガリガリ書いてた時期のほうがただ動くだけのものっていう観点だと作れたんですよね。。。
なんなら今は下手に中途半端な知識が邪魔をして手が止まってしまうことが多く、今まで出来てたことは忘れてるし、覚えてることも今では技術的に陳腐化してて時代遅れだったりでほとんど出来ることも残ってない笑
ということで現状全てが中途半端なので誤ってる前提です。
ただ、絶対の正解もないとも思ってるので自分の考えをちゃんとここに残し、新たな気付きがあればあっぷでーとしつつ理解を深めていけたらと思います！
とりあえず自分の中での型が一つ欲しい。
2024年4月20日時点の考え
- 白コメント：考え方的に問題ないと思う。
- 黄コメント：ちょっと自信なし。
- 赤コメント：ほぼ自信ない。
2024年4月21日時点の考え
- 白コメント：考え方的に問題ないと思う。
- 黄コメント：ちょっと自信なし。
- 赤コメント：ほぼ自信ない。
2024年4月20日時点からFormの考え方が変わりました。
自分の中ではかなりすっきりしてる。
Formクラスのアクセス修飾子は少し悩むな。