Continued…
The problem here is that most business applications don’t actually have a lot of “business logic” in them. Other than basic validation of user input, mainly what we do with objects is Create, Read, Update, and Delete them. There simply isn’t always a need to have a lot of fancy domain logic associated with your domain objects. You can put your object-oriented skills to use however, in dealing with the structural complexity of the domain objects, rather than their behavior complexity.
Lots of people seem to try to make up for the lack of “domain logic” by putting data access and/or user interface code into their business objects. This is a bad idea, because it couples your domain objects to particular external systems, and it also doesn’t leave room in your domain classes for real domain logic when you need to add it. It should be placed in Services or Strategies that are outside of your domain model.
I’m concerned that oo “purists” disagree, since the GOF book contains many examples of moving complex logic out of the objects themselves and into classes dedicated to particular tasks. The best example is the visitor pattern, which enables you to easily add behaviors to a large class heirarchy, while keeping the behavioral logic encapsulated, rather than scattered across the heirarchy. Another relevant pattern is Command, which turns user actions into objects that can be easily managed for purposes of logging, security, undo, transport, loose-coupling of services etc…
These patterns go beyond the type of naive OO most of learned in school where classes represent nouns and methods represent verbs. But if they are not pure OO, then I don’t know what is. It shouldn’t be surprising that real application development requires some more depth.