OOP: how much program logic should be encapsulated within related objects/classes as methods?

Posted by Andrew on Stack Overflow See other posts from Stack Overflow or by Andrew
Published on 2010-03-31T01:58:42Z Indexed on 2010/03/31 2:03 UTC
Read the original article Hit count: 347

Filed under:
|
|
|
|

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.

© Stack Overflow or respective owner

Related posts about oop

Related posts about overkill