Najlepsze praktyki korzystania z publicznego, chronionego, prywatnego?

12

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?

— AJJ
źródło

2

Jeśli tworzysz interfejs API, musisz przewidzieć funkcjonalność, której może potrzebować osoba dzwoniąca. Dlatego musisz bardziej przemyśleć modyfikatory dostępu. To zależy od tego, kto używa kodu, który piszesz.

— user2023861,

Możliwy duplikat ZRÓB WSZYSTKIE zmienne należy uznać za prywatne?

— komar

10

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ą.

— Ben Cottrell
źródło

Więc jeśli spróbuję podsumować to, co do ciebie mówisz (aby zobaczyć, czy rozumiem), dobrym pomysłem jest najpierw pomyśleć o interfejsie publicznym (tj. Jak ta klasa jest faktycznie używana przez na zewnątrz?), a następnie uczynić wszystko inne prywatnym?

— AJJ

1

@ArukaJ Dobrym podejściem jest napisanie kodu, który będzie korzystał z twoich klas przed zbudowaniem implementacji. Może to być trochę problem z kurczakiem lub jajkiem, dopóki nie zaczniesz najpierw pisać testów jednostkowych.

— JimmyJames

1

@ArukaJ Zasadniczo tak; co na początku może wydawać się trudniejsze, chociaż jak wspomina JimmyJames, pisanie testów jednostkowych jest o wiele bardziej intuicyjne. Może to wymagać nieco odmiennego sposobu myślenia, ale celem jest dokładniejsze zastanowienie się nad tym, co reprezentuje twoja klasa i jak wyglądają twoje wejścia / wyjścia - ogólnie rzecz biorąc, jest to po prostu bardziej „OO” sposób myślenia o projektowaniu; bardziej prawdopodobne jest, że będą one starannie zamknięte w klasach o wysokiej spójności.

— Ben Cottrell

Jestem ostrożny w używaniu testów jednostkowych do projektowania twojej klasy, ponieważ testy jednostkowe nie są tymi, którzy naprawdę będą go używać. Są jednak zdecydowanie lepsi niż nic w myśleniu o tym, jak zostanie wykorzystana klasa.

— user949300

8

„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.

— gnasher729
źródło

Powiedzmy, że masz klasę, że nie zamierzają podklasy w tym czasie (a może nigdy nie trzeba) i sposób, że jeśli były do podklasy swoją klasę, byłoby użyteczne / wymagane do / przez podklasy. Czy zrobiłbyś tę metodę privatelub protected?

— lfk

Powinna być zaakceptowana odpowiedź, spraw, aby wszystko było prywatne na pierwszy rzut oka, jakbym nie chciał myśleć / projektować.

— Niing

1

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.

— Chris Ghyzel
źródło