My 2011 GoRuCo talk, Less - The Path to Better Design, is at Vimeo.
It's mostly about reducing object coupling and is full of example code. If you occasionally find yourself forced into a corner where you have to write case statements that switch on class, have a look, this will help.
Plus, the last two and a half minutes are full of bicycles; what's not to like?
The slides are on Heroku.
Thanks again to all the GoRuCo organizers. The conference is great and is an accurate reflection of their commitment to the community.
I am enjoying the great book: Practical Object Oriented Design in Ruby. In the testing chapter you have the Interface tests but you have not discussed about testing the semantics of the public interface. How do we go about the output and the arguments that must be provided to the public interface? Will you be discussing this in the book?
ReplyDeleteI'm certainly no testing expert, so the only advice I can tender is what I do myself. During tests I try to tell a story about how the interface works, which means illustrating normal behavior, edge behavior and error behavior.
ReplyDeleteAs a simple example, I would test a method that accepts a number between 2 and 999 by creating a test for inputs 1, 2, 999, 1000 and something random in between. Since the output is determined by the input, as long as I test the normal, edge and error cases, I have everything covered.
I'd be interested in other opinions.
And no, thanks for asking, but I hadn't planned on discussing this topic in the book. I was uncertain about covering testing at all, even though (as is probably obvious) it turned out I had more to say about designing tests than I initially imagined. There's a fuzzy line between giving advice about design and giving advice about how to test and while I may have unintentionally ventured across it, I really do mean to leave testing to the experts.
Depending what language you're working in, it might also be possible, and maybe once in a while even useful, to test your method by passing it a floating point number (with non-zero fractional part), no input, nil (or the language's equivalent), empty and non-empty arrays and hashes, objects, etc.
ReplyDeleteDuring Part I of the talk I had a strong sense of deja vu. Later on I realized you were talking about Parnas' criterion for decomposing modules: http://en.wikipedia.org/wiki/David_Parnas
ReplyDeleteAre you familiar with the Parnas paper or was this an independent rediscovery?
I have looked at the Parnas paper and my intentions are noble, but being a non-academic my eyes always glaze over before I get too far. The idea of this talk definitely felt like an 'independent rediscovery' but my guess is that the Parnas ideas have won so thoroughly that they're in the air that OO programmers breathe and that we're all more or less infected. Loosing coupling in this way just feels _right_, and all credit to Parnas, and all the other early OO folks, for making this so.
ReplyDeleteGrowing new things is constantly a test for buy a college essay online others people are taking a shot at gigantic scale and keeping up their work.
ReplyDeleteThis talks flooring away the renowned design principles and someone write my college essay representation the secreted, fundamental goals of design. It reveals indoctrination techniques that permit you to inscribe fewer regulations while creating gorgeous, flexible applications.
ReplyDelete