Re: Calling a private member function from another class

[Ben Bacarisse]

Jii Fox <kerr...@gmail.com> writes:

You posted this in comp.lang.c, probably because you used Google Groups
and that interface removes the ++ from the group name. I've just
re-posted it to comp.lang.c++, quoted. Maybe you'll get an answer that
way.

> Say I have a card game and Windows to draw cards in the game:
>
> class MainWindow
> {
> public:
> // methods
> void start();
> private:
> // fields
> void drawCurrentGameSituation();
> };
>
> Then I create a Match class to handle one card game match between players:
>
> class Match
> {
> public:
> Match(MainWindow* pMainWnd) : mainWnd_{ pMainWnd }
> {}
> void playNextCard();
> private:
> MainWindow* mainWnd_;
> };
>
>
> then I could create a match in MainWindow something like this:
>
> void MainWindow::start()
> {
> Match match{this};
> match.start();
> }
>
> My question is that how can Match call MainWindow from its playNextCard() function when the game
> situation needs to be updated (graphically) so that it could call a *private* drawCurrentGameSituation() function:
>
> void Match::playNextCard()
> {
> // ERROR (the problem): this does not work because drawCurrentGameSituation() is private
> mainWnd_->drawCurrentGameSituation();
> }
>
> I know I could make drawCurrentGameSituation(); public, but I feel it really should be private,
> isnt it?
>
> Also, I want this to work with concole windows (text based GUI), so using some Windows message is not a solution.
>
> So how to solve this issue? I had many times similar issue like this. I wonder what tricks could
> be used here. Or is there some totally different better approach to this existing?
> Thanks

--
Ben.

[Jii Fox]

On Monday, January 11, 2021 at 5:20:41 AM UTC+2, Ben Bacarisse wrote:
> Jii Foxwrites:

>
> You posted this in comp.lang.c, probably because you used Google Groups
> and that interface removes the ++ from the group name. I've just
> re-posted it to comp.lang.c++, quoted. Maybe you'll get an answer that
> way.

> --
> Ben.

oh, thank you. I am actually JiiPee from last year. I moved and cannot use the ThunderBirds anymore, so using alittle web browser now.
Oh, the browser version removes the ++ ....

[Jii Fox]

(I re-post this because it went to C-group by accident first)

[Richard Damon]

I will ask you why you think this function should be private?

A private function tends to mean this is an internal implmentation
detail that others aren't supposed to really need to know about, only I
and my closest friends can use it (friendship being used to allow a
small number of outside elements to be considered part of me).

Your function drawCurrentGameSituation(), from the way you seem to want
to use it, seems to be an entry point for an external request, so should
be public.

[Jii Fox]

On Monday, January 11, 2021 at 2:16:11 PM UTC+2, Richard Damon wrote:
> On 1/11/21 2:20 AM, Jii Fox wrote:
> I will ask you why you think this function should be private?

Oh ok, you think it should be public?

>
> A private function tends to mean this is an internal implmentation
> detail that others aren't supposed to really need to know about, only I
> and my closest friends can use it (friendship being used to allow a
> small number of outside elements to be considered part of me).
>
> Your function drawCurrentGameSituation(), from the way you seem to want
> to use it, seems to be an entry point for an external request, so should
> be public.

Because I am thinking that the drawCurrentGameSituation() is a private operation only between Match object and the Window, so why expose it elsewhere? Like if you create a Window, you would never call it alone outside Match object, right?
An example, lets create the game Windows:

int main()
{
MainWindow window;
window.drawCurrentGameSituation(); // 1
window.start(); // 2
window.drawCurrentGameSituation(); // 3
cout << window.getGameResult(); // 4
}

Above, I am just thinking, it makes sense to call (2) and (4) from the main, but it does not make sense to call (1) and (3) from outside MainWindow ?
So, in what situation all the public would need to draw the game situation like that? It would be very rare that from main() we would need to draw the game situation into the windows because the program is designed so that it is the Match objects responsibility always to draw the windows.

If we make a decision that it is the Match objects responsibility always to draw the game, then what reason would be to expose it to main()?

[Richard Damon]

Then you either need to decide that the Match object is 'part of the
implementation' of a Window, and have the MainWindow class make it a
friend, or make it public.

Making it a friend exposes ALL the internal details to it, so you need
to decide how much you want to expose to whom.

