Kotlin è conosciuto principalmente come una sostituzione drop-in per Java, ma si sbarazza di un ben noto costrutto Java: la parola chiave static . Invece, questa funzionalità a livello di classe è offerta principalmente da oggetti complementari.
Cosa c'è di sbagliato nei metodi e nei campi statici a cui gli oggetti associati forniscono un'alternativa migliore? Sono confuso riguardo la logica, e non ho trovato alcuna spiegazione nella documentazione.
Scala sostituisce anche le dichiarazioni a livello di classe con un oggetto "Singleton". Il principale vantaggio di questo è che tutto è un oggetto. In Java, i membri statici sono trattati in modo molto diverso rispetto ai membri dell'oggetto. Ciò significa che non puoi fare cose come implementare un'interfaccia o inserire l'istanza della classe in una mappa o passarla come parametro a un metodo che accetta Object. Gli oggetti Companion tengono conto di queste cose. Questo è il vantaggio.
Citando da Kotlin documenti di riferimento :
Note that, even though the members of companion objects look like static members in other languages, at runtime those are still instance members of real objects, and can, for example, implement interfaces.
Mi sembra molto che i progettisti di Kotlin considerino questo come un vantaggio rispetto ai membri statici di Java.
Inoltre, la parte relativa a Interoperabilità Java e membri statici spiega come gli oggetti companion possono essere utilizzati per creare membri che si comportano in modo efficace come membri statici quando annotati con @JvmStatic .
Kotlin è un linguaggio orientato agli oggetti. In un linguaggio orientato agli oggetti, qualcosa che non è un oggetto è una limitazione invalidante estremamente . Le classi non sono oggetti, ma oggetti sono oggetti (duh!), Quindi la domanda dovrebbe essere piuttosto: perché una lingua non usa oggetti complementari?
Un altro aspetto è la semplicità: perché due cose, oggetti con membri di istanza e classi con membri statici quando puoi semplicemente avere oggetti con membri di istanza?
Un'alternativa che viene usata in molte lingue derivate da Smalltalk, è di rendere le classi stesse oggetti. Per esempio. nelle classi Smalltalk sono istanze di una gerarchia parallela di metaclasses . In Ruby, le classi sono istanze della classe Class (e sì, ciò significa che Class è un'istanza di se stesso). In tal caso, i "metodi di classe" sono in realtà solo normali metodi di istanza del metaclasse della classe. Non so perché questo progetto non è stato scelto in Java (dato il suo stretto rapporto con Smalltalk), ma potrebbe avere qualcosa a che fare con la semplificazione del sistema di tipi (si noti che la maggior parte delle lingue con classi-come-oggetti tendono ad essere lingue dinamiche).
Leggi altre domande sui tag language-design