Solved

Please review this code

10 answers Last reply Best Answer
More about please review code
  1. Correction:
    What does line 164 (not 163) do?

    I mean "playArea.addMouseMotionListener(this)".
  2. No idea what that means, because GRect class isn't defined in your source code. However, in the future I'd advice naming variables so it would be clear what they are made for from their names.
  3. Sunius said:
    No idea what that means, because GRect class isn't defined in your source code. However, in the future I'd advice naming variables so it would be clear what they are made for from their names.


    Sorry, I don't quite understand you.

    GRect (which creates a rectangle) is not defined by me. It's defined in the ACM package which I imported.

    What's wrong with my naming convention?
  4. For example, take Player class. It's confusing it has field 'player'. Also, there are some variable in GCompound that uses shortenings of words and it's hard to understand them (like bulletArr). And generally, I don't think you want to define same objects inside of class (like bullet inside Bullet class). Bullet class should consist of fields about one bullet and when you write
    Bullet bullet = new Bullet()

    then a single bullet is created.
  5. Sunius said:
    For example, take Player class. It's confusing it has field 'player'. Also, there are some variable in GCompound that uses shortenings of words and it's hard to understand them (like bulletArr). And generally, I don't think you want to define same objects inside of class (like bullet inside Bullet class). Bullet class should consist of fields about one bullet and when you write
    Bullet bullet = new Bullet()

    then a single bullet is created.



    Thanks. That's noted.
  6. Best answer
    Takwas said:
    There are five Classes: Is it OO enough?


    It can be improved. You have a class Invader which has several different types, each which behave slightly differently (eg. they all have different max hits and different colours). You are using an enum to switch the behaviour of the class when you should be extending Invader instead. Each derived class can then override the methods and fields of the Invader class which differ depending on the type, while the common members will only be defined once in the parent class.

    The rest of your application can then, for the most part, continue to work with Invader objects since derived classes are still valid Invader instances. It won't have to keep using switches and other checks to see what type it's working with because it doesn't care, since each derived class of Invader takes care of its own peculiarities internally.

    This also applies to any other similar usages of enums to define types, like the Bullet class.
  7. randomizer said:
    It can be improved. You have a class Invader which has several different types, each which behave slightly differently (eg. they all have different max hits and different colours). You are using an enum to switch the behaviour of the class when you should be extending Invader instead. Each derived class can then override the methods and fields of the Invader class which differ depending on the type, while the common members will only be defined once in the parent class.

    The rest of your application can then, for the most part, continue to work with Invader objects since derived classes are still valid Invader instances. It won't have to keep using switches and other checks to see what type it's working with because it doesn't care, since each derived class of Invader takes care of its own peculiarities internally.

    This also applies to any other similar usages of enums to define types, like the Bullet class.



    Thanks for pointing that out randomizer. I would like to ask if the new Invader superClass is what is called an Abstract class.

    Also, if you were to run the updated version of my code which is posted as one of the comments (NOT THE ORIGINAL POST!) in here:

    http://www.dreamincode.net/forums/topic/302496-im-unable-to-access-a-member-from-an-object-properly/

    You will find out that as the levels get increased the game speed gets slower instead of the contrary. I've looked at my code but nothing seems to be wrong with. Could it be a problem with my CPU or an increased number of computations.
  8. Best answer selected by Takwas.
  9. Takwas said:
    Thanks for pointing that out randomizer. I would like to ask if the new Invader superClass is what is called an Abstract class.


    Only if you declare it as such. Abstract classes are classes that can't be instantiated; that is, you can't call the constructor for one. you are only able to call the constructor for its derived classes (unless they are also marked as abstract and have their own derived classes). A class that has derived classes does not necessarily need to be abstract, there are uses for both abstract and normal classes. A common example for needing an abstract class would be if you want to force all derived classes to provide their own implementation of one or more methods. The method would need to be abstract as well as the parent class that declares it.

    Takwas said:
    You will find out that as the levels get increased the game speed gets slower instead of the contrary. I've looked at my code but nothing seems to be wrong with. Could it be a problem with my CPU or an increased number of computations.


    I don't have the Java compiler installed so I can't actually run it myself. If you have a notably faster or slower computer available you could test it on that to see if it is getting slower because your game speed logic is wrong or due to performance problems (a slow PC will slow down more quickly and vice versa for a faster PC). You might also want to run it against a performance profiler and look for locations in the code where the CPU is spending too much time.
  10. randomizer said:
    Only if you declare it as such. Abstract classes are classes that can't be instantiated; that is, you can't call the constructor for one. you are only able to call the constructor for its derived classes (unless they are also marked as abstract and have their own derived classes). A class that has derived classes does not necessarily need to be abstract, there are uses for both abstract and normal classes. A common example for needing an abstract class would be if you want to force all derived classes to provide their own implementation of one or more methods. The method would need to be abstract as well as the parent class that declares it.


    I don't have the Java compiler installed so I can't actually run it myself. If you have a notably faster or slower computer available you could test it on that to see if it is getting slower because your game speed logic is wrong or due to performance problems (a slow PC will slow down more quickly and vice versa for a faster PC). You might also want to run it against a performance profiler and look for locations in the code where the CPU is spending too much time.



    Alright thanks.

    BTW, I'm already building in more functionality into the game and yes most of the superclasses are declared abstract (cos I wrote some abstract methods).

    Also I'm learning about simulating multiple inheritance with Interfaces, so I've also used a few interfaces like Killable, Shooter...

    Indeed, it looks a lot more Object - Oriented with all these new implementations. I really appreciate the fact that you pointed-out about the need for more classes.


    In general, it's fun!


    ----------------------******************------------------
    
    
    while (ALIVE) {
        idea ++;
        implement (idea);
    }
    
    


    ----------------------******************-----------------
Ask a new question

Read More

Programming Java Bullet Apps