Defining Classes from Our Designs

Okay, now its time for the big step: taking your diagrams and documentation and start coding your classes. Whoa, wait. Come back here. You need to design them first, not code them.

We can start by defining the three main types of classes: actor classes, business classes, and user interface classes.

Actor classes are classes that represent the actors within the system. Remember that an actor may be a person or an organization such as a government agency. In our registration example, we might say that one of the actors is the registrar who must approve each registration request. (As a programmer, you might think that you can automate the process completely, and perhaps you can. Just don t be surprised if this becomes a decision of an SME.)

Business classes are the classes that define the business rules, or the main logic of the application. For example, we may have an Enrollment class that governs and enforces the rules for enrolling in a class. Business rules (as described earlier) can get quite complicated, and it is common to have multiple business classes in an application, some of which collaborate with others. Sometimes, business classes can be thought of as representing the actors within a system that are not soft-shelled creatures (in other words, humans ) , such as a government agency.

User interface classes are classes that implement a specific user interface feature. Examples of these might be the CFormView class in MFC, the JPanel in Java, and the Form class in C#. Of course, these are really just base classes in their respective languages, and we would design new classes derived from them to add the desired functionality and controls we need in our application.

In earlier chapters, we discussed the process of designing classes. Simple rules such as describing the requirements in plain English will yield nouns and verbs. The nouns become classes, and verbs become the methods of the classes. It would also be good to take into account the Class Responsibility Collaborator (CRC) diagrams and cards we discussed in the previous chapter, to help define the classes themselves .

We should also discuss something that typically does not become a class: possessive nouns. If something is a possessive noun, such as student ID, then it most likely isn t a class but rather a property or attribute of a class. Of course, then again, it may be a class. We can easily identify that IDs come in various formats, such as Social Security numbers, ISBN numbers , and business tax IDs. For these, we may want to create a class to ensure proper formatting and validation when needed. The rule is, as always, use common sense and rethink the problem a couple times before finalizing your solution.