не зміниться, все одно реалізовуємо в класах поокремо й відбувається код репіт
Нє?
Це лише коли один клас-один інтерфейс. Так робити дійсно немає сенсу. Набагато краще один інтерфейс-три класа
Щось зміниться, а саме з'явиться прямий зв'язок між залежностями Інтерфейс це контракт, який гарантує реалізацію певних методів/властивостей без необхідності знання конкретних типів. Це дозволяє колись підмінити реалізацію без необхідності зміни коду, або використовувати паралельно декілька реалізацій в залежності від environment-а. У тебе може бути, наприклад, clean architecture, при якому на Infrastructure рівні твої реалізації інтерфейсів будуть internal, тобто не видні в інших збірках. І там же може бути метод розширення, який реєструє цей тип у DI.
навряд чи ти усвідомиш їх суть просто по коментам, з такими речами треба раз сісти й розібратись, а щоб розібратись і зрозуміти чому вони всюди юзаються, глянь що таке поліморфізм, а потім патерн проектування стратегія і які проблеми він вирішує, він досить простий якщо розглядати з прикладами
Ну я сидю, розписав інтерфейс і реалізації, а він курва не може навіть виконати роль абстрактного класу, тупо мотивашка дописати методи які запланував бо не скомпілює
взагалі "взаємодія на рівні інтерфейсів" — концепція, яку можна зрозуміти на прикладах з реального життя це як контракт: якщо я відкрию кран, вода потече. мені не потрібно знати тонкощів реалізації (який там смеситель, як прокладені труби і все таке) інтерфейс каже: якщо відкрити кран, вода буде текти. якщо закрити кран, вода перестане текти. цей інтерфейс можна накладати на будь-який кран: вентельний, одноричажний чи сенсорний. коли пишуть код, всередині класів використовуються нестрогі залежності. що це означає? замість того, щоб використовувати якийсь тип Service, ми описуємо тип IService (інтерфейс). Зазвичай це потрібно для того, щоб можна було підставити будь-яку реалізацію інтерфейсу. це не зламає код, який використовує цей IService, адже інтерфейс той самий (як у прикладі з краном: вода тече, якщо кран відкритий, навіть якщо замінили смеситель або труби). Ми надіємось лише на "угоду", нам не цікава реалізація. зазвичай інтерфейс описує якусь одну поведінку. наприклад, якщо клас можна порівнювати, його роблять IComparable. Це означає, що в ньому буде реалізований метод CompareTo. якщо клас може бути утилізований, то він реалізовує IDisposable. І так далі. потім можна використовувати клас як інтерфейс, щоб обмежити доступ до функціоналу класу (ми надаємо доступ лише до того, що потрібно). це interface segregation principle в solid (буква І)
Мені більше подобається приклад з розеткою як контрактом. А коли з аварійних причин в мережі подають підвищену напругу і у вас ломається холодильник - вітаємо, ви познайомилися з leaky абстракцією :)
Дуже перегукується з декларативною парадигмою функціонального програмування)) Всі юзають інтерфейс отже він потрібний ефективний і треба його понять, але він вміє ще щось крім опису й гарантування наявності методів?
якщо не розумієш навіщо він - не юзай. коли дозрієш прийде розуміння. на проектах типу "хелло ворд" він дійсно "навіщо козі баян"
Ну так от него больше и не надо
Обсуждают сегодня