How to not OOP

Hi everyone!

I must admit, I'm not up to date with the series and I haven't watched enough of them to get passed the initial platform layer work. Because of this I don't know how multiple files are handled - other than what Casey explained about compiling a single file and including all others directly instead of through the use of header files.

I've started experimenting with some simple stuff and ignoring graphics, so basically just console output and I'm immediately finding it difficult. My problem is that I'm stuck thinking in OOP. Can someone who is a bit more used to thinking non-OOP help me with a simple example?

Let's say I have BobTheMiner, BobsWife and BobsDaughter and I want each one to be able to say something. I want to put each ones code in seperate files to make it more manageable so I do

1
2
3
4
5
6
7
#include "Bob.cpp"
#include "BobsWife.cpp"
#inclide "BobsDaugther.cpp"

int main() {
// call each method from each file
}


Then what? My initial thought was to create one method each like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
//Bob.cpp

char* BobSays(){
    return "Bob says: I'm hungry again";
}

//BobsWife.cpp

char* BobsWifeSays(){
    return "Bobs Wife says: I want to take a walk";
}

//BobsDaughter.cpp

char* BobsDaughterSays(){
    return "Bobs Daughter says: I love my fluffy cat";
}


But then I thought that maybe it would be best to just create a struct and put the sentence in the struct so that each person is represented by a struct and then there is one method that takes a struct and produces the sentence.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
struct Person{
   char* name;
   char* sentence;
}

char* PersonSays(Person* p){
    return concatenation of p->name and p-> sentence;
}

//Bob.cpp
Person *bob = //allocate memory and set name and sentence

//BobsWife.cpp
Person *wife = //allocate memory and set name etc.


That seems like it's more in line with the Data->transform->newData mentality of data driven design. I'm I on the right path here?

/Robert
You've got the right approach here.

The critical thing to notice is: you're factoring that struct out of already existing code. It's a bundle of data that is *actually* used together consistently. This method of creating objects out of existing patterns in your code is good; the OOP mantra of modeling your objects and then structuring code around *them* is what is mistaken. Data should be grouped together by usage pattern, not world-modeling.
Don't think about the structure of the program. Think about what you want to get done. You want to print statments out. Here's the simplest version that gets the job done:

myprint( "Bob says: I'm hungry again" );
myprint( "Bobs Wife says: I want to take a walk" );
myprint( "Bobs Daughter says: I love my fluffy cat");

There. You're done. The program produces the correct output with the least work.

Next step. Make the problem more complicated. Let's say you want to have a bunch of things that any of them could say. You want to pick a random speaker and a random statement, and do this five times.

First you'll need to write something to generate a random number. So do that, or call rand(), or do what casey did and just copy/paste a list of ten random numbers (5 speakers, 5 statements).

Ok, now you have a random number, you could make a big case statement and put all the "Bob says: Blah.."; break; Then you could cut and paste that and replace Bob with Bob's Wife. But that's getting verbose. We're not programmers, we're just glorified text compressors. So that's probably a good time to write a string concatenation function. Ok. done. etc.. keep going like this. It's much better to try to solve a real problem than use made up examples like this.

I'm not thinking about class hierarchy. I'm not thinking about an Speaker class with a Name. I'm thinking about the task I'm trying to solve, and what's the least work (for you if you're generating code, or the least work for the CPU if you're optimizing it).
Thank you both for some great comments.
That part about producing the leas work to get the job done really hit home I think. And honestly it makes my job so much easier as it cuts away soo many things that I have to think about at any one time. It's always just the current problem and then I trust myself to be able to solve any other problem that comes along in the future :)