4 ms·
ZipCode GetZipCode() { var result = _crm.GetZip(); return isValidZip(result) ? new ValidZip(result) : new InvalidZip(result); } class ValidZipC
by joshka 11y ago
ZipCode GetZipCode()
{
var result = _crm.GetZip();
return isValidZip(result) ? new ValidZip(result) : new InvalidZip(result);
}
class ValidZipCode : ZipCode { ... }
class InvalidZipCode : ZipCode { ... }
No edge cases, perfectly 'documented'.
- codingdave 11y agoHow do you consider that to be documented? Why do you return a different class for invalid zips? Is it OK to use invalid zips in all cases? If not, why not throw an error? If so, what benefit does the separate class give you? Because that code doesn't handle bad data - something in the objects or some other function must handle it, and this code doesn't really tell us what is going to happen with a bad zip. It just tells us that the code noticed it. This is exactly why comments can help.
- joshka 11y agoSee the null object pattern. Encapsulate all such behavior you've mentioned with appropriate OO patterns, and stop writing procedural code spread all over the place that has to rely on comments to inform you about the right way to handle the bad data. Handle the bad data cases simply and specifically. Feel free to add some code that explains your use case and where you think such comments are required...