Разведчик — лицо действующее явно, носящее форму своей армии и т.п
Что-то вспомнилось: «Штирлиц шёл по Рейхстагу. Что-то неуловимо выдавало в нём русского: может быть фуражка с красной звездой, может быть тельняшка, видневшаяся из под гимнастёрки, а может быть ППШ висящий на плече...»
Стойкое ощущение что автор предлагает тараканов из голов одних разработчиков (которые предложили те или иные подходы) заменить на тараканов из своей головы. Но беда в том, что тараканы от этого не перестают быть тараканами (что прекрасно подтверждают комментарии к статье).
Можно было бы тоже начать критиковать конкретные предложения из статьи (а многое из предложенных конкретных примеров и правда — очень плохо), но в этом нет никакого прикладного смысла. Ибо изначальная-то идея совершенно здравая — много думать над понятностью кода. А вот с реализацией — как в той картинке с программистом «Теперь-то я сделаю всё правильно!». Но это объясняется тем, что сложность, в целом, никуда нельзя убрать из индустрии разработки ПО. Это действительно сложно.
Строго говоря «эффективно» и «оптимально» это две формы одного и того же понятия.
Потому что эффективность так же требует критерия как и оптимальность. Реализация может быть эффективна по: тактам процессора, используемой памяти, простоте дальнейшего сопровождения, эффекту производимому на вопрошающего и т.д. и т.п. И вовсе не факт что это будет одна и та же реализация.
В военное время значение синуса может достигать четырёх! В случае появления Чака Норриса дискретные величины становятся непрерывными и наоборот. Чак Норрис может извлечь квадратный корень из отрицательного числа без привлечения мнимой единицы!
Тут вот какое дело: любую (я подчёркиваю — любую!) программу, реализованную на любом (хоть ООП, хоть нет) ЯП можно реализовать и на ассемблере. Который ни разу ни структурный, ни объектный и вообще, практически, машинный. Следует ли из этого что ассемблер — ООП язык?
Вот так и со структурным и объектным. Всё дело в конкретной реализации.
А про определение Алана Кея я вам ещё вчера написал (см. п.6 в Википедии).
P.S. И да, я читал «Чистую архитектуру» (в том числе). И да, я прекрасно понимаю то, что там написано :)
Да у меня-то нет никаких проблем ни с ООП, ни с ООД :)
Но наследование, таки, входит в «набор элементов ООП». Об этом даже стрелочка с треугольником на конце в соответствующих диаграммах говорит.
Потому что если наследования нет, то, практически автоматом, «выбывают» абстракции и полиморфизм. И что остаётся?
В смысле «пришли»? Я регулярно вижу написанный на вполне ООП-шных языках во вполне себе процедурном стиле код. А на собеседованиях на вопрос «Назовите основные концепции ООП» чуть ли не половина больше чем «Наследование» и, в лучшем случае «Инкапсуляция» вспомнить не могут.
Но это не имеет никакого отношения к самой парадигме. Я, например, вообще — разработчик БД (казалось бы — где SQL и где ООП?!), но тем не менее мыслю во вполне объектной парадигме.
Слушайте, я не знаю какие смыслы в термин ООП вкладывал Алан Кей. Но я начинал программировать на языках, про некоторые из которых вы, вполне вероятно, даже не слышали и в них не было даже намёка на ООП, классы и т.п. И когда в мой мир пришла парадигма ООП (а конкретно для меня она началась с Borland TurboPascal 5.5) это потребовало очень серьёзной перестройки мышления. Потому что это действительно была принципиально иная парадигма. И она вполне корректно описана в той же Википедии (и, кстати, там в определении ООП от Алана Кея п.6 значится именно наследование).
А если следовать вашей логике (и слегка довести её до абсурда — простите, профдеформация), то получается что даже обычный Бейсик вполне себе объектный язык, если я могу подключить к нему какую-нибудь библиотеку для работы с сообщениями — ведь в этот момент у него появится messaging и он станет «почти как SmallTalk».
То есть, получается, что Си Объектно-Ориентированный язык, а первые версии SmallTalk — нет?)
Если в Си есть наследование, инкапсуляция, полиморфизм и абстракции — то да. Я последний раз писал на Си лет 25 назад, тогда этого там, насколько я помню, не было. Но возможно я просто не в курсе.
Про SmallTalk не скажу, не знаю. Опять же, насколько я помню он считается первым ООП языком (не считая Симулы-67) и в нём был тот самый messaging. Но если в нём не было наследования он, пожалуй, не полноценная реализация ЯООП.
Подождите, это что же получается: монолитное приложение разделили на 100500 микросервисов, а они, собаки, оказались вовсе даже не микросервисами? Ну, потому что какие же это микросервисы (которые по определению должны быть атомарны и независимы друг от друга), если возникают такого рода проблемы (которые, по факту, вытекают из того незамысловатого факта, что выделенные кусочки вовсе даже не независимы)?
По идее микросервис должен быть «сильным и независимым» (ну, почти). А если нужно обеспечить макро-транзакцию то это нужно делать с помощью отдельного сервиса обеспечения таких транзакций, внутри которого и должно быть сосредоточено всё знание о том, кто и как участвует в этой макро-транзакции, что делать при тех или иных видах отказов тех или иных участников и т.д. и т.п.
Что-то вспомнилось: «Штирлиц шёл по Рейхстагу. Что-то неуловимо выдавало в нём русского: может быть фуражка с красной звездой, может быть тельняшка, видневшаяся из под гимнастёрки, а может быть ППШ висящий на плече...»
Ну и см. мой комментарий чуть выше.
Можно было бы тоже начать критиковать конкретные предложения из статьи (а многое из предложенных конкретных примеров и правда — очень плохо), но в этом нет никакого прикладного смысла. Ибо изначальная-то идея совершенно здравая — много думать над понятностью кода. А вот с реализацией — как в той картинке с программистом «Теперь-то я сделаю всё правильно!». Но это объясняется тем, что сложность, в целом, никуда нельзя убрать из индустрии разработки ПО. Это действительно сложно.
И основная проблема именно в этом
Потому что эффективность так же требует критерия как и оптимальность. Реализация может быть эффективна по: тактам процессора, используемой памяти, простоте дальнейшего сопровождения, эффекту производимому на вопрошающего и т.д. и т.п. И вовсе не факт что это будет одна и та же реализация.
Чаку Норрису для прямоугольного треугольника достаточно гипотенузы и одного катета!
Вот так и со структурным и объектным. Всё дело в конкретной реализации.
А про определение Алана Кея я вам ещё вчера написал (см. п.6 в Википедии).
P.S. И да, я читал «Чистую архитектуру» (в том числе). И да, я прекрасно понимаю то, что там написано :)
Но наследование, таки, входит в «набор элементов ООП». Об этом даже стрелочка с треугольником на конце в соответствующих диаграммах говорит.
Потому что если наследования нет, то, практически автоматом, «выбывают» абстракции и полиморфизм. И что остаётся?
Кто-нибудь знает как можно развидеть это творение Сатаны? Есть подозрение что если этот код прочитать вслух — можно открыть портал в ад :)
Но это не имеет никакого отношения к самой парадигме. Я, например, вообще — разработчик БД (казалось бы — где SQL и где ООП?!), но тем не менее мыслю во вполне объектной парадигме.
А если следовать вашей логике (и слегка довести её до абсурда — простите, профдеформация), то получается что даже обычный Бейсик вполне себе объектный язык, если я могу подключить к нему какую-нибудь библиотеку для работы с сообщениями — ведь в этот момент у него появится messaging и он станет «почти как SmallTalk».
Если в Си есть наследование, инкапсуляция, полиморфизм и абстракции — то да. Я последний раз писал на Си лет 25 назад, тогда этого там, насколько я помню, не было. Но возможно я просто не в курсе.
Про SmallTalk не скажу, не знаю. Опять же, насколько я помню он считается первым ООП языком (не считая Симулы-67) и в нём был тот самый messaging. Но если в нём не было наследования он, пожалуй, не полноценная реализация ЯООП.
Если ООП = OOP — то да. Если ООП = OOD, то вполне
По идее микросервис должен быть «сильным и независимым» (ну, почти). А если нужно обеспечить макро-транзакцию то это нужно делать с помощью отдельного сервиса обеспечения таких транзакций, внутри которого и должно быть сосредоточено всё знание о том, кто и как участвует в этой макро-транзакции, что делать при тех или иных видах отказов тех или иных участников и т.д. и т.п.