A report is a compilation of data, almost by definition. It seems like it is more of a produced artifact than something with behavior. Sometimes things are just data. And sometimes functions from one type of data (the report) to another (the view) is sufficient.
For me the solution would be to make the report "just data" (probably immutable) -- a DTO. If you provide it as data, it can be readily adapted to a specific view technology at render time. Having a "view" behavior could probably never work if it is used in more than one UI technology anyway.
I probably would choose to go WET with this report... no composition or inheritance. Once you need the same set of report fields again for the same reason, then you could worry about refactoring them into their own data class and use composition.
Remember the practices (like SOLID) and paradigms (like OO) should serve the purpose of the code, not the other way around.
A report is a compilation of data, almost by definition. It seems like it is more of a produced artifact than something with behavior. Sometimes things are just data. And sometimes functions from one type of data (the report) to another (the view) is sufficient.
I recently made a post that touched on that here.
Which solution would you prefer in this example and why? Or would you have some other solution? Thanks!
For me the solution would be to make the report "just data" (probably immutable) -- a DTO. If you provide it as data, it can be readily adapted to a specific view technology at render time. Having a "view" behavior could probably never work if it is used in more than one UI technology anyway.
I probably would choose to go WET with this report... no composition or inheritance. Once you need the same set of report fields again for the same reason, then you could worry about refactoring them into their own data class and use composition.
Remember the practices (like SOLID) and paradigms (like OO) should serve the purpose of the code, not the other way around.
Very nice, thanks for your input 👍