Zwracanie referencji do prywatnych skladowyhc klasy

0

Zastanawialem sie nad czyms takim: mam sobie taka bzdurna klase:

class Klasa {
    private StringBuilder sb = new StringBuilder(17);
    public StringBuilder getSB() {
        return sb;
    }
}

Pole sb jest

private

zgodnie z zasadami OOP. Jednak moge sie do niego dostac za pomoca metody getSB. I nad tym sie zastanawialem: przeciez w ten sposob nie ochronilem pola sb poniewaz zwracana wartosc do referencja do dokladnie tego obiektu - moge wiec dowolnie nim manipulowac. Problem dotyczy tylko obiektow ktore mozna zmieniac (mutable), poniewaz np. String lub wrappery nie moga byc zmienione. I co z tym zrobic? Myslelem ze moze powinienem zrobic cos takiego:

public StringBuilder getSB() {
        return sb.clone();
    }

Ale to nie rozwiazuje problemu poniewaz dana klasa moze nie implementowac interfejsu Cloneable. Co nalezy zrobic w takiej sytuacji? I czy to oc pisze ma w ogole jakis sens?

0

Java właśnie taka (głupia) jest...
Jeżeli StringBuilder jest Immutable to spoko :)

Przeczytaj cały dodatek A w "Thinking in Java"
A: Passing & Returning Objects

Zasada z "Effective Java" mówi:
"Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, you should still limit its mutability as much as possible."

http://www.javapractices.com/Topic29.cjp

0

No to teraz zapytam czy da sie napisac program majac do dyspozycji same tylko klasy ktorych nie mozna zmieniac? Wydaje mi sie to niemozliwe.

0
Ali G napisał(a)

No to teraz zapytam czy da sie napisac program majac do dyspozycji same tylko klasy ktorych nie mozna zmieniac? Wydaje mi sie to niemozliwe.

Hmm :] sam stwierdziłeś, że String jest Immutable, i co? Nie da się napisać programu ze Stringami??!!

0

No da sie, ale preciez dobrze wiesz ze wykorzystanie StringBuffer (a jesli nie jest wielowatkowa to nawet StringBuilder) jest o wiele bardziej optymalne jesli chce zmieniac cos w tych napisach, a te klasy sa mutable. Mi chodzilo raczej o jakis powazniejszy program niz "Hello, World".

0

Po to jest clone()...
Przeczytaj dodatek A w TIJ...
Programowanie polega na podejmowaniu decyzji, projektowaniu, itp.

0

Klonowanie jest nieetyczne. [rotfl]

Zasada, ktora przytoczyl MarcinEc jest tylko nedzna proba poradzenia sobie z brakiem modyfikatora const w Javie. :( Dlatego nie istnieje rozsadna odpowiedz na pytanie postawione w temacie. W C++ mozna zwrocic const wskaznik lub const referencje i po problemie. A tu lipa. Moze w wersji 6 bedzie? :)

BTW. Oczywiscie dodali takie "pierduly" jak printf, ale consta do tej pory nie zrobili. Eh. W tym tempie wielodziedziczenia klas doczekamy sie za 40 lat...

0

Dzieki za odpowiedzi. Co do wielodziedziczenia to wydaje mi sie ze nigdy tego nie bedzie w Javie, bo ten jezyk ma byc z zalozenia prosty a nie zawiklany jak momentami C++ (choc osobiscie czasami zaluje ze nie moge dziedziczyc po kilku klasach, interfejsy to tylko namiastka). Natomiast co do const to mysle ze mogliby to zaimplementowac jakos. Pozdro!

0

7 lat później i jest już jakaś const referencja w Javie czy nadal nie?

0

Wow, ale archeolog.

Wielodziedziczenie już w następnym tygodniu :-)

A po co Ci const? Bez problemu możesz robić immutable obiekty bez tego.

1

Jak już wykopaliście tego trupa, to ja sobie pozwolę przypomnieć, że używanie setterów i getterów "bo są bardziej obiektowe" jest największą pomyłką jaką można walnąć. Obiektowość to nie settery i gettery, a enkapsulacja, czyli ukrywanie właściwości na rzecz udostępniania operacji... Dla zainteresowanych:
http://koziolekweb.pl/2012/01/20/ekstremalna-obiektowosc-w-praktyce-czesc-9-nie-uzywaj-getterowsetterowwlasnosci/

1 użytkowników online, w tym zalogowanych: 0, gości: 1