Re: Constructors with long parameter list

From:

"Allan W" <allan_w@my-dejanews.com>

Newsgroups:

comp.lang.c++.moderated

Date:

5 Aug 2006 01:18:21 -0400

Message-ID:

<1154733396.612279.19550@h48g2000cwc.googlegroups.com>

Victor Bazarov wrote:

Yes, but in that case one just puts off the inevitable: the need to
specify those arguments. So, what would be the justification to
generate all this complexity? If the class needs 20 arguments of
type double to initialise it, give the damn 20 arguments to it, and
there is no need to build an initialisation piece upon some other
initialisation piece...

The technique of subdividing initialisation into partitions of sort
buys (IMNSHO) absolutely nothing. And you can take it to extreme
(to absurd, essentially).

It doesn't always help... but any tool we have, can be taken to absurd
extremes. We could replace every if statement with a switch statement,
but of course that would be absurd.

Subdividing arguments doesn't always help, but sometimes it helps a
lot.
Consider a hypothetical function that creates a window in a GUI:

MyVendor::WindowID childWindow - MyVendor::CreateWindow(
    "ClassName", // Window Class Name
    "Child Window", // Caption for new window
    MyMenu, // Menu for new window
    ScreenWidth/4, // Left
    ScreenHeight/4, // Top
    ScreenWidth/2, // Width
    ScreenHeight/2, // Height
    MyVendor::CAP_NORMAL, // Caption style
    MyVendor::FRM_DIALOG, // Border style
    MyVendor::SCR_BOTH, // Scrollbars
    MyVendor::SIZE_NORM, // Do NOT minimize or maximize yet
    MyVendor::BTN_MIN |
        MyVendor::BTN_MAX |
        MyVendor::BTN_CLOSE |
        MyVendor::BTN_SIZE, // All four buttons
    MyVendor::POS_FRONT, // Window is in front of exiting windows
    MyVendor::CLR_WHITE, // Background color
    MyVendor::CLR_BLACK, // Foreground color
    MyVendor::CLR_GREY, // Border color
    MyVendor::CLR_BLUE, // Caption color
    MyVendor::CLR_GREY, // Button background color
    MyVendor::CLR_BLACK, // Button foreground color
    true, // Enabled / Disabled
    true); // Make window visible now

That's 21 arguments. Get them in the wrong order, and things might not
work at all as intended. Contrast this to:

MyVendor::Position myPosition(
    ScreenWidth/4, // Left
    ScreenHeight/4, // Top
    ScreenWidth/2, // Width
    ScreenHeight/2); // Height
MyVendor::Styles myStyles(
    MyVendor::CAP_NORMAL, // Caption style
    MyVendor::FRM_DIALOG, // Border style
    MyVendor::SCR_BOTH, // Scrollbars
    MyVendor::SIZE_NORM); // Do NOT minimize or maximize yet
MyVendor::Buttons myButtons( // All four buttons
    MyVendor::BTN_MIN,
    MyVendor::BTN_MAX,
    MyVendor::BTN_CLOSE,
    MyVendor::BTN_SIZE);
MyVendor::Colors myColors(
    MyVendor::CLR_WHITE, // Background color
    MyVendor::CLR_BLACK, // Foreground color
    MyVendor::CLR_GREY, // Border color
    MyVendor::CLR_BLUE, // Caption color
    MyVendor::CLR_GREY, // Button background color
    MyVendor::CLR_BLACK); // Button foreground color

MyVendor::WindowID childWindow - MyVendor::CreateWindow(
    "ClassName", // Window Class Name
    "Child Window", // Caption for new window
    MyMenu, // Menu for new window
    myPosition, // Position
    myStyles, // Styles
    myButtons, // Buttons
    myColors, // Colors
    MyVendor::POS_FRONT, // Window is in front of exiting windows
    true, // Enabled / Disabled
    true); // Make window visible now

This is actually slightly MORE code -- but it's easier to read and
debug. If it now takes 14 microseconds to create a window, instead of
12
microseconds... do we care? It's actually MORE efficient, if the code
is
creating a lot of almost-identical windows (say with slightly different
styles or buttons), because we can re-use the parts that haven't
changed
(i.e. myColors). But even in the least flattering case (the program
only
creates one window), compare the original code with

MyVendor::WindowID childWindow - MyVendor::CreateWindow(
    "ClassName", // Window Class Name
    "Child Window", // Caption for new window
    MyMenu, // Menu for new window
    MyVendor::Position(
        ScreenWidth/4, // Left
        ScreenHeight/4, // Top
        ScreenWidth/2, // Width
        ScreenHeight/2), // Height
    MyVendor::Styles(
        MyVendor::CAP_NORMAL, // Caption style
        MyVendor::FRM_DIALOG, // Border style
        MyVendor::SCR_BOTH, // Scrollbars
        MyVendor::SIZE_NORM), // Do NOT minimize or maximize yet
    MyVendor::Buttons( // All four buttons
        MyVendor::BTN_MIN,
        MyVendor::BTN_MAX,
        MyVendor::BTN_CLOSE,
        MyVendor::BTN_SIZE),
    MyVendor::Colors(
        MyVendor::CLR_WHITE, // Background color
        MyVendor::CLR_BLACK, // Foreground color
        MyVendor::CLR_GREY, // Border color
        MyVendor::CLR_BLUE, // Caption color
        MyVendor::CLR_GREY, // Button background color
        MyVendor::CLR_BLACK), // Button foreground color
    MyVendor::POS_FRONT, // Window is in front of exiting windows
    true, // Enabled / Disabled
    true); // Make window visible now

About the same number of lines of code -- but now if you get the
arguments in the wrong order, the compiler can complain (cannot convert
MyVendor::Styles to MyVendor::Position!)

That's just a hypothetical case off the top of my head... I'm sure that
real life could provide even more dramatic results.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]