- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Яндекс.Еда запустила сервис оплаты счета в ресторанах по QR-кодам
Услуга будет стоить ресторанам менее 2% от чека клиента
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования - скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
Разные. И класс агент который будет подключать нужные классы создавая динамически класс для нужного вам случая.
Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования - скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
Теория говорит, что программный класс и объект реального мира со всеми его пропертями - не одно и тоже. Разбивка на классы делается в первую очередь для удобства командной разработки. Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой. То же самое с методами, отражающими разные динамические свойства одного объекта. Если один кодер пишет один метод, а другой - другой, то методы лучше связать с разными классами, а вот для сбора их в единое целое в инстансе проще установив наследование между классами.
Solmyr, должно быть несколько интерфейсов, например Automotive, с методами gas, brake, turn_left, turn_right, интерфейс Display, с методом render, и так далее.
А сам класс автомобиля должен реализовывать (или нет) нужные вам интерфейсы. И принимать нужно не инстанс класса, а интерфейс, закрывающий детали реализации.
А сами свойства должны быть закрыты getterами и setterами, если их чтение/изменение предусмотрено.
По сути объект один, а поведение разное.
Для этого выдумали интерфейсы
а вот для сбора их в единое целое в инстансе проще установив наследование между классами.
Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).
Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой.
Делается вообще не так: есть класс автомобиль, если класс двигатель, есть класс трансмиссии, есть класс кузова и т.д., все они встраиваются в автомобиль, и каждый из них взаимодействуют друг с другом. Есть паттерн bridge, через который двигатель передает мощность на колеса (мостом в данном случае выступает класс трансмиссии). И это все должно либо встраиваться друг в друга, либо быть сиблингами в иерархии. Но никак не наследоваться. Даже двигатель с турбой по сути это двигатель + турбо. Нет тут наследования. DI нужно юзать. Тогда и код будет тестируемый и поддерживаемый.
Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).
Это только в глазах профана вроде вас.
Наследования в данном примере нет. Автомобиль как 3Д-объект не наследует автомобиль как транспортное средство. И наоборот тоже нет.
Интерфейсы чуть ближе, но тоже вопрос же не про то. Интерфейсы, это как сделать так чтобы 3Д-рендерить можно было и автомобили и деревья. И автомобиль и дерево реализуют для этого одинаковый интерфейс.
Вопрос собственно в том, в какие классы класть реализации нужных интерфейсов. В один класс "Автомобиль" все интерфейсы, или в отдельные классы "транспортный автомобиль" и "3Д-автомобиль".
Наследование вообще уже признано тупиковой ветвью развития.
В ответ на эту ересь можно только процитировать:
Полный бред.
---------- Добавлено 14.05.2020 в 16:59 ----------
Наследования в данном примере нет.
класс "Автомобиль"
отдельные классы "транспортный автомобиль" и "3Д-автомобиль".
А это что?
Это разные классы, которые не связаны отношением наследования.
Это разные классы, которые не связаны отношением наследования.
Правильнее – наследовать.