<p>I'm wondering if it's a good idea to make <strong>verifications</strong> in <strong>getters</strong> and <strong>setters</strong>, or elsewhere in the code.</p>

<p>This might surprise you be when it comes to <strong>optimizations</strong> and <strong>speeding</strong> up the code, I think you should not make verifications in getters and setters, but in the code where you're <strong>updating</strong> your files or database. Am I wrong?</p>

[{'answer_id': 2754, 'author': 'Justin Standard', 'author_id': 92, 'author_profile': 'https://Stackoverflow.com/users/92', 'pm_score': 1, 'selected': False, 'text': "<p>Validation should be captured separately from getters or setters in a validation method.  That way if the validation needs to be reused across multiple components, it is available.</p>\n\n<p>When the setter is called, such a validation service should be utilized to sanitize input into the object.  That way you know all information stored in an object is valid at all times.</p>\n\n<p>You don't need any kind of validation for the getter, because information on the object is already trusted to be valid.</p>\n\n<p>Don't save your validation until a database update!! It is better to <strong>fail fast</strong>.</p>\n"}, {'answer_id': 2757, 'author': 'Seibar', 'author_id': 357, 'author_profile': 'https://Stackoverflow.com/users/357', 'pm_score': 2, 'selected': False, 'text': "<p>From the perspective of having the most maintainable code, I think you should do as much validation as you can in the setter of a property. This way you won't be caching or otherwise dealing with invalid data.</p>\n\n<p>After all, this is what properties are meant for. If all you have is a bunch of properties like...</p>\n\n<pre><code>public string Name\n{\n    get\n    {\n        return _name;\n    }\n    set\n    {\n        _name = value;\n    }\n}\n</code></pre>\n\n<p>... they might as well be fields</p>\n"}, {'answer_id': 2760, 'author': 'McDowell', 'author_id': 304, 'author_profile': 'https://Stackoverflow.com/users/304', 'pm_score': 2, 'selected': False, 'text': '<p>It depends.</p>\n\n<p>Generally, code should fail fast. If the value can be set by multiple points in the code and you validate only on after retrieving the value, the bug appears to be in the code that does the update. If the setters validate the input, you know what code is trying to set invalid values.</p>\n'}, {'answer_id': 2761, 'author': 'Michael Stum', 'author_id': 91, 'author_profile': 'https://Stackoverflow.com/users/91', 'pm_score': 5, 'selected': True, 'text': "<p>Well, one of the reasons why classes usually contain private members with public getters/setters is exactly because they can verify data.</p>\n<p>If you have a Number than can be between 1 and 100, i would definitely put something in the setter that validates that and then maybe throw an exception that is being caught by the code. The reason is simple: If you don't do it in the setter, you have to remember that 1 to 100 limitation every time you set it, which leads to duplicated code or when you forget it, it leads to an invalid state.</p>\n<p>As for performance, i'm with Knuth here:</p>\n<blockquote>\n<p>&quot;We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.&quot;</p>\n</blockquote>\n"}, {'answer_id': 2768, 'author': 'dlinsin', 'author_id': 198, 'author_profile': 'https://Stackoverflow.com/users/198', 'pm_score': 1, 'selected': False, 'text': '<p>You might wanna check out <a href="http://books.google.com/books?id=7dlaMs0SECsC" rel="nofollow noreferrer">Domain Driven Design</a>, by Eric Evans. DDD has this notion of  a Specification:</p>\n<blockquote>\n<p>... explicit predicate-like VALUE\nOBJECTS for specialized purposes. A\nSPECIFICATION is a predicate that\ndetermines if an object does or does\nnot satisfy some criteria.</p>\n</blockquote>\n<p>I think failing fast is one thing, the other is where to keep the logic for validation. The domain is the right place to keep the logic and I think a Specification Object or a validate method on your Domain objects would be a good place.</p>\n'}, {'answer_id': 5413, 'author': 'Matt Hamilton', 'author_id': 615, 'author_profile': 'https://Stackoverflow.com/users/615', 'pm_score': 1, 'selected': False, 'text': '<p>I like to implement <a href="http://msdn.microsoft.com/en-us/library/system.componentmodel.idataerrorinfo.aspx" rel="nofollow noreferrer">IDataErrorInfo</a> and put my validation logic in its Error and this[columnName] properties. That way if you want to check programmatically whether there\'s an error you can simply test either of those properties in code, or you can hand the validation off to the data binding in Web Forms, Windows Forms or WPF. </p>\n\n<p>WPF\'s "ValidatesOnDataError" Binding property makes this particularly easy.</p>\n'}, {'answer_id': 5501, 'author': 'Leon Bambrick', 'author_id': 49, 'author_profile': 'https://Stackoverflow.com/users/49', 'pm_score': 2, 'selected': False, 'text': "<p>@Terrapin, re:</p>\n\n<blockquote>\n  <p>If all you have is a bunch of [simple\n  public set/get] properties ... they\n  might as well be fields</p>\n</blockquote>\n\n<p>Properties have other advantages over fields. They're a more explicit contract, they're  serialized, they can be debugged later, they're a nice place for extension through inheritance. The clunkier syntax is an accidental complexity -- .net 3.5 for example overcomes this.</p>\n\n<p>A common (and flawed) practice is to start with public fields, and turn them into properties later, on an 'as needed' basis. This breaks your contract with anyone who consumes your class, so it's best to start with properties.</p>\n"}, {'answer_id': 123325, 'author': 'Stefan Moser', 'author_id': 8739, 'author_profile': 'https://Stackoverflow.com/users/8739', 'pm_score': 1, 'selected': False, 'text': "<p>I try to never let my objects enter an invalid state, so setters definitely would have validation as well as any methods that change state.  This way, I never have to worry that the object I'm dealing with is invalid.  If you keep your methods as validation boundaries, then you never have to worry about validation frameworks and IsValid() method calls sprinkled all over the place.</p>\n"}]
['https://Stackoverflow.com/questions/2750', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/435/']