Question

I’m starting the process of learning C++ and object oriented design. What are the known / common techniques for converting procedural code to object-oriented code? What design choices make sense for the following code?

typedef struct
{
    int sector;
    int sectorPos;
}EndPosition;

typedef struct
{
    int rotateAngles;
    double brakingFactor;
}WheelStop;

WheelStop stops[][6] =
{
     /* data removed for brevity */
};

typedef struct
{
    int numImages;      /* Number of images in win amount string */
    int pixWidth;
    int indexes[7];     /* indexes into NumberImages[] */
}WinAmountData;

typedef struct
{
    int xOffset;    /* pixel count offset before next digit */
    std::string fileName;
    //char fileName[20];
    cairo_surface_t *image; 
}ImageInfo;

ImageInfo NumberImages[] =
{
     /* data removed for brevity */
};

enum { DOLLAR = 10, EURO, POUND, YEN };

double DegreesToRadians( double degrees )
{
    return((double)((double)degrees * ( (double)M_PI/(double)180.0 )));
}

int InitImages( void )
{
     /* uses NumberImages */
}


void DestroyNumberImages( void )
{
      /* uses NumberImages */
}

int ParseWinAmountString( char *string, WinAmountData *amtData )
{
        /* uses WinAmountData and enum */
}

gboolean rotate_cb( void *StopPos )
{
      /* uses EndPosition and stops */
}

static gboolean on_expose_event(GtkWidget *widget, GdkEventExpose *event, gpointer data)
{
     /* uses CairoImage class */
}

static void destroy (GtkWidget *window, gpointer data)
{
     /* cleanup GTK stuff */
}

I’ve given it some thought, and I can see maybe two classes:

• CWinAmount which would encompass the data structures and functions that handle the currency amounts to be placed on the “spinning wheel”.
• CWheel which would encapsulate the wheel data structures and functions that control the wheel animation mechanics.

But I’m just not sure if this is a good design.

Answer 1

I’m not going to provide exact details on how to do such a conversion (that’s really up to you). But, your described approach sounds like a perfectly reasonable design. Generally when converting code to OO I find the most obvious groupings of functions and structs with shared state and wrap those together. Then I look at what functions are remained and try to determine if they belong to an existing object, have some relation that could justify grouping them, or leave them as generic functions (if I have the option).

In general there’s no secret to converting to OO style and most approaches simply try to group any/all shared state/functionality into blocks (objects).