- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
В один класс "Автомобиль" все интерфейсы, или в отдельные классы "транспортный автомобиль" и "3Д-автомобиль".
Так от задачи зависит.. (ну, и от возможностей используемого языка)
Если планируется один метод рендеринга и два метода "ехать вперёд" и "ехать назад", то нет смысла городить кучу классов - пусть лежит себе в автомобиле.
Если есть куча разнородных объектов для рендеринга (и автомобиль один из них) - можно их вынести в отдельный класс Renderable и унаследоваться от него (а также от "собирабле" и "управлябле", но опять же, не все языки поддерживают множественное наследование)..
В PHP есть упомянутые trait-ы, которые по сути позволяют заимствовать кусок кода.. но, т.к. логика рендеринга тапочка и автомобиля может быть различной, то часть функций придётся переопределять с учётом особенностей класса\объекта.
Либо под один (несколько) типов объектов пишется свой Renderer (CarRenderer, унаследованный от базового Renderer) реализующий метод render() с учётом особенностей класса Car..
Правильнее – наследовать.
Ну и что от чего тут наследовать? Ору с местных экспертов.
Тут походу никто не слышал про composition over inheritance.
ТС все правильно делает, что не использует наследование. Было бы не плохо на живом примере понять, чего добивается ТС, и какая логика между тем же "Транспортным автомобилем" и "3Д-автомобилем". Если между ними нет никакой связи - можно использовать несколько отдельных классов/структур. Если между ними есть связь - то семантически, это одна и та же единица, которая имеет как логику, так и представление (3Д - например).
Ну и что от чего тут наследовать?
Класс Автомобиль
- длина
- ширина
- высота
Дочерние классы:
Транспортный_автомобиль
- масса
- скорость
3Д-автомобиль
- цвет
- форма кузова
Ору с местных экспертов.
Ори дальше. Не буду мешать.
А я как дурак кнопочки нажимать учусь в android studio через java 🤣
Простите за офтоп :p
Есть 2 способа - наследование и реализация интерфейсов. Из стартпоста я понял, что если применить наследование, то получается множественное наследование.
С этим связана куча граблей, по которым прошлись толпы разработчиков и большинство из них не рекомендуют использовать наследование от нескольких классов. В моём любимом C# множественное наследование прямо запрещено. А вот интерфейсов можно реализовать сколько угодно. Да и принципы SOLID рекомендуют использовать интерфейсы.
PS Все широкоизвестные паттерны проектирования можно реализовать, как через наследование, так и через интерфейсы. Вряд ли ТС придумал что-то новое, что не укладывается в паттерны GOF.
---------- Добавлено 14.05.2020 в 20:52 ----------
Интерфейсы чуть ближе, но тоже вопрос же не про то. Интерфейсы, это как сделать так чтобы 3Д-рендерить можно было и автомобили и деревья. И автомобиль и дерево реализуют для этого одинаковый интерфейс.
Какое-то слишком узкое у вас получилось применение интерфейсов.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования - скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
Удобнее делать 1 класс и реализовать в нём интерфейсы: собирать на заводе, управлять на дороге, рендерить как 3D объект. И в разные обработчики передавать класс по нужному интерфейсу. Всё логично же.
ТС все правильно делает, что не использует наследование
Естественно. Потому что в данном примере оно не нужно.
Sitealert, привел общий пример наследования, как это может использоваться
Удобнее делать 1 класс и реализовать в нём интерфейсы
Это далеко не всегда возможно.
В принципе, понимание основных принципов ООП отвечает на вопросы когда и что использовать - инкапсуляция, наследование, полиморфизм....
Интерфейсы - хорошая штука, если уместны
Это далеко не всегда возможно.
Например, когда это невозможно?
ТС, задачи разные (не поведения)
- сам обект
- управление им
- разработка проектирование этого объекта
поведения разные это когда:
- автомобиль едет по воде-
- на автомобиль дует ветер
- на автомобиль упаль кырпыч
Один класс у вас просто не возможен..
потому что при управлении им есть 2 й класс - описывающий управляющего... (дело в том что управляющий имеет иную технику передвижения - обычно ноги (а не колеса), и которые являются средством управления к тому же)
в 3 м - программа проектирования.
Надо делать один класс для всех сценариев использования,
автомобиль да...
Но у вас есть сложность.. ( с начало нужно спроектировать, потом его делать (но программно (виртуально) можно в принципе пренебречь этой частью - она заключается просто в запуске конструктора класса автомобиль) в вашей программке,, а потом им управлять.... - соблюдать последовательность - иначе абсурд )
Это далеко не всегда возможно.
В принципе, понимание основных принципов ООП отвечает на вопросы когда и что использовать - инкапсуляция, наследование, полиморфизм....
Интерфейсы - хорошая штука, если уместны
Описать поведение интерфейсами можно всегда.
Вот если есть общее состояние, то тогда да, желательно использовать абстрактный класс, в котором инкапсулируется состояние, а всё поведение лучше реализовать через интерфейсы.
Если у нескольких объектов есть одинаковое поведение, то можно его реализацию вынести в базовый класс в виртуальные методы и при необходимости переопределять в наследниках. Но это всё равно интерфейсы.
потер ....