когда в мой мир пришла парадигма ООП (а конкретно для меня она началась с Borland TurboPascal 5.5) это потребовало очень серьёзной перестройки мышления.
Кстати, мне правда интересно, что нового для вас внесла эта парадигма придя в виде классов и экземпляров классов? Ну то есть… В чем принципиальное отличие от того же процедурного программирования, что пришлось серьёзно перестраивать мышление?
Вообще, без принципов того же Алана Кея, даже то что сейчас называют ООП не сильно то отличается от старой доброй процедурщины( «храним данные и методы, которые меняют эти данные, в одном месте, потом вытягиваем данные через геттеры» )
Бейсик вполне себе объектный язык, если я могу подключить к нему какую-нибудь библиотеку для работы с сообщениями — ведь в этот момент у него появится messaging и он станет «почти как SmallTalk».
Вот мы и пришли к моменту что ООП это не только конкретный набор ограничений и не функционала языка, это ещё парадигма в которой можно писать а можно и не писать даже в тех языках что кличутся ООП.
Ну и да, мессаджинг утерян и сейчас лишь немного возврождается в Actor Model (Scala(Acca) / Erlang), либо даже в виде микросервисах, если подходить к ним грамотно.
Да и черт бы с ним с самим понятием, я не топлю что оно действительно нужно. Скорее даже, я не вижу смысла от него. Только если оно не нужно в изначальном виде, то в виде «Инкапсуляция наследование полиморфизм» и подавно. Есть на много более важные вещи, над которыми стоит задумываться.
А такую полезную штуку как Information Hiding можно рассматривать в отдельности от ООП, может хоть немного получится донести до людей что это сокрытие стейта, а не «заменить паблик поле геттером».
А вообще, в ООП от Алана Кея, был ещё один такой момент, как — «Всё — объект», наподобие клеток в организме, обменивающимися сообщениями, и именно эта часть, например, совсем не прижилась в современных языках программирования, если говорить именно о синтаксисе языка.
Вообще, не знаю что вы подразумевали под ООД, но могу предположиться что именно эти понятия, и то о чем вещал Девид Вест(«OOP is dead, long live OOD» / «Object Thinking»)
Инкапсуляция, наследование и полиморфизм(первое и последнее так точно, второе — смотря как определять) без проблем достигаются в языках без привычных вам классов, и которые вобщем то считаются функциональными.
Если ООП = OOP — то да.
ООП = Объектно-Ориентированное Программирование. Термин который ввёл Алан Кей, бакалавр молекулярной биологии, и ввел он его позже чем появилась Симула.
Идеи, которые он вкладывал в это понятие — вовсе не «Наследование, инкаспуляция и полиморфизм»( wiki.c2.com/?AlanKaysDefinitionOfObjectOriented ), иначе его парадигма ничем бы не отличалась от уже существующих приёмов написания кода, хоть в той же Симуле.
Вобщем печально что изначальные идеи ООП утерялись в глубинах истории.
Во-вторых, тема применения ООП принципов в С поднималась не раз, к примеру OOP with ANSI-C тут, и тот же Мартин в Clean Architecture
Перечитайте, пожалуйста, моё предыдущее сообщение, а потом книгу. Потому что речь там, как я уже писал, идёт как раз о том, что «Инкапсуляция, наследование и полимофризм» это не принципы ООП.
Максимум что дало ООП — чуть более удобную реализацию наследования, остальные два «принципа» вообще мимо.
1.
Инкапсуляция упоминается как часть определения ОО потому, что языки
ОО поддерживают простой и эффективный способ инкапсуляции данных
и функций. Как результат, есть возможность очертить круг связанных
данных и функций. За пределами круга эти данные невидимы и доступны
только некоторые функции. Воплощение этого понятия можно наблюдать
в виде приватных членов данных и общедоступных членов-функций класса.
Эта идея определенно не уникальная для ОО. Например, в языке C имеется
превосходная поддержка инкапсуляции. Рассмотрим простую программу
на C:
…
То есть языки, заявляющие о поддержке OO, фактически ослабили
превосходную инкапсуляцию, некогда существовавшую в C.
2.
То есть можно сказать, что некоторая разновидность наследования у нас
имелась задолго до появления языков ОО. Впрочем, это утверждение не
совсем истинно. У нас имелся трюк, хитрость, не настолько удобный, как
настоящее наследование.
…
Справедливости ради следует отметить, что языки ОО действительно
сделали маскировку структур данных более удобной, хотя это и не совсем
новая особенность.
Итак, мы не можем дать идее ОО ни одного очка за инкапсуляцию и можем
дать лишь пол-очка за наследование.
3.
Была ли возможность реализовать полиморфное поведение до появления
языков ОО? Конечно!
Но главное, что хотелось бы видеть в статьях о наследовании:
1. Что есть и другие способы переиспользования кода (и если вам часто приходится использовать наследование, возможно вам следует задуматься о наличии проблем в дизайне вашей системы). Жесткая фиксация иерархии типов не есть хорошо по многим причинам.
2. Что делать наследование опасно, и нужно задуматься о том, к каким проблемам это может привести, задуматься о совместимости типов, это, как я уже упомянул, LSP и контракты.
Вы можете сослаться на то, что это не влезло в статью, но тогда я в принципе не понимаю, что вы хотели донести, т.к. нету ни грамотного описания понятия, ни грамотного описания как его использовать.
На счёт наследования в Си уже ответили выше.
Подменять понятия и выдавать ложные фразы пытаясь прикрыть их громким именем "Автора SOLID", абсолютно не разбираясь в теме, не может быть хорошо.
Нужно различать статьи которые покрывают лишь часть материала, и статьи которые откровенно вредят.
принято считать одним из основополагающих принципов ООП (автором того же SOLID, к примеру)
Не говорил Дядя Боб такого, он высмеивал эту терминологию упоминая что «Инкапсуляция Наследование и Полимофизм» достижимы и в Си, который вроде как не ООП.
Если вы про книгу «Clean Architecture»(«Чистая Архитектура»), то вам определенно стоит внимательно её перечитать. Мне жаль тех новичков кто наткнется на вашу статью, потому что умением фильтровать информацию они, к сожалению, пока что особо не обладают.
Смею надеяться что не все начинающие пойдут лепить наследование куда не надо, но если это все же произойдет, то я в этом буду виновата в той же мере, что и, допустим, википедия.
В русской Википедии тоже всё плохо. Смысл тащить это ещё и на Хабр?
что в статье не упомянуты и SRP, OCP, ISP, DIP,
Если вы обдумаете эти принципы, вы поймете почему я упомянул именно LSP
P.s.
(автором того же SOLID, к примеру)
Я конечно понял что вы про Дядюшку Боба, но он не автор принципов из SOLID, он лишь аббревиатуру красивую придумал
Печально что в статье не указываются альтернативные варианты переиспользования кода, из которых наследование, кстати, считается худшим вариантом которого в принципе следует избегать. Вскользь упомянуто что его нужно использовать осторожно, но ничего про LSP и контракты.
Думаю для начинающих, которые пойдут лепить его где надо и где не надо(то есть везже где заметят похожий, на из взгляд, код) статья скорее вредна чем полезна.
И наследование не является основопологающей идеей ООП. В первой версии SmallTalk его, кстати, вообще не было.
Проблема в том что из современных книг популярны как раз практики и приемы, а первоисточники просто теряются в недрах истории.
Ситуации (в программировании) когда разработчик делает «что-то» только потому что так посоветовал Дядя Боб/Создатель моего любимого фреймворка/документация X/какой-то левый чел на Хабре сейчас встречаются просто повсеместно.
SOLID — очень показательный пример как хорошо задокументированные принципы превратились в набор догм, который все делают но почти никто не задумывается почему и для чего. Проблема в том что некоторое количество описанных в книге догм описанных в «Чистом Коде» аля «Не больше 3-х строчек кода на функцию» никоим образом не покроют все нужды отдельно взятого проекта, а слепое следование им, часто приводит к тому что разработчики забывают о том что нужно думать, и что догм не хватит для написания хорошего кода.
С# прекрасно живет с рефлексией и никто не жалуется что можно получить доступ к private полям или свойствам.
Потому что это компромисс.
То что решение с рефлексией выглядит сильно лучше чем вариант наделать геттеров в сущности не отменяет того что это всего-навсего грязный хак, использующийся в силу, обычно, необходимости маппить наши сущности на структуру баз данных, которые напрямую с объектами не работают( Оставим не особо прижившиеся кейсы объектных БД ) в совокупности с желанием сделать их независимыми от persistence слоя
Угу, я тоже когда на первый в жизни собес шел, начитался на Хабре всяких умников что ООП это инкапсуляция, наследование и полиморфизм, а это ведь люди которые искренне считают что понимают его настолько чтобы других учить.
Просто в математике так просто подменять понятия не получится
Но ведь если мы говорим просто о кусочке пластика которым можно расплатиться, это вопрос лишь инфраструктуры, другое дело — имеет ли это смысл в текущих реалиях.
А удобство понятие относительное
Ну, да, как уже сказали — возможный интерес инвесторов во вторую очередь, и в первую — у Bitwise висит заявка на запуск ETF которая ждет одобрения от той же самой комиссии(SEC), которой была представлена презентация. Практически вся вторая половина оной посвящена объяснению, почему с биткойном всё-таки всё хорошо, что у него достаточная ликвидность, есть честные регулируемые биржи, надежные маркет мейкеры
Криптовалюту также можно получать в обмен на товары и услуги. Если уж рассуждать в этом ключе, их отличие в децентрализованности со всеми прилагающими плюсами и минусами
Кстати, мне правда интересно, что нового для вас внесла эта парадигма придя в виде классов и экземпляров классов? Ну то есть… В чем принципиальное отличие от того же процедурного программирования, что пришлось серьёзно перестраивать мышление?
Вообще, без принципов того же Алана Кея, даже то что сейчас называют ООП не сильно то отличается от старой доброй процедурщины( «храним данные и методы, которые меняют эти данные, в одном месте, потом вытягиваем данные через геттеры» )
Вот мы и пришли к моменту что ООП это не только конкретный набор ограничений и не функционала языка, это ещё парадигма в которой можно писать а можно и не писать даже в тех языках что кличутся ООП.
Ну и да, мессаджинг утерян и сейчас лишь немного возврождается в Actor Model (Scala(Acca) / Erlang), либо даже в виде микросервисах, если подходить к ним грамотно.
Да и черт бы с ним с самим понятием, я не топлю что оно действительно нужно. Скорее даже, я не вижу смысла от него. Только если оно не нужно в изначальном виде, то в виде «Инкапсуляция наследование полиморфизм» и подавно. Есть на много более важные вещи, над которыми стоит задумываться.
А такую полезную штуку как Information Hiding можно рассматривать в отдельности от ООП, может хоть немного получится донести до людей что это сокрытие стейта, а не «заменить паблик поле геттером».
А вообще, в ООП от Алана Кея, был ещё один такой момент, как — «Всё — объект», наподобие клеток в организме, обменивающимися сообщениями, и именно эта часть, например, совсем не прижилась в современных языках программирования, если говорить именно о синтаксисе языка.
Вообще, не знаю что вы подразумевали под ООД, но могу предположиться что именно эти понятия, и то о чем вещал Девид Вест(«OOP is dead, long live OOD» / «Object Thinking»)
ООП = Объектно-Ориентированное Программирование. Термин который ввёл Алан Кей, бакалавр молекулярной биологии, и ввел он его позже чем появилась Симула.
Идеи, которые он вкладывал в это понятие — вовсе не «Наследование, инкаспуляция и полиморфизм»( wiki.c2.com/?AlanKaysDefinitionOfObjectOriented ), иначе его парадигма ничем бы не отличалась от уже существующих приёмов написания кода, хоть в той же Симуле.
Вобщем печально что изначальные идеи ООП утерялись в глубинах истории.
То есть, получается, что Си Объектно-Ориентированный язык, а первые версии SmallTalk — нет?)
Если обратиться к определнию Алана Кея, основополагающие идеи ООП — messaging, information hiding, late static binding.
Классы+инстансы классов != ООП.
В ином случае термин ООП просто не имеет смысла, потому что каждый понимат его по своему.
Перечитайте, пожалуйста, моё предыдущее сообщение, а потом книгу. Потому что речь там, как я уже писал, идёт как раз о том, что «Инкапсуляция, наследование и полимофризм» это не принципы ООП.
Максимум что дало ООП — чуть более удобную реализацию наследования, остальные два «принципа» вообще мимо.
1.
2.
3.
Но главное, что хотелось бы видеть в статьях о наследовании:
1. Что есть и другие способы переиспользования кода (и если вам часто приходится использовать наследование, возможно вам следует задуматься о наличии проблем в дизайне вашей системы). Жесткая фиксация иерархии типов не есть хорошо по многим причинам.
2. Что делать наследование опасно, и нужно задуматься о том, к каким проблемам это может привести, задуматься о совместимости типов, это, как я уже упомянул, LSP и контракты.
Вы можете сослаться на то, что это не влезло в статью, но тогда я в принципе не понимаю, что вы хотели донести, т.к. нету ни грамотного описания понятия, ни грамотного описания как его использовать.
На счёт наследования в Си уже ответили выше.
Подменять понятия и выдавать ложные фразы пытаясь прикрыть их громким именем "Автора SOLID", абсолютно не разбираясь в теме, не может быть хорошо.
Нужно различать статьи которые покрывают лишь часть материала, и статьи которые откровенно вредят.
Не говорил Дядя Боб такого, он высмеивал эту терминологию упоминая что «Инкапсуляция Наследование и Полимофизм» достижимы и в Си, который вроде как не ООП.
Если вы про книгу «Clean Architecture»(«Чистая Архитектура»), то вам определенно стоит внимательно её перечитать. Мне жаль тех новичков кто наткнется на вашу статью, потому что умением фильтровать информацию они, к сожалению, пока что особо не обладают.
В русской Википедии тоже всё плохо. Смысл тащить это ещё и на Хабр?
Если вы обдумаете эти принципы, вы поймете почему я упомянул именно LSP
P.s.
Я конечно понял что вы про Дядюшку Боба, но он не автор принципов из SOLID, он лишь аббревиатуру красивую придумал
Думаю для начинающих, которые пойдут лепить его где надо и где не надо(то есть везже где заметят похожий, на из взгляд, код) статья скорее вредна чем полезна.
И наследование не является основопологающей идеей ООП. В первой версии SmallTalk его, кстати, вообще не было.
Ситуации (в программировании) когда разработчик делает «что-то» только потому что так посоветовал Дядя Боб/Создатель моего любимого фреймворка/документация X/какой-то левый чел на Хабре сейчас встречаются просто повсеместно.
SOLID — очень показательный пример как хорошо задокументированные принципы превратились в набор догм, который все делают но почти никто не задумывается почему и для чего. Проблема в том что некоторое количество описанных в книге догм описанных в «Чистом Коде» аля «Не больше 3-х строчек кода на функцию» никоим образом не покроют все нужды отдельно взятого проекта, а слепое следование им, часто приводит к тому что разработчики забывают о том что нужно думать, и что догм не хватит для написания хорошего кода.
Потому что это компромисс.
То что решение с рефлексией выглядит сильно лучше чем вариант наделать геттеров в сущности не отменяет того что это всего-навсего грязный хак, использующийся в силу, обычно, необходимости маппить наши сущности на структуру баз данных, которые напрямую с объектами не работают( Оставим не особо прижившиеся кейсы объектных БД ) в совокупности с желанием сделать их независимыми от persistence слоя
Угу, я тоже когда на первый в жизни собес шел, начитался на Хабре всяких умников что ООП это инкапсуляция, наследование и полиморфизм, а это ведь люди которые искренне считают что понимают его настолько чтобы других учить.
Просто в математике так просто подменять понятия не получится
А удобство понятие относительное
Ну, вообщем то, давно уже появилась https://cryptopay.me/bitcoin-debit-card/ )