Comments 23
Возможно кому-то моя манера изложения могла показаться чересчур вальяжной...
Именно
Возможно кому-то моя манера изложения могла показаться чересчур вальяжной...
Все норм братюнь, держи пятюнь.
Вопрос про знания:
Есть метод User::getFio(): Fio. Если Fio где-то внесён в приватные, но там используется этот метод без явного упоминания Fio, вычислить его система? А если явно тип возврата не определён, а есть аннотации? А если и их нет, сможет вывести тип?
А так очень интересный пакет, надо поиграться на досуге.
А если явно тип возврата не определён, а есть аннотации?
Пока из анотаций умеет разбирать только
/** @var ... */А если и их нет, сможет вывести тип?
Нет, так пока не умеет
Если Fio где-то внесён в приватные, но там используется этот метод без явного упоминания Fio, вычислить его система?
Такого тоже не умеет, возможно со временем
Как вариант, можно попробовать что-то вытащить через расширение php-ast
https://github.com/nikic/php-ast
Так вот, этот принцип говорит что метрика I компонента должна быть больше метрик I компонентов, которые от него зависят. То есть метрики I должны уменьшаться в направлении зависимости.
Наверное "метрика I компонента должна быть меньше ..."?
Вторая часть вкусная. Обязательно посмотрю техническую реализацию. Мы для Yii 3 активно используем https://pdepend.org/ и https://github.com/clue/graph-composer, но устали руками это всё делать и хотим запилить прямо в наших инструментах для разработки https://github.com/yiisoft/yii-dev-tool
Спасибо! Ну да, рабочая схема, норм для начала, наверное, большинства проектов, но в какой то момент, с развитием и ростом системы, она может стать трудно поддерживаемой. Тогда уже необходимо ее пересматривать, делать реструктуризацию, выделять новые компоненты и т.д. Об этом, кстати, тоже говорится в обсуждаемой книге. Хотя, у большого числа проектов этот момент может и не наступить)
А чем хороший, что все размазано? В одной папке Entity совершенно чужие друг другу классы, ровно как и в других...
Почему рядом с User будет находиться Product, а не UserRepository… Где тут логика?
Оговорюсь, я имел ввиду не совсем Entities, Services, Repositories, а Model (в которой будут entities, value objects и т.д.), Services (слой логики приложения) и Infrastructure (вспомогательные механизмы: конкретные реализации всяких репозиториев, нотификаторов и т.д.)
А также, не имел в виду сваливать все подряд классы в эти 3 папки, естественно можно сделать в каждой из них структуру и каким-то образом группировать логически близкие друг к другу элементы.
Хороша эта схема тем, что она проста. Для декомпозиции системы на большое число правильных компонентов, однозначно, потребуется больше времени и усилий. А вероятность того, что в новом проекте, в котором кода написано с гулькин нос, получится с первого раза сделать правильное разделение на компоненты, очень не велика. При этом, далеко не все проекты дорастают до размера, когда в декомпозиции на большее число меньших по размеру компонентов появляется реальная необходимость. Т.о. можно начать с малого и усложнять систему постепенно, по мере роста, когда это становится нужно.
Вот одна из них:
Допустим есть компоненты A и B. В целом мы не против, чтоб А использовал В, но по ряду причин хотим ограничить эту связь, т.е. сделать её допустимой ТОЛЬКО для конкретной группы классов (на пример, чтоб зависимость не разрасталась очень сильно, мы реализуем в компоненте A что-то типа ACL (anti-corruption layer), только в миниатюре :) и для него разрешаем зависимость от В, остальные элементы компонента A должны взаимодействовать с B ТОЛЬКО через него, т.е. не на прямую.
В данный момент времени, что-то подобное можно реализовать через описание в конфиге отдельного компонента для ACL. Т.е. вводим в конфиг еще один компонент, в него ложим исключительно классы прослойки между А и В, ему разрешаем знать про компонент В, а про него разрешаем знать компоненту А. Проблема данного подхода именно в необходимости добавлять новый компонент. Если таких будет несколько, я думаю, это усложнит картину для визуального восприятия, т.к. на графе и графиках будет много лишних элементов (тех самых прослоек, которые в принципе можно и не выделять в отдельные элементы системы).
Идея: доработать в конфиге компонента секции allowed_dependencies/forbidden_dependencies, чтоб помимо разрешенных/запрещенных компонентов, в них можно было перечислить классы или директории, в которых располагаются классы, которым можно/нельзя знать про задаваемый в конфиге сторонний компонент.
Что думаете по этому поводу?
А в чём минус решения для ввода в B класса фасада или нескольких, к которым только и разрешить доступ "извне"?
Разместить фасад где-то в нашем коде, но в конфиге, директорию в которой мы его разместили указать как второй корневой каталог компонента B.
Работать будет, но тоже добавляет нюансы в конфигурацию. Т.к. без этого костыля, мы вообще могли-бы для стороннего пакета В секцию в modules не описывать, а просто включить vendor_based_modules. А так нужно будет его отдельно описывать в modules + исключать в vendor_based_modules. Не то, чтоб это очень сложно, но как-то вроде не очень :)
Технически это можно реализовать через friendly classes: https://3v4l.org/k1e2l
«Ограничение максмально-допустимого расстояния до главной последовательности (для всех компонентов)», можно «максмально» исправить на максИмально?
Чистая архитектура на PHP. Как её измерять и контролировать?