Вопрос по теории программирования (ООП?)

12 3
Solmyr
На сайте с 10.09.2007
Offline
496
894

Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.

Например автомобиль.

В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования - скажем цвет. А методы и вовсе почти не пересекаются.

Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?

ArbNet
На сайте с 27.10.2019
Online
55
#1

Разные. И класс агент который будет подключать нужные классы создавая динамически класс для нужного вам случая.

Блажен, кто не стремится сделать лучше: он не рискует быть не понятым.
e_v_medvedev
На сайте с 07.03.2013
Offline
182
#2
Solmyr:
Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.

Например автомобиль.

В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования - скажем цвет. А методы и вовсе почти не пересекаются.

Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?

Теория говорит, что программный класс и объект реального мира со всеми его пропертями - не одно и тоже. Разбивка на классы делается в первую очередь для удобства командной разработки. Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой. То же самое с методами, отражающими разные динамические свойства одного объекта. Если один кодер пишет один метод, а другой - другой, то методы лучше связать с разными классами, а вот для сбора их в единое целое в инстансе проще установив наследование между классами.

smartceo.ru (https://smartceo.ru) (методология интернет-торговли, портфолио, онлайн сервисы)
D
На сайте с 18.12.2015
Offline
142
#3

Solmyr, должно быть несколько интерфейсов, например Automotive, с методами gas, brake, turn_left, turn_right, интерфейс Display, с методом render, и так далее.

А сам класс автомобиля должен реализовывать (или нет) нужные вам интерфейсы. И принимать нужно не инстанс класса, а интерфейс, закрывающий детали реализации.

А сами свойства должны быть закрыты getterами и setterами, если их чтение/изменение предусмотрено.

Разработка и поддержка высоконагруженных проектов.
IL
На сайте с 20.04.2007
Offline
415
#4
Solmyr:
По сути объект один, а поведение разное.

Для этого выдумали интерфейсы

программная/синтаксическая структура, определяющая отношение между объектами, которые разделяют определённое поведенческое множество и не связаны никак иначе.
D
На сайте с 18.12.2015
Offline
142
#5
e_v_medvedev:
а вот для сбора их в единое целое в инстансе проще установив наследование между классами.

Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).

e_v_medvedev:
Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой.

Делается вообще не так: есть класс автомобиль, если класс двигатель, есть класс трансмиссии, есть класс кузова и т.д., все они встраиваются в автомобиль, и каждый из них взаимодействуют друг с другом. Есть паттерн bridge, через который двигатель передает мощность на колеса (мостом в данном случае выступает класс трансмиссии). И это все должно либо встраиваться друг в друга, либо быть сиблингами в иерархии. Но никак не наследоваться. Даже двигатель с турбой по сути это двигатель + турбо. Нет тут наследования. DI нужно юзать. Тогда и код будет тестируемый и поддерживаемый.

e_v_medvedev
На сайте с 07.03.2013
Offline
182
#6
danforth:
Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).

Это только в глазах профана вроде вас.

Solmyr
На сайте с 10.09.2007
Offline
496
#7

Наследования в данном примере нет. Автомобиль как 3Д-объект не наследует автомобиль как транспортное средство. И наоборот тоже нет.

Интерфейсы чуть ближе, но тоже вопрос же не про то. Интерфейсы, это как сделать так чтобы 3Д-рендерить можно было и автомобили и деревья. И автомобиль и дерево реализуют для этого одинаковый интерфейс.

Вопрос собственно в том, в какие классы класть реализации нужных интерфейсов. В один класс "Автомобиль" все интерфейсы, или в отдельные классы "транспортный автомобиль" и "3Д-автомобиль".

S
На сайте с 30.09.2016
Offline
459
#8
danforth:
Наследование вообще уже признано тупиковой ветвью развития.

В ответ на эту ересь можно только процитировать:

danforth:
Полный бред.


---------- Добавлено 14.05.2020 в 16:59 ----------

Solmyr:
Наследования в данном примере нет.
А это что?
Solmyr:
класс "Автомобиль"
Solmyr:
отдельные классы "транспортный автомобиль" и "3Д-автомобиль".
Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
Solmyr
На сайте с 10.09.2007
Offline
496
#9
Sitealert:
А это что?

Это разные классы, которые не связаны отношением наследования.

S
На сайте с 30.09.2016
Offline
459
#10
Solmyr:
Это разные классы, которые не связаны отношением наследования.

Правильнее – наследовать.

12 3

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий