Help with proper OOP Tecniques

[MikeCox]

Hello!

I'm working on developing a Space Defender game in VB, where the player's main ship is represented by a class module. This is mostly to learn more about classes and creating an object that is as stand-alone as possible. I realize that the object should "encapsulate" all the methods and variables it needs in order to act as an object, allowing the client code to be ignorant of its internal being.

My question is concerning the bitmap image of the class.

On one hand it seems that I should try to make the bitmap part of the class, in keeping with the encapsulation theory, and allowing the game engine to focus on game stuff, not object stuff. But a class module can't (that I know of) maintain its own reference to a bitmap, which forces me to either load it from a .bmp file, or reference a picturebox on a different form in the app. (in both cases, my class's intelligence is scattered around, defeating the purpose.)

On the other hand, if the game engine has to update an object's bitmap every time it moves or explodes, does that not also kill the benefit of OOP? Which is the better tecnique? I'm trying to get a good handle on objects in order to smoothen the transition to C++. Thanks to all for any input.

Mike

 

[neilkonitzer]

You state, "I'm trying to get a good handle on objects in order to smoothen the transition to C++."

This is simply my opinion, but me being a C++ and a Visual Basic developer, I think that your better off starting with C++ to get a grasp for the TRUE intent of object orientated programming (OOP).

 

[MikeCox]

I know you're absolutely right. At present, I am familiar with C++ classes, sub-classes, inheritance, and several other C++ object concepts, so I do have a pretty good idea of the concept, and the limitations in VB6. Being self-taught, I can always use advice like that, and I appreciate it.
My true intent is to practice creating objects (such as they may be in VB) at a simple level for starters. I want to get used to creating re-usable, stand-alone classes, avoiding common mistakes like making the class dependant on values outside the class. I figure although VB classes don't provide the flexibility (and therefore the full benefit) of C++ objects, the encapsulation concept still applies and should provide similar "good habits" when developing a true object. Would you agree with this approach?

 

[dbleyl]

Hi,

It sounds like a good idea to me. Keep in mind that you can have lots of different kinds of objects. Pay special attention to the subtle ones. You could have a general 'graphic' class that wraps the implementation details of a more specific graphic format, like a bitmap and it's container. You could use LoadResPicture to load the graphic. The benefit would be that you could switch containers later on.

Don't worry about encapsulation in and of itself. Worry about the costs & benefits. You don't want other classes reaching into your object, say MyObject.picturebox.visible = true, but MyObject.DisplayOn = True. (DisplayOn might set me.picturebox.visible = true (you can use forms as objects, if you need to.))

I think OOP is much harder with VB than C++. With VB you have to think in terms of COM at the sametime.