Единственно понимаю, что они нужны когда ты пишешь какой то класс, с которым могут работать внешние клиенты. тогда да. Надо чтобы они могли только вызывать задокументированные методы. Чтобы не могли что-то изменить по своему усмотрению.
А вот когда проект внутренний. Когда есть в них необходимость?
Можно простой пример, который будет понятен?
Здравствуйте, Аноним, Вы писали:
А>Единственно понимаю, что они нужны когда ты пишешь какой то класс, с которым могут работать внешние клиенты. тогда да. Надо чтобы они могли только вызывать задокументированные методы. Чтобы не могли что-то изменить по своему усмотрению.
А>А вот когда проект внутренний. Когда есть в них необходимость? А>Можно простой пример, который будет понятен?
А какая разница? Если проект внутренний то клиентом является ты сам. И то как ты спроектируешь все будет напрямую отражаться на поддержке и удобстве использования...
Если говорить конкретно про дотнет, то интерфейсы — это способ явно описать контракт кода и отделить его (контракт) от реализации. Всё остальное — возможность смены реализации, возможность передавать интерфейсы в код на других языках, использование интерфейсов для описания сетевых сервисов — это уже следствия.
Плюсы интерфейсов: у вас появляется переиспользуемый жёстко задокументированный контракт и возможность заменить одну реализацию другой, не заботясь о том, что что-либо поломается.
Минусы: у вас появляется жёстко задокументированный контракт Во-первых, это дополнительный слой кода, который нужно сопровождать и поддерживать, причём стоимость его изменения выше стоимости исправления "обычных" классов. Во-вторых, нередко этот слой оказывается лишним. По крайней мере, до тех пор, пока в проекте нет реальной необходимости иметь полностью взаимозаменяемые реализации одного и того же поведения. Когда такая необходимость есть — к использованию интерфейсов (или наследования) приходят сами собой и ничего обосновывать не надо
Если посмотреть на BCL, то в ней интерфейсы практически не используются, за редкими удачными исключениями — IEnumerable/IComparer/IFormatable etc. Все они описывают минимально необходимый API для конкретного сценария использования. Чуть более "универсальные" интерфейсы, например IList/IDictionary etc заметно сложнее, в них торчат хвосты от предыдущих версий фреймворка. Не, серьёзно — кто использует dictionary.SyncRoot или list.IsReadOnly?
Всё что сложнее — это уже не интерфейсы, а базовые классы. Вот тут
ув. Sinclair привёл очень хороший пример с наследованием от TextReader. Попробуйте придумать интерфейсы для Stream, TraceListener, xml-документа — неизбежно получится или интерфейс, дублирующий нюансы конкретной реализации, или сборник мелких интерфейсов, которые, опять-таки, проще реализовать в базовом классе, чем реализовывать их раз за разом в отдельных наследниках.
Отдельная тема — тестирование. Лично я к "интерфейсы нужны для беспроблемного тестирования" отношусь очень скептически.
Во-первых, ради решения одной задачи (причём не имеющей никакого отношения к предметной области софта) создаются проблемы для всего остального кода.
Во-вторых, для тестирования вовсе необязателен перевод всего на интерфейсы. Эту же задачу решают наследование от всё тех же базовых классов, или мок-фреймворки аля moles/MS fakes.
В-третьих, такое тестирование слоёв находит очень узкий круг проблем — снизу подпирают простые юнит-тесты и ассерты, сверху — интеграционное тестирование и всё те же ассерты.
Конечно, стоит ли связываться с интерфейсами чисто ради тестируемости кода или нет — зависит от конкретного проекта, но в общем случае — я резко против
А>Когда есть в них необходимость? А>Можно простой пример, который будет понятен?
Когда начинаешь писать тесты на свой код и в тестах надо подменить одну реализацию другой.
Например когда у тебя класс работает с базой а в тесте по какой то причине надо его подменить что блы например вернуть результат не из базы а тот что тебе нужен в тесте.
Веб сервисы, различные дефайсы, файлы всё в ту же оперу. Если в тестах надо эмулировать их поведение то единственный кошерный способ это использование IoC & DI принципов
Вообще применение DI даёт намного больше.
1.
Один из самых больших плюсов, который почему то мало обсуждают это явный контроль над зависимостями.
Открывая класс (конструктор) ты сразу видишь и понимаешь от чего зависит твой класс.
2.
Применяя IoC & DI и желательно контейнер твой код становится бесплатно расширяем. Ибо любую реализацию можно поменять извне.
3.
Написание тестов становится на порядки проще, ибо опять же любую реализацию любого класса можно заменить
Итд итп
Народная мудрось
всем все никому ничего(с).
Re[2]: Необходимость интерфейсов
От:
Аноним
Дата:
16.12.13 17:42
Оценка:
Здравствуйте, Tom, Вы писали:
Tom>2. Tom>Применяя IoC & DI и желательно контейнер твой код становится бесплатно расширяем. Ибо любую реализацию можно поменять извне.
нифига вот непросто подсунуть HttpContext в тестах.
asp.net mvc
Здравствуйте, Tom, Вы писали:
Tom>Если в тестах надо эмулировать их поведение то единственный кошерный способ это использование IoC & DI принципов
Уважаемый, не говорите ерунды. Единственный кошерный способ (и тебе об этом уже не раз говорили) это чистая функция — принимаем всё как параметры, возвращаем всё как возвращаемое значение, работаем без артефактов и побочных эффектов, не используем глобальный контекст.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IncremenTop, Вы писали:
IT>>Единственный кошерный способ (и тебе об этом уже не раз говорили) это чистая функция IT>Это первый признак говнокода, если речь об ОО-языке.
А это первый признак зашоренности мышления, идолопоклонничества и восприятия мира через замочную скважину. Открой двери, станет лучше видно. ОО здесь вообще по боку.
Если нам не помогут, то мы тоже никого не пощадим.
IT>>Единственный кошерный способ (и тебе об этом уже не раз говорили) это чистая функция
IT>Это первый признак говнокода, если речь об ОО-языке.
Есть Command-Query Separation Principle, но даже в нем Query является чистым, т.е. без побочных эффектов. Стало очень любопытно, с точки зрения чего или кого чистые функции стали говногодом в ОО-языке? ОО гуру вроде Мейера, вроде бы, так не считают; здравый смысл говорит, что чистая функция будет проще с точки зрения всех сложностей, поскольку все, что идет на вход и является результатом является очевидным!
Поддержу Игоря, чистые функции — это идеальный инструмент композиции, проверенные раз, чистые функции будут работать в любом контексте (да, другой вопрос, что чистые функции не всегда возможны, но где возможны, это лучший инструмент).
Здравствуйте, SergeyT., Вы писали:
ST>(да, другой вопрос, что чистые функции не всегда возможны, но где возможны, это лучший инструмент).
На самом деле чистую функцию вполне возможно воспринимать как паттерн. Также как в ОО-языках можно писать immutable код без специальной языковой поддержки, точно так же можно писать и чистый код без артефактов и использования глобального контекста. А внутренняя реализация такой "функции" вполне может использовать и даже базироваться на классах. Тут вопрос больше в мышлении, а не в ключевом слове "class". Но видимо у некоторых в голове это ключевое слово гвоздями прибито к облачкам Буча.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>единственный кошерный способ это использование IoC & DI принципов
Только у меня неприятие IoC-контейнеров? Мне кажется это какая-то мода, которая создаёт свои проблемы и без чего можно прекрасно обойтись. Особо меня пугает, что в некоторых книгах (например Pro ASP.NET MVC 4 by Adam Freeman (в целом книга неплохая)) применение IoC-контейнеров идет по умолчанию и преподносится как что-то само собой разумеещееся. Со мной что-то не так и мне надо лучше вникать в IoC-контейнеры или всё нормально? Хотелось бы мнения уважаемых опытных разработчиков.
Здравствуйте, MozgC, Вы писали: MC>мне надо лучше вникать в IoC-контейнеры?
Да, для начала прочитать части 1-3 этой книги: DI in .NET
MC>Хотелось бы мнения уважаемых опытных разработчиков.
Jimmy Bogard достаточно уважаем?
DI is about creating highly flexible components, both in lifecycle and component selection. DI removes component resolution responsibilities from classes, therefore removing code. And less code is ALWAYS a good thing.
Здравствуйте, SergeyT., Вы писали:
ST> здравый смысл говорит, что чистая функция будет проще с точки зрения всех сложностей, поскольку все, что идет на вход и является результатом является очевидным!
С точки зрения сложности, то функция в которой или для которой создается объект и работающая с ним без интерфейса — это ад и израиль. Это не гибко, не читаемо, трудно поддерживается.
ST>(да, другой вопрос, что чистые функции не всегда возможны, но где возможны, это лучший инструмент).
Вы про промышленный код или про гномиков?
Здравствуйте, MozgC, Вы писали:
MC>Особо меня пугает, что в некоторых книгах (например Pro ASP.NET MVC 4 by Adam Freeman (в целом книга неплохая)) применение IoC-контейнеров идет по умолчанию и преподносится как что-то само собой разумеещееся.
Коммерсанты Ему нужно продавать свои книжки. А кому нужен простой и понятный код без наворотов? А вот если туда пару паттернов вкрутить да по модней, до по раскрученней, то будет в самый раз.
Мне вся эта суета вокруг DI напоминает мою молодость, когда мы нереально пёрлись от косвенной адресации в целом и косвенных вызовов в частности, пока не поумнели и не стали их применять только по делу. Теперь молодёжь (местами запоздалая) нереально прётся от косвенности вызовов, но только уже через интерфейсы. Раз смог понять такой концепт, то жизнь вроде как удалась и можно считать себя крутым профиперцем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, MozgC, Вы писали:
MC>Только у меня неприятие IoC-контейнеров? Мне кажется это какая-то мода, которая создаёт свои проблемы и без чего можно прекрасно обойтись. Особо меня пугает, что в некоторых книгах (например Pro ASP.NET MVC 4 by Adam Freeman (в целом книга неплохая)) применение IoC-контейнеров идет по умолчанию и преподносится как что-то само собой разумеещееся. Со мной что-то не так и мне надо лучше вникать в IoC-контейнеры или всё нормально? Хотелось бы мнения уважаемых опытных разработчиков.
бОльшая часть продуктов MS написаны с использованием IoC контейнеров. Это очень мощная штука, но как и любая мощная штука она имеет свой порог вхождения и он достаточно высок. Отдельно надо понимать, что DI — это совсем другая штука, которая появилась не так давно и вот от нее уже на мой взгляд больше вреда, чем пользы. Самый лучший и простой IoC контейнер, который невозможно не понять называется IServiceProvider и лежит в простарнстве имен System
Здравствуйте, QrystaL, Вы писали:
IT>>пока не поумнели и не стали их применять только по делу. QL>Ну то же самое и с DI. В вышеозначенной книге есть глава по этому поводу — 1.3
Применение DI для тестирования — это уже не то же самое.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Tom, Вы писали:
Tom>>Если в тестах надо эмулировать их поведение то единственный кошерный способ это использование IoC & DI принципов
IT>Уважаемый, не говорите ерунды. Единственный кошерный способ (и тебе об этом уже не раз говорили) это чистая функция — принимаем всё как параметры, возвращаем всё как возвращаемое значение, работаем без артефактов и побочных эффектов, не используем глобальный контекст.
Давай на конкретных примерах.
Я пример как бы сделал я — ты пример как бы сделал ты.
Потом обсудим оба. так будет лучше чем чесание языка.
Накидал простейший пример, думаю коментарии не нужны.
Перереши его так как считаешь нужным:
public interface ISerialPort
{
byte ReadByte();
}
public class SerialPort : ISerialPort
{
public byte ReadByte()
{
return 1;
}
};
public interface IMessage
{
// ...
}
public interface IMessageParser
{
bool IsEom(byte b);
IMessage Parse(IEnumerable<byte> rawMessage);
}
public interface IMessageProcessor
{
void ProcessMessage(IMessage message);
}
public class MessageProcessor
{
public void ProcessMessage(IMessage message)
{
// E.g. save 2 database or trace to the file or anything
}
}
public interface ISerialPortProcessor
{
void ReadAndProcessLoop();
}
public class SerialPortProcessor : ISerialPortProcessor
{
private readonly ISerialPort _port;
private readonly IMessageParser _parser;
private readonly IMessageProcessor _processor;
public SerialPortProcessor(
ISerialPort port,
IMessageParser parser,
IMessageProcessor processor)
{
_port = port;
_parser = parser;
_processor = processor;
}
public void ReadAndProcessLoop()
{
var message = new List<byte>();
while (true)
{
var b = _port.ReadByte();
message.Add(b);
if (_parser.IsEom(b))
{
var parsedMessage = _parser.Parse(message);
_processor.ProcessMessage(parsedMessage);
}
}
}
}
Если нам не помогут, то мы тоже никого не пощадим.
Ему нужно продавать свои книжки. А кому нужен простой и понятный код без наворотов? А вот если туда пару паттернов вкрутить да по модней, до по раскрученней, то будет в самый раз.
