Quote:
Originally Posted by Enfernikus
To expand upon my original post, I found when I first started programming for larger applications the hardest part wasn't the actual scripting/coding/programming but planning out the object and really keeping it concise and deciding what functionality goes in which object.
For instance, when I was working with Cruise data, the question was what sort of information should the Cruise Liner Object have? What sort of functionality should it have? Should their even be an object for a cruise liner?
Are itineraries ( their sailing plan ), which are intrinsic to ships, dependent on the ship object or should I make it independent?
|
This is just a quick write, I intend on expanding further later. but is this what you are taking about?
Objects are designed to give you reusable code. But what does reusability really mean? Reusable code has two possible meanings
- Code that will be used many times though your particular program
- Code that will see uses (whatever the amount) in many different programs
The first use, code that will be used many times in your program, is probably what you’ll end up writing the most unless you repetitively do the same area of programming. These objects contain common functions and variables that are used many times throughout the program. When I write games, virtually every item of importance needs the following: X position, Y position, display image, direction, speed, functions to change all previously mentioned, a checker to see if the X and Y cords are in or out of the screen and many other common functions. Since everything uses them, I make an abstract class (a class that can only be inherited) and inherit that class for everyone one of my objects that require it. This alone saves me 300+ lines per object I need to write after that.
The second use is not as common, but can prove more useful. Most advanced programmers have a set of objects they use for almost everything. These objects complete generic tasks that cover a wide range of things. If you are a computer programmer in C, you might want to have a class that opens a window very easily (it is time consuming to do it from scratch). Higher level languages (like PHP, VB and python) don’t as often require these generic classes since the tedious low level stuff is taken care of for you. But a PHP programmer may have classes for SQL interaction or user authentication. This way the programmer can complete tedious but common tasks by just copying and pasting these classes into their application.
Classes, however, need to be written right to achieve this reusability. As mentioned before, specifics that are not reused should not be placed in a class. To continue with the games I write, let’s say I’m writing a game of pong. Two of the objects I need to create would be a paddle and a ball. Both these objects require the characteristics I named in the second paragraph. So I make a ball and paddle class that both inherit these properties. So then I only have to do the following (written in pseudo-code to maintain language independence)
Code:
Class ball (Inherits general_object_properties)
Sound_clip Bounce_noise; // The noise that the ball will make when it colides with something
integer points; //The number of points this ball awards when it makes a goal\
end class
Class paddle (Inherits general_object_properties)
bool isHumanPlayer; //Tells the object if it should respond to keypresses
key key_bind_up; //The binding for which key to go up on
key key_bind_down; //The binding for which key to go down on
void key_input(); //The function that checks if the binded keys are pressed and moves the paddle if they are
end class
And that’s it! Both my objects inherited the common properties that they use. Now all I needed to do was specify the specifics and I have a working object. While the ball and paddle classes are specific to this program, the paddle class will be used twice and the ball class may be used more than once. Due to their need for lots of robust functions, they belong in a class. These classes will probably see no use in a later project, the object properties class will.
So what should we avoid placing in classes? Anything non-generic. Different classes do have different levels of needed generalness, the object_properties class has to be extremely generic and only contain the properties that every graphical object would require. The paddle and ball classes were specific to this program, but would be used multiple times in that single program. If I were to have placed the key bindings in the ball class, what use would that be of? That would be needlessly adding a specific feature to a general object. This is where you come into the picture, there is no set answer to what should go in and what should not. Only you can decide where your code needs to be placed. Although, here are a few guidelines to help you decide:
- Ask yourself “why should this be a class”. If you cannot answer this, it probably should remain outside of one.
- Ask “would I have to rewrite this multiple times if I took this out of a class.” If the answer is yes, it probably should not be in a class
- Do your programs have lots of variables defined at the global scope that have numerators (var paddle_1, var paddle_2, ect). If so you might want to be using an object to reuse the code.