Skip to content
This repository has been archived by the owner on Jun 9, 2019. It is now read-only.

Design Ideas

Matt Whipple edited this page Feb 15, 2016 · 1 revision

Checks vs. Navigation

Validation primarily consists of tests against values which in Valerie is represented by the concepts of Checks. These are the rules that define what constraints should be satisfied by input, and the definition and extension of these defines the problem that is being solved. This is provided by the underlying Check and supporting classes which provide the equivalent of Predicate or an implementation of the Specification pattern with additional composition behavior.

The checking of simple values is a simple problem, and therefore the design of Valerie is to keep that part of the solution simple by having the library provide the means of navigating your data. This will allow Checks to remain focused on the specific input they're evaluating and accordingly simple. The Idator provides input graph traversal and facilities to enable some of the more DSL style behavior on top of the Check layer.

The Check layer is expected to be extended regularly so that domain specific validation rules can be provided. The Idator layer is intended to provide enough general functionality that extension should not be necessary (ultimately). The Check layer is also designed to be effectively language agnostic while the Idator layer leverages some language specific features.

Functional Characteristics

Checks adhere to the charactersitics of functions as prescribed by functional languages (and mathematics). A Check c applied to input x should always yield the same y (c(x) = y), after which x will remain unchanged. Functions should be side-effect free and objects should be considered immutable.

Any custom Checks that are created should abide by these rules or they may break in future versions. Presently there is not consistent enforcement of these charactertistics or protection if they are violated.

Provide building blocks and means of combination

Everything is a Check

Avoid assumptions/opinions

As much as possible the framework will be written in a way that is indifferent to how it is being used.