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

12

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

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

— AJJ
источник

2

Если вы создаете какой-то API, вам нужно предвидеть функциональность, которая может понадобиться вызывающей стороне. Таким образом, вам нужно больше думать о ваших модификаторах доступа. Это зависит от того, кто использует код, который вы пишете.

— user2023861

Возможный дубликат ВСЕ ли ваши переменные должны быть объявлены закрытыми?

— комнат

10

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

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

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

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

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

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

— Бен Коттрелл
источник

Поэтому, если бы я попытался обобщить то, что вы говорите вам (чтобы понять, понимаю ли я), лучше сначала подумать об общедоступном интерфейсе (т.е. как этот класс на самом деле используется снаружи для начала?) а потом все остальное сделать приватным?

— AJJ

1

@ArukaJ Хороший подход - написать код, который будет использовать ваши классы, прежде чем вы создадите реализацию. Это может быть проблемой для курицы или яйца, пока вы сначала не начнете писать модульные тесты.

— JimmyJames

1

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

— Бен Коттрелл

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

— user949300

8

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

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

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

— gnasher729
источник

Скажем , у вас есть класс , который вы не собираетесь подкласс в это время (и не можете и не нужен) и метод, если вы были подкласс вашего класса, было бы полезно / необходимый для / подкласса. Вы бы сделали этот метод privateили protected?

— ЛФК

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

— Niing

1

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

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

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

— Крис Гизел
источник