Ну значит классы делает нечто похожее. Значит это похожее можно выделить в отдельный класс, потому что это уже что-то другое, не относящееся к тем двум
Или в трейты чтобы просто подключить и юзать сразу через this
1) неудобно тестировать. Вместо подачи фейкового контракта придётся мокать это дело. 2) Т.е. в одном классе мы генерируем хмл и тудаже тащим методы репозитория (условно) для поиска контракта? Ну блин 🙂
1) неудобно тестировать. Вместо подачи фейкового контракта придётся мокать это дело. 2) Т.е. в одном классе мы генерируем хмл и тудаже тащим методы репозитория (условно) для поиска контракта? Ну блин 🙂
а если в проекте не используется тестирование и не будет использоваться?
1) неудобно тестировать. Вместо подачи фейкового контракта придётся мокать это дело. 2) Т.е. в одном классе мы генерируем хмл и тудаже тащим методы репозитория (условно) для поиска контракта? Ну блин 🙂
а если в проекте не используется тестирование и не будет использоваться?
удобство тестирование почти автоматически означает слабую зависимость от других классов, а значит простую модульную архитектуру, в которой нет лапшекода
всё просто. все эти солиды и граспы придуманы не для усложнения простого кода, а для упрощения сложного. Если у вас три класса в проекте, ради бога, трейты шмейты. Но если проект большой, вы там просто закопаетесь )
удобство тестирование почти автоматически означает слабую зависимость от других классов, а значит простую модульную архитектуру, в которой нет лапшекода
удобство тестирование почти автоматически означает слабую зависимость от других классов, а значит простую модульную архитектуру, в которой нет лапшекода
Когда проект небольшой и клиент не овер богатый и программист всего один, все это красиво но ведёт к х2 цене проекта и потере клиента
я бы импортировал в di контракт, и внутри дёрнул метод getContractNumber или для чего он там нужен. Или даже сразу этот номер в конструктор передал. И тогда классу вообще пофиг куда и как этот метод сходил что бы получить эти данные