When designing a system that displays information about an entity (but where modification of the data is rare or restricted to few users - such as a user profile), would it make sense to have two separate classes to do this? One for management of a user profile (logging in, changing password, modifying profile content) and another purely for the consumption of this data (a UserProfile/UserView) which can only retrieve the displayed data for the user.

1. Is this a sensible choice to make?
2. Would there be any security reasons in this style of architecture?
3. Would this violate the concept of modelling an entity as a single class? (and are there instances where this is acceptable/expected?)
4. Are there any common patterns or best practices for modelling an entity in this way?

I'm asking purely out of interest, but lets work on the assumption that this is a social media profile.

When designing a system that displays information about an entity (but where modification of the data is rare or restricted to few users - such as a user profile), would it make sense to have two separate classes to do this? 

One for management of a user profile (logging in, changing password, modifying profile content) and another purely for the consumption of this data (a UserProfile/UserView) which can only retrieve the displayed data for the user.

1. Is this a sensible choice to make?
2. Would there be any security reasons in this style of architecture?
3. Would this violate the concept of modelling an entity as a single class? (and are there instances where this is acceptable/expected?)
4. Are there any common patterns or best practices for modelling an entity in this way?

Let's work on the assumption that this is a social media profile.