Scala non ha una parola chiave statica , ma ha invece funzionalità simili tramite oggetti complementari. Dietro le quinte gli oggetti complementari sono compilati in classi che hanno metodi statici, quindi tutto questo è zucchero sintattico. Quali sono i vantaggi di questa scelta di design? Svantaggi? Gli altri linguaggi hanno costrutti simili?
Ecco alcuni motivi, che potrebbero essere più o meno interessanti per te, in base alle tue preferenze:
Non lo sconto semplicemente per essere "zucchero sintattico". Mentre puoi dire che qualcosa è solo zucchero sintattico, dopo tutto è lo zucchero che addolcisce la tua vita - come programmatore altrettanto bene come un caffè o un bevitore di tè.
Singleton - ogni Scala object è intrinsecamente un singleton. Considerando che nel mondo Java le persone stanno implementando singleton in tutti i modi diversi e più spesso che non finiscono per fare un errore nella loro implementazione, non si può fare un errore così semplice in Scala. Scrivere object invece di class lo rende un singleton e il gioco è fatto.
Accesso ai metodi statici: è possibile accedere ai metodi statici in Java dagli oggetti. Ad esempio, supponiamo di avere una classe C con un metodo statico f e un oggetto c di tipo C . Allora dovresti chiamare C.f , ma Java ti permette (anche se con un avvertimento) di usare c.f , che quando vieni dallo sfondo di Scala non ha alcun senso, perché gli oggetti fanno non ho un metodo f veramente.
Separazione chiara: in Java è possibile combinare attributi e metodi statici e non statici in una classe. Se lavori disciplinato, questo non diventa un problema, tuttavia, se tu (o qualcun altro per quella questione) non lo fai, allora finisci con parti statiche e non statiche intercalate ed è difficile dirlo a una rapida occhiata cosa è statico e cosa non lo è. In Scala, tutto ciò che si trova all'interno dell'oggetto companion non è chiaramente parte degli oggetti runtime della classe corrispondente, ma è disponibile da un contesto statico. Viceversa, se è scritto all'interno di una classe, è disponibile per le istanze di quella classe, ma non da un contesto statico. Ciò diventa particolarmente gravoso in Java, una volta che si iniziano ad aggiungere blocchi di inizializzazione statici e non statici alla classe. Questo può risultare molto difficile da comprendere in termini di ordine di esecuzione dinamico. È molto più chiaro in Scala, dove si inizializza l'oggetto companion dall'alto verso il basso e poi si esegue lo stesso per la classe in caso di creazione di un oggetto runtime.
Meno codice: non è necessario aggiungere la parola statica a ogni attributo o metodo in object , mantenendo così il codice più conciso (infatti, non è un vantaggio prominente in realtà).
Gli svantaggi sono molto più difficili da trovare. Si potrebbe obiettare che le parti statiche e non statiche dovrebbero appartenere, ma sono separate dal concetto di Scala di oggetti complementari. Ad esempio, può sembrare strano avere un diagramma di classe, ma poi finire per dover creare due cose nel codice e analizzare quale attributo va dove.
Un altro vantaggio è che object s può implementare interfacce / tratti, diversamente dai metodi statici.
Gli oggetti Companion sono il primo posto cercato per impliciti, dopo di che, scala guarda Predef e quindi in esplicite istruzioni "import" in quel particolare file sorgente.
Non sono abbastanza un java dev per sapere se il linguaggio java o le librerie forniscono meccanismi comparabili.
Leggi altre domande sui tag scala