Czy istnieje termin używany, gdy zmienne wewnętrzne są deklarowane jako publiczne i dostępne?

Jeśli ktoś pisze kod, aby wewnętrzna zmienna $ _fields była dostępna bez korzystania z metod getter / setter, czy istnieje odpowiedni termin, aby to opisać?

Coś na tyle grzecznego, by korzystać z zarządzania :)

Ujawnianie prywatnych członków nigdy nie jest dobre w uprzejmym społeczeństwie ...

Ta praktyka to brak / słabe kapsułkowanie.

Poza brakiem enkapsulacji wspomnianym już przez Odeda, w zależności od języka programowania i jego paradygmatów, może to być również „zwykłe stare dane” (gdzie niekoniecznie jest to zapach antypatternowy lub kodowy).

Słyszałem już wcześniej termin „nagi przedmiot”.

Nazywa się to torbą nieruchomości.

Zwykle służy do przechowywania zestawu może powiązanych właściwości (gdzie każda z nich może potencjalnie być obiektem klasy, który ma odpowiednie specyfikatory dostępu lub nie). Ale otaczająca go struktura to tylko torba właściwości.

Nazywa się to „nieprzestrzeganiem określonego standardu kodowania”.

OP napisał:

wewnętrzna zmienna $ _fields jest dostępna bez użycia metod getter / setter

Może to być niezgodne z twoim standardem i (a więc) może to być zapach kodu. Ale niekoniecznie jest to słaba enkapsulacja. Wystawienie zmiennej zewnętrznej (jak w „tylko do użytku wewnętrznego”) na getter i setery na świat zewnętrzny byłoby jeszcze gorsze.

Pytanie brzmi: czy powinno $_fieldsbyć dostępne dla świata zewnętrznego?

Jeśli tak, mamy przypadek, w którym dodajesz metody pobierające / ustawiające. Te metody nie zawierają niczego poza faktem, że $_fieldsjest to pewnego rodzaju zmienna (w przeciwieństwie do czegoś obliczonego / pobranego itp. W locie). W zależności od języka prawdopodobnie nadal będziesz wyciekał na zewnątrz (inaczej szczegóły implementacji). Niezależnie od tego, czy zawsze chcesz getterów / seterów, czy tylko wtedy, gdy „potrzebny” jest standardowym problemem kodowania.

Jeśli nie$_fields powinno być dostępne, to nie korzystaj z niego. To, czy powinieneś uniemożliwić innym dostęp do niego na poziomie językowym (prywatnym i znajomym), czy nie (co może ułatwić debugowanie w pewnych okolicznościach) jest - znowu - standardowym zagadnieniem kodowania.

Problem enkapsulacji jest całkowicie ortogonalny. Naruszenie enkapsulacji jest absolutnie możliwe w przypadku osób pobierających i ustawiających. Jeszcze łatwiej jest się w nie wsunąć, ponieważ dzwonki większości ludzi nie dzwonią, gdy widzą grupę pobierających i ustawiających - kod, który pozornie przestrzega najlepszych praktyk. Kod, który bardzo dobrze może wprowadzić znacznie więcej zależności od wewnętrznych szczegółów implementacji niż wywoływana zmienna, $_fieldsktóra nie jest określona jako private.

Jestem fanem złych analogii: nazywanie tego złym hermetyzacją jest jak nazywanie kogoś, kto trzyma broń, mordercą.

Nazwałbym takie zmienne zmiennymi publicznymi .

jeśli twoje metody setter / getter są niczym więcej niż

void setfoo(bar){foo=bar;}
foo getfoo{return foo;}

to po prostu utworzenie zmiennej łonowej pozwala zaoszczędzić trochę pisania poza kilkoma przypadkowymi krawędziami, w których różnica ma znaczenie.