либы специально для их мокирования?
2. Я объяснял тебе сообщением выше, там всё доступно и понятно
Тот же пхп юнит не умеет так делать и нужно тянуть Mockery
А пхп юнит не сторонняя либа?
Сторонняя, но зачем тянуть ещё одну?
А проблема-то в чём? У тебя зависимости платные?
Пиздят за каждый composer require
В том, что все проблемы решаются лишь отсутствием статик методов в коде и правильной инкапсуляцией
Сторонние инструменты могут заставлять тебя писать код по другому, если это делает сам код действительно лучше, в иных случаях об этом даже думать не стоит!
На счёт делают ли статик методы код лучше, всё зависит от того, с какой стороны смотреть на код и ООП
Всё верно. И здесь лучше выбрать правильную сторону. Если метод не использует контекст, то зачем делать его частью инстанца? На худой конец, можно вывести его в отдельный хелпер.
Чтобы не делать код процедурным. ООП про объекты и их взаимодействие.
Так а разница в чём? Какой профит получит код, если он будет на все 100% (но это не про пхп) ООП? Есть определённые вещи, которые выпадают из цепочки ООП и это неизбежно и это нормально.
тогда надо и скалярные типы в объекты перевести, а то не по канону получается
Упрощает код и его поддержку
Возможно, выпадение из ООП обусловлено желанием сделать как удобно, а не как нужно
В пхп конечно так не получится) Но в той же джаве вполне
Чем именно? Тем, что у тебя в классе 100 методов и чтобы тебе понять, что 50 методов являются чистыми, тебе нужно их изучить. Этим? Не знаю, какие книжки ты читаешь, но лучше растопи ими дом!
в джаве как и в пхп получится обертка над скалярным типом
Зачем понимать что они чистые? Тебе даже не нужно их содержимое смотреть, если код хороший
А электроны в процессоре вообще не объекты)
вот и получается что парадигма ооп не соблюдается
Обсуждают сегодня