From: Mikhail K. <me...@cs...> - 2002-06-08 07:14:49
|
> Refactorings that would simplify the system and make conform to best > practices: > 1) Rand - currently, a random number gets set in ScorchApplet.receiveGameSettings. However, it is > passed all over every object with no change. Recommed: static variable in some Util class (or > just ScorchApplet). All other objects requiring this static value would then call > .getCurrentRandom() to get the Random object. Impossible, unfortunately. It can't be static, because it than would be shared by all instances of the game running in the same JVM, which can happen if somebody opens up applet in two windows of the same browser. This would screw up our synchronization based on the same random # sequence. You could make it non-static publically available object in ScorchApplet, or ScorchField, but I think I decided again it because that meant that I would have to pass reference to that containing object everywhere. > 2) Weapon acting as a Weapon base class and a Factory. Recommend: > splitting the effort - create a > separate Factory class to handle the creation of Weapons. However, if > this is done, Item would > also have to be modified to remain consistent since it has the same > issue. (Is it worth the > trouble?) Just that Weapon and Item should not know about the > implementing classes. Wait, the only thing that weapon knows about the extending classes are their names. It's easy to get rid of this: we can use reflection to list all classes in "scorch.weapons" package which extend Weapon. Then call getName() on them etc. I'm not sure it's worth the effort. Factory is a possibility too. If you feel like it, try it. Of course changes to Items should be symmetrical. > 3) ScorchField - knows about specific Weapons and Explosions. This should be refactored so that > it is unware of types. For example, it could call the WeaponFactory > (or just Weapon if we don't > do the Factory) for a randomExplosion() (death explosion) and get back > the appropriate Explosion > class. (just saw you had a TODO in there for this also.) Yes and no. Explosions are not eactly the same as weapons. I guess the right way to do it is to add a flag to each weapon which would say whether it can be used for the death sequence. I need to think more about this, but just moving this to weapon or weapon factory doesn't sound 100% good. Much biggre problems is with Items. ScorchPlayer has a lot of knowledge about specific item classes. > public class LiquidDirt extends Weapon { > protected static int radius = 50; > > public LiquidDirt() { > //to make the design more obvious, the below variables can be obtained > //by creating 2 abstract methods in the Weapon class, and sub-classes > //would then implement them. > type = SandBomb; > price = 5000; > } > > //make parent class abstract > //call our Explosion -- only this weapon needs to know how > public Explosion produceExplosion(Bitmap bitmap) { > //this removes need of argument variable > LiquidDirtExplosion expl = new LiquidDirtExplosion(bitmap, radius); > return (Explosion)expl; > } > } I think I have a better idea. I kind of like the fact that produceExplosion is so generic and that weapon class doesn't have to implement any methods. The solution I have in mind is to make argument an Object isntead of int. For example MIRVExplosion needs really 2 arguments: number of particles and radius. Then the object passed to is as arument would be an array of two ints. This might introduce some weird relation ship between Weapon and Explosion class, but it looks good to me. At least at 3am. Let me know what you think about this idea. |