Кращі практики використання громадських, захищених, приватних?

12

Чи справедливо сказати, що є хорошою практикою замовчувати все privateнаперед, коли щось кодує?

А потім лише оновити його, protectedякщо потрібен підклас або publicінший клас?

— AJJ
джерело

2

Якщо ви створюєте якийсь API, вам потрібно передбачити функціонал, який може знадобитися абоненту. Таким чином, вам потрібно буде більше продумати свої модифікатори доступу. Це залежить від того, хто використовує код, який ви пишете.

— користувач2023861

Можливий дублікат УСІХ змінних потрібно оголосити приватними?

— гнат

10

Коротка відповідь: Так

Більш довга відповідь:

Так, але це не слід трактувати як пропозицію почати з написання своїх занять із усього приватного; такий підхід передбачає дизайн класу, орієнтуючись на деталі реалізації, перш ніж ви зупинилися на інтерфейсі.

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

Крім того, такий підхід, як правило, не вистачає шансів запитати себе: "Як би я написати одиничний тест для цього класу?" - що важливо запитати, навіть якщо ви насправді не пишете одиничні тести. (Пов'язано: "Які принципи дизайну рекламують перевіряється код?" )

Отже, після того, як ви визначили загальнодоступний інтерфейс, тоді добре б решту за замовчуванням встановити приватним, оскільки більшість із них, як правило, є деталізацією з дрібною реалізацією, яка не стосується нічого поза класом.

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

Тож якби я намагався узагальнити те, що ти говориш до себе (щоб зрозуміти, чи я розумію), добре б спершу подумати над загальнодоступним інтерфейсом (тобто, як насправді використовується цей клас зовні для початку?), а потім зробити все інше приватним?

— AJJ

1

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

— JimmyJames

1

@ArukaJ Широко так; що спочатку може здатися складнішим, хоча, як згадує Джиммі Джеймс, це виглядає набагато інтуїтивніше, коли ви пишете одиничні тести. Це може включати дещо інший спосіб мислення, але мета - більш ретельно продумати, що представляє ваш клас, і як виглядають ваші входи / виходи - загалом це просто набагато більш "OO" спосіб мислення щодо дизайну; більше шансів, що це призведе до акуратно капсульованих класів з високою згуртованістю.

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

Мені цікаво використовувати одиничні тести для проектування вашого класу, оскільки одиничні тести - це не ті, хто справді ним будуть користуватися. Однак вони, безумовно, краще, ніж нічого, думаючи, як буде використовуватися клас.

— user949300

8

"А потім лише оновіть його до захищеного, якщо йому потрібен підклас, або до публічного, якщо йому потрібен інший клас?"

Це неправильний підхід. На час проектування ви повинні знати, який доступ до публіки ви хочете надати. Зазвичай ви даєте доступ громадськості, тому що в цьому і полягає вся мета вашого класу. І ви надаєте захищений доступ, оскільки ви хочете, щоб підкласи мали доступ до речей. І ви використовуєте приватне для речей, які нікому не займаються.

Тепер, якщо комусь потрібен доступ до речей, до яких вони не можуть отримати доступ, то вам слід дуже подумати над цією потребою . Їм не потрібен такий доступ, або ваш дизайн неправильний. Може бути , ваш дизайн є неправильним, і що - то не є публічним , які повинні бути відкритими, щоб ви змінити. Але якщо ваш дизайн правильний, то з потребою щось не так, тож ви виправте це, замість того, щоб пошкодити дизайн.

— gnasher729
джерело

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

— lfk

Якщо має бути прийнята відповідь, зробіть усе приватне спочатку звучить так, як я не хочу думати / розробляти

— Нінг

1

Запорукою розуміння цього аспекту об'єктно-орієнтованого програмування є концепція інкапсуляції даних . Ідея полягає в тому, щоб зробити клас легшим для розуміння, приховавши деталі його реалізації. Це називається приховуванням даних . Таким чином, ми хочемо лише розкрити (оприлюднити) ті функції, які необхідні для використання класу. Ці функції є інтерфейсом до класу.

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

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

— Кріс Гізель
джерело