Ho letto che non esiste alcun pacchetto privato (predefinito in Java) in scala e utilizzare l'accesso pubblico per impostazione predefinita.Accesso pubblico predefinito in scala
Quali sono le motivazioni di questa scelta? È una buona pratica visto che l'accesso pubblico predefinito rende tutto visibile, quindi parte dell'API?
Ciò significa digitare in eccesso per incapsulare i campi e i metodi (che sia privato, ambito privato, protetto, accesso).
Questo è qualcosa che dà a molte persone qualche problema. Suggerirei di dare una lettura a this (in realtà l'intera serie).
L'immutabilità impedisce anche alcuni dei divertimenti che generalmente si verificano con tale accesso. Potrebbe essere vero che "c'è più tipizzazione", ma guardando gli IDE, essi sono responsabili di molto fango, in quanto qualsiasi metodo generato dall'IDE è di solito pubblico, il che non è sempre valido.
Secondo Programming Scala, sembra che il pubblico di default è dovuto principalmente alla uniform access principle, in cui l'overloading degli operatori permettono di definire la getter come field = newvalue
In Java è molto più facile di scegliere 'pacchetto-privato' come il default perché è una delle sole tre possibilità lì.
In Scala è possibile scegliere tra l'accesso del pubblico (public), l'accesso pacchetto-privato con l'ereditarietà (protected[C]), l'accesso pacchetto-privata senza eredità (private[C]), l'accesso di classe-privato (private), l'accesso agli oggetti-privato (private[this]), accesso all'ereditarietà (protected), accesso protected[this] (qualunque cosa si possa chiamare) e, in aggiunta, si ha una specie di modificatore di accesso privato ai file (sealed).
È difficile selezionare un valore predefinito diverso da public.
(Considerando i metodi interni, si potrebbe anche aggiungere metodo-privato alla lista ...)
Hai sollevato un punto valido, ancora direi, anche se scala dà più e meglio (coerenza in ambito protetto) scelta, il default dovrebbe essere qualcosa che nasconde l'implementazione. In questo senso, l'accesso privato al pacchetto senza ereditarietà (privato [C]) nella tua dichiarazione. Non mi dispiace scrivere a macchina in più e sono d'accordo che è facile con IDE, chiedendo ancora una migliore logica della scelta. – bsr
Ma allora quanto spesso avresti bisogno di 'privato [C]'? E inoltre, dal momento che è possibile nidificare i pacchetti, quale pacchetto o classe sarebbe 'C' essere? Il più esterno sarebbe inutile, il più interno sarebbe la classe in cui è definito il membro, quindi sarebbe semplicemente "privato". Ancora un'opzione valida, naturalmente; è soprattutto la cosa del pacchetto che diventa complicata. – Debilski
Ma beh, è difficile discutere comunque perché è proprio così e non è così male come potrebbe sembrare. – Debilski
Scala ha una maggiore flessibilità nella scelta della visibilità di qualcosa di Java, anche se alcuni di regole di visibilità Java, legato alla le classi annidate non sono traducibili in Scala.
E, sì, c'è il pacchetto privato in Scala. È scritto come private[package] in Scala.
Il motivo per cui Scala rende public l'impostazione predefinita è perché è la visibilità più comune utilizzata. La "digitazione extra" è in realtà less digitando, perché è molto più raro rendere i membri privati o protetti.
Un'eccezione a tale regola in Java è campi, che devono essere resi privati in modo da poter modificare i dettagli dell'implementazione senza rompere i client. Una conseguenza pratica di ciò sono le classi con campi e poi getter e setter per ogni campo.
In Scala, poiché è possibile sostituire uno o uno var con lo def corrispondente, non è necessario.
'è molto più raro rendere i membri privati o protetti ' potrebbe essere vero per gli attributi con getter e/o setter, ma non sono d'accordo nel caso generale. Esistono molti più dettagli di implementazione privati rispetto all'API pubblica, poiché l'API espone metodi di livello superiore – Dici
beh .. in realtà ho letto qui (http://joelabrahamsson.com/entry/learning-scala-uniform-access-principle) che il compilatore inserisce un getter per un accesso uniforme.Ma l'accessor è pubblico – bsr
Per un principio di accesso uniforme dovrebbe bastare che i livelli di accesso predefiniti per campi e metodi siano uguali, non è necessario che siano entrambi pubblici. –