Avoiding use of a getter

[Paul N]

I was wondering if I could cut down, or avoid, the use of a getter
function.

In my program, I have a class Note which represents a note. Originally
it had lots of functions, but to try and cut down on this I created
another class Displayhandler which would handle most of the details
related to displaying the note in a window on the screen.
Displayhandler has a variable hWnd which, if the note is being
displayed, is a handle to the window it is shown in. Displayhandler
has a function get_hwnd which returns this.

At one stage, I tried to cut down my use of this function, and I got
it down to about two uses. But as I've done more coding, I seem to
have lost my touch and it now gets used eight times. Mainly these are
to identify a "parent" window for the functions MessageBox,
DialogBoxParam and ShellExecute.

I appreciate that I could write member functions for Displayhandler
which call MessageBox, DialogBoxParam and ShellExecute, feeding in the
right value for hWnd, but as far as clarity goes this seems worse than
the problem. I would have thought if Note wanted to call any of these
three functions it ought to be doing it itself under its own control.

To make matters worse, I have now put in a check that, if the user
asks to save, it first checks whether any of the notes are being
edited. If so, it puts up a message asking the user what to do - the
message varies slightly depending on whether there is one note being
edited or more than one, and in the former case it has the offending
note as the parent. This required Note itself to have a get_hwnd. I
can't see any easy way round this if both messages are produced by
feeding appropriate parameters into the same DialogBoxParam call.

On my first attempt at cutting down, several uses seemed essential one
day and then the next I'd think of a way round it. But this time the
ideas don't seem to be coming.

Can anyone offer any advice?

Thanks.
Paul.

 

[Victor Bazarov]

I was wondering if I could cut down, or avoid, the use of a getter
function.

In my program, I have a class Note which represents a note. Originally
it had lots of functions, but to try and cut down on this I created
another class Displayhandler which would handle most of the details
related to displaying the note in a window on the screen.
Displayhandler has a variable hWnd which, if the note is being
displayed, is a handle to the window it is shown in. Displayhandler
has a function get_hwnd which returns this.

At one stage, I tried to cut down my use of this function, and I got
it down to about two uses. But as I've done more coding, I seem to
have lost my touch and it now gets used eight times. Mainly these are
to identify a "parent" window for the functions MessageBox,
DialogBoxParam and ShellExecute.

I appreciate that I could write member functions for Displayhandler
which call MessageBox, DialogBoxParam and ShellExecute, feeding in the
right value for hWnd, but as far as clarity goes this seems worse than
the problem. I would have thought if Note wanted to call any of these
three functions it ought to be doing it itself under its own control.

To make matters worse, I have now put in a check that, if the user
asks to save, it first checks whether any of the notes are being
edited. If so, it puts up a message asking the user what to do - the
message varies slightly depending on whether there is one note being
edited or more than one, and in the former case it has the offending
note as the parent. This required Note itself to have a get_hwnd. I
can't see any easy way round this if both messages are produced by
feeding appropriate parameters into the same DialogBoxParam call.

On my first attempt at cutting down, several uses seemed essential one
day and then the next I'd think of a way round it. But this time the
ideas don't seem to be coming.

Can anyone offer any advice?

Seems that the obvious solution is a type conversion operator, but it's
so obvious that I'm reluctant to suggest it...

class DisplayHandler { ...
public:
operator HWND () const { return hWnd; }
};

Yes, it has some perhaps unintended consequences, like that you can use
your DisplayHandler object in other expressions that expect hWnd, and
it's the trade-off.

Did I miss something in your explanation?

V

 

[Paul N]

Seems that the obvious solution is a type conversion operator, but it's
so obvious that I'm reluctant to suggest it...

    class DisplayHandler { ...
    public:
       operator HWND () const { return hWnd; }
    };

Yes, it has some perhaps unintended consequences, like that you can use
your DisplayHandler object in other expressions that expect hWnd, and
it's the trade-off.

Did I miss something in your explanation?

Thanks Victor. That hadn't occurred to me.

But I think what I am worried about is making the value of hWnd
available at all. This means that things can mess about with the
window without Displayhandler being aware of it. Which seems unideal.
Is there a clever way to avoid it?

Thanks.
Paul.

 

[Victor Bazarov]

Thanks Victor. That hadn't occurred to me.

But I think what I am worried about is making the value of hWnd
available at all. This means that things can mess about with the
window without Displayhandler being aware of it. Which seems unideal.
Is there a clever way to avoid it?

If you want to limit what others can do, it got to be the functionality
your 'DisplayHandler' offers (directly or by means of some intermediate
class that is designed to work with it). I believe there is no other
way around it. As soon as you give a window handle out, people can
start sending all kinds of messages to it, etc. It doesn't really
matter whether you do so from a 'getter' or from a type conversion
operator function.

Seems that you're in for more high-level design and your problem isn't
of the language kind, really.

V

 

[Jorgen Grahn]

I was wondering if I could cut down, or avoid, the use of a getter
function.

In my program, I have a class Note which represents a note.

Nitpick: a note as in a musical note, a short text, a Post-It (TM)
with something scribbled on it, ... ?

Class names are rarely informative without plenty of context.

/Jorgen