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

123
IL
На сайте с 20.04.2007
Offline
418
#11
Solmyr:
В один класс "Автомобиль" все интерфейсы, или в отдельные классы "транспортный автомобиль" и "3Д-автомобиль".

Так от задачи зависит.. (ну, и от возможностей используемого языка)

Если планируется один метод рендеринга и два метода "ехать вперёд" и "ехать назад", то нет смысла городить кучу классов - пусть лежит себе в автомобиле.

Если есть куча разнородных объектов для рендеринга (и автомобиль один из них) - можно их вынести в отдельный класс Renderable и унаследоваться от него (а также от "собирабле" и "управлябле", но опять же, не все языки поддерживают множественное наследование)..

В PHP есть упомянутые trait-ы, которые по сути позволяют заимствовать кусок кода.. но, т.к. логика рендеринга тапочка и автомобиля может быть различной, то часть функций придётся переопределять с учётом особенностей класса\объекта.

Либо под один (несколько) типов объектов пишется свой Renderer (CarRenderer, унаследованный от базового Renderer) реализующий метод render() с учётом особенностей класса Car..

... :) Облачные серверы от RegRu - промокод 3F85-3D10-806D-7224 ( http://levik.info/regru )
danforth
На сайте с 18.12.2015
Offline
153
#12
Sitealert:
Правильнее – наследовать.

Ну и что от чего тут наследовать? Ору с местных экспертов.

Тут походу никто не слышал про composition over inheritance.

ТС все правильно делает, что не использует наследование. Было бы не плохо на живом примере понять, чего добивается ТС, и какая логика между тем же "Транспортным автомобилем" и "3Д-автомобилем". Если между ними нет никакой связи - можно использовать несколько отдельных классов/структур. Если между ними есть связь - то семантически, это одна и та же единица, которая имеет как логику, так и представление (3Д - например).

Junior Web Developer
S
На сайте с 30.09.2016
Offline
469
#13
danforth:
Ну и что от чего тут наследовать?

Класс Автомобиль

- длина

- ширина

- высота

Дочерние классы:

Транспортный_автомобиль

- масса

- скорость

3Д-автомобиль

- цвет

- форма кузова

danforth:
Ору с местных экспертов.

Ори дальше. Не буду мешать.

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
Z0
На сайте с 03.09.2009
Offline
737
#14

А я как дурак кнопочки нажимать учусь в android studio через java 🤣

Простите за офтоп :p

VoV@
На сайте с 22.09.2007
Offline
196
#15

Есть 2 способа - наследование и реализация интерфейсов. Из стартпоста я понял, что если применить наследование, то получается множественное наследование.

С этим связана куча граблей, по которым прошлись толпы разработчиков и большинство из них не рекомендуют использовать наследование от нескольких классов. В моём любимом C# множественное наследование прямо запрещено. А вот интерфейсов можно реализовать сколько угодно. Да и принципы SOLID рекомендуют использовать интерфейсы.

PS Все широкоизвестные паттерны проектирования можно реализовать, как через наследование, так и через интерфейсы. Вряд ли ТС придумал что-то новое, что не укладывается в паттерны GOF.

---------- Добавлено 14.05.2020 в 20:52 ----------

Solmyr:

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

Какое-то слишком узкое у вас получилось применение интерфейсов.

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

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

Удобнее делать 1 класс и реализовать в нём интерфейсы: собирать на заводе, управлять на дороге, рендерить как 3D объект. И в разные обработчики передавать класс по нужному интерфейсу. Всё логично же.

⭐ Разработка Андроид-приложений (Xamarin C#). ⭐ Разработка ASP.NET (WebForms, MVC, WebAPI, Core). ⭐ Цой жив!
Sly32
На сайте с 29.03.2012
Offline
270
#16
danforth:
ТС все правильно делает, что не использует наследование

Естественно. Потому что в данном примере оно не нужно.

Sitealert, привел общий пример наследования, как это может использоваться

VoV@:
Удобнее делать 1 класс и реализовать в нём интерфейсы

Это далеко не всегда возможно.

В принципе, понимание основных принципов ООП отвечает на вопросы когда и что использовать - инкапсуляция, наследование, полиморфизм....

Интерфейсы - хорошая штука, если уместны

danforth
На сайте с 18.12.2015
Offline
153
#17
Sly32:
Это далеко не всегда возможно.

Например, когда это невозможно?

Anamnado
На сайте с 08.02.2010
Offline
242
#18

ТС, задачи разные (не поведения)

- сам обект

- управление им

- разработка проектирование этого объекта

поведения разные это когда:

- автомобиль едет по воде-

- на автомобиль дует ветер

- на автомобиль упаль кырпыч

Один класс у вас просто не возможен..

потому что при управлении им есть 2 й класс - описывающий управляющего... (дело в том что управляющий имеет иную технику передвижения - обычно ноги (а не колеса), и которые являются средством управления к тому же)

в 3 м - программа проектирования.

Solmyr:
Надо делать один класс для всех сценариев использования,

автомобиль да...

Но у вас есть сложность.. ( с начало нужно спроектировать, потом его делать (но программно (виртуально) можно в принципе пренебречь этой частью - она заключается просто в запуске конструктора класса автомобиль) в вашей программке,, а потом им управлять.... - соблюдать последовательность - иначе абсурд )

VoV@
На сайте с 22.09.2007
Offline
196
#19
Sly32:
Это далеко не всегда возможно.
В принципе, понимание основных принципов ООП отвечает на вопросы когда и что использовать - инкапсуляция, наследование, полиморфизм....
Интерфейсы - хорошая штука, если уместны

Описать поведение интерфейсами можно всегда.

Вот если есть общее состояние, то тогда да, желательно использовать абстрактный класс, в котором инкапсулируется состояние, а всё поведение лучше реализовать через интерфейсы.

Если у нескольких объектов есть одинаковое поведение, то можно его реализацию вынести в базовый класс в виртуальные методы и при необходимости переопределять в наследниках. Но это всё равно интерфейсы.

Dreammaker
На сайте с 20.04.2006
Offline
566
#20

потер ....

123

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