Sign In
Create Account
Follow Us on Twitter
Subscribe on Youtube
I have a large amount of source code in my computer that I have written on my own. It's good code, because I have found the objects I've programmed to be remarkably reusable. The project I was working on (sorry, NDA) required code that was remarkably similar to another object I had programmed in the past with C++, so I went and found that source code, copy/pasted the source code document with that object, included it in the new project, and was immediately able to use it out-of-the-box without any problems in an entirely different program. Even though the object had been programmed in one situation to serve that purpose, it could be picked up, brought to an entirely alien program, and dropped in with no changes to it whatsoever. This made me think of my attempted post to explain the advantages of OOP, and I wanted to share with you this example:
Say you wrote a project 2 years ago who's job was to keep track of tickets purchased at a movie theatre. One of the objects you programmed in this accepted a const char* as a name and an integer as a cash value, then kept it. (I'm using a simple example, sorry) You would use this object to keep track of the movies playing each day in a data array, and it would look something like this:
class MovieData
{
public:
MovieData(const char* n, unsigned long long t)
{
/* This constructor just runs init(const char*, long) */
init(n, t);
}
MovieData(const char* n, double t)
{
/* This constructor does the same as above, except changes
the double to a long. */
if (t > 0) // double can't be unsigned.
init(n, static_cast<unsigned long long>( (t * 100) ));
else
init(n, 0); // If t is negative, just set it to zero.
}
~MovieData()
{
/* Alternatively, if you'd rather not manually manage memory,
you can use std::auto_ptr for the std::string. */
delete name;
delete[] tpString; // You can delete null pointers safely.
}
const char* getName()
{
return name->c_str();
}
const char* getPriceString()
{
/* We should cache the string. This makes it so the object
is responsible for deleting the tpString, and also makes
this function more efficient. Since it returns a const char*
the user shouldn't be able to delete it. */
if (tpString == 0) maketpString();
return tpString;
}
unsigned long long getPriceLL()
{
return ticketPrice();
}
double getDoublePrice()
{
return (static_cast<double>(ticketPrice) / 100);
}
private:
std::string *name;
unsigned long long ticketPrice;
char* tpString;
void maketpString()
{
std::string temp;
std::stringstream ss(temp, std::ios_base::in)
ss << (ticketPrice / 100) << "." << (ticketPrice % 100);
tpString = new char[temp.length() + 1];
strcpy(tpString, temp.c_str());
}
void init(const char* n, unsigned long long t)
{
/* This is the initialization function for our object, this must
be ran by each constructor to get the object going. No other
method in this object should call init. */
name = new std::string(n);
ticketPrice = t;
tpString = 0;
}
};
Now, obviously, this isn't nearly anything like a fully fleshed out class, but assuming it were you wouldn't want to write it a second time. Also, assuming you had written this class, it'd be separated into two documents (unless of course it was a template...), the .cpp source file and the .h header file. Presumably, you may consider yourself done with this now, but I'd say you were wrong. What about documenting the API? Java has the very convenient javadoc, but for C++ programmers, you'll need to do it by hand. You should write at the very least a text file containing API information, namely what each function in the object does, how to instantiate the object, what it's dependencies are, etc. There's not too much you have to write with the above object, and I know it seems like a chore, but think about you two years from now. The simple fact is, if you find source code you wrote two years ago, you're not going to remember it, and that code might has well have been written by someone else. In this case, how could you hope to reuse the object if you haven't even got an API backing it up? THAT is why you should always document your code, even if you can't imagine (now) why you'd reuse it!
Alright, now fast forward those aforementioned two years and let's assume you wrote the API. Let's also assume you're working on another project, except this time you need an object that can keep track of the title of a movie at a video store and it's rental price. You remember back to when you wrote this cinema software, and decided to get the code. You haven't the foggiest how to use it, but you've written an API, so you read it, relearn how to use it, then copy the .cpp and .h source files and transfer them into your new project. From there, you can now completely reuse the object as if it were written for your program with no changes whatsoever! What this means is you've saved a lot of time not writing a class you otherwise would have had to!
I know this was a contrived example, but I think it does illustrate well one of the strengths of OOP, which is all of the data is encapsulated. Think about it, lets say this was written in C, what if the functions were written in different documents? What if the data structures were different in the two programs? If this were the case, no matter what you did you'd have to rewrite a lot of program code, whereas when it's encapsulated in a single object you can drop it in and use it from the get go. This also means that functions in one object should never interfere with properties of other objects, nor should you ever expect things that are obviously there in your program right now, but may not be there in future software you write.
Well, I'm done preaching, I just wanted to provide an example of me getting something out of OOP. If you've done some programming, why not provide an example of you reusing old code? Maybe I'm wrong, and you can just as easily reuse C code. I'd like to hear what all of you have to say.
Back to top
