Цитата:
Сообщение от
gl00mie
Это все верно, вот если бы еще разработчики стандарта всегда умели отделять "детали реализации" от возможных точек расширения реализуемых классов. Стопятсот раз на проектах были модифы, в рамках которых приходилось private-метод стандартного класса переделывать в protected. А то понашлепают private-методов, и думаешь - чего было сразу не сделать класс final?..
У меня мысль такая.
По идее надо различать API и детали реализации, API это то, изменения чего можно хоть как-то контроллировать (т.е. разделять ломающие изменения и не ломающие).
Если выставлять все методы в API проще плюнуть и париться с ломающими изменениями. Т.е. объявление метода protected должно быть неким ответственным шагом.
С другой стороны, если потребитель принял решение поменять метод с private на protected, это вполне его право - он знает, что берет решение о поддержке этого куска на себя.
Сейчас пока не все готово для того, чтобы полностью отделить API от деталей реализации (Например нет InternalsVisibleTo что делает невозможным юниттестинг), но как-мне кажется, направление в уелом правильное - разделить поддерживаемые и неподдерживаемые модификации.