29
Karma
0
Rating

Пользователь

Apple выпустила «тихий» апдейт для Mac, чтоб удалить скрытый веб-сервер от Zoom

-6
Есть. Айфон это окно в интернет (физическое воплощение браузера), а мак это персональный комп для работы.

Ещё лучшая ZIP-бомба

Прощай, простуда: внедрение препаратов в «карманы» вирусов

Что за черт, Javascript

0
На многих современных языках такой код написать невозможно

Психологи: секс-роботы приведут к увеличению числа людей без пары, которым не нужны отношения с другими людьми

Психологи: секс-роботы приведут к увеличению числа людей без пары, которым не нужны отношения с другими людьми

Осторожно доктор

+2
Какую именно, и откуда вы уверенны что критикуемый оратор — шарлатан?

Осторожно доктор

0
При том что у противовирусных могут быть нефиговые побочки.

Single Responsibility Principle. Не такой простой, как кажется

0
Ответ: Это зависит. Если выпивание всегда одинаково, но есть много реализаций этого выпивания, то это либо наследование, либо декоратор, либо адаптер. Ифчики тоже никто не отменял. Семантически эти подходы почти не различаются, а какой из сахаров выбрать — зависит от контекста: языка, бизнеса и, пожалуй, фазы луны.

В любом случае — это не вопрос SRP. Это вопрос Open-Close принципа (OCP) и он требует отдельной проработки. Постараюсь найти время заняться и этим парнем ;)

Свежий воздух на Марсе: согнуть молекулу СО2 и получить кислород

+1
Человеку нужны вызовы. То что происходит сейчас, когда в цивилизованной части света, единственная проблема это лайки и социальный статус — неестественно для психики человека. И жизнь в колонии, в скафандрах, холодильниках и тяжелых нагрузках, без пути назад — может оказаться ответом.

Свежий воздух на Марсе: согнуть молекулу СО2 и получить кислород

+3
Если рассматривать жизнь как высокоуровневую химическую реакцию — то такая реакция очень подвержена эффекту бабочки. При это сложно придумать ситуацию, где изменение условий приведет к глобальному размножению. А вот глобальное вымирание вещь простая: у каждого вида есть своя ниша и набор необходимых для выживания и конкуренции параметров — температура, пища, свет итд.

Но есть один вид, который заселил все — от северного до южного полюса и остановился ибо «зачем?».

У этого вида есть механизм осознанного (или частично осознанного) влияния на внешние условия. Потому, в рамках научных ограничений, мы можем поселиться хоть на поверхности солнца (летая у поверхности в холодильнике со скоростью достаточной что бы внутри аппарата было 1g) Была бы мотивация и достаточный уровень развития науки.

Короче — центрифуги, радиационная защита, евгеника и прочее прочее — дело техники, ресурсов и мотивации. В конце концов, как сказали выше, может оказаться что низкая гравитация напротив будет полезна. Мы не знаем.

Свежий воздух на Марсе: согнуть молекулу СО2 и получить кислород

+2
Причины вымирания — худшая приспособленности организма к резко ( в масштабах эволюции) изменяющейся среде. Пищевой и экологической. То есть вот плавал себе бульбульзавр. Плавал и ел жуков. Миллионы лет плавал и ел. А потом жуки стали крупнее и южнее. А там много акул. А акулы едят бульбозавров. И вымерли бульбозавры. Людям же это не опасно, так как мы можем воссоздавать каких хочешь жукозаменителей и где угодно (были бы финансы). И подошвы липкие можем напридумывать.

Куда опаснее — остановившаяся эволюция тут, у нас в естественной гравитации. Вот с этим точно надо что то делать иначе через сто лет вся современная Евразия на колясках будет рассекать.

Свежий воздух на Марсе: согнуть молекулу СО2 и получить кислород

Свежий воздух на Марсе: согнуть молекулу СО2 и получить кислород

