[Java/Generici] Istanziare oggetto generico?

[Mrk31]

No. Questa classe HashUtils NON puo' essere "top level". Dovrebbe essere contenuta dentro un'altra classe. E se lo fosse, l'unica cosa (ripeto l'unica) che cambierebbe e a livello di naming, cioe' di qualificazione del nome:

String ciphredPwd = ClasseTopLevel.HashUtils.getMd5(pwd);



Ti ripeto che il concetto del pattern "singleton" non c'entra nulla con la differenza tra una classe "top level" e una "nested" (static).

Forse non riesco a spiegarmi bene io....

Io vorrei generare una mia classe di utilita' per delle mie librerie, in modo analogo ad esempio a Math...

Quindi con un utilizzo del tipo Math.abs() senza istanziare un oggetto Math...

Pensavo che fosse giusto che una classe con SOLO metodi statici dovesse essere dichiarata statica, ma mi son guardato la API di Math ed in effetti è una classe non-statica final in modo da non poterla estendere, che contiente SOLO metodi statici...

A questo punto non capisco perchè non ci sia la "regola" (che non conoscevo) di non avere classi Top Level statiche?
Se una classe ho SOLO metodi statici può non essere per forza dichiarata statica, anzi se è top-level NON DEVE...perchè?
A sto punto qual'è l'utilità del modificatore static riferito alle classi?

Il mio paragone con il singleton era in relazione alla domanda: mi serve un modo per richiamare metodi senza avere un'istanza per ogni classe che la utilizza o dover passare l'istanza a tutte le classi, come posso fare?

In ogni caso ci sono articoli, libri, ecc... che confrontano classi statiche e Singleton e che propongono il singleton come alternativa all'utilizzo di classi statiche, non è una mia invenzione ...

P.S. per curiosità ho guardato in .Net la classe Math è invece statica...

[andbin]

Pensavo che fosse giusto che una classe con SOLO metodi statici dovesse essere dichiarata statica, ma mi son guardato la API di Math ed in effetti è una classe non-statica final in modo da non poterla estendere, che contiente SOLO metodi statici...

Appunto.

A questo punto non capisco perchè non ci sia la "regola" di non avere classi Top Level statiche?

Pensa: un membro "static" è concettualmente associato alla classe che lo contiene. Se una classe top level potesse essere static, con chi e come c'entrerebbe? Con niente. E quindi non farebbe differenza.

Se una classe ho SOLO metodi statici può non essere per forza dichiarata statica, anzi se è top-level NON DEVE...perchè?

L'ho detto al punto prima.

A sto punto qual'è l'utilità del modificatore static riferito alle classi?

Una classe nested (static) che è quindi membro di un'altra classe la si usa spesso per rappresentare un sotto-concetto o per implementare una qualche interfaccia usata all'interno della classe top level o altre cose del genere. Anche una enum che è nested dentro una classe è implicitamente static.

Il mio paragone con il singleton era in relazione alla domanda: mi serve un modo per richiamare metodi senza avere un'istanza per ogni classe che la utilizza o dover passare l'istanza a tutte le classi, come posso fare?

Conta solo il fatto che il metodo sia static. Non dove sia. Dove sia (se in una classe top level o nested) cambia solo a livello di qualificazione del nome.

ClasseTopLevel.metodoStatico() oppure ClasseTopLevel.ClasseNested.metodoStatico()

In ogni caso ci sono articoli, libri, ecc... che confrontano classi statiche e Singleton e che propongono il singleton come alternativa all'utilizzo di classi statiche, non è una mia invenzione ...

Continuo a ripeterti che il pattern "singleton" non c'entra nulla con top level vs nested.
Una classe "singleton" (di cui si può ottenere una sola ed unica istanza) la puoi realizzare sia come top level che come nested static class.

P.S. per curiosità ho guardato in .Net la classe Math è invece statica...

.Net è sicuramente tutta un'altra cosa .... non facciamo miscugli di linguaggi e piattaforme completamente differenti.

[Mrk31]

Appunto.


Pensa: un membro "static" è concettualmente associato alla classe che lo contiene. Se una classe top level potesse essere static, con chi e come c'entrerebbe? Con niente. E quindi non farebbe differenza.


L'ho detto al punto prima.


Una classe nested (static) che è quindi membro di un'altra classe la si usa spesso per rappresentare un sotto-concetto o per implementare una qualche interfaccia usata all'interno della classe top level o altre cose del genere. Anche una enum che è nested dentro una classe è implicitamente static.


Conta solo il fatto che il metodo sia static. Non dove sia. Dove sia (se in una classe top level o nested) cambia solo a livello di qualificazione del nome.

ClasseTopLevel.metodoStatico() oppure ClasseTopLevel.ClasseNested.metodoStatico()


Continuo a ripeterti che il pattern "singleton" non c'entra nulla con top level vs nested.
Una classe "singleton" (di cui si può ottenere una sola ed unica istanza) la puoi realizzare sia come top level che come nested static class.


.Net è sicuramente tutta un'altra cosa .... non facciamo miscugli di linguaggi e piattaforme completamente differenti.

Ok ho capito che c'è questa "regola" per cui anche se potrei usare classi top-level statiche è meglio utilizzare classe non statica con metodi statici...mentre per le nested va bene che sia statica anche la classe...

Quello che non capisco è il perchè ci sia questa differenza tra Top-level e nested??? Perchè introdurre questa regola?

Ne guadagno in termini di prestazioni/ottimizzazione? è semplicemente una convenzione?

P.S. il confronto col .net era solo per capire se fosse una cosa universalmente nota/accettata o fosse una particolarità di Java...

[andbin]

Ok ho capito che c'è questa "regola" per cui anche se potrei usare classi top-level statiche è meglio utilizzare classe non statica con metodi statici...mentre per le nested va bene che sia statica anche la classe...

Quello che non capisco è il perchè ci sia questa differenza tra Top-level e nested??? Perchè introdurre questa regola?

Riguardo alle classi top level la questione è semplice. Una classe top level non è "membro" di qualcosa. Una classe top level è ovviamente in un package ma i package sono solo una questione a) di denominazione e b) strutturale (in termini di cartelle). Un package non è un tipo di dato. Quindi ripeto che una classe top level non è contenuta dentro un altro tipo. E quindi static NON ha senso.

In .NET ho letto adesso su https://msdn.microsoft.com/en-us/library/79b3xss3.aspx :
A static class is basically the same as a non-static class, but there is one difference: a static class cannot be instantiated..

The following list provides the main features of a static class:
* Contains only static members.

Ovviamente! Se non può essere istanziata non ha neanche membri "di istanza" e quindi potrà avere solo cose statiche. In .NET è così. In Java (che non c'entra nulla con .NET) è diverso. Stop.

Ne guadagno in termini di prestazioni/ottimizzazione?

No



E per finire, ricorda che in Java una classe che è dentro un'altra può essere:

* static che la fa diventare una "nested" (e io aggiungo sempre static, per chiarire) class. Che non ha nulla di particolare, se non il fatto che la classe top level è una sorta di "namespace" a livello di denominazione per la classe nested ( es. org.pincopalla.TopLevel.Nested come nome completamente qualificato).

* non static che la fa diventare una "inner" class. E qui è diverso. Una inner-class ha una relazione molto particolare con una specifica istanza della classe contenitore.