Sono in una situazione in cui è necessario mescolare un tratto definito in un altro pacchetto. Per facilitare il test, un metodo protetto in questo tratto è qualificato come pacchetto. Ecco un esempio:Ereditarietà di un metodo protetto da pacchetti con una classe in un pacchetto diverso
package A {
trait X {
protected[A] def method(arg: Int)
}
}
package B {
class Y extends A.X {
protected[A] def method(arg: Int) { }
}
}
compilazione questo con scalac 2.9.1 rendimenti:
test.scala:9: error: A is not an enclosing class
protected[A] def method(arg: Int) { }
Modifica della "protetto [A]" in classe Y a qualsiasi altro risultato accesso modificatori in questo:
test.scala:9: error: overriding method method in trait X of type (arg: Int)Unit;
method method has weaker access privileges; it should be at least protected[A]
override protected def method(arg: Int) { }
La mia domanda è questa: supponendo che la definizione di tratto X non possa cambiare, c'è qualche modifica alla classe Y che consentirebbe di estendere il tratto X? (pur mantenendo un certo livello di accesso "protetto")
Se ciò non è possibile, ci sono altre strategie progettuali consigliate per ovviare a questo problema? (oltre a rendere pubblico il "metodo")
Aggiungo che sto cercando di rispondere alla semplice domanda se questo sia impossibile in base alla progettazione, in modo tale che l'unico (semplice) modo di sistemare è quello di cambiare "protetto [A]" in "pubblico". Sembra solo una sottoclasse, indipendentemente dal pacchetto che dovrebbe essere in grado di accedere? o no? – nu11ptr
Sembra che la soluzione "giusta" qui sia quella di suddividere la definizione di classe Y in una classe e un tratto. Metterò il tratto in un sottoprogetto di A, definirò il 'metodo' lì, e poi lo mescolerò con la classe Y. Nel mondo reale, A è 'marketdata' e B è 'broker', quindi ha senso quando finalmente abbiamo un'istanza broker che è anche un fornitore di dati per dividere questa funzionalità, inserirla in un sotto-pacchetto di dati di mercato e mischiarla. Questo è probabilmente un progetto migliore in ogni caso, poiché sono due preoccupazioni completamente diverse (gestione degli ordini rispetto ai dati di mercato). – nu11ptr