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

views:

answers:

+3 Q:

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

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.

The creation of accounts is certainly a business activity, so it should be part of one of your business classes (e.g. Account) rather than having the logic in the button's method.

Giovanni Galbo 2010-03-31 02:04:08

What if I have a module that contains procedures for management of objects, which the buttons/UI can access, but is not a class in itself (or part of the classes it manages)? The procedure could sayDim X as New UserAccount (name, password)and thus call the constructor for the UserAccount objectOr the button-click event code could call a methodAdminAccount.AddUserAccount(name, password)in which case I'd be going through one object to create a new instance of another. Is this correct OOP practice?

Andrew 2010-03-31 02:15:55

I'm sure that if you ask a million people this question, that you'll get a million different answers. In my opinion, use the model that most closely resembles real life. If only admins can create accounts, then admin.CreateUser(userName, passWord) feels natural (at least to me). Another common approach that I've seen is a static method that takes in a user (e.g. admin), like so Account.CreateAccount(creatingUser,newUserName, newUserPassword). The CreateAccount method would validate that the creating user is an admin. This is less "OO" to me, but (...continued)

Giovanni Galbo 2010-03-31 05:48:46

is useful for apps that define a bunch of roles in the database, but do not have individual role classes defined for each role. I find this approach to be reasonable as well.

Giovanni Galbo 2010-03-31 05:50:55

Thanks. This was helpful. I went with your first suggestion.

Andrew 2010-03-31 16:39:45

No problem... good luck!

Giovanni Galbo 2010-03-31 17:33:50

+2 A:

How much logic should be in objects?

All of it.

Object-oriented 101 would say that you should have an Account class. User and Admin are roles that might bestow different powers on one over the other, but the behavior of adding and removing accounts from the system shouldn't change.

It should also be true that your objects express use that's over and above the interface a user gets to see. Your use cases should be executable for either text or graphical user interfaces. It's a good test to see how well you've separated the user interface from the logic to first see if you can drive the problem without a GUI.

If you're thinking GUI first you're doing it wrong.

duffymo 2010-03-31 02:04:23

Hmm... I'm not sure there is a problem with _thinking_ about GUI first...

2010-03-31 03:22:10

Objects first; UIs come and go.

duffymo 2010-03-31 09:32:25

Yes one of the things I wanted to avoid was putting any important code in the VB forms/events. However, there is a choice between encapsulating all the methods within objects, or gathering the important object-management/busines-logic procedures together in one place (eg. a module). The advice I've received so far seems to lean towards putting all logic within objects/classes, so the system is fully OO.

Andrew 2010-03-31 22:11:26

ansaurus

tags:

views:

answers:

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

related questions