Dlaczego atrybuty w Javie mogą być publiczne?

Dla elastyczności. To byłby ogromny ból, gdybym nie był w stanie napisać:

class Point {
    public int x;
    public int y;
}

Nie ma cennej przewagi, aby ukryć to za geterami i seterami.

Ponieważ sztywna "enkapsulacja danych" nie jest jedynym paradygmatem, ani obowiązkową cechą orientacji obiektu.

I, bardziej do rzeczy, jeśli ktoś ma atrybut data, który ma publiczną metodę setter i publiczną metodę getter, a metody nie robią nic innego niż rzeczywiście ustawić / get atrybut, jaki jest sens utrzymywania go w tajemnicy?

Nie wszystkie klasy są zgodne z paradygmatem enkapsulacji (np. klasy fabryczne). Dla mnie Zwiększa to elastyczność. W każdym razie, to jest odpowiedzialność programisty, a nie języka, aby zakres odpowiednio.

Omawianie dobrych stron zmiennych publicznych... Podoba mi się... :)

Może być wiele powodów, dla których warto używać zmiennych public. Sprawdźmy je jeden po drugim:

Wydajność

Choć rzadko, będą pewne sytuacje, w których ma to znaczenie. W niektórych przypadkach należy unikać narzutu wywołania metody.

Stałe

Możemy używać zmiennych publicznych dla stałych, których nie można zmienić po zainicjowaniu w konstruktorze. Pomaga to również w wydajności. Czasami mogą to być stałe statyczne, jak łańcuch połączenia z bazą danych. Na przykład,

public static final String ACCEPTABLE_PUBLIC = "Acceptable public variable";

Inne Przypadki

Są przypadki, gdy public nie robi różnicy lub posiadanie gettera i settera jest niepotrzebne. Dobry przykład z Point jest już napisany jako odpowiedź.

Projektowanie obiektowe nie wymaga enkapsulacji. Jest to najlepsza praktyka w językach takich jak Java, która ma znacznie więcej wspólnego z projektem języka niż OO.

To tylko najlepsza praktyka, aby zawsze enkapsulować w Javie z jednego prostego powodu. Jeśli nie zostanie zakapsulowana, nie będzie można później zakapsulować bez zmiany sygnatury obiektu. Na przykład, jeśli twój pracownik ma nazwisko, a Ty je upubliczniasz, jest to employee.name. jeśli później chcesz go zamknąć, kończysz z pracownikiem.getName () i employee.setName (). spowoduje to oczywiście złamanie dowolnego kodu przy użyciu klasy pracownika. Dlatego w Javie najlepszą praktyką jest Hermetyzowanie wszystkiego, tak aby nigdy nie trzeba było zmieniać sygnatury obiektu.

