tag:blogger.com,1999:blog-36201586.post9141065463149015567..comments2023-01-05T21:58:34.019+00:00Comments on Derek says:: The always-valid entity anti-patternDerek Fowlerhttp://www.blogger.com/profile/09963865123124577525noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-36201586.post-7632291013505738032009-05-18T21:25:00.000+01:002009-05-18T21:25:00.000+01:00@andy
I'd argue that this is incorrect because a. ...@andy<br />I'd argue that this is incorrect because a. modifying a constructor goes against the OO principal of extend rather than modify and b. you may not own the instantiation code to be able to take advantage of the compiler or Resharper catching the change.<br /><br />I'm not saying that parameterised constructors are bad, they are essential, especially for behavioural classes that just wont work without some outside object being passed in. Here I'm looking at the case where you're forced to set values for *every* property of the entity. Where the business rules surrounding what makes the entity valid are hardcoded into the structure of the class.<br /><br />Exception handling should not need to be used to implement normal business logic at all, it should cater for exceptional cases only i.e. the unforseen, not the expected "user typing in the wrong thing" case. Also by implementing validation using exceptions in properties you're only going to be able to identify one invalid value at a time, no collation can occur unless you use multiple try/catches. I'd also argue that allowing an exception to bubble all the way out of your app tier to the UI as a "feature" of your program is bad practice.<br /><br />I think your presentation tier code should prepare itself an entity with the values from the user input. It should then apply validation to the entity to check it's all good, notifying the user of any problems if they arise. Only once this has passed should it attempt to save the entity and at this point if the entity is still invalid we have an exception case.Derek Fowlerhttps://www.blogger.com/profile/09963865123124577525noreply@blogger.comtag:blogger.com,1999:blog-36201586.post-55694580766101771092009-05-18T21:18:00.000+01:002009-05-18T21:18:00.000+01:00@Andrew
I did read them, and still am.@Andrew<br />I did read them, and still am.Derek Fowlerhttps://www.blogger.com/profile/09963865123124577525noreply@blogger.comtag:blogger.com,1999:blog-36201586.post-45528478293754049522009-05-18T10:46:00.000+01:002009-05-18T10:46:00.000+01:00It's better to have to refactor the parameters for...It's better to have to refactor the parameters for a constructor at instance creation than to allow a developer not to set a property that is required for an entity to be valid, or to fail to alter each place where it should be set. The compiler is on your side and tools like Resharper make this painless.<br /><br />Constructor parameters usually reflect the minimum set of properties that are required for the initial state of the entity instance. Your car is perhaps burdened with mandatory information that should be optional?<br /><br />Exception handling should be sparse. Try/catch around every call to an entity would indeed be an anti-pattern, however a better approach is to catch the exception once at an appropriate level (in this case the UI). Your validation framework is going to collate all of the violated rules and throw one exception.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-36201586.post-53229860016751822252009-05-18T09:57:00.000+01:002009-05-18T09:57:00.000+01:00Did you read the comments at the end of Jeffery's ...Did you read the comments at the end of Jeffery's post? There are some compelling arguments in favour of "always-valid".Anonymousnoreply@blogger.com