AS
А еще - более выгодные чем в Турции
Size: a a a
2021 March 11
AS
А еще более выгодные чем в Испании
AS
и так далее, ну вы поняли
AS
OP
Привіт. В аплікусі є модулі. В декількох модулях є однакові/схожі класи. Також в vendor є спеціально зроблений пакет в який додається спільний для модулів функціонал.
Створюю там один клас, щоб використовувати в модулях замість тих однакових, про які говорив спочатку (щоб не було дублікатів).
Питання - як бути з залежностями цих класів? В них юзаються класи з інших модулів і пакунків з vendor.
Створюю там один клас, щоб використовувати в модулях замість тих однакових, про які говорив спочатку (щоб не було дублікатів).
Питання - як бути з залежностями цих класів? В них юзаються класи з інших модулів і пакунків з vendor.
AS
Спагетти получается
AS
типо module/A and module/B using vendor/C and vendor/C using module/D
AS
если я правильно понял
Z
Створити контракти в проекті і всі модулі щоб мали доступ до інших модулів через контракт
OP
если я правильно понял
То я трохи незрозуміло пояснив
MW
коллеги. прошу совета )
имеется модель. регион (напр москва, питер, калининград)
у этой модели есть поле - is_required_address
в коде, в сотнях мест используется. что еще более усложняет, так это то, что там идет доступ напрямую к полю, без аксессора, т.е. $region-> is_required_address
задача сейчас, сделать так, чтобы часть пользователей получала в этом поле false в любом случае (это для а/б тестирования нового поведения)
и вот что то нет идей как так переопределить поле
имеется модель. регион (напр москва, питер, калининград)
у этой модели есть поле - is_required_address
в коде, в сотнях мест используется. что еще более усложняет, так это то, что там идет доступ напрямую к полю, без аксессора, т.е. $region-> is_required_address
задача сейчас, сделать так, чтобы часть пользователей получала в этом поле false в любом случае (это для а/б тестирования нового поведения)
и вот что то нет идей как так переопределить поле
OP
Всім дякую, вже розібрався)
S
коллеги. прошу совета )
имеется модель. регион (напр москва, питер, калининград)
у этой модели есть поле - is_required_address
в коде, в сотнях мест используется. что еще более усложняет, так это то, что там идет доступ напрямую к полю, без аксессора, т.е. $region-> is_required_address
задача сейчас, сделать так, чтобы часть пользователей получала в этом поле false в любом случае (это для а/б тестирования нового поведения)
и вот что то нет идей как так переопределить поле
имеется модель. регион (напр москва, питер, калининград)
у этой модели есть поле - is_required_address
в коде, в сотнях мест используется. что еще более усложняет, так это то, что там идет доступ напрямую к полю, без аксессора, т.е. $region-> is_required_address
задача сейчас, сделать так, чтобы часть пользователей получала в этом поле false в любом случае (это для а/б тестирования нового поведения)
и вот что то нет идей как так переопределить поле
Вроді через аксесор можна
MW
можно. но в коде нигдще не используется. а пилить костыль в __get мне бы не хотелось
AS
Oleksandr Petrenko
Всім дякую, вже розібрався)
А как ты разобрался?
AS
ну можно еще найти все обращения и заменить на вызов гетера, и там выполнить нужный код
S
можно. но в коде нигдще не используется. а пилить костыль в __get мне бы не хотелось
Ну ти ж в коді юзаєш is_required_address
Якщо на нього аксесор напиляти, зможеш модифікувати значення, яке отримав з бази
Якщо я нічого не плутаю)
Якщо на нього аксесор напиляти, зможеш модифікувати значення, яке отримав з бази
Якщо я нічого не плутаю)
OP
А как ты разобрался?
Потрібно було змінити деякі залежності і їх інтерфейси і підставити їх в той узагальнений клас
AS
Oleksandr Petrenko
Потрібно було змінити деякі залежності і їх інтерфейси і підставити їх в той узагальнений клас
да, тут без кухоля Вятского кваса не разобраться
S
можно. но в коде нигдще не используется. а пилить костыль в __get мне бы не хотелось
