Рубрика «srp»

Представьте, что вам на собеседовании дали задачу: спроектировать систему доставки газа по трубам переменного давления, причём система должна загружаться почти на 100% в зоне высокого давления, а разгружаться (быстро и почти полностью) в зоне низкого. Вы бы, наверное, нарисовали линейную зависимость. Больше давления — больше загрузка. Просто, и главное, что будет легко тестировать.

Эволюция посмотрела на этот вариант, подумала 500 миллионов лет и сделала всё наоборот.


Техзадание от природы

Предлагаю чуть формализовать. У нас есть два «дата-центра»:

«Он слишком занят самой жизнью, чтобы еще задумываться над ней».

— Джек Лондон, «Морской волк»

Я не React разработчик. Я прибыл к вам с далёкой планеты с одной целью: внедриться и изучить слабые места вашей архитектуры, ваших подходов, дабы доказать своему народу, что ваша цивилизация слишком хаотична, чтобы создать что-то по-настоящему долговечное.

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

Читать полностью »

В статье "Пережить великую нехватку переменных" (Outliving the Great Variable Shortage) Тим Оттингер формулирует закон Кёрли:

«Переменная должна означать только что-то одно. Она не должна означать "что-то при таких-то условиях" и иметь разный смысл в разных обстоятельствах. Также она не должна иметь два смысла одновременно. "За двумя зайцами погонишься – ни одного не поймаешь". Переменная должна означать что-то одно все время своего существования»

Седого ковбоя Кёрли Уошбурна в комедии 1991 года "Городские пижоныЧитать полностью »

Про принцип единственной ответственности (The Single Responsibility Principle, SRP) уже было написано множество статей. В большинстве из них даётся лишь поверхностное его описание мало чем отличающееся от информации в википедии. А те немногие статьи что затрагивают ключевые особенности SRP делают это вскользь, не акцентируя на них внимания и не развивая тему дальше.
Эта статья — попытка дать более глубокое объяснение принципу единственной ответственности, а также показать как его всё таки можно применять на практике. Кому интересно — добро пожаловать под кат.Читать полностью »

image Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.

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

В лесу нас разделили на группы по 8-9 человек в каждой и устроили соревнование — какая группа быстрее выпьет бутылку водки при условии, что первый человек из группы наливает водку в стакан, второй выпивает, а третий закусывает. Выполнивший свою операцию юнит встает в конец очереди группы.

Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.

Читать полностью »

Предыстория

За последние пару лет я поучаствовал в немалом количестве собеседований. На каждом из них я спрашивал соискателей о принципе единственной ответственности(далее SRP). И большинство людей о принципе ничего не знают. И даже из тех, кто мог зачитать определение, почти никто не мог сказать как они используют этот принцип в своей работе. Не могли сказать, как SRP влияет на код, который они пишут или на ревью кода коллег. Некоторые из них также имели заблуждение, что SRP, как и весь SOLID, имеет отношение только к объектно ориентированному программированию. Также, зачастую люди не могли определить явные случаи нарушения этого принципа, просто потому что код был написан в стиле, рекомендованном известным фреймворком.
Redux — яркий пример фреймворка, гайдлайн которого нарушает SRP.
Читать полностью »

Большое и увлекательное путешествие начинается с простого и банального шага. Когда мне на работе понадобилось реализовывать процесс логина для набора автоматизированных тестов, я даже не представлял, куда это приведет.
Дальше в статье вы узнаете, как доказать, что вы знаете пароль, ни разу не передав его в каком бы то ни было виде (доказательство с нулевым разглашением), и как я спотыкался на готовых примерах, чтобы получить работающий код на Python в конце пути.
ОТКАЗ ОТ АВТОРИТЕТНОСТИ: Я программирую на Питоне не очень давно, потому, вещи о которых я расскажу, и ошибки, которые я совершал могут показаться вам тривиальными.

Я тебе конечно верю, разве могут быть сомненья?
Я и сам всё это видел, это наш с тобой секрет

image
Для начала, если вы не знаете о незаслуженно мало упоминаемом протоколе SRP-6a тот вамобязательно надо ознакомиться с замечательной статьей на Хабре и крайне подробная англовики.
Читать полностью »

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

Определение

Каждый программный объект имеет одно и только одно назначение.
Его можно исчерпывающе описать одним предложением, не используя союзы.

Пример

Lazy<T> — обертка для объекта, чье создание откладывается до первого обращения к нему.

Антипример

Синглтон — класс, не допускающий создания более одного экземпляра. В этом описании нет союзов, но оно неполное — синглтон всегда имеет основную функциональность помимо контроля единственности собственного экземпляра. Синглтон — класс, реализующий полезную функциональность и контролирующий единственность собственного экземпляра. Теперь описание исчерпывающее, но имеет союз "и" — у синглтона два разных назначения. Он не соответствует принципу единственной ответственности.

Еще антипример

Локатор сервисов — позволяет получить доступ к любому сервису приложения. Это описание без исчерпывающего списка сервисов заведомо неполное.

Назначение

Упрощение создания, анализа и модификации программных систем.

Читать полностью »

От всех моих предыдущих реализаций сетевого слоя осталось впечатление, что есть еще куда расти. Данная публикация ставит целью привести один из вариантов архитектурного решения по построению сетевого слоя приложения. Речь пойдет не об очередном способе использования очередного сетевого фреймворка.

Часть 1. Взгляд на существующие подходы

Для начала из публикации 21 Amazing Open Source iOS Apps Written in Swift взято приложение Artsy. В нем используется популярный фреймворк Moya, на базе которого и построен весь сетевой слой. Отмечу ряд основных недостатков, которые встретил в данном проекте и часто встречаю в других приложениях и публикациях.

Читать полностью »

Single Responsibility Principe достаточно прост для понимания и его не сложно придерживаться.
Но в работе я достаточно часто сталкиваюсь нарушением этого принципа. В этой статье я собрал самые больные из способов нарушить SPR из тех, что я встречал.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js