Should a class validate itself or create another class to validate it?

Question

Let's say I have a class like:

class NavigationData
{
  float roll;
  float pitch;
  double latitude;
  double longitude;
}

and if I want to create a method:

const bool validate() const;

which basically validates whether the 4 fields contain valid values.

Should validate() be part of NavigationData class, or should I create something like a NavigationDataValidator, that contains a validate(const NavigationData&) method.

I'm just giving a simple example, obviously my real class is a lot more complicated than this. I'm looking for good OO principles.

Put it another way: given a method, how do we know if it should belong to the class, or should belong to a separate class?

Answer 1

I would say it depends. If the class's data is validatable in isolation I would put the method in the class, but if the validation requires a context then I would create a validator class based on some interface.

Answer 2

Depends...

Sometimes the validations are not part of the class itself, but business logic, and adding it to the class would prevent reutilization, and therefore, the usage of a validating class is good. Otherwise, the class should be able to validate itself.

Answer 3

I'd say have it validate itself as long as the valid values don't depend on what other classes use NavigationData.

Basically, as long as latitude and pitch has to always be between +/- 90 degrees, and longitude and roll always be between +/- 180 degrees, keep the validator in the class.

(By the way, what about heading?)

Answer 4

Your class should be designed such a way and provide such methods that validate() is always true:

• after any public constructor invoked
• before and after any public method is invoked
• (in C++-land) before destructor is invoked

Such validate() methods are called class invariants and are important part of Design by Contract.

Answer 5

The right answer is: it depends.

The natural place to put such object logic is in the object itself. Sometimes though the validation rules could be dependent on a rules engine or some kind of larger "framework" which validates stuff. Another situation where you wouldn't want to do validation inside the object is when validation belongs in another tier, or layer or the application, such as the view layer.

Answer 6

Typically it is a class's own responsibility to ensure that it maintains a logically consistent and valid internal state. For instance, Person may have a constructor that requires both a first and last name if operations on Person are meaningless without this data.

However, "logically consistent and valid" is different from "makes sense in the domain", so it is sometimes the responsibility of an external class to ensure that domain rules are obeyed. For example, PersonValidator may require that Person has a phone number which is in the US. But Person shouldn't necessarily need to know anything about whether or not a PhoneNumber is in the US.

A good rule of thumb is that if state or domain rules external to the class are required in addition to the data that already belongs to the class, you will want to consider having external validation. You may also want to centralize validation in an external class if the state of the class's instances can come from multiple sources (e.g., database, web form, file, etc.).

Answer 7

It depends on the context. Sometimes, your object is absolutely valid internally, but in the context its values aren't acceptable.

If you have simple Data Transfer Object then it probably shouldn't validate itself.

If you have a class of Domain Model then it should do some validation.

P.S. just my personal preference: isValid () instead of validate () when method returns boolean value.

Answer 8

As it has already been said, it depends.

But in your case, I would go for a different solution, create new immutable class for geo coordinates

class GeoCoordinates
{
    double Latitude;
    double Longitude;
}

And let this class validate that latitude and longitude are within valid limits. You will probably need this other places as well, for example.

class Airport
{
    GeoCoordinates Location;
    ...
}