Что выносить в интерфейс, а что оставлять в классе? Критерии?

Интерфейс - способ одинаково взаимодействовать с объектами различной "природы" (классами). Класс состоит из описаний своих состояний (свойства) и механизмов их изменения (методы). Опыта в проектировании классов нет, поэтому кажется, что в интерфейсы можно вынести чуть ли не все механизмы (двигаться, прыгать, ударить и т.п.), оставив в классах только состояния. Как при проетировании какого-либо класса определить, вынести его метод в интерфейс или оставить в классе? На мой взгляд задача усложняется, если язык нас не ограничивает в множественном наследовании.
Единственный критерий при проектировании, на мой взгляд, это будет ли где-нибудь в коде цикл перебора объектов различных классов с передачей им одинакового воздействия. Например, солдат, машина, часть дом попадают под взрыв гранаты. И всем нужно передать набор параметров взрыва, чтобы они рассчитали свои повреждения. Опять же включается стопор, если будет несколько объектов, у которых может быть общий предок - тогда можно пользоваться наследованием, а не интерфейсами.

в терминах какого языка изложенное выше? если речь про раздельное хранение объявления класса и его реализации в с++, то в хидеры следует выносить реализацию методов которые содержат всего несколько инструкций, чтобы компилятор мог заинлайнить их.

cranky
> в терминах какого языка изложенное выше?

Delphi. Сразу понятно по фразе:

loonypy
> Опять же включается стопор

Ясно понятно - дельфи!

=A=L=X=
1С!
Вопрос без привязки к конкретному языку - в общем навыке проектирования классов.

cranky
> если речь про раздельное хранение объявления класса и его реализации в с++
Нет, я про Interface vs inheritance.

имхо проектировать сначала на бумаге, а там видно будет

из разумных соображений... из самого понятия, назначения интерфейса...

loonypy
по стилю изложения чувствуется, что привязка к конкретному языку имеет место быть, если я правильно понял вопрос, попробую ответить выражаясь в терминах с++. существует наследование от обычного и от абстрактного класса, в первом случае потомок наследует интерфейс и реализацию родителя, которую он может перекрыть, во втором только интерфейс, для которого он должен иметь свою собственную реализацию. в с++ имеется возможность комбинировать наследование от обычного и абстрактного класса используя виртуальные функции, чисто виртуальные функции и обычные методы.

Интерфейс выражает роль.
Не класс нуна делать а потом думать что выносить в интерфейс, а создавать интерфейс, чтобы его методов и свойств было достаточно для взаимодействия с ролью. Можно даже написать програмку где будут одни интерфейсы. А вот только потом реализовывать, причем один класс может реализовывать несколько ролей.

my.name
Вот как раз программирование от интерфейсов - самая большая беда для ООП как парадигмы

pr0gl
> Вот как раз программирование от интерфейсов - самая большая беда для ООП как
> парадигмы
не стоит связывать интерфейс и ооп, это не связаные вещи. Интерфейс это роль, она не подразумевает наследование или частиную реализации (абстрактность). Интерфейсы можно юзать безз ооп. Например когда класс реализует две несвязаные роли, это не ооп воопсче, это больше подходит на композицию (агрегацию) чем на наследование. А вот конек ооп это как раз иерархия классов, каждый из которых решает роль в той или иной полноте.

например в наших проектах нет ооп, но больше половины компонентов реализуют интерфейсы

my.name
Я просто имел ввиду что в контексте ООП программирование сверху-вниз чревато неисправимыми ошибками, вот и всё.

>например в наших проектах нет ооп
Кстати, ООП != полиморфизм + инкапсуляция + наследование. Если вы оперируете данными в связке со специальными функциями, определяющими способы работы с этими данными (методами), то вы, можно сказать, пишете объектно-ориентированно. Если всё-таки нет, в какой парадигме работаете? Мне интересно.

Интерфейс описывает "что может делать объект". Реализация описывает как он это делает.

to pr0gl

мы не пишем объектно ориентированно, мы пишем компонентно ориентированно или аспектно ориентированно (правда каждый понимает это по своему).
Системы это отношения ролей.
Вся система это компоненты предоставляющие сервисы и\ или использующие их.

Что похожее на COM.

zlos
> Интерфейс описывает "что может делать объект". Реализация описывает как он это
> делает.

Прокси и заглушка не описывает как он это делает =)