Comments 1280
те языки и подходы, которые в итоге оказывались самыми практичными и популярными
Популярность — продукт рекламы и продвижения крупными компаниями. Качество при этом и рядом не валялось. Только финансовые интересы.
А с учетом такой популярности про практичность говорить бессмысленно.
Всё-таки между академическим программированием и прикладным есть большая разница.
Прикладное программирование — это когда школота лепит быдлокод? Для них и придуман был ООП.
Один мой знакомый в давние времена сказал такую умную вещь: объектное программирование должно быть в голове, а не в языке.
А большинству современных программистов до Дейкстры, как до Шанхая…
Прикладное программирование — это когда школота лепит быдлокод?
Ну, если школота прямо сейчас решит задачу, которая позволит уже завтра продать продукт, то почему нет? У меня есть один коллега, все ворчит, что код не тот. Но когда ему говоришь «ОК. У тебя появляются возможность 2 дня писать код без оплаты». Он вдруг задает вопрос, а почему это?
Академический интерес это очень занятная штука. Заставляет шевелить мозгами и это очень даже хорошо. Но проблема в том, что она не всегда приносит денег! А деньги люди очень любят, думаю и вы тоже!
Хотим мы с вами или нет, но мы решаем задачи бизнеса. А пользователь на бизнес стороне, как правило, понятия не имее про ООП или BDD или синглтон. Ему наплевать что там в кишках! Он просто тыкает кнопку и если она не решает его задачу он не платит денег. И хоть вы там идеальную архитектуру наколбасите ему будет пофиг, лишь бы кнопка делала то что надо!
Когда вас просят «добавить рюшечку» и вы это делаете — без плана и дизайна, то получается пресловутый Дом Винчестеров.
Автор же, совершенно справедливо, отмечает, что нормальные, удобные дома — так не строят. Но до этого индустрия разработки ПО — пока не доросла.
На самом деле методы написания хороших программ были придуманы и стандартизованы ещё во времена первых Space Shuttle. Просто до сих пор мало кто в это умеет: из-за холиварщиков типа Дейкстры программисты уже три десятка лет занимаются поиском самого "правильного" языка программирования и обсиранием "неправильных" языков: это как если бы электронщики каждые 5-10 лет придумывали новый набор обозначений на схемах для отображения всё тех же резисторов, транзисторов и конденсаторов.
А решение проблемы находится на более высоком уровне: на уровне организации, методик и подходов.
А решение проблемы находится на более высоком уровне: на уровне организации, методик и подходов.… которые не позволяют даже NASA избежать ошибок…
Обозначения тоже важны, просто в последнее время им уделяется куда больше внимания, чем следует.
Это уже скорее аналог добавления новых функций в библиотеку: никто не пересматривает обозначения резистора, например, или сложения в математике.
Навскидку.
Всё в порядке с диодами, просто не надо путать направление тока и направление движения электронов!
Если вы желаете исправить "ошибку" — надо начинать с пересмотра определения электрического заряда, чтобы он стал у электрона положительным. Но не думаю что физики такой пересмотр поддержат.
Есть 2 обозначения резисторов, «советский» прямоугольником и «западный» пилой.
Есть примеры и в математике: tg и tan, скажем. Или десятичная запятая/точка.
Диоды следовало бы пересмотреть — когда рисовали их значок, думали что ток течёт в другую сторону, а дальше «так исторически сложилось».
А вот тут никакой проблемы нет. Направление тока (туда же, куда электроны, или в противоположную сторону) вообще не имеет особого значения на практике для расчёта цепей. Надо просто один раз договориться. И договорились: от плюса к минусу.
На самом деле методы написания хороших программ были придуманы и стандартизованы ещё во времена первых Space Shuttle.И сколько такие методы будут стоить компаниям? В том-то и проблема что хорошесть программ может определяться очень разными способами, не существует универсального параметра качества. И стоимость разработки решения практически всегда вносит определенный вклад в то, насколько программа хороша для ее заказчика.
И именно эту проблему как раз помогает если не решать, то слегка уменьшать ООП. Каждая новая рюшечка более-менее отдельный монстр
1. Пользователь решил проблему. Больше не пришел
2. Кроме одного пользователя эту сделанную фичу больше никто не использовал
3. Пользователь решил проблему. Пришел с багой\предложением
…
и еще 100500 вариантов развития будущего.
Вы уверены, что в написанном коде вам действительно придется ковыряться и что-то переделывать? Да, можно вспомнить закон Мерфи про то что худшее по-любому случится, если оно может случиться. Но на практике вариаций развития будущего масса! Как надо будет переписывать так и не надо, а иногда и оказалось не надо и лучше удалить код, нет кода — нет багов!
Мы же когда пишем код мы же обычно так поступаем:
Встретилась задача просто пишем код. Встретилась второй раз тупо копи-пастим. Встретилась в третий — выносим в отдельную функцию. Втретилась в четвертый — выносим в библиотеку.
Ну так и тут надо также! Сначала вы просто пишете код. Да, стараетесь написать по-лучше. Но слишком заморачиваться не стоит, т.к. «лучшее враг хорошего». И уж если потом потребуется тогда и сделаете как надо, т.е. тогда, когда это действительно будет оправдано.
Другими словами: Если значимость и ценность кода еще не доказана требованиями бизнеса, то тратить на него слишком много времени и усилий не следует. Исходить нужно из математической фразы «необходимо и достаточно»
Исходить нужно из математической фразы «необходимо и достаточно»
Я всё же предпочитаю делать небольшой "запас прочности", да хотя бы чтобы удалить больше ненужный код было просто без особых рисков сломать что-то.
Чтобы написать хороший код вы должно понимать (и желательно хорошо так понимать) — что за код вы пишите и как он долежн работать.
Чтобы написать плохой код… вам не нужно ничего. Тяп-ляп и в продакшн.
То есть написать какой-то плохой код — гораздо быстрее, написать отлаженный плохой код… на самом деле даже дольше, чем хороший… но кого это волнует?
Посмотрите вокруг: «потерявшиеся» кортинки, неработающие кнопки и так далее и тому подобное… это же норма! Никто не доводит код до безошибочного состояния.
Мы, программисты, всегда почему-то свято верим в то, что пользователь придет и по-любому попросит что-то поменять\добавить. А это не так! Да, приходят и просят, но не всегда! Очень часто решат свою задачу и забудут, то у вас в принципе есть такая хорошая программа.
Как я в прошлом году пошел в гугл, нашел youtube-видео-даулодер, поставил, скачал видео и все! Больше я НИ РАЗУ с прошлого года эту прогу не запускал. Мне абсолютно наплевать насколько там идеально хорошо продумана архитектура.
Вот вы напишите сразу «хорошо» потратите на 5 часов больше времени, а пользователь больше ни разу не обратиться по поводу вами разработанной фичи. А из какого кармана эти допольнительные 5 часов будут оплачиваться? Из вашего? Согласны, чтоб из вашего, а не работодателя?
Слово "клиент" подразумевает несколько другую модель разработки по сравнению с публичными небольшими программами. В разработке на заказ или длительной продуктовой очень часто просьбы что-то изменить приходят ещё до того как работа доведена до какого-то логического конца. Да и вы один раз воспользовались, а, возможно десятки тысяч людей пользуются регулярно и просят авторв что-то улучшить, чтобы пользоваться было удобнее.
Во второй половине XX века во время холодной войны наука и технология бурно развивались за счет заказов от военно-промышленного комплекса. Ну и в виде побочного продукта доставалось гражданке.
Сейчас военные расслабились, вместо реальной работы придуряются, активно пилят огромные бюджеты. Результат на лицо.
А бизнесу нужны только деньги, ничего кроме денег. В программировании деньги в основном зарабатываются на рекламе. Все эти поисковики, мессенджены и пр. заточены на втюхивание китайских товаров.
Правильные языки никому не нужны, энтузиасты без финансирования даже если сделают, без агрессивного продвижения никто не будет такой язык использовать.
И еще, популярность Java Scrip обусловлена саботажем разработчиков браузеров. Почему нельзя сделать нормальный вменяемый язык для фронтенда с контролем типов? Вот и выросло поколение горе-программистов, не понимающих, зачем нужен статический контроль типов, проверка используемости процедур (или, как сейчас модно говорить, методов). Объяснять таким полезность контроля равносильно попытке объяснять глухому от рождения величие классической музыки. И это не их вина, это их беда.
Почему нельзя сделать нормальный вменяемый язык для фронтенда с контролем типов
А разве таковым не был Dart который не взлетел?
Другое дело, что оказалось не так-то просто добавить статическую типизацию в LISP и не потерять его выразительности…
Самая лучшая апологетика динамической типизации (не с ура-пофигистских позиций типа «а нафига типы?»), которую я видел, здесь:
youtu.be/YR5WdGrpoug
youtu.be/2V1FtfBDsLU?t=1143 (можно даже отсюда начать: youtu.be/2V1FtfBDsLU?t=1639)
Расшифровка есть?
Текст выступления? Или перевод на русский?
Насколько я знаю, ни того, ни другого нет.
Ни разу не использовал void* даже в C++, ЧЯДНТ?
Прекрасная позиция, ведь за Вас его используют авторы библиотек. )) Вот пусть они и отдуваются)))
А void* — да, с ним авторы библиотек пусть возятся. Это их работа.
Я, если что, писал свой any и свой variant. Даже там как-то удалось обойтись без void*.
Было бы занятно взглянуть. Это возможно?
Если Вы используете такой срез C++, где не нужно явно использовать просто машинный адрес и/или взаимодействовать с C — почему нет. Но я бы не стал этим гордится)))
А так — указатель на базовый класс, от которого наследуется шаблонный производный класс. Всё. Никаких void*, всё очень типобезопасно.
И указатель на этот самый базовый класс и оказывается нижней гранью выбранной «подсистемы» типов. Но C++ не ограничивается только этой «подсистемой», поэтому void* в нем необходим.
Я понял, что Вы имеете в виду. Согласен, для каждого конкретного случая можно обойтись без void*, зафиксировав нужные типы в параметрах шаблонов.
Но не согласен, что void* не является полноценным элементом системы типов. Как и просто void, в шаблонах он тоже вылазит и, по слухам, там без него не обойтись. То, что void* можно использовать для обхода типизации — следствие наличия в языке низкоуровневых средств и особенностей типа «указатель на» (преобразование T*->void*->T* безопасно). Именно это средство C++ делает возможным «бескомпромиссную совместимость» с миром C и с аппаратурой, например.
Так что гордится тем, что ни разу не использовал void* не стоит: просто повезло запереть себя в «чистой комнате». Как-то так)
Впрочем, давайте с другой стороны. Почему при работе с железом нельзя обойтись без void*?
Возможно, это просто историсеское наследие, но думаю, что преобразование беззнаковых целых в указатели так или иначе включает «создание» void* из целого. Указатель ведь, по сути, структура с битовыми полями и кучей атрибутов, и на низком уровне на него накладываются ограничения, которые, ну, скажем, невыразимы в языке, по крайней мере в текущем виде. Нужен какой-то тип данных, который позволит все это делать. Я так думаю. Это может быть и не видно явно, для C и даже C++ такая спрятанная в компилятор неявность — дело обычное.
И да, указатель на байт может заменить указатель на void. Но что это даст в плане типобезопасности? Те же яйца, вид сбоку, в gnuc void* ведет себя, как byte*.
Вон сколько уже ISO/IEC TR 18037 все не примут, так и нужда пройдет.
Остался в языке для совместимости с C, видимо.
Сколько безобразного кода люди готовы написать только для того, чтобы гордо заявлять «мне void* не нужен!»… )))
И Алан Кей и Рич Хики говорят, что ещё не видели системы типов, которая бы помогала, а не мешала, и не причиняла бы боль.
Ну вы не ровняйте всех программистов с Кеем и Хикки. Им, может, и не помогает, а программистам ниже уровня — помогает вполне.
Я вот дурачок, самому думать трудно, по-этому мне часто проще, когда за меня думает тайпчекер.
Самая лучшая апологетика динамической типизации
Рассуждать о динамике вс статике сейчас имеет смысл исключительно в контексте тайскрипта. С-но, значительную часть проблем тс решает, из оставшейся части значительную часть — не решает, но оно в принципе решаемо.
Ну, если школота прямо сейчас решит задачу, которая позволит уже завтра продать продукт, то почему нет?
Потому что предпочтительнее считается смотреть не только на один день вперед, но ещё и на два, а иногда и ещё больше, например?
Если вы конечно не фрилансер, или не аутсорс контора которая не заботиться о своей репутации и стремиться выжать из заказчика денег любым способом и распрощаться
Потому что предпочтительнее считается смотреть не только на один день вперед, но ещё и на два, а иногда и ещё больше, например?Далеко не всегда. Стандартная ситуация с начинающей компанией — есть предположение что наше решение решит чью-то проблему. Можно долго создавать крутое решение, потратить кучу денег на него, а можно быстро накидать МВП и выкатить его. В случае если решение действительно нужное — да, первый вариант, скорее всего, в итоге окажется выгоднее. Если не совсем и нужно допиливать — возможно и так, и так. Если совсем нет, то, очевидно что второй вариант потратит заметно меньше ресурсов. И даже в первом случае выкатить что-то на говнокоде и допиливать потом имеет смысл. Потому что оно принесет денег вот сейчас — тех самых денег, которые нужны чтобы таки сделать хороший продукт. Совсем не факт что такие деньги на старте вообще есть.
Я что пытаюсь сказать на самом деле — заглядывать в будущее конечно хорошо и правильно, вот только никто не умеет это делать надежно. И в условиях ограниченных ресурсов вариант делать сейчас как кажется правильным, а что будет потом — будет потом, вполне может оказаться выгоднее.
Стандартная ситуация с начинающей компанией — есть предположение что наше решение решит чью-то проблему. Можно долго создавать крутое решение, потратить кучу денег на него, а можно быстро накидать МВП и выкатить его.
А речи про крутое решение за куччу денег не было, можно и MVP накидать нормально, а можно сделать уже абсолютно нерасширяемую программку.
очевидно что второй вариант потратит заметно меньше ресурсов
martinfowler.com/bliki/DesignStaminaHypothesis.html
И даже в первом случае выкатить что-то на говнокоде и допиливать потом имеет смысл
Много проектов фейлится и после этапа MVP, и при оценке рисков не стоит забывать, что после MVP мы не попадаем в сказочную страну где мы монополист на огромном рынке и гребем деньги лопатой, мы попадаем в реальность, где рядышком уже существуют 10 копий вашего бизнеса заметивших что к теме есть интерес, и пока вы будете тратить кучу времени на рефакторинг вашего MVP в попытках приспособить его к новым требованиям ловя баги с каждым релизом, конкуренты будут делать качественный и стабильный продукт, выкатывая новые фичи в срок и не ломая старый фукционал.
И в условиях ограниченных ресурсов вариант делать сейчас как кажется правильным, а что будет потом — будет потом, вполне может оказаться выгоднее.
А может совсем и не оказаться. Вопрос в том, происходит ли оценка рисков, или higest payed person/product owner считает что «так выгоднее», потому что ни капли не программист и далёк от критериев качества ПО.
Если конкуренты начинают с нуля, то и мы можем начать с нуля, уже имея своих пользователей.
Легко можно продать:
пока вы будете тратить кучу времени на рефакторинг вашего MVP в попытках приспособить его к новым требованиям ловя баги с каждым релизом, конкуренты будут делать качественный и стабильный продукт, выкатывая новые фичи в срок и не ломая старый фукционал.
:)
Может, как я и писал, можно, но я не слышал о таких success story, возможно потому что объяснять уже нужно будет не только бизнесу, а ещё и юзерам/инвесторам как-то сознаться что в продукте все не так радужно.
Возможно потому, что, опять же, дорого, конкурентов надо как-то обгонять.
Я понимаю, потому и смайлик поставил. На самом деле при разработке чего-то вроде MVP и его дальнейшем развитии я стараюсь искать баланс между скоростью и поддерживаемостью/расширяемостью/… Благо веб-разработка позволяет относительно малой кровью совмещать старый и новый код даже на разных фреймворках, языках, ОС и прочих платформах, часто всего лишь изменением конфига реверс-прокси.
конкуренты будут делать качественный и стабильный продукт, выкатывая новые фичи в срок и не ломая старый фукционал.Чтобы получилось как вы говорите нужно чтобы конкуренты умели сделать быстро и качественно то, что мы умеем либо быстро, либо качественно. В рельности же скорее всего конкуренты после нашего MVP будут все же на шаг позади. И если они начнут долго и упорно пилить идеальный продукт, то о них можно вообще не думать, к тому моменту как они закончат рынок уже будет поделен среди тех кто выкатывал быстро но не очень качественно.
Вопрос в том, происходит ли оценка рисков, или higest payed person/product owner считает что «так выгоднее», потому что ни капли не программист и далёк от критериев качества ПО.А этот вопрос вообще за рамками текущего обсуждения. То же самое может произойти в любом случае.
Ну и обычно MVP всё же часть будущего продукта, а не вещь которую скоро выкинут
Дело в том что проект и с кучей неизвестных можно сделать более менее качественным и расширяемым, и не иметь необходимости его переписывать.Я в этом не уверен. В каких-то частных случаях — наверняка. Но мне не сложно представить случай когда расширяемость будет сделана не для того и не туда для чего и куда она будет нужна. Можно попробовать запланировать расширяемость во все возможные направления, но результат будет так себе выглядеть и работать будет, скорее всего, совсем не просто. И даже так для меня не очевидно что это в принципе всегда возможно.
Анализ потока изменений имеет место быть, но при грамотном проектировании не должно происходить ситуаций требующих переписывания значительной части приложения, а в «написанном школниками на коленке» MVP — вполне себе.
Изменения изменениям рознь. И ошибки могут быть не только в проектировании, но и в постановках.
Невозможность архитектуры приспособиться к каким-либо изменениям говорит об ошибках в проектированииКонечно это ошибки. Но не потому что плохо подумали, а потому что предположили другое будущее. Невозможно создать архитектуру которую будет одновременно легко поддерживать и легко расширять вообще в любую сторону. По-крайней мере я такой архитектуры никогда не встречал. А если мы выбираем сторону куда мы предполагаем что будет расширяться приложение, то мы всегда можем ошибиться. Люди не умеют видеть будущее.
Но не потому что плохо подумали, а потому что предположили другое будущее.
Предполагать будущее — так себе затея.
Если мы пока что не предполагаем, например, что наше приложение будет использовать другие устройства ввода/вывода, это вовсе не повод забыть про абстрагирование от них, и лепить прямую зависимость из всех модулей что с i/o работают.
Я не спорю что ошибки будут всегда, проектированием мы стараемся сократить их количество, и упростить процесс их исправления.
Между случаем когда опытные разработчики хоть немного задумываются об архитектуре на MVP, и случаем, когда проект делают, как выше было сказано, «школьники на коленке», разница огромна.
Ну и время на создание MVP все же оптимизируется сокращением и упрощением фич, а не выкидыванием этапа проектирования/рефакторинга.
Предполагать будущее — так себе затея.Конечно. Именно об этом я и говорю. Но не предполагая будущего вы не сможете построить расширяемую систему. Потому что вам необходимо знать куда она должна уметь расширяться.
не выкидыванием этапа проектирования/рефакторинга.Никто не говорит про выкидывание. Но очевидно что на этот этап можно потратить разное количество времени. И достаточно очевидно что с какого-то момента дополнительное затраченное на него время будет приносить все меньше и меньше пользы, а потом даже начнет работать во вред. Вы про overengeneering когда-нибудь слышали? Термин не на пустом месте появился, его не маркетологи придумали.
Но не предполагая будущего вы не сможете построить расширяемую систему. Потому что вам необходимо знать куда она должна уметь расширяться.
Так ведь суть проектирования в том чтобы при появлении новых / изменении требований менять как можно меньше кода, для этого ведь нужны всякие DI, OCP, ISP. Подготовить почту для каки-то определыннх вариантов развития, и совершенно не учитывать другие сродни игры в русскую рулетку в которой при удаче проигрыш лишь отложиться на некоторое время.
Вы про overengeneering когда-нибудь слышали? Термин не на пустом месте появился, его не маркетологи придумали.
Да, но я не считаю что посадить на проект разработчиков, а не «школьников на коленке» — оверинжиниринг.
Так ведь суть проектирования в том чтобы при появлении новых / изменении требований менять как можно меньше кода, для этого ведь нужны всякие DI, OCP, ISP.Я не очень понимаю — вы пытаетесь сказать что всегда можно спроектировать так чтобы потом не было проблем с расширением? Или с чем именно вы спорите?
Быстро сделав прототип «тяп-ляп», мы получаем:
— возможность рекламировать что-то относительно реальное, а не «вот через 10 лет будет вау»
— Инвесторы гораздо легче одобрят что-то прототипное прямо сейчас, чем графики-картинки и сказки как будет круто
— можно набирать пользователей, получать реальную обратную связь, действительно полезные замечания внедрять сразу
— В конце концов, это даст возможность оценивать реальную нужность идеи.
Потом, когда будет первая версия, есть дизайн, некий костяк пользователей, понятно что на самом деле нужно а что шелуха, тогда нужно будет заново провести оценку решения, если надо — сменить язык, и написать нормально. Но пока нет «нормально» — придётся поддерживать прототип.
Один мой знакомый в давние времена сказал такую умную вещь: объектное программирование должно быть в голове, а не в языке.Можно ли мыслить не на языке, тем более измысливать программы и структуры данных? Просто обычно мыслят на языках программирования более высокого уровня, чем пишут код.
Много используете программ, написанных Дейкстрой? Я — ни одной.
Алгоритм Дейкстры мы все используем, когда пользуемся интернетом.
Но вообще так бывает, что гениальный человек оказывается не способен до конца понять и отвергает какие-то идеи из субъективных соображений. Вон Эйнштейн так до конца и не принял квантовую механику, хоть и сам сыграл ключевую роль в ее зарождении.
те языки и подходы, которые в итоге оказывались самыми практичными и популярными
А, например, COBOL вы в ту же категорию относите?
На COBOL крутится очень много бизнес-логики, на нём до сих пор пишут ПО. Раз его используют спецы в этой области — значит для своих задач он хорош. Мнение человека вроде Дейкстры, не имеющего опыта в энтерпрайзе, годится лишь для холиваров. Для меня вообще удивительно, что он допускал такие резкие высказывания — видимо в академической среде какая-то своя атмосфера: не шарящим студентам, лижущим тебе задницу ради оценки, всегда можно навешать на уши х*ету.
Раз его используют спецы в этой области — значит для своих задач он хорош.
Нет, не значит. Скорее это значит что так 'исторически сложилось'
Во всяком случае это решать спецам, а не холиварщикам со стороны.
То есть это очень опасный процесс, способный даже бизнесу нанести огромные проблемы, при этом профит возможен только на длинном отрезке времени, в виде ускорения разработки (но без гарантий) и в виде более «простого» рекрутинга.
Мне кажется, что ET все-таки скорее средство «быстрой разработки» численных расчетов, дающий вполне достойную, но не пиковую производительность. Может быть, требования к срокам и стоимости разработки стали жестче и теперь нельзя шлифовать код до идеала?
Я не зря написал «удобный и быстрый». Expression templates в C++ это просто кошмар какой то. Чтобы их использовать в реальных задачах нужен настоящий эксперт в С++, который потратил годы на обучение и изучение всех тонкостей языка. Это реально эзотерическое программирование. А отладка? Сообщения об ошибках в шаблонах способны заставить рыдать даже закалённого бородатого кодера. Нет, это не подходит для программирования научного кода, который обычно пишется учёными, а не профессиональными программистами. Конечно, можно нанять и их. Например у нас в организации на каждый десяток physical scientists есть один или пара computer scientists. Но оказалось, что их усилия гораздо эффективнее направить на другие методы оптимизации, например переписать под многопоточность или векторные операции, ручную оптимизацию кода наконец.
Expression templates в C++ это просто кошмар
А это вообще в реальности кто-то использует? В чем проблема использовать внешний кодогенератор?
И, спасибо clang, сообщения об ошибках уже давно весьма хороши.Они, кстати, вполне неплохи и в последних версиях gcc… но это потому что их clang заставил…
в 16 реакте мы наблюдаем феерический разворот от классов к функциональному стилю )Вы хотели сказать «к процедурному»? Тот феерический ужас, который они реализовали с useState не имеет ничего общего с фп, а просто какая-то хрень от современных ооп-хейтеров, чтобы не писать гадкое слово class
Вы хотели сказать «к процедурному»? Тот феерический ужас, который они реализовали с useState не имеет ничего общего с фп, а просто какая-то хрень от современных ооп-хейтеров, чтобы не писать гадкое слово class
Самое смешно в данной ситуации то, что useState — это, по факту, бедная реализация методов классов на замыканиях из SICP :)
То есть, вместо того, чтобы использовать нативные классы, ребята просто сделали свою параллельную костыльную ООП-подсистему.
Люди вечно путают тьюринг-полноту с возможностями языка. Так-то можно сказать что любой язык с
eval поддерживает любую, мыслимую и немыслимую, парадигму — просто потому, что он полон по Тьюрингу.В энтерпрайзе одни подходы, в академии — другие. А ещё вспоминается поговорка про плохого танцора.
Как уже написали, аргумент «раз на нем пишут, значит он хорош» очень спорный. Дейкстра может быть прав или нет по поводу COBOL, ваше право с ним не соглашаться, но для критики языка программирования не обязательно иметь какой-то особый «опыт в энтерпрайзе».Для критики вообще — да. Для критики языка применительно к энтерпрайзу, то есть критики того, насколько он этому энтерпрайзу может быть полезен — такой опыт все же необходим. Неважно насколько язык хорош или плох в его фундаментальных решениях, в бизнесе важно насколько хорошо он позволяет решать поставленные задачи и описывать бизнес процессы. И это включает в себя стоимость специалистов необходимого уровня.
На коболе просто написанно много плохого кода, который переписывать очень страшно и чревато большими простоями и рисками. Одновременно с этим на этом не лучшем языке люди не хотят писать, поэтому их заманивают большими деньгами. Ну примерно как кроссовер платит 50 баксов в час за проекты в стиле Delphi + .Net 1.1. Знаю из первых рук.
Вот так и складывается "стоимость специалистов необходимого уровня".
Много занимался корпоративным ПО на Java и все никак не могу понять о каком таком особом энтерпрайзе идет речь. Зато видел тонны плохо кода, подходов и инструментов, которые можно смело критиковать после одного взгляда ни них.Суть в том, что бизнес не очень волнует качество кода само по себе. Его волнует стоимость получения результата и, иногда, стоимость последующей поддержки и развития. И если нужен сайт визитка, который будет таким и оставаться, а при необходимости чего-то более крутого просто перепишется, то совершенно неважно какой там отстойный код напишет нанятый джун. И нанятый джун на «плохом» JS, например, будет гораздо дешевле чем нанятый джун с плюсами. Хотя бы потому что первый получит результат куда быстрее. При этом его код может быть максимально отвратителен — но кого это волнует? То есть приоритеты другие, академичность и правильность by the book могут легко быть неприменимы в бизнесе. Это не значит что обязательно будут, просто нужно понимать когда и почему они все-таки применимы. А это очень сложно сделать без опыта работы на собственно бизнес.
Сроки бизнес часто волнуют куда сильнее стоимости (в разумных пределах). Откладывание реальной эксплуатации продукта, фичи, визитки, любого ПО, разрабатываемого с коммерческими целями обычно означает откладывание увеличения доходов и(или) уменьшения расходов. С джуном же очень велики неопределенности по срокам готовности к эксплуатации, они могут стремиться к бесконечности, если джун взялся решать теоретически неразрешимую задачу :)
бизнес не очень волнует качество кода само по себе. Его волнует стоимость получения результата и, иногда, стоимость последующей поддержки и развития.Согласен.
То есть приоритеты другие, академичность и правильность by the book могут легко быть неприменимы в бизнесе.В некотором смысле да, но в то же время, в бизнесе используются инструменты и подходы рожденные в академической среде. То есть, если кто-то для простой разовой задачи начнет использовать некий академический подход требующий избыточного количества времени, то это конечно ошибка. Но вроде бы подобной массовой проблемы и нет, когда академики ломают бизнес. Зато, например, тот же джун может с пользой для себя и своей продуктивности потратить время на изучение какой-то «академической» литературы.
В некотором смысле да, но в то же время, в бизнесе используются инструменты и подходы рожденные в академической среде. То есть, если кто-то для простой разовой задачи начнет использовать некий академический подход требующий избыточного количества времени, то это конечно ошибка.Вот мой комментарий именно о том, что вот этот вот подход, на мой взгляд, и подразумевается когда говорится про отличие энтерпрайза от академических рассуждений и решений. При этом задача необязательно разовая или простая (хотя вероятнее всего именно так, но бывают разные ситуации все же). Просто иногда могут случаться всякие обстоятельства когда академический подход не сработает из-за недостатка ресурсов — времени и всего из него вытекающего (наывыка, количества рук) или денег. Например если в компании кризис и нужно срочно что-то выкатывать максимально быстро или закрываться. В таком случае выкатить что-то что внутри будет выглядеть отвратительно и будет очень тяжело поддерживать и расширять, но вот прямо сегодня, а не через месяц — вполне может оказаться лучше.
А с учётом того, что он внёс значительный вклад в разработку Алгола, который является предком подавляющего большинства современных ЯП…
Самое смешное, что goto так никуда и не делся, поскольку выходить из вложенного цикла без него ещё не научились.
Для этого перед break нужно присвоить переменную указывающую куда нужно выйти, а во внешних циклах ловить значение этой переменной, и делать break в зависимости от её значения.
А потом посчитать, насколько уродливее и тяжелее та кажущаяся «красота» на уровне human-readable абстракций…
)))
А еще можно сравнить итоговый код в машинных командах и офигеть, насколько короче и быстрее тот некошерный goto, чем Ъ и обобренный брейк… )))
Борьба с goto велась всегда с оговоркой «не используйте его без надобности». Выход из вложенных циклов — это один из немногих осмысленных кейсов goto.
Не всегда. Видел я кандидата наук, которая считала break разновидностью goto и снижала за него баллы на ЕГЭ...
Да и тут на Хабре похожие кадры попадаются.
Видел я кандидата наук, которая считала break разновидностью goto и снижала за него баллы на ЕГЭ...
Это — клиника и не лечится. Я тоже таких к.т.н. видел.
Препод зачем-то вела уравнения мат. физики. При этом ни хрена в этом не соображала. Было забавно, когда студенты исправляли косяки в ее лекциях, потому что она не втыкала где у нее ошибка.
Это — клиника и не лечится.
Может, какие светила медицины попробуют? Готов стать подопытным.
Чем break не разновидность goto?
Чем break не разновидность goto?
Тем, что бездумное использование goto — резко снижает читаемость кода. Использование break — зачастую необходимость.
Но исходно речь шла про то, что занижать оценки за использование break — глупость. Хотя остается вариант, что это интерпретация студента, и оценка была занижена за что-то осмысленное, а не за break.
Оценка была занижена потому что использование break нарушает теорему Дейкстры. Это не интерпретация, это точная цитата с апелляции.
Оценка была занижена потому что использование break нарушает теорему Дейкстры. Это не интерпретация, это точная цитата с апелляции.
Ну так вы текст программы приведите — посмотрим. Судя по всему, break как таковой ни при чем.
Там был обычный цикл с выходом по-середине:
repeat
{foo}
if {some_condition} then break;
{bar}
until false; Написать его по-другому без дублирования кода невозможно (а за дублирование кода тоже штрафуют).
Чтобы не быть голословным пример из моего солидити кода
for (uint64 i = uint64(dates.length - 1); ; i--) {
if ((!latestStatusIndex.hasValue || dates[i] > dates[latestStatusIndex.value]) && isDistributionStatus(statusCodes[i])) {
latestStatusIndex = Types.OptionU64(true, i);
}
if (i == 0) {
break;
}
}переменная i — unsigned, поэтому проверять на i < 0 в условии цикла нельзя.
uint64 i = uint64(dates.length);
do
{
--i;
if ((!latestStatusIndex.hasValue || dates[i] > dates[latestStatusIndex.value]) && isDistributionStatus(statusCodes[i])) {
latestStatusIndex = Types.OptionU64(true, i);
}
}
while (i > 0);
Если что, я не против break (и не против goto, честно говоря).
Во-первых в солидити (как и многих других языках) нет do циклов.
Во-вторых этот код сломается если dates пустой массив.
until — это противоположность while. Так что until false — это while(1).
Заданием на ЕГЭ в части С всегда является написание работающего кода, без перерасхода памяти, времени и строчек программы.
По задумке, в основном задания должны либо содержать очевидные оптимальные решения, либо возможные решения должны быть явно перечислены как правильные.
Условно, всем должно быть очевидно, что лучше добавить три строчки в программу, но выиграть в 100 раз по памяти. А если есть какая-то неоднозначность — существует апелляция.
А на самом деле на апелляции сидит "кандидат наук", сравнивающая текст программы посимвольно.
Вот это:
использование break нарушает теорему Дейкстры.
я могу трактовать как «преждевременный выход из цикла нарушает теорему Дейкстры». Т.е. претензия не к break'у, а к алгоритму. Чтобы это проверить — нужен текст программы, а вы его не привели.
Вы издеваетесь или как? Как я вам вспомню какую задачу я решал на экзамене 12 лет назад и какой код при этом написал?
И ладно бы это был самый сложный экзамен всей моей жизни, так ведь нет, это был очередной экзамен на внимательность при заполнении бланка...
я могу трактовать как «преждевременный выход из цикла нарушает теорему Дейкстры». Т.е. претензия не к break'у, а к алгоритму.
Во-первых, теорема Дейкстры на самом деле называется теоремой Бёма — Якопини.
Во-вторых, эта теорема говорит лишь о возможности приведения программы к некоторому виду, но никак не запрещает иной вид программы. Теорему невозможно "нарушить".
В-третьих, в соответствии с теоремой, любой алгоритм можно выразить в указанной форме. В том числе мой. Поэтому в этой фразе не может быть никакой претензии к алгоритму, есть лишь претензия к оператору break.
Вы издеваетесь или как? Как я вам вспомню какую задачу я решал на экзамене 12 лет назад и какой код при этом написал?
Почему издеваюсь?
1) Да, тупые преподы бывают.
2) Да, бывают студенты, которые считают, что их незаслуженно обидели.
3) При этом бывает, что обидели студента заслуженно.
4) Как я могу определить, что имело место быть на самом деле без текста программы?
5) Поскольку название алгоритма непонятное, непонятно и к чему придрался препод.
6) break используется повсеместно.
7) Наезда на языковую конструкцию в вашей цитате я не увидел.
8) Иногда преждевременный выход из цикла покрывает не все кейсы алгоритма и поэтому некорректен.
Как я могу определить, что имело место быть на самом деле без текста программы?
А слов разработчика с 8-летним стажем олимпиад и 10-летним стажем разработки вам недостаточно? Почему вы вообще взялись проводить какое-то расследование в комментариях на Хабре?
Поскольку название алгоритма непонятное, непонятно и к чему придрался препод.
А где вы вообще увидели название алгоритма?
Наезда на языковую конструкцию в вашей цитате я не увидел.
Для кого я писал комментарий выше? Эта фраза не может быть ничем кроме как наездом на языковую конструкцию.
Иногда преждевременный выход из цикла покрывает не все кейсы алгоритма и поэтому некорректен.
В таком случае мне бы сказали "алгоритм некорректно работает в таком-то случае", а не то что я цитировал выше.
А слов разработчика с 8-летним стажем олимпиад и 10-летним стажем разработки вам недостаточно?
Конечно, нет. Во первых, ошибаться / преднамеренно вводить в заблуждение может кто угодно. Во вторых, у вас на лице ваш стаж / квалификация не написаны. В третьих, на просьбу показать код последовало гениальное «begin… end», что в середине — не помню.
В четвертых, мне непонятно, чего вас колбасить начинает. Я высказал свое мнение. Не устраивает — пройдите дальше. Чего кипятиться-то?
Почему вы вообще взялись проводить какое-то расследование в комментариях на Хабре?
С того, что после моей фразы (безобидной вполне):
Хотя остается вариант, что это интерпретация студента, и оценка была занижена за что-то осмысленное, а не за break.
последовала какая-то бурная деятельность с вашей стороны.
А где вы вообще увидели название алгоритма?
«теорема Дейкстры». До букв докапываться не будем, ок? :)
Для кого я писал комментарий выше? Эта фраза не может быть ничем кроме как наездом на языковую конструкцию.
Позвольте на слово вам не поверить. Как хотите. Бодаться я не хочу, а что-то содержательное без текста программы выдать не получится.
В таком случае мне бы сказали «алгоритм некорректно работает в таком-то случае», а не то что я цитировал выше.
Ну это ВАШЕ понимание, что нужно говорить. У других людей оно может несколько отличаться. И еще раз повторю: да, я видел тупых преподов. Море. Равно как видел нормальных преподов и тупых студентов, которые считают препода тупым.
Типичный пример полезного брейка:
let user_input: u32 = loop {
if let Ok(user_input) = read_line().parse() {
break user_input;
}
println!("Неверный ввод: ожидалось беззнаковое число");
}Эксепшены забыли. :) Ну и всякие штуки вроде setjmp, отправка сигнала самому себе, прерывания и т.д.
Ну, чтобы следовать евангеле Дейкстры достатоно скопипастить весь код до брейка, а после этого запустить обычный while. Но как мне кажется, когнитивная нагрузка от такого решения вряд ли снизится. Особенно если брейков может быть больше одного. Например на каждой строчке цикла мы проверяем, что результат корректный, и если нет, то прерываем.
Вечный цикл покинуть нельзя. Если используется break это значит цикл не вечный, но условие выхода находится где-то унутре
Goto — безусловный переход.
Break — безусловный переход к любому оператору после определённого цикла.
Бездумное использование break снижает читаемость
Бездумное программирование снижает читаемость.
goto (jmp) — зачастую необходимость.
Примеры, конечно можно привести. Но, «зачастую»… В своей практике, вообще ни разу не применял goto. Кейсов таких не возникало. А вот break — постоянно.
Break — безусловный переход к любому оператору после определённого цикла.
Что значит к любому? К следующему оператору за циклом. Что обычно и требуется.
1) Как областной эксперт по проверке ЕГЭ по Информатике и ИКТ могу утверждать, что нет такой позиции в «Критериях оценивания заданий с развёрнутым ответом» (не верите — зайдите на сайт ФИПИ или загуглите демонстрационный вариант ЕГЭ, там будут критерии для экспертов).
2) Баллы — это для ЕГЭ очень много… снижение даже на 1 (один) балл требует очень веских обоснований, например, «неверная инициализация или её отсутствие там, где она необходима» или «используется неверный тип данных»
goto переключает управление в любую точку, а все эти break — только в одну конкретную точку. Другое дело, что нельзя снижать баллы за это, если только смыслом учебного курса не является достижение цели «как угодно, но только без goto».
А еще можно сравнить итоговый код в машинных командах и офигеть, насколько короче и быстрее тот некошерный goto, чем Ъ и обобренный брейк… )))Даже более. В машинных командах в любом случае будет аналог JMP операнда, который тот же Goto.
По сути, дело в абстракциях и удобстве.
Break — он не просто вызывает выход из цикла, попутно под капотом он может ещё и переменную/коллекцию освобождать.
А так-то вещь весьма удобная — вжик и вышел. А тут оказывается что надо не просто выйти а ещё и ресурсы освободить, файлы закрыть и т.д.
RAII?
Break — он не просто вызывает выход из цикла, попутно под капотом он может ещё и переменную/коллекцию освобождать.
Как он это сделает и почему в той же ситуации goto этого сделать не сможет?
Да и эксепшены по-сути эмулируют goto.
Да запросто:
for(...) {
for(...) {
if (condition) return;
}
}Да-да, цикломатическая сложность >= 2 — повод выделить этот код в отдельную функцию
Во-первых воротить отдельную функцию чисто для подцикла не делает код чище и понятнее, чем с одним goto, во-вторых — может потребоваться перейти на 2 цикла вверх или что-то подобное. А если это какая-то операция с тензорами, то отдельные функции просто для прохода каждого измерения не выглядят сильно оправданными.
Просто есть люди, которые пишут большие и некрасивые, но полезные программы, а есть люди, которые пишут маленькие и красивые, но бесполезные программы. То, что выглядит красиво и хорошо работает в последних, не работает в первых.
Методики и подходы написания надёжных программ были выработаны ещё в 80х при создании софта для SpaceShuttle и к данному моменту стандартизованы. И ключ совсем не в выборе самого лучшего языка программирования, а в организации процесса.
Основная идея в том, что если Дейкстра или кто-либо другой профессионально не писал программы для энтерпрайза и сложных систем, то не ему критиковать подходы, практикуемые там. Вроде бы очевидно, нет? Дальновидность его в области промышленного ПО можно оценить по тому, что он критиковал как раз те подходы, которые до сих пор является широко используемыми (хоть и критикуемыми), и, думаю, здесь дело не в повальной умственной отсталости тех, кто их использует. Проблема же написания качественного софта, которую Дейкстра пытался решать критикой (уровня обычного обсирания) отдельных технических подходов и языков, лежит не в плоскости языка, а в плоскости организационных подходов и методик — например таких, какие были выработаны при разработке ПО для Space Shuttle, а надёжное ПО, используемое десятки лет, можно писать хоть на ассемблере — например тот же MVS.
В 2002 году получил ежегодную премию, вручаемую Симпозиумом по принципам распределённых вычислений (англ. Symposium on Principles of Distributed Computing) Ассоциации вычислительной техники «за публикацию, оказавшую наибольшее влияние на область распределённых вычислений»; в знак признания заслуг учёного с 2003 года эта премия носит название премии Дейкстры.
Действительно, откуда ему что-то знать?)))
Какую, говорите, премию он там получил?:)
Не сказал бы, что COBOL кто-то сильно рекламировал. Скорее наоборот: такие, как Дейкстра, вели против него собственную кампанию-холивар.
Лично для меня критерий прост: чем меньше я трачу времени и усилий на создание решения, и чем больше зарабатываю на нём, тем лучше у меня подход и инструментарий. По этой причине в моей конторе ООП давно списан в утиль.
Можно не рекламировать плохую технологию, и она всё равно захватит мир, как какой-нибудь jQueryА чем jQuery — плохая технология? Для своего времени он был крайне актуальным и ушел, когда стал не нужным.
На самом деле чистый JS весьма неплохо спроектирован — атомарно и консистентно, на нём можно быстро писать эффектные прототипы. А продакшн-разработку можно вести на TypeScript.
Я перешёл на web в 2013-м. Я не никогда не занимался фронтендами для масс маркета. Мне достаточно, чтобы веб-приложение работало на одном браузере.
Но даже если думать о реализации кроссбраузерности через jQuery. Да, он даёт полезный функционал, но при этом также подсовывает очень опасную архитектуру, от которой проект сильно деградирует. Для примитивного лендинга-однодневки это нестрашно. Для сложного web-приложения это большая проблема.
но при этом также подсовывает очень опасную архитектуруНе подсовывает он никакую архитектуру. Это библиотека, а не фреймворк. Он:
1. Делает прозрачную кроссбраузерность
2. Дает более короткий, чем в браузере API
Всё. Эти вещи никак не влияют на архитектуру. На архитектуру могли влиять некоторые плагины. Но всё зависит от программиста
А что не так с отладкой кода на jQuery?
Если я буду выбирать инструмент для получения премии — я поучусь у Дейкстры, если мне понадобиться инструмент для реализации обработки транзакций — я поучусь у тех, кто её реализует.
Боюсь спросить, а какие-нибудь Дядя Боб да Фаулер для вас тоже так, академики, далекие от кода?)
Не правда ли забавно, что разработка ПО воспринимается некоторыми не как инженерная дисциплина, а как некий культ со своими еретиками и гуру? :) При этом софт всё равно часто приходится писать с использованием «плохих» (но эффективных) подходов, но открыто в этом сознаваться не принято. В тоже время никто не хочет читать давно придуманные стандарты по организации процесса разработки и методике написания качественного кода, которые существуют ещё со времён первых Шаттлов, вместо это все бросаются резкими цитатами своих любимых гуру.
Не правда ли забавно, что разработка ПО воспринимается некоторыми не как инженерная дисциплина, а как некий культ со своими еретиками и гуру?
Большинством программистов что я встречаю разработка ПО является сферой где можно работать по 4 часа в день и кучу денег получать. Благо если знают кто такие эти «гуру», и хоть краем уха слышали о чем они вещают.
А еретики это все кто вещают не про те подходы, о которых преподы в институте/на курсах, или не дай-бог какой-нибудь парень с хабра вещал, не признавать же что они чего-то не знают.
часто приходится писать с использованием «плохих» (но эффективных) подходов, но открыто в этом сознаваться не принято
В чем вы меряете эффективность боюсь спросить, и какие такие подходы считаются хорошими но неэффективными?
Не говоря уже о том, что разные подходы используются в разных ситуациях, и «гуру» которых я упоминал вполне себе вещают и про скорость, и про приоритеты.
И раз уже вы решили продолжить диалог, мне было бы интересно услышать ваш ответ на мой вопрос из предыдущего комментария.
Я прошу прощения, но дочитал до этого места становится сложно не видеть обилия Шаталов а комментариях. Шатлы изначально потрясный продукт, но шатлы это же шатлы, а шатлы шатлы шатл шатлы? Шатлы! Шатлы шатл. Шатл!
Скажите, какие походы в используете, и я объясню вам, почему они плохи.
TDD предполагает написание красного теста до изменений в коде. Что приводит либо к недопокрытию, из-за невозможности написать красный тест. Либо к нарушению TDD с написанием изначально зелёного теста, что говорит о том, что он пишется после имплементации тестируемой им функциональности.
TDD замедляет и усложняет RnD, требуя фиксации интерфейса до полного понимания какой он должен быть и реализуем ли вообще.
SRP приводит ко кратному увеличению числа объектов, что даёт излишнюю нагрузку на GC. А это критично, когда число объектов исчисляется сотнями тысяч.
OCP приводит к протуханию кодовой базы, переполнению её устаревшими реализациями, устаревших интерфейсов.
LSP говорит лишь про ковариантность типов, однако в ряде случаев типы должны быть контравариантны, а в ряде инвариантны.
ISP приводит к интерфейсам состоящим из одного метода, что нивелирует смысл интерфейсов и приводит к огромным объёмам бойлерплейта и необходимости дополнительно декларировать каждый используемый метод стороннего объекта.
DIP затрудняет навигацию по коду, усложняет API объекта, приводит к излишнему бойлерплейту.
SRP. Проблема в понимании SRP как «дроби пока дробится». Но это не так. SRP — он же принцип единой изменчивости, единой ответственности и локализации фичей — говорит про границы декомпозиции, а не про ее размер. Нарушение Srp — это не только God-object, но и размазывание и дублирование по коду какой-то конкретной фичи. Дублирование кода, как вы понимаете отнють не ускоряет даже MVP. Ежели мы касаемся вопросов оптимизации — то «преждевременная оптимизация — зло (с)». Кстати неверная декомпозиция, приводит к костылям в коде и кровавому легаси.
OCP, при нормальном проектировании необходим для выполнения SRP и тестирования. А устаревшие интерфейсы можно просто удалить. Другое дело что вы не сможете их удалить если у вас нарушен OCP, что приведет вас к кровавому легаси.
LSP говорит что наследование и полиморфизм должны быть сделаны с умом, в том числе. Везде где есть нарушение LSP — начинается задница и борьба с иерархиями. Как правило тут начинают говорить про кровавое легаси.
ISP не приводит к интерфейсам из одного метода. Аналогично SRP, ISP говорит о том как нужно делать интерфейсы в спорной ситуации, и позволяет развязать жуткие клубки зависимостей. Это крайне необходимо для больших команд, сложной бизнесс логики и ограниченных контекстов. В противном случае — ну вы поняли ;)
DIP — соглашусь. Есть доказательства того, что слепое следование DIP приводит к рекурсивному генерированию кода. Таким образом DIP это не принцип, а ползунок, пренебрегать которым не стоит ни в одну, ни в другую сторону.
Мне кажется, смысл поста вашего оппонента был в том, что любой подход может быть плохим, если его плохо готовить (бездумно следовать, как вариант) в рамках конкретного контекста.
Потому я и указал TDrivenD/TLastD что бы не нарваться на формализм.
Я ж не знал, как вы TLD расшифровываете. Я подумал, что это TLeadD.
Кстати отсутствие атомарных тестов зачастую приводит к кровавому легаси.
Не знаю, что такое "атомарные" тесты, но написать код так, чтобы он проходил один тест, но не проходил остальные, обычно сложно и бессмысленно.
Ежели мы касаемся вопросов оптимизации — то «преждевременная оптимизация — зло (с)».
Дьявол в слове "преждевременная". Архитектурная оптимизация должна выполняется как можно раньше, так как потом менять её будет сложно или даже невозможно. Это, кстати, большое заблуждение, что можно не думать о скорости, пока петух не клюнет.
Другое дело что вы не сможете их удалить если у вас нарушен OCP, что приведет вас к кровавому легаси.
Ко кровавому легаси приводит отсутствие регулярного рефакторинга. А OCP явно запрещает рефакторинг. OCP полезен лишь при взаимодействии со внешними клиентами, когда нужно сохранять обратную совместимость.
Везде где есть нарушение LSP — начинается задница и борьба с иерархиями.
Не, вы не поняли суть проблемы. Смотрите, Cat является подтипом Animal, Cat[] является подтипом Animal[]. И если мы только читаем, то мы можем где угодно вместо Animal[] передать Cat[]. Но если мы где-то помещаем в массив, например, Dog, то, внезапно, мы уже не можем передавать Cat[] вместо Animal[]. Во времена Барбары об этой проблеме ещё не думали.
Мне понравилось определение "легаси" как кода, над которым невозможно провести полноценный рефакторинг, по факту — код, который не покрыт тестами, покрывающими требования. Даже с полным покрытием кода тестами, нельзя быть уверенным, что кто-то где-то не завязался на undefined behavior пускай и зафиксированное тестами.
undefined behavior пускай и зафиксированное тестами
Это как вообще возможно?
В требованиях нет, например, какую сумму выводить в отчёте по заказам, если ни одного пункта в заказе нет. Программист использовал какой-нибудь reduce со стартовым значением 0 и зафиксировал 0 как ожидаемое значение в тестах, хотя в требованиях этого нет, вообще ничего нет как должна вести себя системах в таких случаях, он сам принял решение, ну или с QA обсудили и решили, что это ожидаемое поведение. Но в требования оно не попало.
Не знаю, что такое «атомарные» тесты, но написать код так, чтобы он проходил один тест, но не проходил остальные, обычно сложно и бессмысленно.
«атомарные» — тестирующие минимальный объект. Я имею ввиду, что использование TDD в интеграционном ключе, тоесть тестирование больших кусков кода за раз, не тестируя маленькие — имеет тенденцию к «спецификации макарон в виде тестов». Кажется человечество еще не придумало как распутывать такие клубки.
Дьявол в слове «преждевременная». Архитектурная оптимизация должна выполняется как можно раньше, так как потом менять её будет сложно или даже невозможно. Это, кстати, большое заблуждение, что можно не думать о скорости, пока петух не клюнет.
Архитектурная «оптимизация» это хорошо, но речь про обычную, вызванную SRP. И это не заблуждение, по крайней мере если в стеке есть нормальные инструменты профайлинга. А вот экономия кол-ва типов — это кажется оскорбление чуств верующих в прекрасное, да и будущих разрабов за компанию.
Ко кровавому легаси приводит отсутствие регулярного рефакторинга. А OCP явно запрещает рефакторинг. OCP полезен лишь при взаимодействии со внешними клиентами, когда нужно сохранять обратную совместимость.
Ocp не запрещает и не поощряет рефакторинг. Он говорит что «изменение поведения кода нужно делать через… поведения-)». Иными словами — не надо хардкодить.
Не, вы не поняли суть проблемы. Смотрите, Cat является подтипом Animal, Cat[] является подтипом Animal[]. И если мы только читаем, то мы можем где угодно вместо Animal[] передать Cat[]. Но если мы где-то помещаем в массив, например, Dog, то, внезапно, мы уже не можем передавать Cat[] вместо Animal[]. Во времена Барбары об этой проблеме ещё не думали.
Либо я вас по прежнему не понял, либо вы путаете LSP и проблемы ковариантных/контравариантных преобразований и структурной типизации.
Кажется человечество еще не придумало как распутывать такие клубки.
Придумало. Компонентное тестирование называется.
SRP. И это не заблуждение, по крайней мере если в стеке есть нормальные инструменты профайлинга.
Ну вот профайлер вам показывает, что создание 100к объектов вместо 10к — это как-то сильно долго. Что вы там соптимизируете, не выпиливая SRP?
Он говорит что «изменение поведения кода нужно делать через… поведения-)». Иными словами — не надо хардкодить.
Он говорит "интерфейс закрыт для изменения, но открыт для расширения", что прямо противоречит рефакторингу.
вы путаете LSP и проблемы ковариантных/контравариантных преобразований
LSP фактически утверждает, что все типы должны быть ковариантны. Что во первых не так. А во вторых даже не является свойством типа.
Он говорит «интерфейс закрыт для изменения, но открыт для расширения», что прямо противоречит рефакторингу.Нет, не противоречит. Он говорит о том, как код должен быть написан, а не о том, как код должен писаться.
То есть он говорит о конечном результате, а не способе достижения.
Он говорит о двух глаголах в несовершенной форме, которые по семантике не могут говорить о результате. Думаю вам стоит освежить в памяти о чём этот принцип и какова его мотивация.
Принципы SOLID вообще довольно спорные, а понимают их как имели ввиду авторы вообще единицы. Интересное чтиво на тему.
Про LSP тоже интересный вопрос: должен ли список который каждый Add дублирует элемент наследоваться от обычного списка (или даже IList) или нет?
Цитата по вашей ссылке: "в результате расширения поведения сущности, не должны вноситься изменения в код, который эти сущности использует".
Код самой сущности править можно, главное — сохранять все инварианты.
Вот назвали вы метод неудачно. Что теперь, создавать новый класс с новым названием этого метода?
А кто определяет инварианты? В ФП допустим у вас все в типе возвращаемого значения зашито, а в ООП? Какие инварианты у метода ICollection.Add? Логично ли предположить, что если мы вызввали Add, то Count должен увеличиться ровно на единицу?
Вот программист и определяет. Кстати, какие инварианты определяет тип возвращаемого значения IO ()? :-)
Вот программист и определяет.
А что если один программист одно подумал, а другой-другое?
Кстати, какие инварианты определяет тип возвращаемого значения IO ()? :-)
Плохие, поэтому файнал таглес и MTL в помощь :)
А что если один программист одно подумал, а другой-другое?
Плохо будет, но это общая проблема программирования, а вовсе не проблема OCP.
Хорошо, тогда давайте по-другому: какие у нас формальные критерии соблюдения LSP? Ну вот чтобы мы могли бота написать, который на хук гитхаба срабатывает и говорит, что вот тут нарушили. Для каого-нибудь SRP можно считать количество пересечений графа ответственности и зависимостей, для open-closed насколько часто модифицируется исходный код каких-то классов. Короче, сложно, но можно.
А для LSP кроме как "я так вижу" не могу ничего придумать.
В гипотетическом формально верифицируемом ОО-языке достаточно проверить результат этой самой верификации.
В тоже гипотетической, но более приближенной к реальности ситуации, можно потребовать у использующих класс программистов оформлять свое видение инвариантов к нему в форме тестов.
А вот как вы будете формально описывать граф ответственностей — ума не приложу...
Что вы вкладываете в утверждение "все типы должны быть ковариантны"?
Не совсем по теме, но бездумное применение LSP может привести к забавным вещам. Например Java с её ковариантным array.
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.
Для производных типов это означает безусловную ковариантность.
Ковариантность — свойство, которым может обладать лишь конструктор типов (дженерик), но никак не одиночный тип.
А то, что назвали вы, называется "полиморфизм".
Да нет, вас обманули. Вот смотрите, у вас есть 2 функции:
printFirstAnimal( animals : Animal[] ) — сюда можно передать Cat[], но нельзя Object[].
addAnimal( animals : Animal[] ) — сюда нельзя передать Cat[], но можно Object[].
В зависимости от того как вы работаете с типом — у него разная вариантность.
Да нет, нельзя
Несовершенство конкретного компилятора — такой себе аргумент.
По правилам языка — нельзя, а по семантике функций должно быть можно, в этом и проблема.
Собственно, поэтому в C# и появились ключевые слова in и out, чтобы объяснять компилятору где какая нужна вариантность.
Собственно, поэтому в C# и появились ключевые слова in и out, чтобы объяснять компилятору где какая нужна вариантность.
Осталось понять, при чём тут LSP...
Не везде тип может быть заменён своим подтипом. Более того, в ряде случаев он может быть заменён надтипом. Даже не знаю как ещё вам это объяснить.
Вы путаете тип и объект этого типа. LSP говорит о замене объекта, а не о замене типа.
Не заставляйте меня повторять вам определение LSP…
Давайте завязывать с этим словоблудием. Ваше уточнение ничего не меняет.
Давайте вы сами его перечитаете? И увидите, что там ничего не говорилось про дженерики, только про функции.
Можно подумать дженерики — не типы.
Дженерик — конечно же тип. А не функция.
Вот только LSP ничего не говорит про функции из типа в тип...
Именно так: LSP говорит про объекты x типа T, а вовсе не про обобщенные типы, принимающие сам тип Т как аргумент.
Рассуждения в терминах LSP для дженериков возможны, но только если мы пытаемся установить отношения подтипа для дженериков (в таком случае мы применяем LSP к самому дженерику, а не к его аргументу). Если мы не пытаемся так сделать — то и LSP тут неприменим.
Иными словами, существование инвариантного дженерика не нарушает LSP.
а вовсе не про обобщенные типы, принимающие сам тип Т как аргумент.
Когда обобщенный тип применяется к аргументу, он становится конкретным типом. И LSP тут становится напрямую применим.
Так я именно про это и написал же...
А кто из этих конкретных типов относится друг к другу как подтип?
(эта может быть та же самая ситуация, как с мутабельными кваратом и прямоугольником)
А кто из этих конкретных типов относится друг к другу как подтип?
Ну если у вас А подтип В, то List[A] подтип List[B]. примерно так.
Это применимо только для некоторых дженериков. Хотя вы и сами это знаете. Фактически по самому факту, что T подтип T1 нельзя сказать что X является подтипом для X и конкретно для List это не так.
Some kids go trick-or-treating for Halloween. They all have Bags of Candy. It's safe for them to eat anything that gets put in their Bag of Candy, because the only thing inside, by definition, is Candy.
But when they get to the end of the block, a grumpy old man who hates children begrudgingly opens the door. He looks down and sees the children all have Bags of Candy. But a Bag of Candy, he reasons, is also a Bag of Things. And the evil old man grabs a handful of RazorBlades — which are also Things — and puts them in the Bag of Things the children are holding.
Это применимо только для некоторых дженериков.
Для ковариантных. Для контравариантных — применимо наоборот. Для инвариантных неприменимо. И что, с-но?
конкретно для List это не так.
Для стандартного мутабельного списка это конечно так быть не должно, мутабельные списки должны быть инвариантными. А для иммутабельных — все окей.
Не везде тип может быть заменён своим подтипом. Более того, в ряде случаев он может быть заменён надтипом. Даже не знаю как ещё вам это объяснить.
Очень легко объяснить. В ковариантных позициях (тех, по которым генерик ковариантен) тип может быть заменен подтипом, в контравариантных позициях (тех, по который генерик контравариантен) тип может быть заменен надтипом, а в инвариантных — ничем не может быть заменен. Но вы сами это плохо понимаете.
Обе функции имеют одинаковые сигнатуры, но разную вариантность
У функций вариантности нет, вариантность есть у функционального типа (генерик Func<A, B>), и этот генерик ковариантен по первого аругменту и контравариантен по второму — всегда.
И не зацикливайтесь на генериках. Это проблема любых составных типов.
Нет, это проблема именно генериков и без генериков ее вообще не существует. Тип F: -> (генерик) называется ковариантным, если A <: B => F(A) <: F(B) и контравариантен, если A <: B => F(B) <: F(A)
Поэтому в наиболее продвинутых языках есть ключевые слова для указания вариантности аргументов.
И эти ключевые слова указывают именно вариантность генериков (типов с кондом * -> ...). У функций и аргументов вариантность указывать нельзя нигде и никак. Боле того — ни в каком языке нельзя написать ф-ю принимающую аргумент типа Т но не принимающую подтип Т (офк говорим о type safe случаях).
Компилятор мог бы вывести вариантность сам
Не мог бы, это алгоритмически неразрешимая задача.
// а сюда нельзя
В обе ф-и можно передавать Boy.
Это в каком языке так?
Если взять гипотетический нормальный язык с инвариантными массивами, то в обоих случаях в такие функции можно будет передавать только Animal[], но не Cat[] и не Object[].
А чтобы всё было так как вы расписали, функции должны выглядеть как-то так:
printFirstAnimal( animals : <? extends Animal>[] ) — сюда можно передать Cat[], но нельзя Object[]
addAnimal( animals : <? super Animal>[] ) — сюда можно передать Object[], но нельзя Cat[]
В обоих случаях вариантностью обладает анонимный тип-параметр, но никак не тип Animal.
addAnimal( animals: Animal[] ) — сюда нельзя передать Cat[], но можно Object[].
Почему?
Все ф-и коварианты по типу аргумента, в вашем случае дело в вариантности генерика [].
Обе функции имеют одинаковые сигнатуры, но разную вариантность, которая зависит не от объявленного типа, а от содержимого этих функций. Компилятор мог бы вывести вариантность сам, но мне такие не известны. Поэтому в наиболее продвинутых языках есть ключевые слова для указания вариантности аргументов.
И не зацикливайтесь на генериках. Это проблема любых составных типов.
class Man { pet : Animal }
class Boy extends Man { pet : Cat }
// сюда можно передавать Boy
declare function feedPet( man : Man ) : void
// а сюда нельзя
declare function giveDog( man : Man ) : voidВаш пример всего лишь означает, что наследование некорректное. Не вижу тут никакой контравариантности.
Ну вот профайлер вам показывает, что создание 100к объектов вместо 10к — это как-то сильно долго. Что вы там соптимизируете, не выпиливая SRP?
Прежде чем «грязнить» код — есть много других возможностей:
1) Большинство проблем происходят из O-сложности. Если O — побеждена — переходим на уровень малой крови.
2) Делаем синглтоны или кэши для часто используемых объектов, меняем ref на value типы (если позволяет инфраструктура) — итд.
3) Если и это не помогло — то часто можно упростить или реорганизовать архитектуру во благо скорости и без ущерба смыслу (на этом этапе уже понятно как).
4) Для высоконагруженных — не забываем про горизонтальное масштабирование.
И только потом, когда все вышеперечисленное не помогло — начинаем крошить код во благо скорости. Но необходимость этого встречается редко. Как правило на мобилках и ARM. И, безусловно — тут все средства хороши.
Что самое главное — предыдущие 4 пункта сложно выполнить, если у вас там все SOLID-ы порушены вкривь и вкось.
Он говорит «интерфейс закрыт для изменения, но открыт для расширения», что прямо противоречит рефакторингу.
Он говорит про изменение поведения, а не про то, что код нельзя трогать. Например — смена конекшн стринги из конфиг файла.
Или более сложный случай — вы хотите сменить одну SQL базу на другую — значит подготовьте бек-код так, что бы можно было менять провайдера DB, а не удалять старого и вместо него писать нового. Так же это говорит о том, что предпочитайте if-чикам — стратегии и композицию
LSP фактически утверждает, что все типы должны быть ковариантны. Что во первых не так. А во вторых даже не является свойством типа.
Lsp утверждает, что наследование и интерфейсы должно быть обоснованно по смыслу, а не для экономии кода. Иными словами оно против структурной типизации в языках — где структурной типизации нет, так как это лютый самострел.
Есть ощущение, что вы принципиально пытаетесь переспорить изначальный тезис, что спортивно и прикольно.
Большинство проблем происходят из O-сложности.
Это ваша личная статистика. У меня другая.
Делаем синглтоны или кэши для часто используемых объектов
Как кеши помогут вам создать 100к объектов необходимых для старта приложения?
часто можно упростить или реорганизовать архитектуру во благо скорости и без ущерба смыслу
Ага, например не лепить по 10 объектов на каждую сущность.
не забываем про горизонтальное масштабирование
Это вообще не оптимизация, а брутфорс.
И только потом, когда все вышеперечисленное не помогло — начинаем крошить код во благо скорости.
А можно изначально не создавать себе проблему во благо сомнительных аббревиатур.
Lsp утверждает, что наследование и интерфейсы должно быть обоснованно по смыслу, а не для экономии кода.
Сможете процитировать, где оно что-то такое утверждает?
Есть ощущение, что вы принципиально пытаетесь переспорить изначальный тезис
Ну а у меня ощущение, что вы уперлись рогом в свои представления и не слышите собеседника. Ведь только тролль может быть с вами не согласен, правда?
А откуда у вас возьмется 100к разных ответственностей при старте приложения?
Мы как-то расследование проводили — и обнаружили, что в Java один-единственный вызов
String.format("%0.2g", 0.1); порождает несколько сотен объектов. Добавьте сюда пачку обсуждающихся акронимов — и вы получите 100к объектов вместо нужных вам 10к легко несмотря на все кеши и прочее. Рождённых как раз всеми вот этими ускоряторами.что в Java один-единственный вызов String.format("%0.2g", 0.1); порождает несколько сотен объектов
Это вопрос уже не про SRP. А по поводу кол-ва объектов — повторюсь — SRP не про то что нужно все измельчать, а про то, как делить.
Это-таки именно о нём. Если вы посмотрите на C версию printf (вот тут, например), то вы обнаружите страшное нарушение SRP, которое любой правоверный ООПшник заменит на десятки, а то и (как видим на примере Java) сотни маленьких объектиков. В результате — то, что в C версии аллоцирует пару объектов (связанных с локалью) при первом обращении (и ничего при последующих) теперь создают 200 с лишним объектов при каждом обращении (и хорошо за 1000 при первом).что в Java один-единственный вызов String.format("%0.2g", 0.1); порождает несколько сотен объектовЭто вопрос уже не про SRP.
Вот когда ускорите Java версию так, чтобы она работала со скоростью хоть чуть-чуть приближающуюся к тому, что делает C — можете начинать петь песни о том, что вы можете вначале делать что-то с соблюдением всех этих акронимов и притом — со сравнимой эффективностью.
Но это же scanf по ссылке. Хотя да, от GNU coding style глаза сразу в кучку, различить сложно :-)
Впрочем, это не имеет отношения к SRP. Задача функции printf — сформировать в соответствии с переданным шаблоном и аргументами итоговую строку, она именно это и делает.
Вот если мы в printf засунем возможность читать данные из mysql, — это будет нарушением SRP.
Но это же scanf по ссылке.Не туда ткнул. Printf тут… но не сказал бы, что он сильно проще.
Задача функции printf — сформировать в соответствии с переданным шаблоном и аргументами итоговую строку, она именно это и делает.Ну вот разработчики Java решили что нет… и они, в некотором смысле, правы: там действительно можно выделить много подзадач. Конвертировать аргументы, переставить их по разному (вы ведь в курсе, что «Hello, World!» можно напечатать так:
printf("%3$s%2$*1$s\n", 6, "word!", "Hello"); ), обработать коллбаки (вы же в курсе, что можно дополнительные буквы зарегистрировать и дополнительный обработчик навесить) и так далее.Нельзя сказать, что все эти сотни создаваемых объектов совсем ничего не делают… но даже после долгой обработки JIT'ом там происходит куда больше работы, чем в C printf… а уж пока JIT не прогреется — там вообще караул с производительностью…
И это, ещё раз повторяю — библиотека, которой пользуются миллиарды и, вроде как, неглупыми людьми написанная. Если они не умеют в SOLID, то кто тогда умеет?
С моей точки зрения вы правы, SOLID имеет свою цену. Так же как и любое другое повышение уровня абстракции. Переход на языки высокого уровня, СУБД, библиотеки тоже имеют свою цену.
Если бы вы использовали вместо sprintf на C специально написанный для вашего случая код на ассемблере, вероятно, это заняло бы еще меньше ресурсов.
Кстати, думаю, что если на каких-то задачах sprintf является узким местом, там бы код оптимизировали возможно уйдя от SOLID.
Если бы вы использовали вместо sprintf на C специально написанный для вашего случая код на ассемблере, вероятно, это заняло бы еще меньше ресурсов.Конечно. Но вот вопрос: насколько меньше? Ответ: не так сильно меньше, чем вам кажется. Чтобы вывести 3-4 цифры в десятичной записи «наивно» — вам потребуется поделить число на 10. А это, опаньки, от 10 до 40 тактов (в зависимости от процессора). А вот
printf — этого избегает.В результате простое, наивное, приходящее в голову первым, решение, написанное на ассемблере — работает, на самом деле, медленнее, чем C printf. Что, собстенно, и делает C printf хорошей абстракцией: да, можно сделать быстрее — но это непросто. Это думать надо. И профайлить.
А вот Java printf — с этих позиций, похоже, вообще не оценивали. Даже со всеми кешами и прочими чудесами (а их там хватает, пресловутые 4 шага разработчики Java освоили неплохо) — оно всё равно работает заметно медленнее, чем пара циклов и StringBuffer.
А вот это уже, извиняюсь — никуда не годится.
Кстати, думаю, что если на каких-то задачах sprintf является узким местом, там бы код оптимизировали возможно уйдя от SOLID.Невозможно написать быстрый код «оптимизируя узкое место уйдя от SOLID». Это так не работает. То есть да, можно легко перейти от скорости в 0.1% от оптимальной к 1% от оптимальной. А вот уже даже 30%-40% получить, если у вас код в стиле фабрик-фабрик-фабрик сделан — не так-то просто.
Почему? Да потому что с 1982го года ничего принципиально не изменилось. И ваш настольный компьютер и ваш телефон — это, по прежнему, вот такой вот вот зверь, если заглянуть в микроскоп:
В нём по-прежнему разнесчастные 32KB-64KB памяти, а всё остальное — медленные свистелки и перделки.
Вылететь за 32KB-64KB памяти при использовании SOLIDного проектирования — нефиг делать. А это — сразу замедление на порядк. А если вы уже за пару мег вылетели — так там ещё один порядок будет…
А вот Java printf — с этих позиций, похоже, вообще не оценивали.
Если не оценивали за столько лет, может быть нет задач, где это является узким местом?
Невозможно написать быстрый код «оптимизируя узкое место уйдя от SOLID». Это так не работает. То есть да, можно легко перейти от скорости в 0.1% от оптимальной к 1% от оптимальной. А вот уже даже 30%-40% получить, если у вас код в стиле фабрик-фабрик-фабрик сделан — не так-то просто.
А по моему как раз наоборот, если есть SOLID то изменить начинку куска кода не меняя интерфейс проще.
SRP говорит о том, когда декомпозиция строго необходима. Достаточность же на усмотрение разработчика.
Разработчики стандартной библиотеки Java решили, что гибкость дизайна важнее производительности, вот и все.
У меня с точки зрения SRP нет претензий ни к тому, ни к другому. (Ну, к printf есть, но несущественные — можно было бы работу с буфером вынести отдельно).
Ну а у меня ощущение, что вы уперлись рогом в свои представления и не слышите собеседника. Ведь только тролль может быть с вами не согласен, правда?
Я пока слышал от вас аргументацию уровня джуниора, и «особое» понимание принципов SOLID.
Из ваших слов получается:
SRP вы воспринимаете как необходимость дробить до безумия,
OCP — запрет на редактирование кода
LSP — это о преобразование сложных типов
ISP — требует интерфейсов из одного метода
Честно я ждал от вас вдумчивых аргументов, тоскуя вечерами. А получается что вы просто не понимаете, не умеете и логично что не любите SOLID и всячески защищаете свою безграмотность.
SRP вы воспринимаете как необходимость дробить до безумия,Это не он так его понимает — это его так «правоверные ООПшники, писавшие стандартную библиотеку Java» так понимают.
Можно, конечно, сказать, что они — ничего не понимают в ООП, но… если люди, пришущие стандартную библиотеку не умеют в SRP, то… кто тогда умеет?
OCP — запрет на редактирование кодаДа, часть из этих сотен объектов рождена из OCP…
А получается что вы просто не понимаете, не умеете и логично что не любите SOLID и всячески защищаете свою безграмотность.Я ещё не видел людей, «понимающих и любящих SOLID» — и при этом способных сделать что-нибудь хоть сколько-нибудь сравнимое по эффективности решение с тем, которое могут предложить люди, «не умещие в SOLID».
Я охотно принимаю, что если постановка задачи звучит как «у нас есть 100500 индусов, не хотящих разбираться в том, что они пишут и нам нужно произвести монстра, который ну хоть как-нибудь, пусть медленно и плохо — но решает задачу», то SOLID — это отличный подход.
Но на выходе у вас всегда будет получаться большое и тормозное дерьмо… и хотя я готов признать, что «большое и тормозное дерьмо» — гораздо лучше, чем «отсутстствие работающего результата вообще», но ведь надо же понимать — какую задачу вы решаете и зачем!
Условно говоря: SOLID, это… ну не знаю — примерно способ выпекать гамбургеры в тысячах Макдональдсов по всему миру, но ни в коем случае не способ приготовления еды, которая понравится человеку, который хотя бы раз в жизни ел вкусную еду.
Для 95% задач важнее чистая и гибкая архитектура, позволяющая эффективно решать возникающие задачи и быстро реагировать на меняющиеся требования как в краткосрочной, так и в долгосрочной перспективе.
Для 5% задач, типа той же sprintf, которая используется миллионы раз, да, надо взять, написать эффективно и отлить в камне.
(Ну это, конечно, смотря какая область, если вы пишете ядро ОС или стандартную библиотеку, то там соотношение будет обратное).
Что касается стандартной библиотеки Java, скажу мягко, она во многом не пример для подражания. Надо делать скидку на середину 90-х, когда еще были иллюзии, что JIT-ом получится все оптимизировать, и даже о специализированных CPU для Джавы всерьез думали.
Для 95% задач важнее чистая и гибкая архитектура, позволяющая эффективно решать возникающие задачи и быстро реагировать на меняющиеся требования как в краткосрочной, так и в долгосрочной перспективе.Вот только фикция это: не позволяет эта «гибкая архитектура» ничего менять. Вот проводить 100500 рефакторингов — позволяет. А делать вещи, которые не сводились бы к «добавлению красненького» — нет. Вот в чём парадокс-то.
Что касается стандартной библиотеки Java, скажу мягко, она во многом не пример для подражания.Если она — «не пример для подражания», то почему ей все подражают? Ведь об этом вся статья, в принципе. А не о том, что нужно про ООП забыть и всё на чистый Pascal ISO/IEC 7185:1990 переписать…
Надо делать скидку на середину 90-х, когда еще были иллюзии, что JIT-ом получится все оптимизировать, и даже о специализированных CPU для Джавы всерьез думали.Ну тогда много о чём думали… и что компилятор вместо суперскаляра работать сможет (не смог) и что JIT сможет 100500 уровей индирекции «схлопнуть» (не умет) и что GC смогут сделать таким, что он вместо ручного распределения памяти сможет работать (не смогли: предсказуемости всё равно нет, хотя в некоторых ограниченных масштабах «цирковые трюки» и работают).
На самом-то деле самое главное, что происходило «в середине 90х» — это резкое, просто реактивное, ускорение процессоров: 486й (1й процессор, где большинство инструкций исполнялись за 1 такт) на 25MHz — это 1989й, на 50MHz — это 1991й, 1993й — это P5 (1.5 команды за такт плюс-минус и 60MHz), P54CS на 200Mhz — это 1995й, а Pentium II на 300MHz (плюс спекулятивное исполнение) — 1997й, через пару лет Katmai на 600Mhz и ещё через два года Tualatin на 1GHz с гаком.
Производительность удваивалась каждую пару лет — и под это всё и затачивалось.
А потом… оп-па: шайтан-машина издохла, славный путь к 10-20GHz (а такие планы всерьёз в конце прошлого века озвучивались!) обломался… но разработка-то ведётся в предположении, что вот-вот уже, совсем скоро, мёртвая лошадь встанет и побежит! А когда покупатели этого… добра, резонно спрашивают — почему оно всё тормозит и жрёт память «как не в себя»… то им отвечают: ну тут гибкость такая, необычайная… вы главное больше в эту гибкость верьте! То, что в конце прошлого века за пару часов разработчик мог без всяких CI и прочих мудрых слов добавить в формочку и отчёт новые данные — это всё фигня. Это вы просто «не такую» гибкость ищите. Неправильную. Там зато «дизайна» не было правильного…
P.S. Есть только одна вещь, в которую я не верил 10 лет назад, но которая сейчас реально работает: удаление «мёртвого кода». И Clang/GCC/MSVC и Java/C# и даже JavaScript движки — отлично с этим справляются (JavaScript — сносно)… при одном условии: если у вас нет вот этого вот всего SRP, OCP, DIP, ISP и прочего. Когда данные, которые используются совместно — и лежат в памяти близко. А вот как раз все эти SOLID'ные подходы устраивают в данных полный кавардак: вещи, которые используются совместно оказываются в разных местах памяти, а вещи, которые совместно почти никогда не используются — собираются в один объект.
Да, чёрт возьми, сама основа современных языков такова, что данные расположить в памяти «плотно», вообще говоря, невозможно! Вообще! Никак! Ну… если, вдруг, вас не устраивает ситуация, когда ваш огнедыщаший дракон с потреблением как доменная печь, почему-то работает медленнее, чем калькулятор, то вот вам, с барского плеча, костылик… радуйтесь.
А вот как раз все эти SOLID'ные подходы устраивают в данных полный кавардак: вещи, которые используются совместно оказываются в разных местах памяти, а вещи, которые совместно почти никогда не используются — собираются в один объект.
Выглядит как нарушение SRP как раз
printf. Что нужно, для того, чтобы вывести этот три несчастных циферьки? Разделитель тысяч, десятичную точку, информацию про набор символов (арабские цифры, настоящие арабские цифры) и так далее. И вот в соотвествии с SRP всё это у вас будет разбросано по памяти. Более того: велик шанс, что у вас класс, вставляющий разделитель тысяч будет отделён от класса, занимающегося десятичной точкой, а значит что — он будет эти данные копировать.В том-то и дело, что когда вы начинает обрабатывать данные — то вам становится нужно, чтобы данные из разных «уровней абстракций» оказались где-то рядом. А SRP требует ровно противоположного.
Как будет выглядеть SRP-почта? Ну примерно так: где-нибудь в Африке у нас много-много пакетов, куда упаковывается содержимое посылок. Там у нас живут упаковщики. А этикетки к ним печаются где-то в Северное Америке — там печатники. Проверка на вредные вещества — где-то в Австралии, а весы — в Азии. Посылка посланная на соседнюю улицу наматывает 3-4 «кругосветки».
И когда у нас возникает вопрос: «а как нам добиться того, чтобы посылка шла не полгода, а хотя бы месяц?», то, как правило, идёт выбор между строительством сверхзвуковых авиалайнром или гиперлупом.
И то и другое — дорого и, главное, не нужно: нужно просто избавиться от континента, населённого печатниками — и свести обработку посылок в одно почтовое отделение. Но это же будет нарушением SRP! У нас будут доблироваться отделы! И одно и то же будет происходить много раз! Это низззяяя!
И одно и то же будет происходить много раз! Это низззяяя!
Кто сказал что нельзя? Любые принцыпы можно нарушать, если знаешь зачем.
Разбиение на разные объекты вовсе не означает, что данные при этом обязательно должны попасть в разные места.
Ну, в Java, вроде бы, означает. Но ведь не одной только Java ООП ограничивается...
Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