Part of the question comes to what if the Match object uses some other
classes to do some of its work, should those be able to call the draw
function too, or is it restricted to just the original Match class.

It really sounds like this operation is part of the API of the window
class. Access to classes is fairly broad in C++, just because some code
doesn't have a need to access something isn't a reason to hide that
operation from that code.

Access specifiers are about dividing internal details from external API.
Access is restricted to implementation details, and granted to the
defined interface. Things 'inside' the implementation have full access,
and need to be looked at if you change the implementation.

The question comes, do you really think of the Match object as
responsible for the display of the state of the game, and thus part of
the window system, or is it just a user of that system, and should be
accessing it through the API. The existence of the
drawCurrentGameSituation() function seems to imply to me that Match
isn't given implmentation responsibility for a window, and thus that
function is part of the API.

Another good question is what harm would it cause if someone
'unauthorized' called this function. My first guess is probably nothing
major, yes, you waste a lot of time doing the update, but nothing really
'breaks', so it can easily be part of the API.

[Jii Fox]

Thanks for the detailed answer... it helps me to make decision.

"Making it a friend exposes ALL the internal details to it"

- Yes, I dont like this so much.

" or is it restricted to just the original Match class."

- In this project Match is a small class, so pretty sure only Match will be making drawing requests.

"It really sounds like this operation is part of the API of the window class."

- It surely would be the easiest solution. But I am a perfectionist, so I am scared if its not the best :).

"The existence of the drawCurrentGameSituation() function seems to imply to me that Match
isn't given implmentation responsibility for a window, "

- True. No details at all. Match does not have (and definitely should not have) any drawing/windows related stuff inside it. It only deals with the Match related things (like running/starting the games and player management).

"...and thus that function is part of the API."
- hmm, ok.

"Another good question is what harm would it cause if someone 'unauthorized' called this function."

- No harm. I can easily make is such that it causes no harm. Its only the thing "what is the perfect way to do it"... I am just doing this for learning purposes really. I know public access function very easily does the job, but just to learn new things (if there is some trick here to learn).

If you have any new ideas or final recommendation, am happy to hear.

[Jii Fox]

What do you think of using a call back function (the Match class calls Windows class via callback function)? I was thinking it alot also. The limitation of it is that its more difficult to use it (needs to do all that reinterpret casts etc), plus passing the parameters gets a little more complicated.

Or is it best to think here (as the project is small ) that needs to keep things simple? Placing that draw function to be public of the Windows obviously is by far the most simple solution. I was just worried if it is logical to place it there.

[Richard Damon]

My first thought was have you looked at the M-V-C structure (Model -
View - Controller)


The "Game" is divided into 3 major pieces.

First, the Model, it holds the state of the game, but makes no real
decisions except if a given move is valid, and after a move is recorded,
it invokes the View.

The View, is what knows how to display the game that is stored in the
Model. The view will be created with a pointer to the Model and will
give the model a pointer to itself, so the Model can inform it that it
needs to update (this is sort of your callback, but done in a type-safe
manner so no casting needed). The view will also likely link into the
Main Window to implement it drawing on its piece of the screen.

The Controller, this part 'runs' the came, and interacts with the user
through the main window too. Based on the input it gets, it sends
command to the Model to make the moves (either player input or its own
AI). Note, the controller doesn't worry about updating the screen after
a move, as that is the job of the Model, and the Controller actually
CAN'T do the update, as it doesn't have a pointer to the View object.

You achieve your desire to restrict access to the update display
function not by making it private, but by only giving the view object to
those that need it.

[Jii Fox]

On Monday, January 11, 2021 at 5:54:00 PM UTC+2, Richard Damon wrote:

> My first thought was have you looked at the M-V-C structure (Model -
> View - Controller)
>
>
> The "Game" is divided into 3 major pieces.

Yes I am familiar with it. Actually I use MFC and Document/Window/Frame there which is similar.

>
> You achieve your desire to restrict access to the update display
> function not by making it private, but by only giving the view object to
> those that need it.

Yes you got me thinking. So I am actually now planning to put all draw/UI functions into public section so that becomes an API.
I might come back after ready....

[Melzzzzz]

And then?


--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Jii Fox]

On Wednesday, January 13, 2021 at 12:05:42 AM UTC+2, Melzzzzz wrote:

> > I know I could make drawCurrentGameSituation(); public, but I feel it really should be private,
> > isnt it?


> And then?
>

Sorry what do you mean?