When to: Including Headers vs. Getting an Object Instance

[iacondios]

This is a question about C++ style in general.

Succinctly, the question is this: If I have two separate files, say file1 and file2, containing functions appropriate to that file's purpose, when is it appropriate for file1 to include a header for file2 to use file2's functions, and when is it appropriate to make file2 a class and get an object instance of it?

I am making a small database that can keep track of the number of campus meal "swipes" that you use per quarter to help you better manager them.

Currently, my program consists of several .cpp files. None of these are currently classes, and by classes I mean they don't have a

class classname
{
public:
function1()
{
}
private:
function2()
{
}
};

format. Instead, they are simply a collection of functions with data types used between the functions. At the moment, my main.cpp file which organizes running of the program simply includes headers to the classes which it uses and calls the functions in that manner.

Recently, one of my friends who is a skilled programmer told me that this was terrible style, since object oriented programming should probably have objects.
While I agree this is a reasonable conclusion, at the same time my program is functioning perfectly fine with zero classes and zero objects, instead sharing data via headers and reference passing.

Is there a benefit to using one over the other? When are headers required and when can instantiating objects do the job? Is it simply a matter of good style?
If any C++ experts out there could enlighten me, I would be quite grateful.

If you would like a snippet of my code, I can edit to include some if necessary.

[Disch]

From what you're describing, it sounds like you might be mimicing OOP without using C++'s OOP language features.

Are you doing stuff like this?

void dosomething( mystruct* foo );  // does something with foo
void dosomethingelse( mystruct* foo );  // does something else

//.. etc 

If you are, then yeah you're probably better off changing mystruct to a class and making those member functions.

at the same time my program is functioning perfectly fine with zero classes and zero objects

OOP doesn't let you do anything you couldn't otherwise do. It's possible to write even the most complex program without using any OOP design decisions.

All OOP does is potentially make your code easier to write, maintain, and understand.

Is it simply a matter of good style?

Yes.

Basically if you have something in your code that can be represented with a class, it makes it easier to represent it that way. Intelligently designed classes make code easier to write.

If you would like to post one of your headers as an example I could probably give tips on how to adapt it to OOP style and illustrate why it would be better that way.

[iacondios]

Ah yes- that does sound exactly like what I am doing. Especially considering the language I used the most before C++ was C#!

The code snippit you posted is also what I am doing.
Here are some code samples:

int main()
{	

	//Initialization and Loading
	YearRecord *AllRecords;
	AllRecords = new YearRecord(2011);
	LoadDatabase(AllRecords);
	LoadTodaysDate();
...
}

The basic premise is to represent each day of the year through a combination of arrays and a linked list called YearRecord: each member of the list represents one year, and contains a 12x31 array to hold the actual data being stored. So essentially, each day of the year gets its own data storage space in memory, and also when stored in a .txt .

The two functions called belong to two separate files, but they aren't actually classes. For instance, to use LoadDatabase(), I included a header...

#include "DatabaseManager.h" 

The header (DatabaseManager.h) contains function prototypes for the two functions in the file DatabaseManager.cpp:

#ifndef DATABASEMANAGER_H
#define DATABASEMANAGER_H

#include "YearRecord.h"

void LoadDatabase(YearRecord*);
void SaveDatabase(YearRecord*);

#endif 

and then the function itself is detailed in the file DatabaseManager.cpp, with an include to its own header.

From what I was taught, doing this allowed me to include the header of any file I wished to call functions from, and then the compiler (or linker?) would figure out the details from the file fleshing out the header's function declarations.

It seems, that this would be similar to making DatabaseManager a class, getting an object instance of it in main.cpp, and then calling functions from there. But instead, I am using the header include as my "instance" from which to call functions. OOP imitation is probably an excellent diagnosis.

So from what I gather, in order to better employ good C++ OOP, I need to make each of my .cpp files into classes so that they can have object instances.