• Немного закулисья VK
    0

    Ну тип того. Яркий пример такого простого специализированного решения — beanstalkd. Ну или вот.

  • Немного закулисья VK
    +1

    но вообще — просто поресерчите истории популярных опенсурс продуктов. Подавляющее большинство рождались в недрах каких-то компаний.


    Возьмите тот же angular — его пилили в гугле как хобби. А сегодня это один из самых популярных фреймворков. Или react — его так же пилили в facebook годами перед тем как зарелизить. Тот же graphql это так же был внутренний проект.


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


    ClickHouse так же пилится с 2009-ого года, и на тот момент когда начинали пилить только только появились сырые хадупы и касандры. Потому на тот момент рисков явно было меньше а профита явно было больше.

  • Немного закулисья VK
    0
    Я конечно все понимаю, но как то очень оптимистично.

    специализированная СУБД, под конкретную задачу. Это не база данных общего назначения. Потому да, не вижу ничего страшного в 2-х месяцах.


    А тестирование? А затраты на внедрение?

    Вы можете внедрять новую систему планомерно, получая профит постепенно и тестируя в реальных условиях. Это существенно упрощает вопрос.


    И это ещё не факт что вообще взлетит.

    обычно перед тем как решаться на такое уже должен быть некий proof of concept который доказывает эффективность решения.


    Разве что они наняли гениев, которые за два месяца написали весь функционал.

    Решение после обкатки было выложено в опенсурс как раз что бы уменьшить и эти издержки (хотя сам факт выкатки в опенсурс это тоже дорогое удовольствие).


    Как по мне то это очень сложные вопросы

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


    И да, я забыл рассказать еще об одном аспекте таких решений. Предположим что ваша компания может себе позволить такое удовольствие как написать свою СУБД. Помимо решения каких-то внутренних проблем, это вам даст еще возможность отправлять людей на конференции и повышать престиж компании среди разработчиков. А это в свою очередь будет создавать конкуренцию за рабочее место. И если вам позвонят из компании и скажут "а не хотите ли вы придти на собес" то большинство ответят "конечно хочу".


    У многих компаний существует такая практика. Найм людей тоже штука дорогая.

  • Немного закулисья VK
    0
    кушает он только в рабочее время

    Я и считал 160 часов в месяц.


    и все-таки немного поменьше

    Суть была не в том что бы конкретные цифры обсудить, а в простом соотношении и времени окупаемости. cost/benifit анализ. Подставляя свои цифры мы можем прикинуть что и как.


    Например Вася пупкин начитался статей о том как люди делают всякие кафки, касандры и прочие кликхаусы, и подумал "а чем я хуже, я ж тоже могу!". И введение кастомного решения у него затратит его времени на $10K а сэкономит он $100 в месяц, окупаемость ~10 лет. Вместо этого инвестировать время можно в другие вещи.


    А вот если вы фэйсбук со своими датацентрами, и у вас все на php, то выгодно нанять команду высококвалифицированных C/C++ разработчиков что бы они вам на LLVM JIT компилируемый язык нарисовали, который позволит вам в 2-3 раза уменьшить нагрузки на железо (вот ту миллионы) +, поскольку у вас контроль за языком — позволят ввести новые фичи в язык, которые существенно упростят тот же статический анализ (array shapes, type aliases).


    Ну то есть помимо очевидного бенифита в виде сокращения издержек на сервера, мы имеем косвенные бенифиты.


    ну и да, реально довольно часто хочется что-то маленькое, специализированное и скучно. А потом уже под это дело можно и бенифиты придумать.


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

  • Немного закулисья VK
    0
    Ну и да, в некоторых ситуациях смена модели данных и разработка эффективного стораджа под эту модель единственный способ вписаться в нефункциональные требования. Благо обычно хватает существующих моделей (документы, графы, колонки)
  • Немного закулисья VK
    +4
    300 серверов тоже надо поддерживать. Вы должны это учитывать так же при анализе. А так математика в целом простая. Что бы написать кастомную СУБД под задачу много людей не надо, достаточно человека 2-3. Кушать допустим они будут сумарно баксов 150 в час. 300 серверов предположим что кушать будут баксов 60 в час (предположим что у нас 300 штук каких m4.xlarge).

    Предположим что разработка СУБД в целом займет месяц-два работы и потом затраты на поддержку оной будут составлять уже каких-нибудь $15/h (типа часов 16 часов в месяц например). Итого инвестиция окупится через каких-нибудь месяцев 6.

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

    Понятно что если вы просто вася пупкин — не надо вам делать свои СУБД. Разве что как хобби.

    p.s. я все ж подозреваю что кушать эти разработчики будут чуть меньше.
  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0
    Попробуйте так модуль скидок кастомный прикрутить. Или модуль трекинга доставки. Что бы было дешево интегрировать и в целом небыло конфликтов по функционалу с другими элементами системы.

    Это в целом беда всех CMS которые пытаются таким образом расширять функциональность. за счет обобщения и объединения.

    Словом, не вы первый и не вы последний. Несколько раз в год кто-то делает свою новую CMS и как бы… ничего толком качественно не меняется.
  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0
    это базовые элементы для построения вашей архитектуры. Это не бэст вэй для создания CMS-ок.
  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0

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

  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0
    Не согласен.

    Тогда приведите конкретику, как именно бандлы позволят вам расширять вашу систему. Скажем что нужно будет сделать что бы при просмотре карзины можно было лицезреть продукты, которые вы выложили из корзины перед чекаутом в предыдущие заходы?


    их удобной установки

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

  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0
    Тут не хватает ещё одного предложения.

    Это тонкая отсылка к Yii, который был популярен как раз в те времена, и который прославлял наследование как единственно верный путь расширения функционала и реюза кода.


    Чем это плохо — не мне рассказывать.


    Вы лучше знаете что мне удобно?

    А вы продукт свой единолично будете использовать? если так — то никаких вопросов. Но тогда зачем вы статью опубликовали?


    Если вы делаете продукт, без разницы коммерческий или опенсурс, он должен быть удобен не вам а пользователям продукта. Увы.


    И тут вопрос не "мне удобно" а в том что расширяемость через бандлы — так себе идея. Это не плагины в чистом виде, ваша система должна предоставлять какие-то свои точки расширения функционала. И это не просто.


    Но тут я чувствую, что цель была не помочь, а выпендриться.

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

  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0
  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB
    0
    Для модулей админки есть абстрактный класс

    так вот к чему про 2009-ый год в статье.


    По-моему этот механизм очень удобен.

    нет.


    Например, там очень легко менять структуру данных

    сегодня даже sqlite умеет в json.


    эти данные отдельно друг от друга нужны в очень редких случаях.

    типичная ошибка начинающего архитектора — проектировать модель данных под UI.


    Просто шутки ради рекомендую посмотреть: Microservices and Rules Engines – a blast from the past — Udi Dahan. Там больше про связанность и про мелочи декомпозиции которые могут быть неочевидны поначалу но заставляют чуть по другому смотреть на проектирование.

  • Компьютерное зрение и машинное обучение в PHP используя библиотеку opencv
    0
    > работает быстрее и потребляет при этом меньше памяти.

    все познается в сравнении. Оно на самом деле не медленное, но для реалтайм обработки на мобилках этого не хватает и придется уже додумывать свои оптимизации поверх. А это требует большего контроля за алгоритмами.

    так же есть коммерческие реализации все тех же алгоритмов которые на порядки быстрее, но…
  • Компьютерное зрение и машинное обучение в PHP используя библиотеку opencv
    +1
    Вы результаты опроса к статье смотрели?

    я смотрел и варианты ответов подобраны так что бы объективного опроса не вышло.


    Большая часть php-разработчиков не знает python

    и не знают ничего о CV. по трудозатратам на обучение выучить синтаксис python не составляет труда. Более того, будет даже проще потому что намного больше примеров на том же python. Банально даже те что идут вместе с opencv.


    и при этом интересуется машинным обучением.

    "интересуется" — тут надо было уточнять что именно означает фраза интересуется. Читает статьи на хабре, и публикации на эту тему — это разные все же вещи. Или там запустить дэмку распознавания лиц которая идет в комплекте с opencv тоже не совсем точно степень вовлеченности характеризует.


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


    то я не спешу выносить эту часть на python

    это делает nginx из коробки. Можно еще поставить imaginary. И только если вам уж совсем прям что-то другое надо можно изголяться и что-то писать на эту тему.


    Проблема не в том что питон как язык лучше, проблема в экосистеме. Для php есть биндинги того же vips, вполне себе удобные, но если вам надо побыстрому SVM классификатор или с класстеризацией побаловаться + немного DSP — то под питон вы банально быстрее найдете готовые решения. И не просто готовые а качественные готовые решения.


    «удобство» — абстрактное понятие

    удобство, которое выражается в качестве экосистемы под выбранную задачу — не такое уж и абстрактное. Удобно это когда не надо писать код и просто берешь готовое. Особенно если твоя цель — побаловаться или поресерчить можно ли вообще сделать штуки. А так если вы вдруг захотите сделать сервис по типу фликера, с автоматическим распознованием людей на фото, opencv вам хватит только на начальную фазу ресерча. А потом придется пилить что-то более свое и низкоуровневое. Ну или там захотите вы написать новый маскарад — и окажется что opencv для этого не годится (медленно на мобилках).


    там вообще нет к нему биндингов

    вроде уже есть

  • Общая картина модульного тестирования
    0
    Ну смотря как трактовать information hiding.

    Из того что вы говорите, вам в целом важно скрыть как работает модуль в том плане, что бы изменения в этом модуле не оказывали каскадного эффекта на клиенский код. Так? Типа low coupling и все такое. И для тестов вы просто делаете исключение (и то стараетесь не делать, если конечно так не проще), дабы упростить себе жизнь.

    Я все верно уловил?
  • Общая картина модульного тестирования
    0
    > Я сторонник энкапсуляции, но не сокрытия.

    можете раскрыть столь глубокую мысль? То есть information hiding это бушит? Или вы про то что кастыль вида private/public это булшит? Если последнее — то я вас поддержу.

    > но если там какая-то сложная логика, то протестирую сначала эту функцию

    И скорее всего я буду делать так же. И из моего опыта — это крайне редкие случаи.
  • Общая картина модульного тестирования
    0
    Но стоит этот метод вынести в отдельный класс и внезапно тестировать его необходимо отдельно

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


    что в нём сложно тестировать приватные методы.

    они не спроста приватные (хотя часто просто так, да, или псевдо-приватные). Это деталь реализации которая не важна с точки зрения клиентского кода. Давайте так. Вот есть у нас функция и она спрятана в контексте модуля. Вы вооще никак не можете получить к ней доступ. Будете ли вы экспортировать функцию или будете проверять ее косвенно? Или в целом вопрос некорректен без указания контекста что мы тестируем, с какой целью и т.д.?

  • Общая картина модульного тестирования
    0
    Изоляция и декомпозиция — ортогональные понятия.

    Не согласен. У этих понятий есть пересечение. И это важно.


    Впрочем, декомпозиция, ради декомпозиции, тоже не имеет практической ценности.

    согласен.


    Ну, поднять in-memory базу не такая большая сложность.

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


    что ваш запрос базой будет интерпретирован верно.

    я тестирую запрос или то как база интерпритирует запросы? Или тот факт что под выбранны прекондишен запрос вернул то что мне нужно? Сколько мне нужно таких примеров сделать что бы убедиться в корректности системы? хочу ли я это делать или я больше доверюсь комбинации из приемочных e2e тестов на позитивные сценарии (потому что они всеравно будут триегрить те же запросы, просто на меньшем количестве возможных прекондишенов) + ограничения на уровне схемы + тайп чекинг.


    И я буду намного больше уверен что все работает.


    "как так он живёт хорошо с компонентными тестами"

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


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


    И очень важный момент — когда я говорю изолированные тесты я не имею ввиду что я всегда изолирую все зависимости и т.д. Как никак стандартную библиотеку я ж не подменяю, что мешает мне еще что-то не подменять? Но тесты все еще изолированы на уровне модуля который я хочу тестировать.

  • Общая картина модульного тестирования
    0
    Нам нужно проверить, что алгоритм реализован правильно

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


    А так комбинация из покрытия типами + примеры — этого достаточно что бы проверить требуемое поведение.


    Результат сортировки останется прежним, но эффективность станет хуже чем даже у пузырька.

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


    А если какой-то вариант кода будет лучше оптимизироваться JIT-ом, вы тоже будете в модульных тестах проверять это дело? или это уже перебор?


    Тут мы обсуждали приватный и публичный интерфейсы.

    Скорее то, сколько знаний о реализации мы экспоузим в тэстах. И я не очень понимаю причем тут http api и модульные тесты. Для приемочных/интеграционных тестов да, можно говорить. Модульные действуют на другом уровне.


    Да и те же http api можно частично покрыть типами что бы уменьшить необходимость в дорогих тестах.

  • Общая картина модульного тестирования
    0
    Давайте без терминологических споров.

    ну так вы же их разводите.


    В реальном приложении удобство изоляции отдельного модуля — не имеет практической ценности.

    Декомпозиция не имеет практической пользы?


    У меня сейчас перед глазами два проекта:

    увы по вашему описанию я могу сделать два вывода:


    • слишком много зависимостей?
    • так себе ситуация в JS с mock фреймворками?

    У меня же перед глазами другая проблема. Прекондишен для функционала на уровне базы (я ж еще и бэкэндщик, мне не надо мокать http, мне надо как-то стэйт в базе держать). И знаете, вот можете что хотите говорить но я интеграционные тесты буду использовать только для проверки контрактов которые мне не принадлежат.


    как следует разобраться в теме.

    может быть вы как следует не разобрались в том о чем он вещает и только лозунги слушали? Да, я согласен что сам по себе доклад в целом не отвечает на вопрос "как делать" и для этого лично мне пришлось немало времени потратить что бы понять "как так он живет хорошо с модульными тестами". Ну то есть вопрос о e2e тестах скажем у него за кадром остался, вопрос о event driven подходах и снижении количества зависимостей до минимума так же. Но все же...

  • Общая картина модульного тестирования
    0
    > начинает требовать на вход не только массив, но и «логгер», «квантайзер», «менеджер памяти», «хеш-функцию» и прочую ерунду

    не обязательно, вопрос лишь в степени изоляции с которой нам удобно работать.

    > это прям требование, а не деталь реализации.

    а можете привести более… приближенный к реальности пример?

    > Разным потребителям должны быть доступны разные уровни интерфейсов.

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

    > Ну вот представьте, у вас есть один публичный метод и 10 приватных.

    Да, согласен, но в реальной жизни такие ситуации крайне редки (обычно 10 приватных методов -> что-то с разделением ответственности пошло не так). В целом я отказываюсь обсуждать этот вопрос на сферических конях в вакууме ибо все просто скатится к пустой демагогии.
  • Простое объяснение принципов SOLID
    0
    Это DI

    А где вы там усмотрели именно внедрение зависимостей? Я бы согласился что для DIP нужно соблюдение Inversion of control, но DI лишь один из способов добиться IoC.


    А какая разница? Или что?

    Разница в направлении зависимостей. Предположим у нас есть модуль A который зависит от чего-то из модуля B. То есть направление зависимости у нас A -> B. А что бы возник принцип инверсии зависимостей, у нас B должен стать зависимым либо от A (A <- B), за счет добавления интерфейса в модуль A, либо, мы должны ввести третий модуль C, который будет содержать в себе абстракцию (A -> C <- B).


    Если же у вас просто есть зависимость от класса — нет никакой инверсии зависимостей.


    На всякий случай уточню, что мы должны стараться всегда выбирать направления зависимостей от менее стабильного модуля к более стабильному (Stable dependency principle от того же дяди Боба). И DIP тут является одним из вариантов как мы можем достичь этого.

  • Простое объяснение принципов SOLID
    0

    если возвращаться к исходной теме — вы действительно путаете DIP и DI. Вы можете реализовать DIP без DI (таблица указателей на функции в каком-нибудь Си, или промежуточный модуль который предоставляет абстракцию остальным и какой-то другой модуль, который является реализацией этой абстракции), а так же вы можете практиковать DI без соблюдения DIP. Например когда у вас зависимость это конкретная реализация какого-то класса.

  • Простое объяснение принципов SOLID
    0
    А как вы их отличаете?

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


    Так что именно "принял решение"

    принял решение в этом ключе — это если там есть if statement. В любом случае это логика инициализации. Никакого отношения к "построению дерева зависимостей" это не имеет.


    то это снова DI? а если без сахара — то не DI? :)

    А как это вообще относяится к вопросу? В прочем что есть DI я уже говорил.


    обработки, которую делает сервис.

    если у вас у сервиса есть некая логика в конструкторе — скорее всего вам надо делать отдельную фабрику.


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

    Ничем. И все это никакого отношения к DI не имеет.


    Ну вот я передал в конструктор строкой имя конкретного класса в качестве зависимости.

    Да, ваш класс ничего не знает о том откуда зависимость и что там, главное что бы соблюдался контракт.


    Хотя если он потом инстанцирует зависимость и т.д. это уже не совсем DI в том плане что нам приходится еще и закладывать знания о том как собирать зависимость (зависимости зависимостей).

  • Простое объяснение принципов SOLID
    0
    это и есть уже «поиск и построение»

    Инициализация — да, поиск и построение — нет.


    И ваш сервис принял решение — положить этот объект вот в это поле.

    Это не "принял решение" а просто сохранил ссылку. Предположим что у нас есть возможность делать так:


    public function __construct(
        private Dependency $dep
    ) {}

    в этом случае мы лишь указали тип зависимости, а вся эта хрень с "положить в поле" скрыто сахаром. В целом это вообще все просто ограничение того, что нам нужно где-то хранить референс на переданный объект. Не более того.


    Мог проигнорировать

    в этом случае ему не нужна зависимость, и тогда вопрос — зачем оно объявлено как оное?


    Суть в том что сервис ваш объявляет лишь какие зависимости ему нужны, что он с ними делать будет это уже его забота.


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


    В этом собственно суть инверсии управления.


    В какой из описанных моментов DI перестало быть DI?

    DI это про то что зависимости передаются извне. Все. Ваш код не должен знать кто и как их вам предоставляет. Точно так же как тот кто передает зависимости не должен знать как эти зависимости будут использованы.


    К чему вообще спор и эти пустые философства?

  • Общая картина модульного тестирования
    0
    2. не просто «без зависимостей» а «в изоляции». Иногда (в случае сложных алгоритмов) это подразумевает тестирование приватных методов, но это крайне редко. Опять же основная рекомендация для таких тестов — нещадно их удалять когда они начинают мешать.

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

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

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

    К вашей статье добавлю ссылку где в целом все эти тезисы разбираются: [J B Rainsberger — Integrated Tests Are A Scam](https://www.youtube.com/watch?v=VDfX44fZoMc)
  • Общая картина модульного тестирования
    0
    модульные тесты — это тесты белого ящика

    Тут важный момент — как проявляется знания тестов о тестируемом коде. Описанный вами случай, когда нам прям нужно знать что мы реализовали qsort, как по мне больше экзотика. В 99% случаев нас не должны интересовать такие детали.


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


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


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

  • PHP-Дайджест № 132 (27 мая – 10 июня 2018)
    0

    Крайне сомневаюсь что они когда-либо пойдут на подобное. Это идет в разрез с философией фреймворка.

  • PHP-Дайджест № 132 (27 мая – 10 июня 2018)
    0
    это может быть удобнее оказаться

    очень плохо себе это представляю, так как для серверного рендринга придется мутить что-то дополнительно. Что не может быть удобнее. Хотя не отрицаю вероятности таких вещей. Но я бы рассматривал это как самый редкий и крайний костыль.

  • PHP-Дайджест № 132 (27 мая – 10 июня 2018)
    +1
    Стартовало голосование

    и так же финишировало. Голосование отложено до момента финализации RFC. Ну либо просто зафэйлится.

  • PHP-Дайджест № 132 (27 мая – 10 июня 2018)
    +2

    или подключить бизнес логику написанную на php в nodejs. Ну мало ли.

  • Простое объяснение принципов SOLID
    0

    class diagram смещает внимание с взаимодействия на структуру.

  • Простое объяснение принципов SOLID
    0
    но теперь есть UML, паттерны и принципы, все таки много с тех пор прошло времени.

    UML было до, паттерны так же (их назвали в 94-ом году но по сути все тоже самое было и до).


    Что до "много с тех пор прошло времени" — классы существуют уже лет 50. Структурный дизайн (который вводит понятия low coupling, high cohesion, information hiding (который по сути open/close или protected variations, авторы сами говорят что это одно и то же). Эти понятия появились в 70-х. Но почему-то не особо люди их понимают. И паттерны и прочие UML только хуже делают как по мне в этом плане.

  • Простое объяснение принципов SOLID
    0

    я не нахожу практической пользы в такой трактовке.

  • Простое объяснение принципов SOLID
    0
    не всегда будут совпадать.

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

  • Простое объяснение принципов SOLID
    0

    Егор такой Егор…


    Где-то тут уже писали что в последних редакциях дядя Боб делает уточнение что фокус этого принципа на выделении ролей, которые генерят вам требования. "Зона ответственности" в том плане что вашему модулю соответствует один стэкхолдер. И профит от соблюдения этого принципа заключается в том, что нам намного проще отслеживать конфликты в требованиях разных людей, проще предсказывать изменения модулей (когда уже известен некий набор изменений которые были произведены в прошлом), ну и в целом если мы добавим к этому OCP то проще делать более стабильные модули.


    Это не про маленькие классы, как пишет Егор. Нет никаких противоречий аля "является ли багфикс причиной для изменения, а оптимизация? а рефакторинг" как пишет Марко.


    По факту этот принцип целиком и полностью завязан на то, как ваши модули представляют интересы людей, для которых вы эти модули пишите. И да, это сложно. Есть книжки на эти темы (типа Object design, roles responsibilities and collaborations) и соблюдать этот принцип можно только если вы учитываете поток изменений требований.


    А если потока изменений требований нет — можете обратиться к другому принципу — Информационный эксперт. Он проще и не требует анализа потока изменений. Он в купе с protected variations в целом про information hiding и декомпозицию. Так же по сути как и SRP + OCP.

  • Простое объяснение принципов SOLID
    +1

    Попробую чуть перефразировать....


    в ваших примерах можно выделить 2 уровня. Уровень AuthManager и уровень приложения.


    В первом примере у нас композиция, нет ни DI ни IoC. С этим мы вроде оба согласны.


    Во втором примере, у нас на уровне AuthManager происходит внедрение зависимостей, однако если оно происходит мы можем говорить что на этом уровне происходит и инверсия управления, мы не знаем кто и как нам готовит зависимости, это не наше дело. Однако на уровне приложения у нас простая агрегация, это не DI, и поскольку мы сами управляем процессом у нас нет инверсии управления.


    Третий пример видоизменяет второй таким образом, что наш уровень приложения больше не знает каким образом формируются зависимости. То есть мы все же можем говорить о IoC, но для этого мы воспользовались сервис локатором. Так что на уровне приложения у нас все еще нет DI но есть IoC. А с точки зрения AuthManager разницы между двумя примерами нет.


    p.s. вообще я нахожу этот спор бессмысленным. Во всей литературе DI это реализация IoC. Они не разделимы. Ну и управление зависимостями это капля в море по сравнению со всем, что дает нам IoC.

  • Простое объяснение принципов SOLID
    0

    нет. У вас A зависит от B. То что вы не сами создаете инстанс а получаете его извне не устраняет зависимости A от B. Инверсии направления зависимостей не происходит. Что нужно сделать — либо разместить в модуле A интерфейс, который будет имплементить B, и тогда уже B будет зависеть от A. Происходит инверсия. Другой вариант — введение модуля C, от которого будут зависеть и A и B.


    Ну и очень важный момент который многие упускают, это выбор того когда нам нужна инверсия. В частности инверсию мы можем использовать для того, что бы все направления зависимостей указывали от менее стабильного модуля (тот кто чаще меняется) к более стабильному (тот кто меняется реже).

  • Простое объяснение принципов SOLID
    0
    изменение кода клиента

    проблема в том что вы сами изолировали пример только в рамках AuthManager. И с точки зения кода этого самого AuthManager инверсия управления происходит в обоих случаях.


    А с точки зрения "клиентского кода", того что вы указываете, я не вижу ни применения DI ни применения Inversion of control. В третьем варианте можно принятуть IoC за счет использование сервис локатора (не DI, прошу заметить).