- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как работает схема DBS на разных маркетплейсах
Кому подойдет, условия работы, стоимость
Сервис Кактус
Яндекс Директ обновил требования для рекламы сервисов по ремонту техники
При модерации объявлений будут проверяться контактные и юридические данные
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 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Д-автомобиль".
А это что?
Это разные классы, которые не связаны отношением наследования.
Это разные классы, которые не связаны отношением наследования.
Правильнее – наследовать.