The ServicePattern module is defined as a top-level module, rather than being namespaced within the DfE::Analytics module. It therefore pollutes the top-level namespace of any Ruby app which uses the dfe-analytics gem.
|
# a template for creating service objects |
|
module ServicePattern |
|
def self.included(base) |
|
base.extend(ClassMethods) |
|
base.class_eval do |
|
private_class_method(:new) |
|
end |
|
end |
For example, this caused some strange behaviour over in DFE-Digital/itt-mentor-services#521 (comment) where we had to manually require our own ServicePattern module directly in a spec file to override the one provided by dfe-analytics.
I think ideally this module should be namespaced inside DfE::Analytics to avoid this from happening – plus to be consistent with the other classes in this gem, which all seem to be namespaced according to their file path.
In other words, I think lib/dfe/analytics/shared/service_pattern.rb should be changed to:
# a template for creating service objects
module DfE
module Analytics
module Shared
module ServicePattern
# ...
end
end
end
end
The
ServicePatternmodule is defined as a top-level module, rather than being namespaced within theDfE::Analyticsmodule. It therefore pollutes the top-level namespace of any Ruby app which uses the dfe-analytics gem.dfe-analytics/lib/dfe/analytics/shared/service_pattern.rb
Lines 1 to 8 in 3e078f9
For example, this caused some strange behaviour over in DFE-Digital/itt-mentor-services#521 (comment) where we had to manually require our own
ServicePatternmodule directly in a spec file to override the one provided by dfe-analytics.I think ideally this module should be namespaced inside
DfE::Analyticsto avoid this from happening – plus to be consistent with the other classes in this gem, which all seem to be namespaced according to their file path.In other words, I think lib/dfe/analytics/shared/service_pattern.rb should be changed to: