In my case, i have about a number of .java papers that I"d prefer to group into 3 packages according to the MVC pattern. One package for version classes, one package for watch classes and also one package for Controller classes. I"ve identified which belong in what package, however not certain of the following step.
You are watching: This is a group of related classes.
I desire to know exactly how to seperate them into packages, perform I make 3 folders and place the .java files in the folder that represents the package castle belong in?
java mvc packages separation-of-concerns
enhance this concern
edited Nov 7 "13 in ~ 15:51
21.7k2929 yellow badges105105 silver- badges255255 bronze title
request Nov 7 "13 in ~ 8:14
12311 silver- badge33 bronze badges
add a comment |
3 answers 3
energetic earliest Votes
Java needs that the name of a class document reflects the class name but there"s no such requirement for packages. Packages are just names that execute not form hierarchies although it might appear so on the surface. The is quiet a an excellent practice come separate different packages to various directories that reflect the package name. All advancement environment execute this because that you automatically.
improve this answer
reply Nov 7 "13 in ~ 8:55
57733 silver badges1111 bronze badges
include a comment |
Sun / Oracle Java coding conventions abstain of offering concrete needs on exactly how to package.
Per my reading of related components of conventions, this appears a deliberate decision: developers space expected to package at their discretion, following the general guidance and ideas noted by conventions.
Particular convention to save in mental is 10.1 Providing access to Instance and Class Variables
Don"t make any type of instance or class variable windy without great reason. Often, instance variables don"t must be explicitly collection or gotten-often the happens as a side impact of technique calls.
Take right into account the classes and also methods advert from in ~ the same package enable to avoid public access, this provides sort the a preference to larger packages.
But, if one follows over blindly, this may bring about unmantainable packages that space too large. Come balance because that that, one would far better take right into account the component of 3.1.3 Class and Interface Declarations that provides guidance on how to team things (bold font in below quote is mine):
...methods have to be grouped by functionality quite than by border or accessibility... The score is to make reading and also understanding the password easier.
You see, as shortly as you feel (better yet, discover in code-review) favor package i do not care somehow complicated to read and also understand, it"s time come reconsider the packaging ("grouping"), following above considerations.
Use her judgement, tests and also code evaluate to store code readable and maintainable, and also avoid utilizing public without an excellent reason - that"s it.
Applied to your case, above way you space not strict mandated to make three packages together you listed. Because that the reference, young name Fowler gives solid recommendation to just separating the model:
Make a solid separation in between presentation (view & controller) and also domain (model) - be separated Presentation...
For view and controller, Fowler still recommends some degree of separation, however not in such strong terms:
Controller and view need to (mostly) not interact directly yet through the model.
I have also seen a nice compelling thinking in donate of keeping controller and also view nearby to each other:
...a view and also controller are frequently intertwined - think of it as M(VC).
The controller is the input mechanism of the user interface, i m sorry is often tangled increase in the view, an especially with GUIs. Nevertheless, check out is output and also controller is input. A check out can often work without a equivalent controller, however a controller is usually much less useful without a view. User-friendly controllers usage the see to analyze the user"s intake in a much more meaningful, intuitive fashion. This is what it renders it tough separate the controller ide from the view.
Think of one radio-controlled robot on a detection field in a sealed box together the model...
Most user-friendly UI"s name: coordinates the view through the controller to administer a much more intuitive user interface. Because that example, imagine a view/controller with a touch-screen reflecting the robot"s present position in 2-D and permits the user come touch the allude on the display that just happens to be in front of the robot. The controller requirements details around the view, e.g. The position and also scale of the viewport, and also the pixel place of the spot touched family member to the pixel position of the robot top top the screen) to analyze this correctly (unlike the male locked in the closet through the radio controller)...
With above in mind, you have actually a reasonable alternative to start developing your code split to 2 packages rather of three (say, design and, if you like to follow Fowler"s naming, presentation).
Further down the road, as you add more code, you need to keep an eye on maintaining the code great for "reading and understanding", as argued by Java coding conventions quoted above. Writing tests and also going through code reviews provide an excellent means because that such a "complexity monitoring".
See more: In Too Deep Lyrics Sum 41 Meaning, In Too Deep
If you discover that details package i do not care troublesome in that regard, take into consideration splitting it or extracting some part of it into a new, separate package. It can happen that this will lead to splitting presentation package come view and controller, happen it come exact complement with MVC, but one can"t tell beforehand whether it will certainly be the instance or not.