2009-07-02 5 views
11

Je comprends que le modèle OO de Perl est plutôt primitif; il s'agit, à bien des égards, essentiellement d'un hack de l'espace de noms. Néanmoins, je me demande s'il est possible de créer quelque chose comme une «interface»? Mon but est d'avoir une classe de base à partir de laquelle d'autres sont étendues dont le but principal est de rendre obligatoire l'implémentation de certaines méthodes (par le nom est bien, aucune signature nécessaire) par ces sous-classes. Peu m'importe si c'est une classe "purement virtuelle" (comme une "interface" en Java) ou une classe concrète avec des stubs implémentationnels réels pour ces méthodes dans la superclasse, mais ce que je veux, c'est rendre déterministe le fait que sous-classe implémenter certaines méthodes de la superclasse.Puis-je créer des interfaces de type Java dans Perl?

Est-ce possible? Si c'est le cas, comment?

+6

Perl's OO n'est pas primitif, c'est juste une façon différente d'aborder le concept. –

+0

Je pense qu'il voulait dire primitif en termes de fonctionnalités offertes. OO a quelques principes directeurs, et l'encapsulation est l'un d'entre eux. Perl fait (la plupart du temps) de l'encapsulation par convention, sauf si on utilise les bibliothèques les plus modernes, donc oui, Perl's OO est primitif, en s'appuyant sur les futurs développeurs pour maintenir la convention au lieu d'une vérification stricte. Je veux dire, cette personne demande des interfaces/classes virtuelles pures, et ce n'est pas là sans extensions. Ce n'est pas "entièrement en vedette". –

Répondre

5

Je pense que l'idée de mandater la mise en œuvre/surcharge des fonctions de classe de base/sous-marins est étranger à Perl. À quel moment envisageriez-vous le mécanisme d'exécution?

Si cela vous convient au moment de l'exécution, vous pouvez mourir si l'implémentation de votre classe de base est appelée.

EDIT: En fait, oui, Class :: Contract semble être le chemin à parcourir.

10

Je ne sais pas comment vous pourrez l'implémenter. Cependant, jetez un oeil à Moose, qui est "Un système d'objet postmoderne pour Perl 5".

+8

Avec Moose, les rôles peuvent remplir la fonction d'une interface Java. Ils peuvent également faire plus, mais un rôle qui a juste une liste de méthodes requises est une interface. –

1

solution simple qui crée des erreurs lors de l'exécution:

package SomeVirtualClass; 

use strict; 
use warnings; 

use Carp; 

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

Eh bien, oui, sans doute c'est une possibilité. Pour être parfaitement honnête, je cherchais quelque chose à un niveau plus sémantique. –

5

Le Class::Contract peut aider avec ceci. Il prend en charge la vérification des contrats à la compilation.

26

est ici une réponse en utilisant Moose ...

package Comparable; 
use Moose::Role; 

requires 'eq'; 

package Person; 

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

Maintenant, l'attribut de taille doit être un objet qui implémente l'interface « » Comparable. Dans Moose-land, les interfaces sont des rôles, et les rôles peuvent être plus qu'une simple définition d'interface.

2

J'ai un modèle léger que j'appelle « Compatible », et je discuter dans ma réponse à How important is it to indicate if a class implements an interface in Perl?

Il est juste une question de coller des paquets pseudo dans @ISA:

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

Vous cassez leur code si vous ne faites pas ce qu'ils attendent de X. En pratique, j'ai un tas de comportements documentés que je réutilise, mais un cours qui me dit que c'est X::Compatible est ce que j'utilise pour m'assurer qu'il peut faire ce que j'attends.

Depuis perl 5.10 a introduit le concept DOES, qui est à peu près aussi léger, un objet X::Compatible hérite d'une classe de base Object::Compatible qui met en œuvre une base DOES en regardant à travers @ISA pour /::Compatible$/ et répondre par l'affirmative pour quoi que ce soit là-dedans.L'idée est la suivante:

$object->DOES($x) == $object->isa($x . '::Compatible') 
Questions connexes