0
Зато как круто там прыгать! Баскетбол, на стадионе размером с футбольныйс кольцами на высоте 5ти этажного дома. А нет, случаем такой компьютерной игры?

Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами

Single Responsibility Principle. Не такой простой, как кажется

Single Responsibility Principle. Не такой простой, как кажется

0
К программированию эта нагрузка имеет мало отношения.
Если же волею ТЗ требуется взять именно 4 игрока, то разбиение выпивохи на сабличности тем более пригодится.

Single Responsibility Principle. Не такой простой, как кажется

0
Зависит от контекста задачи. В случае с оригинальной студенческой игрой эти ответственности определенно разделены ;)

Если же весь процесс действительно жестко сцеплен, то есть изменение одной его части повлечет изменение другой — то это разделение не только не нужно, но и вредно.
В терминах SRP — такое разделение противоречит идее «локализации изменений».

Исключением может быть объемный процес, допустим на 500 строк кода (цифра «зависит»). В таком случае нужно стараться изыскивать возможности разделения ответственности, из-за ограничений нашего с вами мозга. Разбить сложный процесс на взаимодействие нескольких более простых.

Single Responsibility Principle. Не такой простой, как кажется

0
Переименовал статью в «Не такой простой, как кажется» ;)

Single Responsibility Principle. Не такой простой, как кажется

+2
Эта фраза и была основной мотивацией написать эту статью, так как вторая ее часть еще более загадочна чем изначальное определение. На сайте у дядюшки Боба еще целую страницу он объясняет что значит «Пользователи и заинтересованные лица и есть та самая причина для изменений».

Single Responsibility Principle. Не такой простой, как кажется

0
Дополнил статью вашим замечанием.

Я написал эту статью в т.ч. из опыта общения с начинающими разработчиками и в процессе общения открыл для себя много нового.

Для тех кто уже знаком с Srp — да, вопрос «что делает этот класс» — хороший критерий для самопроверки.
Но если вас еще не успели познакомить — то возникает много вопросов:
1) При наличие фасадов ответ может быть расплывчатым
«Выпивоха ответственнен за все что касается выпивания». А стакан — касается выпивания или за хранения жидкости? Он часть выпивохи или нет? Для новичка (да и не только) это может быть большим вопросом.
2) Формулировка «за что отвечает» является больше мотивацией дробить чем объединять, то есть накладывает ограничение сверху по размеру модуля, по крайней мере в понимание начинающих программистов (практика опять таки показывает, что не только)

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Кстати об индексах:

Embeded (24%):
C 14.243%
C++ 8.095%
asm 1.816%

Enterprise (30%):
Java 16.005%
Visual Basic .NET 5.193%
C# 3.984%
SQL 2.555%
PHP 2.489%

Действительно больше чем я ожидал. Впрочем это не касается особенно дискурса ибо Solid, безусловно не про низкоуровневую разработку

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

+1
Вы раскусили нас. Наш с манагерами заговор. Вы не могли бы скрыть или опровергнуть свой комментарий, так как нам еще деньги зарабатывать, а вы нас хлеба лишаете? С меня процент!

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Более того, манагер просят поменьше SOLID-а. У них «сроки-сжаты» и ХХВП их методология. SOLID и тесты — зачастую единственный формализм защиты от KPI-хаоса

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

+1
khim — да это же старый добрый Punks-not-dead--driven-development!

Есть спортивные машины, а есть гражданские. Произвести спортивную машину, в абсолютных деньгах и сложности намного дешевле и прощще чем гражданскую. И гражданских машин — 98% рынка.

К чему это я- вокруг дивный чудный мир, и львиная доля рынка занимается разработкой сложного ПО, не критичного к производительности, но критичного к функицональности. Одиночки и маленькие команды никогда не справятся с этим количеством нюансов, правок и этой динамикой рынка. И разрабатывать такое по — это искуство писать код для человека. Сделать себя взаимозаменяемым, и из этого стать дороже для рынка.
Другой пример, где читабельность выходит на первый план — Open source, где мэинтейнеру выгоден только тот реквест, который не усугубит энтропию. Максимально ясный, и покрытый тестами.

