Лучшие практики для использования публичного, защищенного, частного?

Справедливо ли говорить, что privateпри кодировании чего-либо является хорошей практикой по умолчанию все по умолчанию ?

А затем обновите его только до того момента, protectedкогда это потребуется подклассу, или publicесли это понадобится другому классу?

Краткий ответ: да

Более длинный ответ:

Да, но это не должно быть истолковано как предложение начать писать свои занятия со всем частным; этот подход подразумевает дизайн класса, сосредоточив внимание на деталях реализации, прежде чем вы остановитесь на интерфейсе.

Один из наиболее важных аспектов, который следует учитывать при разработке класса, - как он будет использоваться; который включает в себя обдумывание ваших общедоступных методов, прежде чем вы начнете думать о деталях приватности / реализации

Кроме того, этот подход обычно не дает возможности задать себе вопрос: «Как бы я написал модульный тест для этого класса?» - это важный вопрос, даже если вы на самом деле не пишите юнит-тесты. (Похожие: «Каковы принципы проектирования, которые продвигают тестируемый код?» )

Итак, после того как вы определили открытый интерфейс, то хорошей идеей будет по умолчанию установить остальное на приватное, потому что большая часть этого будет, как правило, детальной реализацией, которая не имеет отношения к чему-либо вне класса.

«И затем обновлять его до защищенного, если это нужно подклассу, или публичного, если это нужно другому классу?»

Это неправильный подход. Во время разработки вы должны знать, какой публичный доступ вы хотите предоставить. Обычно вы предоставляете публичный доступ, потому что это и есть цель вашего класса. И вы предоставляете защищенный доступ, потому что вы хотите, чтобы подклассы обращались к вещам. И вы используете личное для вещей, которые не являются ничьим делом.

Теперь, если кому-то нужен доступ к вещам, к которым у него нет доступа, тогда вам следует серьезно задуматься об этой необходимости . Им не нужен этот доступ, иначе ваш дизайн неправильный. Может быть , ваш дизайн является неправильным, и что - то не является публичным , которые должны быть открытыми, чтобы вы изменить. Но если ваш дизайн верен, то с необходимостью что-то не так, поэтому вы исправите это, а не повредите свой дизайн.

Ключом к пониманию этого аспекта объектно-ориентированного программирования является концепция инкапсуляции данных . Идея состоит в том, чтобы облегчить понимание класса, скрывая детали его реализации. Это называется скрытием данных . Таким образом, мы хотим выставить (обнародовать) только те функции, которые необходимы для использования класса. Эти функции являются интерфейсом к классу.

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

Так что ответ на ваш вопрос - да. Вы хотите скрыть как можно больше сведений о классе от других классов. Понимать, когда что-то должно быть публичным, частным или защищенным, легко учить, но трудно освоить.