This is part 3 of the series, you can find the other parts here:
part 1 part 2 Introduction In the first two parts we defined a basic OOP structure to validate data objects, and in this part we’re going to digress slightly into a plugin, service based validation infrastructure.
As mentioned in the first part, a static class doing validations is not very modular, and I would definitely advise against it.
This is part 2 of the series, you can find the other parts here:
part 1 part 3 Validation The second idea to validation is to design an interface that specifies validation:
public interface IValidatable<T>{ ?? Validate(); } What return type should the validate method have? The first thing that comes to mind is a boolean indicating whether the validation was successful or not. In something I like to call happy-case-thinking that would definitely suffice, but when the validation wasn’t successful, what kind of information would I need?
Introduction In this blog series I’ll take you, the reader, on a journey through the world of validation. Validation is something that is present in all software, but especially so in business software. Business software always has external dependencies, which cannot be trusted to deliver proper data.
I’ll investigate systems to check for the validness of data of differing degrees of sophistication and effectiveness and how we can use them.