Вы приводите пример писателя и книг — но позвольте. Если вам нужно написать книгу в 10к страниц, а дополнять или изменять главы нужно раз в неделю — много вы книг издадите? Книга подобна алгоритму в программе — красивый, отточенный, согласованный. Но в программе таких алгоритмов тысячи. Современный софт, в основной своей массе нельзя сравнивать с книгами — он из них состоит.

Вы приводите пример авиаконструкторов — но их флоу обусловлен экономикой. Стоимость испытания великА а стоимость факапа — катастрофична. В софте эти стоимости почти бесплатны в сравнении. И сравните скорость развития самолоетостроения и софтвер отрасли. Софтвер отрасль развивается на порядки быстрее — в том числе из-за итеративного подхода. Иными словами — да, конструкторы делали бы итерациями если могли бы. И да — мои предки так же инженеры-конструкторы. Это имеет мало общего с современной разработкой ПО.

Безусловно есть крайние примеры легаси банкинга и физ базз интертеймент, но это точно такой же непрофессионализм как и методы по 10к строк. Две крайности.

Я вполне допускаю что конкретно вы делаете классные и специфичные вещи — это прекрасно! Мне классно что бы мы все были разными, и не греблись под одну гребенку.

Но основная масса занимается немного другими делами. Наше массовое исскуство — в читабельности и гибкости, и это отнюдь не проще чем создание алгоритма или тем более оптимизация. Не понимаете этого? Не практикуете это? Так зачем критикуете то в чем не разбираетесь?

И да, в моей практике тоже есть много кейсов, когда именно грамотное разбиение по модулям, и SOLID с unit-тестированием позволяли внедрять огромные фичи почти бесплатно, стал бы иначе я так защищать эти подходы? Я вступаю адвокатом дьявола по той причине что был по обе стороны барикад. И низко уровневой разработке втч алгоритмов и высокоуровневом процессинге высоконагруженных серверов.

Ну и в конце концов — уважьте людей. Брать в заложники заказчика своей уникальностью, это некрасиво, не профессионально и как то… низко что ли?

Доброго дня вам, и отличных задач!

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

+2
Ну тихо вы, вас же дети смотрят!

Поправьте меня, если я вас не понял:
— Вы — считаете что командная работа над одной задачей это плохо
— Считаете что UI-код в сетевом стеке это норм, пока его можно докостылить
— Считаете что выделение компонентов это плохой ход при котором скачком растет сложность
— Вы предпочитаете переписывание рефаторингу
— Считаете что оптимизацию нужно делать как можно раньше.

Позвольте уточнить — что именно вы делаете и на каком языке?

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Ну а у меня ощущение, что вы уперлись рогом в свои представления и не слышите собеседника. Ведь только тролль может быть с вами не согласен, правда?

Я пока слышал от вас аргументацию уровня джуниора, и «особое» понимание принципов SOLID.

Из ваших слов получается:

SRP вы воспринимаете как необходимость дробить до безумия,
OCP — запрет на редактирование кода
LSP — это о преобразование сложных типов
ISP — требует интерфейсов из одного метода

Честно я ждал от вас вдумчивых аргументов, тоскуя вечерами. А получается что вы просто не понимаете, не умеете и логично что не любите SOLID и всячески защищаете свою безграмотность.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

+1
что в Java один-единственный вызов String.format("%0.2g", 0.1); порождает несколько сотен объектов


Это вопрос уже не про SRP. А по поводу кол-ва объектов — повторюсь — SRP не про то что нужно все измельчать, а про то, как делить.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Ну вот профайлер вам показывает, что создание 100к объектов вместо 10к — это как-то сильно долго. Что вы там соптимизируете, не выпиливая SRP?

