Название: Наследование Отправлено: Igors от Октябрь 17, 2016, 08:09 Добрый день
Есть классы Код И вот получается что CDeformer'у нужны очень многие методы CGroup. Переносить их (из CGroup в CDeformer) резона никакого, они к нему отношения не имеют. Конечно это можно легко решить неск способами, напр Код Или просто лепить этот static_cast всякий раз когда нужен CGroup. Но не является ли это признаком "корявости архитектуры" и все такое? Спасибо Название: Re: Наследование Отправлено: Авварон от Октябрь 17, 2016, 11:15 Что значит не нужны методы, если он их зовет? Сдаётся мне, у вас один класс надо, а не два.
Еще можно рекурсивным шаблоном сделать, но это те же яйца будут: Код: template <class Derived> Название: Re: Наследование Отправлено: ssoft от Октябрь 17, 2016, 11:24 Корявость архитектуры - однозначно ;D.
Вот только как решать? Возможно между Deformer и Group отношение не наследования, а агрегирования или вообще простые ассоциации? Код
Или общий API просто выделяется общим предком, а не наследованием друг от друга? Код
Название: Re: Наследование Отправлено: Racheengel от Октябрь 17, 2016, 18:12 Можно к CDeformer добавить интерфейсный класс, через который будут вызываться имплементации методов CGroup .
Типа такого: Код: class IDeformer Название: Re: Наследование Отправлено: Igors от Октябрь 20, 2016, 10:38 Все-таки заменил на членство (агрегирование). СDeformer может быть только один (у одного CGroup) и его не может не быть - ну вроде бы наследование. Но тут неприятный эффект, пример
Код А у CGroup немало всяких VertexList помимо деформера, пришлось раздувать имена (GetDeformerVertexList). Также получается что подавляющее большинство методов СDeformer'а - чистые виртуалы, без CGroup он практически нулевой. А вот данные-члены у него свои, и приличные. В общем "настоять" на наследовании конечно можно, но как-то смысла не видно. Мда... |