Приватные методы

[Old]

По-моему, у Вас тут противоречие. Нужен статус или нет? Если да - зачем его убирать? Если нет - зачем его возвращать?

У нас есть какой-то класс:

Код

C++ (Qt)
class Hardware
{
private:
    Status    m_status;
};
 

Мы решаем добавить публичный метод для его получения и решили использовать константную ссылку:

Код

C++ (Qt)
class Hardware
{
public:
    const Status &status() const { return m_status; }
 
private:
    Status    m_status;
};
 

Через год оборудование изменилось и его состояние можно получать в момент запроса, а переменная m_status перестала быть нужна:

Код

C++ (Qt)
class Hardware
{
public:
    const Status &status() const
    {
        Status status;
        status.device1( m_device1->status() );
        status.device2( m_device2->status() );
        return status;
    }
};
 

И упс, мы возвращаем ссылку... Приходится менять интерфейс изменяя метод status, что он он возвращал значение.
А если бы сразу возвращали по значению, ничего менять бы не пришлось.
А что бы эффективно возвращать объекты, есть много разных способов: от умных указателей и до pimplов.

[m_ax]

Я не писал, вообще-то, что мы СОВСЕМ не используем приват. Но на практике почему-то от него было больше проблем, чем позитива.

Так спор то как раз и том, что Вы сейчас достаточно категорично пытаетесь списать это на проблему языка, не пытаясь принять и другую, более правдоподобную (на мой взгляд)  причину этой проблемы  Выше об этом уже писали Old и _Bers

Или сделать данные приватными и на каждую переменную завести по геттеросеттеру (java style) - это хорошая практика???

А если при изменении переменной требуется делать дополнительные действия? Даже если сейчас этого и не предусмотрено, но завтра потребуется? Согласен, в некоторых случаях (например std::pair) в этом нет необходимости. Я и сам в некоторых случаях открываю переменные..
Но я готов принять get/set, если этого требует, например code style. Но это уже другой вопрос..

[ViTech]

Как бы Вы метод status() написали?

Нормальный метод, возврат по ссылке исключает создание копии. Что с ней дальше будут делать - вопрос, если очередной Гуру Полиморфизма придет, то const_cast напишет Он же ГУРУ.

С этого места можно поподробнее? Чем возврат по ссылке исключает создание копии? И чем const мешает, если доступ к статусу даётся только для чтения?

Возвращать по ссылке или по значению - отдельная тема. Если это публичный метод, то лучше по значению. Если же это детали реализации конкретного класса (куда посторонние если и должны залезать, то с особой осторожностью) можно и по ссылке.

[Racheengel]

И упс, мы возвращаем ссылку... Приходится менять интерфейс изменяя метод status, что он он возвращал значение.
А если бы сразу возвращали по значению, ничего менять бы не пришлось.

Вот-вот, это то, про что я писал еще 5 страниц назад.

Есть у нас класс типа

Код:

class SomeCrap
{
public:
    double GetSomeShit() const;

private:
    double CalculateSomeShit() const;

    double m_shitValue;
};

и в cpp у него:

Код:

double SomeCrap::GetSomeShit() const
{
	double result = 0;
	
	// some crap
	
	result += CalculateSomeShit();
	
	// another crap
	
	return result;
}

void SomeCrap::CalculateSomeShit() const
{
	return sqrt(m_shitValue * 0.001);
}

Все работает замечательно добрый десяток лет, пока не появляется стандарт SomeNewCrap, который подразумевает вариабельное вычисление SomeShit.
Наследуемся:

Код:

class SomeNewCrap : public SomeCrap
{
public:

private:
    double CalculateSomeShit() const;		// таак... а ведь CalculateSomeShit мы не можем переопределить :(
};

Гуру, засунувший CalculateSomeShit() в приват, не мог знать, что появится новый стандарт...
Но он появился... Что делать?

[Пантер]

Racheengel - в твоем примере класс не предназначен для наследования изначально. И насрать, что CalculateSomeShit приватный.

[Racheengel]

Так спор то как раз и том, что Вы сейчас достаточно категорично пытаетесь списать это на проблему языка, не пытаясь принять и другую, более правдоподобную (на мой взгляд)  причину этой проблемы   Выше об этом уже писали Old и _Bers

