Suggestions for my ruby snippet so will not look like C anymore: method(method(param))

Ruby
1

I have a class which uses a connection object to send the request data
created by a request_builder object.

The code looks like this:
connection.send_request(request_builder.build_request(customer))

This in turn is called by:
build_report(customer,
connection.send_request(request_builder.build_request(customer)))

Ugly! Any ideas on how to make it more expressive? Usually in ruby and
OOP we chain objects like this: “string”.make_it_bigger.flash_it.send

2

On Feb 24, 2011, at 1:27 PM, Costi G. wrote:

This in turn is called by:
build_report(customer,
connection.send_request(request_builder.build_request(customer)))

Ugly! Any ideas on how to make it more expressive? Usually in ruby and
OOP we chain objects like this: “string”.make_it_bigger.flash_it.send

One approach might be to encapsulate the connection within the customer.

customer = Customer.new(connection, other, args)

or even

customer = connection.create_customer(other, args)

In either case, the customer is internally bound to the connection so
that
you can handle the queries internal to the customer object and just ask
the customer object for the complete report:

customer.report

Gary W.

3

Constantin G. wrote in post #983681:

I have a class which uses a connection object to send the request data
created by a request_builder object.

The code looks like this:
connection.send_request(request_builder.build_request(customer))

This in turn is called by:
build_report(customer,
connection.send_request(request_builder.build_request(customer)))

Ugly! Any ideas on how to make it more expressive?

I would write it like this:

request = request_builder.build_request(customer)
response = connection.send_request(request)
report = build_report(customer, response)

Otherwise, you could consider moving your logic around:

report = customer.build_request(request_builder).
send_on(connection).
report_for(customer)

But I think that’s a bad idea. You could maybe argue that a request
object should know how to send itself down a connection and decode the
response, but it’s much harder to argue that a customer object should
know how to build an RPC request for a particular application, or that
an RPC response should know how to turn itself into a report.

IMO this is one of the biggest downsides of “OOP”: when you have an
operation involving A and B, you have to decide whether the logic
‘belongs’ in A or B (or in a separate function). I think you’ve done it
right.

The problem goes away with functional programming, where you just have
data and methods. Your existing code is quite close to being functional,
except that I imagine your request_builder and connection objects hold
some state of their own.