How to avoid abstract class pattern in Ruby? [closed] - ruby

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Abstract class looks in Ruby code like an alien from remote planet Java. I'm trying to collect Ruby tricks which can substitute this unwanted pattern.
Let's take a completely random example:
class AbstractRace < Struct.new(:runner_count)
def go!
runner_count.times.map do |index|
Thread.new do
run(index)
end
end.each(&:join)
end
def run(index)
raise 'To be implemented in derivative classes'
end
end
class RunnerRace < AbstractRace
def run(index)
puts "I am runner number #{index}. I am running"
end
end
class CarRace < AbstractRace
def run(index)
puts "I am car number #{index}. I am accelerating"
end
end
RunnerRace.new(2).go!
CarRace.new(2).go!
How to rewrite it? A possible approach would be using a mixin, like this:
require 'active_support/concern'
module Race
extend ActiveSupport::Concern
def go!
participant_count.times.map do |index|
Thread.new do
run(index)
end
end.each(&:join)
end
module ClassMethods
def configure_race(methods)
[:participant_count, :run].each do |method_symbol|
define_method method_symbol, methods[method_symbol]
end
end
end
end
class RunnerRace < Struct.new(:runner_count)
include Race
configure_race participant_count: ->() { runner_count },
run: ->(index) { puts "I am runner number #{index}. I am running" }
end
class CarRace < Struct.new(:car_count)
include Race
configure_race participant_count: -> { car_count },
run: ->(index) { puts "I am car number #{index}. I am going" }
end
RunnerRace.new(2).go!
CarRace.new(2).go!
What other solutions could be? Is there a common idiom for such case?

Answer 1

Why not just take advantage of the fact that Ruby is a dynamic language?
class Race
attr_reader :participants
def initialize(participants)
#participants = participants
end
def go!
participants.each_with_index.map do |index,participant|
Thread.new do
participant.run(index)
end
end.each(&:join)
end
end
class CarEntry
def run(index)
puts "I am car number #{index}. I am going"
end
end
There is no need for anything running in a 'race' to extend a superclass. All anything in the race must do is be capable of racing i.e having a
run(index)
method that does something.

Answer 2

In ruby I would tend to think of 'AbstractRace' as more of a role for a class to play. Roles are best encapsulated in modules (as you've suggested in your first response).
If you are trying to come up with a general ruby solution, however, I would recommend removing the reference to ActiveSupport::Concern. This module is something that comes from Rails and may not be available in all ruby environments.

Answer 3

There is nothing wrong with what you have written there and I'm not entirely sure what you are unhappy with.
That being said, this is Ruby and there is no need to define the run method on your AbstractRace class. If that's what is bothering you, then just don't do it.
The reason you put it there is to show both yourself and other developers who might be working on the code that a Race should have a run method. It's defining the interface. It definitely is not required though, but it is the "proper" way to make an object oriented class hierarchy.

Answer 4

I think you're missing the point of abstract classes
Languages like Java use abstract classes because they want to:
Collect common code for derived classes in one place (common base class), and
Prevent instantiating this common base class, because it is a base class.
If you wanted to achieve the same goals, you could do this by:
Creating a base class with the common code
Giving it a private constructor:
```
class AbstractRace
private:
def initialize
end
end
```
The other reason people use abstract classes, is the same as interfaces: they want to guarantee that some method exists on a derived class.
Unfortunately, there's no such construction as Ruby; in fact, this is "un-Ruby-like." In Ruby, we rely on "duck typing," which means "if it quacks, it's a duck!" Observe:
class Car
def drive
return 'VROOOM!'
end
end
class Duck
def quack
return 'Quack quack!'
end
end
test_objs = [Car.new, Duck.new]
test_objects.each do |some_obj|
if some_obj.respond_to?(:quack)
puts "#{some_obj} is a duck! #{some_obj.quack}"
else
puts 'Not a duck, sorry.
end
end
This will output something like <Duck:0x123456> is a duck! Quack quack!
This is relying on "duck typing," by checking for the existence of methods before using them. This is the closest idiom in Ruby.