Sun / Oracle Convenzioni di codifica Java astenersi di fornire requisiti concreti su come confezionare.
Per la mia lettura delle parti correlate delle convenzioni, questa sembra una decisione deliberata: gli sviluppatori dovrebbero confezionare a loro discrezione, seguendo le indicazioni generali e le idee fornite dalle convenzioni.
Una convenzione particolare da tenere a mente è 10.1 Fornire accesso a istanze e variabili di classe
Don't make any instance or class variable public without good reason. Often, instance variables don't need to be explicitly set or gotten-often that happens as a side effect of method calls.
Considera che le classi e i metodi riferiti all'interno dello stesso pacchetto consentono di evitare l'accesso public , questo dà una sorta di preferenza ai pacchetti più grandi.
Ma, se si segue in modo cieco sopra, questo può portare a pacchetti non gestibili che sono troppo grandi. Per bilanciare ciò, è meglio prendere in considerazione la parte della Classe 3.1.3 e le dichiarazioni dell'interfaccia che forniscono indicazioni su come raggruppare le cose (il carattere in grassetto in basso è mio):
...methods should be grouped by functionality rather than by scope or accessibility... The goal is to make reading and understanding the code easier.
Vedi, non appena ti senti (meglio ancora, trova in code-review ) come pacchetto diventa in qualche modo difficile da leggere e capire, è tempo di riconsiderare la confezione ("raggruppamento"), seguendo le considerazioni di cui sopra.
Usa il tuo giudizio, test e code review per mantenere il codice leggibile e mantenibile, ed evitare di usare public senza una buona ragione - il gioco è fatto.
Applicato al tuo caso, sopra significa che non sei strettamente obbligato a fare tre pacchetti come hai elencato. Per il riferimento, Martin Fowler offre una strong raccomandazione solo per la separazione del modello:
Make a strong separation between presentation (view & controller) and domain (model) - Separated Presentation...
Per la visualizzazione e il controller, Fowler raccomanda ancora un certo grado di separazione, ma non in termini così forti:
Controller and view should (mostly) not communicate directly but through the model.
Ho persino visto un ragionamento piuttosto convincente in favore del mantenimento del controller e della visualizzazione vicini tra loro:
...a view and controller are often intertwined - think of it as M(VC).
The controller is the input mechanism of the user interface, which is often tangled up in the view, particularly with GUIs. Nevertheless, view is output and controller is input. A view can often work without a corresponding controller, but a controller is usually far less useful without a view. User-friendly controllers use the view to interpret the user's input in a more meaningful, intuitive fashion. This is what it makes it hard separate the controller concept from the view.
Think of an radio-controlled robot on a detection field in a sealed box as the model...
Most user-friendly UI's coordinate the view with the controller to provide a more intuitive user interface. For example, imagine a view/controller with a touch-screen showing the robot's current position in 2-D and allows the user to touch the point on the screen that just happens to be in front of the robot. The controller needs details about the view, e.g. the position and scale of the viewport, and the pixel position of the spot touched relative to the pixel position of the robot on the screen) to interpret this correctly (unlike the guy locked in the closet with the radio controller)...
Tenendo presente in mente, hai un'opzione ragionevole per iniziare a progettare la suddivisione del codice in due pacchetti anziché tre (ad esempio model e, se preferisci seguire la denominazione di Fowler, presentation ).
Più avanti, mentre aggiungi altro codice, devi tenere d'occhio il codice per "leggere e capire", come suggerito dalle convenzioni di codifica Java sopra citate. Scrivere test e passare attraverso le revisioni dei codici fornisce buoni mezzi per un simile "monitoraggio della complessità".
Se trovi che quel particolare pacchetto diventa problematico a tale riguardo, prendi in considerazione la possibilità di suddividerlo o di estrarne una parte in un nuovo pacchetto separato. Può succedere che questo porti a dividere il pacchetto presentation in view e controller , portandolo alla corrispondenza esatta con MVC, ma non si può dire in anticipo se sarà il caso o meno.