Najlepsze praktyki korzystania z publicznego, chronionego, prywatnego?

Czy można uczciwie powiedzieć, że dobrą praktyką jest domyślne ustawianie wszystkiego z privategóry podczas kodowania?

A następnie uaktualnij go tylko wtedy, protectedgdy podklasa tego potrzebuje, lub publicjeśli potrzebuje innej klasy?

Krótka odpowiedź: tak

Dłuższa odpowiedź:

Tak, ale nie należy tego interpretować jako sugestii, aby zacząć od pisania swoich zajęć ze wszystkim prywatnym; takie podejście zakłada projektowanie klas poprzez skupienie się na szczegółach implementacji zanim zdecydujesz się na interfejs.

Jednym z najważniejszych aspektów do rozważenia przy projektowaniu klasy jest sposób jej użycia; która obejmuje myślenie o twoich publicznych metodach zanim zaczniesz myśleć o szczegółach prywatnych / implementacyjnych.

Co więcej, w takim podejściu zwykle nie ma szansy zadać sobie pytania „Jak napisałbym test jednostkowy dla tej klasy?” - które jest ważnym pytaniem, nawet jeśli nie piszesz testów jednostkowych. (Powiązane: „Jakie są zasady projektowania promujące testowalny kod?” )

Więc po zdefiniowaniu interfejsu publicznego, dobrym pomysłem jest ustawienie reszty jako prywatnej, ponieważ większość z nich będzie zazwyczaj drobiazgowymi szczegółami implementacji, które nie dotyczą niczego poza klasą.

„A następnie uaktualnij go tylko do ochrony, jeśli potrzebuje go podklasa, lub publicznego, jeśli potrzebuje innej klasy?”

To złe podejście. W czasie projektowania powinieneś wiedzieć, jaki publiczny dostęp chcesz przyznać. Zwykle dajesz publiczny dostęp, ponieważ jest to cały cel twojej klasy. Dajesz chroniony dostęp, ponieważ chcesz , aby podklasy miały do ​​niego dostęp. I używasz prywatnego do rzeczy, które nie są niczyją sprawą.

Teraz, jeśli ktoś potrzebuje dostępu do rzeczy, do których nie ma dostępu, powinieneś naprawdę mocno przemyśleć tę potrzebę . Nie powinni oni potrzebować takiego dostępu, bo twój projekt jest zły. Może twój projekt jest zły i coś nie jest publiczne, co powinno być publiczne, więc to zmienisz. Ale jeśli twój projekt jest poprawny, oznacza to, że coś jest nie tak z potrzebą , więc naprawiasz to zamiast uszkadzać swój projekt.

Kluczem do zrozumienia tego aspektu programowania obiektowego jest koncepcja enkapsulacji danych . Chodzi o to, aby uczynić klasę łatwiejszą do zrozumienia, ukrywając szczegóły jej implementacji. Nazywa się to ukrywaniem danych . Dlatego chcemy tylko ujawnić (upublicznić) te funkcje, które są niezbędne do korzystania z klasy. Te funkcje są interfejsem do klasy.

Pomyśl o interfejsie przypominającym kierownicę samochodu. Ty decydujesz, w jakim kierunku zmierza samochód, obracając koło, ale pod pokrywami znajdują się zawory obrotowe, hydraulika, koła pasowe zmieniające obrót kół, ale nie musisz być inżynierem mechanikiem, aby prowadzić samochód.

Odpowiedź na twoje pytanie brzmi: tak. Chcesz ukryć jak najwięcej szczegółów o klasie przed innymi klasami. Zrozumienie, kiedy coś powinno być publiczne, prywatne lub chronione, jest łatwe do nauczenia się, ale trudne do opanowania.