Creating an Abstract Method

Problem

You want to define a method of a class, but leave it for subclasses to fill in the actual implementations.

Solution

Define the method normally, but have it do nothing except raise a NotImplementedError:

	class Shape2D
	 def area
	 raise NotImplementedError.
	 new("#{self.class.name}#area is an 
abstract method.")
	 end
	end

	Shape2D.new.area
	# NotImplementedError: Shape2D#area is an 
abstract method.

A subclass can redefine the method with a concrete implementation:

	class Square < Shape2D
	 def initialize(length)
	 @length = length
	 end

	 def area
	 @length ** 2
	 end
	end

	Square.new(10).area 	 # => 100

 

Discussion

Ruby doesn't have a built-in notion of an abstract method or class, and though it has many built-in classes that might be considered "abstract," it doesn't enforce this abstractness the way C++ and Java do. For instance, you can instantiate an instance of Object or Numeric, even though those classes don't do anything by themselves.

In general, this is in the spirit of Ruby. But it's sometimes useful to define a superclass method that every subclass is expected to implement. The NotImplementedError error is the standard way of conveying that a method is not there, whether it's abstract or just an unimplemented stub.

Unlike other programming languages, Ruby will let you instantiate a class that defines an abstract method. You won't have any problems until you actually call the abstract method; even then, you can catch the NotImplementedError and recover. If you want, you can make an entire class abstract by making its initialize method raise a NotImplementedError. Then no one will be able to create instances of your class:[4]

[4] Of course, unless you freeze the class afterwards, someone else can reopen your class, define an empty initialize, and then create instances of your class.

	class Shape2D
	 def initialize
	 raise NotImplementedError.
	 new("#{self.class.name} is an abstract class.")
	 end
	end

	Shape2D.new
	# NotImplementedError: Shape2D is an abstract class.

We can do the same thing in less code by defining a decorator method of Class that creates an abstract method by the given name.

	class Class
	 def 
abstract(*args)
	 args.each do |method_name|
	
	 define_method(method_name) do |*args|
	 if method_name == :initialize
	 msg = "#{self.class.name} is an abstract class."
	 else
	 msg = "#{self.class.name}##{method_name} is an abstract method."
	 end
	 raise NotImplementedError.new(msg)

	 end
	 end
	 end
	end

Here's an abstract class that defines an abstract method move:

	class Animal
	 abstract :initialize, :move
	end

	Animal.new
	# NotImplementedError: Animal is an abstract class.

Here's a concrete subclass that doesn't bother to define an implementation for the abstract method:

	class Sponge < Animal
	 def initialize
	 @type = :Sponge
	 end
	end

	sponge = Sponge.new
	sponge.move
	# NotImplementedError: Sponge#move is an abstract method.

Here's a concrete subclass that implements the abstract method:

	class Cheetah < Animal
	 def initialize
	 @type = :Cheetah
	 end

	 def move
	 "Running!"
	 end
	end

	Cheetah.new.move
	# => "Running!"

Abstract methods declared in a class are, by convention, eventually defined in the subclasses of that class. But Ruby doesn't enforce this either. An abstract method has a definition; it just happens to be one that always throws an error.

Since Ruby lets you reopen classes and redefine methods later, the definition of a concrete method can happen later in time instead of further down the inheritance tree. The Sponge class defined above didn't have a move method, but we can add one now:

	class Sponge
	 def move
	 "Floating on ocean currents!"
	 end
	end
	sponge.move
	# => "Floating on ocean currents!"

You can create an abstract singleton method, but there's not much point unless you intend to fill it in later. Unlike instance methods, singleton methods aren't inherited by subclasses. If you were to define Superclass.foo abstract, then define it for real as Subclass.foo, you would have accomplished little: Superclass.foo would still exist separately and would still be abstract.