Думайте об интерфейсе как о контракте для определения семантики или концепции. Это общий подход, а не конкретный язык. В контексте ОО, если вы работаете в модели с единым наследованием, есть отличный пример предпочтения интерфейсов, а не классов, для определения вашей объектной модели, поскольку этот единственный путь суперкласса довольно полезен, и вы хотите сохранить его для нечто более «существенное», чем определение свойств объекта или методов.
Наличие семантики IContainer (контракта) является довольно плохой причиной для создания интерфейса из вашей папки; лучше, чтобы ваша папка (если она выполняет какую-то нетривиальную логику) «внедрила» (вероятно, уже существующий) интерфейс IContainer или ICollection в базовые структуры вашего языка.
Как всегда, лучший выбор в значительной степени зависит от конкретной проблемы. В случае ваших рецептов, которые также являются папками (?!), Вы, вероятно, думаете о родительско-дочерних или композиционных отношениях - семантике, которая может (и должна) быть выражена с помощью интерфейсов, если в вашей системе будут другие элементы «оперировать» вещами, составленными с использованием такой семантики.
Существуют некоторые накладные расходы (с точки зрения программирования) с интерфейсами, и, если вы окажетесь, когда закончите с не более чем набором классов и интерфейсов Woof и IWoof, то вы будете знать, что, вероятно, не нужно выразить вашу проблему в терминах интерфейсов - простых классов было бы достаточно.
Как правило, для любого I у вас должно быть хотя бы пара конкретных классов (с более значимыми именами, кроме IImpl или).
Надеюсь, это поможет.