propper naming for your classes?
category: general [glöplog]
im asking this since my engine-code is a mess, and i need to clean it up somehow. so i start with simple things like naming classes properly. maybe not that simple in my case because the code is a mess as i said, i probably have to change and make new classes to split them so that on class dont take care of everything, but also i dont want to inherit to many bases. ill try not to make a mistake so i have to change it all back again.
i have a base class which is called Effect and now i am thinking of changing the name to Synch because it doesn actually contain any effects code which i inherit in other classes but only some parameters which i might change later. anyway the Effect-class (which it is named) actually has a pure virtual function that is called Draw, and also an update function (which is not pure). the effects class contains basically a stack of synchronisation values. thats why im thinking of changing the name to Synch.
is it a bad idea to change the name to Synch or should i make to separate classes for the synch and the drawing, i may've been ignorant to not do this in the past, but the past is the past and now i need to work on this to be more clean.
how about this? is it a bad idea?
i just want my code to be easier to read, when i think about inheritace and classes my brain doesnt find any proper solution because its all a big mess.
i have a base class which is called Effect and now i am thinking of changing the name to Synch because it doesn actually contain any effects code which i inherit in other classes but only some parameters which i might change later. anyway the Effect-class (which it is named) actually has a pure virtual function that is called Draw, and also an update function (which is not pure). the effects class contains basically a stack of synchronisation values. thats why im thinking of changing the name to Synch.
is it a bad idea to change the name to Synch or should i make to separate classes for the synch and the drawing, i may've been ignorant to not do this in the past, but the past is the past and now i need to work on this to be more clean.
how about this? is it a bad idea?
Code:
Effect *fx = synch[i];
Synch *sync = synch[i];
if (synch->inUse(time)) //actually i use a switch, but its irrelevant, its the naming im out after.
{
fx->Update(time);
fx->Draw(....);
}
i just want my code to be easier to read, when i think about inheritace and classes my brain doesnt find any proper solution because its all a big mess.
Synch => Values;
if it only has some synch. data (that's what i got from it), then why is there a draw function on it? (even if it's virtual)
superplek: because its the base class?
when i draw an effect i need to use a pointer to a base-class because there are other types of effect-classes which inherits it. if that makes any sense to you?
when i draw an effect i need to use a pointer to a base-class because there are other types of effect-classes which inherits it. if that makes any sense to you?
Synch class => ParameterSetBase class;
synch => params;
synch => params;
i forgot to mention that the effect class has a pure virtual clone function.
neoneye: hmm
it makes sense but in your opening post, you make the argument that the parameter/synch data is separated from the actual rendering code. so in that way it would seem more sensible to keep the drawing to the rendering code and the parameters a separate object that you for example 'set' on the effect prior to drawing.
there are a 1000 ways to do this, that's why i prefer just having part*.cpp with static functions from a certain point onward :)
there are a 1000 ways to do this, that's why i prefer just having part*.cpp with static functions from a certain point onward :)
rydi:
If you want legibility, you need to switch to LOLCODE:
If you want legibility, you need to switch to LOLCODE:
Code:
HAI
CAN HAS demo_lib.dat BTW precompiled engine library, for better perfs
I HAS A PART ITZ 0 BTW change this one to jump to different parts of the demo. it might conflict with the sync tags in the MP3 when we have them in tho.
SETUSUPDADEMO
IM IN YR DEMO UPPIN YR PART
PART, WTF?
OMG 1, DO_INTRO, GTFO
OMG 2, DO_FAT_CHIX, GTFO
OMG 3, DO_WEIRD_THING, GTFO
OMG 4, DO_TUNNEL, GTFO
OMG 5, DO_GREETZ, GTFO
OMG 6, DO_OUTRO, GTFO
OMG 7, GTFO DEMO
OMGWTF, VISIBLE "ERROR, INVALID PART"
OIC
IM OUTTA YR DEMO
CLEANUPMAHSHIT
KTHXBYE
i dare to say tha, if and Effect is going to be called Sync when it has a virtual Draw and a real Update, well, the naming it the least of all your problem :)
rydi: in your case, i'd have synch values separated from effect code since it doesn't make sense to have them as a base.
Don't think about it as "code", but think about it generally, and then translate to code.
Is synchronization (generally speaking) the base of all effects? I don't think so... and if it is for you, then your engine is amazingly screwed from the bottom up.
Synch points are parameters for an effect (thus, they should be a member of the Effect class).
Think about it for a second... if you were to make a demoeditor with your engine, why would you need synch points to be driving the effects? You would actually be editing the synch points (adding, editing, removing) on a effect that you are creating, but at the time of creation (or at rendering time for a WYSIWYG still editor) they are completely unneeded and you could do with just the rendering part of it.
And, of course, about the "naming" (which is your original question)... you don't "Draw" a synch point... you draw an effect (or a scene, or whatever you want to call it), so having a "Draw()" function on your "Sync" class is just adding mess to the already messed :)
Don't think about it as "code", but think about it generally, and then translate to code.
Is synchronization (generally speaking) the base of all effects? I don't think so... and if it is for you, then your engine is amazingly screwed from the bottom up.
Synch points are parameters for an effect (thus, they should be a member of the Effect class).
Think about it for a second... if you were to make a demoeditor with your engine, why would you need synch points to be driving the effects? You would actually be editing the synch points (adding, editing, removing) on a effect that you are creating, but at the time of creation (or at rendering time for a WYSIWYG still editor) they are completely unneeded and you could do with just the rendering part of it.
And, of course, about the "naming" (which is your original question)... you don't "Draw" a synch point... you draw an effect (or a scene, or whatever you want to call it), so having a "Draw()" function on your "Sync" class is just adding mess to the already messed :)
Jcl:
why doesnt that make sense? im not going to be philosophical here, but for an effect to occur it needs a start-time and an end-time, as well as the parameters for that same effect. thats one of the things that i can actually see as clean in the code. the derived effect class using the sync class as a base, i dont really see why that is a problem? maybe you can rephrase that. i may separate the sync-code from the effect-code, thats right, but i dont think i want to separate them so that the loop code will be different.
i see timing as the base of all the "effects" or parameters for those effects. its much easier to know which time belongs to what effect-parameter. if you can change the time after the effect was created then something magical happens, now now how would that work? it is what makes the synchronization of the effects and its parameters one of the core features in the loop.
hmm. i dont understand. but this is a demoeditor yea. its not wysiwyg in a sense that it lets you see it, its a tracker-editor to be exact. it does have a calculate loop that interpolates between values before starting the demo, so that time gets properly synced for each parameter or whatever.
yes, i agree with that one. i think some cleanup is definitively needed, but thats my intentional in the first place :P
thanks for the comments, it was really helpfull.
Quote:
in your case, i'd have synch values separated from effect code since it doesn't make sense to have them as a base.
why doesnt that make sense? im not going to be philosophical here, but for an effect to occur it needs a start-time and an end-time, as well as the parameters for that same effect. thats one of the things that i can actually see as clean in the code. the derived effect class using the sync class as a base, i dont really see why that is a problem? maybe you can rephrase that. i may separate the sync-code from the effect-code, thats right, but i dont think i want to separate them so that the loop code will be different.
Quote:
Is synchronization (generally speaking) the base of all effects? I don't think so... and if it is for you, then your engine is amazingly screwed from the bottom up.
i see timing as the base of all the "effects" or parameters for those effects. its much easier to know which time belongs to what effect-parameter. if you can change the time after the effect was created then something magical happens, now now how would that work? it is what makes the synchronization of the effects and its parameters one of the core features in the loop.
Quote:
Think about it for a second... if you were to make a demoeditor with your engine, why would you need synch points to be driving the effects? You would actually be editing the synch points (adding, editing, removing) on a effect that you are creating, but at the time of creation (or at rendering time for a WYSIWYG still editor) they are completely unneeded and you could do with just the rendering part of it.
hmm. i dont understand. but this is a demoeditor yea. its not wysiwyg in a sense that it lets you see it, its a tracker-editor to be exact. it does have a calculate loop that interpolates between values before starting the demo, so that time gets properly synced for each parameter or whatever.
Quote:
And, of course, about the "naming" (which is your original question)... you don't "Draw" a synch point... you draw an effect (or a scene, or whatever you want to call it), so having a "Draw()" function on your "Sync" class is just adding mess to the already messed :)
yes, i agree with that one. i think some cleanup is definitively needed, but thats my intentional in the first place :P
thanks for the comments, it was really helpfull.
rydi: to sum up what you don't understand (i might have expressed myself poorly, sorry about that):
"an effect has synch points" vs "a synch point has an effect attached to it"
To me (and to most people), the first statement is more true than the later one... but if you say you are treating the demoeditor as a tracker (in which you tell every synch point which effect it belongs to, and not the opposite), then in your "architecture" the second sentence maybe makes more sense to you.
I mean, both paradigms can be reached either way (and many other thousands of ways), but to my understanding of scenes/effects and synch points... yours make no sense (to me).
PS: Not trying to be cynical here, excuse me if my wording sounds like it.
"an effect has synch points" vs "a synch point has an effect attached to it"
To me (and to most people), the first statement is more true than the later one... but if you say you are treating the demoeditor as a tracker (in which you tell every synch point which effect it belongs to, and not the opposite), then in your "architecture" the second sentence maybe makes more sense to you.
I mean, both paradigms can be reached either way (and many other thousands of ways), but to my understanding of scenes/effects and synch points... yours make no sense (to me).
PS: Not trying to be cynical here, excuse me if my wording sounds like it.
Also, if you want to take the OOP paradigm further... in your implementation (Effect inheriting and implementing Sync), you are basically saying that "An effect is a more complete sync point", which might be true in some obscure sense... but that's not what people would usually think when designing something like a demo engine, methinks.
I have to take math, science, history, and speech this year. Those are my classes.
I have to take meth, essence, hashish, and speed this year. Those are my classes.
Very classy indeed.
If you architect your design in a sensible way, the naming of classes and interfaces almost always comes naturally on its own..
i'm not gonna suggest a design here, because I'm not completely sure what you have and what you want and secondly because there's mostly several solutions to the design depending on perspective, while mixing up concepts is not one of them :-)
i'm not gonna suggest a design here, because I'm not completely sure what you have and what you want and secondly because there's mostly several solutions to the design depending on perspective, while mixing up concepts is not one of them :-)
the great thing about hobby projects (e.g. demo coding) is that you are not obliged to write code that adheres to a predefined standard.
Just name them all Bob!
Jcl:
of course it makes no sense. i am not using that second statement believe me :) maybe i dont express myself very well. anyway, maybe its confusing because the synctables are inside the effects class, which i should think about some time how i wanna do it. either change the name, make another class or something.
i shall work on the code tomorrow, since its getting late here. ill come up with something atleast.
hooverphonique:
i dont stick to one design, i always work on the design, so it always changes, but until now the design (or the code for that matter) has gotten so messy so i try to clean it up and make it even more better and more readable to code so that its easier to change something that needs to be changed. when you finally get something done, but see that the engine doesnt have all the features you want, then you have to look at all the underlying code, base-code, loop-code or whatever and change all that. its a pitty but, i wanna find that magic solution that works. and i am by no means a pro-coder, i just wanna find that great solution so the tool gets flexible enough. and when i think about OOP, my head spins around and i never get somewhere, so i just need to take small steps along the way.
of course it makes no sense. i am not using that second statement believe me :) maybe i dont express myself very well. anyway, maybe its confusing because the synctables are inside the effects class, which i should think about some time how i wanna do it. either change the name, make another class or something.
i shall work on the code tomorrow, since its getting late here. ill come up with something atleast.
hooverphonique:
i dont stick to one design, i always work on the design, so it always changes, but until now the design (or the code for that matter) has gotten so messy so i try to clean it up and make it even more better and more readable to code so that its easier to change something that needs to be changed. when you finally get something done, but see that the engine doesnt have all the features you want, then you have to look at all the underlying code, base-code, loop-code or whatever and change all that. its a pitty but, i wanna find that magic solution that works. and i am by no means a pro-coder, i just wanna find that great solution so the tool gets flexible enough. and when i think about OOP, my head spins around and i never get somewhere, so i just need to take small steps along the way.
kusma: of course, that makes no sense at all :P
Synch => TimeSegment;
Synch => Bass!
Synch => TimeSlice;