読者です 読者をやめる 読者になる 読者になる

Javaプログラマ(銅) ぬるぽの刑

HR/HMプログレ好きでJavaプラグラマな人がいろいろ書くのと、日々の業務でぬるぽ地獄に遭ってゲンナリするブログ('A`)

やっとこさプログラマになれる...?

4月入って始まった新規案件、なんとプロジェクトの基本部分の設計から始めました。
いままではだいたい先輩がこさえてくれてたのを、今回はオイラがいろいろ調査して流用して一から作ってます。
共通部分を考えたり作ったりってのは仕様書通り作るのよりもアタマ使いますね。ひどく疲れます。
ということで苦労は多いけどもコーダーとはちと違う、デザイナというかクリエイタというかそんな感じで楽しいです。

んで、設計について…これ失敗じゃねぇのw?ってだんだん思ってきた。
たぶん問題はないんだろうけど、ほかのひとにはわかりにくいかなぁ。
設計前や設計レビュー時に「時間内からそんなにクラス作らなくて済むようにねー」的なことや、「不必要にふるまい持たせちゃだめよー」的なことをリーダーから言われてたのでトンデモ設計。
基本クラスでは初期処理イベントだけ!
検索したいなら検索イベントのインタフェース、メンテしたいならメンテ系イベントのそろったインタフェース、印刷したいなら(ry
って感じで責務をわけてしまいました。
んで、基本的にはアクションクラスはなにもしない!サービス層に細かい実装を!ってことにしたので、場合によってはアクションクラスで特に変な動きがない、たとえば「この画面では初期化と検索以外はなんもしないよ」っていうのなら、アクションの実装は1個だけで済んでしまって、下のようにbeanのid変えるだけってこともできます。

 <bean id="xxxSearchAction" class="foo.bar.action.BaseSearchAction"><property name="searchService"><ref bean="xxxSearchService"></property></bean>
 <bean id="yyySearchAction" class="foo.bar.action.BaseSearchAction"><property name="searchService"><ref bean="yyySearchService"></property></bean>
 <bean id="zzzSearchAction" class="foo.bar.action.BaseSearchAction"><property name="searchService"><ref bean="zzzSearchService"></property></bean>

今までアクションクラス:サービスクラス=1:1→n:nで作ってたのを、同じ責務であればアクションクラス:サービスクラス=1:nなんてこともできるという(書いてても読むと意味わかんないだろうなwUML書きたいが時間がないです…w)。

でもさ、これちゃんと説明できるかなぁ('A`)
すべておれのウデしだいw?

なにはともあれ、これでコーダー卒業でプログラマですかね…?