Прежде чем «грязнить» код — есть много других возможностей:
1) Большинство проблем происходят из O-сложности. Если O — побеждена — переходим на уровень малой крови.
2) Делаем синглтоны или кэши для часто используемых объектов, меняем ref на value типы (если позволяет инфраструктура) — итд.
3) Если и это не помогло — то часто можно упростить или реорганизовать архитектуру во благо скорости и без ущерба смыслу (на этом этапе уже понятно как).
4) Для высоконагруженных — не забываем про горизонтальное масштабирование.

И только потом, когда все вышеперечисленное не помогло — начинаем крошить код во благо скорости. Но необходимость этого встречается редко. Как правило на мобилках и ARM. И, безусловно — тут все средства хороши.

Что самое главное — предыдущие 4 пункта сложно выполнить, если у вас там все SOLID-ы порушены вкривь и вкось.

Он говорит «интерфейс закрыт для изменения, но открыт для расширения», что прямо противоречит рефакторингу.

Он говорит про изменение поведения, а не про то, что код нельзя трогать. Например — смена конекшн стринги из конфиг файла.

Или более сложный случай — вы хотите сменить одну SQL базу на другую — значит подготовьте бек-код так, что бы можно было менять провайдера DB, а не удалять старого и вместо него писать нового. Так же это говорит о том, что предпочитайте if-чикам — стратегии и композицию

LSP фактически утверждает, что все типы должны быть ковариантны. Что во первых не так. А во вторых даже не является свойством типа.

Lsp утверждает, что наследование и интерфейсы должно быть обоснованно по смыслу, а не для экономии кода. Иными словами оно против структурной типизации в языках — где структурной типизации нет, так как это лютый самострел.

Есть ощущение, что вы принципиально пытаетесь переспорить изначальный тезис, что спортивно и прикольно.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Позвольте вашей фантазии, добавлять к каждому абзацу фразу про «кровавое легаси»:

Не знаю, что такое «атомарные» тесты, но написать код так, чтобы он проходил один тест, но не проходил остальные, обычно сложно и бессмысленно.


«атомарные» — тестирующие минимальный объект. Я имею ввиду, что использование TDD в интеграционном ключе, тоесть тестирование больших кусков кода за раз, не тестируя маленькие — имеет тенденцию к «спецификации макарон в виде тестов». Кажется человечество еще не придумало как распутывать такие клубки.

Дьявол в слове «преждевременная». Архитектурная оптимизация должна выполняется как можно раньше, так как потом менять её будет сложно или даже невозможно. Это, кстати, большое заблуждение, что можно не думать о скорости, пока петух не клюнет.


Архитектурная «оптимизация» это хорошо, но речь про обычную, вызванную SRP. И это не заблуждение, по крайней мере если в стеке есть нормальные инструменты профайлинга. А вот экономия кол-ва типов — это кажется оскорбление чуств верующих в прекрасное, да и будущих разрабов за компанию.

Ко кровавому легаси приводит отсутствие регулярного рефакторинга. А OCP явно запрещает рефакторинг. OCP полезен лишь при взаимодействии со внешними клиентами, когда нужно сохранять обратную совместимость.


Ocp не запрещает и не поощряет рефакторинг. Он говорит что «изменение поведения кода нужно делать через… поведения-)». Иными словами — не надо хардкодить.

Не, вы не поняли суть проблемы. Смотрите, Cat является подтипом Animal, Cat[] является подтипом Animal[]. И если мы только читаем, то мы можем где угодно вместо Animal[] передать Cat[]. Но если мы где-то помещаем в массив, например, Dog, то, внезапно, мы уже не можем передавать Cat[] вместо Animal[]. Во времена Барбары об этой проблеме ещё не думали.


