Thread: OBJECT ORIENTED VS C STYLE for small projects

It depends on how do you define a small project...
I think that you can always know what to use...

I always go straight-OOP, even on small projects.

The key is this: Do you ever think you'll need to revisit the task on hand? Will you ever need to modify or expand this code? If so, then you want to design so it's easily changable. The key to design is to make your code readable and understandable so you never have to question what you were doing.

I've looked at code I've written in the past and wondered "What the hell was I doing here?". It's best to avoid this by clearly outlining what the job you're doing is, and if need be, what reason you chose for doing it that way.

I'd say design methodology isn't that much a big deal so long as your code is understandable.

Quzah.

I really don't believe in "small projects". Anything you do today may be useful tomorrow. Initially when I start a project, big or small, I think about the services and tools it will need to come out modular. I build these first, test them, and then code the actual program. In fact, my latest project, encapsulating Windows, has taken several months of coding, and the whole time I didn't write a single program. Imagine the anticipation! The entire library now consists of about 20,000 lines of code, though it has been rewritten several times over, so a lot of coding has gone into it. The point is, "the framework should come before the program".

Here's a good exercise, too, by the way:

Write a program as quickly as you can, making no effort to be neat or tidy. Just get it to run without errors. Now delete the project and write the very same program, again, as fast as you can. Repeat as many times as you can stand.

This exercise is useful because it teaches you to have the will to rewrite anything, which is very important, and also keeps you up to speed and sharp, of course. It's interesting too seeing how the program becomes more and more refined each pass.

- Cheers

You're a goober.

The best exercise is just programming constantly. I program at work, program when I get home, and whenever I'm not programming, I'm thinking about it. I think as long as you get a solid 4-12 hours a day at it, you're bound to improve considerably, which is of course, just like anything else. One of my favorite past-times is creating libraries of mechanisms. A mechanism in this sense, is an atomic operation that is often reused. Start with the smallest mechanisms and then build bigger mechanisms with these. Here's an example:

How often have you done this?:

Code:

int Foo(int new_value){
int old_value = value;
value = new_value;
return old_value;
}

This could be considered a mechanism, and it is a very common operation. Templated we get:

Code:

template <typename number>
number cycle(number& value, number new_value){
 number old_value = value;
 value = new_value;
 return old_value;
}

Now we can rewrite Foo() like this:

Code:

int Foo(int new_value){
 return cycle(value, new_value);
}

Now consider this operation:

Code:

void Swap(double a, double b){
 double temp = a;
 a = b;
 b = temp;
}

Of course, the STL has the swap() function, but bear with me. We can reuse the cycle() mechanism since it does half of a swap:

Code:

template <typename number>
void swap(number& a, number& b){
 b = cycle(a, b);
}

Finally, let's consider where you need to an arrays elements over to place a value somewhere in the middle, much like a linked list. Not a very efficient operation, but then sometimes it must be done. Here's a simple solution using the swap mechanism:

Code:

template <typename type>
type shift_back(type array[], int start, int stop, type io = 0){
 int iter = start;
  while(iter < stop){
   swap(array[iter++], io);
  }
 return io;
}


template <typename type>
type shift_back(type array[], int length, type io = 0){
 return shift_back(array, 0, length, io);
}




template <typename type>
type shift_forward(type array[], int start, int stop, type io = 0){
 int iter = stop;
  while(--iter >= start){
   swap(array[iter], io);
  }
 return io;
}


template <typename type>
type shift_forward(type array[], int length, type io = 0){
 return shift_forward(array, 0, length, io);
}

And now let's put it "practical" to use.

Code:

int main(int argc, char *argv[])
{
  char message[81] = {0}, c = ' ';

  strncpy(message,
  "News Flash :: News Flash :: News Flash :: News Flash :: News Flash :: News Flash :: News Flash ::", 80);

       while( !kbhit() )
     {
       printf("\n\n\n\n\n\n\n%s", message);
       c = shift_forward(message, 80, c);
       Sleep(100);
       clrscr();
     }

  getch();

  c = ' ';

       while( !kbhit() )
     {
       printf("\n\n\n\n\n\n\n%s", message);
       c = shift_back(message, 20, 60, c);
       Sleep(100);
       clrscr();
     }
  return 0;
}

So mechanisms are the nuts and bolts of a program. The more you capture, the more generic and effortless programming will be for you.

I hope that was helpful to you. Happy coding.