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


Solmyr
903

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

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

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

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


ArbNet

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


e_v_medvedev

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

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

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

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

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


danforth

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

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

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


ivan-lev

Solmyr:
По сути объект один, а поведение разное.

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

программная/синтаксическая структура, определяющая отношение между объектами, которые разделяют определённое поведенческое множество и не связаны никак иначе.


danforth

e_v_medvedev:
а вот для сбора их в единое целое в инстансе проще установив наследование между классами.

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

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

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


e_v_medvedev

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

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


Solmyr

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

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

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


Sitealert

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

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

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

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

Solmyr:
Наследования в данном примере нет.

А это что?

Solmyr:
класс «Автомобиль»
Solmyr:
отдельные классы «транспортный автомобиль» и «3Д-автомобиль».


Solmyr

Sitealert:
А это что?

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


Sitealert

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *