heatxsink.com

Alright, so there's this nice lady/girl that works here and she got reamed the other day cause I honestly don't think she understands object oriented stuff all that well. But how they got her was on this really easy concept. So the object oriented paradigm is all based around having a class for everything and/or anything. So please see my nicely written short and condensed example, now remember this is an example which an ideal condition, I'm sure there are better examples but this one came off the top of my head....so please just try to see what I'm saying and don't get caught up on the frivolous details.....
// Java Code Snippetclass AddressBookEntry{private string firstName;...public void setFirstName( string firstname ){this.firstName = firstname;}public string getFirstname( ){return this.firstName;}...}
// C# code snippetclass AddressBookEntry{private string firstName;...public string FirstName{set{this.firstName = value;}get{return this.firstName;}}...}
So as you can see here with something with a lot of data to manipulate in the class scope one has to make a decision, do you hide your data internally in the class by making all of your class member variables "private" and write what is called "setters", and "getters". Do you then decide not to sling a bunch of code...and just expose all of those fields to the world and make them "public"? Or depending on the language you're using which in our case is C++ do you decide to make a structure and pass the structure around? Historically, the reason for "setters" and "getters" is because some languages such as Java didn't implement structures. Like in C/C++, where you could define a data type with just fields of data of different types (i.e. int, long, double, char..etc..). So someone comming from the Java world such as our nice co-worker that got her ass chewed out and is now emerced in C++ land welcome back to a world of full control! See this is where I'd like to interject that I feel that "managed" code really dumbs people down and doesn't allow them to really understand what is going on with the machine, at the machine level. Problem is there are a ton of idiots out there, and there's this cool word called "productivity" that most managers love to see because they are pressured by deadlines. Drones!!! So back to our "setter" and "getter" dilema. So as you could imagine, all of the data that goes into a "AddressBookEntry" there's a lot so for every field in that entry (i.e. full name, address, telephone numbers, emails, web addresses..etc.). So in C++ one could do one of two things make a struct or just make a class and implement the copy constructor, assignment operator, and destructor because in our case we know there is going to be more than one AddressBookEntry, so we know this class is most likely going to reside in some sort of collection. So implementing those three member functions (methods) would allow our class to be used properly in a STL container such as a vector, map, or multimap.
/* AddressBookEntry.H or AddressBookEntry.hpp */#ifndef ADDRESSBOOKENTRY_H_#define ADDRESSBOOKENTRY_H_#include class AddressBookEntry {public:// constructorAddressBookEntry( void );// destructor~AddressBookEntry( void );// copy constructorAddressBookEntry( const AddressBookEntry & );// assignmentAddressBookEntry & operator=( const AddressBookEntry & );std::string first_name_;private:void swap( AddressBookEntry & ) throw();};
/* AddressBookEntry.C or AddressBookEntry.cpp */#include #include "AddressBookEntry.H"using namespace std;// ConstructorAddressBookEntry::AddressBookEntry( void ): first_name_( "" ){/* Left empty */}// DestructorAddressBookEntry::~AddressBookEntry( void ){/* Do class clean up here */}// Copy ConstructorAddressBookEntry::AddressBookEntry( const AddressBookEntry & info_to_copy ): first_name_( info_to_copy.first_name_ ){/* deliberately empty */}// Assignment OperatorAddressBookEntry & AddressBookEntry::operator=( const AddressBookEntry & right_hand_side){AddressBookEntry temp( right_hand_side );swap( temp );return *this;}// swap helper functionvoid AddressBookEntry::swap( AddressBookEntry & swapper ) throw(){// swap member variablesstring temp_first_name_ = swapper.first_name_;swapper.first_name_ = first_name_;first_name_ = temp_first_name_;return;}
I know there's more explaining to do, and I hope I can come back and finish this example up and explain my intentions and caveats!