OO Coding - to use Object Managers or not?

Question

a point of architectural style that I'd like your opinion on please:

My ORM has given me a User object which corresponds to a user of my system. I wanted to develop a bunch of methods for handling Users - GetByUsername(), Authenticate(), VerifyLoginPassword() etc. However it feels to me that some of these methods don't really belong to the User class - e.g. GetByUsername() feels like a static method of User at least, but wouldn't it be more "clean" to have another class, say "UserManager" which provides us with these User-management type of tasks? It seems a little strange for a User instance to contain the Authenticate() method, for example, if it's the security system that does the authenticating?

The thing I worry about is that I end up following this model to the point where the User class is no more than a struct, and my User Manager and Security Manager classes actually do all the method work. It doesn't feel very "OO" to have all these manager classes manipulating lightweight objects.

Any thoughts or links to prior art on this philosophical matter would be appreciated!

Answer 1

It sounds like you at that point where you are moving beyond defining objects as "a dog is-a animal" and moving into object definitions in terms of roles, responsibilities, and behaviors.

I would recommend this book to help you make that transition and really "get it":

Object Design: Roles, Responsibilities, and Collaboration

I don't have an answer to your specific question because it is such a fundamental design decision that you really should learn about the "bigger picture." This book will give you a good foundation in the principles and techniques of Responsibility-Driven Design.

Answer 2

Martin Fowler has some useful views on this.

The fundamental choice is between Service Locator and Dependency Injection. The first point is that both implementations provide the fundamental decoupling that's missing in the naive example - in both cases application code is independent of the concrete implementation of the service interface. The important difference between the two patterns is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.