I am working with Elasticsearch persistence model, and have some common methods for each index.
Given an Events Index, I have a service class where some methods are defined, the same goes for other n indexes built of their models.
class EventSearchService
class << self
def with_index(index_name)
old_repository = repository
#repository = EventSearchService::ElasticsearchEventRepository.new(index_name: index_name)
yield
ensure
#repository = old_repository
end
def index_name
repository.index_name
end
def index_all(event_documents)
return unless event_documents.present?
actions = event_documents.map do |e|
{ index: { _index: index_name, _id: e.id, _type: "_doc", data: e.to_hash }}
end
repository.client.bulk(body: actions)
end
protected
def repository
#repository ||= EventSearchService::ElasticsearchEventRepository.new
end
end
end
My problem is that I have ended up with n files with the same class methods. When I try to extract it out to an abstract class directly, I get an error whose investigation reaches me to a point that singleton classes can't be inherited.
After searching for some answers, I followed this thread and I tried to DRY it up
require 'forwardable'
require 'singleton'
class ElasticsearchService
include Singleton
class << self
extend Forwardable
def_delegators(
:with_index,
:index_name,
:index_all,
:repository
)
end
def with_index(index_name)
old_repository = repository
#repository = search_repository.new(index_name: index_name)
yield
ensure
#repository = old_repository
end
def index_name
repository.index_name
end
def index_all(documents)
return unless documents.present?
actions = documents.map do |d|
{ index: { _index: index_name, _id: d.id, _type: "_doc", data: e.to_hash }}
end
repository.client.bulk(body: actions)
end
def search_repository
fail "Needs to be overriden"
end
protected
def repository
#repository ||= search_repository.new
end
end
And I include it as
class EventSearchService < ElasticsearchService
def search_repository
EventSearchService::ElasticsearchEventRepository
end
end
I have redacted the code to keep it small, simple, and related to the cause, but wanted to show different aspects of it. Sorry if it's too long a read.
The error I get is:
`<class:ElasticsearchService>': undefined local variable or method `' for ElasticsearchService:Class (NameError)
This one is very sneaky. There are some non-ASCII space characters inside your code which the ruby interpreter is recognizing as the name of a method that's being called.
I threw your code inside my terminal, getting precisely the same error as you, but after writing it by hand and executing method by method, did not get it.
Found a conversor online and after copy/pasting your code (here's the link to the one I used), the code ran without that error.
So formatting the file properly should do the trick with that particular error you're experiencing.
Related
I am implementing 'service objects' as per a workshop I've been studying, I'm building a reddit API application. I need the object to return something, so I can't just execute everything in the initializer. I have these two options:
Option1: Class needs instantiating
class SubListFromUser
def user_subscribed_subs(client)
#client = client
#subreddits = sort_subs_by_name(user_subs_from_reddit)
end
private
def sort_subs_by_name(subreddits)
subreddits.sort_by { |sr| sr[:name].downcase }
end
def user_subs_from_reddit
#client.subscribed_subreddits :limit => 100
end
end
Called with:
#subreddits = SubListFromUser.new(#client).user_subscribed_subs
Or Option2 is having it as a class method:
class SubListFromUser
def self.user_subscribed_subs(client)
sort_subs_by_name(client, user_subs_from_reddit)
end
private
def self.sort_subs_by_name(subreddits)
subreddits.sort_by { |sr| sr[:name].downcase }
end
def self.user_subs_from_reddit(client)
client.subscribed_subreddits :limit => 100
end
end
Called with:
#subreddits = SubListFromUser.user_subscribed_subs(#client)
What is considered 'best practice' in this situation? Is there a reason I shouldn't be using object.new(args).method? I think it gives a cleaner service class but I'm not sure of the technicalities of this approach and if it has disadvantages.
Edit: Or option3 - I'm going about this all wrong and there is a better approach :)
In many cases you'll need to keep a state for the process lifecycle, such as the client. Instead of having it "travel" through all methods you need it, as an argument, it makes more sense to keep it as a class variable. But for the sake of cleaner syntax, I recommend to combine the two approaches:
class SubListFromUser
def initialize(client)
#client = client
end
private_class_method :new # only this class can create instances of itself
def user_subscribed_subs
#subreddits = sort_subs_by_name(user_subs_from_reddit)
end
private
def sort_subs_by_name(subreddits)
subreddits.sort_by { |sr| sr[:name].downcase }
end
def user_subs_from_reddit
#client.subscribed_subreddits :limit => 100
end
class << self
def user_subscribed_subs(client)
new(client).user_subscribed_subs # create instance of this class and run a process
end
end
end
Call as a class method:
#subreddits = SubListFromUser.user_subscribed_subs(#client)
In Ruby, I don't find that there's much of a difference.
I find the use of class variables in your "static" version a bit disturbing.
I think the class version might lead to more-creative re-use through subclassing, but that brings its own set of headaches unless things are designed as correctly as possible.
I have tried several way to rspec the 'to_type' function. The fact that it is inside the class means that only the class should be able to call it right? I've tried to include the Class in my rspec but the module "Format" is still not recognized. Any ideas how I can rspec this method 'to_type' from the module?
class Loom::Lma < Loom::Base
module Format
STANDARD_FORMATS = {
1 => '0',
2 => '13.4',
}
def to_type(format)
# type is calculated here then return type
# for instance
return :date
end
module_function :to_type
end
def initialize()
#init stuff
end
def otherstuff()
#another function
end
end
RSPEC
it 'type should not be :date' do
include Loom::Lma
Format.to_type('some string format').should_not eq(:date)
end
Any ideas?
Are you sure you want to put that module into a class not the other way around?
Anyway, you can access to_type like this:
Loom::Lma::Format.to_type()
I'm currently trying to achieve something similar to what is proposed in the chosen answer of this question: Ruby design pattern: How to make an extensible factory class?
class LogFileReader
##subclasses = { }
def self.create type
c = ##subclasses[type]
if c
c.new
else
raise "Bad log file type: #{type}"
end
end
def self.register_reader name
##subclasses[name] = self
end
end
class GitLogFileReader < LogFileReader
def display
puts "I'm a git log file reader!"
end
register_reader :git
end
class BzrLogFileReader < LogFileReader
def display
puts "A bzr log file reader..."
end
register_reader :bzr
end
LogFileReader.create(:git).display
LogFileReader.create(:bzr).display
class SvnLogFileReader < LogFileReader
def display
puts "Subersion reader, at your service."
end
register_reader :svn
end
LogFileReader.create(:svn).display
The unit tests work flawlessly, but when I start the server no class is being registered. May I be missing something about how the static method call is working? When is the register_reader call made by each subclass?
To answer the OP's question about when the classes call register_reader, it happens when the file is loaded. Add this code to an initializer to load the files yourself.
Dir[Rails.root.join('path', 'to', 'log_file_readers', '**', '*.rb').to_s].each { |log_file_reader| require log_file_reader }
I am trying to learn Ruby by reading tutorials on Class Variables.
The code creates a "Worker" object, a class variable is created to keep track of which instance of Worker was created by the user last.
I have copied the code from the author but I get the error:
undefined method `latest' for Worker:Class (NoMethodError)
The code I have found is:
class Worker
attr_writer :number_of_jobs
def initialize(name, job)
#name = name
#job = job
##latest = #name
##job = #job
puts "Lets get started"
end
def new_job(job)
#job = job
puts "I moved to #{job}!"
self.fetch_info
end
def name_update(name_new)
#name = name_new
puts "My new name is #{name_new}."
self.fetch_info
end
def fetch_info
puts "I'm #{#name} in #{#location}."
end
def job_score
return "#{#number_of_jobs * 10}Fg"
end
protected
def are_you_worker?(guest_name)
puts "Yes #{guest_name}, I am a worker!"
return true
end
private
def text_a_message(message)
puts message
end
public
def tell_friend(where)
text_a_message("I just applied to #{where}")
end
end
#running the code
Worker1 = Worker.new("Steve", "Support")
Worker2 = Worker.new("Alan", "PA")
puts Worker.latest
Can anybody see why?
The Class variables are private inside this class which is causing a problem. Therefore accessing the Worker.latest variable will cause an error as it isn't visible from instances outside of the class (but it is created and set).
Additionally, attributes are part of the object not the class so you shouldn't have an attribute for this class . In native Ruby the class variables are not accessible from outside EXCEPT through a class method (there are extensions in Rails for them tho).
Hope that helps
IMHO, this is one of the more frustrating things about Ruby's class system. The privacy of class variables is true even for subclasses. In any case, the immediate solution to your problem is to add a class method like so:
class Worker
def self.latest
##latest
end
end
I want to simulate an abstract class in Ruby on Rails. I.e. I want to raise an exception if someone tries to call Abstract.new, but he should be able to call Child.new (while Child < Abstract).
How to do this? Overwriting both new and initialize does not work.
In another comment, the OP mentions that the purpose of the abstract class is to share behavior (methods) needed by its children. In Ruby, that's often best done with a module used to "mix in" methods where needed. For example, instead of:
class Abstract
def foo
puts "foo!"
end
end
class Concrete
end
Concrete.new.foo # => "foo!"
this:
module Foo
def foo
puts "foo!"
end
end
class Concrete
include Foo
end
Concrete.new.foo # => "foo!"
But here's how the original request might be satisfied:
#!/usr/bin/ruby1.8
class Abstract
def initialize(*args)
raise if self.class == Abstract
super
end
end
class Concrete < Abstract
end
Concrete.new # OK
Abstract.new # Raises an exception
Why would you want to do this? The point of abstract/interfaced classes are to hack Strongly typed languages into a dynamic paradigm. If you need your class to fit in the signature, name your methods according to the original class or make a facade and plug it in, no need to trick a compiler into allowing it, it just works.
def my_printer obj
p obj.name
end
So I defined the interface as any object with a name property
class person
attr_accessor :name
def initialize
#name = "Person"
end
end
class Employee
attr_accessor :name
def initialize
#name = "Employee"
#wage = 23
end
end
so nothing stops us from calling our printer method with either of these
my_printer Person.new
my_printer Employee.new
both print there names without a hitch :D
You almost always need to do this to enforce an API, when some third party is going to implement some stub, and you're sure they're going to mess it up. You can use specific prefix-templates in your parent class and a module that introspects on creation to achieve this:
module Abstract
def check
local = self.methods - Object.methods
templates = []
methods = []
local.each do |l|
if l =~ /abstract_(.*)/ # <--- Notice we look for abstract_* methods to bind to.
templates.push $1
end
methods.push l.to_s
end
if !((templates & methods) == templates)
raise "Class #{self.class.name} does not implement the required interface #{templates}"
end
end
end
class AbstractParent
include Abstract
def initialize
check
end
def abstract_call # <--- One abstract method here
end
def normal_call
end
end
class Child < AbstractParent # <-- Bad child, no implementation
end
class GoodChild < AbstractParent
def call # <-- Good child, has an implementation
end
end
Test:
begin
AbstractParent.new
puts "Created AbstractParent"
rescue Exception => e
puts "Unable to create AbstractParent"
puts e.message
end
puts
begin
Child.new
puts "Created Child"
rescue Exception => e
puts "Unable to create Child"
puts e.message
end
puts
begin
GoodChild.new
puts "Created GoodChild"
rescue Exception => e
puts "Unable to create GoodChild"
puts e.message
end
Result:
[~] ruby junk.rb
Unable to create AbstractParent
Class AbstractParent does not implement the required interface ["call"]
Unable to create Child
Class Child does not implement the required interface ["call"]
Created GoodChild
If you want this for doing STI, you could follow the suggestions in this thread:
class Periodical < ActiveRecord::Base
private_class_method :new, :allocate
validates_presence_of :type
end
class Book < Periodical
public_class_method :new, :allocate
end
class Magazine < Periodical
public_class_method :new, :allocate
end
Caveat: I'm not sure if this is a working solution. This hides new and allocate in the base class and re-enables them in child classes -- but that alone does not seem to prevent objects being created with create!. Adding the validation on type prevents the base class from being created. I guess you could also hide create!, but I'm not sure if that covers all the ways Rails can instantiate a model object.