111 reputation
2
bio website
location Austria
age 26
visits member for 2 years, 10 months
seen Nov 4 at 15:07

Aug
30
comment Are too many if-else statements for validation bad?
Wow, if they go through the trouble to make a BrokenBusinessRule, why didnt they create a BusinessRule that encapsulates 1 if statement and adds a broken rule to a collection if that if applies. Just throw them in a list, iterate over it and execute the rule. You can then re-use the rules and create multiple different validation even for a user (general validity, should-get-a-credit, etc.). If the rest of the book is like that snippet, then you're probably be better off without it.
Aug
30
comment Are too many if-else statements for validation bad?
@kahoon that's where Domain Specific Languages come in ;) The term database here means "not hard-coded, can change at runtime without re-compiling the whole thing". I think most business rules can be implemented as if-else statements (however complex and nested). Creating a DSL for that isn't too hard, though the evaluation part might be.
Aug
30
answered How would I design an interface such that it's clear which properties may change their value, and which will remain constant?
Aug
30
comment How would I design an interface such that it's clear which properties may change their value, and which will remain constant?
In my opinion, it doesn't matter if the .NET framework follows the convention of solution 3. I expect developers to be smart enough to know if they're working with in-house types or framework types. Devs that don't know that don't read docs and thus solution 4 wouldn't help either. If solution 3 is implemented as a company / team convention, then I believe it doesn't matter whether or not other APIs follow it too (although it would be very much appreciated, of course).
Aug
30
comment Documentation in OOP should avoid specifying whether or not a “getter” performs any computation?
+1 for using Get methods over attributes to indicate a more heavy-weight operation. I've seen enough code where developers assume a property is just an accessor and use it multiple times instead of saving the value to a local variable, and thus execute a very complex algorithm more than once. If there is no convention to not implement such properties and the documentation doesn't hint at the complexity, then I wish whoever has to maintain such an application good luck.
Aug
30
awarded  Supporter
May
2
awarded  Teacher