Либо я вас по прежнему не понял, либо вы путаете LSP и проблемы ковариантных/контравариантных преобразований и структурной типизации.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
TDD. Про TDD в оригинальном варианте максималиста — я соглашусь с вами. Однако гармоничный путь, описанный в исскустве автономного тестирования — это смесь написания тестов иногда перед, иногда после, но в основном — одновременно с написанием кода. «думай о тестах и коде как о едином целом (с) Тестиус». Потому я и указал TDrivenD/TLastD что бы не нарваться на формализм. Кстати отсутствие атомарных тестов зачастую приводит к кровавому легаси.

SRP. Проблема в понимании SRP как «дроби пока дробится». Но это не так. SRP — он же принцип единой изменчивости, единой ответственности и локализации фичей — говорит про границы декомпозиции, а не про ее размер. Нарушение Srp — это не только God-object, но и размазывание и дублирование по коду какой-то конкретной фичи. Дублирование кода, как вы понимаете отнють не ускоряет даже MVP. Ежели мы касаемся вопросов оптимизации — то «преждевременная оптимизация — зло (с)». Кстати неверная декомпозиция, приводит к костылям в коде и кровавому легаси.

OCP, при нормальном проектировании необходим для выполнения SRP и тестирования. А устаревшие интерфейсы можно просто удалить. Другое дело что вы не сможете их удалить если у вас нарушен OCP, что приведет вас к кровавому легаси.

LSP говорит что наследование и полиморфизм должны быть сделаны с умом, в том числе. Везде где есть нарушение LSP — начинается задница и борьба с иерархиями. Как правило тут начинают говорить про кровавое легаси.

ISP не приводит к интерфейсам из одного метода. Аналогично SRP, ISP говорит о том как нужно делать интерфейсы в спорной ситуации, и позволяет развязать жуткие клубки зависимостей. Это крайне необходимо для больших команд, сложной бизнесс логики и ограниченных контекстов. В противном случае — ну вы поняли ;)

DIP — соглашусь. Есть доказательства того, что слепое следование DIP приводит к рекурсивному генерированию кода. Таким образом DIP это не принцип, а ползунок, пренебрегать которым не стоит ни в одну, ни в другую сторону.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Приведите пример, я видел крайне мало удачных иерархий, и крайне много удачных композиций.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Из очевидного — Tdd/Tld с покрытием в зависимости от задач и SOLID. Начинайте.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
В синтаксическом дереве — набор типов фиксирован стандартом языка.

С другой стороны Visitor это не только паттерн матчинг но и SRP точка. Как раз та самая логическая группировка процедур обработки узлов.

И в довесок к ништякам — Visitor есть очень удобный интерфейс для использования в DFS. Тоесть отлично разделяются алгоритм обхода дерева и алгоритм преобразования.

Также есть вопрос к процедурному обходу — по читабельности:
В «безвизиторном» варианте обхода дерева с огромной вариативностью алгоритмов, вопрос группировки всех этих процедур встает очень остро, и, по сути, решается внимательностью и совестью разработчика. Это ок — если разраб один. Это очень не ок когда разрабов несколько и у каждого немного свое мнение, а среди них еще и затаился человек-снежинка.

Итого. В данном случае, визитор это:
— SRP
— Читабельность
— Строгая типизация

То есть больше, чем просто паттерн матчинг фиксированной иерархии в одном модуле.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Я не очень опытный разрабочик компиляторов, но, кажется для конкретно вашей задачи отлично подходит «Визитор». Безусловно нужно смотреть контекст задачи.

С проблемой каши из кода, при подходе DFS по синтаксическим нодам со свитчами и процедурами я столкнулся уже при N = 7, и M = 30.

Также, у каждого типа синтаксической ноды есть множество принципиально различных атрибутов, нужных для анализа и принятия решений, что есть жирный, статически типизированный плюс (привет Roslyn).

Один такой визитор будет инкапсулировать один из N алгоритмов для всех M нод. В случае дубляжа кода можно воспользоваться как полиморфизмом так и наследованием.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

0
Но если вы не учились у Дейкстры, то поймете все превратно. Ведь они то учились у него.

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

1 There