в этом классе целый букет проблем:) во-первых он не value object.
Есть возврат заинжекшеной переменной
public Settings settings() {
return this.settings;
}
есть создание сервиса внутри класса, есть нарушение закона Деметры. Не особо разбирался, что он делает, но уверен что есть нарушение SRP.
Теперь представь как будет выглядеть тест этого класса.
И мог ли подобный класс возникнуть в ходе TDD?
в мире dependency injection такого не бывает.просто оставлю здесь, что бывает в мире dependency injection:)
а есть пруф линк?
рынок ниразу не насыщен нодопрограммерами.думается это следствие, а не причина
универсальных ЖС девелоперов, чем зоопарк разработчиков-специалистовпоживем-увидим, но пока это явно не так
спрос на ноду и монго велик
около 3х вакансий в Киевечто-то тут не так:)
ну и «клёвые» достаточно субъективный показатель
поиск по слову node на доу выдал аж 2 результата — в Одессе и Харькове
ну все таки классы это не есть неотемлемое требование ооп. И если очень уж хочется, можно рассматривать директивы как классы
а в ангуляре нет ооп?
наверное, это только один из аргументов?
да уже все используют неймспейсы. вот те длинные названия — из старых фреймворков
уже достаточно давно есть неймспейсы
смотря что понимать под «вкуда»:)
когда-то открыл сайт yii, увидел «Yii::app()->», закрыл
не кормите троля:)
Ну вот инжектить как отдельную сущность может быть неверно с логической точки зрения. Например, часть не имеет смысла в отрыве от целого. Поэтому нужно поменять интерфейс агрегата, и где-то внутри делегировать части.
Тут вопрос в другом — инжектить ли внутреннюю часть агрегата.
Если да — агрегат перестает контролировать часть.
Поэтому правильный путь — менять интерфейс агрегата.
исчезнет только одна эта конкретная проблема (в контексте нашего обсуждения).
легковесные value обьекты и классы сервисыЭто на самом деле тема другого холивара
Агрегат — объект состоящий из других объектов и контролирующий изменения своих внутренностей.
Domain объекты это не только объекты-структуры или value-объекты, это могут быть объекты с достаточно сложными методами, которые нужно тестировать самостоятельно, и соответственно мокать в других тестах (чтобы не допустить хрупкости тестов).
Мокать нужно не те объекты, которые трудно создать, а те с которыми нужно протестировать взаимодействие (с очевидным исключением в вид value-objects и структур данных)
в коде просто не должно быть никогдатут дело не только в дисциплине написания кода.
ну а если, например, это был какой-то агрегат? Ты будешь инъектить его часть, а не самого? Если будешь — потеряешь возможность агрегата контролировать свое внутреннее состояние. Естественно, возвращение части тоже ошибка — на это четко укажут тесты.
И программа состоит не только из сервисов. Есть еще доменные объекты, в которых нарушение закона Деметры тоже очень возможны.
Дублирования в коде тоже не должно быть никогда. Но вся индустрия борется с этим и не очень-то успешно (если даже взять довольно качественный open-source код)
в моем подходе (tdd) такой класс в принципе не может возникнуть
Я тебе показал как может быть в DI мире — DI сам по себе ничего не гарантирует.
А теперь вопрос: ты все еще считаешь что тесты не влияют на дизайн при тдд?