Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

About hiding classes private members in another class

36 views
Skip to first unread message

JiiPee

unread,
Dec 15, 2017, 5:07:19 PM12/15/17
to
I feel like I just invented something myself nobody ever thought about!!
hehe. Just joking, am sure somebody has done similar before.

I have a question that is this idea good. I present it with a simple
game class example. We all know that its better to get access to data
members preferable via functions (like if parent class has private
members, then the inherited class would get access to them by protected
funtions and the variables are not in protected section but rather
privates.).

Ok,.. Here first the "normal" version without "my invention" :) :

class Board
{
    // data/functions for the board
};

class Game
{
public:
    void startGame() {
        if (!m_isGameOn) {
            m_board = make_unique<Board>();
            m_isGameOn = true;
        }
    }
private:

    void gameOver() {
        m_isGameOn = false;
        m_board.reset(nullptr); // board not needed anymore
    }

    bool m_isGameOn{false};
    std::unique_ptr<Board> m_board;
};


So we get access to private member directly. And because gameOn is
linked to board here, we do them together when the game starts (many
times variables are linked with each others somehow like this ... just
an example, maybe not best... but just to illustrate the point).

Now, ....lets see "my invention" version (which I feel might be better):

class Board
{
    // data/functions for the board
};

class GamePrivate
{
public:
    bool isGameOn() { return m_isGameOn; }
    void gameStarts() {
        if (!m_isGameOn) {
            m_board = make_unique<Board>();
            m_isGameOn = true;
        }
    }
    void gameOver() {
        m_isGameOn = false;
        m_board.reset(nullptr); // board not needed anymore
    }
private:
    bool m_isGameOn{ false };
    std::unique_ptr<Board> m_board;
    // other private variables for Game
};

class Game
{
private:
    void startGame() {
        m_data.gameStarts();
    }
    GamePrivate m_data;
};

So, all (private) data is hidden behind GamePrivate class, thus we
cannot modify any private variabe directly! Because many times I
actually want this: I dont want the *Game* class to be able to directly
modify its own private variables. Now all variables are accessed by a
(getter/setter) function from GamePrivate. So this way Game glass cannot
mess up for example the connection between m_board and m_isGameOn: like
after starding the game Game class cannot change only one of them by
accident.


Is this a good idea to have all private data hidden in another class so
that Game class cannot get direct access to its variables?



JiiPee

unread,
Dec 16, 2017, 7:17:13 AM12/16/17
to
On 16/12/2017 10:54, Stefan Ram wrote:
> JiiPee <n...@notvalid.com> writes:
>> Is this a good idea to have all private data hidden in another class so
>> that Game class cannot get direct access to its variables?
> http://en.cppreference.com/w/cpp/language/pimpl
> http://wiki.c2.com/?PimplIdiom
> http://www.cppsamples.com/common-tasks/pimpl.html
>
yes I know pimpl idea, but I was wondering should *all* private raw
variables be behind pimpl? Because I see classes where they use pimpl
but only part of the private variables are put there.

Öö Tiib

unread,
Dec 16, 2017, 9:30:03 AM12/16/17
to
On Saturday, 16 December 2017 00:07:19 UTC+2, JiiPee wrote:
>
> Is this a good idea to have all private data hidden in another class so
> that Game class cannot get direct access to its variables?

On general case if some complexity is added without purpose then it
is not good idea but over-engineering. Is there purpose? What
it is? What problems it solves?

JiiPee

unread,
Dec 16, 2017, 11:43:32 AM12/16/17
to
But do we always know the future? so it would be ready there if needed
like that in the future?

Öö Tiib

unread,
Dec 16, 2017, 1:05:34 PM12/16/17
to
You answered to questions with questions. That indicates you do not
have answers. We can't make software to solve problems that we can't
even describe right now. So ... describe the problem.

As for your questions ... adding complexity because of future (that we
don't know) violates YAGNI principle and KISS principle.
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
https://en.wikipedia.org/wiki/KISS_principle
Additionally it is better to leave FUD about future to politicians
and other liars.
https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

0 new messages