Skip to main content
gamedev.net
🔒 Locked

OOP acting upon objects

Started by i_luv_cplusplus Sep 19, 2010 at 8:47 AM 2 replies 1.1k views
Original Post
i_luv_cplusplus
i_luv_cplusplus
Hello :) I've recently started using Java, after a switch from C++ (got bored and frustrated with poor IDE and complicated language). Anyway, when doing (more like trying to) apply OOP to my projects, I often find myself confused. To put it into gamedev perspective:

Let's say I'm having a Texture object, which can be bound to the current state/sampler/whatever. What approach is preferable, renderer.bindTexture(tex) or tex.bindTexture()? When should you use one approach and when would the second be better?

My assumption is that unless you can use friend classes, second approach is better because you have full access to the class. On the other hand, clumping all device state in renderer could be a better way to group things.
OpenGL fanboy.
theOcelot
theOcelot
If tex doesn't require a renderer to bind itself, then you should probably use the second form. If it does require a renderer, you could add tex.bindTexture(renderer) to the list of options. I don't really know 3d enough to give you more than that. [sad]

The way I would think about it is: which object does the action of binding really belong to?
rip-off
rip-off
Bindings is a binary operation. You bind X to Y. So I would have renderer.bind(texture). But texture.bind(renderer) could work too.

Also, try not to include the class name in methods. It should be clear from the types involved, you don't need to say "bindTexture" when "bind" would suffice.
Basiror
Basiror
Hi,

when you design your program, you first subdivide it into subsystems with minimal interfaces that allow loose coupling. Each of these subsystems can be split into classes.


I personally thinks its a good approach to structure your program code into layers.

The baselayer usually represents you IO subsystems.
On top of this IO layer comes your abstract datatypes to represent different kinds of resources.
The next layer contains all the algorthims acting upon your resources.
In general lower layers should not need to know about classes of upper layers.
Representing your dependencies as a graph would result in a DAG "directed acyclic graph",
usually a good sign of loose coupling.

layer0: IO
layer1: resources ( textures in your case)
layer2: algorithms ( renderer instances for different rendering algorithms)


In your case texture.bind(renderer) would certainly introduct circular dependencies (renderer <--> texture), something you should avoid at all costs.

OOP always teaches you information hiding and the like, which is infact very important, in order to not rely on internal states of objects, but that doesn t mean that your simple texture class shall do everything from loading, up to binding .....

A better approach is to introduce a ResourceLoader, or maybe event add another layer ("add another level of indirection")

The keywords are "loose coupling" "high coherence".


http://www.8ung.at/basiror/theironcross.html

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.