Как (и можно ли) в С++ ограничить порождение классов, или как вариант выборочно ограничить полимоморфизм в порождаемых классах (т.е например запретить люое переопределение функции в порожденном классе).
Здравствуйте, TRONZA, Вы писали:
T> Как (и можно ли) в С++ ограничить порождение классов, или как T> вариант выборочно ограничить полимоморфизм в порождаемых классах
А зачем?
Posted via RSDN NNTP Server 1.6 RC1
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, TRONZA, Вы писали:
TRO> Как (и можно ли) в С++ ограничить порождение классов, или как вариант выборочно ограничить полимоморфизм в порождаемых классах (т.е например запретить люое переопределение функции в порожденном классе).
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Здравствуйте, TRONZA, Вы писали:
T>> Как (и можно ли) в С++ ограничить порождение классов, или как T>> вариант выборочно ограничить полимоморфизм в порождаемых классах
ПК>А зачем?
Смысл наложения такого ограничения — в усилении защиты порожденного класса (в случае выборочного ограничения) от сложности исходного класса, или (если полный запрет) — гарантия (точнее усиление такой гарантии) использования класса точно определенным способом — это все — если хотите инкапсуляция сложности.
Re[2]: Принудительное ограничение иерархии классов
Здравствуйте, Вадим Никулин, Вы писали:
ВН>Здравствуйте, TRONZA, Вы писали:
TRO>> Как (и можно ли) в С++ ограничить порождение классов, или как вариант выборочно ограничить полимоморфизм в порождаемых классах (т.е например запретить люое переопределение функции в порожденном классе).
ВН>Умную мысль можно прочитать здесь
А-а..(остроумно — но трюк ) Такой способ я также сообразил, но ввиду недостаточного знакомства с языком (в пособиях и учебниках этот вопрос как-то опускается) полагал, что все-таки существует явный механизм.
Re[3]: Принудительное ограничение иерархии классов
Здравствуйте, TRONZA, Вы писали:
TRO>Здравствуйте, Вадим Никулин, Вы писали:
ВН>>Здравствуйте, TRONZA, Вы писали:
TRO>>> Как (и можно ли) в С++ ограничить порождение классов, или как вариант выборочно ограничить полимоморфизм в порождаемых классах (т.е например запретить люое переопределение функции в порожденном классе).
ВН>>Умную мысль можно прочитать здесь
TRO> А-а..(остроумно — но трюк ) Такой способ я также сообразил, но ввиду недостаточного знакомства с языком (в пособиях и учебниках этот вопрос как-то опускается) полагал, что все-таки существует явный механизм.
Интересно, трюк сообразили ( ), а с языком недостаточно знакомы
В С++ такого явного механизма, как в Яве final — нету.
То ли не додумались, то ли посчитали ненужным. Поэтому — только через приватный конструктор. Надеюсь, пока. Может сообразят, что final нужен в явном виде?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Принудительное ограничение иерархии классов
LVV>Интересно, трюк сообразили ( ), а с языком недостаточно знакомы
Чуть в сторону;
Ничего себе! Не подумайте, что я кокетничаю, но мере изучения языка все меньше уверенности, что я смогу когда либо быть с ним достаточно знакомым.
Re[5]: Принудительное ограничение иерархии классов
LVV>>Интересно, трюк сообразили ( ), а с языком недостаточно знакомы TRO> Чуть в сторону; TRO> Ничего себе! Не подумайте, что я кокетничаю, но мере изучения языка все меньше уверенности, что я смогу когда либо быть с ним достаточно знакомым.
А Элджера читали?
Одна из первых фраз: Язык С++ изучается постепенно ...
С++ ДО КОНЦА изучить невозможно! Каждый день что-нибудь новенькое нароешь или подсмотришь. Сколько людей — столько способов использования. А Александреску почитаешь — вообще пора на пенсию уходить! ТАКОЕ сообразить — это ж надо такими задачами заниматься!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Принудительное ограничение иерархии классов
Здравствуйте, TRONZA, Вы писали:
T>>> Как (и можно ли) в С++ ограничить порождение классов, или как T>>> вариант выборочно ограничить полимоморфизм в порождаемых классах
ПК>> А зачем?
T> гарантия использования класса точно определенным способом
Имхо, указания в документации, что класс не предназначен для дальнейшего наследования, достаточно.
Posted via RSDN NNTP Server 1.6 RC1
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[4]: Принудительное ограничение иерархии классов
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, TRONZA, Вы писали LVV>В С++ такого явного механизма, как в Яве final — нету.
На самом деле, по опыту знаю, что потобные механизмы крайне вредны... Запрет на рассширение лучше в документации указывать, а то как только упираешься в недостаток разработки какой-нибудь либы, очень хочется отнаследоваться и перекрыть некоректно работающий метод — ан нет — какой-то умник решил, что клас финальный — и иди правь чужую либу и получай механизм патчей.
С уважением Вадим.
Re[5]: Принудительное ограничение иерархии классов
Здравствуйте, lboss, Вы писали:
L>Здравствуйте, LaptevVV, Вы писали:
LVV>>Здравствуйте, TRONZA, Вы писали LVV>>В С++ такого явного механизма, как в Яве final — нету.
L>На самом деле, по опыту знаю, что потобные механизмы крайне вредны... Запрет на L>рассширение лучше в документации указывать, а то как только упираешься в недостаток L>разработки какой-нибудь либы, очень хочется отнаследоваться и перекрыть некоректно L>работающий метод — ан нет — какой-то умник решил, что клас финальный — и иди правь L>чужую либу и получай механизм патчей.
Собственно, я уже понял что явного механизма не имеется. Спасибо всем ответившим.
Все же добавлю, что мнение о вреде такого запрета, и достаточности указания запрета в документации вообще не согласуется с механизмами типобезопасности, ооп и т.д. Эти механизмы должны быть жесткими а иначе прок от них невелик. Вы же сами пишите
"...в документации указывать", и тут же "...очень хочется отнаследоваться". Ведь методы могут работать сложным образом, тот кто их разрабатывал может иметь сложную мотивацию их устройства и нет гарантии что перекрывающие методы (или унаследованный класс) сможет корректно это сделать. Т.е. опять таки такие ограничения — элемент защиты от сложности (именно тех кто с этим классом потом работает.
Re[6]: Принудительное ограничение иерархии классов
Здравствуйте, TRONZA, Вы писали:
T> Вы же сами пишите "...в документации указывать", и тут же "...очень хочется отнаследоваться".
Все верно: указанием в документации, что класс не предназначен для наследования, автор снимает
с себя ответственность за корректную работу своего класса в виде подобъекта чужого, унаследованного.
Наследуясь, пользователь соглашается с таким положением вещей, беря ответственность на себя.
T> Ведь методы могут работать сложным образом, тот кто их разрабатывал T> может иметь сложную мотивацию их устройства и нет гарантии что перекрывающие T> методы (или унаследованный класс) сможет корректно это сделать.
Но нет и обратной гарантии, что это не будет сделано корректно.
T> Т.е. опять таки такие ограничения — элемент защиты от сложности T> (именно тех кто с этим классом потом работает.
Такими темпами надо и указатели, и еще много чего из языка поубирать.
Posted via RSDN NNTP Server 1.6 RC1
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[4]: Принудительное ограничение иерархии классов
Здравствуйте, LaptevVV, Вы писали:
LVV>В С++ такого явного механизма, как в Яве final — нету. LVV>То ли не додумались, то ли посчитали ненужным. Поэтому — только через приватный конструктор. Надеюсь, пока. Может сообразят, что final нужен в явном виде?
Что бы сделать класс Final можно обявить его внутри функции (см. Александреску)
struct Base
{
virtual void Fun() = 0;
};
template<class T_>
Base* createDerived()
{
class Derived : public Base
{
private :
T_ obj;
public :
virtual void Fun() { /*...*/ }
};
return new Derived();
};
но в локальных классах нельзя объявлять статические переменные...
Species come and go, but the earth stands forever fast...
Re[5]: Принудительное ограничение иерархии классов
Здравствуйте, Libra, Вы писали:
LVV>>В С++ такого явного механизма, как в Яве final — нету. LVV>>То ли не додумались, то ли посчитали ненужным. Поэтому — только через приватный конструктор. Надеюсь, пока. Может сообразят, что final нужен в явном виде?
L>Что бы сделать класс Final можно обявить его внутри функции (см. Александреску) L>
L>struct Base
L>{
L> virtual void Fun() = 0;
L>};
L>template<class T_>
L>Base* createDerived()
L>{
L> class Derived : public Base
L> {
L> private :
L> T_ obj;
L> public :
L> virtual void Fun() { /*...*/ }
L> };
L> return new Derived();
L>};
L>
L>но в локальных классах нельзя объявлять статические переменные...
Да, спасибо! Тут Вадим Никулин приводил ссылку на очень интересную конструкцию и для нелокального класса.
Речь шла именно о явной конструкции.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Принудительное ограничение иерархии классов
Здравствуйте, LaptevVV, Вы писали:
LVV>Речь шла именно о явной конструкции.
Хм... Если речь идет именно о явной конструкции, то тогда действительно в C++ нет никаких средст на подобии жабовского final...
Я что-то немогу отыскать ссылку Вадима Никулина... Можно ее еще разок указать? Ткните носом плз...
Species come and go, but the earth stands forever fast...
) Такой способ я также сообразил, но ввиду недостаточного знакомства с языком (в пособиях и учебниках этот вопрос как-то опускается) полагал, что все-таки существует явный механизм.
), а с языком недостаточно знакомы 