Niektóre inne języki OO (ActionScript3, C#, itd.) obsługują właściwości true, gdzie dodanie gettera / settera nie wpływa na sygnaturę. W takim przypadku, jeśli masz getter lub setter, zastępuje on właściwość publiczną tym samym podpisem, dzięki czemu możesz łatwo przełączaj się tam iz powrotem bez łamania kodu. W tych językach praktyka enkapsulacji nie jest już konieczna.

Java jest gałęzią języków składniowych w stylu C. Te języki obsługiwały structs, które były stałymi aliasami offsetowymi dla bloku pamięci, który był ogólnie uważany za"jeden element". Innymi słowy, struktury danych zostały zaimplementowane za pomocą struct s.

Podczas gdy używanie struktury bezpośrednio narusza cele enkapsulacji programowania obiektowego, kiedy Java została wydana, większość ludzi była znacznie bardziej kompetentna w programowaniu iteracyjnym (proceduralnym). Odsłaniając members jako public można efektywnie używać klasy Java w taki sam sposób, w jaki można używać C struct, mimo że podstawowe implementacje obu środowisk były drastycznie różne.

Są pewne scenariusze, w których można to zrobić nawet przy odpowiedniej enkapsulacji. Na przykład wiele struktur danych składa się z węzłów zawierających dwa lub więcej wskaźników, jeden wskazuje na "zawarte" DANE, a jeden lub więcej wskazuje na "inne" połączenia z resztą struktury danych. W takim przypadku, ty może utworzyć klasę prywatną, która nie ma widoczności poza klasą "data structure" (jak Klasa wewnętrzna), a ponieważ cały kod do poruszania się po strukturze jest zawarty w tym samym pliku .java, możesz usunąć metody .getNext() klasy wewnętrznej jako optymalizację wydajności.

Uważam, że enkapsulacja danych jest oferowana bardziej jako dodatkowa funkcja, a nie obowiązkowy wymóg lub reguła, więc koder ma swobodę korzystania ze swojej mądrości, aby zastosować funkcje i dostosować je zgodnie z ich potrzebami.Stąd elastyczne jest!

Podobny przykład może być podany przez @ Oli Charlesworth

Jestem dopiero początkujący, ale jeśli publiczne oświadczenie nie istnieje, rozwój Javy będzie naprawdę skomplikowany do zrozumienia. Ponieważ używamy publicznych, prywatnych i innych oświadczeń, aby uprościć zrozumienie kodu, jak jars, których używamy i inni stworzyli. Chcę powiedzieć, że nie musimy wymyślać, musimy się uczyć i kontynuować.

Mam nadzieję, że po angielsku, staram się poprawić i mam nadzieję pisać jasno w przyszłości.

Modyfikatory dostępności są implementacją koncepcji enkapsulacji w językach OO (widzę tę implementację jako sposób na rozluźnienie tej koncepcji i umożliwienie pewnej elastyczności). Istnieją czyste języki OO, które nie mają modyfikatorów dostępności, np. Smalltalk. W tym języku wszystkie stany (zmienne instancji) są prywatne, a wszystkie metody są publiczne, jedynym sposobem na modyfikowanie lub odpytywanie stanu obiektu są jego metody instancji. Brak dostępności modyfikatory metod zmuszają programistów do przyjęcia pewnych konwencji, na przykład metody w protokole prywatnym (protokoły są sposobem organizowania metod w klasie) nie powinny być używane poza klasą, ale żadna konstrukcja języka tego nie wymusi, jeśli chcesz, możesz wywoływać te metody.

Używanie public czy nie tak naprawdę zależy od tego, czy istnieje niezmiennik do utrzymania. Na przykład, obiekt Pure data nie ogranicza przejścia stanu w żaden sposób, więc nie ma sensu zamykać członków kilkoma accesorami, które nie oferują więcej funkcji, które ujawniają członka danych jako publicznego.

Jeśli masz zarówno getter, jak i setter dla konkretnego Nie-prywatnego członka danych, który zapewnia nie więcej funkcji niż getting i setting, możesz chcieć zrecenzuj swój projekt lub upublicznij go.

Naprawdę nie mogę wymyślić dobrego powodu, aby nie używać getterów i seterów poza lenistwem. Skuteczna Java, która jest powszechnie uważana za jedną z najlepszych książek Javy, mówi, aby zawsze używać getterów i setterów. Jeśli nie musisz słyszeć o tym, dlaczego zawsze powinieneś używać getterów i setterów, pomiń ten akapit. Nie zgadzam się z przykładem odpowiedzi numer 1 punktu jako czasu, aby nie używać getterów i setterów. Jest z tym kilka problemów. Co zrobić, jeśli trzeba zmienić rodzaj numer. Na przykład, pewnego razu, kiedy eksperymentowałem z Grafiką, odkryłem, że często zmieniałem zdanie co do pogody, chcę przechowywać lokalizację w kształcie Javy lub bezpośrednio jako int, jak pokazał. Gdybym nie używał getterów i setterów i zmieniłem to, musiałbym zmienić cały kod, który używał lokalizacji. Jednak, jeśli nie mogę po prostu zmienić getter i setter.

Gettery i settery to ból w Javie. W Scali można tworzyć public data members i następnie getters I or setters później bez zmiany API. To daje najlepsze z obu światów! Być może Java kiedyś to naprawi.