Calling Them Managers

[Previous] [Next]

In this chapter, we've been talking about the difference between stateful objects and stateless ones. In our examples, objects have been stateless. We have, however, used class names that are liable to give a viewer of the model an impression of statefulness. For example, the class name Horses indicates that this class keeps state in the form of a collection of Horse objects, as you saw in Figure 8-4. In our example application, however, this isn't the case.

So we decided to use a different naming convention. Since the main business classes in diagrams such as the one in Figure 8-9 manage rather than keep information about horses, trainers, and countries, why not call them managers? They also perform services for their clients. Even more to the point, they supply information and information services to them. This might induce you to call them servers or suppliers rather than managers. HorseManager, HorseSupplier, or HorseServer—it's up to you. All these names are better for the kind of classes we are talking about here than Horses and Horse because the latter names indicate the keeping of application state.

Figure 8-9. The entity classes are now renamed to stress the fact that they manage data about horses, trainers, and countries rather than represent these types of objects.

Besides, if you choose names such as HorseManager, TrainerManager, and CountryManager for classes such as the ones we've been talking about, you still have the option—if needed—of adding stateful versions with names such as Horses, Horse, Trainers, Countries, and so on to your model.

On Personal Experience

If you want to use more object-oriented names (such as Horses and Horse), you should. This book isn't meant to be normative. What we want to do with it is to give you informative examples and what we hope is good advice. It's entirely up to you whether to follow the examples or deviate from them. We just hope that this book will help you make more informed decisions. Saying this, we can't help quoting Mark Twain. According to actor Hal Holbrook, Twain in How to Be Seventy reminds us that experience is the best way to find out about something. "A fellow who takes a hold of a bull by the tail is getting 60 or 70 times as much information as a fellow who doesn't. And if he once carries a cat home by the tail he's acquiring knowledge that's always going to be useful. He's never likely to grow dim or doubtful." Twain continues: "Chances are he'll never carry a cat that way again!" Then he goes on in a way very typical for him: "But if he wants to carry a cat that way, I say let him!"

So we say this: Anyone who once created a stateful and purely object-oriented application for thousands of simultaneous users is never likely to grow dim or doubtful about the possible consequences for scalability of statefulness. Chances are he'll never create such an application again. But if he wants to create such an application, I say let him! Just as long as he doesn't do it with your money!