Изюбрну интерфейсом не только сам interface зовется. Но и открытые члены касса.
Может я и не полностью корректно употребил. Но интерфейсом я назвал просто "весь набор методов и свойств", которые видит программист при поддержке класса (в том числе и приватно-протектные).
И суть была в том, что чем меньше в этом "интерфейсе" левых методов (которые используются только в одной функции, например инкапсулируют некую логику в цикле) тем понятней класс.
Просто одно дело когда подфункции складируются в нужной функции, и там используются (а в шарпе получается их еще и передавать между друг другом функции могут, так что опять таки нет нужды выносить их в "интерфейс класса", а просто передать при вызове).Если разделение метода на методы неудобно - зачем это делать? Чтобы не было конфликтов с именами локальных переменных в большом методе - можно разбить его на блоки
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
void MyBigMethod()
{
int j = 0; // общая для всего метода
{
int i = 0; // локальная для блока
}
{
int i = 0; // локальная для блока
}
}
Получается примерно тоже самое, что и с вложенными процедурами в Паскале.
ИзюбрА другое дело, когда в классе 20 функций, и нужно пройтись и выяснить, что 15 из них используются только в одном единственном месте и ни в коем случае не могут быть полезны где-то еще.Может есть смысл разделить класс на классы?
ИзюбрИ это хорошо, если будут коменты к методам, и не придется залазить в них.Коментарии должны быть только в крайнем случае. Всё должно быть понятно из имён методов, имён их параметров и контекста вызова.
