scala - software - ¿Qué puedo hacer con las clases virtuales?

scala vs java

Question

He visto (y escuchado) bastante ruido al agregar clases virtuales a Scala (ya tiene tipos virtuales , según Martin Odersky ).

¿Cuál es la perspectiva de un laico (quizás con un ejemplo) sobre qué es un tipo virtual y qué podría ser posible si Scala tuviera clases virtuales?

( [No tengo experiencia con C o C ++, por lo que preferiría cualquier respuesta para no referirme a estos idiomas] ).

Answer 1

Los tipos virtuales son simples:

• Las clases y rasgos pueden tener miembros de tipo. P.ej

  trait Foo {
    type T
  }

• Se pueden refinar (pero no se pueden anular una vez definidos):

  class Foo1 extends Foo {
    type T <: AnyVal
  }
  
  class Foo2 extends Foo1 {
    override type T = Boolean
  }
  
  class Foo3 extends Foo2 {
    // override type T = Int // rejected by the compiler – would be unsound
  }

Aquí hay un ejemplo de clases virtuales en un lenguaje descendiente de Java ( cclass es una clase virtual):

Características de las clases virtuales

Veamos otro ejemplo para estudiar las posibilidades de las clases virtuales. Usaremos clases virtuales para ampliar una colaboración con una funcionalidad totalmente nueva. Digamos que tenemos un modelo de datos central para representar expresiones:

public cclass ExprModel {
   abstract public cclass Expr {}

   public cclass Constant extends Expr {
      protected int _val;
      public Constant(int val) { 
         _val = val;
      }                 
   }

   abstract public cclass BinaryExpr {
      protected Expr _left;
      protected Expr _right;
      public BinaryExpr(Expr left, Expr right) {
         _left = left;
         _right = right;
      }
   }

   public cclass Add extends BinaryExpr {}
   public cclass Mult extends BinaryExpr {} 
}

La colaboración define Expr como la clase base para todas las expresiones, clases concretas para representar constantes, suma y multiplicación. La clase BinaryExpr implementa la funcionalidad común de todas las expresiones con dos operandos. Tenga en cuenta que la versión actual de Caesar no admite constructores con parámetros y métodos abstractos en cclass. El siguiente código muestra cómo se pueden construir expresiones de muestra utilizando dicha colaboración:

public model.Expr buildSampleExpr(final ExprModel model) {
   model.Expr const1 = model.new Constant(-3);
   model.Expr const2 = model.new Constant(2);
   model.Expr op1 = model.new Mult(const1, const2);
   model.Expr const3 = model.new Constant(5);
   model.Expr op2 = model.new Add(op1, const3);
   return op2;
}

La colaboración define Expr como la clase base para todas las expresiones, clases concretas para representar constantes, suma y multiplicación. La clase BinaryExpr implementa la funcionalidad común de todas las expresiones con dos operandos.

Hay muchas funcionalidades diferentes relacionadas con las expresiones: su evaluación, formateo de expresiones a texto simple en infijo o postfijo, varias verificaciones de consistencia, búsquedas y transformaciones. Queremos mantener todas estas funciones específicas separadas unas de otras y del modelo de datos central. Esto se puede lograr con la ayuda de clases virtuales. Por ejemplo, la colaboración a continuación extiende el modelo central con una funcionalidad de formato de expresión simple:

public cclass ExprFormat extends ExprModel {
   abstract public cclass Expr {       
      abstract public void String format();
   }

   public cclass Constant {
      public void String format() { 
         return _val < 0 ? “(“ + _val + “)” : “” + _val; 
      }
   }

   abstract public cclass BinaryExpr {
      public void String format() { 
         return “(” + _left.format() + getOperSymbol() 
                    + _right.format() + “)”; 
      }
      abstract public void String getOperSymbol();
   }

   public cclass Add {
      public void String getOperSymbol() { return “+”; }
   }

   public cclass Mult {
      public void String getOperSymbol() { return “*”; }
   }
}

Este breve ejemplo muestra varias características de las clases virtuales:

• No es necesario repetir las relaciones de herencia entre las clases virtuales si ya están definidas en la supercollaboración. Por ejemplo, ExprModel define Constante como subclase de Expr. Significa que Constant también se asume implícitamente como subclase de Expr en ExprFormat.

• Las clases virtuales pueden usar los campos y métodos definidos en sus versiones anteriores. Por ejemplo, ExprFormat.BinaryExpr puede usar los campos _left y _right definidos en ExprModel.BinaryExpr.

• Se puede acceder a la funcionalidad definida en las clases virtuales anuladas sin conversiones de tipo. Por ejemplo, los campos _left y _right de BinaryExpr se declararon inicialmente con el tipo Expr de ExprModel, que no tiene formato de método (), pero en el contexto de ExprFormat, la nueva versión de Expr se asume como el tipo de _left y _right. Por lo tanto, se puede llamar a format () sin ningún tipo de conversión.

• Los métodos introducidos en las clases virtuales anuladas pueden volver a anularse de nuevo en las nuevas versiones de las subclases. Por ejemplo, Expr anulado introduce el formato de método (), que se puede anular en BinaryExpr. Si bien Add y Mult no anulan más este método, heredan el formato () de BinaryExpr.

Además de las propiedades demostradas, las clases virtuales anuladas también pueden

• introducir nuevos campos de datos,
• implementar nuevas interfaces,
• Introducir nuevas relaciones de herencia.