0

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?

  • 1
    At 2000 LOC I feel barely warmed up and I always use packages/namespaces/projects/etc, but is there a real answer here? Isn't it just a matter of taste (aka opinion), with a few general guidelines? – david.pfx May 10 '14 at 12:20
  • The organization you proposed sounds reasonable. Why not just go with it? – lethal-guitar May 10 '14 at 12:57
  • @Prog you could always change it later on, if you notice that a package grows too big/is too small etc. – lethal-guitar May 10 '14 at 12:59
  • @lethal-guitar The way I think of organizing this is by 'systems-subsystems'. A system is represented by a package, containing subpackages which represent subsystems, and so on. With the exception that classes implementing a specific technique (like the Strategy pattern) are also contained in a common package. Is this a common approach? – Aviv Cohn May 10 '14 at 13:16
  • 1
    This is a terrific resource to get you thinking about how to package (with an obvious bias towards an approach provided) javapractices.com/topic/TopicAction.do?Id=205 – jordan May 10 '14 at 16:28
1

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.

  • I'll look into Open Source projects. Anyway could you look at the example-organization I described in the question and say if it seems reasonable to you? – Aviv Cohn May 10 '14 at 12:56
  • @Prog I just left a comment on your question about that :) – lethal-guitar May 10 '14 at 12:57
3

There is no one answer to your question and it depends on the architecture of your application. This question might get closed.

2000 Lines of code is actually pretty small. How you divide your program into classes is the same question as how do I do object oriented programming. You should probably start with Wikipedia and then buy a book on the subject or find a course online.

In terms of guidelines you could start with SOLID and Packaging Principles

From Packaging Principles, the Reuse-release equivalence principle (REP) states:

REP essentially means that the package must be created with reusable classes.

That is, If you don't need to reuse, then don't need to package them independently from your application.

  • I'm aware that 2000 LoC is pretty small ;) . Also I feel I have a decent grasp of OOP principle and design. My question wasn't about how to divide my program into classes. It was about how to divide my classes into packages. This question was meant to see if there is a 'common acceptable' approach to do this. Could you please review my example-organization of a program that I described above and say if it seems reasonable? – Aviv Cohn May 10 '14 at 12:45
  • 1
    @Prog the thing is, the two things are related. If you've designed your application well, then the packages should be obivious – Dave Hillier May 10 '14 at 12:48
0

Organize and model your classes so you can GET THE BENEFITS of OOP and SOLID, etc.

Encapsulation and data hiding. There are many ways to organize things into classes that are tightly bound to each other and still satisfy the 'official' definition of OOP. OOP languages and design principles make it easier and give you the tools to achieve encapsulation and data hiding, and it fact make it difficult to create quite such a tightly bound, dependent mess. Try to understand WHY you would want to do it the OOP way, by understanding, WHAT the OOP methods might give you, in the future.

Polymorphism and reuse. Again there are a million way to extract some abstraction out of almost any 'thing' or concept. The point of OOP is that you can achieve a benefit from this philosophizing. You can get re-use, generalization, less code for more functionality. Less maintenance, etc.

Those are some good ones. Look at the rest of the OOP and SOLID and decide whether you can really achieve a benefit, and let that lead you to a natural organization strategy.

Also, there are many times when OOP principles do not really help you; at least in the current size and maturity of your product; they simply make things more complicated. But this adherance, 'in principle', may make your product more future-proof. A good example would be something like Dependency-Inversion/Injection, or maybe something like Factory patterns. Often overkill, but when you app grows, you thank the heavenly stars you put that hook (DI, Factory) in there in version 1.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.