Здравствуйте, Буравчик, Вы писали:

Б>Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию?

Б>Когда имеется несколько реализация — понятно, интерфейс обычно выделяют.
Б>Но если реализация только одна, для каких классов выделяете интерфейсы, а для каких нет?

В тех случаях, когда может/должна появиться независимая реализация. Наличие интерфейса при одной-единственной реализации это, собственно, способ сказать читателю кода: «Появится другая, возможно, я знаю, какая, а возможно — имею об этом лишь смутное представление».

Важными считаю 2 момента:

1. Иногда реализация так и остаётся единственной. Например, библиотека умирает вместе с проектом, платформой etc. Но это НЕ означает автоматически overengineering, ведь фиксировать свои мысли об архитектуре надо по мере их появления, начиная с самой ранней версии. Overengineering'ом это может быть в каждом конкретном случае. Или не быть. Поэтому когда бараны кругом начинают блеять своё «YAGNI», надо требовать доказательств применительно к данному классу и данному интерфейсу. Общий случай не катит. Хотя в частном они могут оказаться правы.

	Скрытый текст
	Как вы понимаете, такой подход обесценивает YAGNI в принципе.

2. В каждом конкретном случае думать приходится творчески, к механическим правилам это свести невозможно. (Невозможно заложить правила проверки в static code analyser). Такой ответ, наверно, кого-то разочарует, но кого-то, наоборот, успокоит: у всех так, посоны.

Б>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык.

Зависит мало, на самом деле. 20 лет назад в плюсах дефайнили interface на class/struct и вперёд. Не для компилятора же мы это писали.

Здравствуйте, Буравчик, Вы писали:

Б>Чем руководствуетесь, принимая решение выделять или не выделять интерфейс из класса, т.е. нужно ли разделить интерфейс и реализацию?

Б>Когда имеется несколько реализация — понятно, интерфейс обычно выделяют.
Б>Но если реализация только одна, для каких классов выделяете интерфейсы, а для каких нет?

В тех случаях, когда может/должна появиться независимая реализация. Наличие интерфейса при одной-единственной реализации это, собственно, способ сказать читателю кода: «Появится другая, возможно, я знаю, какая, а возможно — имею об этом лишь смутное представление».

Важными считаю 2 момента:

1. Иногда реализация так и остаётся единственной. Например, библиотека умирает вместе с проектом, платформой etc. Но это НЕ означает автоматически overengineering, ведь фиксировать свои мысли об архитектуре надо по мере их появления, начиная с самой ранней версии. Overengineering'ом это может быть в каждом конкретном случае. Или не быть. Поэтому когда бараны кругом начинают блеять своё «YAGNI», надо требовать доказательств аргументов применительно к данному классу и данному интерфейсу. Общий случай не катит. Хотя в частном они могут оказаться правы.

	Скрытый текст
	Как вы понимаете, такой подход обесценивает YAGNI в принципе.

2. В каждом конкретном случае думать приходится творчески, к механическим правилам это свести невозможно. (Невозможно заложить правила проверки в static code analyser). Такой ответ, наверно, кого-то разочарует, но кого-то, наоборот, успокоит: у всех так, посоны.

Б>P.S. Возможно, ответ сильно зависит от используемого языка. По возможности, укажите используемый язык.

Зависит мало, на самом деле. 20 лет назад в плюсах дефайнили interface на class/struct и вперёд. Не для компилятора же мы это писали.