A
всякие Contracts, Interfaces - это от неумения в ООП
Size: a a a
2020 February 17
ИЛ
A
Если модели лежат в App/Models - можешь пока прям туда и положить. А если у тебя эти модели гдето в особенной папке лежат. где все связанное с продажами, то идеально туда.
A
ты еще скажи LoggerInterface - это хорошее название класса :)
ИЛ
и?
Откуда брать идеалы того, каким должен быть код? Проще всего просто посмотреть на то, как написаны используемые тобою библиотеки. И под невероятными рассказами о крутой и немагичной симфе ты идёшь смотреть в её репозиторий, и находишь контракты, которые либы используют при резолве зависимостей, и тоже начинаешь так делать
A
ну сами контракты то нормально... плохо что лежат они обособленно. не должны интерфейсы, абстрактные классы как-то сильно выделяться от обычных.
ИЛ
ну сами контракты то нормально... плохо что лежат они обособленно. не должны интерфейсы, абстрактные классы как-то сильно выделяться от обычных.
Можно пример?
A
Позволю себе смелость процитировать себя:
ИЛ
все равно классы это или интерфейсы
ИЛ
ИЛ
Разработчику нужно ещё не допустить ошибку при резолве
ИЛ
И не перепутать контракт с concrete классом
A
он их не резолвит
ИЛ
он их не резолвит
Он их указывает в конструкторе
A
он просит Storage
A
а если он попросит S3Storage - то наверно задумается немного, не?
ИЛ
App\Contracts\Storage\Managerпрекрасно даёт понимание того, что мы используем контракт, и можем быть уверенны, что в любой момент можем заменить реализацию
ИЛ
Где быть контрактам, чтобы их можно было удобно использовать?