A
Anton
> ну "признано" - пиши кем, не надо за всех говорить... я вот не признал, значит не признано )
Согласен, использовал лишние weasel word, anonymous authority (https://en.m.wikipedia.org/wiki/Weasel_word), которые как раз и портят многое из того, "о чем люди говорят, книги пишут". Не подумал, что вы не в курсе этой рекомендации с наследованием и слишком резко написал об этом))
Хотя источник на wiki привел, еще больше можно найти запросом "why inheritance worst practices".
Вот тут например краткие практичные ответы:
https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern
Мне был интересен не срач, а что Mikhail имел ввиду под пониманием ООП и что это пониманин дало практически. Потому что сам не могу однозначно определить это понимание, т.к. критери ООП для кода нечеткие, их обычно сводят к компромисам принципов SOLID, GRASP, KISS, YAGNI, DRY, Worse is better и т.п.
Для самих языков парадигма ООП более опеделенная - они либо помогают писать в стиле ООП, либо нет. Знакомые профи считают, что если используется язык ООП, это уже технически ООП, отдельный вопрос к качеству конкретного дизайна, которое и служит в итоге критерием понимания ООП. Как стойной "теории", ООП по-моему нет, скорее ОО-дизайн и uml, которые парадигмой ООП и принципами притянуты к теориям и довелены до ума лучшими практиками. Т.о. ООП практиччески бессмысленно учить, а понять можно только на практике, за много итераций. И по началу уж точно ООП не облегчает жизнь програмиста.
Когда говорят, что не понимают ООП, у всех это разные вещи и мне интересно что именно непонятно, чтобы вовремя подсказать начинающим. И точней увидеть основной паттерн непонимания в чужом коде.
Что в ООП можно непонимать для реальной работы/дизайна не так очевидно. Полиморфизм, наверное, самое сложное, в части нюансов статического/динамического связывния и техник избежания явного приведения типов, перекликается и с паттернами и с наследованием. Рефакторинг в ООП стиле - тоже тема непростая, например - не бояться создавать технические классы, которые могут быть только из одной функции или по-другому не похожи на классическое описание объекта. Ещё правильное понимание инкапсуляции - оно полегче, но и правильность применения возмодно проверить только в долгоживущем проекте.
Понять проблематку отдельных паттернов проектирования сложно, слишко глубокие практические корни для начинающих, требующие понимания принципов (SOLID etc.) и нансов реализации поддержки ООП конкретным языком, не всегда адекватные практике примеры.
Ответы Mikhail дал:
"Множество задач, которые я решал функциональным программированием приобрели для меня иной вид, даже на контролы на форме я стал по другому смотреть". Примерно отвечает, что было непонятно до этого, особенно в плане IU. Но как сформулировать, что было непонятно до этого, не знаю.
"Создать объект, а потом от него создать наследника, использовав методы базового класса, а если очень захочется, то переопределить методы parent-класса, у наследника"
Тоже примерно понятно, что дало понимание наследования и полиморфизма для практики. И опять не очень ясно, что было непонятно до этого.
Я уже не очень понимаю, какие стожности в применении наследования в конкретных языках и, соответственно, как это непонятное проще обьяснить.
Языки предоставляют этот механизм, и часто обязывают им пользоваться как минимум для суперобъекта. Для применения в дизайне, по-моему важней понять, когда наследование не нужно (нарушает инкапсуляцию, LSP и т.п.). С Turbo Pascal тоже немного имел дело (без ООП, формошлёпил немного), там наверное особые усилия нужны именно перейти к парадигме ООП. В Java мне по-началу было больше непонятно наоборот, почему чисто процедурные куски помещаются в объекты, которые не похожи на обьекты по большинству пюопределений и примеров.
Согласен, использовал лишние weasel word, anonymous authority (https://en.m.wikipedia.org/wiki/Weasel_word), которые как раз и портят многое из того, "о чем люди говорят, книги пишут". Не подумал, что вы не в курсе этой рекомендации с наследованием и слишком резко написал об этом))
Хотя источник на wiki привел, еще больше можно найти запросом "why inheritance worst practices".
Вот тут например краткие практичные ответы:
https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern
Мне был интересен не срач, а что Mikhail имел ввиду под пониманием ООП и что это пониманин дало практически. Потому что сам не могу однозначно определить это понимание, т.к. критери ООП для кода нечеткие, их обычно сводят к компромисам принципов SOLID, GRASP, KISS, YAGNI, DRY, Worse is better и т.п.
Для самих языков парадигма ООП более опеделенная - они либо помогают писать в стиле ООП, либо нет. Знакомые профи считают, что если используется язык ООП, это уже технически ООП, отдельный вопрос к качеству конкретного дизайна, которое и служит в итоге критерием понимания ООП. Как стойной "теории", ООП по-моему нет, скорее ОО-дизайн и uml, которые парадигмой ООП и принципами притянуты к теориям и довелены до ума лучшими практиками. Т.о. ООП практиччески бессмысленно учить, а понять можно только на практике, за много итераций. И по началу уж точно ООП не облегчает жизнь програмиста.
Когда говорят, что не понимают ООП, у всех это разные вещи и мне интересно что именно непонятно, чтобы вовремя подсказать начинающим. И точней увидеть основной паттерн непонимания в чужом коде.
Что в ООП можно непонимать для реальной работы/дизайна не так очевидно. Полиморфизм, наверное, самое сложное, в части нюансов статического/динамического связывния и техник избежания явного приведения типов, перекликается и с паттернами и с наследованием. Рефакторинг в ООП стиле - тоже тема непростая, например - не бояться создавать технические классы, которые могут быть только из одной функции или по-другому не похожи на классическое описание объекта. Ещё правильное понимание инкапсуляции - оно полегче, но и правильность применения возмодно проверить только в долгоживущем проекте.
Понять проблематку отдельных паттернов проектирования сложно, слишко глубокие практические корни для начинающих, требующие понимания принципов (SOLID etc.) и нансов реализации поддержки ООП конкретным языком, не всегда адекватные практике примеры.
Ответы Mikhail дал:
"Множество задач, которые я решал функциональным программированием приобрели для меня иной вид, даже на контролы на форме я стал по другому смотреть". Примерно отвечает, что было непонятно до этого, особенно в плане IU. Но как сформулировать, что было непонятно до этого, не знаю.
"Создать объект, а потом от него создать наследника, использовав методы базового класса, а если очень захочется, то переопределить методы parent-класса, у наследника"
Тоже примерно понятно, что дало понимание наследования и полиморфизма для практики. И опять не очень ясно, что было непонятно до этого.
Я уже не очень понимаю, какие стожности в применении наследования в конкретных языках и, соответственно, как это непонятное проще обьяснить.
Языки предоставляют этот механизм, и часто обязывают им пользоваться как минимум для суперобъекта. Для применения в дизайне, по-моему важней понять, когда наследование не нужно (нарушает инкапсуляцию, LSP и т.п.). С Turbo Pascal тоже немного имел дело (без ООП, формошлёпил немного), там наверное особые усилия нужны именно перейти к парадигме ООП. В Java мне по-началу было больше непонятно наоборот, почему чисто процедурные куски помещаются в объекты, которые не похожи на обьекты по большинству пюопределений и примеров.
.я в курсе рекомендаций отдельных людей или групп людей, о не считаю их весомыми