I am seeking confirmation of what seems to be a fairly straight-forward OOP practice (for others anyway).
Let's use a common example:
A certain application deals with a central "user" ... (this "user" is the subject of its own class). This user can register itself with the system, authenticate itself (create a session), logout (destroy its session), alter its profile information, conduct searches on other "users", etc.
Is it cleaner in practice to create a "User" class that has all of the abilities above OR a "User" and an "Authentication" class that divides the abilities above accordingly? The "Authentication" class would, of course, handle authentication of the user, session management, registration, etc. The "User" class would handle the altering of profile information, searches, etc. I am consistantly hung up on the division of labor (so to speak) between classes. I run into the same question when dealing with a "Display" class ... should the "Display" class display the forms needed to authenticate or leave that to the class that handles the processing logic? (My guess is the former rather than later).
There is a distinct possibility that I am not envisioning the structure and responsibilities correctly when it comes to OOP. I have been a procedural programer for a little too long.
As always, thank you all ahead of time for your advice and guidance.
author => jeyroz
In reply to The division of (class) labor in OOP by jeyroz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |