Сегодня ознакомился с новой религией

← →
KSergey © (2006-12-15 08:08) [0]

Оказывается, теперь модно писать приватные виртуальные методы. Ну перегружать их.
Виртуальность при этом работает, однако вызвать реализацию базового класса нельзя.
Названные "за":
1.Уменьшается "сцепление" межру классами. типа заново переписываем всю реализацию - и это есть гуд.

Что я вижу плохого:
я всегда считал, что вызывать базовый метод - в общем-то хорошо. Тем более, когда к его функциональонсти надо добавть 2 строки.
Правда, я согласен с тем, что иногда (особенно в визуальных компонентах) в этих 2-х строках приходится бороться с тем, что собственно базовый метод и сделал. но как-то всегда боялся сопи-пастить код базового метода, ведь только он знает как именно работать со своими приватными полями. Впрочем, даже если бы я знал - я бы все равно не смог до них добраться.

Было бы любопытно выслушать мнения народные...

← →
KSergey © (2006-12-15 08:10) [1]

> Оказывается, теперь модно писать приватные виртуальные методы.
> Ну перегружать их.

На всякий случай: именно private, это не описка.
Во втором предложении пропущен союз. Читать так:

Ну и перегружать их.

← →
Думкин © (2006-12-15 08:14) [2]

Если потомки и предок в одном юните, то ничего и такого. Для остальных потомков закрываем или если надо - повышаем видимость.
Или я не понял?

← →
Cash © (2006-12-15 08:16) [3]

0_о Приват, да еще и виртуал... это анамнез!
У того видать с понятиями объектно-ориентированного подхода туговато...

← →
Чапаев © (2006-12-15 08:17) [4]

> Если потомки и предок в одном юните, то ничего и такого.
Ничего такого+непонятно, почему "вызвать реализацию базового класса нельзя".

← →
KSergey © (2006-12-15 08:29) [5]

ну эта.. не одним же дельфями жив мир :)

Т.е. речь идет именно о полностью protect методе. Без "в одном уните" и "объявлении их freinds" :)

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

look at this:

--------------------------------------------------------------------
class Foo
{
public:
void MyCoolMethod()
{
// some complex logic
...
doCoolLogic(); // logic which could be tuned in inheritors
...
}
private:
virtual doCoolLogic()
{
// no implementation or smth by default
}
};

class Bar: public Foo
{
public:

private:
virtual doCoolLogic()
{
// We wanna tune/specialize logic with our custom behavior
...
}
};

// Use-case:
...
Foo* obj = new Bar();

obj->MyCoolMethod(); // this method do standard logic with custom
behavior which been overridden in Bar class
...
--------------------------------------------------------------------

Non-Virtual Public interface idiom:

http://www.gotw.ca/publications/mill18.htm

http://www.octopull.demon.co.uk/c++/implementation_hiding.html

← →
ZeroDivide © (2006-12-15 08:29) [6]

но как-то всегда боялся сопи-пастить код базового метода, ведь только он знает как именно работать со своими приватными полями.

Нельзя будет работать с приватными полями базового класса. :)

← →
KSergey © (2006-12-15 08:30) [7]

> Чапаев © (15.12.06 08:17) [4]
> > Если потомки и предок в одном юните, то ничего и такого.
>
> Ничего такого+непонятно, почему "вызвать реализацию базового
> класса нельзя".

Это я честно не понял про что.

← →
Думкин © (2006-12-15 08:31) [8]

> Чапаев © (15.12.06 08:17) [4]

Про верность и т.п я и слова не говорю - ибо не ведаю что надо.

Если этот метод предка я собираюсь использовать и далее в классах - то ясно. Раз виртуал - то вроде собираюсь. Но допустим, чел знает, что это затем будет пользоваться потомками и многие захотят закрыть доступ к этому методу вообще. Тогда я эти потомки размещу в том же юните. А если кто-то захочет дать доступ и прочим потомкам - подымит до протекта.

Примерно так.

← →
KSergey © (2006-12-15 08:31) [9]

> KSergey © (15.12.06 08:29) [5]
> ну эта.. не одним же дельфями жив мир :)
>
> Т.е. речь идет именно о полностью protect методе. Без "в
> одном уните" и "объявлении их freinds" :)

Блин, досадная описка!

Т.е. речь идет именно о полностью private методе. Без "в одном юните" и "объявлении их freinds" :)

Т.е. речь идет именно о полностью protect методе.

Давайте не путать protected и private... и здесь все же большинство народа думает в терминах Delphi, в котором это возможно, только если метод будет protected.

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

Из ссылки:
Guideline #2: Prefer to make virtual functions private.

That"s easy. This lets the derived classes override the function to customize the behavior as needed, without further exposing the virtual functions directly by making them callable by derived classes (as would be possible if the functions were just protected). The point is that virtual functions exist to allow customization; unless they also need to be invoked directly from within derived classes" code, there"s no need to ever make them anything but private.

Only if derived classes need to invoke the base implementation of a virtual function, make the virtual function protected.

Т.е. речь идет о предоставлении для перекрытия только части базовой функции, путем выделения ее в отдельную функцию, и проставления virtual только ей. И в этом, действительно, Ничего такого

Интересно, а в SmallTalk-е накрытие приват метода сработет?... :)
Ну и, как вытекающее из этого, сработает ли вызов накрытого приватного
отцовского метода?... :)

> [7] KSergey © (15.12.06 08:30)
Про то, что если на делфовом форуме говоришь о Си, то хоть уточняй, что ты говоришь о Си. Потому что сишные и делфовые приваты -- две большие разницы.

Сегодня ознакомился с новой религией Найти похожие ветки