in reply to The division of (class) labor in OOP

Let's see. You have a User. And you have some object that Authenticates said user (is the user who they say they are?) - this could be via /etc/passwd, LDAP, DB, or whatever (and by having a separate object, you can swap in and out different objects to do different types of authentication). In fact, to create a User object, the Authenticate object would be called, and it would create the User object (with a read-only flag that said it was authenticated). And then you have Authorisation (can this user do what they're asking to do?) - and different ways to store that authorisation This object would check the user's authentication flag to see if it is actually authenticated to be authorised.

On the other hand, that's way too complex for the large majority of applications out there. So you probably would have no issues with putting it all together in a single location. Split out objects that make sense when you will either need to do the action on multiple things (User and something else), or you need the ability to swap out objects for differing functionalities (Authenticate::passwd -> Authenticate::DBI). But that's actually not a bunch different from procedural programming, I think.

  • Comment on Re: The division of (class) labor in OOP