OOP: how much program logic should be encapsulated within related objects/classes as methods?
- by Andrew
I have a simple program which can have an admin user or just a normal user.
The program also has two classes: for UserAccount and AdminAccount.
The things an admin will need to do (use cases) include Add_Account, Remove_Account, and so on.
My question is, should I try to encapsulate these use-cases into the objects?
Only someone who is an Admin, logged in with an AdminAccount, should be able to add and remove other accounts. I could have a class-less Sub-procedure that adds new UserAccount objects to the system and is called when an admin presses the 'Add Account' button. Alternatively, I could place that procedure as a method inside the AdminAccount object, and have the button event execute some code like 'Admin.AddUser(name, password).'
I'm more inclined to go with the first option, but I'm not sure how far this OO business is supposed to go.