Różne sposoby tworzenia obiektu

Witam,
Mam za zadanie stworzyć trzy obiekty na trzy sposoby, więc według tego co znalazłem w google pod hasłem "java different ways to create object" napisałem poniższe kody.

Pierwszy sposób działa dobrze:

Object o1;
o1 = new Object(); //pierwszy obiekt poprzez operator new

Przy drugim sposobie:

Object o2 = (Object) Class.forName("java.lang.Object").newInstance(); //drugi poprzez Class.forName

Kompilator wyświetla mi błąd:

unreported exception java.lang.ClassNotFoundException; must be caught or declared to be thrown
unreported exception java.lang.InstantiationException; must be caught or declared to be thrown

Przy trzecim sposobie:

Object o3 = o2.clone(); //trzeci poprzez clone()

Kompilator wyświetla mi błąd:
clone() has protected access in java.lang.Object

Jak ktoś wie jak poprawić te błędy lub zna inne trzy różne sposoby na stworzenie obiektu, to proszę o pomoc.
Z góry dziękuję i pozdrawiam.

No bez jaj... w drugim przypadku masz jawnie napisane, co jest nie tak - nie łapiesz rzucanych wyjątków. Musisz ując wywłanie "forName()" w try ... catch(OdpowiedniWyjątek e) {...}. Co do drugiego przypadku - nie da się tego obejść, bo w klasie Object metoda clone() jest protected, czyli NIEwidoczna z zewnątrz (dla Ciebie). Możesz klonować obiekty, które przedefiniowały tę metodę (klasy pochodne od Object).

1 ze sposobów to singleton:

public class Singleton
{
private Singleton(){} //prywatny konstruktor

private static class SingletonHolder  //wewnętrzna klasa 
{
private static final Singleton  handler = new Singleton();
}

public static Singleton getInstance()
{
return SingletonHolder.handler;
}

}

@up - przyfafales teraz z tym singletonem - to jest creational pattern a nie sposob tworzenia obiektu - ten jest tworzony zwyczajnie z new.

Na marginesie, w Javie jest jeszcze lepszy sposob tworzenia singletona - za pomoca enumeracji, Joshua Bloch go opisuje w swojej ksiazce Effective Java jako najlepszy sposob. Przeczytaj.

Singleton-enum czasem w ogóle nie daje się zastosować. Wady enuma:

• nie da się go dziedziczyć,
• nie można utworzyć kolejnych obiektów,

Jak dla mnie najlepszym rozwiązaniem jest jednak wstrzykiwanie zależności :P

• nie trzeba w każdym singletonie wpisywać holdera ani robić z niego enuma,
• można dziedziczyć do woli i tworzyć kolejne obiekty,
  Java jako język jednak nie jest specjalnie przystosowana do wstrzykiwania, więc kodu może wyjść trochę więcej.

Object.clone() jest metodą na stworzenie obiektu? Przecież w środku to musi wywołać jakiś konstruktor czy w inny sposób stworzyć obiekt, a i nawet wtedy jego stan ma być podobny do oryginału.

Metodą stworzenia obiektu może być serializacja, a potem deserializacja.

Tak w drodze małej dygresji, szkoda, że w zarządzanych językach typu C#, J2SE nie wprowadzają możliwości znanych z PHPowego eval(). O tyle, o ile w językach typowo kompilowanych jak C++ to byłoby kłopotliwe, to już w zarządzany kodach jak Java, a szczególnie C# to dałoby się ogranąć - przynajmniej w ograniczonym zakresie...

Opolski Portal Programistyczny
http://programowanie.opole.pl

Wibowit napisał(a)

Singleton-enum czasem w ogóle nie daje się zastosować. Wady enuma:

• nie da się go dziedziczyć,
• nie można utworzyć kolejnych obiektów,

No wlasnie dlatego jest nazwany Singletonem - bo jest tylko jeden. Nie ma podklas, nie ma innych instancji - jest single.

Wibowit napisał(a)

Jak dla mnie najlepszym rozwiązaniem jest jednak wstrzykiwanie zależności :P

• nie trzeba w każdym singletonie wpisywać holdera ani robić z niego enuma,
• można dziedziczyć do woli i tworzyć kolejne obiekty,
  Java jako język jednak nie jest specjalnie przystosowana do wstrzykiwania, więc kodu może wyjść trochę więcej.

Popieram w pelni, rowniez jestem fanen DI.

Wibowit napisał(a)

Metodą stworzenia obiektu może być serializacja, a potem deserializacja.

Chyba ze mowimy o Singletonach i ktos ma readResolve() zaimplementowane poprawnie - wtedy dostanie sie ten sam obiekt ;d

No wlasnie dlatego jest nazwany Singletonem - bo jest tylko jeden. Nie ma podklas, nie ma innych instancji - jest single.

Pomijając już to, że Singleton jest antywzorcem, to co jeśli np chcę mieć np listę Integerów jako singleton? Albo lepiej, kilka list Integerów w jakimś sensie globalne (używając DI można ograniczyć ten zakres globalności), ale nie związane bezpośrednio ze sobą?

Kolejna sprawa to sytuacja, gdy chcę zrobić Singleton, tak aby uniknąć wycieków pamięci - tzn jeśli przestanie być używany to powinien być usunięty. Można to osiągnąć za pomocą WeakReference. Wrzucenie takiej logiki do enuma jest niemożliwe, a wrzucanie do holdera zwiększa znacznie jego rozmiar.

Wibowit napisał(a)

Kolejna sprawa to sytuacja, gdy chcę zrobić Singleton, tak aby uniknąć wycieków pamięci - tzn jeśli przestanie być używany to powinien być usunięty. Można to osiągnąć za pomocą WeakReference. Wrzucenie takiej logiki do enuma jest niemożliwe, a wrzucanie do holdera zwiększa znacznie jego rozmiar.

Idac tym tropem, podczas dzialania aplikacja moze widziec wiele instancji czegos co ma byc singletonem, ale nie jednoczesnie. Np, na starcie jest tworzony com.test.Singleton@123, przestaje byc uzywany, jest sprzatniety. Po pol dnia jest znowu potrzebny, i tworzone jest com.test.Singleton@456, i tak dalej i tak dalej. Co z tego za Singleton?

Lista integerow jako singleton to moze byc po prostu enum z jednym polem, ktore ma w sobie liste integerow. Wszystko sie da zamodelowac. Ale nie bede sie upieral, calkiem mozliwe ze masz racje ze nie wszystko da sie z enumem robic. Jednak nie spotkalem takiego wymagania ktore by sie nie dalo zamodelowac, a od dluzszego czasu nie uzywam Singletona jako wzorca, tylko uzywam zasiegow ktore sa dostarczane przez DI.

Takie ciekawskie pytanie
singletona używam do przechowywania uchwytu entityhandler

co można użyć zamiast singletona ?? skoro jest to antywzorzec to musi być co najmniej kilka technik zastępczych do rozwiązania problemu ??