А
проще это воспринимать как контракты, а не стены
Size: a a a
2020 February 26
DS
Стены служат для разграничения между комнатами. Если убрать из дома стены, и сложить их отдельном месте, то будет только одна комната в доме.
Стены - это в корне неверная аналогия.
А
а с позиции контрактов - не плохо их иметь отдельно, но, к примеру, с разбивкой на группы, как ранее замечал samdark
NO
Стены - это в корне неверная аналогия.
Кладезь аргументов...
DS
а с позиции контрактов - не плохо их иметь отдельно, но, к примеру, с разбивкой на группы, как ранее замечал samdark
Совершенно верно.
NO
Я раз за разом убеждаюсь, что правильное понимание роли интерфейсов в ООП, доступно мизерному числу разработчиков ( это печально
AM
Так... я не понял, каких именно классов интерфейсы?
AM
Про что речь?
AM
Что предлагаем?
DS
Что предлагаем?
Речь о контрактах. Если ты не хочешь чтобы эти пакеты юзались только для йии3, то неплохо было бы иметь контракты в отдельном пакете/пакетах.
АЖ
🤷♂️ тоже не пойму аналогию со стенами.
NO
Главная роль интерфейса, это не контракт, а обозначение архитектурных границ.
Суть контракта всегда заключается в его содержании. В зависимости от содержания контракт может быть полезным либо бесполезным.
Суть границы определяется её наличием и расположением. Свою пользу она приносит уже своим существованием. Разграничивая области взаимодействия компонентов, мы упрощаем высокоуровневую структуру приложения.
Интерфейс нужен в первую очередь для построения качественной абстракции, а уже второстепенная роль - использование во всяческих паттернах с наследованием.
Архитектура — это не только паттерны, но большинству разработчиков это неведомо (
Суть контракта всегда заключается в его содержании. В зависимости от содержания контракт может быть полезным либо бесполезным.
Суть границы определяется её наличием и расположением. Свою пользу она приносит уже своим существованием. Разграничивая области взаимодействия компонентов, мы упрощаем высокоуровневую структуру приложения.
Интерфейс нужен в первую очередь для построения качественной абстракции, а уже второстепенная роль - использование во всяческих паттернах с наследованием.
Архитектура — это не только паттерны, но большинству разработчиков это неведомо (
AM
Речь о контрактах. Если ты не хочешь чтобы эти пакеты юзались только для йии3, то неплохо было бы иметь контракты в отдельном пакете/пакетах.
Про какой именно пакет речь?
NO
Если вынести интерфейсы в отдельный пакет, это будет полный пипец для абстракции.
NO
Если кратко )
AM
Если вынести интерфейсы в отдельный пакет, это будет полный пипец для абстракции.
Если все в один - да.
NO
Слава богу кто-то меня понимает )
А
Главная роль интерфейса, это не контракт, а обозначение архитектурных границ.
Суть контракта всегда заключается в его содержании. В зависимости от содержания контракт может быть полезным либо бесполезным.
Суть границы определяется её наличием и расположением. Свою пользу она приносит уже своим существованием. Разграничивая области взаимодействия компонентов, мы упрощаем высокоуровневую структуру приложения.
Интерфейс нужен в первую очередь для построения качественной абстракции, а уже второстепенная роль - использование во всяческих паттернах с наследованием.
Архитектура — это не только паттерны, но большинству разработчиков это неведомо (
Суть контракта всегда заключается в его содержании. В зависимости от содержания контракт может быть полезным либо бесполезным.
Суть границы определяется её наличием и расположением. Свою пользу она приносит уже своим существованием. Разграничивая области взаимодействия компонентов, мы упрощаем высокоуровневую структуру приложения.
Интерфейс нужен в первую очередь для построения качественной абстракции, а уже второстепенная роль - использование во всяческих паттернах с наследованием.
Архитектура — это не только паттерны, но большинству разработчиков это неведомо (
почему контракт не может разграничивать области взаимодействия компонентов?
AM
Может и разграничивает.
А
я о том, что понимание интерфейса как контракта не мешает утверждать тоже самое