Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию?
Когда имеется несколько реализация — понятно, интерфейс обычно выделяют.
Но если реализация только одна, для каких классов выделяете интерфейсы, а для каких нет?
P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык.
Б>Когда имеется несколько реализация — понятно, интерфейс обычно выделяют. Б>Но если реализация только одна, для каких классов выделяете интерфейсы, а для каких нет?
Выделяется при любом взаимодействии двух и более классов, ибо тесты.
Б>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык.
Здравствуйте, Буравчик, Вы писали:
Б>Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию?
KISS же. Язык Java. Интерфейс создаю только когда без него никак. IDEA умеет рефакторинг "выделить интерфейс", так что нет никакой проблемы добавить когда реально понадобится.
Тест-фреймворк позволяет мокать любой класс.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Буравчик, Вы писали:
Б>Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию?
Б>Когда имеется несколько реализация — понятно, интерфейс обычно выделяют. Б>Но если реализация только одна, для каких классов выделяете интерфейсы, а для каких нет?
Б>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык.
От языка сильно зависит. В том же C++ не выделяю интерфейсы до тех пор, пока без этого никак нельзя, т.е. крайне редко, так как довольно часто можно обойтись статическим полиморфизмом вместо динамического.
В случае с Python и того реже есть такая необходимость, благодаря динамической типизации, хотя если хочется точно указать какие методы должны быть реализованы, то abc наш лучший друг и соратник.
В Go ситуация диаметрально противоположная, там сам язык тебя подталкивает к тому, что бы как можно чаще выделять минимальные интерфейсы. Так что на Go интерфейсов всегда много и они выполняют строго одну задачу.
C++
Я стараюсь писать классы так, чтоб H и CPP файл можно было просто взять и воткнуть в любой другой проект. Конечно, не всегда это возможно, но стараюсь.
Так вот, когда вижу, что класс полезный и стопроцентно пригодится в другом месте, но при этом у него есть взаимодействие с другими классами, то это взаимодействие определяю через интерфейсы.
Так же не обойтись без интерфейсов в плагинной системе.
Так же делегаты и коллбеки оборачиваю в интерфейсы.
Здравствуйте, Буравчик, Вы писали:
Б>Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию? Б>Когда имеется несколько реализация — понятно, интерфейс обычно выделяют. Б>Но если реализация только одна, для каких классов выделяете интерфейсы, а для каких нет? Б>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык.
.net core, С#. Стал с недавнего времени использовать DI, а там без интерфейсов практически никуда.
Здравствуйте, kaa.python, Вы писали:
KP>В случае с Python и того реже есть такая необходимость, благодаря динамической типизации, хотя если хочется точно указать какие методы должны быть реализованы, то abc наш лучший друг и соратник.
Я пишу на python. Тестировать можно и без интерфейсов, но руки все равно тянутся выделять интерфейсы, чтобы явно выделить контракт сервиса и развязать компоненты между собой (DI). И каждый раз, когда я создаю интерфейс, меня терзают мысли об overdesign Ведь это совсем не python-way
Здравствуйте, ·, Вы писали:
·>KISS же. Язык Java. Интерфейс создаю только когда без него никак. IDEA умеет рефакторинг "выделить интерфейс", так что нет никакой проблемы добавить когда реально понадобится.
В каких случаях добавляешь интерфейсы? Как отличить ситуацию, когда "без интерфейса никак" и когда "без интерфейса норм"?
Здравствуйте, Sharov, Вы писали:
Б>>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык. S>.net core, С#. Стал с недавнего времени использовать DI, а там без интерфейсов практически никуда.
А зачем для DI интерфейсы? Это специфика C# что-ли?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Буравчик, Вы писали:
Б>·>KISS же. Язык Java. Интерфейс создаю только когда без него никак. IDEA умеет рефакторинг "выделить интерфейс", так что нет никакой проблемы добавить когда реально понадобится. Б>В каких случаях добавляешь интерфейсы? Как отличить ситуацию, когда "без интерфейса никак" и когда "без интерфейса норм"?
В подавляющем большинстве случаев это когда более одной реализации.
Ещё иногда для выделения API между разными модулями (но это в каком-то смысле то же самое). Например, можно начать писать код, выделяя что-то в интерфейсы, мОкая их в тестах. А потом интерфейсы реализуется кем-то другим.
Другие случаи что-то в голову сейчас не приходят, вспомню — напишу.
Публичные методы класса это и есть интерфейс по сути.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Sharov, Вы писали:
Б>>>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык. S>>.net core, С#. Стал с недавнего времени использовать DI, а там без интерфейсов практически никуда. ·>А зачем для DI интерфейсы? Это специфика C# что-ли?
1)необязательно, типа признака хорошего тона. Еще и буковка D в SOLID.
2)как иначе изменить реализацию через какой-нибудь конфиг файл?
Здравствуйте, Sharov, Вы писали:
S>>>.net core, С#. Стал с недавнего времени использовать DI, а там без интерфейсов практически никуда. S>·>А зачем для DI интерфейсы? Это специфика C# что-ли? S>1)необязательно, типа признака хорошего тона.
Культ Карго, иначе говоря.
S>Еще и буковка D в SOLID.
KISS über allen. Если классы в разных модулях это ещё имеет смысл. Но когда у тебя каждый класс продублирован интерфейсом, то просто мусорный код, который только мешается.
S>2)как иначе изменить реализацию через какой-нибудь конфиг файл?
Если реализацию можно изменить, значит у тебя несколько реализаций. Этот случай, вроде, не рассматриваем. Тут, ясен пень, интерфейс нужен.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Буравчик, Вы писали:
Б>Я пишу на python. Тестировать можно и без интерфейсов, но руки все равно тянутся выделять интерфейсы, чтобы явно выделить контракт сервиса и развязать компоненты между собой (DI). И каждый раз, когда я создаю интерфейс, меня терзают мысли об overdesign Ведь это совсем не python-way
Предполагаю, что желание выделять интерфейсы — обусловлено тем, что язык не имеет возможности разделить контракт от реализации (наподобии хидеров в C++), и когда реализация распухает — становится тяжело прочитать натуральным образом этот самый контракт. С этим могут помочь всяческие тулзы, редакторы, внешняя документация, но по моему мнению они сильно проигрывают простому файлу и в большинстве случаев не имеют необходимого функционала.
Используя C# хочется иногда вводить подобные интерфейсы, но приходится себя останавливать, т.к. в нем это инструмент для разрешения иных задач. Поэтому без необходимости не ввожу. Например, если, я сделаю struct (value-type) которая реализует интерфейс — это с одной удовлетворит мои желания, а с другой может провоцировать пользователей передавать их именно через интерфейс (что приведет к боксингу) — что аннигилирует саму цель её существования. Ну, в более стандартных ситуациях это все равно выливается в лишний шум.
Здравствуйте, Буравчик, Вы писали:
Б>Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию?
Java/Scala
Еще две причины:
— Тестирование. тестовую реализацию интерфейса можно заимплементить, не сваязываясь с фреймворками для моков.
— Оформление кода. отдельный интерфейс с джавадоком — это удобная документация для программиста, не загроможденная реализацией.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Sharov, Вы писали:
Б>>>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык. S>>.net core, С#. Стал с недавнего времени использовать DI, а там без интерфейсов практически никуда. ·>А зачем для DI интерфейсы? Это специфика C# что-ли?
Хотелось бы посмотреть на DI без интерфейсов в случае юнит-тестов на С++.
Здравствуйте, a7d3, Вы писали:
Б>>>>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык. S>>>.net core, С#. Стал с недавнего времени использовать DI, а там без интерфейсов практически никуда. A>·>А зачем для DI интерфейсы? Это специфика C# что-ли? A>Хотелось бы посмотреть на DI без интерфейсов в случае юнит-тестов на С++.
Во-первых, в С++ нет интерфейсов. Так что не очень понятно что конкретно ты имеешь в виду.
Во-вторых, класс с вирт-функциями мокается ровно же как и в Java/C#, без всяких интерфейсов. Или ты конструктор имеешь в виду?
В-третьих, другие опции есть, шаблоны там, препроцессор, подмена .cpp системой сборки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
A>>·>А зачем для DI интерфейсы? Это специфика C# что-ли? A>>Хотелось бы посмотреть на DI без интерфейсов в случае юнит-тестов на С++. ·>Во-первых, в С++ нет интерфейсов. Так что не очень понятно что конкретно ты имеешь в виду.
В каком плане в С++ нет интерфейсов?
И что именно понимается под интерфейсами, которые якобы не нужны в DI?
Здравствуйте, a7d3, Вы писали:
A>>>·>А зачем для DI интерфейсы? Это специфика C# что-ли? A>>>Хотелось бы посмотреть на DI без интерфейсов в случае юнит-тестов на С++. A>·>Во-первых, в С++ нет интерфейсов. Так что не очень понятно что конкретно ты имеешь в виду. A>В каком плане в С++ нет интерфейсов?
В языке такого понятия нет.
A>И что именно понимается под интерфейсами, которые якобы не нужны в DI?
Ищем в гугле "di c# example", первая ссылка вот. Там interface ICustomerDataAccess не нужен, и даже немножко вреден.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, a7d3, Вы писали:
A>>>>·>А зачем для DI интерфейсы? Это специфика C# что-ли? A>>>>Хотелось бы посмотреть на DI без интерфейсов в случае юнит-тестов на С++. A>>·>Во-первых, в С++ нет интерфейсов. Так что не очень понятно что конкретно ты имеешь в виду. A>>В каком плане в С++ нет интерфейсов? ·>В языке такого понятия нет.
Ведь это совсем не python-way
