Строго говоря, они не только для ООП. Ну т.е. понятно, что если в языке нет наследования, и объектов, некоторые вещи в нем обязательно будут сформулированы иначе. Но общую идею вполне можно выделить. Ну вот давайте глянем на LSP. LSP вообще говоря про типы. А типы это совсем не обязательно ООП, это все что угодно, в функциональном языке они тоже есть.
Да. Вы правы, это и правда есть в русской версии, я правда не понимаю, почему это значительно ниже по тексту, потому что это и есть цель всех принципов.
Ну раз уж у нас цель упростить понимание, поддержку и расширение, из этого почти автоматически следует, что это не универсальные принципы, если нам и так легко понимать, поддерживать и расширять, то нам SOLID не нужно. Ну или сейчас не нужно - понятно, что если вы наймете в команду новых людей, особенно более низкой квалификации, то упрощение понимания для вас станет актуальным.
И еще нюанс, которого на мой взгляд многое может прояснить: по сути, все пять принципов сводятся к одному - нужно чтобы вносимые изменения были локальны. Т.е. новая функциональность не должна размазываться по всему коду. SOLID, которые по большей части говорят о слабой связности модулей, как раз эту локальность и обеспечивают - все по разному, но суть в общем-то одна.
Спасибо, но всё же пока не нашёл ответа на свой вопрос.
А вы сформулируйте вопрос четче. Пока не очень понятно, что вам непонятно.
Наследники должны соблюдать контракт. Иначе использование наследника сломает логику существующего кода в том месте, где использовался предок. В этом и цель - расширение кода путем создания класса наследника не должно ломать существующий код, который использует предка.
К сожалению, типы данных, включая сигнатуры методов, в существующих языках, недостаточно мощные, чтобы полностью описать контракт. Поэтому часть контракта описывается неформально, и не может быть проверена компилятором. Там где контракт сводится к сигнатуре функции, где функции чистые, то есть скажем в функциональных языках, LSP не имеет особого смысла - сигнатура совпадает - значит функцию можно использовать вот тут вместо другой. И это может проверить компилятор.
Все те статьи, что вы нашли, в большинстве своем страдают тем же недостатком, что и данная - они забывают за примерами кода основное назначение принципов, которое очень простое - чтобы код легко сопровождался и расширялся, при расширении не должно ломаться то, что уже написано ранее.
Вы возможно сами не заметили, но вы опустили в тексте то самое основное, для чего принципы нужны. Попробуйте например открыть статью про SOLID в английской википедии, и прочитайте первый абзац. Вы там найдете то самое "зачем", которое в вашем тексте на много страниц отсутствует. И когда вы это найдете, вы возможно для себя тоже поймете простую вещь:
Но цель статьи, ещё раз - совсем новичков с SOLID познакомить.
что может и не надо знакомить новичков с этим? Чтобы нормально понять данные принципы, надо на практике столкнуться с теми проблемами, которые они решают. А у новичков чаще всего такие проблемы просто не стоят.
И что самое смешное - понимание этого самого "зачем" как раз дает ответ на вопрос, нужно ли принципы эти пихать везде и всюду. Еще раз - смысл "зачем" нормально укладывается в один абзац. Попробуйте найти ответ сами.
Ну, сами-то советы по большей части вполне очевидные (хотя по этой же причине одновременно и банальные). Например, что не стоит думать, будто работодатели ждут вас, бакалавров, с распростертыми объятиями. Но они ведь и правда не ждут? В среднем.
Откуда автор может знать? Да ниоткуда, сочиняет из головы. Стоит ли этим советам верить? Я думаю вы и так знаете ответ - нет, полностью не стоит, но кому-то может пригодится. К ним лучше относиться как к личному мнению автора, чем они собственно и являются.
Так и не понял из текста, что же скрывается под "множество терабайтов и миллиарды строк". Это мешает понять, какими же реально масштабами они оперируют.
плагины на VBA можно писать и в грамотном современном виде
Только отчасти. VBA все равно останется устаревшим языком, с кучкой странных по сегодняшним временам решений. Чуть лучше сделать можно - но страдать все равно придется.
Если автор переписал 100 строк в 380, то мне приходилось переписывать 120 тысяч строк кода, которые были намного сложнее, чем работа с данными внутри листов таблицы. Там были и файловая система, и шина данных, и сложный UI.
Если у вас реально стоит задача переписать в современном виде - возьмите и перепишите на C#, будет намного, намного лучше.
Ну вот хорошо что у автора 0-арная функция. А если мы заходим использовать аргументы? Я пытался как-то разобраться с expressions, но так и уперся в отсутствие документации, скажем, непонятно где вот эти InternalRow взять, и что с ними можно делать.
Реализация генератора UUID с использованием UDF проста.
Я бы хотел отметить, что на самом деле все не всегда так просто, даже для такой простой функции. Дело в том, что UDF сериализуются и передаются в executors, это во-первых (ну, те кто программирует на спарке, уже должны это обычно знать).
Но тут еще могут добавляться вопросы с класслоадерами. Скажем, мы как-то попытались создать экземпляр UDF и зарегистрировать его в groovy скрипте, который динамически выполнялся из кода на спарке. Так вот, ничего не получилось, потому что класслоадер оказался другой, и наша функция имела сигнатуру, отличную от нужной. А как устроены класслоадеры в спарке, описано примерно так же, как описано создание catalyst выражений из этой статьи - т.е. примерно никак.
Не, ну спортивно или нет - это другая история. Ну вот последний проект, что я смотрел - это был apache kerby, который является открытой java реализацией Kerberos - сервера и клиента. Ну т.е. это проект достаточно крупный, и в тоже время это проект, который можно охватить целиком (пусть и не за 15 минут). И там, для сравнения, всего 43 pom.xml (я посчитал). Вот мне поэтому и интересно - у вас проект, условно, в три раза сложнее? Или ваши модули по какой-то причине наполненные, но мелкие? Ну или еще проще - у вас очевидно есть проблемы с управлением этими сотнями модулей - вы про них статью написали, так? А вот где профит от таких мелких модулей в большом количестве? Ну раз вы их в таком количестве создаете - значит это чем-то удобно?
Как по мне, тут не хватает одной вещи - оценки масштаба проектов с какой-то другой точки зрения. Ну т.е. вот у вас 120 модулей получилось - у вас в проекте скажем сколько LOC? Как понять, много это модулей, или мало, как оценить объективно?
Ну, да, но я бы сказал, что в каком-то смысле это одно и тоже. Если вы в другой плоскости - вам просто понадобится еще много характеристической скорости, чтобы эту плоскость повернуть. Причем я много раз сталкивался с тем, что люди, не изучавшие баллистику, не понимают интуитивно, насколько это "много" (ну т.е. не держат в голове, что скорость это вектор, и что поворот вектора - это может быть большая дельта, даже если модуль не изменился).
Ну вы можете смотреть на дельту, разумеется, и это правильно. Тем не менее, если в тексте (не для специалистов) написано "орбита 450 км, близкая к геостационарной", и ничего не написано про дельту (про критерий "близости") - этот текст мне кажется неграмотным. Да не, наверное даже не кажется, а он такой и есть.
Мне кажется, вы усложняете. Повесить трубку, и в черный список. Какие могут быть минусы, даже если это настоящий капитан (я оцениваю вероятность такого варианта в контексте разговора как строго нулевую)?
И еще заметьте - такая штука, как синтез голоса, уже реальность. Чем больше вы наговорите с этим "капитаном" - тем больше шансы, что из вашего образца голоса потом что-то синтезируют. А оно вам надо?
Я верю, что Роскосмос отличает 450 км от геостационара, и что в другом месте где-то все написали правильно. Меня смущает, что в данном тексте в одном предложении утверждается, что 450 км это близко к геостационару. И хотелось бы понять, кто это так лажает?
Вот упомянутый вами разгонный блок «Орион» - вот его и должны были вывести на 450 км, и это было бы ожидаемо. Только он и не полезная нагрузка, строго говоря.
Строго говоря, они не только для ООП. Ну т.е. понятно, что если в языке нет наследования, и объектов, некоторые вещи в нем обязательно будут сформулированы иначе. Но общую идею вполне можно выделить. Ну вот давайте глянем на LSP. LSP вообще говоря про типы. А типы это совсем не обязательно ООП, это все что угодно, в функциональном языке они тоже есть.
Ну куда копать, примерно понятно. Скажем, вот: https://books.japila.pl/spark-sql-internals/expressions/ScalaUDF/#one-argument-udf
Да. Вы правы, это и правда есть в русской версии, я правда не понимаю, почему это значительно ниже по тексту, потому что это и есть цель всех принципов.
Ну раз уж у нас цель упростить понимание, поддержку и расширение, из этого почти автоматически следует, что это не универсальные принципы, если нам и так легко понимать, поддерживать и расширять, то нам SOLID не нужно. Ну или сейчас не нужно - понятно, что если вы наймете в команду новых людей, особенно более низкой квалификации, то упрощение понимания для вас станет актуальным.
И еще нюанс, которого на мой взгляд многое может прояснить: по сути, все пять принципов сводятся к одному - нужно чтобы вносимые изменения были локальны. Т.е. новая функциональность не должна размазываться по всему коду. SOLID, которые по большей части говорят о слабой связности модулей, как раз эту локальность и обеспечивают - все по разному, но суть в общем-то одна.
А вы сформулируйте вопрос четче. Пока не очень понятно, что вам непонятно.
Наследники должны соблюдать контракт. Иначе использование наследника сломает логику существующего кода в том месте, где использовался предок. В этом и цель - расширение кода путем создания класса наследника не должно ломать существующий код, который использует предка.
К сожалению, типы данных, включая сигнатуры методов, в существующих языках, недостаточно мощные, чтобы полностью описать контракт. Поэтому часть контракта описывается неформально, и не может быть проверена компилятором. Там где контракт сводится к сигнатуре функции, где функции чистые, то есть скажем в функциональных языках, LSP не имеет особого смысла - сигнатура совпадает - значит функцию можно использовать вот тут вместо другой. И это может проверить компилятор.
Все те статьи, что вы нашли, в большинстве своем страдают тем же недостатком, что и данная - они забывают за примерами кода основное назначение принципов, которое очень простое - чтобы код легко сопровождался и расширялся, при расширении не должно ломаться то, что уже написано ранее.
Вы возможно сами не заметили, но вы опустили в тексте то самое основное, для чего принципы нужны. Попробуйте например открыть статью про SOLID в английской википедии, и прочитайте первый абзац. Вы там найдете то самое "зачем", которое в вашем тексте на много страниц отсутствует. И когда вы это найдете, вы возможно для себя тоже поймете простую вещь:
что может и не надо знакомить новичков с этим? Чтобы нормально понять данные принципы, надо на практике столкнуться с теми проблемами, которые они решают. А у новичков чаще всего такие проблемы просто не стоят.
И что самое смешное - понимание этого самого "зачем" как раз дает ответ на вопрос, нужно ли принципы эти пихать везде и всюду. Еще раз - смысл "зачем" нормально укладывается в один абзац. Попробуйте найти ответ сами.
Ну, сами-то советы по большей части вполне очевидные (хотя по этой же причине одновременно и банальные). Например, что не стоит думать, будто работодатели ждут вас, бакалавров, с распростертыми объятиями. Но они ведь и правда не ждут? В среднем.
Откуда автор может знать? Да ниоткуда, сочиняет из головы. Стоит ли этим советам верить? Я думаю вы и так знаете ответ - нет, полностью не стоит, но кому-то может пригодится. К ним лучше относиться как к личному мнению автора, чем они собственно и являются.
Так и не понял из текста, что же скрывается под "множество терабайтов и миллиарды строк". Это мешает понять, какими же реально масштабами они оперируют.
Только отчасти. VBA все равно останется устаревшим языком, с кучкой странных по сегодняшним временам решений. Чуть лучше сделать можно - но страдать все равно придется.
Если автор переписал 100 строк в 380, то мне приходилось переписывать 120 тысяч строк кода, которые были намного сложнее, чем работа с данными внутри листов таблицы. Там были и файловая система, и шина данных, и сложный UI.
Если у вас реально стоит задача переписать в современном виде - возьмите и перепишите на C#, будет намного, намного лучше.
О, давайте-давайте, будем ждать.
Ну вот хорошо что у автора 0-арная функция. А если мы заходим использовать аргументы? Я пытался как-то разобраться с expressions, но так и уперся в отсутствие документации, скажем, непонятно где вот эти
InternalRow взять, и что с ними можно делать.Я бы хотел отметить, что на самом деле все не всегда так просто, даже для такой простой функции. Дело в том, что UDF сериализуются и передаются в executors, это во-первых (ну, те кто программирует на спарке, уже должны это обычно знать).
Но тут еще могут добавляться вопросы с класслоадерами. Скажем, мы как-то попытались создать экземпляр UDF и зарегистрировать его в groovy скрипте, который динамически выполнялся из кода на спарке. Так вот, ничего не получилось, потому что класслоадер оказался другой, и наша функция имела сигнатуру, отличную от нужной. А как устроены класслоадеры в спарке, описано примерно так же, как описано создание catalyst выражений из этой статьи - т.е. примерно никак.
Ну мне оценить сложно, насколько это может быть полезно, но идею я понял.
Ну то есть это скорее особенность андроида, нежели ваших проектов?
Не, ну спортивно или нет - это другая история. Ну вот последний проект, что я смотрел - это был apache kerby, который является открытой java реализацией Kerberos - сервера и клиента. Ну т.е. это проект достаточно крупный, и в тоже время это проект, который можно охватить целиком (пусть и не за 15 минут). И там, для сравнения, всего 43 pom.xml (я посчитал). Вот мне поэтому и интересно - у вас проект, условно, в три раза сложнее? Или ваши модули по какой-то причине наполненные, но мелкие? Ну или еще проще - у вас очевидно есть проблемы с управлением этими сотнями модулей - вы про них статью написали, так? А вот где профит от таких мелких модулей в большом количестве? Ну раз вы их в таком количестве создаете - значит это чем-то удобно?
Как по мне, тут не хватает одной вещи - оценки масштаба проектов с какой-то другой точки зрения. Ну т.е. вот у вас 120 модулей получилось - у вас в проекте скажем сколько LOC? Как понять, много это модулей, или мало, как оценить объективно?
Нууу... я по умолчанию сегодня исхожу из того, что позвонили на мобильный. Все же стационарные телефоны уже более редки нынче.
Ну, да, но я бы сказал, что в каком-то смысле это одно и тоже. Если вы в другой плоскости - вам просто понадобится еще много характеристической скорости, чтобы эту плоскость повернуть. Причем я много раз сталкивался с тем, что люди, не изучавшие баллистику, не понимают интуитивно, насколько это "много" (ну т.е. не держат в голове, что скорость это вектор, и что поворот вектора - это может быть большая дельта, даже если модуль не изменился).
Ну вы можете смотреть на дельту, разумеется, и это правильно. Тем не менее, если в тексте (не для специалистов) написано "орбита 450 км, близкая к геостационарной", и ничего не написано про дельту (про критерий "близости") - этот текст мне кажется неграмотным. Да не, наверное даже не кажется, а он такой и есть.
Мне кажется, вы усложняете. Повесить трубку, и в черный список. Какие могут быть минусы, даже если это настоящий капитан (я оцениваю вероятность такого варианта в контексте разговора как строго нулевую)?
И еще заметьте - такая штука, как синтез голоса, уже реальность. Чем больше вы наговорите с этим "капитаном" - тем больше шансы, что из вашего образца голоса потом что-то синтезируют. А оно вам надо?
Я верю, что Роскосмос отличает 450 км от геостационара, и что в другом месте где-то все написали правильно. Меня смущает, что в данном тексте в одном предложении утверждается, что 450 км это близко к геостационару. И хотелось бы понять, кто это так лажает?
Вот упомянутый вами разгонный блок «Орион» - вот его и должны были вывести на 450 км, и это было бы ожидаемо. Только он и не полезная нагрузка, строго говоря.