On Wed, Jul 16, 2008 at 4:47 PM, Ashley Moran <[EMAIL PROTECTED]> wrote: > > 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
Well, I don't think people would fall into the trap of misusing inheritance if you don't give them classes to inherit from :) The original post was about writing specs for base classes that have empty methods. The reason that he wanted to write these empty methods was to provide documentation for later programmers. If, however, you provided a set of specs that defined the expected contract, people could write whatever code they want and know that it should work within the framework - no inheritance required. And if the framework developer did want to provide existing behavior, he can do so by writing modules that people can mix into their own stuff. Now, this is speculation on my part, as I've never actually done this. But I like the idea of taking DBC ideas and flipping them on their head, defining contracts from the client-side in the form of specs. Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
