Nested classes as data holders make sense to me. However, you need to consider several other factors.
- The example shows only scalar contents, in which case would it be better to use a struct to make it value-like?
- In these classes you have shown setters, but wouldn't it be better if they were immutable?
- If there were reference value fields and they are not immutable, wouldn't you need a copy constructor?
- If A calls B and B returns a value and A expects that value then there is a contract between them, but in a nested class the contract is rather one-sided.
- How would you reconcile this strategy with defining contracts in terms of interfaces rather than concrete classes?
I guess what I'm saying is that in the (relatively) narrow situation of scalar fields and/or immutable values with concrete implementations it looks OK. I suspect that as you break out of that niche they will cause more trouble than they are worth. YMMV.