K>error C2259: 'Frame' : cannot instantiate abstract class
K>Народ, как такое разруливать? Вроде ничего сверхестественного не делаю
Если вы хотите замещать виртуальный метод в базовом интерфейсе из первой иерархии наследования в другой, параллельной иерархии наследования, тогда базовый интерфейс в обоих иерархиях должен наследоваться виртуально. Тогда интерфейс превратиться в единый базовый класс (т.е. интерфейс будет присутствовать лишь единожды в объекте Frame-а) и виртуальные фукнции будут замещаться так как вы хотите. Правда в студии появиться другой warning, C4250: 'Frame' : inherits 'Component::Component::CommonMethod' via dominance, который лишь говорит о том что произошло нечто нетривиальное: функция была отнаследована из параллельной иерархии и возможно это не то что вы хотите.
Написал кучу слов — потом подумал и стер
"Пишите unit tests".
зы если все таки интересуют долгие объяснения, то нет смысла их тут выписывать тк есть книжки, на которые стоит ссылаться. Например в "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" сравните 6ю главу и 10ю.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
class IComponent
{
virtual void CommonMethod()=0;
};
class Component/* : public IComponent - есть/нет на результат не влияет */
{
void CommonMethod()
{
...
}
};
class IFrame : public IComponent
{
virtual void SpecificMethod()=0;
};
class Frame : public Component, public IFrame
{
void SpecificMethod()
{
...
}
};
error C2259: 'Frame' : cannot instantiate abstract class
due to following members:
'void IComponent::CommonMethod(bool)' : is abstract
Народ, как такое разруливать? Вроде ничего сверхестественного не делаю
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>Народ, как такое разруливать? Вроде ничего сверхестественного не делаю
Делаешь. Без ": public IComponent" — не перекрываешь виртуальную функцию, с этим — имеешь две базы IComponent с перекрытым CommonMethod только в одном.
Варианты:
1. Пересмотреть дизайн
2. Сделать IComponent виртуальным базовым классом — в обоих наследованиях : public virtual IComponent
3. Применить шаблоны. Например, сделать Component шаблонным, template<class T> class Component : public T {}; class Frame : public Component<IFrame> {}; Или вообще всё сделать на CRTP базах (WTL-way)
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, Kingofastellarwar, Вы писали:
K>>Народ, как такое разруливать? Вроде ничего сверхестественного не делаю
AG>Делаешь. Без ": public IComponent" — не перекрываешь виртуальную функцию, с этим — имеешь две базы IComponent с перекрытым CommonMethod только в одном. AG>Варианты: AG>1. Пересмотреть дизайн AG>2. Сделать IComponent виртуальным базовым классом — в обоих наследованиях : public virtual IComponent AG>3. Применить шаблоны. Например, сделать Component шаблонным, template<class T> class Component : public T {}; class Frame : public Component<IFrame> {}; Или вообще всё сделать на CRTP базах (WTL-way)
пасиба мужики, про виртуал я тупо забыл, а вообще нада подумать...инетересно как такое решают на практике? мне кажется такое нужно довольно часто: базовый интерфейс для кастомных интерфейсов и соответствующий базовый класс для кастомных классов реализующие эти кастомные интерфейсы.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>инетересно как такое решают на практике? мне кажется такое нужно довольно часто: базовый интерфейс для кастомных интерфейсов и соответствующий базовый класс для кастомных классов реализующие эти кастомные интерфейсы.
Я вроде как назвал все способы решения, с которыми сталкивался.
Виртуальное наследование плюс доминирование — сложная штука. И имеет рантайм оверхед
и по памяти и по времени. AG>Сделать всё на шаблонах — полиморфизм будет чисто статическим. И опять таки сложная штука.
та не, я имел ввиду как можно архитектуру поменять, чтобы эту проблему можно было вообще избежать. и желательно без шаблонных извратов
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>пасиба мужики, про виртуал я тупо забыл, а вообще нада подумать...инетересно как такое решают на практике? мне кажется такое нужно довольно часто: базовый интерфейс для кастомных интерфейсов и соответствующий базовый класс для кастомных классов реализующие эти кастомные интерфейсы.
Имхо, каждый раз изобретают свой велосипед согласно вкусам конкретного разработчика
Здравствуйте, Kingofastellarwar, Вы писали:
K>та не, я имел ввиду как можно архитектуру поменять, чтобы эту проблему можно было вообще избежать. и желательно без шаблонных извратов
Самое простое — не наследуй реализацию, наследуй только интерфейс.
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, Kingofastellarwar, Вы писали:
K>>та не, я имел ввиду как можно архитектуру поменять, чтобы эту проблему можно было вообще избежать. и желательно без шаблонных извратов
AG>Самое простое — не наследуй реализацию, наследуй только интерфейс.
а общие методы как? делегировать? тогда в каждом классе появится много однострочных одинаковызх методов.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
AG>>Самое простое — не наследуй реализацию, наследуй только интерфейс.
+1000
K>а общие методы как? делегировать? тогда в каждом классе появится много однострочных одинаковызх методов.
Все познается в сравнении. Ну будет у тебя столько же 3х строчных методов, каждый из которых вызывает цепочку унаследованных и насколько легче будет вносить изменения?
single responsibility principle придумали не для того чтобы меньше бить по клавишам
кстати классная иллюстрация здесь
И между прочим IComponent не далеко ушел от эмфэцэшного CObject и тп это одна сплошная ошибка проектирования
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, Kingofastellarwar, Вы писали:
AG>>>Самое простое — не наследуй реализацию, наследуй только интерфейс. SD>+1000
K>>а общие методы как? делегировать? тогда в каждом классе появится много однострочных одинаковызх методов.
SD>Все познается в сравнении. Ну будет у тебя столько же 3х строчных методов, каждый из которых вызывает цепочку унаследованных и насколько легче будет вносить изменения? SD>single responsibility principle придумали не для того чтобы меньше бить по клавишам SD>кстати классная иллюстрация здесь SD>И между прочим IComponent не далеко ушел от эмфэцэшного CObject и тп это одна сплошная ошибка проектирования
ну при наследовании у меня не будет дублирования одного и того же, потому что оно будет описано в базовом и унаследовано остальными т.е. я не понял какие 3х строчные методы имеются ввиду.
или это сейчас считается плохим тоном?
а single responsibility principle это конечно правильно, но так же ж можно к чистому Си скатиться а вообще можете пример показать как бы вы в данном случае делегировали вместо наследования?
а в чем беда CObject? я не в курсе. да и у меня самого есть такие базовые классы и не вижу в этом проблемы, как раз очень удобно.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, SleepyDrago, Вы писали:
SD>зы если все таки интересуют долгие объяснения, то нет смысла их тут выписывать тк есть книжки, на которые стоит ссылаться. Например в "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" сравните 6ю главу и 10ю.
Согласен, ведь архитектура вообще сильно зависит от требований к программе и коду.
народ, я так понимаю вы предлагаете этот вариант:
(просто хочу знать как сейчас модно делать
class IComponent
{
virtual void CommonMethod()=0;
};
class Component /* никого не реализуем*/
{
void CommonMethod()
{
...
}
};
class IFrame : public IComponent
{
virtual void SpecificMethod()=0;
};
class Frame : public Component, public IFrame
{
void CommonMethod()
{
Component::CommonMethod();
}void SpecificMethod()
{
...
}
};
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Мож тогда вообще вот так делать? Народ тут говорит что тоже модно
class Frame : public IFrame
{
Component component_;
IComponent * GetComponent()
{
return component_;
}void SpecificMethod()
{
...
}
};
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