Спрошу проще. Вам подарили смартфон с несъемной батареей. Она сдохла. Чья это проблема, что вы не можете заменить батарею? Ваша? Или производителя? По логике гугу, виноваты вы.

А если при изменении переменной требуется делать дополнительные действия? Даже если сейчас этого и не предусмотрено, но завтра потребуется?

Бинго! См. мой пример с кодом

[ViTech]

Гуру, засунувший CalculateSomeShit() в приват, не мог знать, что появится новый стандарт...
Но он появился... Что делать?

Да, в этом виноват private, а не virtual вовсе . Предлагаю задвинуть ещё одну фишку: все методы обязать быть виртуальными!

[Racheengel]

Racheengel - в твоем примере класс не предназначен для наследования изначально. И насрать, что CalculateSomeShit приватный.

Дык правильно, Гуру решил, что надо все в приват засунуть, он же не предвидел, что придет новый стандарт...

[Racheengel]

Гуру, засунувший CalculateSomeShit() в приват, не мог знать, что появится новый стандарт...
Но он появился... Что делать?

Да, в этом виноват private, а не virtual вовсе . Предлагаю задвинуть ещё одну фишку: все методы обязать быть виртуальными!

Напишем в привате virtual double CalculateSomeShit() const;   
Что изменится?

[Пантер]

Мы сможем его переопределить, это называется NVI.

[Racheengel]

Предлагаю задвинуть ещё одну фишку: все методы обязать быть виртуальными!

В принципе, если бы не совместимость с С, было бы неплохо, если бы по умолчанию в C++ все методы были виртуальными, пока не указано обратное - таким образом можно было бы избежать совсем глупых ошибок.

[Racheengel]

Мы сможем его переопределить, это называется NVI.

Да, конечно, можно решить проблему и так. Но это уже дополнительный оверхед. И человек, который потом будет читать этот код, акуеет

[Igors]

С этого места можно поподробнее? Чем возврат по ссылке исключает создание копии?

Просто не тратится время на создание возвращаемой копии, конечно потом вызвавший ее скопировать может.

Возвращать по ссылке или по значению - отдельная тема. Если это публичный метод, то лучше по значению.

"Вот если у нас в объекте ссылка исчезнет - все равно по значению мы вернуть сможем". Но собирались ли мы убирать ее сейчас? А в обозримом будущем? Нет, мы просто очень умны, мы "сразу делаем правильно" - и потом не придется переделывать (ну это мы сейчас так полагаем). Плохо здесь то что соображение (само по себе разумное) возведено в ранг "абсолюта" - все, это уже непреложное правило которому должен следовать каждый считающий себя грамотным. Также заметим - такой подход репродуцирует сам себя. Ведь возвращать приличную структуру по значению - ошибка начинающего. И немедленно вызывающему навязывается вумный указатель. И опять-таки, нормальная вещь, но не вызванная никакой необходимостью. Вот так и лепится псевдо-грамотный код который по сути говнокод, т.к. усилия направлены не на содержательную часть, а так - соблюсти мнимую грамотность.

Открываем букварь наугад

Код

C++ (Qt)
const QBrush & QPainter::brush() const
Returns the painter's current brush.

Как же так? А вдруг brush перестанет существовать

[ViTech]

В принципе, если бы не совместимость с С, было бы неплохо, если бы по умолчанию в C++ все методы были виртуальными, пока не указано обратное - таким образом можно было бы избежать совсем глупых ошибок.

Это было бы плохо, потому что нельзя переопределять всё подряд. И привело бы к большему числу глупых ошибок. Поэтому лучше явно указать, какие методы можно переопределить.

Кстати, было бы интересно посмотреть, как должен выглядеть правильный класс SomeCrap с вашей точки зрения.

[Old]

Плач Ярославны комментировать смысла нет.

А вот это причина всех слезных ошибочных доводов:

Ведь возвращать приличную структуру по значению - ошибка начинающего.

И доказательства (если мы рассматриваем код Qt как эталон ) находятся в том же букваре. Стоит взглянуть например на QSqlDatabase или QDBusConnection. Интересно насколько приличны (или не приличны) эти структуры?
А в сухом остатке, возвращаем по значению, а копируется только указатель. Шайтан.