@davetron5000 I am also fond of class level methods on collaborators so the client class does *not* need to now if the collaborator object is a class and how to initialize it.
The less they know about each other the easier it gets to change _just_ one of them
@davetron5000 here the injected dependencies may be classes or modules, this orchestator class does not now (or need to).
And I can use a placeholder for reporter until it is implemented.
![require "setup"
require "debug"
class Disburser
include Loggable # provides pseudo-global `logger(msg)`
include Measurable # provides `measure(&blk)`
include Configurable # provides `config(key)`
include Runnable # provides class level `run`
class Error < StandardError; end
def initialize(
loader: ::Disburser::Loader,
backfiller: ::Disburser::Backfill,
reporter: Object.new.tap { def it.run = puts("Reporter.run") }
)
@loader = loader
@backfiller = backfiller
@reporter = reporter
end
def run
logger.info "Disburser.run with options: #{::Setup::Config.instance.config}"
load_csv_files if config(:load_files)
backfill_disbursements if config(:backfill)
run_report
rescue Error => e
abort("Unable to complete: #{e.message}")
end
private
attr_reader :loader, :backfiller, :reporter
def load_csv_files
logger.info "Loading CSV files into DB..."
measure("Load CSV files") { loader.run }
rescue Loader::Error => e
handle_error e
end
def backfill_disbursements
# edited for brevity
end
def run_report
logger.info "Generating disbursement report..."
measure("Report generation") { @report = reporter.run }
rescue Report::Error => e
handle_error e
end
def handle_error(exception)
msg = "[#{exception.class}]: #{exception.message}"
logger.error msg
raise Error, msg
end
end](/proxy/post_attachment/447319/c4bce46bf8.png "require \"setup\"
require \"debug\"
class Disburser
include Loggable # provides pseudo-global `logger(msg)`
include Measurable # provides `measure(&blk)`
include Configurable # provides `config(key)`
include Runnable # provides class level `run`
class Error < StandardError; end
def initialize(
loader: ::Disburser::Loader,
backfiller: ::Disburser::Backfill,
reporter: Object.new.tap { def it.run = puts(\"Reporter.run\") }
)
@loader = loader
@backfiller = backfiller
@reporter = reporter
end
def run
logger.info \"Disburser.run with options: #{::Setup::Config.instance.config}\"
load_csv_files if config(:load_files)
backfill_disbursements if config(:backfill)
run_report
rescue Error => e
abort(\"Unable to complete: #{e.message}\")
end
private
attr_reader :loader, :backfiller, :reporter
def load_csv_files
logger.info \"Loading CSV files into DB...\"
measure(\"Load CSV files\") { loader.run }
rescue Loader::Error => e
handle_error e
end
def backfill_disbursements
# edited for brevity
end
def run_report
logger.info \"Generating disbursement report...\"
measure(\"Report generation\") { @report = reporter.run }
rescue Report::Error => e
handle_error e
end
def handle_error(exception)
msg = \"[#{exception.class}]: #{exception.message}\"
logger.error msg
raise Error, msg
end
end")
@oinak I worked in a large Java Spring app for several years. I liked a lot about this style, but I definitely did not like the flexibility it allowed and having to chase down across several files what code was actually running in production. It's a tradeoff and for me, flexibility is usually bad and not something to strive for. I think the “call .new, then call a named method" is a decent seam and I'm fine with classes being coupled in that way. It makes debugging a lot easier IME.
@davetron5000 a lot of our preferences are based on whatever did hurt to each one of us. I have found RSpec mocking abuse and high class coupling a lot in my job life, and used Minitest and enthusiastic DI in my free time and fun pet projects, and that most probably shaped my biases.
Thanks for sharing the context of your choices, I am sure I will grasp BrutRB better now. 🙇🏼
@oinak Yeah, you are probably right about that - glad to have a nice discussion about it tho!