Overusage or Underusage of objects.
BlitzMax Forums/BlitzMax Beginners Area/Overusage or Underusage of objects.
| ||
| Ok well I love objects as much as the next guy, but I tend to make fewer objects than some folks. I tend to make alot of functions rather than objects. Is this a bad programming practice? Is there such a thing as overusage or underusage? |
| ||
| As a single programmer I dont think that there is a rule on this. I object like mad. And try to have no globals that are outside a type namespace. And the same for constants. I think I probably "Overuse" objects, becuase even when I know its a pointless Type, I still make it. I think an "ideal" (asin what I think is pleasing), would be everything in a type. Global ReturnValue:Int = 0 Local Game:Game = New Game Return ReturnValueI quite willing to be told that this makes me a bad progammer or not. Cos I dont care, It seems so much more.... elegant. |
| ||
| I think that BlitzMax was specifically designed to cater to both procedural and object-oriented programmers, so it allows whatever level of OO that you like. Personally I think that's a great approach, since it doesn't force OO on those who don't want it, but allows it for those who like it. As for me, I'm big on OOP. One of my few problems with the otherwise-great Blitz3D was how functions were unrelated to their data, and how there were no static locals (i.e. Globals within a Type in Max), forcing the use of program-wide Globals for what should be limited within a Function. BlitzMax fixed all that wonderfully while not requiring OO use. I'm quite happy with it, and once 3D is added, it should become the greatest language around for those who can appreciate it! (That's perhaps a bit over-the-top, but it's how I feel <g>.) So program with whatever amount of objects that you like. It's your code, and whatever level of objects works best for you, from none to near-total, BMax is ready to provide. |
| ||
| i try to use objects a lot while keeping things that are needed everywhere outside of types and keep the number of unneeded variables in types low. also i tend to use parent types a lot so some of my types only have 1 or 2 varibales that go to that one type |
| ||
| I use objects without any inheriting. I let them work together via the eventsystem, so each object stays 100% independent/unlinked. I personally think inheriting is overrated (few prof.coders I talked to some while ago think so as well) |
| ||
| while I prefer the OO approach, i think it's important to realize that OOP is not the be-all-end-all. There always are some situations where a prodecural approach is just easier and/or faster and has less overhead. I think it's great that bmax offers you the possibility to use both at the same time. So it's really just a matter of what you feel comfortable with. I really wouldnt bother with questions like 'Is this bad programming?". It all comes down to personal peference really. In the end the only thing that matters is that your game gets done and in the most efficient and fast way possible,so you can get the best possible performance out of it. Whether this is achieved through procedural or OOP design, is entirely dependant on the type of program you are creating. The only thing you need to watch out for when combining the 2, is that you have a coherent structure to it. Being consistent is the key here, because otherwise you will find yourself in a maze of unfathomable garbage when you read it back in a few weeks. As long as there is a clear structure to your way of doing things, then it really oughta be ok. |
| ||
| I've got about 95% objects and a couple of function. Also lots of the objects inherit, but only once. Also I like to contain objects in other objects. BMax is so easy for this and once you get used to it you never want to go back. |
| ||
| Is this a bad programming practice? As you can see, that depends entirely on who you ask. However it is going to be much more difficult to maintain in the future. Is there such a thing as overusage or underusage? No. There's only poor design and good design.Just writing arbitrary functions everywhere = bad design. Low coupling, high coherency = good design. |
| ||
| i agree with Gray because, what is the point of having a type inhert stuff from one that inherted from another type when you can just add a variable that can change the stats of a type say you have 3 or 4 different versions of one enemy, instead of making a bunch of different types that inhert stuff from 2 types when you can make a parent type that is very abstract and can be used for most of the types. then you use a variable along with a simple function that figures out how much HP, attack, defense, etc. points to give to it based on one variable that defines it's class/level i use that method of making different versions of one type of enemy, just makes more sense to me and it seems to save memory EX: one list for all "goblin" class enemies then one list for each version |
| ||
| what is the point of having a type inhert stuff from one that inherted from another type when you can just add a variable that can change the stats of a type So you can change the functionality of one type, without it having cascade consequences through out your entire program, and so you don't have to keep track of which parts of your code affects which other parts? just makes more sense to me and it seems to save memory EX: one list for all "goblin" class enemies then one list for each version That doesn't actually *save* memory tho'. |
| ||
| yeah that is the main reason why i only use inhertance from a non-inherted type and i only put in simple functions that may draw the image, move the enemy, etc. nothing too type specific oh well but it works for me, all of them are right in one list and easier to find and run all the update and AI functions and it can save lines and time, something saved :P |
   |