Yup, I think ahundiak is on the right track. Traditionally in OO, a class is responsible for keeping its private data in a valid state. If it was possible for a Post object to have a published date but not be in a published state, then that would be invalid.
But there’s a trade-off. We would end up using exceptions for simple validation. For example:
class User
{
// ...
public function setEmail($email)
{
// Ensure this object is always valid
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
throw new Exception('Bad email.');
}
$this->email = $email;
}
Plus, there’s usually more validation to be done than checking individual fields, and that other validation would have to be managed in a different way, making the task of validation less simple and centralized.
I can’t say exactly when this happened, but we collectively seemed to decide to treat entity objects more like a bag of data, as though all the fields were public. We can plug in whatever data we want, then later validate the state of that data.
Sometimes being pragmatic means sacrificing OO purity.