In my voyage of discovery of java I have coded classes for virtual joystick, A*, scrolling, player physics, etc. But now I am trying to put all my methods together and build a game.
I am trying to follow an MVC pattern and so far, have 5 packages and 27 classes. But the big problem I have now is keeping track of everything. I have tried UML before, but got turned off - as it is another thing to learn! At the moment I am using an a4 notepad, but the landscape is to small so was thinking of buying an A1 flip chart type thing.
I was wondering how you pro developers manage or any good books text you can recommend.
Use descriptive names for your classes so you will be able to glance at them and see what they do. The same goes for methods.
Honestly? Memorization is a big component, at least for me. I just remember what everything does. Part of that comes from the fact that I re-use a lot of my code, so I memorize what methods do what.
Yep, pretty much. Working with HeroesGrave on a project with currently about 140 classes in dozens of packages (and growing fast), but I pretty much know what everything does, even though I didn’t write a tenth of it.
Helps if you have an editor (read: IDE) and just leave the tree view of all the packages and such open alongside your code.
Thanx guys - that is much the same as I am doing now - only I am restricted to a 13" screen, so I think that may be a problem. Wow I am struggling with 27 classes - 140 would stress me right out.
If I have a break and knuckle down for exams, when I go back to eclipse I have lost the plot.
I guess the real thing to do is to design so that you don’t have to keep large numbers of classes in your head at once: have the design be modular, comprised of independent sections (…packages? hmm), so that you only have to think about the section you are currently working on.
[quote=“NoFixedAbode,post:4,topic:51889”]
This sounds less like your problem is “keeping track of classes”, and more like your problem is remembering where you left off and how it all fits together.
This is actually a pretty common problem that you’ll continue facing for the rest of your career. Even people who have been programming for 20 years have to scratch their heads a little when they go back to code they wrote a while ago.
The best thing you can do is document your code- use comments to explain why this for loop behaves the way it does, or what this method is used for. Leave yourself TODO notes so you know where you left off.
Viking Dodge has around 45 classes, this is mainly due to poor code structure and lack of abstraction (separating the actual “game” from it’s core engine). Once you work on a project for long enough, it becomes second nature to remember where everything is.
Give it time, like kev said, even people with decades of experience look back at code or classes they have not touched in a while and go “wtf”.
All you need is pen and paper and draw class relations (inheritance and composition).
No need to dig through UML books or get into the clicking madness of bloated UML tools.
Consistency is king when it comes to organizing code. I work on various engine middleware and have ~1500 classes to organize. It’s long past where I can memorize every single class name.
As far as code architecture is concerned the MVC pattern and inheritance eventually break down and really make things too rigid. Most large libraries (Java & Android SDK included) that solely base themselves in this direction go towards being a “kitchen sink” or “big ball of mud”
You are not going to face that problem yet. I’d say things start to buckle around 500 classes.
So some tips:
I’m partial to naming interfaces with a leading capital ‘I’. This makes it obvious when looking at the file that it is an interface and not a class.
For package naming I put interfaces and other common utility code that doesn’t have dependencies using a “commons” tag in the package name. Here is the package name for IEventBus (interface):
org.typhon.commons.java6.sdk.opencore.events.bus.cop.systems
“commons” indicating it stores interfaces, java6 to indicate language level, sdk (in my middleware efforts it’s either ‘sdk’ or ‘rt’ for runtime), opencore indicating this will be a freely available package (‘core’ is another variation for indicating for pay), then the actual specific naming portion for the code at hand.
And one implementation of IEventBus is BasicEventBus; here is it’s package:
org.typhon.java6.sdk.opencore.events.bus.basic.cop.systems
When you have a bunch of code and even when you don’t a big help in organizing is to think about module separations from the get go. At least with IDE tooling like IntelliJ Idea & Android Studio (based on Idea) there is a strong module concept in the IDE. I understand Eclipse might be a bit different, but should have a similar construct.
What I have done is aggressively modularize my middleware and am now at ~750 modules / independent IDE projects. Essentially a module should expose one main core package and a few more if necessary. You don’t split packages between modules! IE don’t have the same package in two different modules. The really cool thing that this does is that in the IDE and build files you can explicitly see any other modules that any given module may depend upon.
I name the modules based on the core package name exposed.
For IEventBus this is the module it is in:
shared-java6-sdk-opencore-events-cop-bus-commons
For BasicEventBus this is the module it is in:
shared-java6-sdk-opencore-events-cop-bus-basic
“shared” indicates that it runs on any platform where Java SE is supported; the other parts of the module name mirror the package name internally. I tail things off with “commons” so its easier to see modules that are interfaces / utility code w/ no dependencies.
So, now when I look through the entire middleware code base I have ~750 modules that are named according to package and utility areas. I’ve ended up now with about ~50 utility areas with X amount of modules under them. Entity system, physics, opengl, opengl es, etc. are all major groupings.
Basically you just have to get meta on organizing your codebase. With 27 classes you are fine. At some point though putting off strongly organizing your code will have a negative consequence in maintenance and productivity. So for the time being just be as consistent as possible. Depending on how long the project / effort goes and how big it gets will determine if you need to consider doing the kinds of things I describe above.
The direction I’m travelling down has been summed up in the Modularity Maturity Model:
Spine has 273 .java files with over 1100 classes. This excludes native code and all dependencies. libgdx has 517 .java files in the core project and 1910 total.
Organize only enough so your stuff makes sense. You don’t need a UML diagram or a text file to keep track of things. You have the code right in front of you. If you aren’t working on or with a bunch of your classes, you don’t need to worry about those. When you do, review them for a refresher and then consider how you will use them.
IMO, focus more on the final product (your game) and less on how to get there. Anything the player will not notice while playing is time wasted, assuming the goal is to actually make a game.
Thanks, I really appreciate you guys taking the time out to reply. Reading through there’s some very good advice and food for thought(at 27 classes I thought I had it bad, but 1100!!! Now that is a wtf moment!).
My final product is not a game(well not yet!) Instead I am trying to develop the skills needed to change my career! So, with that in mind, I have been learning the Java language for the last 18 months and in that time I have coded small routines and started a few games. I don’t think I have enough ‘skills’ at the moment to get a job yet, so I am happy to spend another year learning.
For my next challenge, I am determined to code up a complete game! Recently turning my thoughts to the actual design side(my next uni module is design, with uml playing a big part).
In my game so far I have coded a swing app to design the rooms, and are now coding the game with the Libgdx framework. I have reused some of the classes, ie the MapHelper and xml loading and sorting classes. But I get this feeling that, what I am doing is NOT right, as these classes are duplicated and I am having to alter, as Java2d and Libgdx, at times don’t play nice.
Should I be concentrating on getting the classes within a package to be self contained?
Then these new packages(above) are included into Eclipse like other runtime libraries?
Design is new to me, and I would like to follow the correct path from the beginning but I find myself overwhelmed at the moment. I have spent weeks trawling the internet watching vids and reading articles so far, but still feel on the fringes of understanding.
Thanks Catharis - your link to “big ball of mud” sums up my code so far!
Packages are for organization and the default access (package private) modifier can be used to provide a non-public API across classes, but other than that packages don’t mean anything.
I have always preferred the “straight ahead” approach, which is to sit down with my vague idea of what I’m building and start typing. All the code goes in a single class, using static member classes where it makes sense. As the code grows, I periodically step back to see how it is forming and refactor as needed. If the code grows too large for one file, I break it into multiple files using Refactor > Move type to new file. If the code is done before it gets too big, I still move classes into their own file if it makes sense (usually if other classes will use them or if longer than a few hundred lines).
The key to the straight ahead approach is the periodic refactoring. It also requires speed (you’ll be rewriting and reorganizing a lot) and experience (starting with a decent approach to the solution, knowing what is good/bad and how to refactor). It is good because you learn to write high quality code, as long as you aren’t lazy with your refactoring. It’s bad because a lack of planning can take you way off into the weeds. I don’t advocate not planning at all, but to plan a little and use coding to explore how the plan works out. A beginner is likely to not have a great plan no matter what, so IMO you might as well dive in and build something, then step back and adjust as needed. If you don’t have the skills to assess your own code, ask others for a code review.
Ultimately design requires a lot of experience. If you lack that, you need to jump in, make mistakes, then recognize the mistakes and improve.
Hey, that’s what I (like to think I) do! I’ve never heard the term “straight ahead” before… Is it, like, a thing? A quick google didn’t turn up anything.
I used to use powerpoint to keep track of different code patterns. If I needed to do something like create an actions which I did for my last game, I’d lay out the potential hierarchy then modify it as I went along.
The fewer classes and interfaces you have the easier they are to organize. Do you have interfaces with only one implementation? Are you programming in flexibility you do not yet need? The more you can get rid of, the easier it is to organize what is left.
One thing I have tried recently which has proved useful is to group classes by cardinality. At a high level, my game has a high Game class which then has multiple GameStates. The game then passes execution to the current GameState. So one package has classes that operate at the Game level (Game itself, GameWindow, InputHandler) and another package has classes at a GameState level (GameState interface, EventQueue, etc). This makes it easier for me to see what “goes together”.
Packages have a role in general regarding modularity. In particular they can be useful for meta-data describing import / export requirements of a module. This is scene in OSGi for instance.
