I'm a hobbyist programmer working on my own projects. I use Java.
Until recently my average project was only 1000 LoC. My latest project however is bigger and is starting to exceed 1500 LoC. I estimate it will reach about 2000.
I've never organized my classes into packages. All of them were always in the default package and it worked fine.
However as my projects grow and the amount of classes gets bigger, I'm starting to feel unorganized.
My question is: how exactly does one divide his/her classes into packages? What I mean is, by what criteria do you divide classes?
Is it by the 'part' of the app? Aka GUI classes in one package, business logic in the other, networking, etc.? Or maybe high-level classes versus lower level classes? Aka classes that do concrete, specific work in packages of their own, and 'architectural' classes that tie it all together in their own packages? Or maybe you simply divide by the criteria of 'what feels right and organized' specifically to you?
For example, I'm working on an app that makes music. It is basically divided into two main systems: the system that makes the music, and the system that displays the GUI and controls the other system (i.e. a button press in that system activates the other system).
The music-creation system is also divided into two systems: for creating melodies and for creating chord progressions. And the chord-progression generation part, among other things contains a group of classes that serve as interchangable algorithms for a Strategy pattern involved (i.e. classes used for a specific implementation detail).
There are of course higher-level and lower-level classes involved in every system. For example the progression-generation system contains a ProgressionGenerator class, which is high-level and ties the entire system together. It also has a Chord class which is far more low level (i.e. takes care of playing specific notes).
The way I would organize this into classes is like so:
The music-creation system into one package, the GUI system that controls the other system into another package.
Than the melody-creation into a subpackage of the music-creation pakcage and the progression-creation into a different subpackage.
And inside the progression-creation subpackage, another subpackage contataing the classes used for that Strategy pattern involved somewhere in that system.
Does this sound like a good approach for organizing things into packagages? By what criteria do you divide the classes into packages? By 'what feels right', or by more technical terms?
Best Answer
In general, I tend to organize by responsibility/function. But it totally depends on your concrete project, and architecture, and there is no single definite answer/guideline here. Not to mention that personal taste also plays a large role here.
My suggestion: Look how other people/organizations are doing it. Take advantage of Open Source. Look for Java projects on github, for example, and browse their source. You'll get a feel for different approaches, and can decide which ones you like.