Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования — скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
ArbNet
Разные. И класс агент который будет подключать нужные классы создавая динамически класс для нужного вам случая.
e_v_medvedev
Solmyr: Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования — скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
Теория говорит, что программный класс и объект реального мира со всеми его пропертями — не одно и тоже. Разбивка на классы делается в первую очередь для удобства командной разработки. Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой. То же самое с методами, отражающими разные динамические свойства одного объекта. Если один кодер пишет один метод, а другой — другой, то методы лучше связать с разными классами, а вот для сбора их в единое целое в инстансе проще установив наследование между классами.
danforth
Solmyr, должно быть несколько интерфейсов, например Automotive, с методами gas, brake, turn_left, turn_right, интерфейс Display, с методом render, и так далее.
А сам класс автомобиля должен реализовывать (или нет) нужные вам интерфейсы. И принимать нужно не инстанс класса, а интерфейс, закрывающий детали реализации.
А сами свойства должны быть закрыты getterами и setterами, если их чтение/изменение предусмотрено.
программная/синтаксическая структура, определяющая отношение между объектами, которые разделяют определённое поведенческое множество и не связаны никак иначе.
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: Это разные классы, которые не связаны отношением наследования.
Solmyr
Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования — скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
ArbNet
Разные. И класс агент который будет подключать нужные классы создавая динамически класс для нужного вам случая.
e_v_medvedev
Вот скажем есть в веб-приложении объект с которым в разным случаях надо обращаться совершенно по разному.
Например автомобиль.
В одних случаях его надо собирать на заводе. В других случаях им надо управлять на дороге. В третьих случаях надо его рендерить как 3D объект. По сути объект один, а поведение разное. Пропертя пересекаются частично, все-таки это реально один и тот же автомобиль, и, скажем, его длина нужна во всех трех случаях, но некоторые пропертя нужны только в одном сценарии использования — скажем цвет. А методы и вовсе почти не пересекаются.
Вопрос в том, что говорит теория программирования? Надо делать один класс для всех сценариев использования, или же делать разные классы для разных сценариев?
Теория говорит, что программный класс и объект реального мира со всеми его пропертями — не одно и тоже. Разбивка на классы делается в первую очередь для удобства командной разработки. Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой. То же самое с методами, отражающими разные динамические свойства одного объекта. Если один кодер пишет один метод, а другой — другой, то методы лучше связать с разными классами, а вот для сбора их в единое целое в инстансе проще установив наследование между классами.
danforth
Solmyr, должно быть несколько интерфейсов, например Automotive, с методами gas, brake, turn_left, turn_right, интерфейс Display, с методом render, и так далее.
А сам класс автомобиля должен реализовывать (или нет) нужные вам интерфейсы. И принимать нужно не инстанс класса, а интерфейс, закрывающий детали реализации.
А сами свойства должны быть закрыты getterами и setterами, если их чтение/изменение предусмотрено.
ivan-lev
По сути объект один, а поведение разное.
Для этого выдумали интерфейсы
danforth
а вот для сбора их в единое целое в инстансе проще установив наследование между классами.
Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).
Так например все пропертя автомобиль могут быть разбиты на несколько классов, которые наследуют один другой.
Делается вообще не так: есть класс автомобиль, если класс двигатель, есть класс трансмиссии, есть класс кузова и т.д., все они встраиваются в автомобиль, и каждый из них взаимодействуют друг с другом. Есть паттерн bridge, через который двигатель передает мощность на колеса (мостом в данном случае выступает класс трансмиссии). И это все должно либо встраиваться друг в друга, либо быть сиблингами в иерархии. Но никак не наследоваться. Даже двигатель с турбой по сути это двигатель + турбо. Нет тут наследования. DI нужно юзать. Тогда и код будет тестируемый и поддерживаемый.
e_v_medvedev
Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).
Это только в глазах профана вроде вас.
Solmyr
Наследования в данном примере нет. Автомобиль как 3Д-объект не наследует автомобиль как транспортное средство. И наоборот тоже нет.
Интерфейсы чуть ближе, но тоже вопрос же не про то. Интерфейсы, это как сделать так чтобы 3Д-рендерить можно было и автомобили и деревья. И автомобиль и дерево реализуют для этого одинаковый интерфейс.
Вопрос собственно в том, в какие классы класть реализации нужных интерфейсов. В один класс «Автомобиль» все интерфейсы, или в отдельные классы «транспортный автомобиль» и «3Д-автомобиль».
Sitealert
Наследование вообще уже признано тупиковой ветвью развития.
В ответ на эту ересь можно только процитировать:
Полный бред.
———- Добавлено 14.05.2020 в 16:59 ———-
Наследования в данном примере нет.
А это что?
класс «Автомобиль»
отдельные классы «транспортный автомобиль» и «3Д-автомобиль».
Solmyr
А это что?
Это разные классы, которые не связаны отношением наследования.
Sitealert
Это разные классы, которые не связаны отношением наследования.
Правильнее – наследовать.