I have the 3 following classes:
Base
module TitleSource
class Base
include Comparable
attr_accessor :company
attr_accessor :priority
attr_accessor :target_title
def initialize(args={})
self.company = args[:company]
self.priority = args[:priority]
self.target_title = args[:target_title]
end
def create_contact_source
raise NotImplementedError
end
def <=>(other)
fetch_value <=> other.fetch_value
end
protected def fetch_value
value
end
private def value
raise NotImplementedError
end
end
end
UnmatchedTitle
module TitleSource
class UnmatchedTitle < Base
def create_contact_source
::ContractorUi::ContactSource.generate_from_unmatched_title(self)
end
private def value
100
end
end
end
IncompleteContact
module TitleSource
class IncompleteContact < Base
attr_accessor :target_title_name
attr_accessor :contact
def initialize(args={})
super
self.target_title_name = args[:target_title_name]
self.contact = args[:contact]
end
def create_contact_source
::ContractorUi::ContactSource.generate_from_incomplete_contact(self)
end
private def value
10
end
end
end
I'm currently reading POODR and came up with this design, which so far served me well.
However, for didactical reasons, I would like to know how I can remove the dependency on ::ContractorUi::ContactSource if it's worth it and if it should be done.
I don't like the idea of passing it in with the constructor because the entire purpose of TitleSource module is to actually generate a ContactSource, but would like to hear from more experienced people. Reading the book (and some on-the-field experience) allowed me to understand how much decoupling is important
I can confirm that having a single dependency is not a big issue in this case. Based on POODR, this code can react to changes well enough, so keeping the class dependency in this case is fine, expecially considering it's the main purpose of the entire class, to generate an instance of ContactSource
Related
I've got a class such as
# this has been simplified for the example
class MyClass
##private_attributes = []
def self.private_attributes(*args)
##private_attributes = args
end
def private_attributes
#private_attributes ||= ##private_attributes
end
end
It works great. I've this ##private_attributes set at class level which's then used at instance level in multiple ways.
I want to abstract this logic somewhere else to simplify my class, something like that
class MyClass
include PrivateAttributes
end
When I create the module PrivateAttributes, however I shape it, the ##private_attributes isn't understood at MyClass level.
I tried many things but here's the latest code attempt
module PrivateAttributes
include ProcessAttributes
def self.included(base)
base.extend(ClassMethods)
base.include(InstanceMethods)
end
module ClassMethods
##private_attributes = []
def private_attributes(*args)
##private_attributes = args
end
end
module InstanceMethods
def private_attributes
#private_attributes ||= process_attributes_from(##private_attributes)
end
def private_attributes?
instance_options[:scope] == :private
end
end
end
It crashes with this error
NameError:
uninitialized class variable ##private_attributes in PrivateAttributes::InstanceMethods
Did you mean? private_constant
In short, the ##private_attributes isn't transferred throughout the code, but looks like it stays at the module level.
What's the best way to abstract this logic from my original class ?
Working solution
An easy workaround is to use mattr_accessor on the class level or anything similar to communicate our data around. I preferred to write down my own methods in this case:
module PrivateAttributes
include ProcessAttributes
def self.included(base)
base.extend(ClassMethods)
base.include(InstanceMethods)
end
module ClassMethods
##private_attributes_memory = []
def private_attributes(*args)
##private_attributes_memory = args
end
def private_attributes_memory
##private_attributes_memory
end
end
module InstanceMethods
def private_attributes
#private_attributes ||= process_attributes_from private_attributes_memory
end
# you can add diverse methods here
# which will be used in MyClass once included
private
def private_attributes_memory
self.class.private_attributes_memory
end
end
end
In Rails we can define a class like:
class Test < ActiveRecord::Base
before_initialize :method
end
and when calling Test.new, method() will be called on the instance. I'm trying to learn more about Ruby and class methods like this, but I'm having trouble trying to implement this in plain Ruby.
Here's what I have so far:
class LameAR
def self.before_initialize(*args, &block)
# somehow store the symbols or block to be called on init
end
def new(*args)
## Call methods/blocks here
super(*args)
end
end
class Tester < LameAR
before_initialize :do_stuff
def do_stuff
puts "DOING STUFF!!"
end
end
I'm trying to figure out where to store the blocks in self.before_initialize. I originally tried an instance variable like #before_init_methods, but that instance variable wouldn't exist in memory at that point, so I couldn't store or retrieve from it. I'm not sure how/where could I store these blocks/procs/symbols during the class definition, to later be called inside of new.
How could I implement this? (Either having before_initialize take a block/proc/list of symbols, I don't mind at this point, just trying to understand the concept)
For a comprehensive description, you can always check the Rails source; it is itself implemented in 'plain Ruby', after all. (But it handles lots of edge cases, so it's not great for getting a quick overview.)
The quick version is:
module MyCallbacks
def self.included(klass)
klass.extend(ClassMethods) # we don't have ActiveSupport::Concern either
end
module ClassMethods
def initialize_callbacks
#callbacks ||= []
end
def before_initialize(&block)
initialize_callbacks << block
end
end
def initialize(*)
self.class.initialize_callbacks.each do |callback|
instance_eval(&callback)
end
super
end
end
class Tester
include MyCallbacks
before_initialize { puts "hello world" }
end
Tester.new
Left to the reader:
arguments
calling methods by name
inheritance
callbacks aborting a call and supplying the return value
"around" callbacks that wrap the original invocation
conditional callbacks (:if / :unless)
subclasses selectively overriding/skipping callbacks
inserting new callbacks elsewhere in the sequence
... but eliding all of those is what [hopefully] makes this implementation more approachable.
One way would be by overriding Class#new:
class LameAR
def self.before_initialize(*symbols_or_callables, &block)
#before_init_methods ||= []
#before_init_methods.concat(symbols_or_callables)
#before_init_methods << block if block
nil
end
def self.new(*args, &block)
obj = allocate
#before_init_methods.each do |symbol_or_callable|
if symbol_or_callable.is_a?(Symbol)
obj.public_send(symbol_or_callable)
else
symbol_or_callable.(obj)
end
end
obj.__send__(:initialize, *args, &block)
end
end
class Tester < LameAR
before_initialize :do_stuff
def do_stuff
puts "DOING STUFF!!"
end
end
How does the look-path decide where to call "super" if I have a module included along with class inheritance. My hunch is that by default it will use the initialize method in the module. Is this correct? And if so, how do I explicitly tell the code to use the initialize method in the inherited class instead?
Posted below is an example:
I want the Employee class to inherit initialize from Other and not Subject.
module Subject
def initialize
#observers = []
end
end
class Other
def initialize
#other_stuff = []
end
end
class Employee < Other
include Subject
attr_reader :name
def initialize(name)
super()
end
end
My hunch is that by default it will use the initialize method in the module.
Correct. If a class includes a module then the methods of that module will be replace inherited methods of the same name.
And if so, how do I explicitly tell the code to use the initialize method in the inherited class instead?
You're probably best off refactoring so that you don't have this problem.
However, there are several ways you could make Other's initialize method get called instead of Subject's.
How about something like this:
module Subject
def initialize
puts "subject initialize"
#observers = []
end
end
class Other
def initialize
puts "other initialize"
#other_stuff = []
end
end
class Employee < Other
alias_method :other_initialize, :initialize
include Subject
attr_reader :name
def initialize(name)
other_initialize
end
end
Employee.new('test')
If you run this, you'll see that Other's initialize method is called. Writing code like this is not a good idea, however.
Is this good practice? Storing objects accessed by a constant. There are plenty of ways to store objects to be accessed by other classes for processing. Using constants instead as means to store hash objects that point to collections is something I recently started doing besides * ##class_variables. What would be the pro's / con's to this if there are any? Not really new to OOP but any insight what would be bad practice would be appreciated.
#!/usr/bin/env ruby
OUTSIDE_STATE = true
NAMES = {:objects => []}
module CheckSelf
module ClassMethods
def self.inherited(child)
::NAMES[:objects] << child
end
def select_and_make_calls
_selected = NAMES[:objects].select {|child|
child.purpose()
}.each {|child|
# _child = child.new(child)
child.new(child).call_out
}
end
end
module InstanceMethods
def call_out
puts "FIRING OFF THE CALLS #{self.class}"
end
end
def self.included(receiver)
receiver.extend ClassMethods
receiver.send :include, InstanceMethods
end
end
class Parent
def initialize(name)
#name = name
end
include CheckSelf
# The inherited class must be defined in the *
# Body of the class.
def self.inherited(child)
NAMES[:objects] << child
end
end
class ObjectOne < Parent
def self.purpose
OUTSIDE_STATE
end
end
class ObjectTwo < Parent
def self.purpose
true
end
end
Parent.select_and_make_calls
I recommend against using constants to store changing data. Using constants not only tells the interpreter that your data won't change, it also tells other programmers that read your code. If you need somewhere to store data over time, use a ##class_variable, and #instance_variable or a $global instead.
This is not so much an OOP convention as a ruby convention.
class A
def a
puts 'in #a'
end
end
class B < A
def a
b()
end
def b
# here i want to call A#a.
end
end
class B < A
alias :super_a :a
def a
b()
end
def b
super_a()
end
end
There's no nice way to do it, but you can do A.instance_method(:a).bind(self).call, which will work, but is ugly.
You could even define your own method in Object to act like super in java:
class SuperProxy
def initialize(obj)
#obj = obj
end
def method_missing(meth, *args, &blk)
#obj.class.superclass.instance_method(meth).bind(#obj).call(*args, &blk)
end
end
class Object
private
def sup
SuperProxy.new(self)
end
end
class A
def a
puts "In A#a"
end
end
class B<A
def a
end
def b
sup.a
end
end
B.new.b # Prints in A#a
If you don't explicitly need to call A#a from B#b, but rather need to call A#a from B#a, which is effectively what you're doing by way of B#b (unless you're example isn't complete enough to demonstrate why you're calling from B#b, you can just call super from within B#a, just like is sometimes done in initialize methods. I know this is kind of obvious, I just wanted to clarify for any Ruby new-comers that you don't have to alias (specifically this is sometimes called an "around alias") in every case.
class A
def a
# do stuff for A
end
end
class B < A
def a
# do some stuff specific to B
super
# or use super() if you don't want super to pass on any args that method a might have had
# super/super() can also be called first
# it should be noted that some design patterns call for avoiding this construct
# as it creates a tight coupling between the classes. If you control both
# classes, it's not as big a deal, but if the superclass is outside your control
# it could change, w/o you knowing. This is pretty much composition vs inheritance
end
end