From: hipster <hipster@...4all.nl>
Date: 2001-04-24T16:23:36+09:00
Subject: [ruby-talk:14143] Re: OO

On Tue, 24 Apr 2001  08:16:33 +0900, chad fowler wrote:
[snip]
> Again, this is all dependent on what the "Options"
> are, but with your example, you've provided a little
> window into what you're trying to do.  My answer for
> the "debug=1" example would be that each class
> shouldn't inherently know what debugging behaviour is.
>  I would centralize the debugging in a class that can
> decide independently how to deal with things that ask
> to be debugged.  I'm guessing that "debug=1" will
> cause level 1 verbosity (however you have that
> defined) logging in your application to happen.  In
> that case, I would probably define a logger object
> that could handle both the implementation of what it
> means to actually log something and the decision of
> *when* to log something (i.e. "if(debug=1)
> logDebugMessage(myMessage)").

I'd suggest Aspect Oriented Programming for this. Check out aspectr in
the RAA; it makes things like logging, debugging, timing, pre- &
postconditions, synchronisation etc. a breeze, while leaving the
target class you add a certain aspect to completely untouched.

Simple logging example:

###
require "aspectr"
include AspectR

class Logger < Aspect
	def wrap(target, *methods)
		super(target, :enter, :exit, *methods)
	end

	def enter(method, object, *args)
		puts "enter #{object.class}::#{method}"
	end

	def exit(method, object, *args)
		puts "exit #{object.class}::#{method}"
	end
end

class Foobar
	def method
		puts "aap noot"
	end
end

logger = Logger.new
logger.wrap(Foobar, :method)	# wrap one or more methods

Foobar.new.method		#=> enter Foobar::method
				#=> aap noot
				#=> exit Foobar::method
###

Nifty!

	Michel