When it comes to class design I’ve tended to shy away from using what database types would call “de-normalized” objects.
In the world of Object Oriented Design the analogue of de-normalized tables are objects that have lots of fields most of which are null or unset.
These kinds of objects should be avoided because they depend on hidden knowledge. They increase the amount of hidden knowledge necessary to work with a given system.
In a perfect world the purpose of an object would be obvious based on its name. The same goes for its properties. But when most of an objects properties are not used at any given moment you usually have an object that can take on radically different roles based on which set of its properties are set (or not null).
How is someone new to the code going to know which role the object is in at the time they’re looking at it? <== There’s that hidden knowledge!
Although it’s tempting in a pinch to pile on the properties/fields of an object, especially when it’s sitting right there and you really need a piece of data, I urge you to resist the temptation. The befuddlement you’re hoisting into the future my just land in the lap of your future self.
As always this rule of thumb should be taken with a healthy dose of skepticism. Sometimes it’s necessary to de-normalize; either for performance reasons or because the design genuinely calls for it.