Evitar pérdidas de memoria Scala - Scala constructores

Question

yo estaba trabajando a través de la "Programación en Scala" libro, y llamó la atención un poco de un problema en la implementación de la clase Rational en el Capítulo 6.

Ésta es mi primera versión de la clase Rational (basado en el libro)

class Rational(numerator: Int, denominator: Int) { 
    require(denominator != 0) 

    private val g = gcd(numerator.abs, denominator.abs) 

    val numer = numerator/g 
    val denom = denominator/g 

    override def toString = numer + "/" + denom 

    private def gcd(a: Int, b: Int): Int = 
    if(b == 0) a else gcd(b, a % b) 

    // other methods go here, neither access g 
} 

el problema aquí es que el campo g permanece durante toda la vida de la clase, incluso si nunca se accede de nuevo. Este problema se puede ver mediante la ejecución del siguiente programa de simulacro:

object Test extends Application { 

    val a = new Rational(1, 2) 
    val fields = a.getClass.getDeclaredFields 

    for(field <- fields) { 
    println("Field name: " + field.getName) 
    field.setAccessible(true) 
    println(field.get(a) + "\n") 
    } 

} 

Su producción va a ser:

Field: denom 
2 

Field: numer 
1 

Field: g 
1 

Una solución que encontré en el Scala Wiki consiste en lo siguiente:

class Rational(numerator: Int, denominator: Int) { 
    require(denominator != 0) 

    val (numer, denom) = { 
    val g = gcd(numerator.abs, denominator.abs) 
    (numerator/g, denominator/g) 
    } 

    override def toString = numer + "/" + denom 

    private def gcd(a: Int, b: Int): Int = 
    if(b == 0) a else gcd(b, a % b) 

    // other methods go here 
} 

Aquí, el campo g es solo local para su bloque, pero, al ejecutar la pequeña aplicación de prueba, encontré otro campo x$1 que conserva una copia de la tupla que consiste en (numer, denom)!

Field: denom 
2 

Field: numer 
1 

Field: x$1 
(1,2) 

¿Hay alguna manera de construir un racional en Scala con el algoritmo anterior, sin causar ninguna pérdida de memoria?

Gracias,

Flaviu Cipcigan

Answer 1

Usted puede hacer esto:

val numer = numerator/gcd(numerator.abs, denominator.abs) 
val denom = denominator/gcd(numerator.abs, denominator.abs) 

Por supuesto que tendría que hacer el cálculo en dos ocasiones. Pero luego las optimizaciones son a menudo una compensación entre memoria/espacio y tiempo de ejecución.

Quizás haya otras maneras también, pero entonces el programa puede volverse demasiado complejo, y si hay un lugar donde la optimización rara vez es prematura, es la optimización del poder del cerebro :). Por ejemplo, probablemente podría hacer esto:

val numer = numerator/gcd(numerator.abs, denominator.abs) 
val denom = denominator/(numerator/numer) 

Pero no necesariamente hace que el código sea más comprensible.

(Nota: Yo en realidad no intento esto, a fin de utilizar a su propio riesgo.)

Answer 2

Un objeto acompañante puede proporcionar la flexibilidad que necesita. Puede definir un método de fábrica "estático" que reemplace al constructor.

object Rational{ 

    def apply(numerator: Int, denominator: Int) = { 
     def gcd(a: Int, b: Int): Int = if(b == 0) a else gcd(b, a % b) 
     val g = gcd(numerator, denominator) 
     new Rational(numerator/g, denominator/g) 
    } 
} 

class Rational(numerator: Int, denominator: Int) { 
    require(denominator != 0) 

    override def toString = numerator + "/" + denominator 
    // other methods go here, neither access g 
} 

val r = Rational(10,200) 

En el alcance del método de fábrica g puede calcularse y utilizarse para derivar los dos valores de constructor.

Answer 3

Hay un pequeño problema con el ejemplo de Thomas Jung; todavía le permite crear un objeto racional con un término común en el numerador y el denominador - si se crea el objeto adecuado y con 'nuevo' a sí mismo, en vez de a través del objeto compañera:

val r = new Rational(10, 200) // Oops! Creating a Rational with a common term 

Usted puede evitar esto que requiere código de cliente para utilizar siempre el objeto compañero para crear un objeto racional, haciendo que el constructor privado implícita:

class Rational private (numerator: Int, denominator: Int) { 
    // ... 
} 

Answer 4

usted puede hacer esto:

object Rational { 
    def gcd(a: Int, b: Int): Int = 
     if(b == 0) a else gcd(b, a % b) 
} 

class Rational private (n: Int, d: Int, g: Int) { 
    require(d != 0) 

    def this(n: Int, d: Int) = this(n, d, Rational.gcd(n.abs, d.abs)) 

    val numer = n/g 

    val denom = d/g 

    override def toString = numer + "/" + denom 

} 

Answer 5

... en realidad, no veo cómo esto constituye una "pérdida de memoria".

Declara un campo final dentro del alcance de la instancia de la clase, y aparentemente se sorprende de que "se cuelga". ¿Qué comportamiento esperabas?

¿Falta algo aquí?

Answer 6

me encontré con este artículo que le puede resultar útil: http://daily-scala.blogspot.com/2010/02/temporary-variables-during-object.html

Parece que podría escribir esto:

class Rational(numerator: Int, denominator: Int) { 
    require(denominator != 0) 

    val (numer,denom) = { 
     val g = gcd(numerator.abs, denominator.abs) 
     (numerator/g, denominator/g) 
    } 

    override def toString = numer + "/" + denom 

    private def gcd(a: Int, b: Int): Int = 
    if(b == 0) a else gcd(b, a % b) 

    // other methods go here, neither access g 
} 

Answer 7

podría ser como:

def g = gcd(numerator.abs, denominator.abs) 

en lugar de val