Comments on my design v2

I posted not so long ago a class diagram for an application that I am making. Got some helpful tips and went to work. Designing sure is tough! Anyways, I made a version 2.0, but ran into other things. Maybe somebody could give pointers, or comments, or advice concerning my class diagram :-)

First I had 'Speed' in SomeInterface as part of the Sprite abstract class. After consideration I figured that this was not the best place to put 'Speed'. A not so good thing was that I was not able to give a proper name to the interface, and that I didn't know where to put 'Speed', in the Attribute or Operations com开发者_如何转开发partment since it is a property...

Each object (Bullet, Invader, Ship) moves at it's own rate, so I put 'Speed' into an interface. All objects inherit from super class Sprite, and only override the Update() method. The Bullet abstract class does nothing with the Update method it got from Sprite, it's just there to show that it got it from there. I do not know if this is the correct way, or that I should leave it out and only show it in the classes that override it?

Another problem that I do not know how to handle is the animation that is done by the invaders. I got the following properties: SheetSize, FrameSize, and CurrentFrame. Sheet contains the alien pictures (like a flip book), FrameSize is for selecting just on frame on the sheet, and CurrentFrame... well, holds the current frame. Since Ship and Bullet do not animate, these properties are not usefull for them. Where to put them?

Finally, I didn't where to implement IBulletBehavior. First I had each bullet behavior implement IBulletBehavior, but switched to letting the abstract Bullet class implement it. Is there any rule that says which one to take?

---

Abstract classes describe what a class is. You do not have to implement the actual functionality of the method calls, so don't feel like you have to implement everything about a bullet in your Bullet class. Also, interfaces are great for describing what you class is capable of. Abstract classes show what something is (Is-A) and interfaces describe what the class can do.

(I don't know if this is just a class/interface exercise or if you are actually making a game. If it is just an exercise, you can skip to the next paragraph). For your SomeInterFace interface, how about something like IMoveable or IMobile? In here you can also look at mathematical vectors. The interface should not expose Speed, unless you want objects outside of the one implementing it to interact with Speed. Instead, it should be something along the lines of Move () and/or DetectCollision (). External interactions go in the interface--you're telling the world what you can do.

Finally, what is IBulletBehavior and why should a sprite care if it is one? This comes back to describing what you class can do. A bullet is a sprite but implements IBulletBehavior (whatever that is). Do you want all sprites to implement IBulletBehavior? What happens when you want a rock or something to just sit in the players way? You will now have an object that doesn't implement the specified behavior.