Recommended Posts

Im getting into a habit. I have subclasses and, whenever I want to access something from the main class, I always make long message calls such as:
vanMain.myGame.randomInteger=5;
Is there any other way around this? I fear my programs are using lots of bad practices that not only make code hard to read, but also make the program slower.

Share this post

Link to post

Share on other sites

Not directly related to your problem, but a book has been written by four developers (known as the 'Gang of Four'), where 21 design patterns where discussed. These patterns are elegant solutions for many issues, and you should take a look.

Share this post

Link to post

Share on other sites

What your descibing is known as the java train or something like that, where a field is accessed by drilling down through layers of classes. look into the facade design pattern which basically is a class that acts as an interface to a group of sub classes.

so instead of calling

myClass.someClass.anotherClass.field

you create a top level class with methods that handles all the drilling down to the property you want.

so now you just call:

myClass.accessField();

and the access field method accesses the field and does whatever you want with itAn example of a facade pattern would be a class that manages a database, opening closing adding removing. one class would provide an interface to all this fuctionallity but in practically the functionality is spread over a number of hidden subclasses

Share this post

Link to post

Share on other sites

I come from a lisp background and all the damn parenthesis make you want to follow the left brace on its own line, but java is so very clean (and for that matter C/C++ as well) that it is trivial...but.

If you don't already have this, or would like to, here is some ant stuff for a beautifier call to JIndent (for copy paste purposes), this is just a ant target:

You'll also need the JIndent pure java downloads from JIndent.com, and to put the jars from that download in the /lib dir of your project. This is not the JIndent-ant.jar but nearly all the other jars that come with the d/l.

It's nice, and you can edit this to accept a file with your custome format preferences.

Share this post

Link to post

Share on other sites

Original post by StrifeThat's not necessarily a bad thing, but not using way too many nested classes seems to make the most sense.

You mean parent classes not nested classes right?

Its a pretty good question though: what is a good rule of thumb for the depth of a heirarchy/ancestry in a game say for something like a game entity -- spaceship or robot or monster? They're moveable, renderable, ID-able, destroyable, reproduceable, customizeable, effectable (many-to-one), runnable, seraializeable, event-firers, etc. Now if all of these were super classes -- would that be acceptable. Hmmmm. Most of this would be just interfaces, but some of those interfaces would be found in super classes. Still this could lead to an ancestry say 3-4 classes deep.

I haven't seen any metrics that say this is bad -- but someone with more experience could probably say for sure.

Share this post

Link to post

Share on other sites

Original post by Grahf750I hope this is what you uys are talking about.

if (x>9){ .....some code}

compared to

if (x>9){ .....some code}

Personally I like the second way better you can see where the brackets start and end much easier because they line up it is especially good if you have lots of nesting going on.

The 2nd edition of Code Complete has a whole section about this. The second example above (although I've used it often in the past) isn't favored by the author. This one is also OK (in addition to Java style) according to the author:

if (blah) { weeee = 2; }

Between this style and the standard Java style, a study was done that found no statistical differences in understandability between the two.

Myself I use different styles--the Sun style for Java coding, and whatever is more appropriate for C++ coding (I aim for consistency with whatever source I'm working on). I don't find it harder or easier to read either style. For the Java style brackets, to help readability, just add an extra blank line and you get basically the same visual effect. There's no use in going against standards and practices that are well established if the practical differences between the two are trivial.

Read the book if you want to know why the below is not ideal..(although personally I've used it often and I like it.) :P

if (blah) { weeee = 2;}

Not terrible either, though. There's worse styles out there. Like this last one...don't do this!!!

Share this post

Link to post

Share on other sites

Original post by TebrielRead the book if you want to know why the below is not ideal..(although personally I've used it often and I like it.) :P

if (blah) { weeee = 2;}

I hate it when people try to tell you that your coding style is no good. I've got news for all of those people: As long as anyone looking at it knows what's going on in terms of the organization, it doesn't matter.

Sure, there are some styles that are worse than others (in that it takes a while to figure it out), but this one above is what nearly EVERYBODY uses. So screw Code Complete. Only morons think that there's only one ideal way of doing things.

Share this post

Link to post

Share on other sites

Its generally not good coding style to access variables directly; thats what accessor/mutator methods are for.

Unless you have a good reason to, make all fields private and only provide accessor methods if you think the class should provide access to the data.

One exeption to this could be subclasses accessing super class fields - when you want a peice of data to be accessed directly by subclasses and not by any other class. However, to start with, even in the case of inheritance (subclasses accessing superclass data) I would keep most data private and provide accessors with the appropriate access modifier (private, package private, protected or public).

For example, say I'm working on a project with a few friends. I assume that in the future any subclasses of my new class will use protected accessor methods to get at its private data. Lets also say my class uses lazy-loading to load data from a file or data store and thus that data only gets set when the accessor method for that data first gets called.

Later on, one of my team comes along and edits part of the class, thinking to himself "Hell, we can just make this variable protected and avoid a whole load of method calls" he edits some of the private data and so bypasses my lazy loading accessor method, assuming that the accessor method does nothing other than return the value.

In this example, my friend has just introduced a bug into the project by making the private data protected. Without a decent test suite this bug could go undetected for months, and could well be hard to trace by the time it starts causing problems.

To cut a long story short; try not to break encapsulation, even for subclasses. And don't avoid calling methods because you think it'll slow your app down.

I also recommend reading: Effective Java, one of the few Java programming books you should bother reading.

Share this post

Link to post

Share on other sites

Original post by TebrielRead the book if you want to know why the below is not ideal..(although personally I've used it often and I like it.) :P

if (blah) { weeee = 2;}

I hate it when people try to tell you that your coding style is no good. I've got news for all of those people: As long as anyone looking at it knows what's going on in terms of the organization, it doesn't matter.

Sure, there are some styles that are worse than others (in that it takes a while to figure it out), but this one above is what nearly EVERYBODY uses. So screw Code Complete. Only morons think that there's only one ideal way of doing things.

I don't really disagree with you, I like that style myself too, but Steve McConnell didn't just say "this isn't the best way" and proclaim it so... Like I said, you'd have to read the book to understand his reasoning. (Too much to bother even trying to explain here.) But even he says that most likely readers aren't going to agree with EVERY thing he says, so at least he's not saying his best practice advice is bible.