Расширение публичного интерфейса в наследнике, как это решается? Всем привет.
Сразу опишу ситуацию, а потом сформулирую вопрос.
Есть класс Car, в котором полями являются компоненты Engine, Gearbox, Body и т.д. со своими публичными интерфейсами.
Допустим, мы хотим расширить публичный интерфейс компонента Body и добавить корпусу машины выдвигающийся спойлер.
Решение, которое сразу приходит в голову:
Ок, создаем наследника Body, назовем его WingedBody.
Выдвигаться этот спойлер будет исходя из какой-то логики класса Car, т.е. вызывать метод deploySpoiler() должен класс Car (а точнее его наследник).
Создаем наследника Car под названием WingedCar, и тут возникает вопрос: как пользоваться новой функциональностью класса WingedBody? Ведь от класса Car мы унаследовали поле с типом Body, а нужен нам WingedBody.
Несколько очевидных решений:
1) Вариант в лоб - приведение типа, то бишь downcasting от Body к WingedBody. Некрасиво и неэффективно.
2) Создаем дополнительное поле с типом WingedBody и новую функциональность вызываем через него. Минус - нужно поддерживать равенство обоих полей (старый с типом Body и новый c типом WingedBody должны быть одним и тем же объектом).
3) Улучшенный вариант второго решения. Создаем интерфейс IDeployableSpoiler, реализуем его в классе WingedBody, а в классе WingedCar создаем поле с типом IDeployableSpoiler а не WingedBody. Более понятное решение, но все равно мы по сути плодим лишние поля.
Есть мнение, что такая ситуация в реальной работе возникает очень редко и является ошибкой проектирования. Если вы так считаете, то обоснуйте это пожалуйста, потому что, как мне кажется, заранее всю функциональность (а соответственно и публичный интерфейс) предусмотреть невозможно (а если это либа - значит и дописать родительский класс нельзя).
Вопрос уже звучал, но повторю для наглядности. Как бы вы решали подобную задачу?
Расширение публичного интерфейса в наследнике, как это решается? Всем привет.
Сразу опишу ситуацию, а потом сформулирую вопрос.
Есть класс Car, в котором полями являются компоненты Engine, Gearbox, Body и т.д. со своими публичными интерфейсами.
Допустим, мы хотим расширить публичный интерфейс компонента Body и добавить корпусу машины выдвигающийся спойлер.
Решение, которое сразу приходит в голову:
Ок, создаем наследника Body, назовем его WingedBody.
Выдвигаться этот спойлер будет исходя из какой-то логики класса Car, т.е. вызывать метод deploySpoiler() должен класс Car (а точнее его наследник).
Создаем наследника Car под названием WingedCar, и тут возникает вопрос: как пользоваться новой функциональностью класса WingedBody? Ведь от класса Car мы унаследовали поле с типом Body, а нужен нам WingedBody.
Несколько очевидных решений:
1) Вариант в лоб - приведение типа, то бишь downcasting от Body к WingedBody. Некрасиво и неэффективно.
2) Создаем дополнительное поле с типом WingedBody и новую функциональность вызываем через него. Минус - нужно поддерживать равенство обоих полей (старый с типом Body и новый c типом WingedBody должны быть одним и тем же объектом).
3) Улучшенный вариант второго решения. Создаем интерфейс IDeployableSpoiler, реализуем его в классе WingedBody, а в классе WingedCar создаем поле с типом IDeployableSpoiler а не WingedBody. Более понятное решение, но все равно мы по сути плодим лишние поля.
Есть мнение, что такая ситуация в реальной работе возникает очень редко и является ошибкой проектирования. Если вы так считаете, то обоснуйте это пожалуйста, потому что, как мне кажется, заранее всю функциональность (а соответственно и публичный интерфейс) предусмотреть невозможно (а если это либа - значит и дописать родительский класс нельзя).
Вопрос уже звучал, но повторю для наглядности. Как бы вы решали подобную задачу?
Сразу опишу ситуацию, а потом сформулирую вопрос.
Есть класс Car, в котором полями являются компоненты Engine, Gearbox, Body и т.д. со своими публичными интерфейсами.
Допустим, мы хотим расширить публичный интерфейс компонента Body и добавить корпусу машины выдвигающийся спойлер.
Решение, которое сразу приходит в голову:
Ок, создаем наследника Body, назовем его WingedBody.
Выдвигаться этот спойлер будет исходя из какой-то логики класса Car, т.е. вызывать метод deploySpoiler() должен класс Car (а точнее его наследник).
Создаем наследника Car под названием WingedCar, и тут возникает вопрос: как пользоваться новой функциональностью класса WingedBody? Ведь от класса Car мы унаследовали поле с типом Body, а нужен нам WingedBody.
Несколько очевидных решений:
1) Вариант в лоб - приведение типа, то бишь downcasting от Body к WingedBody. Некрасиво и неэффективно.
2) Создаем дополнительное поле с типом WingedBody и новую функциональность вызываем через него. Минус - нужно поддерживать равенство обоих полей (старый с типом Body и новый c типом WingedBody должны быть одним и тем же объектом).
3) Улучшенный вариант второго решения. Создаем интерфейс IDeployableSpoiler, реализуем его в классе WingedBody, а в классе WingedCar создаем поле с типом IDeployableSpoiler а не WingedBody. Более понятное решение, но все равно мы по сути плодим лишние поля.
Есть мнение, что такая ситуация в реальной работе возникает очень редко и является ошибкой проектирования. Если вы так считаете, то обоснуйте это пожалуйста, потому что, как мне кажется, заранее всю функциональность (а соответственно и публичный интерфейс) предусмотреть невозможно (а если это либа - значит и дописать родительский класс нельзя).
Вопрос уже звучал, но повторю для наглядности. Как бы вы решали подобную задачу?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Если у вас такая ситуация возникает достаточно часто, то стоит задуматься о пересмотре архитектуры вашей системы. Возможно, есть способы сделать её более гибкой и расширяемой без необходимости создания таких сложных иерархий наследования.
Одним из способов решения вашей проблемы может быть использование шаблона проектирования "Композиция". Вместо того, чтобы наследовать компоненты автомобиля (Engine, Gearbox, Body) в классе Car, вы можете включить их как члены класса. Таким образом, каждый компонент будет независимым и вы сможете легко добавить новые функциональности к любому из них без необходимости менять структуру класса Car.
Другим вариантом может быть использование паттерна "Декоратор". Вы можете создать декораторы для каждого компонента автомобиля (например, EngineDecorator, GearboxDecorator, BodyDecorator), которые будут расширять функциональность базового компонента. Таким образом, вы сможете легко добавить новую функциональность к любому компоненту, не изменяя его базового класса.
Эти подходы помогут сделать вашу систему более гибкой и расширяемой, а также избавят вас от необходимости создания сложных иерархий наследования.