Телеграмм чат группы prophp7 страница 10768

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

источник

13:08пожаловаться #3

АГ

Алексей Гевондян... in PHP

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

а потом в один прекрасный момент ты обнаружишь, что тебе надо поддерживать зоопарк версий и в каждой из версий еще и зоопарк классов

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

источник

13:24пожаловаться #5

Sergey Protko in PHP

ну и как бы "старые версии" всегда можно заменить на адаптеры

источник

13:25пожаловаться #6

Nex Otaku in PHP

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

источник

13:25пожаловаться #7

Sergey Protko in PHP

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

источник

13:26пожаловаться #8

Sergey Protko in PHP

мол надо выветси примерно то же самое + еще пара полей - добавляем поля в общую структуру и юзаем и там и там

источник

13:26пожаловаться #9

Nex Otaku in PHP

При желании их можно ещë и тестами покрыть, защититься от сюрпризов

источник

13:26пожаловаться #10

Sergey Protko in PHP

люди панически боятся дублирования кода

источник

13:26пожаловаться #11

Sergey Protko in PHP

а вот связанности не боятся

источник

13:26пожаловаться #12

АГ

Алексей Гевондян... in PHP

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

источник

13:28пожаловаться #13

АГ

Алексей Гевондян... in PHP

надо использовать стат анализаторы, они эти проблемы должны выявлять.

источник

13:29пожаловаться #14

Sergey in PHP

Sergey Protko

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

источник

14:30пожаловаться #15

Aleh Kashnikau in PHP

Sergey Protko

ты ж не мокаешь datetime

Datetime кстати исключение в случаях, когда берется "текущее время системы". Если такого нет, то мокать действительно обычно не надо.

источник

15:46пожаловаться #16

Sergey Protko in PHP

Aleh Kashnikau

Ммм... Что ты мокать собрался, объект же этот больше про точку во времени а не часы

источник

15:50пожаловаться #17

Sergey Protko in PHP

Так что нет, не исключение

источник

15:50пожаловаться #18

Sergey Protko in PHP

Вообще лучше избегать получения времени внутри

источник

15:50пожаловаться #19

Aleh Kashnikau in PHP

Sergey Protko

Ммм... Что ты мокать собрался, объект же этот больше про точку во времени а не часы

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

источник

15:51пожаловаться #20