По сути, он не имеет отношения к трудам той самой Барбары, где она лишь приводила похожую цитату из более ранней работы своего коллеги.
По существу, когда появились нормальные работы по теории типов, и люди разрбрались с вариантностью, его уже нельзя воспринимать всерьёз.
В оригинале, Барбара и ко размышляли над поведением программы в рантайме и в итоге зашли со своим тезисом в тупик на уровне логики (что, в принципе, нормально для науки). Т.е., если замена одного компонента другим не меняет поведения программы, то зачем вообще это делать? Ведь обычно цель у разработчиков как раз обратная - мы заменяем один компонент на другой, для того что-то изменить в поведении программы.
В следующей части своей работы они попытались добавить в тезис уточнений, более точно очертив рамки неизменности. Но это не дало им особых преимуществ, лишь усложнив само правило. Как я понял, дальше эту тему решили не развивать.
Через несколько лет Дядя Боб вспомнил эту историю, которую когда-то услышал на совместной конференции, и решил использовать в качестве названия для только что придуманного им принципа, применительно к ООП. Позже Барбара говорила, что хоть LSP и не является тем, что она изначально имела ввиду, но благодарна Дяде за то, что тот увековечил её имя.
Если возьмем кодовую базу хорошо функционирующего софта из области энтерпрайза, то обнаружим, что она скорее следует лучшим практикам, чем отвергает их. В том числе всем или некоторым практикам SOLID. Поэтому пытаться их отменить глупо - они просто работают.
Мне нравится ход ваших рассуждений: красивый переход от "просто советы", до "просто работают". Возьму на вооружение когда нужно будет продать какой-нибудь хлам. Неспроста же он есть в любой кодовой базе - вещь в хозяйстве абсолютно незаменимая).
Лучшие практики, применененные не к месту, будут таким же плохим решением как и все остальные. Т.е. их качество не является каким-то абсолютом, а в каждом конкретном случае определяется контекстом конкретной задачи.
Если контрактом (интерфейсом) владеет исполнитель (сервер), то вы (клиент) вынуждены играть по чужим правилам (vendor lock). Это как в ситуации, когда сотовый оператор меняет условия "вашего" тарифа (ведь на самом деле это его тариф) в одностороннем порядке и вам остаётся лишь утереться и подстроиться (сделать рефакторинг). Это пример обычной "прямой" зависимости, где стрелки использования и зависимости при изменении сонаправлены - от клиента к серверу.
Когда же контракт находится на стороне клиента (вашей), то уже он диктует правила для сервера (исполнителя). Здесь как в случае контракта организации с наёмными сотрудниками - имея свой стандартный договор она может менять их потом как перчатки, в любой момент, без особых изменений на своей стороне. Подстраиваться под ваши условия это задача исполнителей. Именно в этом случае стрелки зависимости оказываются развернутыми в отношении стрелок использования, что и описывает DIP.
На уровне кода эта разница может быть выражена, например, на уровне пакетов: в чьём пакете находится определение интерфейса - клиента или сервера.
но если тыкнуть в какой-нибудь популярный продакшн-реди софт из мира энтерпрайза, то я на 99% уверен, что он более вероятно написан с учетом лучших практик, чем с их отрицанием
Первый фундаментальный закон кибернетики заключается в том, что разнообразие сложной системы требует управления, которое само обладает некоторым разнообразием.
Проблемы, которые встают на уровне энтерпрайз имеют большую комплексность и вариативность. Поэтому их решения не могут быть описаны таким простым языком, как SOLID, KISS, YAGNI и прочим народным фольклором.
Поэтому сборники лучших практик в энтерпрайзе: что-то вроде ISO/IEC 27001, Enterprise Integration Patterns, и т.п. - все они представляют собой очень толстые документы или книжки. Такие, что простым землекопам их как правило читать лень, некогда и дорого.
Нет, сами по себе такие "принципы" в отдельности имеют право на существование - равно как пословицы, прибаутки или анекдоты. Порой анекдот, рассказанный к месту, может описать точку ситуации лучше любой толстенной книги.
Но гипотетическое решение заменить несколькими анекдотами весь накопленный багаж знаний и опыта в области архитектуры и дизайна софта было бы уже само по себе анекдотом, да?
А ведь в некоторых кругах это обсуждают на серьёзных щщах, начиная прямо с тестирования сотрудников при приёме на работу. Тут мне становится страшновато за будущее.
На основе своего опыта и опыта коллег в проектах различного масштаба, где довелось участвовать за 25 лет карьеры.
Я здесь как-то уже просил адептов SOLID привезти в качестве примера ссылку на исходный код хотя бы одного реального проекта, построенного в соответствии с принципами, за которые они агитируют. Буду признателен и вам.
Мне нравится ваша попытка обесценить опыт, под соусом "ребята собрались под пивка", но нет.
Им тогда было меньше лет, чем мне сейчас. Имею право. ;)
Ну есть, например, теория типов https://en.m.wikipedia.org/wiki/Type_theory , в бекграунде которой лежат серьёзные исследования из разных областей математической логики. Она неплохо справляется с проблемами разработки, в том числе и в ОО стиле.
А SOLID в общем случае это такая же чушь собачья как советы уважаемых врачей из телевизора.
Дядя Боб не практик, а философ из институтской среды. Он пишет захватывающие произведения и делает вдохновляющие доклады, в которых лестно искать глубинный смысл долгими зимними вечерами. Его многие за это любят, уважают и ценят. Но все его слова нужно воспринимать с большой долей скептицизма, как только речь заходит о вашем конкретном проекте.
We are trying to compose The Ten Commandments of OO Programming.
Betrand Meyer said somewhere that there are about 20 good ideas in OO, and that is what the language(s) have to support.
Is it possible to boil everything down to 10?
Дескать, 20 хороших идей для ОО это хорошо, но абсолютно не практично - их же ни кто не запомнит. Заповедей должно быть 10! Robert Martin (aka Uncle Bob) тогда всех победил, предложив сначала 11 кандидатов, а потом еще сократив список.
Потом он публикует серию статей по мотивам, где спустя несколько итераций в итоге оставляет 5. Как оказалось мирянам, этого вполне достаточно, чтобы гарантированно создавать бурление в комментах. Принцип работает на протяжении уже 30 лет.
Как следует из самой постановки вопроса, за SOLID не было ни какой научной подоплеки. Просто несколько звучных тезисов, выбранных на собственный вкус. Насколько он практичен в области разработки софта, я думаю время уже сто раз показало. =)
Например, в python часто используют манкипаичинг. В JavaScript создаётся специальная сборка с API, которое позволяет заменять одни объекты другими в рантайме.
У меня в соцсетях полно людей, которые часто имеют противоположное моему мнение и жизненную позицию. Это бывшие одногрупники, сослуживцы, коллеги, случайные знакомые. Мне порой любопытны миры, которые отличаются от моего. Но это ни разу не про обшие интересы или доверие.
Плюс, если мы с кем-то контрибьютим в один и тот же опенсорс проект, это совершенно не означает, что мне будет интересна реклама сигарет, собачьего корма или средств от облысения.
Русскому слову национальность в английском больше соответствует ethnicity, обозначающее наследственное и культурное родство (как татары, евреи, удмурты, ...).
Nationality это откуда вы родом. Китайцы кто из Китая, французы, испанцы и т.д. - без относительно конкретной этнической принадлежности.
Nationality по смыслу ближе к гражданству citizenship, с той лишь разницей, что при эмиграции гражданство может поменяться, а nationality - как правило нет. Например, хотя в законодательстве US их формально и уравняли (all U.S. citizens are also nationals), но кто понаехал все равно не может стать президентом.
Не понимаю, почему так вот, не спросясь, и, да, куда на самом деле летят данные о звонках.
Для "почему" есть как минимум одно разумное объяснение. Еще летом в признаки мошеннических операций Центробанк добавил нетипичные телефонные звонки, совершенные клинетом в момент либо накануне операции. Тогда мне было непонятно откуда банки вообще смогут получать такие данные? Возможно приложения теперь стали каналом для сбора банками такой информации.
Ну а каким образом ещё будет использоваться полученная информация - вопрос, конечно, интересный.
Для организаций у них тоже интересные условия. Можно сэкономить если покупать лицензии не по факту, а заранее пачкой на год вперёд. Плюс потом делают скидку в зависимости от количества реально активированных лицензий. У нас одно время даже уговаривали бесплатно заменить домашние ключи корпоративными. Полагаю, что какая-то часть ключей попадает в паблик по тем же соображениям.
Unlike common posix shells, plumbum only captures stderr of the last command in a pipeline. If any of the other commands writes a large amount of text to the stderr, the whole pipeline will stall (large amount equals to >64k on posix systems). This can happen with bioinformatics tools that write progress information to stderr. To avoid this issue, you can discard stderr of the first commands or redirect it to a file.
Несмотря на то, что синтаксически они пытаются копировать sh, но работает это иначе и результат получается не таким как ожидаешь. В поддержке это кошмар.
Скорее, как обычно бывает в таких случаях, совмещаются только недостатки. Несмотря на все синтаксичнские ухищрения, в код приходится добавлять кучу лишних символов. А по существу, оно не поддерживает элементарное разделение stderr и stdout . Обработка ошибок тоже сделана своеобразно.
Для сборки из пайтона standalone нужно хорошее понимание внутрянки, нюансов того или иного тула и окружения. Особенно если в зависимостях используется что-то бинарное. Такие навыки находятся сильно сбоку, если вы просто пишите скрипты. Проще собрать docker контейнер. Но это все равно получается какое-то нагромождение.
LSP из SOLID это просто медийный шум.
По сути, он не имеет отношения к трудам той самой Барбары, где она лишь приводила похожую цитату из более ранней работы своего коллеги.
По существу, когда появились нормальные работы по теории типов, и люди разрбрались с вариантностью, его уже нельзя воспринимать всерьёз.
В оригинале, Барбара и ко размышляли над поведением программы в рантайме и в итоге зашли со своим тезисом в тупик на уровне логики (что, в принципе, нормально для науки). Т.е., если замена одного компонента другим не меняет поведения программы, то зачем вообще это делать? Ведь обычно цель у разработчиков как раз обратная - мы заменяем один компонент на другой, для того что-то изменить в поведении программы.
В следующей части своей работы они попытались добавить в тезис уточнений, более точно очертив рамки неизменности. Но это не дало им особых преимуществ, лишь усложнив само правило. Как я понял, дальше эту тему решили не развивать.
Через несколько лет Дядя Боб вспомнил эту историю, которую когда-то услышал на совместной конференции, и решил использовать в качестве названия для только что придуманного им принципа, применительно к ООП. Позже Барбара говорила, что хоть LSP и не является тем, что она изначально имела ввиду, но благодарна Дяде за то, что тот увековечил её имя.
5К на руки это порядка 9К net в среднем по Европе.
Мне нравится ход ваших рассуждений: красивый переход от "просто советы", до "просто работают". Возьму на вооружение когда нужно будет продать какой-нибудь хлам. Неспроста же он есть в любой кодовой базе - вещь в хозяйстве абсолютно незаменимая).
Лучшие практики, применененные не к месту, будут таким же плохим решением как и все остальные. Т.е. их качество не является каким-то абсолютом, а в каждом конкретном случае определяется контекстом конкретной задачи.
Если контрактом (интерфейсом) владеет исполнитель (сервер), то вы (клиент) вынуждены играть по чужим правилам (vendor lock). Это как в ситуации, когда сотовый оператор меняет условия "вашего" тарифа (ведь на самом деле это его тариф) в одностороннем порядке и вам остаётся лишь утереться и подстроиться (сделать рефакторинг). Это пример обычной "прямой" зависимости, где стрелки использования и зависимости при изменении сонаправлены - от клиента к серверу.
Когда же контракт находится на стороне клиента (вашей), то уже он диктует правила для сервера (исполнителя). Здесь как в случае контракта организации с наёмными сотрудниками - имея свой стандартный договор она может менять их потом как перчатки, в любой момент, без особых изменений на своей стороне. Подстраиваться под ваши условия это задача исполнителей. Именно в этом случае стрелки зависимости оказываются развернутыми в отношении стрелок использования, что и описывает DIP.
На уровне кода эта разница может быть выражена, например, на уровне пакетов: в чьём пакете находится определение интерфейса - клиента или сервера.
Первый фундаментальный закон кибернетики заключается в том, что разнообразие сложной системы требует управления, которое само обладает некоторым разнообразием.
Проблемы, которые встают на уровне энтерпрайз имеют большую комплексность и вариативность. Поэтому их решения не могут быть описаны таким простым языком, как SOLID, KISS, YAGNI и прочим народным фольклором.
Поэтому сборники лучших практик в энтерпрайзе: что-то вроде ISO/IEC 27001, Enterprise Integration Patterns, и т.п. - все они представляют собой очень толстые документы или книжки. Такие, что простым землекопам их как правило читать лень, некогда и дорого.
Нет, сами по себе такие "принципы" в отдельности имеют право на существование - равно как пословицы, прибаутки или анекдоты. Порой анекдот, рассказанный к месту, может описать точку ситуации лучше любой толстенной книги.
Но гипотетическое решение заменить несколькими анекдотами весь накопленный багаж знаний и опыта в области архитектуры и дизайна софта было бы уже само по себе анекдотом, да?
А ведь в некоторых кругах это обсуждают на серьёзных щщах, начиная прямо с тестирования сотрудников при приёме на работу. Тут мне становится страшновато за будущее.
На основе своего опыта и опыта коллег в проектах различного масштаба, где довелось участвовать за 25 лет карьеры.
Я здесь как-то уже просил адептов SOLID привезти в качестве примера ссылку на исходный код хотя бы одного реального проекта, построенного в соответствии с принципами, за которые они агитируют. Буду признателен и вам.
Им тогда было меньше лет, чем мне сейчас. Имею право. ;)
Ну есть, например, теория типов https://en.m.wikipedia.org/wiki/Type_theory , в бекграунде которой лежат серьёзные исследования из разных областей математической логики. Она неплохо справляется с проблемами разработки, в том числе и в ОО стиле.
А SOLID в общем случае это такая же чушь собачья как советы уважаемых врачей из телевизора.
Дядя Боб не практик, а философ из институтской среды. Он пишет захватывающие произведения и делает вдохновляющие доклады, в которых лестно искать глубинный смысл долгими зимними вечерами. Его многие за это любят, уважают и ценят. Но все его слова нужно воспринимать с большой долей скептицизма, как только речь заходит о вашем конкретном проекте.
В JavaScript трюк работает как раз благодаря компилятору, типа Babel. Вы, наверное, имели ввиду что-то другое?)
SOLID возник в 1995 году в переписке https://groups.google.com/g/comp.object/c/WICPDcXAMG8?hl=en&pli=1#adee7e5bd99ab111. Ребята весело проводили время, обсуждая количественный вопрос:
Дескать, 20 хороших идей для ОО это хорошо, но абсолютно не практично - их же ни кто не запомнит. Заповедей должно быть 10! Robert Martin (aka Uncle Bob) тогда всех победил, предложив сначала 11 кандидатов, а потом еще сократив список.
Потом он публикует серию статей по мотивам, где спустя несколько итераций в итоге оставляет 5. Как оказалось мирянам, этого вполне достаточно, чтобы гарантированно создавать бурление в комментах. Принцип работает на протяжении уже 30 лет.
Как следует из самой постановки вопроса, за SOLID не было ни какой научной подоплеки. Просто несколько звучных тезисов, выбранных на собственный вкус. Насколько он практичен в области разработки софта, я думаю время уже сто раз показало. =)
Например, в python часто используют манкипаичинг. В JavaScript создаётся специальная сборка с API, которое позволяет заменять одни объекты другими в рантайме.
У меня в соцсетях полно людей, которые часто имеют противоположное моему мнение и жизненную позицию. Это бывшие одногрупники, сослуживцы, коллеги, случайные знакомые. Мне порой любопытны миры, которые отличаются от моего. Но это ни разу не про обшие интересы или доверие.
Плюс, если мы с кем-то контрибьютим в один и тот же опенсорс проект, это совершенно не означает, что мне будет интересна реклама сигарет, собачьего корма или средств от облысения.
Не было печали, апдейтов накачали.
Тут ещё дело может быть в трудностях перевода.
Русскому слову национальность в английском больше соответствует ethnicity, обозначающее наследственное и культурное родство (как татары, евреи, удмурты, ...).
Nationality это откуда вы родом. Китайцы кто из Китая, французы, испанцы и т.д. - без относительно конкретной этнической принадлежности.
Nationality по смыслу ближе к гражданству citizenship, с той лишь разницей, что при эмиграции гражданство может поменяться, а nationality - как правило нет. Например, хотя в законодательстве US их формально и уравняли (all U.S. citizens are also nationals), но кто понаехал все равно не может стать президентом.
Для "почему" есть как минимум одно разумное объяснение. Еще летом в признаки мошеннических операций Центробанк добавил нетипичные телефонные звонки, совершенные клинетом в момент либо накануне операции. Тогда мне было непонятно откуда банки вообще смогут получать такие данные? Возможно приложения теперь стали каналом для сбора банками такой информации.
Ну а каким образом ещё будет использоваться полученная информация - вопрос, конечно, интересный.
В БРИКС создаётся свой сегмент - AI Alliance Network. Об этом был анонс в декабре https://www.reuters.com/technology/artificial-intelligence/russia-teams-up-with-brics-create-ai-alliance-putin-says-2024-12-11/. Здесь начали с бюрократии, американцы - бизнеса. Однако, номинальные цели у них в общем-то похожи.
Для организаций у них тоже интересные условия. Можно сэкономить если покупать лицензии не по факту, а заранее пачкой на год вперёд. Плюс потом делают скидку в зависимости от количества реально активированных лицензий. У нас одно время даже уговаривали бесплатно заменить домашние ключи корпоративными. Полагаю, что какая-то часть ключей попадает в паблик по тем же соображениям.
У них довольно своеобразная поддержка:
Несмотря на то, что синтаксически они пытаются копировать sh, но работает это иначе и результат получается не таким как ожидаешь. В поддержке это кошмар.
Если использовать только стандартные флажки (POSIX), то проблем с переносимостью будет меньше.
Скорее, как обычно бывает в таких случаях, совмещаются только недостатки. Несмотря на все синтаксичнские ухищрения, в код приходится добавлять кучу лишних символов. А по существу, оно не поддерживает элементарное разделение stderr и stdout . Обработка ошибок тоже сделана своеобразно.
Для сборки из пайтона standalone нужно хорошее понимание внутрянки, нюансов того или иного тула и окружения. Особенно если в зависимостях используется что-то бинарное. Такие навыки находятся сильно сбоку, если вы просто пишите скрипты. Проще собрать docker контейнер. Но это все равно получается какое-то нагромождение.