Здравствуйте, DiPaolo, Вы писали:
DP>А есть примеры таких задач для прикладных областей? Не физика/математика и около-математические расчеты.
Натянуть можно что угодно. Классический пример — объект клиент порождает объект заказ, отдаете объект заказа — объекту менеджер, менеджер что-то с ним делает, вязывая методы заказа, порождает объект инвойс и передает объекту клиент. Ну и т.д.
Только удобно ли это на самом деле? Конечно же нет
Здравствуйте, Shmj, Вы писали:
S>Этот чувак уже третье видео обоснованно унижает ООП:
Термин "ООП" фактически уже устарел. Так же, как устарел термин "структурное программирование", хотя оно никуда не исчезло. В ООП просто к нему добавилось несколько небольших фич, полезных для оформления больших объемов кода. Но с тех пор еще много разных фич добавилось, поэтому термин "ООП" больше не актуален. Теперь уже даже на языках без ООП(типа C) будут использовать принципы ООП, там где надо. И злоупотребления ООП фичами тоже будут.
О фичах, предшествующих ООП: Структурное программирование.
В 1970-е годы объёмы и сложность программ достигли такого уровня, что традиционная (неструктурированная) разработка программ перестала удовлетворять потребностям практики. Программы становились слишком сложными, чтобы их можно было нормально сопровождать. Поэтому потребовалась систематизация процесса разработки и структуры программ.
Методология структурной разработки программного обеспечения была признана «самой сильной формализацией 70-х годов».
По мнению Бертрана Мейера, «Революция во взглядах на программирование, начатая Дейкстрой, привела к движению, известному как структурное программирование, которое предложило систематический, рациональный подход к конструированию программ.
Структурное программирование стало основой всего, что сделано в методологии программирования, включая и объектное программирование»[1].
S>3. Полиморфизм — суть: Как ПИСАТЬ код, который работает с разными типами данных
S> — трейты в Rust
Такие трейты же тоже имеют отношение к ООП, даже если их переименовали, изменили дизайн.
