Too many arguments for functions

[SuperStinger]

Hi all

This is more a design problem than a programming one

Ive done some reading and it seems that having a function with more than 3 or 4 arguments is somewhat unacceptable ( something wrong with the design of the program ).

I know how to reduce the arguments, but it requires more work in the main function. Take this for example...

I have a draw Rectangle function here ( For SDL ), takes the x, y, width, hieght, inside colour, outside colour and the thickness of the rectangle.

void drawRect ( int x, int y, int w, int h, SDL_Surface* screen, int colourOutline, int thickness, int fill );

Some say its too many arguments, I could write it like this:

void drawRect ( SDL_Rect rect, SDL_Surface* screen, scheme* pScheme );

where the SDL_Rect holds x, y, width and hieght
and pScheme holds the colours and thickness

Even though the second bit of code looks somewhat nicer, every time i want to create a different type of rectangle i have to change the rect and pScheme attributes in the main function, which does not confine it to one line.

The main function will end up looking like this:

rectArg.x = 0;
rectArg.y = 200;
rectArg.w = 500;
rectArg.h = 100;
schemeArg.colourOutline = 0xFF00FF;
schemeArg.thickness = 3;
schemeArg.fill = 0x00FF00;

drawRect ( &rectArg, screen, &schemeArg );

instead of this:

drawRect ( 0, 200, 500, 100, screen, 0xFF00FF, 3, 0x00FF00 );

Which is all on one line ( Much nicer )

Im not sure which approach to take! Many opinions on this matter would be much appreciated

Many Thanks, Super_Stinger

[Disch]

Other graphic libs (like SFML) replace a big draw function with 'Sprite' objects. Although this doesn't really end up being any better.. it's just different. Ultimately, instead of passing all the params to the Sprite's draw function... you have to call 2 or 3 setters before drawing. So it basically has the same effect but is more steps... similar to what you're seeing with your 'scheme' idea.


IMO, there's nothing necessarily wrong with having a function that takes a lot of parameters. As long as the code is clear, easy to follow, and not error prone.

[SuperStinger]

Cheers for that Disch ( and a quick reply too )!

I just like to see what other people do.

[Disch]

I typically don't have a generic 'drawRect' function. Rather, I call whatever API's drawing function directly.

The real design challenge here is limiting the areas of code you're drawing from. With an object oriented design, you won't be drawing individual rectangles from your overall logic code. But rather, you'll have individual objects that have their own draw function. That function should really only have one or two params.

class Player
{
public:
   void draw( SDL_Surface* screen );

// ...
};

The player object would know the player's position, animation phase, etc, etc already. It would all be self contained. So your overall logic code could just draw the player by doing player.draw(screen); and would not have to worry about telling the player where or how to draw itself.

Though I typically even go a step further and encapsulate the entire animation inside an Animation class. This class would keep track of where in the current animation the object is so that it would know what to draw. The player would them simply have one or more of these, and player.draw() would merely call draw for all its owned animations.

OOP is great.

[Duthomhas]

Disch +1

[SuperStinger]

Indeed OOP is quite great, but i forgot to mention that im writing in pure C

( That may explain why this is much more of an issue... )

[Disch]

You can use OOP in pure C (see stdio -- the FILE structure is encapsulated quite well)

OOP is a programming paradigm. While some languages have features to make it easier... it is possible in just about any language.

[SuperStinger]

Well thank you very much, i think i am already using many features of an OOP paradigm.

For the button type ( whatever you like to call it ), i have an initialization function ( constructor ) and a free function ( destructor ). Then related functions for that button.

Most forums i tend to run into, they seem very 'concrete' on C++ OOP design and simply say to switch to C++ instead of C. I prefer C because of its direct simplicity, and because you know everything that is going on 'under the hood' should i say.

[Disch]

Most forums i tend to run into, they seem very 'concrete' on C++ OOP design and simply say to switch to C++ instead of C. I prefer C because of its direct simplicity, and because you know everything that is going on 'under the hood' should i say.

There are tradeoffs. I won't say one is better than the other, but I will say I personally prefer C++ over C by a great deal. I could give reasons but I'm sure you've heard them all before... so I'll spare you.

For personal projects... use whatever you want. If you like C, then use C. Don't let people bully you into doing something you don't want to do.

[Duthomhas]

Disch +1

There's nothing wrong with C.

[SuperStinger]

Ahaha, please spare my life for that i am only C weakling! ;)

Cheers guys for the discussion!