Return to Answer

class Point {
   public:

      // Constuctor
      Point();

      // Destuctor
      ~Point();
     
      // Getter functions.
      double get_x() const;
      double get_y() const;

      // Setter functions.
      void set_x(double x);
      void set_y(double y);

      // Need to add copy constructor and copy assignment operators too.
      // Need to take care of the Rule of Three.

      // Class to hold the data
      class Data;

  private:

      // Pointer to the object holding private data
      Data* dataPtr;
};

#include "Point.h"

class Point::Data
{
   public:

      Data() : x(0), y(0) {}

      double x;
      double y;
};

Point::Point() : dataPtr(new Data()) {}

Point::~Point() { delete dataPtr; }

double Point::get_x() const { return dataPtr->x; }
double Point::get_y() const { return dataPtr->y; }

void Point::set_x(double x) { dataPtr->x = x; }
void Point::set_y(double y) { dataPtr->y = y; }

class Point {
   public:

      // Constuctor
      Point();

      // Destuctor
      ~Point();
     
      // Getter functions.
      double get_x() const;
      double get_y() const;

      // Setter functions.
      void set_x(double x);
      void set_y(double y);

      // Need to add copy constructor and copy assignment operators too.
      // Need to take care of the Rule of Three.

      // Class to hold the data
      class Data;

  private:

      // Pointer to the object holding private data
      Data* dataPtr;
};

#include "Point.h"

class Point::Data
{
   public:

      Data() : x(0), y(0) {}

      double x;
      double y;
};

Point::Point() : dataPtr(new Data()) {}

Point::~Point() { delete dataPtr; }

double Point::get_x() const { return dataPtr->x; }
double Point::get_y() const { return dataPtr->y; }

void Point::set_x(double x) { dataPtr->x = x; }
void Point::set_y(double y) { dataPtr->y = y; }

I don't know the language of your posted snippet of code but in C++, it could be something like:

Re:

Why the author says that combining getters, setters and private access modifier is not enough?

It is not enough to hide the implementation details of the public getter and setter functions. It is not enough if you, the developer of Point, want more freedom in how the private data is represented and would like the flexibility of changing the representation without impacting the users of Point.

Re:

then how to do it (hide an object's implementation details)?

I don't know the language of your posted snippet of code but in C++, it could be something like:

There is idiom to hide the private data. There are various names for it: Opaque Pointer, Pimpl Idiom, Cheshire Cat, etc. See https://en.wikipedia.org/wiki/Opaque_pointer for more details.

I don't know the language of your posted snippet of code but in C++, it could be something like:

The header file, call it Point.h:

class Point {
   public:

      // Constuctor
      Point();

      // Destuctor
      ~Point();
     
      // Getter functions.
      double get_x() const;
      double get_y() const;

      // Setter functions.
      void set_x(double x);
      void set_y(double y);

      // Need to add copy constructor and copy assignment operators too.
      // Need to take care of the Rule of Three.

      // Class to hold the data
      class Data;

  private:

      // Pointer to the object holding private data
      Data* dataPtr;
};

The implementation file, call it Point.cpp:

#include "Point.h"

class Point::Data
{
   public:

      Data() : x(0), y(0) {}

      double x;
      double y;
};

Point::Point() : dataPtr(new Data()) {}

Point::~Point() { delete dataPtr; }

double Point::get_x() const { return dataPtr->x; }
double Point::get_y() const { return dataPtr->y; }

void Point::set_x(double x) { dataPtr->x = x; }
void Point::set_y(double y) { dataPtr->y = y; }

This completely hides how the private data of Point are stored.

There is an idiom to hide the private data. There are various names for it: Opaque Pointer, Pimpl Idiom, Cheshire Cat, etc. See https://en.wikipedia.org/wiki/Opaque_pointer for more details.

I read about it the first time in Large-Scale C++ Software Design by John Lakos. He used the term insulation to describe the practice. Insulation is stronger than encapsulation as far as how much control the developer has to modify the details of the private data.

I don't know the language of your posted snippet of code but in C++, it could be something like:

The header file, call it Point.h:

class Point {
   public:

      // Constuctor
      Point();

      // Destuctor
      ~Point();
     
      // Getter functions.
      double get_x() const;
      double get_y() const;

      // Setter functions.
      void set_x(double x);
      void set_y(double y);

      // Need to add copy constructor and copy assignment operators too.
      // Need to take care of the Rule of Three.

      // Class to hold the data
      class Data;

  private:

      // Pointer to the object holding private data
      Data* dataPtr;
};

The implementation file, call it Point.cpp:

#include "Point.h"

class Point::Data
{
   public:

      Data() : x(0), y(0) {}

      double x;
      double y;
};

Point::Point() : dataPtr(new Data()) {}

Point::~Point() { delete dataPtr; }

double Point::get_x() const { return dataPtr->x; }
double Point::get_y() const { return dataPtr->y; }

void Point::set_x(double x) { dataPtr->x = x; }
void Point::set_y(double y) { dataPtr->y = y; }

This completely hides how the private data of Point are stored. One of the interesting things that results from using this idiom in C++ is that the details of Data can be modified at will without requiring any of the files that depend on Point.h to be recompiled. This has real benefits in large applications with hundreds of .cpp files.