On Jul 15, 2008, at 3:24 pm, Pat Maddox wrote:
This defines the contract of an Account abstraction... you can imagine
different account types that might implement it in a way that the
actual dollar values differ. For example, fees may be applied to one
kind of account but not another.
Anyone who implements your API can include that shared example group
and verify their code against the contract you've defined.
Hi Pat
This sounds like a brilliant idea - I've wanted so often to be able to
mix in specs for AR::Base for example. BUT - would it encourage
programming by inheritance, rather than message passing? Often it
feels unnatural to subclass *someone else's* library class and use it
in *my* application. Subclassing a library class to pass back into
the library doesn't bother me. For some reason it feels normal to
subclass a controller class but not an ORM class. Perhaps because a
controller is just a strategy for handling requests, and not something
you instantiate and manipulate yourself, whereas an AR model class has
business logic (handled by the app) and persistence (handled by the
framework) rolled into one?
WDYT?
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
