Choosing among object/class/module/top-level methods

Ruby
1

Hi, Rubyists!

Whenever I try to make a quick solution program,
I stop for a moment to think which approach I should take.

Let’s say that you want to make a puzzle-solver (like Sudoku-solver)
and it’s made up of one ‘solve’ method and several helper methods.

Which is your preferred way among the following?
And why?

[1]

def solve_sudoku problem
…
end

def helper1 args
…
end

def helper2 args
…
end

puts solve_sudoku “15000…00358”

[2]

class Sudoku

def initialize problem
...
end

private

def helper1
...
end

def helper2
...
end

end

sudoku = Sudoku.new “15000…00358”
puts sudoku.solve

[3]

class Sudoku

class << self
	def solve problem
	...
	end

private
	def helper1
	...
	end

	def helper2
	...
	end
end

end

puts Sudoku.solve “15000…00358”

[4]

module Sudoku

class << self
	def solve problem
	...
	end

private

	def helper1
	...
	end

	def helper2
	...
	end
end

end

end

puts Sudoku.solve “15000…00358”

I’m a big fan of Object-orientation.
But if the object’s life-span is as short as Solver.new(problem).solve,
I’m really hesitant to create an object when a simple method call will
do.
Am I thinking of a worthless subjective thing?

Do you have any criteria about going for object/class/module/top-level
methods?

Thanks.

Sam

2

On Fri, 14 Jul 2006, Sam K. wrote:

<snip various methods i’ve used too>

I’m a big fan of Object-orientation. But if the object’s life-span is as
short as Solver.new(problem).solve, I’m really hesitant to create an object
when a simple method call will do. Am I thinking of a worthless subjective
thing?

Do you have any criteria about going for object/class/module/top-level
methods?

in all seriousness this is precisely why i just wrote the prototype
library - i was just facing this question (again) yesterday and couldn’t
stand
it anymore. now i can write

solver = prototype{
@some_instance_var

 def solve
   something @some_instance_var
 end

 def something arg
 end

}

eh voila!

check it out and let me know what you think - it really is designed for
exactly this purpose.

btw - i’ll be making a new release later today which is cleaned up a lot
but
only adds one small new feature so the current one, though messy, should
be
fine to play with regarding functionality.

cheers.

-a

3

unknown wrote:

solver = prototype{
@some_instance_var

 def solve
   something @some_instance_var
 end

 def something arg
 end

}

I haven’t checked out your library yet.
Can you set visibility on methods?
Helper methods don’t have to be public.

Probably I need to see your library first.

I’ll talk to you again.

Sam

4

On Fri, 14 Jul 2006, Sam K. wrote:

}

I haven’t checked out your library yet.
Can you set visibility on methods?

yes.

-a