Comment mettre en œuvre une classe abstraite en ruby?

Je n'aime pas utiliser les classes abstraites en Ruby (il n'y a presque toujours une meilleure façon). Si vous pensez vraiment que c'est la meilleure technique pour la situation même si, vous pouvez utiliser le code suivant pour être plus déclaratif sur les méthodes sont abstraites:

module Abstract
  def abstract_methods(*args)
    args.each do |name|
      class_eval(<<-END, __FILE__, __LINE__)
        def #{name}(*args)
          raise NotImplementedError.new("You must implement #{name}.")
        end
      END
      # important that this END is capitalized, since it marks the end of <<-END
    end
  end
end

require 'rubygems'
require 'rspec'

describe "abstract methods" do
  before(:each) do
    @klass = Class.new do
      extend Abstract

      abstract_methods :foo, :bar
    end
  end

  it "raises NoMethodError" do
    proc {
      @klass.new.foo
    }.should raise_error(NoMethodError)
  end

  it "can be overridden" do
    subclass = Class.new(@klass) do
      def foo
        :overridden
      end
    end

    subclass.new.foo.should == :overridden
  end
end

Fondamentalement, il vous suffit d'appeler abstract_methods avec la liste des méthodes sont abstraites, et quand ils obtiennent appelé par une instance de la classe abstraite, un NotImplementedError exception sera levée.

Essayez ceci:

class A
  def initialize
    raise 'Doh! You are trying to instantiate an abstract class!'
  end
end

class B < A
  def initialize
  end
end

Mes 2 cents: j'opte pour une solution simple, léger DSL mixin:

module Abstract
  extend ActiveSupport::Concern

  included do

    # Interface for declaratively indicating that one or more methods are to be
    # treated as abstract methods, only to be implemented in child classes.
    #
    # Arguments:
    # - methods (Symbol or Array) list of method names to be treated as
    #   abstract base methods
    #
    def self.abstract_methods(*methods)
      methods.each do |method_name|

        define_method method_name do
          raise NotImplementedError, 'This is an abstract base method. Implement in your subclass.'
        end

      end
    end

  end

end

# Usage:
class AbstractBaseWidget
  include Abstract
  abstract_methods :widgetify
end

class SpecialWidget < AbstractBaseWidget
end

SpecialWidget.new.widgetify # <= raises NotImplementedError

Et, bien sûr, l'ajout d'une autre erreur pour l'initialisation de la classe de base serait négligeable dans ce cas.

Dans les derniers 6 ans 1/2 de programmation Ruby, je n'ai pas nécessaire une classe abstraite une fois.

Si vous pensez vous avez besoin d'une classe abstraite, vous êtes trop réfléchir dans un langage qui fournit/nécessite, non pas en Ruby, en tant que tel.

Comme d'autres l'ont suggéré, un mixin est plus approprié pour les choses qui sont censé être des interfaces (comme Java définit), et de repenser votre modèle est plus approprié pour des choses que le "besoin" de classes abstraites à partir d'autres langages comme C++.

Mise à jour 2019: je n'ai pas besoin classes abstraites en Ruby dans 16½ des années d'utilisation. Tout ce que tous les gens commentant ma réponse dites est adressée par le fait de l'apprentissage de Ruby et en utilisant les outils appropriés, comme des modules (qui même vous donner communes des implémentations). Il y a des gens sur les équipes, j'ai réussi, qui ont créé des classes qui ont de la base de la mise en œuvre qui ne parviennent pas (comme une classe abstraite), mais ce sont principalement des déchets de codage car NoMethodError produirait exactement le même résultat qu'un AbstractClassError dans la production.

Personnellement je relance NotImplementedError dans les méthodes de classes abstraites. Mais vous voudrez peut-être laisser sortir de la "nouvelle " méthode", pour les raisons que vous avez mentionnées.

Quel but êtes-vous essayer de servir avec une classe abstraite? Il y a sans doute une meilleure façon de le faire en ruby, mais vous n'avez pas donné de détails.

Mon pointeur est-ce; utiliser un mixin pas l'héritage.

J'ai fait de cette façon, il redéfinit de nouvelles sur les enfants de la classe de trouver un nouveau non classe abstraite.
Je ne vois pas de pratique dans l'utilisation de classes abstraites en ruby.

puts 'test inheritance'
module Abstract
  def new
    throw 'abstract!'
  end
  def inherited(child)
    @abstract = true
    puts 'inherited'
    non_abstract_parent = self.superclass;
    while non_abstract_parent.instance_eval {@abstract}
      non_abstract_parent = non_abstract_parent.superclass
    end
    puts "Non abstract superclass is #{non_abstract_parent}"
    (class << child;self;end).instance_eval do
      define_method :new, non_abstract_parent.method('new')
      # # Or this can be done in this style:
      # define_method :new do |*args,&block|
        # non_abstract_parent.method('new').unbind.bind(self).call(*args,&block)
      # end
    end
  end
end

class AbstractParent
  extend Abstract
  def initialize
    puts 'parent initializer'
  end
end

class Child < AbstractParent
  def initialize
    puts 'child initializer'
    super
  end
end

# AbstractParent.new
puts Child.new

class AbstractChild < AbstractParent
  extend Abstract
end

class Child2 < AbstractChild

end
puts Child2.new

Rien de mal avec votre approche. Générer une erreur dans initialiser semble bien, aussi longtemps que l'ensemble de vos sous-classes remplacer initialiser bien sûr. Mais vous ne voulez pas définir de soi.des nouvelles comme ça. Voici ce que je ferais.

class A
  class AbstractClassInstiationError < RuntimeError; end
  def initialize
    raise AbstractClassInstiationError, "Cannot instantiate this class directly, etc..."
  end
end

Une autre approche serait de mettre tout ce que la fonctionnalité dans un module, qui comme vous l'avez mentionné ne peut jamais être instiated. Ensuite inclure ce module dans vos classes plutôt que d'en hériter d'une autre classe. Cependant, ce serait de casser des choses comme super.

Donc, cela dépend de la façon dont vous voulez de la structure. Bien que les modules sembler comme une solution de nettoyage pour résoudre le problème de "Comment puis-je écrire des trucs qui est destiné à d'autres classes à utiliser"