2009-07-02 16 views
11

Entiendo que el modelo OO de Perl es bastante primitivo; es, en la mayoría de los aspectos, esencialmente un hack de espacio de nombres.¿Puedo crear interfaces tipo Java en Perl?

Sin embargo, me pregunto si es posible crear algo así como una "interfaz?" Mi objetivo es tener una clase base a partir de la cual se amplíen otras cuyo principal objetivo sea hacer obligatoria la implementación de ciertos métodos (por nombre está bien, sin firma necesaria) por esas subclases. Realmente no me importa si se trata de una clase "puramente virtual" (como una "interfaz" en Java) o una clase concreta con stubs de implementación reales para esos métodos en la superclase, pero lo que quiero es que sea determinísticamente necesario que el la subclase implementa ciertos métodos de la superclase.

¿Esto es posible? ¿Si es así, cómo?

+6

El OO de Perl no es primitivo, es solo una manera diferente de abordar el concepto. –

+0

Creo que quiso decir primitivo en términos de características ofrecidas. OO tiene algunos principios rectores, y la encapsulación es uno de ellos. Perl está haciendo (la mayoría de las veces) encapsulación por convención, a menos que uno use las bibliotecas más modernas, entonces sí, el OO de Perl es primitivo, confiando en que los futuros desarrolladores mantengan la convención en lugar de la estricta verificación de tiempo de compilación. Quiero decir, esta persona está pidiendo clases virtuales de interfaz/pura, y no está allí sin extensiones. Eso no es "completamente presentado". –

Respuesta

5

Creo que toda la idea de que obliga a la implementación/sobrecarga de las funciones de la clase base/subs es extranjera a Perl. ¿En qué punto imaginaría que el mecanismo de aplicación funciona?

Si está de acuerdo con hacer esto en tiempo de ejecución, puede morir si se llama a la implementación de su clase base.

EDITAR: En realidad, sí, Class :: Contract parece ser el camino a seguir.

10

No estoy seguro de cómo podrá implementarlo. Sin embargo, eche un vistazo a Moose, que es "Un sistema de objetos posmoderno para Perl 5".

+8

Con Moose, los roles pueden realizar la función de una interfaz Java. También pueden hacer más, pero un rol que solo tiene una lista de métodos requeridos es una interfaz. –

1

solución simple que crea errores en tiempo de ejecución:

package SomeVirtualClass; 

use strict; 
use warnings; 

use Carp; 

sub some_method { croak "virtual method some_method not overridden" } 
+0

Bueno, sí, sin dudas esta es una posibilidad. Sin embargo, para ser sincero, estaba buscando algo en un nivel más semántico. –

5

El Class::Contract puede ayudar con esto. Admite la verificación de contratos en tiempo de compilación.

26

Aquí es una respuesta utilizando Moose ...

package Comparable; 
use Moose::Role; 

requires 'eq'; 

package Person; 

has size => (
    is => 'ro', 
    does => 'Comparable', 
); 

Ahora el atributo de tamaño debe ser un objeto que implementa la "interfaz" comparable. En Moose-land, las interfaces son roles, y los roles pueden ser más que solo una definición de interfaz.

2

que tienen un patrón de peso ligero que llamo "compatible", y analizar el caso en mi respuesta a How important is it to indicate if a class implements an interface in Perl?

Es sólo una cuestión de pegarse paquetes seudo en @ISA:

our @ISA = qw<... X::Compatible ...>; 

Usted romper su código de si no haces lo que esperan del X. En la práctica, tengo un montón de comportamientos documentados que reutilizo, pero una clase que me dice que es X::Compatible es lo que uso para asegurarme de que puede hacer lo que espero.

Desde Perl 5.10 ha introducido el concepto DOES, que es lo más ligero, un objeto X::Compatible hereda de una clase base Object::Compatible que implementa una base DOES mirando a través de @ISA para /::Compatible$/ y respuesta de manera afirmativa por nada allí.La idea es que:

$object->DOES($x) == $object->isa($x . '::Compatible') 
Cuestiones relacionadas