4.1 KiB
Object validation
Validation of objects is essential for the quality of object-oriented programs.
This page provides a rough overview of different techniques and strategies around object validation.
Basics
Object types
The appropriate kind of validation may differ on the kind of object, whether it is
- mutable or
- immutable
Validation results
Validation results can be divided into:
- Detailed: containing a list of violations
- Simple: reporting just one violation (or even only success/failure), either with a simple or a generic message
Technical possibilities
Most languages are offering the following possibilities for failure handling:
- Return values
- Exceptions
Context
Validations can be
- context-dependent
- context-independent
Validation time
- Before object creation
- After creation (but before actual usage of the data)
Validation patterns
- Validation on existing objects/states during business operations (i.e. after object creation) (see https://enterprisecraftsmanship.com/posts/validation-and-ddd/) :
- validate / isValid methods (backdraw: race conditions can lead to invalid state)
- in application services (backdraw: potential business logic leakage)
- TryExecute (backdraw: no CQRS separation: potential state change AND returning data (i.e. error message))
- Execute / CanExecute => call separately „Can“- and „execute“-method, (partial) state is stored locally which means no race conditions can lead to an invalid state
- Validation during object creation (avoids invalid objects), without public validation method
- In constructor
- In factory method (e.g. create method)
- In Factory
- In Builder
- Validation before object creation with public validation method (avoids invalid objects, allows CQRS and detailed results):
- With (static/class level) validation AND factory method - (https://savoiragile.com/2012/06/28/english-object-validation-on-immutable-objects/ & https://reflectoring.io/java-immutables/ )
- Using Essence pattern (https://stackoverflow.com/questions/9776193/good-practice-to-validate-immutable-values-objects )
- Also Factory and Builder pattern could be added with a validate method (https://stackoverflow.com/questions/16221010/should-the-factory-pattern-contain-validation-logic ), but does not seem very common
Potential strategies
When putting the basics above together, you might consider the strategies below.
For mutable or context-dependent objects
Use strategies for validations after object creation (from https://enterprisecraftsmanship.com/posts/validation-and-ddd/):
- The Execute / TryExecute pattern works best for task-based scenarios.
- For CRUD scenarios, you need to choose between Execute / TryExecute and validation in application services. The choice comes down to purity versus ease of implementation.
Immutable and context-independent objects
Use validations before object creation (first, you may want to validate as early as possible, and secondly, it normally makes no sense to create object that never will be valid.)
- Factory method AND validation method (for less complex cases)
- Note: validation method must be static/at class level
- Essence pattern (for more complex cases)
Validation results
Consider
- Detailed results (containing a list of violations)
- for crud-y operations e.g. when using multi-field input
- Simple results
- if detailed results would add no benefits, e.g. for task-based operations (if user just wants to execute a task and/or just wants to know if the task was successful or not resp. why not)
Technical mechanisms
- Return values
- for “expected” failures
- Exceptions
- for “unexpected” failures
https://stackoverflow.com/questions/99683/which-and-why-do-you-prefer-exceptions-or-return-codes https://stackoverflow.com/questions/5460101/choosing-between-exception-and-return-value https://enterprisecraftsmanship.com/posts/error-handling-exception-or-result/
###Appendix
Object creation (patterns, etc):
- Constructor
- Factory method (e.g. create method)
- Factory
- Builder
- Essence
- Other creational patterns: Prototype, Object Pool, Abstract Factory, Singleton
