Q&A
一長一短があるがどちらも正しい構成である。まあパッケージ名は小文字で
前書き
ここに質問するのが正しいかはわかりませんが、経験豊富な方々に意見を頂きたく質問します。
タグは今使用している言語・フレームワークにしておきました。
前提・実現したいこと
現在、ネットワーク構成管理用のWebGUIを作成しています。
チーム事情でWeb系エンジニアが自分一人です。周囲に有識者もいないため、誰かと相談することができない状況です。
現状JavaとSpring bootを用いてWebGUIの設計を行っていますが、私のこれまでの経験では既存システム改修に主に携わってきたこと、パッケージ構成を改善するような大規模改修を行ったことがなく、
またプロジェクトの新規でプロジェクトを立ち上げたことがないので、パッケージ構成について深く考えたことがありませんでした(反省)。
今後、案件としても継続性・拡大性が高いのと、自分が永遠に保守するわけではないので、可能な限りわかりやすいパッケージ構成にしたいと考えています。
もちろんソフトウェア開発の"原則"のようなものはあると思いますが、どうしてもネットの記事や参考書だけでは腑に落ち切らない部分があるので、
有識者の方の経験や、こうあったほうがいいという理想などをお聞き出来たらと思っています。
考えていること
依存関係や再利用性、変更可能性などを鑑みて設計をしているつもりなのですが、今までに経験のあるパッケージ構成にどうしても寄ってしまいます。
経験の大部分を占める条件および構成の例を以下に記載します。
※あくまで例なので、こういう役割があるべき、増やしたほうがいいなどの観点は排除して頂けたらと思います。
- 機能群A、機能群Bがあるとする。
- クラスの役割として、"Controller"、"Form"、"Logic"に分割されている。
package ∟hoge ∟機能群A ∟Controller ∟Form ∟Logic ∟機能群B ∟Controller ∟Form ∟Logic
経験では大体このようなつくりのパッケージ構成が多かったので、初めは何の気なしにこのような構成で設計をスタートさせました。
ただ、もしかしたら、
package ∟hoge ∟Controller ∟機能群A ∟機能群B ∟Form ∟機能群A ∟機能群B ∟Logic ∟機能群A ∟機能群B
こういった作りのほうが大部分の現場ではオーソドックスなのではないか？
と考え始めたら、何が一番良いのか見えなくなってきてしまったのが現在地です。
どういったパッケージ管理が理想的なのか、処理でいうところのOCP的なものはあるのかなどを踏まえ、
ご意見を頂けたらと思います。
よろしくお願いします。
com.example.form.hoge などの形式もある
回答3件
0
経験からすると後者のhoge.controller.FuncsionA.classが多いです。
ちょっと脱線しますが、controllerとformはUI（またはAPI/REST）が起因になるかと思います。
ただlogicはそれとは切り離して考えたほうがいいです。
ボクは細かい業務レベル（20～30ステップ）かDBへのアクセスを基本として考えるので、
logic内のクラスに関しては機能群Xと異なる粒度になります。
例えば、消費税クラスは税率マスタを参照して、税込・税抜き・税額を計算するlogicクラスなど。
このように簡単に分けれるモノは多くないと思いますが、、、
logicを機能群A,B...単位で作成していくと、
コードが冗長になったり、Utilクラスが長くなったり、
最悪はコードが冗長になったことでabstractクラスにメソッド増やしたり、新規で作ったりし始める人がいるので、
要注意です。
個人的には後者ですが、上手くハイブリットに組み合わせるのも手の１つかと、、、
投稿2017/10/13 02:20
総合スコア1400
すみません、Logicクラスに関する扱いは完全にStruts起因でして・・・笑
ActionとLogic的な発想です。Springに触れ始めてからまだ日が浅いので、例えばSQL実行を行うクラスをSpringでいうとどんな役割に充当すべきなのかまだ迷っていたので、Logicと表現しました。
ハイブリッドに組み合わせてわかりやすい構成が作れたらよいですね！
ただ今後の拡大可能性を鑑みてできるだけオーソドックスに行ってみようと思います。
ご意見ありがとうございました！
0
ベストアンサー
こういう役割があるべき、増やしたほうがいいなどの観点は排除して頂けたら
とのことなので、観点とメリット・デメリットのみを。
前者（機能パッケージ以下にクラスのステレオタイプを並べる方法）は、機能単位で作成しやすい。
１つの機能を作る＝Controller/Service/Repositoryを１セット作るので、機能の責務を分けやすい構成だが、Conntroller/Service/Repositoryを必ず１セット作ることになるため、クラスの実数は増える傾向にあるでしょう。
他機能からの参照有無をアクセス修飾子で切りやすい（パッケージプライベートのスコープも使うよう視野に入れられる）
後者（ステレオタイプ以下に機能ごとのクラスを作る）がこちらが採用されているケースが個人的には多いのではと思います。機能別には読みにくい構成にはなりますが、同一ステレオタイプから参照するメソッドが多い場合ならメリットはあるでしょう。
個人的には前者です。
投稿2017/10/12 05:12
総合スコア12011
わかりやすいご説明ありがとうございます！
どちらもメリデメがあるようなので、自分がどういったクラス構成にするのか再度熟考してから決めたいと思います。
ご意見ありがとうございました！
0
自分ひとりでならば、好きにやってしまえばと思う。
Eclipse等のIDEを使っていれば、かなり作りこんだ後でも、パッケージ移動で変えることもできるし。
AOP等でクラスに対して何らかするような場合に
・パッケージを列挙する
・クラス名の正規表現パターン
で対応するようなことが今後あると思われる
パッケージよりも、クラス名やクラスの責務に注意して置いた方が良いと思う。
命名 XxxRepository/XxxService/XxxHelper/XxxController ・・・・
責務 コントローラにビジネスロジックを混ぜない、エンティティをextendsしてmodelにしちゃうのはやめた方が良いかと
投稿2017/10/12 04:48
総合スコア253
今は自分一人なんですが、今後人員が増えてきそうなので・・・笑
責務に関してはご意見の通りですね、今一度認識をし直して考えたいと思います。
ご意見ありがとうございました！
あなたの回答
tips
プレビュー
