Explicit behavior with checks vs. implicit behavior

Posted by Silviu on Stack Overflow See other posts from Stack Overflow or by Silviu
Published on 2010-03-21T08:25:32Z Indexed on 2010/03/21 8:31 UTC
Read the original article Hit count: 569

Filed under:
|
|
|
|

I'm not sure how to construct the question but I'm interested to know what do you guys think of the following situations and which one would you prefer.

We're working at a client-server application with winforms. And we have a control that has some fields automatically calculated upon filling another field. So we're having a field currency which when filled by the user would determine an automatic filling of another field, maybe more fields.

When the user fills the currency field, a Currency object would be retrieved from a cache based on the string introduced by the user. If entered currency is not found in the cache a null reference is returned by the cache object. Further down when asking the application layer to compute the other fields based on the currency, given a null currency a null specific field would be returned. This way the default, implicit behavior is to clear all fields. Which is the expected behavior.

What i would call the explicit implementation would be to verify that the Currency object is null in which case the depending fields are cleared explicitly.

I think that the latter version is more clear, less error prone and more testable. But it implies a form of redundancy. The former version is not as clear and it implies a certain behavior from the application layer which is not expressed in the tests. Maybe in the lower layer tests but when the need arises to modify the lower layers, so that given a null currency something else should be returned, i don't think a test that says just that without a motivation is going to be an impediment for introducing a bug in upper layers.

What do you guys think?

© Stack Overflow or respective owner

Related posts about .NET

Related posts about TDD